Should I publish transforms with future stamps to keep them "valid"?

edit

The correct way to do this is that the TF broadcaster publishes the transform with the correct time stamp (no future-dating), and the client nodes should wait for the transform to become available before looking it up:

http://wiki.ros.org/tf/Tutorials/tf%2...

For example, in Kinetic, base_local_planner does it like this:

https://github.com/ros-planning/navig...

In Melodic, base_local_planner has switched to TF2, and in TF2 it's possible to pass the timeout directly to lookupTransform:

https://github.com/ros-planning/navig...

So what both versions do is the same: They wait for up to 0.5 seconds for the TF transform with the proper time stamp and then look up the transform. If you get these errors, maybe you have more than 0.5 seconds latency? Another reason for this kind of error is when the TF broadcaster node runs on a different PC than the TF listener and the two clocks are not synchronized.

And by the way: one of the "default" nodes for publishing the map -> odom transform is AMCL, and it does indeed future-stamp the TFs that it broadcasts by transform_tolerance_ (by default 0.1 seconds):

https://github.com/ros-planning/navig...

The successor to AMCL, robot_localization, also provides this option (but it's off by default):

https://github.com/cra-ros-pkg/robot_...

I think the reason for doing this is that the map->odom transform usually doesn't change that fast (it's only a correction offset), and future-dating it reduces latency in all the waitForTransform calls in the client nodes. But I 100% agree with you, it's a hack and it has always bothered me a little.