# Extrapolation Error and AMCL

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 http://wiki.ros.org/navigation/Tutorials/RobotSetup 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

Frames:

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 ...

edit retag close merge delete

Sort by » oldest newest most voted

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. http://wiki.ros.org/ROS/NetworkSetup 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.

more

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.

more