ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Providing odom to move_base through a map->odom tf

asked 2013-05-08 16:02:00 -0500

Ernest gravatar image

updated 2014-01-28 17:16:28 -0500

ngrennan gravatar image


I'm providing odometry to move_base through a map->odom tf provided by hector_mapping.

This means that my odom topic is empty, which I think is the cause of a host of warnings, such as:

[ WARN] [1368064440.957099892, 700.300000000]: Costmap2DROS transform timeout. Current time: 700.3000, global_pose stamp: 700.0000, tolerance: 0.3000

[ WARN] [1368064440.957199828, 700.300000000]: Could not get robot pose, cancelling reconfiguration

I have managed to make move_base ignore the lack of odom messages by going to costmap_2d_ros.cpp of the costmap_2d package and doing this (warning: this is a bad hack!):

    // check global_pose timeout
if (current_time.toSec() - global_pose.stamp_.toSec() > transform_tolerance_) {
  ROS_WARN_THROTTLE(1.0, "Costmap2DROS transform timeout. Current time: %.4f, global_pose stamp: %.4f, tolerance: %.4f",
      current_time.toSec() ,global_pose.stamp_.toSec() ,transform_tolerance_);
  return true;
//  return false;

My question: is this a dangerous workaround? Is there a better way to tell move_base to ignore the odom topic?

Thank you in advance,


Sometimes, the two times are very different, which leads me to think that they might be in different time epochs:

Costmap2DROS transform timeout. Current time: 1368081077.4015, global_pose stamp: 136.4000, tolerance: 0.3000

When this happens, the quick hack described above doesn't help..

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2013-05-09 01:36:30 -0500

This is not a good idea. If your timing is off, you need to fix that other than try to make the warning go away. See my answer to your other question about the different time epochs.

edit flag offensive delete link more



Thanks. Your answer to the question for the different time epochs solved the second scenario (Current time: 1368081077.4015, global_pose stamp: 136.4000) for the first scenario (Current time: 700.3000, global_pose stamp: 700.0000) I made transform_tolerance param higher and that fixed the problem.

Ernest gravatar image Ernest  ( 2013-05-09 12:39:17 -0500 )edit

Question Tools

1 follower


Asked: 2013-05-08 16:02:00 -0500

Seen: 1,203 times

Last updated: May 09 '13