Conversation
|
That is incorrect. See http://design.ros2.org/articles/clock_and_time.html#ros-time Until the If this patch actually fixes the problem then I would expect there is an underlying problem in ROS time which needs to be fixed (which would make this patch obsolete). |
I see. I did not recall that design document, so I wrongly inferred |
|
A curious thing is that it seems we're not testing waits for inactive ROS time clocks (see https://github.com/ros2/rcl/blob/master/rcl/test/rcl/test_timer.cpp, https://github.com/ros2/rcl/blob/master/rcl/test/rcl/test_wait.cpp and https://github.com/ros2/system_tests/blob/master/test_rclcpp/test/test_timer.cpp). |
|
closing now that ros2/rcl#357 has been merged |
This pull request attempts to fix failing
Waitabletests as seen in https://ci.ros2.org/view/nightly/job/nightly_linux_release/1023/testReport/, https://ci.ros2.org/view/nightly/job/nightly_xenial_linux-aarch64_release/194/testReport/ and https://ci.ros2.org/view/nightly/job/nightly_xenial_linux_release/188/testReport/. I'm no longer able to reproduce the issue locally with this fix.My current hypothesis as to what's going is that the original test hooks up the timer to the default
Nodeclock, which is ofRCL_ROS_TIMEtype i.e. clock as published on a well known topic. Because of this, the timer sets up a guard condition and waits for it to be triggered, but that never happens because for this test there's no clock topic being published in the first place.As to why it only fails for
Releasebuilds, it has to do with time. Until anRCL_ROS_TIMEtype clock becomes active, it reports wall clock time. If the time it takes the code to reach the firstrmw_waitcall is long enough for the timer to expire, then it will not block because the first wait wakes up because of the/parameter_eventssubscription. If it's too fast, then theExecutorwill go into a second wait cycle from which it'll never wake up (because no one's going to trigger the timer's guard condition).