play - publish /clock topic

[AndreasAZiegler]

Description

Feature request: Provide the --clock option so that rosbag2 publishes to the /clock topic alongside its messages.

Implementation Suggestion

Using starting_time of the bag and the stored (received) timestamp with every message, we can start a publisher for the /clock topic on playback and run it at a fixed rate, publishing messages when the next clock message is past their publishing time.

This requires no introspection or modification of the message contents themselves.

Note that player.cpp is already using message timestamps to sleep in between publishing, to approximate the original rates. In this loop (play_messages_until_queue_empty) we could potentially insert the clock publisher there.

Another option would be to put the clock publisher on a timer, and have it publish the last-published message time.

Original Ticket

From ros 1 I'm used to the --clock option in order that the topics have time stamps as If the system would run right now. I couldn't find this option in the documentation of rosbag2. How can I activate simulated time with rosbag2?

[Karsten1987]

Sorry for being so late on replying here. The concept of simulating time for rosbag2 is not yet realized. Therefore, there is currently no --clock option.

I am going ahead and close this issue. If there is a follow up to this topic, please feel free to re-open it and continue the conversation.

[IanTheEngineer]

Follow-on - @Karsten1987 & @jacobperron - playing back a /clock from a bagfile is very much a core feature in the ROS1 rosbag. Otherwise, no node requiring time can utilize the collected bagfile data during playback. These nodes will use the system clock instead, which will conflict with the recorded data's header timestamps. Specifially, tf and nodes that subscribe to it are useless without /clock.

From a practical standpoint, I am running a high frequency system-clock-publishing-node publishing /clock onboard our robots simply to be recorded for bagfile purposes. This is pretty much the only workaround to debug data collected from amcl, cartographer, perception nodes, etc.

[scoopySHI]

Can't agree more @IanTheEngineer. With --clock publishing msg in current time should be a core feature in ros2bag since the nodes are using current system time. For instance, the robot_localization pkg cannot output correct prediction with "ros2 bag play" bagfile data.
I have created a own branch time_fix to solve the problem temporarily by deserialize the msg and replace the time stamper manually for topic name /imu/data. But this is definitely not the generic solution. It is not clear for me how to write the generic de_serialize process for all msg types. Hopefully it can be solved in Foxy.
Or maybe you can give us some hint how to solve it efficiently :) @dirk-thomas @ivanpauno @Karsten1987

[kikass13]

@scoopySHI +1

[kikass13]

there is a solution from @scoopySHI which uses the ros2 message introspection to memcopy the "proper" ros time (message time propagated into current time) into the serialized message buffer.
That way we emulate a simulated time with the rosbag2 player. We do not know if this is the right way to do this, but it should work in principal and only requires introspection lookups for all messages before playing to find out if a header field exists.

This "feature" is obviously guarded by a --clock flag in the ros2bag python interface

Fork + branch:
https://github.com/scoopySHI/rosbag2/tree/time_fix

Relevant Section in source file:
https://github.com/scoopySHI/rosbag2/blob/time_fix/rosbag2_transport/src/rosbag2_transport/player.cpp#L191

This is a little buggy atm because we do not understand the message member offsets involved ... these structs define their offsets in a way which is not really consistent at first glance (because we do not properly understand the underlying dds implementation?). We will test it further tomorrow, but a little hint could help :)

[kikass13]

see #299 for further details

[kikass13]

our proposed solution did not work out in a way that was feasible.
so this is still a problem.

There is now a drive to implement the /clock topic for simulating time like ros1 did. Apparently the implementation works on the node side.

• how to do that properly is another issue and needs discussion
  • we have 3 separate solutions internally right now without even thinking too hard.

@scoopySHI and I will probably come back to this one at some point.

[emersonknapp]

note: I rewrote the issue description at the top to add some details about how this should be implemented

[vmanchal1]

Any chances this can make to the Foxy release?

[emersonknapp]

PRs are welcome - I don't know of anybody that has time to work on it right now. I believe we're cutting the beta version of the package today for testing - @Karsten1987 does the beta count as a feature freeze or should we only freeze features at the release candidate phase?

[Karsten1987]

I does not count for a feature freeze. I a feature like this one can be implemented in a somewhat straightforward way and we have still enough time to test that I am all up for it. I would just hold back from any major disruptive change across the code base at this point.

[KenYN]

Just to add my tuppence-worth, with code like:

timer_c_ = rclcpp::create_timer(
  this,
  this->get_clock(),
  rclcpp::Duration(std::chrono::milliseconds(timer_ms)),
  std::bind(&MyClass::timerCallback_c, this));

This does not tick at all! I playback my v1 bagfile with:

Ros1BagPlayNode = launch.actions.ExecuteProcess(
    cmd=['ros2', 'bag', 'play', '-s', 'rosbag_v2', LaunchConfiguration('bag_full_path')],
    name='rosbag_play',
    output='log',
    condition=IfCondition(PythonExpression(["'", LaunchConfiguration('bag_version'), "' == 'v1'"]))
)

However, if I use the ros1_bridge and:

rosbag play -r 0.5 --clock bag_full_path.bag

It works! This is a showstopper for us. At the simplistic level, if the ros1_bridge can do it, why can't ROS2 do it?

[emersonknapp]

At the simplistic level, if the ros1_bridge can do it, why can't ROS2 do it?

It's a functionality that exists in rosbag, to publish on the /clock topic on playback in sync with the messages being republished. This just hasn't been built in rosbag2 yet - there is no fundamental blocker. PRs always welcome, of course :)

[KenYN]

This just hasn't been built in rosbag2 yet - there is no fundamental blocker.

I've looked at the code, and yes, I can see one way to do it, and perhaps the Play/Pause functionality should be added too. I'm not sure about a PR, though, as I'd have to get work's legal etc involved...
What happened about #300 (comment) ?

[emersonknapp]

What happened about #300 (comment) ?

That PR unfortunately did not implement the desired feature. It was an attempt to re-stamp messages to current system time before publishing, rather than publishing to /clock to establish sim time. Additionally, in order to introspect and rewrite messages, it directly used an understanding of Fast-RTPS implementation, which made it nonportable to other RMW implementations.

[dejanpan]

I just wanted to post here a workaround for this issue that we are using in one large AD project: https://github.com/mitsudome-r/clock_publisher.

This is JUST a workaround, the proper solution should be implemented as part of the ROS 2 G roadmap: https://index.ros.org/doc/ros2/Roadmap/#id2.

[jediofgever]

sooo did this ever made to Foxy ?

[emersonknapp]

No - there is currently no plan to backport this to Foxy due to the difficulty of maintaining API/ABI stability while doing so. It is available in Galactic and Rolling distributions. To use it in Foxy you might have some luck patching the https://github.com/ros2/rosbag2/tree/foxy-future branch and building from source, but no promises

[jediofgever]

No - there is currently no plan to backport this to Foxy due to the difficulty of maintaining API/ABI stability while doing so. It is available in Galactic and Rolling distributions. To use it in Foxy you might have some luck patching the https://github.com/ros2/rosbag2/tree/foxy-future branch and building from source, but no promises

Thanks for the clarification !

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/fast-accurate-robust-replay-in-ros2/30406/2