New warning message for repeated transforms

[ayrton04]

I just released robot_localization for Noetic, and I'm noting that while the tests pass, we are getting spammed with an endless stream of this message:

Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 1432235782.066014 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.1/src/buffer_core.cpp

For background, this is a common scenario with r_l:

Cycle 1: receive measurement from sensor with time stamp t1. Fuse measurement. Publish state (and transform) at time t1. Cycle 2: receive measurement from sensor with time stamp t2 < t1. Rewind filter, insert measurement from t2, fuse measurement from t2 and then measurement from t1. Publish corrected state at time t1.

From the way things look, it seems that tf2 used to re-insert the transform, until this change:

https://github.com/ros/geometry2/commit/eefb50935bfd28223c87b3d708e916f7bcc4b4ca

That would have been helpful for the use case in question, as overwriting the first transform is what we'd want to do.

However, it was later changed:

https://github.com/ros/geometry2/commit/04625380bdff3f3e9e860fc0e85f71674ddd1587#diff-c25683741e1f7b4e50eb6c5cdcad9661R275

Now insertData returns false and prints out an error.

Either of the previous behaviors would be preferable to the new one. What are the ramifications of restoring the behavior from this commit?

[duda1202]

Do you know how to ensure that it only suppresses the TF_REPEATED_DATA? Whenever I use this command and there is some error on my node, it just crashes with no error messages.

[corot]

My humble contribution: the warning easily floods the logs when running simulations at relatively low frequencies, e.g. old good Stage publishes /clock at 10 Hz, and it's not uncommon to configure Gazebo to a similarly low frequency on not-very-powerful machines. So any node producing tf msgs at > 10 Hz will trigger those warnings, as ros::Time::now() will return the same time more than once. We "solved" the issue by adding incrementing nanoseconds to equal tf msgs, but obviously warning once or throttling to a very low rate is a much better option.

All that said, the positive side is that we are now much more aware of how tf2 works. Thanks @tfoote for the great explanation, and for making so clear why we have this warning.

[tfoote]

That's an interesting case. It's a completely correct warning that the data is being dropped. If time is only turning over at 10Hz what value is publishing /tf at a faster rate? If time hasn't changed, I would have assumed that the source data shouldn't have changed either if the simulation hasn't updated yet. For example timers I would expect to be waiting for time to change over to the next timestep.

Another moderately simple option is to change the logging level up to ERROR or higher to avoid the warnings for those nodes.

[corot]

The thing is that in an ideal world, real-robot and simulation code should be 100% the same. On real robots you don't need to worry about discrete time, and so we shouldn't either on simulation. But this warning forces us to do so, e.g. not publishing new data until clock tics as @tfoote proposes.

[tfoote]

Yes, that's why I'm asking why things are turning over faster than the clock. I was asking why or how something is turning over and publishing faster than time is updating? If you have a timer it can only get triggered once per clock tick. If anything sleeps it should not return until the clock ticks over again. The joints and anything physical doesn't change until the simulator updates. Thus why is something publishing multiple times before the clock ticks?

When you slow down/make time jump in large discrete steps like 1/10th of a second it's expected that some things also loose precision. The general contract with sim time and discrete time is that things don't keep running. This is what allows you to pause the simulation. When you pause the simulation everything should stop. And until things tick over there generally shouldn't be new events being triggered. The system can be thought of as ticking over once per clock tick, and then pausing until the next clock tick, because they don't know when/if the next tick will come.

[raabuchanan]

The only thing that had ever worked for me is this: https://answers.ros.org/question/381529/suppress-tf_repeated_data-warnings/