Closed ayrton04 closed 3 years ago
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.
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.
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.
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.
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.
The only thing that had ever worked for me is this: https://answers.ros.org/question/381529/suppress-tf_repeated_data-warnings/
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: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 timet1
. Cycle 2: receive measurement from sensor with time stampt2
<t1
. Rewind filter, insert measurement fromt2
, fuse measurement fromt2
and then measurement fromt1
. Publish corrected state at timet1
.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
returnsfalse
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?