Are there any standards regarding single vs multiple MCU in a robotic system? More specifically, if a single MCU can handle all of the sensor data and actuator controls, is it better to use a single MCU or multiple MCUs in a hierarchical manner? Are there any references/papers regarding this topic? What are the arguments towards one or the other? I am looking for facts, not personal opinions, so pros, cons, standards and such.
1 Answer
Although you have asked for facts and not opinions, that's a difficult thing to do. As of now, there are no current standards for much of anything in robotics. The field as a whole is so scattered with many avenues of research. In the end, it all comes down to what makes the most sense for the robot being designed. With that said, I do recall some information regarding this subject in this robotics handbook: https://www.cs.cmu.edu/~mmv/planning/readings/handbook.pdf but I'm unaware of any specific papers on this topic - most focus on some specific aspect of robotics or AI, and the controller architecture is just a means to that end.
Single Controller Architecture
For small applications or one-offs, this is a perfectly viable choice. If you know that a single MCU can handle all of the data input and actuator output, then there is nothing wrong with just using one MCU.
Pros
- Fewer Components
- Fewer (or none) board-board connections
- Lower Cost
- Less Power Use (potentially)
- Less Firmware to maintain/update
Cons
- Not easily expandable (limited I/O / space for code)
- All components are coupled - removing 1 thing might break other things
- Not modular - must redesign/reprogram similar systems in the future
- No redundancy - MCU failure is catastrophic
- No Fail-safe - Any blocking code stalls all systems
Multi-Controller Architecture
For larger, complex systems or those which will likely be expanded upon or used for research purposes, a multi-controller architecture is the better option. It should also be noted that robot controllers are not only MCUs, but are commonly controller using microprocessors (MPU) as well, as they are capable of processing more data at higher speeds.
Pros
- Modularity - simple systems can be reused (motor drivers, sensor interfaces)
- Easy to swap to different sensors using documented interfaces
- Decoupled components - Switching to a different sensor or motor does not affect other systems
- Multiple controllers could be less expensive than one powerful one
- Timing - different systems can run at different clock speeds
- Simple firmware - specific code is less cluttered
- Well known and easy to implement serial interfaces (SPI, I2C, USB, etc)
- Able to split control into layers of abstraction
Cons
- More components to manage
- More power usage
- Complicated hardware infrastructure
- More cables to run
Wrapping Up
It's obvious that the pros of one architecture are the cons of the other, and vice versa. This is to be expected. For complex robotic systems, it is common (not necessarily standard, but typical) to break the problem down into smaller chunks - using small MCU circuits that do very specific things. These can then be grouped together, whatever makes sense to you.
For example, there could be one central controller for all motor drivers or distance sensors. Similarly, all of the drivers for one section of a robot could be grouped together, such as a single arm in a humanoid robot. All of these mid-level-controllers are then commanded by a single high-level controller which decides when and why to do things, but doesn't really care how it gets done.
On the other hand, for a simple robot using a vary unique structure that is unlikely to be reused, a single central controller is often used.
-
$\begingroup$ I hoped that someone will appear with a paper that does a thorough comparative analysis but you argumented everything quite well. Thanks $\endgroup$ Oct 19, 2015 at 1:30
-
$\begingroup$ Thank you. I agree, a paper would be best, but I don't think it's really a valid avenue of research since there is no best way to do this. Like I said, the answer really depends on the application. $\endgroup$ Oct 19, 2015 at 13:05