We use tf_fast_repeater from GitHub - tpet/nav_utils: Navigation utilities, odometry and tf processing etc. to listen to a slow transform (like map->odom) and republish it with fresher timestamps on a high frequency until a newer transform arrives (to keep the TF tree a tree, we invert the transform and publish it as odom->map_fast).
With this approach, each of our nodes can decide whether it wants exact transformations (then it will use map frame), or if it is okay with a little drifting and jumping transform (then it chooses map_fast). This allows for deliberate decisions between precision and latency. As an example - a node that integrates ICP-corrected scans into a map would use map, while rviz would use map_fast as the fixed frame. Then we get smooth movement of things in rviz even with very slow mapping (we had 0.3 Hz) - paying with the fact that things are a bit jumping around.
Just to say thanks @tfoote for the detailed explanation of the current system and design considerations. I hadn’t considered the aspects relating to maintaining the tf graph over time, with various publisher frequencies/latencies etc.
I still feel it should be possible to drop the single parent constraint, in a way that does not change the existing publisher/listener api, with the acknowledged drawback that the increased computational load may render this unusable for many applications. I’m interested in having a go at implementing this, just for the purpose of assessing/understanding how much slower such a system would be. However the list of projects I’d like to take on is quite long, so I’m not sure if I’ll ever get to this! I’ll try send an update if I make any progress.
Thanks @Kenji_Brameld for starting this thread, as it hit on a topic I’d been thinking about for some time, and everyone else who contributed for the informative discussion!