Closed bmagyar closed 3 months ago
@matthew-reynolds could you look at this? You resolved a similar issue in ros_control repo
The tests are still flaky (see #154 builds). But I found out why! We have timing issues. Probably is the runner CPU on maximal load and therefore limits/thresholds are not hold each time. For now, I adjusted the threshold a bit, but this is not a long-term solution. I added comments about that in the test file: https://github.com/ros-controls/ros2_controllers/blob/b89f5054a643d63c608186ffa42dd02c0f1005c5/joint_trajectory_controller/test/test_trajectory_controller.cpp#L458 and header file: https://github.com/ros-controls/ros2_controllers/blob/b89f5054a643d63c608186ffa42dd02c0f1005c5/joint_trajectory_controller/test/test_trajectory_controller_utils.hpp#L31
A possible (right) solution would be to measure real wait_time
in the updateController
method . And based on this value the hard-coded values would be adjusted (increased) https://github.com/ros-controls/ros2_controllers/blob/b89f5054a643d63c608186ffa42dd02c0f1005c5/joint_trajectory_controller/test/test_trajectory_controller.cpp#L462-L464
This should be done in all places the same testing approach is used or this could happen.
Regarding the flakiness of the actions tests, we should use custom trajectory constraints. (Or maybe rerun tests multiple times?!?)
The code evolved in the last years and it seems that the mentioned errors are not happening any more.
It causes sporadic failures on the CI