ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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 RobotHW
s), 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.