In the previous chapter we saw that ARCHO is built from three hardware layers: the Jetson, the Raspberry Pi, and a microcontroller. But how do these layers actually connect to each other and to the motor drivers? USB and WiFi aren't well suited for this job — neither in terms of resistance to industrial electrical noise, nor in terms of timing reliability.
Controller Area Network — a rugged industrial network used in automotive and robotics applications for communication between controllers.
| Feature | Meaning |
|---|---|
| Differential Signaling | Sending the signal over two wires with opposite polarity, which creates high resistance to electrical noise |
| Arbitration | Every message has a priority; if two devices send at the same time, the more important message wins |
| Error detection | Transmission errors are detected quickly and the message is resent |
A CAN message (Frame) is usually made up of three parts:
| Part | Meaning |
|---|---|
| CAN ID | The message identifier, which determines both the message type and its priority |
| DLC (Data Length Code) | The number of data bytes in this message |
| Data Bytes | The actual payload of the message |
# Sample CAN message for a motor velocity command
ID: 0x201
Data:
[Velocity Low]
[Velocity High]
[Current Low]
[Current High]
...Remember in Chapter 8 we saw that diff_drive_controller sends commands through controller_manager? On real hardware, this chain has one more layer:
The Hardware Interface (which we briefly saw in Chapter 8) has two main conceptual functions on real hardware:
| Function | Responsibility |
|---|---|
read() | Reads Encoder, Velocity, Current, and Fault data from the motor driver |
write() | Sends Velocity Command, Torque Command, Enable, and Brake to the motor driver |
| Error | Consequence |
|---|---|
| Incorrect termination | Signal reflection and communication errors |
| Mismatched baud rate between devices | No device can understand other devices' messages |
| Improper grounding | Excessive noise and random errors |
| Duplicate ID | Message collisions and unpredictable behavior |
| High bus load | Delays in the delivery of critical messages |
| Long or unsuitable cabling | Signal degradation and bit errors |
| Missing heartbeat | The system fails to notice when a device disconnects |
| Unmanaged Bus-Off | The entire network goes down after repeated errors |
CAN is sufficient for most mobile robots like ARCHO. But if ARCHO had a multi-axis industrial arm that needed very precise timing coordination, EtherCAT would typically be used instead.
| Well suited for |
|---|
| Servo Drives |
| Multi-axis robotic arms |
| Simultaneous coordination of multiple axes |
| Precise control with very low cycle time |
In ROS 2:
One of EtherCAT's key features is that it can synchronize the internal clocks of all drives together — every axis follows a common, synchronized clock. This is essential for motions where several axes must move precisely and simultaneously in coordination (such as a multi-axis welding arm).
| CAN Bus | EtherCAT | |
|---|---|---|
| Speed and timing precision | Suitable for most mobile robots | Much higher timing precision |
| Complexity | Simpler and cheaper | More complex and more expensive |
| Common use case | Wheel motors, sensors, BMS | Industrial servo drives, multi-axis arms |
| Example in ARCHO | Differential-drive wheels, Battery BMS | Multi-axis coordinated pick arm |
Now you know that behind every motion command that Nav2 or MoveIt issues for ARCHO, a real industrial network — CAN Bus for the wheels and sensors, or EtherCAT for a multi-axis arm — delivers that command reliably and on time to the motor drivers.
ARCHO Project now uses CAN Bus to connect the wheel drivers and Battery BMS to the Jetson, with a complete Hardware Interface that implements read() and write() over SocketCAN.
In Chapter 18 we bring all of these layers together and see how we move from a simulated ARCHO in Gazebo to a real ARCHO running on hardware.