Skip to content

PoC: Blocking read implementation#1760

Draft
urfeex wants to merge 5 commits intoUniversalRobots:mainfrom
urfeex:blocking_read_implementation
Draft

PoC: Blocking read implementation#1760
urfeex wants to merge 5 commits intoUniversalRobots:mainfrom
urfeex:blocking_read_implementation

Conversation

@urfeex
Copy link
Copy Markdown
Member

@urfeex urfeex commented Apr 13, 2026

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.

preempt_rt_non_blocking_read_fixed_dt

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.

@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 13, 2026

Codecov Report

❌ Patch coverage is 0% with 52 lines in your changes missing coverage. Please review.
✅ Project coverage is 4.92%. Comparing base (1b121b7) to head (4468554).
⚠️ Report is 568 commits behind head on main.

Files with missing lines Patch % Lines
ur_controllers/src/sine_controller.cpp 0.00% 52 Missing ⚠️
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     
Flag Coverage Δ
unittests 4.92% <0.00%> (+1.33%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@gavanderhoorn
Copy link
Copy Markdown
Contributor

🎉 no more set-rate-to-slightly-higher-than-500hz-just-so-we-don't-miss-any-updates

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants