Thanks! Very useful. I was trying ‘ign topic’ but I guess that’s specific to Ignition Gazebo which I was also testing recently.
Sorry, the second “question” was actually just setting up for my final question re: the difference in RTF/data output rates when running with the Physics update rate set to zero. I’m using this ROS2 port of the velodyne_simulator package with the update rates set to their default 10Hz.
Thanks, maybe this is more a question about ROS2 than Gazebo in that case. Perhaps I’m wrong in stating that the sensor output rate differs between ROS2 CLI/rviz2 and Gazebo; I will check this more rigorously. I’m pretty sure the CLI tool (ros2 topic hz) is correct, and rviz2’s message count is wrong.
I guess I’m still a little confused about how the real_time_factor, real_update_rate, and sim_update_rate are all related based on the docs you linked. Is the following summary correct?
- sim_update_rate is the sensor update rate in simulation time, ie how many times the sensor data is updated per simulated second
- real_time_factor is the rate of simulated time versus real (system clock) time, which is also the rate the physics are updated
- real_update_rate is the sensor update rate in real time, which is calculated as RTF * sim_update_rate. This is identical to we should see using the ROS2 CLI to measure data output rate from Gazebo, as ‘ros2 topic hz’ appears to use
If this sounds correct, then my goal is to keep sim_update_rate fixed to the desired rate (which lockstep should accomplish) while also increasing RTF as high as possible. I think this is what users would expect by default when trying to run faster-than-realtime; it’s pretty confusing to see RTF>1 but see the output rate has actually dropped below the nominal value, in my opinion.
Does this all make sense? Am I missing anything which could help for faster-than-realtime operation?