Pendulum teleop flakiness reduction #232
Conversation
dhood
added
in progress
There was a problem hiding this comment.
LGTM, I'm ok with this since the publisher was already transient local (clearly using durability was the intent, but was working due to the subscription settings).
Should the pendulum_teleop.cpp just spin? Does it need to exit like that?
If I were to implement it from scratch I'd probably use a periodic publisher, given the "real-time" nature of the demo. Better to have wasteful, but deterministic behavior rather than efficient, but asynchronously triggered extra work. At least that's what my intuition tells me.
|
Your questions are valid, I had been working under the assumption that it made sense to be that way for the actual pendulum demo (just publishing once then exiting), not sure if that's reasonable or not. |
* Sleep before exiting to get msgs out * Avoid interrupting already exiting pendulum demo * Use printf * Subscribe to teleop msg with transient local Makes test more robust to startup order * Force flush for output sync
As mentioned in ros2/build_farmer#94, there is still an unresolved/unidentified issue that causes the teleop test to hang, so this won't resolve flakiness completely. I reason that these changes are still worth merging so that they can be ruled out as the cause for future investigations.
CI linux with connext (only combo tests run for):
Repeating 100 times:
(I have seen on other builds that it's still prone to failure if you keep repeating the tests, but it's better)