lidarslam_ros2 icon indicating copy to clipboard operation
lidarslam_ros2 copied to clipboard

Transform lookup extrapolation warning

Open Destranix opened this issue 2 years ago • 7 comments

First: I'm using the scanmatcher node with ros2 galactic (ported from humble with a few changes of included headers).

When testing with gazebo, even for high odometry update rate (500 for odometry vs. 60 for laser), my log is spammed with transform lookup extrapolation warnings: Lookup would require extrapolation into the future. Requested time 20.364000 but the latest data is at time 20.346000, when looking up transform from frame [robot/base_link] to frame [robot/odom]

Maybe you could try to avoid printing a warning when tf is outdated or provide a parameter for maximum timeout or for supressing of that warning. Or you could try to work with the outdated data if possible (in my scenario the messages occure while the robot was standing and odom did not change, so here even old odometry data should be usable).

Destranix avatar Feb 14 '23 12:02 Destranix

in my scenario the messages occure while the robot was standing and odom did not change, so here even old odometry data should be usable

I don't think it is common for odometry values not to be updated when stopped. How about publishing odometry where the robot is stopped but only the timestamp is updated?

rsasaki0109 avatar Feb 15 '23 01:02 rsasaki0109

Sorry if I was imprecise. What I meant was, that even though the old data might be valid one might receive the extrapolation warning.

The actual problem is, that odometry data and laser data might have timestamps that differ too much from each other, leading to that extrapolation warning. That though might not be changeable (depends on update rate and aliasing), so the program maybe should offer simple possibilities to deal with that situation (like trying to use old odometry data and printing a warning only if that does not work (and maybe also allowing to disable the printing of that warning, depending on how likely that case is)).

Destranix avatar Feb 15 '23 07:02 Destranix

I was wrong. Thanks for the explanation. That is a problem. I think that's a common problem and I'll look into implementing it with reference to other OSS.

rsasaki0109 avatar Feb 15 '23 11:02 rsasaki0109

I've also seen a method allowing to set the maximum time tf2 is allowed to extrapolate, but that might have been in an earlier version of the API.

Destranix avatar Feb 15 '23 11:02 Destranix

I have the same problem, how did you solved it?

rafa-martin avatar Apr 23 '24 17:04 rafa-martin

It hasn't been resolved.

rsasaki0109 avatar Apr 24 '24 00:04 rsasaki0109