PoC: Blocking read implementation#1760
Draft
urfeex wants to merge 5 commits intoUniversalRobots:mainfrom
Draft
Conversation
The robot's control loop runs on a fixed time, communication may add a jitter on that. We want to sample the targes at the control loop time.
3 tasks
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1760 +/- ##
========================================
+ Coverage 3.59% 4.92% +1.33%
========================================
Files 13 37 +24
Lines 947 4307 +3360
Branches 152 502 +350
========================================
+ Hits 34 212 +178
- Misses 843 4093 +3250
+ Partials 70 2 -68
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Contributor
|
🎉 no more |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is mainly a testing PR for implementing a non-sleeping ros2_control node that follows the hardware's pace.
It requires a non-sleeping controller manager, e.g. the one from ros-controls/ros2_control#3213.
Basically, this tries to solve the issue that the control loop on the ROS machine and the one on the robot can have a phase shift and might be slightly different. To illustrate things, I added a simple controller that moves a joint on a fixed sine wave pattern with fixed sampling times in between. This is for illustration purposes and will not get merged.
With a non-blocking read with a controller_manager running at a fixed 500Hz we can observe that every couple of minutes, the two loops (controller_manager and robot) come to a point, where it can happen that the robot didn't receive a new command since the last control cycle.
I've used a preempt-rt patched kernel for that test. The upper curve shows the total amount of control cycles without a new command coming in to the robot. For the test I used a position interface.
We can see that control runs quite stable up to a point where the two loops get "out of sync". There, the robot doesn't get a new package for the next control loop. In our case we do linear extrapolation in that case. In the next cycle, we get a new command correcting this extrapolation. This is especially visible on the acceleration domain. After a while, this stabilizes again only to reoccur a few minutes later.
With the controller manager not sleeping and the hardware interface doing a blocking read, the same plot looks exactly like the left half of the plot above, but for a very long time (tested for ~1h). The number of missed packages stays at 0 given a direct network connection without any disturbances.