Question Regarding ros2_control Design

General
, ,
1

Hello!

This post is specifically intended to critique software design. I have nothing but appreciation for the people who work on open source robotics. I’m also relatively new to the community, so it’s perfectly possible that I’m just misunderstanding something :slight_smile:

While trying to understand the architecture of the ros2_control package, I was wondering why it doesn’t use the node and message passing system already provided by ROS 2 and DDS. Basic usage gave me the impression that the control library was over-abstracting when the same level of modularity and interoperability could be achieved via defining both controllers and hardware as regular nodes.

For example, a specific PID controller would have subscribe to /measurement, /setpoint, and /voltage topics with user configured message types. On the receiving end, a piece of hardware would subscribe to /voltage and publish /temperature. This seems more straightforward and benefits from relying on ROS infrastructure for message passing, logging, etc.

This past thread had an inconclusive discussion on the topic.

The main feature a native ros controller implementation would not achieve is requiring controllers to own their hardware resources. However, I question the necessity of that, since it seems like a lot of work to circumvent a specific potential issue.

2 Likes
2

You already found the ROS Answers post where I’ve asked / suggested something similar. I still believe it would be a very interesting approach for the kinds of applications ros2_control (and it’s predecessor: ros_control) tries to make possible.

AFAIU and IIRC, non-determinism in (among other parts) the RMW layer and the executor(s) complicated going that way with the design. Perhaps using components could help mitigate some of that.

It’s possible though, as OROCOS implements the approach you describe (and it comes with ROS 2 integration so you could already use this to implement a control system while keeping ROS compatibility).

1 Like
3

Although the linked post is two years old, the arguments of @destogl are still valid IMHO.

Keep in mind that one focus of ros2_control was real-time safe control loops, and they can run without any ROS networking magic (e.g., the joint_trajectory_controller performing an action goal → there is no ROS node involved any more). This was successfully tested with control loops faster than 1kHz, where you will have problems with most of the DDS implementations if you don’t know exactly how to configure that (latency, jitter,…).
About the use case you are describing with temperature as a measured state: You won’t need fast control loops and you are perfectly fine with ROS nodes without ros2_control. Additionally, you don’t get any benefit with the simulator integrations, because you won’t simulate temperature in gazebo.

2 Likes
4

Hi @AngleSideAngle thanks for your question,

there are actually two parts in there, as I see, and I will answer to both of those separately.

1. Why ros2_control doesn’t uses nodes/components
There are mostly historic resons for it. We at Stogl Robotics (my company) have already testes splitting the ros2_contorl to separate nodes across the network running distributed control in real-time. The test was successful, but if you want to achieve hard real-time (jitter under 1% of control frequency), as expected in industrial applications, we need to extend this even further. In this extreme case, there is also a question, why use then ROS 2 and DDS and not EtherCAT or similar that already solves many real-time related issues.

Looking at the soft real-time approach (jitter up to 50% of control frequency), many ROS 2 users expect - our multi-node approach could be useable out of the box with some smaller polishing. Still, to make this nicely integrated into the current architecture (keeping everything working) is a project between 6 and 12 months for a FTE.

Also on the note of the components - I often encounter that those are not working on the robot as one would expect, so also some work to make this bulletproof.

2. Abstraction of ros2_control
Even is go with the node-based structure to ros2_control, I would argue to keep the same amount of abstraction as there is now. This is not uncommon in other ROS 2 libraries. The point is that one would have communication over topics, but basically the structure of them should be the same to have enough flexibility of exchanging controllers and HW interfaces.

Regarding ownership of HW resources, this is not a bug, but a feature. In the control system, you want to have deterministic behavior about who is talking when and what to the hardware. Now these all mechanisms are all done through internal functions and in the node case we have to give them access through services or actions.

To wrap-up, I am very open to exploring the design with nodes and components - the only requirement I have is that someone commits to work on this until it is done.

5 Likes
5

Hi @AngleSideAngle @destogl,

I came across the Topic Based Ros2 Control package by PickNik Robotics. It integrates ros2_control with topic-based communication. It might be relevant to the discussion on modularity and integration.

I’d be interested to hear your thoughts on how such an approach might fit into the goals of ros2_control, particularly regarding the balance between real-time performance and modular design.

Looking forward to your insights!

6

Hi @manojm,

The ROS 2 control is modular. What you have referenced is not topic-based ros2-control, but only hardware interface.

There is already one experimental application of it, but more with the goal of making the control system distributed across multiple computers. To do this right, it is a lot of effort, but not many use-cases. Therefore, I don’t expect anything in this direction anytime soon.

Using topics instead of shared memory for communication is achievable also in terms of the real-time, but as I said, I don’t see anyone willing to invest 1-2 years of work into it.

1 Like
7

This approach could indeed simplify modularity and interoperability while reducing the need for extra layers of abstraction.

The primary reason for ROS 2 control’s architecture, I think largely comes down to the real-time performance requirements. Using shared memory within a single process allows for low-latency, high-throughput communication between controllers and hardware. DDS-based topic communication, although real-time capable, can introduce more latency than direct memory access.
The current design enforces that a controller manages its hardware resources to avoid conflicts and ensure deterministic performance. However, in more distributed, non-time-critical systems, this strict ownership model might not be as necessary.

8

Which approach do you mean exactly? Can you also explain a bit more your perspective, on how you imagine this to work and why would be simpler?

Can you also please elaborate more, what do you mean by that?

9

I doubt ros2_control was developed for this. There are more than enough solutions for “distributed, non-time-critical systems”. If your application requires such systems, maybe consider something else that isn’t ros2_control.

You can consider integrating drivers for industrial networks such as CC-Link IE, SLMP, Modbus TCP, MQTT, etc… instead of re-inventing the wheel. If your application is for monitoring purposes with some amount of “pushing a button to turn on something”, OPC UA might even work for you. APIs/documentation for these networks are freely available on the internet.

1 Like