I am encountering an issue with the NvbloxCostmapLayer when trying to transform between the map and odom frames in my ROS2-based application. The system frequently logs a warning about extrapolation into the future, as shown below:
[component_container_isolated-4] [WARN] [1727793921.601548454] [global_costmap.global_costmap]: [NvbloxCostmapLayer] Can’t transform: map to odom. Error: Lookup would require extrapolation into the future. Requested time 1727793921.600585 but the latest data is at time 1727793921.580367, when looking up transform from frame [odom] to frame [map]
It seems that the requested time for the transform is slightly ahead of the latest available data, causing the TF lookup to fail.
For context, I am using nvblox and have enabled visual odometry. I am successfully publishing the transform relationships from map to odom and odom to base_link. Despite this, the issue occurs intermittently.
Could you provide any guidance or best practices to avoid this “extrapolation into the future” error in Isaac ROS with NvbloxCostmapLayer? Specifically, I would like to know:
Are there recommended TF buffer or transform settings that can help mitigate this issue?
Should I be handling the transform requests differently to account for time delays or synchronization issues?
Any suggestions on improving TF performance, especially with visual odometry, to prevent this issue?
These types of errors are usually related to communication. There is one or more nodes that are receiving TF in delay. It can be the hardware communication, compute time, or something around these points.
I have some questions to help you better.
All ROS 2 nodes are running on the same platform?
if you are working on Jetson, which Jetson are you using?
Hi @Raffaello. I am having the same issue as well. All nodes are running on the same platform, and I’m using a Jetson Orin Nano. I tried the two solutions in the linked page, but neither worked.
@Raffaello I noticed the global_costmap is publishing at a lower rate than the Nav2 parameter, but changing the parameter doesn’t help. Wondering where else the problem may be.