# What is the purpose of RobotHW?

I am currently working on a robot with several subsystems. For simplicity, let's say it has a robotic arm and a drive system. These things need to be modular, so if we removed the arm (for example), the robot can still drive. If we're testing the arm, we'd like not to send drive commands.

We have written a separate library for interacting with our electronics. In particular, we have a single chip for getting and setting PWM / GPIO signals.

I'm trying to integrate this robot with the ros_control framework, and I'm somewhat in a dilemma as to how to divide up responsibility such that we have modular software. My main confusion stems from the fact that I am not sure how RobotHW is supposed to be used. To be honest, I'm still partially confused about what controller_managers are for, too, and that could be feeding into my confusion as well, since we do have the built-in ROS controllers controlling both the arm and drive.

Which pattern is preferred?

• Have a single RobotHW class, called "MyRobotHW"
• Have a single controller manager associated with MyRobotHW,
• read() and write() directly interact with our PWM libraries.

OR

• Have a RobotHW class for each subsystem, i.e., "ArmHW" and "DriveHW"
• Each class interacts with the same PWM library
• Each class gets its own controller manager
• Each class runs in its own node, so we'd need to make the PWM library thread safe

OR

• Same as above, but have a single controller manager, and just have a single node in which we call read() and write() for each HW class (in sequence), so that we don't need to worry about thread safety.

OR

something else entirely?

Is this really just a design choice? Or am I misunderstanding the design of ros_control? I've read the documentation several times but I am still confused. I would greatly benefit from the help of someone who's successfully used ros_control in practice.

edit retag close merge delete

Sort by » oldest newest most voted

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.

more