Use blocking read in controller manager (backport #1760)

[mergify]

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.

---

Note

Medium Risk
Changes real-time control-loop synchronization defaults and depends on ros2_control hardware synchronization support; misconfiguration between launch and URDF defaults could affect timing in custom setups.

Overview
Adds a blocking_read launch/configuration path so the ROS control loop can wait on incoming robot state instead of running on a fixed timer, reducing phase drift between the driver and the robot controller.

ur_control.launch.py defaults blocking_read to true and passes hardware_synchronization.expect_blocking_read_write to ros2_control_node. ur_rsp.launch.py and ur.urdf.xacro expose the same flag (URDF/xacro default false for multi-robot setups) and map it to hardware non_blocking_read.

Docs cover the new startup argument, a blocking read usage section, and Makoa migration notes (launch defaults vs URDF default).

^{Reviewed by Cursor Bugbot for commit eee3cd4. Bugbot is set up for automated code reviews on this repo. Configure here.}

---

This is an automatic backport of pull request #1760 done by [Mergify](https://mergify.com).

---

Note

Medium Risk
Changes real-time control-loop synchronization and depends on matching ros2_control hardware synchronization with UR hardware read() behavior; launch default false vs docs calling blocking the recommended startup default may confuse custom launch chains that omit blocking_read on the description side.

Overview
Introduces a blocking_read launch/xacro flag so the driver can block in read() on fresh robot state and let the robot controller pace the ROS control loop, instead of relying on a fixed timer that can drift out of phase with the robot.

ur_control.launch.py passes hardware_synchronization.expect_blocking_read_write and overruns.print_warnings (inverted when blocking is enabled) into ros2_control_node, and declares blocking_read (default false in this backport). ur_rsp.launch.py forwards the same argument into the robot description; ur.urdf.xacro maps it to hardware non_blocking_read via ${not blocking_read}.

startup.rst documents the new startup argument and a Blocking read section explaining when to enable it (single-robot setups vs unreliable comms).

^{Reviewed by Cursor Bugbot for commit affee10. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mergify]

Cherry-pick of c747f3e has failed:

On branch mergify/bp/lyrical/pr-1760
Your branch is up to date with 'origin/lyrical'.

You are currently cherry-picking commit c747f3e.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   ur_robot_driver/doc/usage/startup.rst
	modified:   ur_robot_driver/launch/ur_control.launch.py
	modified:   ur_robot_driver/launch/ur_rsp.launch.py
	modified:   ur_robot_driver/urdf/ur.urdf.xacro

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	deleted by us:   ur_robot_driver/doc/migration/makoa.rst

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4d5763d. Configure here.}

[urfeex]

Waiting for ros2_control getting released with the required change, therefore blocked until then.