Symptom: the robot freezes or loses subsystems under load, the roboRIO power LED flashes amber, and the Driver Station voltage display flashes red. That is a brownout - battery voltage crossed the roboRIO threshold (6.3V on a roboRIO 1.0, 6.75V default on a 2.0) and outputs were disabled until voltage recovered above 7.5V.
Debugging workflow (work top to bottom, change one thing at a time):
- Confirm it's a brownout, not a disconnect. Open the Driver Station Log Viewer after the match. Brownouts show as markers and a rising '12V fault count.' A comms drop looks different (radio/CAN). Don't fix the wrong problem.
- Check the battery first - it's the most common cause. Test with the Battery Beak: a battery reading 12.5V on an idle robot, or internal resistance above 0.020 Ohm, will sag hard under load. Swap to a battery that reads 12.7-13.5V open-circuit and under 0.015 Ohm. Never start eliminations on an untested battery.
- Inspect the high-current path. A loose SB-50 connector, a corroded or under-torqued battery lug, or wire thinner than 6 AWG between battery, 120A main breaker, and PDP/PDH all add resistance and cause sag. Wiggle-test connections; redo any that move.
- Look for a mechanical stall. A jammed mechanism pulls stall current continuously. If one PDH/PDP channel spikes, you have a binding gearbox or an over-driven motor.
- Add current limits in firmware. On a CTRE TalonFX set a SupplyCurrentLimit (e.g., 70A dropping to 40A after 1.0s) and enable it; on a REV SPARK MAX use setSmartCurrentLimit. This caps draw so voltage never reaches the brownout floor.
- Fix gearing. If wheels can't slip until far above ~40-50A per motor, the drivetrain can stall the whole bus. Re-gear so wheels slip before motors stall.
- Re-test and verify. Re-run the same driving pattern, watch RobotController.isBrownedOut() / getBatteryVoltage(), and confirm the DS log is clean. Don't declare victory without re-reading the log.
The #1 mistake is blaming code when the real cause is a tired battery or a loose lug. Always test the battery and the high-current connections before touching firmware.
Key takeaways
- Confirm brownout via the DS Log Viewer (markers, 12V fault count) before changing anything.
- Test the battery and the SB-50/lug/6 AWG path first - these cause more brownouts than code does.
- Cap draw with supply current limits and gear so wheels slip below motor stall.
Go deeper
Lesson quiz
RequiredAnswer all 3 questions correctly to complete this lesson.
01.On a roboRIO 1.0, at what input voltage does the controller cross its brownout threshold and disable outputs?
02.What should you check first when troubleshooting brownouts, since it causes more brownouts than anything else?
03.Which firmware measure most directly keeps motor current spikes from reaching the brownout floor?
Answer every question to submit.
All 28 lessons in Safety
- Not started:Mini-Project: A Battery Management & Logging System
- Not started:Mini-Project: Write a Robot Lockout/Tagout (LOTO) Procedure
- Not started:Worked Example: Current Limits That Prevent Brownouts
- Not started:Mini-Project: Assemble a Competition Pit Safety Kit
- Not started:Mini-Project: Run a Mock Pit Safety Inspection
- Not started:Troubleshooting Brownouts and Power Sag
- Not started:Battery Handling Mistakes That Cause Injuries and Fires
- Not started:Electrical Isolation and Wiring Mistakes Inspectors Fail You For
- Not started:Stored-Energy Surprises: Pneumatics and Springs
- Not started:Pit and Shop Conduct Mistakes That Hurt Your Judging