Transform lookup extrapolation warning

[Destranix]

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).

[rsasaki0109]

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?

[Destranix]

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)).

[rsasaki0109]

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.

[Destranix]

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.

[rafa-martin]

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

[rsasaki0109]

It hasn't been resolved.

[ncnynl]

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]

I also encountered this problem during simulation, which caused path drift. The default odom frequency is 50hz, but the actual odom released during simulation can only reach 33hz. By configuring the controller and odom release frequency to 100hz, the actual odom release reaches 68hz. This problem no longer occurs.