Ask Your Question

Extrapolation Error and AMCL

asked 2013-12-01 14:47:27 -0500

pwong gravatar image

updated 2013-12-12 20:06:07 -0500

tfoote gravatar image

Its my first time trying to get the navigation stack up and running. After fiddling with the .yaml files, I've gotten it to move with RVIZ. There are some issues I'm running into.

The robot is having issues localizing. My set up follows the tutorials, but only have a laser scanner as an input.

Here's the error generated by move_base.launch.

[ERROR] [1385945596.417775629]: Extrapolation Error: Lookup would require extrapolation into the future.  Requested time 1385945596.400712013 but the latest data is at time 1385945596.309387000, when looking up transform from frame [odom] to frame [map]

[ERROR] [1385945596.417830096]: Global Frame: odom Plan Frame size 305: map

[ WARN] [1385945596.417853423]: Could not transform the global plan to the frame of the controller

After reading up on some other posts on answers.ros, to see what could be the problem, I took a look at my transforms, and I don't think thats it.

Here is the tf_monitor report.

RESULTS: for all Frames

Frame: /base published by /base_ctrl_odom Average Delay: 0.000454951 Max Delay: 0.000718333
Frame: body published by /robot_state_publisher Average Delay: -0.499598 Max Delay: 0
Frame: bracket published by /robot_state_publisher Average Delay: 0.000529436 Max Delay: 0.000995636
Frame: bracket_90 published by /robot_state_publisher Average Delay: -0.499596 Max Delay: 0
Frame: hokuyo published by /robot_state_publisher Average Delay: -0.499597 Max Delay: 0
Frame: hokuyo_90 published by /robot_state_publisher Average Delay: -0.499597 Max Delay: 0
Frame: left_wheel published by /robot_state_publisher Average Delay: 0.000526063 Max Delay: 0.000993213
Frame: odom published by /amcl Average Delay: 0.0103003 Max Delay: 0.0867516
Frame: right_wheel published by /robot_state_publisher Average Delay: 0.000528483 Max Delay: 0.000995021
Frame: servo published by /robot_state_publisher Average Delay: -0.4996 Max Delay: 0

All Broadcasters:
Node: /amcl 41.432 Hz, Average Delay: 0.0103003 Max Delay: 0.0867516
Node: /base_ctrl_odom 5.82941 Hz, Average Delay: 0.000454951 Max Delay: 0.000718333
Node: /robot_state_publisher 60.1176 Hz, Average Delay: -0.420926 Max Delay: 0.000994623

I also ran

>rosrun tf tf_echo odom map

But there wasn't anything that threw a red flag at me.

There were three of those errors thrown when I was running the navigation stack. The room I'm using was fairly large. I used rviz to set an initialpose. After I did that, sending a it a goal didn't go too well. It moved a lot farther than it was suppose to, and I had to shut it off before it had a chance to try to complete the path. It also did a lot of extra rotating even though it was sent a straight path.

What additional information would be helpful to debug this issue? I'm not too sure where to look myself.

Thank you!

Edit: After reducing the size of the local cost map back down to the original size of 6x6 @ 0.5 resolution, the extrapolatoin error went away.

There weren't any grid cells with ... (more)

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted

answered 2014-01-19 15:00:18 -0500

pwong gravatar image

updated 2014-01-19 15:02:13 -0500

After making sure the odom message is being published is correctly, the main issue on getting it to run smoothly was the laptop.

To make sure the CPU didn't stall, I essentially lowered the local/global maps and move_base controller update frequency to a point where the navigation wouldn't work well at all. For me, the map updating/publishing rates were down to 3Hz and 2Hz, respectively. The move_base frequency was also down to 3-4Hz. On top of this, I was running rviz on the same laptop on an integrated graphics card.

Some of the behaviors I had while running with the above setup was:

  1. The local planar detected an obstacle. As it moves around it, the obstacle was dragged across the local map, enclosing the robot an completely unmovable space.

  2. This lead to the robot getting lost, a lot. I would see it moving to the goal designated, but when it gets there, it would spin to get the correct orientation. While this happens, the laser scan would slowly move out of place of the global map.

Here is a couple general rule of thumb if you want to run the navstack.

  1. Use gnome-system-monitor to see if the CPU is close to stalling. If you are, try splitting some of the cpu intensive nodes across different machines. Or run rviz on different machine and just have the navstack run on the local machine.

  2. Don't run the map/controller frequency lower than the ros nav stack guide.

I upgraded to a laptop with an i7-4th gen (~2.2Ghz), and an nvidia graphics card. I run the map publish rates and controller publish rates to twice the ros tutorial's values. It can run at higher velocities and smoother motions!

Hopefully this post will help someone run the navstack successfully for the first time(like me). If any of this is incorrect, please comment and I'll edit the post!

Edit: Naturally, those errors went away after the upgrade and the CPU stopped stalling/running so slow.

edit flag offensive delete link more


This answer actually helped me a lot. Sepecifically, decreasing 'controller_frequency' parameter removed the error message and the planning worked. By the way, i don't know why changing the parameter's default value in the move_base.cpp did not work. I added parameter set line to my launch file and it worked

Harestew gravatar image Harestew  ( 2020-03-09 01:21:23 -0500 )edit

answered 2014-09-11 05:10:14 -0500

rastaxe gravatar image

I had the same problem with an youbot (ROS Hydro), that mounts a no powerful pc. I solved this problem changing the global frame of the local costmap from odom to map. The error disappeared and the navigation behavior became more smoothly and promptly with no drawback until now.

edit flag offensive delete link more

answered 2020-11-12 02:36:33 -0500

Sai Krishna gravatar image

updated 2020-11-12 05:09:12 -0500

I have faced the same problem. This problem is solved by increasing the value of "transform_tolerance" parameter to 1.0 (default is 0.1) of amcl node. Just for information, I am running ROS navigation stack and RVIZ completely on Jetson nano. After increasing the value of transform_tolerance, this error is resolved and everything worked fine.

edit flag offensive delete link more

Your Answer

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

Add Answer

Question Tools



Asked: 2013-12-01 14:47:27 -0500

Seen: 3,362 times

Last updated: Nov 12 '20