[CAN 01] - What Is CAN?
An introduction to CAN bus and its role in robotic hardware
Introduction
This is the first note in the CAN Bus for Robotic Hardware series. The series moves from the CAN data link and physical layers to Linux SocketCAN, embedded communication, actuator control, PCAN drivers, ROS 2 Control integration, and practical debugging.
What Is Controller Area Network (CAN)?
Controller Area Network (CAN) is a multi-master, message-based communication protocol developed for reliable communication in electrically noisy environments. Multiple nodes—such as sensors, motor controllers, and embedded computers—share the same bus. Access is coordinated by non-destructive bitwise arbitration, so a lower numerical CAN identifier has higher priority.
A complete CAN node normally contains three distinct pieces:
- a host processor or microcontroller that produces and consumes application data,
- a CAN controller that formats frames, performs arbitration, and checks protocol errors,
- a CAN transceiver that converts logic-level TX/RX signals to the differential CAN-H/CAN-L physical layer.
The achievable cable length depends strongly on bit rate, transceiver characteristics, topology, termination, and signal integrity. Higher bit rates leave less time for propagation delay, so long buses generally operate more slowly.
How Is CAN Used in Robotics?
Robots often use CAN between a central control computer and distributed actuator or sensor modules. A typical actuator module contains a microcontroller, a CAN controller, a transceiver, a gate driver, and a three-phase inverter. The microcontroller closes the fast current-control loop locally—often using field-oriented control (FOC)—while the host sends commands and receives state estimates over CAN.
This separation matters. The PWM and current-control loops should not depend on host traffic arriving over the bus at every switching cycle. CAN is better used for joint-level commands, feedback, configuration, diagnostics, and synchronization at a rate that the complete network can sustain.
CAN can support a joint-level impedance loop when the command and feedback rates, latency, and jitter remain within the controller’s design budget. The actuator still closes its faster current loop locally, while the host may update desired position, velocity, feed-forward torque, stiffness, and damping:
\[\tau_\text{cmd} = \tau_\text{ff} + K(q_d-q) + D(\dot{q}_d-\dot{q})\]Legged robots are a useful example because they combine many actuators, frequent contact changes, and tight latency requirements. Architectures such as the MIT Mini Cheetah distribute the actuators across multiple communication channels instead of placing every motor on one heavily loaded bus.
Classic CAN Frame Size
The 11-bit field in a Classic CAN base frame is the identifier, not the payload. A Classic CAN data frame uses either an 11-bit base identifier or a 29-bit extended identifier, and carries from 0 to 8 data bytes. CAN FD increases the payload limit to 64 bytes and may use a faster data phase, but that is a different frame format.
For an 11-bit Classic CAN data frame with an 8-byte payload, the nominal transmission cost is:
| Field | Bit times |
|---|---|
| Start of frame | 1 |
| Arbitration field: 11-bit identifier + RTR | 12 |
| Control field: IDE + reserved bit + DLC | 6 |
| Data field | 64 |
| CRC sequence + CRC delimiter | 16 |
| ACK field | 2 |
| End of frame | 7 |
| Minimum intermission | 3 |
| Total before bit stuffing | 111 |
This total already includes the identifier, arbitration-related fields, control field, CRC, ACK, end of frame, and the minimum inter-frame separation. Dynamic bit stuffing applies from the start of frame through the CRC sequence, so the actual number of transmitted bits depends on the identifier and payload. Arbitration contention increases the response time of lower-priority frames; error frames, retransmissions, diagnostics, and traffic from other nodes add further bus load.
Estimating the Bus Load
Suppose one actuator receives one 8-byte command frame and returns one 8-byte feedback frame at 1 kHz. Before bit stuffing:
\[2\ \text{frames/cycle} \times 1000\ \text{cycles/s} \times 111\ \text{bit-times/frame} = 222{,}000\ \text{bit/s}\]At 1 Mbit/s, that is a minimum nominal load of 22.2% per actuator, not 22,000 bit/s. Three actuators already reach 66.6% before bit stuffing and all other traffic; four reach 88.8% before those costs. The practical limit is therefore not a universal number of motors. It depends on payload length, identifier format, traffic pattern, priorities, error margin, and the latency required by the controller.
Reducing the update rate reduces bus load, but its control effect depends on the system. It may reduce closed-loop bandwidth or robustness; it does not automatically make a robot unstable. Other options include packing multiple signals into one frame, broadcasting shared commands, reducing payload size, staggering transmissions, using multiple CAN channels, or moving to CAN FD or a higher-bandwidth fieldbus.
For a real-time robot, average bus utilization is only the first check. The final design should also consider worst-case arbitration delay, response time, stale feedback, and behavior during errors or retransmission.