Timer callbacks and rate sleep behave differently if sim clock update rate is slow

[guihomework]

Not really a bug but a difference of behavior

When using timer_callbacks in a rclcpp node with a sim clock (typically along with gazebo) to regularly call a callback, the callbacks will not be called on time if the simulated clock publish_rate or update_rate is too slow.

This is known, however not as clearly explained in ROS 2 in comparison to ROS.

Indeed, in http://wiki.ros.org/Clock mentions when using sim time

Then, the time will only be updated on receipt of a message from the /clock topic, and will stay constant between updates.

which explains why a slow update_rate on /clock might lead to missing the correct time to wake up a callback.

in ROS 2, I did not find this clear statement that the simulated clock is constant between updates, in the main doc, but it appears in the design document

The problem is that when using rate.sleep, the callbacks seem to be called on time.
After digging, I think the reason is that rate does not care about sim time.
However, with time passing slower than real time using rate.sleep will lead to wrong timing again.

My question is then, if rate gets fixed to be aware of sim time in #465, will it then behave like timer callbacks ?

Required Info:

• Operating System:
  • Ubuntu 22.04.2
• Installation type:
  • binaries
• Version or commit hash:
  • rolling
• DDS implementation:
  • default
• Client library (if applicable):
  • rclcpp

Steps to reproduce issue

Use my example package at my repository

https://github.com/guihomework/ros2_tests/tree/main/test_timers

It offers :

• a simulated clock node that publishes walltime on /clock at a given update_rate. This clock is not slower than realtime, it just sends its messages containing the current time at a specific update_rate on /clock
• a rate_test node that uses rate.sleep in a main loop to call 2 callbacks that publish messages at slow 1 Hz and fast 20 Hz rates
• a similar node timer_test using timer callbacks instead (which is the recommended and obviously cleaner way)

One can choose which test is started, and the update_rate for the simulated clock. See README.md in the repo.

Additionally a setting also starts gazebo empty world with its default 10 Hz settings or a 100 Hz publish rate setting. This option is not necessary to test the behavior but is the real-life scenario that unveiled the issue.

Expected behavior

I now understood that there is no interpolation of the ROSTime clock as stated in the design document.
At least using either rate.sleep() or timer callbacks, the messages should be sent on topics at the same rate (depending on sim clock updates).

Actual behavior

With a slow simulated clock update_rate (typically at 10 Hz which is the default value in gazebo simulated clock publish_rate) , timer callbacks are not called on time but rate.sleep seem to behave correctly (I know it is not as it follows walltime which could be different than sim time)

Final thoughts

Even if I used ROS for 9 years and ROS 2 for 6 months now, I faced that issue using ROS 2. I am not sure if ROS has the same different behavior or if gazebo was updating the /clock faster or if I never used timer callbacks in the past, but for sure I did not understand the reason immediately, and I ensure I read the doc and tutorials of ROS 2 before starting with it.
Intuitively I was expecting some interpolation of sim clock but it is not the case.

Thanks to the people who raised awareness on this issue there https://articulatedrobotics.xyz/mobile-robot-12a-ros2-control-extra/ and there https://github.com/cpslabor-education/robotwiki/wiki/[Simulation][Gazebo]-Gazebo-simulation-in-ROS-2.

[clalancette]

My question is then, if rate gets fixed to be aware of sim time in #465, will it then behave like timer callbacks ?

Correct. We currently have a pull request in review that will allow us to do this for Rate, at least: #2123

[guihomework]

(using correct account this time to answer) @clalancette thanks for clarifying and showing the latest state on that matter.
Should we keep this issue open until the behavior is matching between Rate and Timer Callbacks ?

[clalancette]

Yes, we can keep this open. I'll mark this as one of the issues to be automatically closed when we merge #2123