Transform [sender=unknown_publisher]Unknown reason for transform failure
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]
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.
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
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.
Well it was one thing to check. I did not suggest it would be the one-and-only cause.