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

Revision history [back]

click to hide/show revision 1
initial version

I was also getting the "Extrapolation into the future" errors when using move_base with amcl. I switched to a faster localization package and it fixed these errors for me.

I am guessing amcl's update rate was very low on my machine. The gap between 2 readings must have been greater than transform_tolerance parameter. This parameter specifies the acceptable delay in transforms required by move_base - map to odom and odom to base_link.

Imagine this case: if at any instance move_base is requesting a map to odom transform and if more than transform_tolerance seconds have passed since the last transform, the next valid transform would be into the future (since amcl post dates transforms using its own transform_tolerance parameter). I tried reducing amcl's transform tolerance, even made it zero, but the problem remained. Another approach would be to increase move_base's transform tolerance (it was already at 0.5 for me), however that would cause errors in path planning since the robot would have moved by a non-trivial distance during that time.

As faster localization package, MIT's Particle Filter, fixed it for me. I publishes a map to laser transform by default. I had to make some changes so that it publishes a map to odom transform instead.

I was also getting the "Extrapolation into the future" errors when using move_base with amcl. I switched to a faster localization package package, MIT's Particle Filter, and it fixed these errors for me.

EDIT: I am guessing amcl's update rate was very low on my machine. The gap between 2 readings must have been greater than transform_tolerance parameter. This parameter specifies just realized that the acceptable delay in transforms required by move_base - map to odom and odom to base_link.

Imagine this case: if at any instance move_base is requesting a map to odom transform and if more than transform_tolerance seconds have passed since the last transform, the next valid transform would be into the future (since amcl post dates transforms using its own transform_tolerance parameter). I tried reducing amcl's transform tolerance, even made it zero, but the problem remained. Another approach would be to increase move_base's transform tolerance (it was already at 0.5 for me), however that would cause errors in path planning since the robot would have moved by a non-trivial distance during that time.

As faster localization package, MIT's Particle Filter, fixed it package did not fix these errors for me. I publishes a map made one more change along with using another localization package. I set the global_frame of local_costmap_params.yaml to laser transform by default. map, earlier it was set to odom. This fixed these errors. No matter what localization package I had use, if I set global_frame to make some changes so that it publishes a map to odom transform instead.odom then I get these errors.