Proposal to Use Real-Time Methods for Data Reading and Writing to Ensure Real-Time Safety

[maxwelllls]

The current project may not fully utilize ROS's real-time safety mechanisms for data reading and writing. In robot control scenarios requiring high real-time performance, non-real-time data operations can lead to system latency and unpredictability.
Proposed Solution
Use RealtimePublisher for Writing Data:
Utilize realtime_tools::RealtimePublisher for publishing data during the hardware interface's write operations
This ensures that message publishing within the real-time loop does not block the real-time thread
Use RealtimeBuffer for Reading Data:
For subscribed topic data, use realtime_tools::RealtimeBuffer to safely transfer data between real-time and non-real-time threads
This prevents data races and ensures data consistency
Expected Benefits
Improved system real-time performance and determinism
Reduced latency and jitter caused by non-real-time operations
Enhanced system safety and reliability
Consistency with real-time safety practices in other components of the ROS control framework

[christophfroehlich]

We discussed this briefly when we added this package. But as this package is using ROS topics for communication, there is no realtime guarantee at all, so why complicating the code in this package here? Things might be different if we would support running all inside a composable node, but this is not the case (yet).

[MarqRazz]

Read and write are atomic functions that are called within the controller_managers realtime loop so you wouldn't really gain anything using the realtime_tools because they are already exclusive when called. The goal is to get in and out as fast as possible to give the remaining time to other hardware/controllers that are also running in the same loop.

[maxwelllls]

I generally agree with MarqRazz’s point that read() and write() are already called atomically inside the controller_manager’s real-time loop, and that the primary goal is to keep these functions as short and deterministic as possible.

My intention with mentioning realtime_tools::RealtimePublisher is not to “add real-time guarantees” to ROS topic communication itself, but to avoid introducing additional sources of non-determinism inside the real-time thread. In particular:

A standard ROS publisher may trigger dynamic memory allocation, locking, or backpressure when the outgoing queue is full

Even if these effects are rare, they can still introduce jitter and cause the hardware interface’s read/write cycle to overrun its expected period

RealtimePublisher ensures that publish attempts inside the real-time loop are strictly non-blocking and fail fast if data cannot be handed off, allowing the real-time loop to always complete within its cycle

So from my perspective, the benefit is not mutual exclusion (which is already handled), but bounding the worst-case execution time of the real-time loop and preventing accidental blocking behavior from creeping in as the code evolves.

I fully agree that ROS topics themselves are not real-time safe, but using real-time–safe primitives at the hardware interface boundary can still help keep the real-time process predictable and robust, especially in high-frequency control scenarios.

We are currently working on similar real-time–critical integrations on our side, and if this direction is considered acceptable, I’d be happy to contribute PRs to help improve this incrementally.

[christophfroehlich]

I don't see a real downside in using the RealtimePublisher.

An alternative option would be to run this hardware component in async mode: Then the non-realtime publisher will not harm the realtime loop of other controllers/components.

[MarqRazz]

I don't see a downside either but it all really boils down to where spin is called and we are using a MultiThreadedExecutor in the controller manager. I can see the RealtimePublisher does all of this in it's own thread but so does the MultiThreadedExecutor. Are we saying that the controller manager is also relying on the MultiThreadedExecutor spin in its realtime loop and we don't want to overload it?