The site is read-only. Please transition to use Robotics Stack Exchange
| 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 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.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
