nav2 teb 'lookup would require extrapolation into the future'

Question

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

---

Originally posted by johnconn on ROS Answers with karma: 553 on 2020-07-22

Post score: 1

---

Original comments

Comment by NEngelhard on 2020-11-19:
Did you solve the issue? And could you maybe share your configuration for the tab planner?

Comment by sph on 2021-03-30:
I also had the same problem, any solution?

Answer 1

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.

---

Originally posted by stevemacenski with karma: 8272 on 2020-07-22

This answer was ACCEPTED on the original site

Post score: 2

Answer 2

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

---

Originally posted by AlexandrosNic with karma: 233 on 2021-05-12

This answer was NOT ACCEPTED on the original site

Post score: 2