Chainable controllers

[Richard-Haes-Ellis]

I am often frustrated by the current limitations in ROS 2 Control when it comes to chaining controllers. Specifically, the inability to directly connect higher-level controllers, such as custom Linear Quadratic Regulators (LQR) or Model Predictive Controllers (MPC), with lower-level controllers (like position, velocity, or effort controllers) restricts the flexibility and sophistication of control strategies in complex robotic systems. This limitation makes it challenging to implement advanced control strategies where higher-level controllers need to dictate the references or setpoints for lower-level controllers in real-time.

I propose adding support for chaining controllers within the ROS 2 Control framework. The ability to configure higher-level custom controllers (such as LQR, MPC) to directly control the references or setpoints of lower-level controllers (such as position, velocity, and effort controllers) would significantly enhance the framework's capabilities. This feature would make ROS 2 Control more powerful and versatile, comparable to advanced systems like Simulink.

Here’s what I envision:

• Controller Composition: Enable configuration of higher-level controllers to send commands or setpoints to lower-level controllers through a well-defined interface or communication channel.

• Chainable Controllers: Enhance the existing ControllerInterface class to support chaining, allowing for integration of existing controllers in a hierarchical manner.

Alternatives:

While there have been some attempts to demonstrate controller chaining (e.g., chaining_demo), these are not yet integrated into the mainline ROS 2 Control framework. Documentation on controller chaining (controller chaining) provides some insights but lacks practical implementation.

Currently, advanced control algorithms (AFAIK) must be implemented in separate nodes that subscribe to and publish controller inputs and outputs. This approach compromises real-time performance and creates complexity, making the system less clean and manageable. Integrating chaining directly into the ROS 2 Control framework would offer a more streamlined and real-time-capable solution.

Additional context

Integrating controller chaining within ROS 2 Control would align with the broader goal of enhancing ROS 2's capabilities for advanced robotics applications. It would facilitate more sophisticated control strategies and increase ROS 2 Control’s competitiveness with other advanced control frameworks.

[Richard-Haes-Ellis]

It seems that there is implementation of this feature in the ControllerInterface class but not sure how it's used in the controllers.
https://github.com/ros-controls/ros2_control/blob/master/controller_interface/src/controller_interface.cpp

There has been little development on it's implementation on diff_drive: ros-controls/ros2_controllers@dea3d3c#diff-f8d3a930a6782d85b295ef6bce89dc2a757ae540cc80128e8044aee6ddee5df9

Seems to be a bit complicated sice it's implemented on another class. Wondering if its possble to have it on the ControllerInterface class and have those methods available.. Would seem much simpler..

[christophfroehlich]

Fyi there is a chaining demo in our examples repository.

I'm not sure why your LQR or MPC cannot directly claim the interfaces. If it is just a naming issue (like the MPC has controller_output which you want to connect to joint1/velocity), then #1667 will help you.

[Richard-Haes-Ellis]

I'm aware of that demo, but the problem I see is that current controllers such as the position, velocity or effort controllers aren't afaik, chainable. So I can't claim the reference interfaces in my lqr controller. Instead the option I see is to publish to the command topics from those existing controllers. I would like to avoid re-writing lower level controllers if they are already available and proven to work.

[christophfroehlich]

I'm aware of that demo, but the problem I see is that current controllers such as the position, velocity or effort controllers aren't afaik, chainable.

That's true but could be extended if someone puts time in it.

So I can't claim the reference interfaces in my lqr controller. Instead the option I see is to publish to the command topics from those existing controllers. I would like to avoid re-writing lower level controllers if they are already available and proven to work.

Why you can't claim directly the interfaces from your hardware, if you just want to pass them trough? (that is what the mentioned controllers are doing).

[Richard-Haes-Ellis]

Im referring to the reference interfaces (which are non existent since the controller's aren't chainable) of existing controllers not the hardware interfaces themselves.

Also wanted to note the closing remarks in this document regarding design of chainable controllers: https://control.ros.org/master/doc/ros2_control/controller_manager/doc/controller_chaining.html

I would think it would be logical to have the methods implemented in the ControllerInterface instead of another class, it would seem like it would make development of chainable controllers much easier.

[christophfroehlich]

Im referring to the reference interfaces (which are non existent since the controller's aren't chainable) of existing controllers not the hardware interfaces themselves.

Thats true for the mentioned ros2_controllers. But to understand your problem, please tell us why your high-level controller can't claim the interfaces of the hardware directly.

[Richard-Haes-Ellis]

I don't have issues with it, just found it hard to find information on the current state of development on chaining controllers.

I would love to be part of the discussion on this particular feature if possible and perhaps contribute wherever I can. Shall I keep this issue open or close it?

[christophfroehlich]

I always support folks updating and improving the docs and demos, like ros-controls/ros2_control_demos#568.
If you have clear questions which are not answered in the docs, formulate them, and someone will be able to answer hopefully.
About the chosen design decisions @saikishor can explain a bit.
Then I'd be grateful if you revise the current docs and update them to be clear for a non-maintainer perspective.

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.