Costmap timeout

asked 2011-03-27 09:44:20 -0600

JediHamster
995 ●42 ●53 ●59 http://sluggish.dyndns.org/

updated 2011-04-07 09:44:55 -0600

AHornung

5904 ●43 ●74 ●102 http://www.informatik....

When using amcl having set the initial pose I'm getting a lot of warnings related to costmap:

Costmap2DROS transform timeout

Eventually followed by:

[ERROR] [1301261347.311430182]: Connectivity Error: Could not find a common time /base_link and /map.

My costmap parameters look like the following:

local_costmap:
   global_frame: /odom
   robot_base_frame: /base_link
   update_frequency: 2.0
   publish_frequency: 2.0
   static_map: false
   rolling_window: true
   width: 5.0
   height: 5.0
   resolution: 0.1
   transform_tolerance: 0.5

global_costmap:
   global_frame: /map
   robot_base_frame: /base_link
   update_frequency: 2.0
   publish_frequency: 2.0
   static_map: true
   transform_tolerance: 0.5
   rolling_window: true
   width: 20.0
   height: 20.0
   resolution: 0.1

obstacle_range: 2.5
raytrace_range: 3.0
robot_radius: 0.3
footprint: [[-0.18, -0.24], [0.11, -0.24], [0.11, 0.24], [-0.18, 0.24]]
inflation_radius: 0.4
observation_sources: scan
scan: {sensor_frame: /kinect_fake_laser, data_type: LaserScan, topic: /scan, marking: true, clearing: true}

I've checked /odom and it is indeed being published regularly throughout. Any ideas on what might be causing the above warnings and errors?

RESULTS: for all Frames

Frames:
Frame: /base published by /robot_state_publisher Average Delay: 0.00295674 Max Delay: 0.00692934
Frame: /base_link published by /odometry Average Delay: 0.0201343 Max Delay: 0.0437646
Frame: /collar published by /robot_state_publisher Average Delay: 0.00296054 Max Delay: 0.00693374
Frame: /front_side published by /robot_state_publisher Average Delay: 0.00296375 Max Delay: 0.00693695
Frame: /head_pan_bracket published by /robot_state_publisher Average Delay: 0.00296677 Max Delay: 0.00693988
Frame: /head_tilt_servo published by /robot_state_publisher Average Delay: 0.0029704 Max Delay: 0.00694373
Frame: /head_tilt_support_left published by /robot_state_publisher Average Delay: 0.00297362 Max Delay: 0.00694736
Frame: /head_tilt_support_right published by /robot_state_publisher Average Delay: 0.00297716 Max Delay: 0.0069512
Frame: /joystick published by /robot_state_publisher Average Delay: 0.00298044 Max Delay: 0.00695455
Frame: /joystick_box published by /robot_state_publisher Average Delay: 0.00298363 Max Delay: 0.00695825
Frame: /kinect_depth_camera published by /robot_state_publisher Average Delay: 0.00298672 Max Delay: 0.00696168
Frame: /kinect_fake_laser published by /robot_state_publisher Average Delay: 0.0029899 Max Delay: 0.00696531
Frame: /kinect_illumination published by /robot_state_publisher Average Delay: 0.00299316 Max Delay: 0.00696894
Frame: /kinect_illumination2 published by /robot_state_publisher Average Delay: 0.00299688 Max Delay: 0.00697271
Frame: /kinect_pivot published by /robot_state_publisher Average Delay: 0.00300013 Max Delay: 0.00697634
Frame: /kinect_rgb_camera published by /robot_state_publisher Average Delay: 0.0030034 Max Delay: 0.0069799
Frame: /kinect_sensor published by /robot_state_publisher Average Delay: 0.00300658 Max Delay: 0.0069834
Frame: /left_axel published by /robot_state_publisher Average Delay: 0.00300997 Max Delay: 0.00698717
Frame: /left_castor published by /robot_state_publisher Average Delay: 0.00301312 Max Delay: 0.00699108
Frame: /left_castor_stand published by /robot_state_publisher Average Delay: 0.00301631 Max Delay: 0.00699457
Frame: /left_castor_stand_support1 published by /robot_state_publisher Average Delay: 0.00301972 Max Delay: 0.00699834
Frame: /left_castor_stand_support2 published by /robot_state_publisher Average Delay: 0.00302338 Max Delay: 0.00700246
Frame: /left_castor_stand_support3 published by /robot_state_publisher Average Delay: 0.00302763 Max Delay: 0.00700686
Frame: /left_castor_stand_support4 published by /robot_state_publisher Average Delay: 0.00303146 Max Delay: 0.0070114
Frame: /left_motor published by /robot_state_publisher Average Delay: 0.0030348 Max Delay: 0.00701503
Frame: /left_side published by /robot_state_publisher ...

(more)

edit retag flag offensive close merge delete

Comments

Can you include the output of "rosrun tf tf_monitor" or otherwise let us see what the tf statistics are for your tf tree?

Eric Perko ( 2011-03-27 09:48:32 -0600 )edit

add a comment

0

answered 2011-04-08 05:08:48 -0600

eitan
2743 ●16 ●18 ●36

The commanded velocity not being achieved shouldn't have any effect on the TrajectoryPlanner's ability to run. In fact, I've had our robot sit e-stopped for many minutes with a velocity being commanded and never seen anything like this. I'm very surprised that upping the velocity limits solves the costmap timeout problem for you as it should be totally unrelated.

I'm glad that you have things working, but I'm still quite puzzled as to what was actually going on.

edit flag offensive delete link

add a comment

0

answered 2011-03-27 10:03:00 -0600

Eric Perko

8406 ●73 ●90 ●144 http://ericperko.com/

updated 2011-03-27 10:14:07 -0600

According to the output of your rosrun tf tf_monitor command, you don't have anyone publishing the /map tf frame (or /odom frame) for that matter. You'll need to have a publisher for these frames (or change them in your costmap configuration files to frames you are publishing (for example, /odom == /odometry?))

Normally, /map frame is taken care of by amcl, which attempts to compute (by default) the transform between /odom and /map.

If you haven't already, take a look at the Robot Setup page for the navigation stack.

edit flag offensive delete link

Comments

If I run "rostopic hz /odom" I can see that it's publishing at the expected frequency. Odometry is the node which is publishing to /odom

JediHamster ( 2011-03-27 10:07:27 -0600 )edit

Not the /odom topic, the /odom tf frame. See how, in your local costmap config you specified "global_frame: /odom". Those are tf frames that your sensor data will be transformed into before being inserted into the map.

Eric Perko ( 2011-03-27 10:10:55 -0600 )edit

I see the odometry node publishing base_link which presumably has /odom as the parent. What you need is the transform from /odom -> /map to be published. That is usually published by a localization node, either gmapping or amcl. To get things running without localization you can change your global_costmap to work in /odom as well.

tfoote ( 2011-03-27 10:15:39 -0600 )edit

Ah... would /odom not show up in tf_monitor if it were only a parent frame?

Eric Perko ( 2011-03-27 10:18:01 -0600 )edit

Looking at TF within Rviz I can see the hierarchy /map -> /odom -> /base_link

JediHamster ( 2011-03-27 10:44:05 -0600 )edit

Changing both global_frame parameters to /map seems ok, but I get many warnings of the type "[ WARN] [1301266162.958055783]: Map update loop missed its desired rate of 2.0000Hz... the loop actually took 5.1950 seconds"

JediHamster ( 2011-03-27 10:52:05 -0600 )edit

Try turning off publishing (set publish_frequency to 0 or try some other slower rate). Your maps aren't really that large though... what are the specs for the computer you are running this on?

Eric Perko ( 2011-03-27 10:54:51 -0600 )edit

Intel Core 2 Duo 1.66GHz

JediHamster ( 2011-03-27 11:00:38 -0600 )edit

add a comment

0

answered 2011-03-27 10:16:57 -0600

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

I see the odometry node publishing base_link which presumably has /odom as the parent. What you need is the transform from /odom -> /map to be published. That is usually published by a localization node, either gmapping or amcl. To get things running without localization you can change your global_costmap to work in /odom instead of /map.

edit flag offensive delete link

Comments

Changing both global_frame parameters to /odom gives the same warnings and errors.

JediHamster ( 2011-03-27 10:38:57 -0600 )edit

Did you restart? If you did, you might be editing a different parameter file than you're executing.

tfoote ( 2011-03-27 13:20:38 -0600 )edit

I notice that once the error "Connectivity Error: Could not find a common time /base_link and /map" occurs Rviz is frozen, such that the time values are no longer incrementing. It might be that something is getting itself into an infinite loop.

JediHamster ( 2011-03-28 23:03:05 -0600 )edit

I notice that the first condition within MoveBase::clearCostmapWindows where the robot pose is retrieved is failing. Maybe there's either something wrong with the pose, or it's not being published.

JediHamster ( 2011-04-06 10:22:58 -0600 )edit

The pose of the robot is retrieved via TF, so it depends on the transform between the global_frame and the robot_base_frame being available. Its strange that rviz stops receiving TF when you try to run navigation. Does "rosrun tf view_frames" or "rosrun tf tf_monitor" change after the freeze?

eitan ( 2011-04-06 10:34:52 -0600 )edit

I notice I'm getting some warnings: [ WARN]: MessageFilter [target=/odom /kinect_depth_frame ]: The majority of dropped messages were due to messages growing older than the TF cache time. The last message's timestamp was: , and the last frame_id was: /kinect_fake_laser

JediHamster ( 2011-04-06 20:51:30 -0600 )edit

The resulting file, produced whilst getting the error "connectivity error: could not find a common time /base_link and /map" http://sluggish.homelinux.net/sandpit/frames.pdf

JediHamster ( 2011-04-06 21:50:32 -0600 )edit

Typically the costmap timeout occurs before the connectivity error.

JediHamster ( 2011-04-06 21:52:39 -0600 )edit

add a comment

0

answered 2011-04-07 05:08:30 -0600

eitan
2743 ●16 ●18 ●36

So, from the PDF you posted, it looks like whatever you're using to publish the "map" frame has indeed stopped publishing as no "map" frame exists in your TF tree. What are you using for localization? Also, "kinect_depth_frame" doesn't seem to exist in your TF tree. Perhaps you should be using "kinect_depth_camera" or "kinect_fake_laser" instead? Are your LaserScan messages stamped correctly? What node are the message filter warnings coming from?

Also, it makes sense that the costmap timeout would occur before the connectivity error, because the connectivity error is essentially the same thing just with a longer time threshold equal to the TF cache time.

edit flag offensive delete link

Comments

See the above localization launch file.

JediHamster ( 2011-04-07 05:52:51 -0600 )edit

Does the "scan" topic have the correct frame_id associated with it so that AMCL can transform it to the "odom" frame?

eitan ( 2011-04-07 07:47:27 -0600 )edit

Yes, it's connected to the kinect_fake_laser frame.

JediHamster ( 2011-04-07 08:07:19 -0600 )edit

Hmm. Can you run AMCL separately from the other parts of the navigation stack without issue? Does setting the initial pose of the robot through rviz work? Even when things are frozen, does the laser still publish scans at a reasonable rate?

eitan ( 2011-04-07 11:23:39 -0600 )edit

add a comment

0

answered 2011-04-07 22:04:01 -0600

JediHamster
995 ●42 ●53 ●59 http://sluggish.dyndns.org/

The solution to this turns out to be fairly simple. It looks as if the velocity commands being output from move_base are either below static inertia or only barely above it (this is quite a big heavy robot). Increasing the velocities within TrajectoryPlannerROS seems to overcome the problem. It could be that the timeout is caused by a growing position error between the current pose and the reference pose along the planned path, which maybe has some bad effects upon trajectory planning.

edit flag offensive delete link

add a comment

Costmap timeout

Comments

5 Answers

Comments

Comments

Comments

Question Tools

Stats

Related questions

Costmap timeout edit

Comments

5 Answers

Comments

Comments

Comments

Question Tools

Stats

Related questions

Costmap timeout