ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

nav2 teb 'lookup would require extrapolation into the future'

asked 2020-07-22 16:41:10 -0600

johnconn gravatar image

I've been using the dwb Controller in the ros2 nav stack for a while now with success. Today, I wanted to try out the teb local planner.

Building and loading the plugin were a breeze, but for some reason, whenever I set a goal, I get this transform error:

[controller_server-10] [ERROR] [1595453488.697856494] [controller_server]: Extrapolation Error: Lookup would require extrapolation into the future.  Requested time 1595453488.692529 but the latest data is at time 1595453488.682535, when looking up transform from frame [odom] to frame [map]

Then my robot enters a recovery state, until it hits this error again.

If I switch back to using DWB, the error is gone!.

I'm using cyclonedds as my rmw implementation on ros2 foxy

edit retag flag offensive close merge delete


Did you solve the issue? And could you maybe share your configuration for the tab planner?

NEngelhard gravatar image NEngelhard  ( 2020-11-19 15:43:39 -0600 )edit

I also had the same problem, any solution?

sph gravatar image sph  ( 2021-03-30 01:43:36 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2020-07-22 20:37:27 -0600

updated 2020-07-22 20:38:14 -0600

TF issues can be caused by so many things its really hard to generally debug for someone else without doing it myself. I will say:

  • Check your odom->map publisher, make sure its publishing fast enough and slightly into the future since this leads your system

  • Check your robot state publisher, make sure its publishing fast enough

  • Check your outputs of RL and make sure that's fast enough

Almost all TF problems like that boil down in my experience to:

  • Poorly setup custom RL configs / sensor publishing / transform update rates

  • Your SLAM or localizer isn't leading the system a little bit

  • You're running on a tiny tiny CPU and overloading it (disguard if i3 or better)

This is the type of things you toil with once when you set up a new robot and hopefully never touch again afterwards.

edit flag offensive delete link more

answered 2021-05-12 06:50:53 -0600

AlexandrosNic gravatar image

updated 2021-05-12 08:52:27 -0600

To add to the previous accurate answer, in case you use hector slam, a solution is given in this post

Edit: Alternatively, @balkce suggested a solution for move_base's base_local_planner, by adding a waitForTransform here.

Another possible solution is to use amcl since it accepts future-dated transforms, as opposed to hector slam and gmapping

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: 2020-07-22 16:41:10 -0600

Seen: 913 times

Last updated: May 12 '21