Symptom: The robot comes off the field with a problem, the next match is minutes away, and three people are talking at once while nobody actually fixes anything.
Root cause: No triage protocol. Panic spends your scarce minutes on the wrong thing. The fix is a rehearsed workflow, not heroics.
The triage workflow:
- Stabilize first (60 seconds, every time, no exceptions). Swap to a fresh, load-tested battery and reconnect it tightly. A shocking fraction of "the robot is broken" turns out to be a depleted battery. This also buys the rest of the team a baseline to debug against.
- Reproduce and localize (2–3 min). Ask the drivers exactly what they saw — "it died in endgame" vs "it never moved" point at completely different systems. Power on in the pit and try to reproduce. Pull the Driver Station log from the last match: brownout? Code crash (RioLog stack trace)? Comms drop? Let the evidence pick the subsystem instead of opening everything at once.
- Decide: fix vs. play degraded (1 min). If you can't safely fix it in the time left, decide what the robot can still do and brief the drive coach. A robot that can only farm FUEL but reliably do it is worth more than a robot you half-fix and that disables on the field. Sometimes the right call is to play a limited role this match and do the real repair after.
- Fix one thing, then re-verify (remaining time). Change a single suspected cause, then run your pre-match control check and a power-on test. Don't stack three changes; if it works you won't know why, and if it doesn't you've burned the clock.
- Final checklist before you roll. Battery labeled and secured, bumpers correct color, robot enables on the bench, dashboard connected, controllers zeroed. Same checklist, every match.
Roles prevent chaos. Assign them in advance: one person owns the battery swap, one drives the laptop and reads logs, one does mechanical, the drive coach owns the fix-vs-degrade decision and the queue clock. When everyone knows their lane, a short turnaround is plenty. Teams that win on Saturday aren't the ones that never break — they're the ones who triage calmly and walk a working robot back to the field on time.
the part worth keeping
Key takeaways
- Always stabilize with a fresh load-tested battery first - many 'broken robot' reports are just a depleted battery.
- Let the Driver Station log (brownout / RioLog crash / comms) localize the subsystem before anyone opens the robot.
- Pre-assign turnaround roles and a fix-vs-play-degraded decision owner; change one thing, then re-run the pre-match checklist.
Drive TeamCommon Mistakes & Troubleshootinglesson 5 of 5
Keep going
Take the quiz+10 XP with an accountwhere this came from
Sources and corrections
This lesson is AI-assisted: drafted from primary sources, then reviewed and edited by hand. Errors still get through. When one is reported we fix it and write down what changed, in public, in the corrections log.
sources and further reading
- docs.wpilib.orgWPILib: Driver Station Log Viewer
- docs.wpilib.orgWPILib: roboRIO Brownout and Understanding Current Draw
clipped to this lesson
Articles that go further on this
The lesson gets you through the topic. These go wider on it, and they read in one sitting.
- 13 min readWPILib Won't Deploy: Every Cause and How to Fix ItYour WPILib deploy is failing? Work the decision tree: wrong folder in VS Code, team number, roboRIO image, JDK version, macOS network privacy. Fixes for each./blogread it
- 7 min readFRC "No Robot Code" & Driver Station Won't Connect: Full Fix ChecklistA verified, step-by-step FRC troubleshooting decision tree for "No Robot Code" and a Driver Station that won't connect to the roboRIO — most common causes first./blogread it
- 7 min readFRC Brownout: Why Your Robot Goes Limp and How to Actually Fix ItThe exact roboRIO brownout voltage stages, how to spot one in the Driver Station log, and the fixes ranked by payoff: current limits, battery health, gearing, and compressor scheduling./blogread it
answer sheet
Lesson quiz
All 3 right completes the lesson. Miss one and only that question comes back, anything you already answered correctly stays banked.
0 of 3 answered
01In the match-turnaround workflow, what is the mandatory first stabilize step before you debug anything else?
02After stabilizing, how should the crew localize the failure to the right subsystem?
03When you finally repair the robot with time running out, what is the recommended approach?
Answer every question to submit.
All 34 lessons in Drive Teamopenclose
01 / prerequisites
02 / the-drive-team-and-its-roles
03 / driver-station-and-controls
04 / driver-practice-and-match-performance
05 / the-pit-and-match-turnaround
06 / worked-examples-mini-projects
- Not read yet:Project 1: A Production-Ready Driver Control Scheme
- Not read yet:Project 2: A Drivetrain That Survives a Whole Match
- Not read yet:Project 3: Build a Paper + Spreadsheet Scouting System
- Not read yet:Project 4: Pull Live OPR & EPA Data with Python
- Not read yet:Project 5: The One-Page Pre-Match Strategy Brief
07 / common-mistakes-troubleshooting
08 / advanced-strategy-case-studies