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

Extrapolation error using hector_mapping + move_base

asked 2013-05-23 05:54:56 -0500

Huibuh gravatar image

updated 2013-06-05 03:16:34 -0500

Hello all,

I have a problem with my robot setup which I cannot resolve, even after reading all relevant posts on here. I really would appreciate your help.

Problem Description

The system starts up not generating any errors (see, producing an accurate map, and localization working well, too. As soon as I select a goal in rviz, move_base reproducibly throws the following errors:

[  ...]
[ERROR] [1369321339.784772926]: Extrapolation Error: Unable to lookup transform, cache is empty, when looking up transform from frame [/odom] to frame [/map]
[ERROR] [1369321339.785409391]: Global Frame: /odom Plan Frame size 107: /map
[ WARN] [1369321339.785726634]: Could not transform the global plan to the frame of the controller
[ERROR] [1369321340.434425166]: Extrapolation Error: Unable to lookup transform, cache is empty, when looking up transform from frame [/odom] to frame [/map]
[ERROR] [1369321340.434493357]: Global Frame: /odom Plan Frame size 107: /map
[ WARN] [1369321340.434528719]: Could not transform the global plan to the frame of the controller
[  ...]

However, if I make the following change in the local_costmap_params.yaml file:

local_costmap: global_frame: /odom


local_costmap: global_frame: /map

I don't get any errors and move_base generates a plan to the goal, which is also displayed in rviz. Unfortunately, the generated cmd_vel commands are very shaky, oscillate and weird navigation behaviour is the result.

My Setup

  • Robot: Custom robot with chain drive, i.e. non-holonomic. I have written a base_controller node for it which sends drive commands to the motors and uses the encoder information to calculate odometry and publish as tf+nav_msg (as described http:// I have also created a *.urdf file and use robot_state_publisher to publish the tf's for the model.
  • Sensors: Hokuyo UTM-30LX laser scanner
  • Nodes: max_driver (custom base_controller), hector_mapping, move_base, hokuyo_node
  • hector_mapping config:

[hector_config.launch] https://

  • move_base config:

[move_base_config.launch] https://

[base_local_planner_params.yaml] https://

[costmap_common_params.yaml] https://

[global_costmap_params.yaml] https://


  • Remote nodes: The hokuyo_node and the base_controller node run on an embedded PC, which is connected via ethernet to a powerful laptop running the remaining nodes. The time of both machines is synced via crony.
  • SW-Version: Ubuntu 12.04 + ROS Groovy, everything up to date

Debug Info

  • tf tree: [link] (https://
  • tf_monitor output:
ros@Base:~$ rosrun tf tf_monitor
RESULTS: for all Frames

Frame: /base_frame published by /max_driver Average Delay: -0.00377412 Max Delay: 0
Frame: /base_laser published by /robot_state_publisher Average Delay: -0.476582 Max Delay: 0
Frame: /base_laser_cap published by /robot_state_publisher Average Delay: -0.476592 Max Delay: 0
Frame: /base_laser_mount_box published by /robot_state_publisher Average Delay: -0.476591 Max Delay: 0 ...
edit retag flag offensive close merge delete


it would be great if you could provide solution to your problem, because I believe most ppl like me is struggling to get the navigation stack to work. Thank you verymuch!

Gazer gravatar image Gazer  ( 2013-06-18 12:12:05 -0500 )edit

I have the same problem. I looked at the code, the lookup fails in transformGlobalPlan, Either this is too strict about the timestamps or it has a bug which only surfaces in special cases.

Achim gravatar image Achim  ( 2013-08-07 03:35:35 -0500 )edit

I tried move_base with gmapping last week and got a similar issue... the robot moved for a few centimeters sometimes, but stopped with the same messages. Comparing the TFs, I get 40Hz from hector_slam and 50Hz from gmapping. So it seams the local planner is too strict with timestamps.

Achim gravatar image Achim  ( 2013-08-12 01:25:41 -0500 )edit

Hello Achim, I just saw your two recent posts. What are you suggesting to fix the problem? Increase the frequency of hector_slam? I still haven´t found a solution to make it work...

Huibuh gravatar image Huibuh  ( 2013-08-12 01:43:06 -0500 )edit

3 Answers

Sort by » oldest newest most voted

answered 2013-05-23 20:15:24 -0500

That's a very exhaustive report - certainly very helpful for finding the cause for your troubles. That being said, the cause of the problem isn't immediately obvious to me, as things look fine from looking over them (at least from a published tf/hector_mapping POV). I assume the /odom frame moves around in rviz as expected? First guess would've been some time sync problem between computers, but looking at your exhaustive tf debugging output, that doesn't seem to be the case. If there's no other troubles regarding the state estimation (robot pose, map etc all look fine) my guess is that the culprit is the setup of move_base (which hopefully someone else can look at).

edit flag offensive delete link more


Thank you for taking a look at this Stefan. Please see my updated post above regarding your odom frame question.

Huibuh gravatar image Huibuh  ( 2013-05-23 21:07:15 -0500 )edit

That sounds like correct odom frame behavior. What you could try is setting the fixed frame to odom and see if LIDAR data with decay time drifts slowly when the robot is moving as described here in comments:

Stefan Kohlbrecher gravatar image Stefan Kohlbrecher  ( 2013-05-24 07:46:10 -0500 )edit

answered 2013-08-13 04:51:19 -0500

David Lu gravatar image

I am unfamiliar with hector_mapping, but can you temporarily replace it with a static transform publisher?

edit flag offensive delete link more



Yes, unless the origin is set to something different, in which case the bottom left corner will be at the point specified in the origin.

David Lu gravatar image David Lu  ( 2013-08-18 09:46:25 -0500 )edit

also, I have one more question about the costmap2d. Currently, I am using Gmapping which produces a static map. The costmap2d takes in laserScan and static map to produce a costmap. If the static map already contains information about the unknown/free/occupied, why does costmap 2d still

Gazer gravatar image Gazer  ( 2013-08-18 13:40:38 -0500 )edit

needs the laserScan to reproduce the same information?

Gazer gravatar image Gazer  ( 2013-08-18 13:42:07 -0500 )edit

Answer 1: In case you're not GMapping. Answer 2: To make the local costmap which doesn't use the static map.

David Lu gravatar image David Lu  ( 2013-08-18 14:41:37 -0500 )edit

@david: Good idea, I will try to replace the map->odom transform generated by hector_mapping with a startic transform publisher and report back.

Huibuh gravatar image Huibuh  ( 2013-08-18 22:41:36 -0500 )edit

@David Lu, so basically in the nutshell, Map published from Gmapping has almost the same structure as with the 2D Map from Costmap2D? Where could I find the detail structure of the Costmap2d?

Gazer gravatar image Gazer  ( 2013-08-19 13:07:04 -0500 )edit

For the most part. Addendum Answer 3: If you use the voxel structure, it is not the same information.

David Lu gravatar image David Lu  ( 2013-08-20 04:13:28 -0500 )edit

I have the same problem as the one stated in this question. Since Huibuh doesn't seem to be reporting back as he said, I have tried replacing map->odom with a static transform publisher myself. Nothing changed! Same error!(I even tried different frequencies: last param of the static publisher)

AbuIbra gravatar image AbuIbra  ( 2013-10-10 10:03:54 -0500 )edit

answered 2013-08-17 18:18:43 -0500

Gazer gravatar image

@David Lu I have a quick quesiton about the 2d Map of the nav::occupancy_grid message type Is the (0,0) point (ie, the origin of the map) represents the lower left corner of the map?

edit flag offensive delete link more

Question Tools



Asked: 2013-05-23 05:54:56 -0500

Seen: 2,717 times

Last updated: Aug 13 '13