Ask Your Question
3

Costmap timeout

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

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

AHornung gravatar image

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 gravatar image Eric Perko  ( 2011-03-27 09:48:32 -0500 )edit

5 Answers

Sort by ยป oldest newest most voted
0

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

eitan gravatar image

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 more
0

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

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 more
0

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

eitan gravatar image

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 more

Comments

See the above localization launch file.
JediHamster gravatar image JediHamster  ( 2011-04-07 05:52:51 -0500 )edit
Does the "scan" topic have the correct frame_id associated with it so that AMCL can transform it to the "odom" frame?
eitan gravatar image eitan  ( 2011-04-07 07:47:27 -0500 )edit
Yes, it's connected to the kinect_fake_laser frame.
JediHamster gravatar image JediHamster  ( 2011-04-07 08:07:19 -0500 )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 gravatar image eitan  ( 2011-04-07 11:23:39 -0500 )edit
0

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

tfoote gravatar image

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 more

Comments

Changing both global_frame parameters to /odom gives the same warnings and errors.
JediHamster gravatar image JediHamster  ( 2011-03-27 10:38:57 -0500 )edit
Did you restart? If you did, you might be editing a different parameter file than you're executing.
tfoote gravatar image tfoote  ( 2011-03-27 13:20:38 -0500 )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 gravatar image JediHamster  ( 2011-03-28 23:03:05 -0500 )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 gravatar image JediHamster  ( 2011-04-06 10:22:58 -0500 )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 gravatar image eitan  ( 2011-04-06 10:34:52 -0500 )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 gravatar image JediHamster  ( 2011-04-06 20:51:30 -0500 )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 gravatar image JediHamster  ( 2011-04-06 21:50:32 -0500 )edit
Typically the costmap timeout occurs before the connectivity error.
JediHamster gravatar image JediHamster  ( 2011-04-06 21:52:39 -0500 )edit
0

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

Eric Perko gravatar image

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

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 more

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 gravatar image JediHamster  ( 2011-03-27 10:07:27 -0500 )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 gravatar image Eric Perko  ( 2011-03-27 10:10:55 -0500 )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 gravatar image tfoote  ( 2011-03-27 10:15:39 -0500 )edit
Ah... would /odom not show up in tf_monitor if it were only a parent frame?
Eric Perko gravatar image Eric Perko  ( 2011-03-27 10:18:01 -0500 )edit
Looking at TF within Rviz I can see the hierarchy /map -> /odom -> /base_link
JediHamster gravatar image JediHamster  ( 2011-03-27 10:44:05 -0500 )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 gravatar image JediHamster  ( 2011-03-27 10:52:05 -0500 )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 gravatar image Eric Perko  ( 2011-03-27 10:54:51 -0500 )edit
Intel Core 2 Duo 1.66GHz
JediHamster gravatar image JediHamster  ( 2011-03-27 11:00:38 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2011-03-27 09:44:20 -0500

Seen: 2,635 times

Last updated: Apr 08 '11