Proposal: Modular Reference Handling in ROS 2 Controllers

[my-rice]

Hi, we are writing this issue as part of the Automatic Control Group from the University of Salerno. We have previously contributed to the ROS ecosystem, for example, through pull requests such as here and here, as well as by deploying ROS 2 packages to the community like here.

---

We are opening this issue to propose a new design approach for the control framework, specifically aimed at improving how controllers handle reference inputs.

Is your feature request related to a problem? Please describe.
After reviewing the current implementations, we observed that a significant portion of controller code is dedicated to managing reference acquisition, typically via subscribers or action servers. For example, here and here.

Describe the solution you'd like
To improve modularity and separation of concerns, we propose a cleaner structure that decouples reference acquisition from control logic. The idea is to divide responsibilities into two distinct modules:

1. Reference Generator – This component is practically a controller, but its purpose is to receive and validate reference trajectories or setpoints from the ROS 2 network. It abstracts the communication interface and provides a clean output to downstream controllers, using controller chaining.

2. Controller – This component is exclusively responsible for computing the control law. It receives input from the Reference Generator and remains agnostic to how references are produced or delivered.

This modular structure promotes better organization and a clearer separation of responsibilities. Moreover, Reference Generators increase code reuse across multiple controllers. The diagram below illustrates the proposed architecture:

Importantly, this proposal does not require any modifications to existing controllers. The framework is fully backward-compatible, allowing existing controllers to continue functioning without changes. Developers creating new controllers may adopt this structure if it aligns with their needs.

Describe alternatives you've considered
The most straightforward alternative is to maintain the current design, leaving users responsible for implementing their own reference-handling logic, even when this functionality could be modularized and reused across controllers.

Additional context
We have already internally implemented a prototype of this modular framework and developed demo controllers to demonstrate its benefits. We are happy to make the repository public on request.

We are sharing this issue now to gather feedbacks and assess whether this direction aligns with the needs and preferences of the community. We are happy to discuss, refine, or adjust the approach based on your input.

[christophfroehlich]

Thanks for publishing your proposal.

For some controllers this makes sense, for example all mobile platform controllers having a twist input. This is exactly what I proposed here to avoid duplicating the twist limiter etc.

For other controllers the situation is different, at least if action interfaces enter the scene it gets complicated. I wished that something like this was possible with JTC, but ended up in proposing custom controller plugins because advanced control strategies need the full trajectory, even maybe before executing the trajectory, instead of only the current reference point in your proposal.

[eferre89]

@christophfroehlich, so, if I get your point, we essentially have two possibilities:

• define a "ROS-communication interface controller", like the reference generator @my-rice is proposing, or
• sort of reusing the JTC (essentially its interpolation capabilities) with configurable control logic (through a plugin)

... or both, I see them as two complementary approaches. Perhaps there are cases where you want to use some more evoluted control logic without dealing with a trajectory (e.g. impedance control receiving online references from a teleoperator).

[destogl]

Hi @eferre89,

very interesting proposal! The main questions after imagining this is, do we actually require here controller chaining, or just a library with the handling methods that can be resuable, e.g., put in control_toolbox might solve the issue sufficiently, without adding a complexity?

[eferre89]

Dear @destogl,

thank you for your feedback! Indeed, what you are proposing sounds like a third way to us, that is embedding the communication interfaces (action server/subscriber on specific messages) within external libraries, if I caught your point. But I'd like to go to the very origin of our proposal: I guess there is some need, in ros-controls, to deal with

• task-space control (not just performing IK, but I mean defining a task-error-based controller, like task-space inverse dynamics control, for instance).
• interaction control (compliance control, impedance control, admittance control, direct force control, hybrid force/position control; the latter -might- require the definition of a reference wrench)

Clearly, if a planning system was able to generate plans for such controllers, it would likely use different messages, that would not comply with the JointTrajectory we are mostly using in these days in ros-controls. This would call for specialized controllers (the reference generators @my-rice was proposing) or specialized libraries to configure the JTC with (perhaps, JointTrajectoryController shall become TrajectoryController in this case, to accommodate the use cases above).

On the other hand, what is nice about JTC (that I really consider a masterpiece controller) is that it already implements both the PointReference and TrajectoryReference interfaces @my-rice was pointing out in his design through the usage of the same message, i.e. the JointTrajectory, and, at the same time, can be chained with arbitrary -joint space- controllers. For instance, we have been validating JTC with both ros-control's PidController and a GravityCompensationPDController we developed. Both configurations worked nicely.

Therefore, to sum up, in the next future, I would

• keep the JTC as it is, with its ability to chain other controllers and manage both single-point and trajectory references
• place other "controllers" next to it to manage different messages and enable the use cases I mentioned before (these would be the reference generators @my-rice was proposing)

More on the long run, I'd try to

• assess whether controller-level configurability (through either plugin or toolbox library), i.e. same "ROS-communication interface controller" with different configuration to cope with different messages, would be preferable over controller-manager-level configurability, i.e. one controller per message type. I guess this really gets down to the point of whether different messages shall undergo the same logic within the controller. I have ideas about this, but not a definitive answer and deeper analysis would be needed.

For the time being, we have code implementing what @my-rice proposed:

• A joint space reference generator able to accept "extended" joint space references (see Feature/joint wrench msgs control_msgs#221)
• A task space reference generator able to accept task space messages (either trajectories or single points)
• The common logic is included in a superclass the two controllers inherit from, while message-specific processing and input/output mapping (through semantic components) is managed in the derived classes