Timeline mixup when running bagfile

[glpuga]

Bug description

A few transforms and messages are getting stamped with unmatched timestamps, probably as a result of a mixup when the bagfile was generated.

As a result of this, amcl is publishing the map->odom tf in a totally different timescale than the odom->base and base->laser_front , causing RViz to fail to display the later.

See timestamps on the logs and on the two transforms on the right:

See timestamps on the /clock and /scan topics:

On RViz,

Platform (please complete the following information):

• OS: Humble development container included in Beluga
• Beluga version: ed7dfe3

How to reproduce

List steps to reproduce the issue:

1. On a console: cd /ws && colcon build && source install/setup.bash && ros2 launch beluga_example perfect_odometry.launch.xml
2. On another console: ros2 topic echo /tf, ros2 topic echo /clock, ros2 topic echo /scan
3. On RViz, the TF visor will also show a warning for both base and laser_front.

Code snippets or minimal examples are always helpful, if not necessary.

Expected behavior

All message timestamps to be consistent when running out of a demo and test bagfile.

Actual behavior

Timestamps are not consistent with a single timeline, and some information fails to be displayed as a result.

[hidmic]

I think I saw this when working on #223. Messages carry some simulated clock stamp but rosbag2 stamped them on arrival using the system clock.

[glpuga]

This is probably related to beluga_benchmark being unable to measure NAV2 AMCL. The node crashes or dies out shortly after starting the playback, regardless of the configuration.

Bisecting with git the problem, it seems to have started after #211 when we refactored the bagfile and launchfiles.

[nahueespinosa]

Ah, that was me.

I did two things that might have caused this:

1. I removed the /clock topic messages from the ROS bag.
2. I added the --clock option to the ROS bag play command.

The motivation was being able to play ROS bags that don't have /clock messages, like the ones we recorded in HQ (do you have any thoughts on how to do this correctly?).

Seems like it was not the right approach, we can definitely revert the changes to the ROS bag.

[stwirth]

From my experience, you always must use --clock (with /clock topic) to be safe. There are many packages that mix the use of ROS time (which is current system time if no --clock is used) and message header stamps.