Robot Baseline Blueprints, software and hardware baselines for robot builders 中文

Home/Hardware

B grade Authoritative secondary, traced to origin

CAN bus: the threshold between hobby servos and brushless joints

The moment joints move from servos to integrated brushless motors, communication almost always lands on CAN. Wiring is not the hard part — the hard part is that several conditions must hold at once, and when one fails they do not raise an error together. They go quiet together.

Physical layer
Differential twisted pair, two signal wires plus a common ground
Termination
120 ohm at each end of the bus; miss one and packets drop sporadically
Bitrate
Classic CAN up to 1 Mbps; CAN FD higher, but both ends must support it
Controller requirement
A real CAN peripheral — not something a GPIO can emulate
Common setup
USB-CAN adapter to the host, or a multi-channel CAN FD adapter for several buses
The spec, and what it measures
The critical parameter is not the bitrate but termination and topology: 120 ohm at both ends, a common ground across every node, and short stubs. A missing terminator produces a symptom that is actively misleading — not "no communication" but intermittent communication and random packet loss, which looks like a software problem. On bitrate, CAN FD carries more data when both ends support it, but a single classic-CAN node on the bus drags the whole segment down to the lower rate.
Price tiers
Entry cost is low: one USB-CAN adapter gets you started, and integrated motors carry their own CAN transceivers. The real spending is on the host side — if your controller has no native CAN peripheral you need an add-on board or a different controller. Put "has a CAN controller" on the must-check list when choosing a controller; adding it later is worse.
How to pick
(1) Confirm the controller has a CAN peripheral — the easiest thing to discover too late. (2) Size the adapter to the number of buses: when several joints share a line, bandwidth and real-time behaviour have to be planned together, and one channel may not be enough. (3) Keep a multimeter handy: measure termination before powering up — the resistance across the two signal wires should read close to 60 ohm (two 120 ohm in parallel), and that minute saves a day. (4) Unify the bitrate: every node must match, and a mismatch again produces silence rather than an error.
Known pitfalls
(1) Missing termination — sporadic loss is the hardest class to diagnose because the symptom is not stable. (2) No common ground: differential signalling resists interference, but large potential differences between node references still break it. (3) Controllers without real CAN hardware: some boards can only bit-bang it, and timing collapses under load. (4) Mixing CAN FD with classic CAN: the segment drops to the lower rate and nothing reports it.
What we checked
We checked the two hard requirements of termination and topology, that the host side needs a real CAN peripheral rather than GPIO emulation, and the behaviour of mixing CAN FD with classic CAN. Not checked: we have not benchmarked specific adapters for packet loss or latency, so what is written here is the mechanism and the method rather than a verdict on any particular adapter.
This site's call

Treat it as a one-time threshold rather than an ongoing nuisance: termination, common ground, bitrate and a controller with real CAN hardware, all four right at once, and you will rarely touch it again. The controller item is the easiest to overlook and the only one wiring cannot rescue — settle it when you choose the board, not afterwards.

The one-minute check before powering up

  • Measure the resistance: powered down, across the two signal wires it should read near 60 ohm (two 120 ohm terminators in parallel). If it is far off, do not apply power yet.
  • Check the common ground: every node needs a shared reference, especially when supplies are separate.
  • Match the bitrate: nodes and adapter must agree; any mismatch means no communication at all, not slower communication.
  • Confirm the controller: a hardware CAN peripheral, not a software emulation.
The hardest failure class

Intermittent packet loss on CAN almost always points at the physical layer: termination, grounding, stubs that are too long. Do not start by loosening software timeouts and retries — that turns one definite problem into two uncertain ones.

Sources

  • CAN physical layer specifications (published standards on termination, topology and bitrate)
  • Wiring and debugging records in open robot projects and motor vendor documentation

Objects in this entry

Last checked 2026-09-28