FRC CAN Bus Explained (and How to Fix Common Problems)

Almost every motor controller, your power distribution board, and most of your sensors talk to the roboRIO over a single pair of wires. That pair is the CAN bus, and when it works you forget it exists. When it breaks, your whole robot can go dark at once. The good news: CAN failures are extremely predictable, and almost all of them come down to four or five causes you can learn to spot in minutes. This guide explains what CAN is, how to wire it correctly, and exactly how to track down the most common problems with the same tools the pros use.

What CAN is and why FRC uses it

CAN stands for Controller Area Network. It's a communication standard originally built for cars, where dozens of electronic modules need to share one network reliably in a noisy electrical environment. FRC adopted it for the same reason: instead of running a separate control wire to every device, every device shares one bus.

The big advantage is data and wiring. A CAN connection is daisy-chained from device to device, which usually means much shorter wire runs, and it carries far more information than the old PWM signal wires could. According to WPILib's "Using CAN Devices" docs, CAN lets devices report rich telemetry back to the roboRIO, like motor temperature, current draw, and encoder position, all over the same two wires that carry commands out.

Devices that live on the CAN bus include CTRE Talon FX / Kraken motors, CANcoder and Pigeon 2.0 sensors, REV SPARK MAX and SPARK Flex controllers, and your Power Distribution Panel (PDP) or Power Distribution Hub (PDH).

The daisy-chain and 120-ohm termination

CAN on an FRC robot is wired as a daisy chain. Per the WPILib CAN Wiring Basics page, the wiring "should usually start at your roboRIO and go into and out of each device successively until finally ending at the PDP." There is no branching and no star topology. The signal flows in one continuous line from one end to the other.

CAN uses two signal wires, conventionally yellow for CAN-High and green for CAN-Low. Keeping the colors consistent across every device makes wiring mistakes obvious at a glance.

The most important and most misunderstood part is termination. A CAN bus needs a 120-ohm resistor at each end of the chain. These resistors absorb electrical reflections that would otherwise bounce back down the wire and corrupt your data. In FRC you usually don't add these yourself, because they're built into the devices at the two ends:

• The roboRIO has a 120-ohm terminating resistor built in. It sits at one end of the bus.
• The PDP ships with its termination jumper in the "ON" position. WPILib recommends leaving that jumper on and placing the PDP at the other end of the bus, so it provides the second terminator.

If you want the PDP somewhere in the middle of the chain instead, you must move its jumper to "OFF" and add your own 120-ohm resistor at the new end of the bus. CTRE's CAN Bus Troubleshooting guide puts it simply: there must be two 120-ohm resistors, one at each end.

The 60-ohm test

Here's a trick worth memorizing. Two 120-ohm resistors at opposite ends of the bus are electrically in parallel, and two equal resistors in parallel give half the value. So a correctly terminated, powered-off CAN bus measures about 60 ohms between CAN-High and CAN-Low. CTRE documents this directly: with the robot off, measuring CANH-to-CANL should read roughly 60 ohm. If your meter reads close to 120 ohm, only one terminator is in the circuit, meaning the other end (often the PDP) isn't connected through, or a hop in the daisy chain is broken. A multimeter and this one measurement will tell you more than an hour of guessing.

Device IDs and avoiding conflicts

Every device on a CAN bus is addressed by a device ID. The roboRIO doesn't care where a device physically sits in the chain; it finds devices by their ID. The rule is simple but strict: every device of the same type must have a unique ID on that bus.

The exact range depends on the vendor, but they overlap closely:

REV's documentation states plainly that "each device on the CAN bus must be assigned a unique CAN ID number" — give two SPARK MAX controllers the same ID and the roboRIO can no longer tell them apart. A common beginner trap: every new controller ships with ID 0, so the moment you put two fresh controllers on the bus, you have a conflict. Assign a unique ID to each device the first time you connect it. Many teams use a simple scheme, like numbering controllers 1-8 by mechanism, and write the ID on tape next to each one.

One nuance from the WPILib CAN addressing docs: the full CAN address also includes a device type and manufacturer field. That means a CTRE Talon FX with ID 1 and a REV SPARK MAX with ID 1 do not conflict, because they're different device types from different manufacturers. The conflict rule applies within the same device type. When in doubt, give everything a unique number anyway. It's free insurance.

Reading CAN utilization in the Driver Station

The FRC Driver Station has a built-in CAN health monitor. On the CAN/Power tab (the fifth tab down on the left side) you'll find:

• CAN Bus Utilization - the percentage of the bus's capacity currently in use. Lower is healthier; if you're pushing very high utilization, status frames can start to lag.
• CAN faults - counts of each of the four CAN fault types accumulated since the Driver Station connected. Rising fault counts are a strong signal that something on the bus is intermittent or miswired.

There's an important catch documented in WPILib's Known Issues: the live utilization number "spikes" because the roboRIO occasionally counts CAN packets in the wrong time period, so one reading is too low and the next too high. The fix is to open the DS log afterward, zoom in, and read the average of the stable region. Don't panic over a single spike. The Diagnostics tab also lists CAN Device Versions, the firmware of connected devices, which is handy for confirming a device is actually being seen.

The most common failures and how to diagnose each

Most CAN problems trace back to wiring, not code. The signature symptom is dramatic: because everything shares one line, a single bad spot can knock out many devices at once, and the devices "downstream" of the break vanish from your tools while upstream ones stay fine. That pattern is a gift, because it points you straight at the break.

Diagnosing with Phoenix Tuner X (CTRE devices): Connect to the roboRIO and open the device list. Every healthy CTRE device appears as a card. A duplicate ID shows up as a red card with a conflict message in the middle. To resolve a conflict, CTRE recommends isolating devices: wire the roboRIO to one device only (roboRIO to device to a 120-ohm terminator), confirm it appears, give it a unique ID, then repeat for the next device. Select a device's numeric ID field to change it.

Diagnosing with the REV Hardware Client (REV devices): Plug a USB cable into any SPARK MAX or the PDH and open the Hardware tab. Thanks to the USB-to-CAN bridge feature in SPARK MAX firmware, one USB-connected controller can surface the entire CAN bus, so you can see, configure, and update every REV device on the chain without cabling into each one. Set each device's CAN ID and update firmware from the same screen.

When you genuinely can't tell whether you have an ID conflict or a wiring fault, fall back to the isolation method. Strip the bus down to roboRIO plus one device, prove it works, then add devices back one at a time. The moment things break, the last device or wire you touched is your culprit. For a deeper look at building a clean, fault-resistant electrical board, see our electrical track.

What a CANivore is

As you add more high-performance devices, a standard CAN bus can get crowded. The CANivore is CTRE's answer. Per the Phoenix 6 CANivore docs, it's a multipurpose USB-to-CAN FD device that adds a second, separate CAN bus to the roboRIO. CAN FD ("Flexible Data-rate") improves on classic CAN with higher device bandwidth and faster transfers, which matters when you're running many high-update-rate motors and sensors.

Two practical wins for teams: you can split your devices across two buses to reduce load on each, and the CANivore has its own built-in termination, which makes it a handy bench tool. CTRE notes you can configure a single device on a short harness as CANivore to device to a 120-ohm resistor, giving you a known-good, properly terminated test setup away from the robot.

The takeaway

CAN feels intimidating until you internalize three facts: it's one continuous daisy chain, it needs a 120-ohm terminator at each end (so ~60 ohm with power off), and every device of a type needs a unique ID. Master those, keep Phoenix Tuner X and the REV Hardware Client handy, and watch the Driver Station's fault counts, and you'll diagnose the vast majority of CAN problems before they ever cost you a match.

Ready to wire a bulletproof electrical system from scratch? Start with the LearnFRC electrical track.