Allow running Sensors and Physics update in Lockstep mode

[YoshuaNava]

Desired behavior

Classic Gazebo provided a Lockstep mode that synchronized the update of physics and sensors -> https://classic.gazebosim.org/tutorials?tut=lockstep_physics_sensors

This mode allowed the simulation to better resemble a real-system, where sensors are sampled uniformly following a global clock, fitting the same timeline as the physics.

However, this feature does not seem to be present in New/Ignition Gazebo. Could it be implemented? Happy to help if so!

Alternatives considered

Not relying on the Lockstep mode, but this would make our simulation less representative of a real system.

Implementation suggestion

Implementing an equivalent of the Classic Gazebo Lockstep mode.

Additional context

None

[iche033]

This should be supported by default in gz-sim (without needing to specify any args on launch). If you set a camera sensor to run at 30 Hz, it should run at the specified rate in sim time. If the camera can not render fast enough, it would block the main / physics thread and hence lowering the sim RTF.

However, this feature does not seem to be present in New/Ignition Gazebo

Are you running into issues where you see that physics and sensors are not lockstepping?

[azeey]

Technically, it is possible for the next physics step to occur before the rendering/sensor system blocks, but this only introduces one extra time step in physics. If this is a concern for you, I'd like to know, but otherwise, as @iche033 said, Sensors and Physics do run in lockstep by default in the new Gazebo.

[YoshuaNava]

Hi @iche033 and @azeey,
First of all, thank you for your prompt reply.

Are you running into issues where you see that physics and sensors are not lockstepping?

We may have observed physics and sensors updating at different time frames.

To be more specific on the testing setup, my project partner @Magnusgaertner and I were running a Distrobox of Ubuntu 24.04 with ROS2 Jazzy. When running some of the single-camera examples from this repo, the /stats topic of the simulator indicated a higher update rate (>60%), than the frequency of the camera topic (it was set to 30Hz, but we could get at most 8 Hz).

Technically, it is possible for the next physics step to occur before the rendering/sensor system blocks, but this only introduces one extra time step in physics.

Out of curiosity, how is this mechanism for synchronizing and spinning a new physics iteration implemented?

Thank you in advance 🙏

[iche033]

is the 8 Hz output from ros topic hz or gz topic -f -t? I think they output the frequency in wall clock time instead of sim time. If your simulator is running at a lower RTF, the frequency output from those tools will be lower than expected. The cameras should still be updating at their target rate in sim time. If not, then there could be a bug. One way to double check this is to look at the timestamps of the received camera images - they should indicate that the images are published at fixed intervals.

[iche033]

I wrote a simple python program to verify camera timestamps some time ago, see osrf/mbzirc#147 (comment) in case it helps