ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Timestamps and rosbags: discussing an alternative to clock and use_sim_time


when I play rosbags, sometimes I feel that the whole timestamp / clock /use_sim_time is hard to grasp and has many pitfalls and corner cases where it doesn’t work.

When I use rosbag play --clock and set the rosparam use_sim_time=true things work 90% of the time, but occasionally, especially with TF, this approach seems to be unreliable.

Am I the only one that had this kind of problems? Am I missing something?

I would like to implement an additional option for rosbag play to change the Header/stamp field of each message to avoid the simulated clock.

I am not asking if this is technically feasible (because I know how to implement it), I wonder if this is even desirable and if the community would find it useful; as I said, maybe the rest of the community is just happy with the default approach.



I think for a good portion of the use-cases this doesn’t come up as
typically you wouldn’t have more than 15-25 transforms in TF.

With more complex robots (humanoids, quadrupeds, etc) there’s a significant
increase and that’s where TF starts to fail. I’m not sure that problem is
with rosbag though…
I once thought of implementing an alternative way to capture the robot part
of TF by grabbing the urdf and joint states and let the
robot_state_publisher do it’s job on the go. Never really got around to do

I can’t really recall a case when it wasn’t TF failing. Could you bring an
example of something else failing with rosbag time?

If not less…

At least static transforms with rosbag fails 100% of the time :smiley:

I have found myself wanting this feature too. My poorly implemented solution was rosbaglive.

When you say “unreliable” do you mean you get TransformExceptions, or something else?

Im wondering whether timestamps or simulated time are the problem. We more often encounter issues because rosbag does not capture params and services. Also, there is some earlier discussion about inexact playback.

@iluetkeb I agree that one additional feature (may be a command line option) that would benefit rosbag would be to capture rosparams during recording and setting them at the beginning of playing.

That should be a quite simple in terms of implementability .

The problem you’re encountering is because rosbag play plays back messages in the order they were recorded in the bag file, but that is not necessarily the same as the chronological order of their timestamps nor the order they were broadcast in. Due to that, some messages can get replayed out of order compared to TFs that they relied upon.

I don’t think it’d be useful to make rosbag play change the header/stamp of messages; messages will still get played back in the wrong order, and you will be guaranteed to get different behavior from your system than was originally observed. Playing back bag files based on the order of message timestamps would be more useful, but also fairly difficult to do correctly due to how rosbags are structured.

The commonly accepted solution is to simply do a bit of post-processing on recorded bag files and reorder them so that messages are ordered based on their timestamps. There is an example snippet of Python code in the rosbag Cookbook that shows how to do that.

Edit: Oops, the example I was thinking of involves rewriting header timestamps, not reordering messages. I’ll see if I can find the code for that…

Edit 2: I added the script we use for reordering bag files to the cookbook page, since it’s fairly small and will hopefully be useful for other people.

1 Like

@preed Thanks a lot, I am sure that many people will find this useful.