Revision history [back]

Hi Brice,

You've described two extremes of designing ROS systems: break it into tiny pieces with many communication channels, or pack everything into one monolithic process. I can't give you the right answer; it depends on your specific needs and without experimenting there are too many unanswered questions. However, I will try to give some suggestions for designing the system you've described.

You asked how quickly ROS can run. I have seen ROS pass messages reliably at 1kHz, however, as the system load increases and the connection quality drops, ROS will start to drop messages. I would suggest combining the PID controller, the encoder reader, and the voltage writer into a single process. A PID controller can be sensitive to running at an inconsistent frequency, and there isn't a straightforward solution to dealing with dropped messages.

The design does get trickier when you are controlling a full arm. If you are writing an aggressive controller that is very sensitive to perturbations in timing, then you should keep it in a single process. Dropped messages will cause intermittent problems with your controller, and it will be difficult to determine if the issue is dropped messages or a bug in your controller.

If your full arm controller is "simpler", then you can put it in a separate node. Communicating over ROS will give you a few benefits. The commands from the controller are easier to view or plot in realtime. It's easier to change to a different full arm controller without taking down the PID controllers running the motors. If your controller crashes, then it will only take down its own process. By communicating over ROS you gain introspection, flexibility, and better error diagnostics.

For your full arm control and inverse kinematics, I would suggest first separating the components into separate nodes, and then combining them into a single process if there are any issues.

Best of luck with your system