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.
