0
$\begingroup$

Rosanswers logo

Hi,

I am working with a real kuka youbot robot. When I run AMCL I get constantly the following warning and error:

[WARN] [1531475915.405190988]: Failed to compute odom pose, skipping scan (Lookup would require extrapolation into the future.  Requested time 1531475915.373467473 but the latest data is at time 1531475915.371227514, when looking up transform from frame [base_link] to frame [odom])

[ERROR] [1531475915.405592384]: Couldn't determine robot's pose associated with laser scan

When I launch Rviz and set the initial pose with "2D Pose Estimate", /initialpose topic echo's the following:

header: 
  seq: 0
  stamp: 
    secs: 1531476085
    nsecs: 404504998
  frame_id: "map"
  pose: 
  pose: 
    position: 
      x: -0.121083259583
      y: -0.0682992935181
      z: 0.0
    orientation: 
      x: 0.0
      y: 0.0
      z: 0.00537968781778
      w: 0.999985529375
  covariance: [0.25, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.25, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.06853891945200942]

And in the terminal running AMCL appears:

[ INFO] [1531476085.547250607]: Setting pose (1531476085.547161): -0.121 -0.068 0.011

But after that it continues throwing same warning and error mentioned before.

I can not attach TF tree, but it is: map -> odom -> base_footprint -> base_link -> ...And TF transformations are working right at a rate, respectively in those cases, (starting with map -> odom) of: 21.609, 42.11, 50.981.

Here are the results of tf_monitor:

RESULTS: for all Frames
Frames:
Frame: /camera_depth_frame published by unknown_publisher Average Delay: -0.2982 Max Delay: 0
Frame: /camera_depth_optical_frame published by unknown_publisher Average Delay: -0.297965 Max Delay: 0
Frame: /camera_rgb_frame published by unknown_publisher Average Delay: -0.297891 Max Delay: 0
Frame: /camera_rgb_optical_frame published by unknown_publisher Average Delay: -0.297604 Max Delay: 0
Frame: arm_link_0 published by unknown_publisher Average Delay: -0.696617 Max Delay: 0
Frame: arm_link_1 published by unknown_publisher Average Delay: -0.191182 Max Delay: 0
Frame: arm_link_2 published by unknown_publisher Average Delay: -0.19118 Max Delay: 0
Frame: arm_link_3 published by unknown_publisher Average Delay: -0.191179 Max Delay: 0
Frame: arm_link_4 published by unknown_publisher Average Delay: -0.191179 Max Delay: 0
Frame: arm_link_5 published by unknown_publisher Average Delay: -0.191178 Max Delay: 0
Frame: base_footprint published by unknown_publisher Average Delay: -0.190222 Max Delay: 0
Frame: base_laser_front_link published by unknown_publisher Average Delay: -0.696646 Max Delay: 0
Frame: base_link published by unknown_publisher Average Delay: -0.696637 Max Delay: 0
Frame: camera_link published by unknown_publisher Average Delay: -0.29782 Max Delay: 0
Frame: caster_link_bl published by unknown_publisher Average Delay: -0.189073 Max Delay: 0
Frame: caster_link_br published by unknown_publisher Average Delay: -0.189071 Max Delay: 0
Frame: caster_link_fl published by unknown_publisher Average Delay: -0.18907 Max Delay: 0
Frame: caster_link_fr published by unknown_publisher Average Delay: -0.189069 Max Delay: 0
Frame: gripper_finger_link_l published by unknown_publisher Average Delay: -0.191177 Max Delay: 0
Frame: gripper_finger_link_r published by unknown_publisher Average Delay: -0.191176 Max Delay: 0
Frame: gripper_palm_link published by unknown_publisher Average Delay: -0.696653 Max Delay: 0
Frame: odom published by unknown_publisher Average Delay: -0.269718 Max Delay: 0
Frame: plate_link published by unknown_publisher Average Delay: -0.696657 Max Delay: 0
Frame: wheel_link_bl published by unknown_publisher Average Delay: -0.189068 Max Delay: 0
Frame: wheel_link_br published by unknown_publisher Average Delay: -0.189066 Max Delay: 0
Frame: wheel_link_fl published by unknown_publisher Average Delay: -0.189065 Max Delay: 0
Frame: wheel_link_fr published by unknown_publisher Average Delay: -0.189064 Max Delay: 0
All Broadcasters:
Node: unknown_publisher 199.909 Hz, Average Delay: -0.354249 Max Delay: 0

I do not know if there is a problem with the difference in publishing rates between TF transform /odom ->...-> /base_link and AMCL request time of that transform... I am stucked and I do not know how to solve this problem. I would really appreciate any help. Thanks in advance!


Originally posted by kuka_kuka on ROS Answers with karma: 23 on 2018-07-13

Post score: 0


Original comments

Comment by Humpelstilzchen on 2018-07-13:
First check that all computer in your ROS network share the same time. Its recommended to synchronized them with ntp.

Comment by kuka_kuka on 2018-07-16:
All nodes (except Rviz) are running on same machine

Comment by Humpelstilzchen on 2018-07-16:
The timestamps 1531475915.373467473 and 1531475915.371227514 are about 2ms apart, is it always that close? To what value have you set the amcl parameter transform_tolerance? Can you post a sample of your scan?

Comment by kuka_kuka on 2018-07-16:
Time difference varies between 0-5 ms. Transform tolerance is set to default (0.1) and modifying it to 0.5 does not make any change. You mean the result of the 2D map scan? The .yaml and .pgm files? Scan is made using gmapping.

Comment by kuka_kuka on 2018-07-16:
.yaml file:

image: my_map.pgm resolution: 0.050000 origin: [-5.000000, -5.000000, 0.000000] negate: 0 occupied_thresh: 0.65 free_thresh: 0.196

I think I cant attach images so I cant show the .pgm 2D map, but I think it is quite good. By the way, thank you for your help :)

Comment by Humpelstilzchen on 2018-07-16:
The output of a single rostopic echo /scan (or whatever your scan topic is)

Comment by kuka_kuka on 2018-07-16:
Cheader: seq: 74 stamp: secs: 1531743667 nsecs: 581998729 frame_id: odom angle_min: -0.546698212624 angle_max: 0.546698212624 angle_increment: 0.00171110546216 time_increment: 0.0 scan_time: 0.0329999998212 range_min: 0.449999988079 range_max: 10.0

Comment by kuka_kuka on 2018-07-16:
ranges: [nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, 3.259399652481079, 3.256758689880371, 3.281576156616211, 3.2762844562530518, 3.273649215698242, 3.2710208892822266, 3.2957406044006348, 3.293104410171509, 3.290475368499756 ...

Comment by Humpelstilzchen on 2018-07-16:
You have set frame_id of your scan to odom, is this correct for you? Usually the laser scanner is attached to the vehicle, which for you is probably camera_link.

Comment by kuka_kuka on 2018-07-16:
I changed it to /odom some weeks ago...I have set it to camera_link again and it seems that amcl works correctly now! I have lost so much time on this...Really thank you for your help!! :D

Comment by kuka_kuka on 2018-07-16:
Do I have to add an answer with the result? Or what am I suppose to do now for indicating the answer?

Comment by Humpelstilzchen on 2018-07-16:
You can post the answer if you like. Thats probably good for someone else with the same problem.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Thanks to "Humpelstilzchen" I was able to solve this issue. Laser frame was set to /odom instead of to /camera_link. After setting frame to /camera_link amcl warnings and errors dissapeared.


Originally posted by kuka_kuka with karma: 23 on 2018-07-16

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by aarontan on 2018-07-27:
where do you configure this?

Comment by kuka_kuka on 2018-08-14:
As I am working with a Kinect and not with a real laser I use a package that simulates the usage of a laser from the depth cloud received by Kinect. That package is called "depthimage_to_laserscan" and one of the parameters is "output_frame_id". I set that parameter to "camera_link":

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.