-
Notifications
You must be signed in to change notification settings - Fork 501
Description
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
/clockat a givenupdate_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_testnode 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_testusing 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.