Simulation time in replay mode

[JulioPlaced]

When replaying a recorded bag (using replay.launch.xml), the deserialized packets will be assigned the current ROS time instead of the simulated time (available in /clock topic). This causes the deserialized points/IMU to be desynchronized from other topics in the bag.

As far as we understand, even with use_sim_time=true, the call to rclcpp::Clock(RCL_ROS_TIME).now() (used here) is not able to subscribe to /clock itself; therefore it always returns the current ROS time. In ROS2 the simulation time (from /clock) is only accessible from a node, e.g. using node->now().

Screenshots Desynchronization example between GPS (with recorded time), clock (simulated time) and deserialized ouster points (using current ROS time)

We've coded a workaround that passes the node from os_cloud_node.cpp to the LidarPacketHandler and ImuPacketHandler classes, but we're wondering if this issue has been identified or addressed before. Otherwise we're happy to share it.

Platform:

• Ouster Sensor: OS-1
• ROS version/distro: Humble
• Operating System: Linux
• Machine Architecture: x64

[Samahu]

Hi @JulioPlaced, Although I have previously thought about this issue I have never looked in depth into replaying bag files storing raw sensor packets. Your question definitely sheds light on the issue. This is probably why I kept the timestamp_mode parameter available to users even within replay. Have you actually tried to replay the bag file with timestamp_mode set to TIME_FROM_ROS_TIME?

[JulioPlaced]

Hello @Samahu. Yes, timestamp_mode is set to TIME_FROM_ROS_TIME, and it is in fact retrieving ROS time (using rclcpp::Clock(RCL_ROS_TIME).now()). The problem with this time is that it is the current ROS time, not the ROS time at the time of recording. As far as I understand, the only way to access the simulation time in ROS2 is from within a node, since you have to subscribe to /clock. Therefore, instead of using rclcpp::Clock(RCL_ROS_TIME).now() here and here, we'd need to call node->now(). The first retrieves current ROS time whereas the second one subscribes to /clock and gets sim time. Let me know if that makes sense.

[Samahu]

Hello @Samahu. Yes, timestamp_mode is set to TIME_FROM_ROS_TIME, and it is in fact retrieving ROS time (using rclcpp::Clock(RCL_ROS_TIME).now()). The problem with this time is that it is the current ROS time, not the ROS time at the time of recording. As far as I understand, the only way to access the simulation time in ROS2 is from within a node, since you have to subscribe to /clock. Therefore, instead of using rclcpp::Clock(RCL_ROS_TIME).now() here and here, we'd need to call node->now(). The first retrieves current ROS time whereas the second one subscribes to /clock and gets sim time. Let me know if that makes sense.

Yeah that makes sense

[Hari3941]

Hi, When I changed the from 'lidar_packet.host_timestamp = static_cast<uint64_t>(rclcpp::Clock(RCL_ROS_TIME).now().nanoseconds());' to 'lidar_packet.host_timestamp = static_cast<uint64_t>(this->get_clock()->now().nanoseconds());' In os_clode_node line 203, it is assessing the clock while recording the bag file.

[JulioPlaced]

Any updates on this being fixed, @Samahu ?

[Samahu]

Hi @JulioPlaced, sorry for the delayed response. Please take a look at #440. With these changes && using the TIME_FROM_ROS_TIME timestamp_mode I do notice that the published messages are reporting the sim time.

Please let me know if this fully address the issue and I will have this merged soon!