Robotics: CAN Bus

Understanding Robotics: CAN Bus

A CAN message is sent as a frame. The frame contains an identifier, a small amount of data, error checking information, and an acknowledgement field. The identifier describes what the data means, such as wheel speed, battery current, arm position, or a command to a motor controller.

It does not name one receiving device. Each node is configured to accept the identifiers it needs and ignore the rest.

This publisher style is useful in robots because one sensor reading can be used by several controllers at once. A gyro can publish angular rate while the drive controller, balancing controller, and data logger each use that same message.

Arbitration works at the level of individual bits. When several nodes begin transmitting together, every transmitter watches the bus while it sends. A node that sends a recessive bit but sees a dominant bit knows that a higher priority frame is present.

It immediately stops and waits. The winning frame continues without being corrupted, while the other nodes retry later. This is different from a network where two simultaneous transmissions create a damaged packet that must be discarded.

Priority therefore needs careful planning. Safety-related commands should receive high priority, but giving every message high priority defeats the purpose.

Fast control data needs frequent updates. Temperature or diagnostic data can usually wait longer.

Reliability comes from more than the cable itself. CAN hardware checks each frame using several methods, including a cyclic redundancy check, bit monitoring, format checks, and acknowledgement. A receiver that detects a bad frame sends an error signal.

The frame is then retransmitted automatically. Nodes count their own transmission and reception errors. A node with too many errors can remove itself from normal traffic, a state called bus off.

This prevents one damaged device from continuously blocking communication for the rest of the robot. Good robot software should detect missing messages and bus-off events. It should move motors to a safe state when important feedback stops arriving.

Physical layout causes many real CAN problems. The main cable should form one continuous backbone, with short branches leading to devices. Long branches act like extra transmission lines and can distort fast signals.

Connectors must be secure, twisted pairs should stay together, and the network must share a sensible electrical reference where the hardware requires one. A multimeter check across the disconnected bus can reveal whether the expected total termination resistance is present.

An oscilloscope can show reflections, noise, or rounded edges that a multimeter cannot reveal. Students should learn to separate wiring faults from software faults by checking power, connector pinouts, resistance, message traffic, and error counters in a steady order.

Bus speed sets a tradeoff between distance and timing margin. Faster traffic allows more messages each second, but it makes cable length, branch length, and clock accuracy more critical. Every node must use compatible timing settings or it will interpret bits at the wrong instant.

Standard CAN frames carry limited data, so designers often send compact numbers rather than long text. For example, a controller may send an integer representing a measured speed in thousandths of a unit. The receiving program must know the scale, units, update rate, valid range, and timeout.

Clear message definitions matter as much as correct wiring. A network can electrically work perfectly while the robot behaves incorrectly because two modules disagree about what a number represents.