I have a Linorobot running on a Raspeberry pi 4 and ROS 18.04 and a YDlidar.
It has been working without this problem for many months. I have not changed anything and this problem appeared in RVIZ a few day ago.
I have looked at the previous answers to this question but they do not apply to my case since my tf tree seems ok.
See the image below.
When i echo the transform from /laser to /map after two tries I get the transform echoed nicely
$ rosrun tf tf_echo /laser /map
Failure at 1634088802.435207342
Exception thrown:Lookup would require extrapolation into the past. Requested time 1634088802.397446394 but the earliest data is at time 1634088802.807524000, when looking up transform from frame [map] to frame [laser]
The current list of frames is:
Frame base_link exists with parent base_footprint.
Frame base_footprint exists with parent odom.
Frame imu_link exists with parent base_link.
Frame laser exists with parent base_link.
Frame odom exists with parent map.
Frame caster_left_link exists with parent base_link.
Frame caster_right_link exists with parent base_link.
Frame wheel_left_link exists with parent base_link.
Frame wheel_right_link exists with parent base_link.
Failure at 1634088802.435545412
Exception thrown:Lookup would require extrapolation into the past. Requested time 1634088802.397446394 but the earliest data is at time 1634088802.807524000, when looking up transform from frame [map] to frame [laser]
The current list of frames is:
Frame base_link exists with parent base_footprint.
Frame base_footprint exists with parent odom.
Frame imu_link exists with parent base_link.
Frame laser exists with parent base_link.
Frame odom exists with parent map.
Frame caster_left_link exists with parent base_link.
Frame caster_right_link exists with parent base_link.
Frame wheel_left_link exists with parent base_link.
Frame wheel_right_link exists with parent base_link.
At time 1634088803.397
- Translation: [-0.358, 1.633, -0.180]
- Rotation: in Quaternion [0.000, 0.000, 0.977, -0.212]
in RPY (radian) [0.000, 0.000, -2.715]
in RPY (degree) [0.000, 0.000, -155.535]
At time 1634088804.397
- Translation: [-0.356, 1.634, -0.180]
- Rotation: in Quaternion [0.000, 0.000, 0.977, -0.211]
in RPY (radian) [0.000, 0.000, -2.716]
in RPY (degree) [0.000, 0.000, -155.601]
At time 1634088805.397
- Translation: [-0.353, 1.634, -0.180]
- Rotation: in Quaternion [0.000, 0.000, 0.978, -0.210]
in RPY (radian) [0.000, 0.000, -2.717]
in RPY (degree) [0.000, 0.000, -155.700]
Originally posted by frge on ROS Answers with karma: 51 on 2021-10-12
Post score: 0
Original comments
Comment by gvdhoorn on 2021-10-13:
Is this a multi-host ROS application? If it is, clocks may have drifted between the hosts publishing and subscribing. Especially with TF, that can cause the problems you describe.
Comment by frge on 2021-10-13:
In principle this should not be the issue. I have an ntp server in the mobile robot and chrony in the remote pc with rviz. If i check the synchronicity it is looking ok see below
chronyc tracking
Reference ID : D8C59C53 (ntp.nyy.ca)
Stratum : 2
Ref time (UTC) : Wed Oct 13 19:31:41 2021
System time : 0.000142170 seconds slow of NTP time
Last offset : -0.000099168 seconds
RMS offset : 0.212730974 seconds
Frequency : 25.788 ppm slow
Residual freq : -0.240 ppm
Skew : 2.451 ppm
Root delay : 0.051655117 seconds
Root dispersion : 0.015191648 seconds
Update interval : 64.4 seconds
Leap status : Normal
As an additional point, if i add a screen to the mobile robot and also run RVIZ on this unique machine i still have the problem.
Comment by gvdhoorn on 2021-10-14:
Well it was one thing to check. I did not suggest it would be the one-and-only cause.