rviz2 requests data ahead of system clock -> requires extrapolation into the future

Question

Hello everyone,

I'm trying to visualize LaserScan data from the map frame and I get the 'requires extrapolation into the future'-error. However, the requested time is actually ahead of the system clock (always almost precisely 71 seconds). The transformation map->odom->base_link->laser_frame seems to work, since the full tree is shown in the tf2 plugin in rviz2 and the LaserScan data can be visualized, when the fixed frame in rviz is set to base_link or laser_frame.

Rviz Error, (the requested time is ahead of the system time, while the "latest data" is spot on the system time):

[ERROR] [1626000928.858451390] [rviz2]: Lookup would require extrapolation into the future.  Requested time 1626000999.830946 but the latest data is at time 1626000928.843655, when looking up transform from frame [laser_frame] to frame [map]

• My own written node publishes the LaserScan and the header's stamp corresponds to the system time
• The base_link->laser_frame transformation is published by the robot_state_publisher
• The odom->base_link transformation is published by the ekf_node from robot_localization. I tried publishing it directly from my Odometry node, but nothing changed.
• For now, the map->odom transformation is a static_transform_publisher

When running tf2_monitor I get these results:

RESULTS: for all Frames

Frames:
Frame: base_link, published by <no authority available>, Average Delay: 0.00016122, Max Delay: 0.00232911
Frame: laser_frame, published by <no authority available>, Average Delay: 0.000118047, Max Delay: 0.00148201
Frame: odom, published by <no authority available>, Average Delay: 82.28, Max Delay: 82.28

All Broadcasters:
Node: <no authority available> 100.011 Hz, Average Delay: 0.000142455 Max Delay: 0.00232911

Has anybody an idea? What can I do, to further debug this problem? I've spent a few days on this problem and I'm absolutely clueless by now, this prevents me also from using Nav2 further down the line...

I'm using Ros2 Foxy and all nodes are running on one machine (Ubuntu 20.04)

---

Originally posted by Lukarios on ROS Answers with karma: 3 on 2021-07-11

Post score: 0

Answer 1

71 seconds is a very large offset. My initial thought is that you're on a different computer with an offset clock.

As you say the tree looks fine and can be rendered and viewed and appears to be approximately system time then the problem is likely the incoming data has a timestamp in the future.

A consistent large offset like that implies that there's like a different time source instead of a potential small latency due to transmission delays etc. The requested transform time comes from the timestamp of the incoming data. As such you should look at the timestamp of the incoming laser scan. And then trace back to what is generating that timestamp and what time source it's using.

---

Originally posted by tfoote with karma: 58457 on 2021-07-12

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by Lukarios on 2021-07-12:
First of all, thank you for your answer, I did not now that the requested timestamp is from the incoming laser scan. I agree, that this is a systematic error and not just "lag"

I checked and the LaserScan stamp is correct, meaning synchronized to the system clock, but this got me thinking about the LaserScan data. I set the scan_time and time_increment to 0.2 seconds (for reason I cannot remember) When leaving these undefined everything works!

Sorry, that this was just a mistake like this. I wouldn't have opened a question, if I hadn't spent days on it myself... Your answer lead me to the right way, thank you very much!

Comment by tfoote on 2021-07-12:
No problem, glad that you found the issue following the above. Please use the checkmark on the left of my answer to mark it as resolved so other's know that you've found your answer.

Yeah a time_increment of 0.2 is very large. That should be the interbeam time increment which is typically orders of magnitude lower. And scan_time should be the inverse of the scan frequency so you can know when to expect the next data.