🏆 Competition · All Roles · Intermediate

Auton Failure Diagnosis

Your auton worked perfectly in practice. Then it failed at the tournament. This guide covers the 6 reasons this happens — and the 3-minute pre-match protocol that prevents most of them.

This is not PID Diagnostics. PID Diagnostics covers mechanical and tuning failures. This guide covers match-day failures in code that worked fine before — different causes, different fixes.

🚨 The 6 Match-Day Failure Modes

❌ 1 — Field tile variation

Your practice field has different friction or tile height from the competition field. The robot drives the same inches but ends up in a different position.

Fix: Use sensors, not time/distance alone. Add a drive_imu_reset() after wall contact. Use distance sensors to verify position at the start. Never trust raw drive distances at tournaments without a position check.

❌ 2 — Starting position drift

The robot was placed 2 inches off its intended start. Every subsequent movement is now 2 inches wrong. By mid-auton, the error compounds into a miss.

Fix: Use a physical reference — tile edge, corner, or field wall — to position the robot identically every match. Add a tape mark to your robot showing where the tile edge should land. Brief your driver on the exact placement before every match.

❌ 3 — IMU not calibrated

The robot was picked up or bumped after the Brain powered on. The IMU calibrated wrong. Every turn is now off by a fixed angle — usually 5–20°.

Fix: Set the robot down, power on, and don't touch it until the Brain screen shows your auton selector. Add a pros::delay(2000) at the start of initialize() as a forced quiet period before calibration begins. See IMU Setup & Calibration.

❌ 4 — Wrong auton selected

Driver selected the wrong slot in the auton selector. Red-side auton runs on blue side, or skills routine runs in a match. This is a process failure, not a code failure.

Fix: Add a color indicator to the Brain screen — display "RED" or "BLUE" in the auton name. Add to your pre-match checklist: Strategist reads the auton name aloud, Driver confirms. Make it a two-person verbal confirmation.

❌ 5 — Battery power drop

Motor speeds are battery-voltage-dependent. A 60% battery drives differently than a 90% battery. Your auton was tuned on a full battery.

Fix: Only use batteries above 80% for competition autons. Add battery level to your pre-match checklist: check pros::battery::get_capacity() in your Brain screen display. See Battery Management.

❌ 6 — Opponent robot interference

The opponent's robot crossed into your auton path. Your robot hit them, lost position, and finished the auton in the wrong place.

Fix: Design autons to avoid the opponent's side of the field in the first 5 seconds. Watch opponent autons in your scouting notes — if they cross your path, use your backup auton. Brief the Strategist to scout opponent auton paths specifically.

⏱ 3-Minute Pre-Match Auton Protocol

Run this at every competition match, every time. Most auton failures are preventable with a consistent process.

Check battery level on Brain before queuing. Under 80%? Swap batteries now, not in the queue.

Confirm auton selection — Strategist reads the Brain screen auton name aloud. Driver confirms by nodding. Both names match alliance color and strategy agreed in briefing.

Power cycle if needed — if robot was moved since last match, power off, set on field, power on, wait for Brain to show auton selector before touching robot again.

Place to reference — use the physical landmark (tile edge, field wall) to position the robot. Engineer checks placement, not the driver who is focused on the controller.

Say the call — Strategist says the match call (one sentence: what we're doing in the first 10 seconds). Drive team repeats it. Queue.

⚙ STEM Highlight Engineering: Root Cause Analysis & Fault Isolation

Autonomous failure diagnosis applies root cause analysis (RCA) — the engineering methodology used in aerospace and manufacturing to trace failures to their fundamental cause rather than surface symptoms. The five-step RCA process: observe symptom, isolate variable, form hypothesis, test hypothesis, verify fix. Each step eliminates a category of causes. Skipping to fixes without RCA produces solutions that address symptoms and leave root causes active.

🎤 Interview line: “We use structured root cause analysis for every autonomous failure. When our auton drifted left at competition but worked in practice, we isolated the variable systematically: field tile friction differed. We added a surface-specific friction coefficient to our EZ Template config, and auton success rate went from 60% to 92% by addressing the actual cause.”

Your auton works in practice but fails at competition, drifting left consistently. What variable should you isolate first?

⬛ Reduce all drive constants by 20% to compensate for the drift

⬛ Test on competition tiles — tile friction often differs from practice mats and causes IMU-correction errors

⬛ Rewrite the entire autonomous from scratch

📝

Notebook entry tip: Test & Evaluate — Cyan slide — Log every auton failure as a diagnostic test entry: symptom, variable isolated, root cause found, fix applied, and result verified. A failure log showing the debugging process across multiple events is strong Test & Evaluate evidence — it proves systematic engineering, not guesswork.