search

ros-navigation / navigation2

ROS 2 Navigation Framework and System
https://nav2.org/
Other
2.58k stars 1.3k forks source link

Extrapolation Error: Lookup would require extrapolation into the future #3101

Closed miku54 closed 2 years ago

miku54 commented 2 years ago

Steps to reproduce issue

When I use gmapping to build a map, use that map to navigate, everything works fine when I run nav2, In rviz, I give the robot a 2D Nav Goal. Immediately, I get the following error: Failed to transform initial pose in time (Lookup would require extrapolation into the future. Requested time 1659339558.513968 but the latest data is at time 1659339558.496260, when looking up transform from frame [base_footprint] to frame [odom_combined]) [recoveries_server-15] [ERROR] [1659339575.919917542] [transformPoseInTargetFrame]: No Transform available Error looking up target frame: "odom" passed to lookupTransform argument target_frame does not exist. My navigation parameters can be seen here https://github.com/ros-planning/navigation2/issues/3012

padhupradheep commented 2 years ago

Are you sure, if the "odom" frame is being broadcasted?

miku54 commented 2 years ago

Hi, thanks for the reply! I'm pretty sure I'm not broadcasting the coordinates of the odom, including the topic of not remapped odom, my odometer data is always odom_combined.

Are you sure, if the "odom" frame is being broadcasted?

padhupradheep commented 2 years ago

No worries, you can read the docs on first-time robot setup. You can find all the details regarding transformation setup and so on.

In the future, it would be nice, if you could forward your questions to answers.ros.org , as this tracker is mainly focused on feature requests and bugs.

SteveMacenski commented 2 years ago

It looks like you need to configure (or modify) gmapping to forward date the timestamps a bit more. The global localization system needs to “lead” the clock slightly so that transformations for “now” always have that element of the tree represented, even if the last time the localizer ran was a few milliseconds ago. Since the localizer runs relatively infrequently, we republish this transform at current stamps + a leading amount at a regular interval to complete the tree for any reasonable request. This is totally fine since that transform won’t change either until an update is made and isn’t very time sensitive. We do this in slam toolbox using the transform tolerance param and was done so in ROS 1’s gmapping.

Since there is no formally supported version of gmapping in ROS 2, I can’t comment on the quality of the port to having done these more subtle timing elements correctly. That would be something to address in that project.