Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

All alternatives you describe are valid. The first two patterns are already supported, and your usecase should determine which works best. For instance, if you're interested in having a controller that can talk to more than one subsystem, then the second choice is out of the question.

I personally tend to favor one controller manager per robot. Without additional knowledge on your system, a variation of the third alternative is the one I'd aim at: A RobotHW that aggregates the resources of all the subsystems (individual RobotHWs), and pass this aggregated RobotHW to the controller_manager constructor.

Note that currently this aggregation has to be done manually, which I admit is somewhat inconvenient. Exposing convenience tools for composing RobotHW instances is on the TODO list of the ros_control project. It is mentioned towards the end of the ROSCON 2014 presentation, as part of the future work, and has already been discussed on the project's issue tracker.