play - publish /clock topic about rosbag2 HOT 20 CLOSED

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.

from rosbag2.

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.

from rosbag2.

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.

from rosbag2.

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

from rosbag2.

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.

from rosbag2.

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

from rosbag2.

@scoopySHI +1

from rosbag2.

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 :)

from rosbag2.

see #299 for further details

from rosbag2.

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

from rosbag2.

Any chances this can make to the Foxy release?

from rosbag2.

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?

from rosbag2.

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.

from rosbag2.

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?

from rosbag2.

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 :)

from rosbag2.

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) ?

from rosbag2.

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.

from rosbag2.

sooo did this ever made to Foxy ?

from rosbag2.

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 !

from rosbag2.

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

from rosbag2.