Power, Brown-Outs, and CAN Bus Faults

Half of 'the code is broken' reports are really electrical. Two failure families dominate: brown-outs and CAN bus problems. Both have clear signatures once you know them.

Brown-out thresholds#

The roboRIO uses a staged brown-out scheme to protect itself from low battery voltage. The exact second-stage threshold differs by hardware:

• On both the roboRIO 1.0 and 2.0, when voltage drops below 6.8V the 6V rail on the PWM pins begins to drop.
• The roboRIO 1.0 enters the brown-out protection state at 6.3V (fixed): PWM outputs are disabled. WPILib motor controllers send a single neutral pulse, then the output is cut.
• The roboRIO 2.0's default brown-out level (Stage 2) is 6.75V, and it is software-configurable via RobotController.setBrownoutVoltage().

When this happens mid-match your robot goes limp for a moment and the driver swears the code froze. It didn't -- the hardware protected itself.

How to confirm a brown-out#

Three independent signals:

1. The DS CAN/Power tab increments the 12V fault counter by 1.
2. The DS records a brown-out event in the DS log.
3. The DS Log Viewer marks it with a bright orange line on the voltage graph.

How to prevent brown-outs#

• Use a fully charged, healthy battery (measure resting voltage and internal resistance with a tester before each match).
• Set current limits on motors -- e.g. config.smartCurrentLimit(40) on a SPARK, or CurrentLimitsConfigs with SupplyCurrentLimit on a Talon FX -- so several mechanisms can't all spike at once.
• Ramp demand instead of slamming to full output; avoid commanding every motor to peak simultaneously.

CAN bus faults#

The CAN bus is a daisy chain; problems show up as devices going missing or comms lagging.

• High CAN utilization (CAN/Power tab >90%): too many high-rate frames. Lower status-frame periods on devices you don't read often, or reduce excessive signal refresh rates.
• Duplicate CAN IDs: two devices of the same type with the same ID on the same bus is a hard fault -- one or both behave erratically or vanish. Every device of a given type needs a unique ID; check with the vendor tools (Phoenix Tuner X, REV Hardware Client).
• A loose connection anywhere breaks the chain past that point; constructors for some pneumatics/CAN devices can even throw if the bus is disconnected at boot, so wrap them in try/catch and, more importantly, verify wiring.
• Missing termination: the CAN bus needs a 120-ohm terminating resistor at the end of the chain (the PDP/PDH provides a built-in terminator) or you'll see flaky communication.

The discipline#

Maintain a written CAN ID map for the whole robot, label every device, and re-run a device scan in Phoenix Tuner X / REV Hardware Client after any rewiring. Most 'random' CAN failures are a duplicate ID or a loose connector, and both are found in minutes with the vendor scan tools.