Competition Calibration & Auton Selector

// Section 01

Why Auton That Works in Practice Fails at Competition

The competition venue is not your practice field. Five things change every time you travel to an event.

🎦

Recommended: Pre-Match Calibration Walkthrough

    
  Pre-match calibration workflow
  
  Power On
  charge check
  
  Confirm
  Sensors
  IMU + encoders
  
  Select
  Auton
  from selector
  
  Test
  Drive
  quick check
  
  Confirm
  w/ Strat
  everyone agrees

🚫

Most auton failures at competitions are environmental, not code failures. The routine worked perfectly in practice. It failed at the event because the environment changed and the team had no process for checking it.

What Changes at Every Competition

Your Practice Setup

Same lighting, same brightness level
Fresh or consistently worn tile surface
Walls you've verified for distance readings
Full battery from your charger
Relaxed placement, no pressure
You can re-run immediately if something's off

The Competition Venue

Different lighting — bright gym, dim warehouse, skylights
Tiles with months of wear from practice fields
Field walls that may be slightly different height or texture
Battery borrowed from a teammate or charged in the pit
60-second queue window, crowd noise, pressure
One shot — no re-run after a bad autonomous

How Each Factor Affects Autonomou

Lighting: Optical sensors (line tracking, color) are directly affected. Distance sensors are less sensitive to light, but optical interference from skylights can cause noise spikes in any sensor.
Tile wear and surface: Higher friction on worn tiles means the robot stops shorter. Lower friction on polished tiles means it overshoots. Your sensor target distance was calibrated on your tiles.
Wall reflectivity: Some competition field walls have different surface texture than practice walls. A 5–8 mm reading difference is enough to shift a scoring position.
Battery level: A partially charged battery produces less motor output. PID compensates, but the correction range shrinks. Start your competition day with fully charged batteries.
Starting alignment: In practice you place the robot carefully. Under queue pressure, placement is rushed. A 1-inch start shift plus a 5mm wall difference puts you 3–4 cm off position — a missed score.

✅

None of these failures require code fixes. They require a pre-match workflow. The code was right. The checklist was missing.

1 / 5

// Section 02

Pre-Match Calibration Workflow

Do this before every match. Takes 90 seconds. Catches 90% of competition failures before they happen.

🏆 Pre-Match Calibration — 90 Seconds Before Queue

Brain powered on — correct program slot selected and running

Verify slot number matches the one you want, not last match's program

IMU fully calibrated — robot stationary during calibration

Any movement during IMU calibration causes drift all match — wait for the green indicator

Controller paired — LCD shows YOUR robot name

Not another team's robot — verify by name on screen

Alliance color confirmed — correct auton side selected

Checked by BOTH strategist and engineer independently

Auton routine selection verified by strategist

Driver and strategist say the routine name out loud before walking to field

Drive test — robot responds to joystick in pit area

5-second test drive confirms connection before queue — don't skip this

Robot stationary at field edge until match begins

No repositioning after IMU calibration — every move adds drift

🏆 Pre-Match Calibration — Every Match

Brain powered on — program loaded and running

Green light on Brain; correct program slot selected

IMU calibrated — robot stationary during calibration

Never move the robot while the IMU is calibrating

Controller paired — LCD shows your robot name

Not another team's robot — verify on LCD screen

Alliance color confirmed — correct auton side selected

Red or Blue — checked by strategist AND engineer

Auton routine confirmed on Brain screen

Navigate selector to the correct routine name

Robot placed in start position using reference marks

Use tape or field perimeter — not by eye

Quick drive test — robot responds to controller

Move joystick, confirm robot responds before walking to field

🏆

This is a standard operating procedure, not a suggestion. Write it on a laminated card. Put it in the pit. Practice it before every run in practice, not just at competitions.

Pre-Match Checklist — 8 Steps

01

Turn on early — before you queue

Power on the robot at least 3 minutes before your match window. The IMU needs 2–3 seconds to calibrate on startup. Give it time before walking to the field.

02

Select the correct autonomous

Use the controller to select your routine in the disabled() period. Programmer confirms the name on the Brain screen. Say it out loud — "Left Safe selected."

03

Place robot in starting position

Use a defined reference — tile edge, alliance marker, or a taped mark on the mat. Consistent placement is as important as the sensor check.

04

Check sensor readings on the Brain screen

Your debug screen should show live distance sensor values. Verify the front wall reading matches your expected starting distance. If it's off by more than 20mm — fix the placement, not the code.

05

Verify the value is stable

Watch the reading for 2–3 seconds. A stable value (e.g. 478mm ±2mm) is good. A jumping value (460 → 501 → 478 → 512) means something is in the beam path or the sensor is loose.

06

Check robot is square to the wall

Sight down the robot from behind. If one side is clearly closer to the wall, re-seat it. A 3° angle at start becomes a 5-inch lateral error by the goal.

07

If allowed — run one quick test movement

During practice matches or skills runs, a 12-inch test drive confirms the wheels are spinning, no stalls, and PID responds normally. Never do this at a real qualifier without permission.

08

Re-seat and step back

Make final adjustments, step away from the robot, and tell the referee you're ready. Don't touch the robot again unless given permission.

Quick Sensor Check — What Drivers Watch For

The driver doesn't need to understand sensor theory. They need three questions:

Driver Quick Check

"Does the number look right?" — your starting distance from the wall should be a consistent number your team knows (e.g. "should read around 480"). If it says 230 or 900, something is wrong.

"Is it stable or jumping?" — a stable reading is good. Jumping by 30+ mm every second means the beam is blocked or the sensor is loose.

"Is the robot square to the wall?" — look from behind the robot toward the wall. Both sides of the robot should be equidistant from the nearest boundary.

"Did we confirm the auton name on the Brain screen?" — driver says the name, programmer confirms it visually. Two-person confirmation.

Adding a Debug Display

Show live sensor values on the Brain screen during the disabled() period. Drivers and programmers can see exact readings without pulling out a laptop.

src/main.cpp — in disabled()

void disabled() { while (true) { // Row 1: Current auton selection (auto-shown by EZ Template) // Row 2: Live distance sensor value pros::screen::print(pros::E_TEXT_MEDIUM, 3, "DIST: %d mm ", dist_sensor.get()); // Row 3: IMU heading (0° = aligned correctly at start) pros::screen::print(pros::E_TEXT_MEDIUM, 4, "HDG: %.1f deg ", chassis.drive_imu_get()); // Row 4: Battery voltage pros::screen::print(pros::E_TEXT_MEDIUM, 5, "BATT: %d%% ", pros::battery::get_capacity()); pros::delay(100); } }

✅

Add trailing spaces to every print format string. Brain screen doesn't auto-clear old text — a previous long value can leave trailing digits. "DIST: %d mm " ensures the line is always overwritten cleanly.

2 / 5

// Section 03

Autonomous Selector Setup

The selector is the interface between your code and your driver. A confusing selector causes match losses that have nothing to do with programming quality.

Why Auton Selection Loses Matches

Selecting the wrong autonomous is one of the most common and most preventable match failures in VRC. It happens because:

Routine names are cryptic (auton1, test_auton_FINAL, rightv3_fixed)
Too many options — driver scrolls past the right one under pressure
Nobody confirmed the selection visually before placing the robot
Programmer changed routine names between matches without telling the driver

⚠️

A match lost to wrong auton selection is a process failure, not a code failure. The code was right. The routine was ready. The team skipped the two-second confirmation step.

EZ Template Selector Structure

Routines are registered in initialize() using ez::as::auton_selector.autons_add(). The selector appears automatically in the disabled() period and is controlled via the joystick on the connected controller.

src/main.cpp — registering routines in initialize()

void initialize() { chassis.initialize(); // Register all competition routines // Names shown on the Brain screen selector — keep them SHORT and CLEAR ez::as::auton_selector.autons_add({ Auton("Left Safe", left_safe), Auton("Right Safe", right_safe), Auton("Left Aggressive", left_aggressive), Auton("Skills Run", skills_run), Auton("Do Nothing", do_nothing), }); }

ℹ️

Always include a "Do Nothing" routine. If you're unsure which routine is safe, selecting "Do Nothing" is better than running the wrong routine and scoring for the opponent. It's the safest fallback.

Naming Your Routines — Rules

Use alliance + side + type. Format: [Side] [Strategy]. Examples: "Left Safe", "Right Aggressive", "Center AWP".
Max 20 characters. Longer names get cut off on the Brain screen.
No version numbers. "Right v3" tells the driver nothing about when to use it. "Right Safe" does.
Match what the driver calls it verbally. If your driver says "run left safe," the Brain screen should say exactly "Left Safe."

Recommended Routine Set — 3 to 5 Max

Standard

Left Safe

Low-risk. Scores auton bonus. Use when winning or unsure about opponent's routine.

Standard

Right Safe

Mirror of Left Safe. Use based on alliance color and field position.

High Risk

Aggressive

Max points. Use when you need a win and alliance coordination is confirmed.

Skills

Skills Run

Full 60-second skills. Only run during skills slots — never at a match start.

Fallback

Do Nothing

Robot stays still. Use when unsure or if auton reliability is in question before a match.

✅

Keep "Do Nothing" and "Skills Run" at the ends of the list. Skills Run at the end means it's never accidentally one scroll away from your competition routine. Do Nothing near the top is easy to find under pressure.

3 / 5

// Section 04

Safe Selection Workflow & Advanced Tips

A two-person confirmation process and the Brain screen features that make it foolproof.

The Selection SOP — 5 Steps Before Every Match

01

Strategist calls the auton

Based on alliance color and match context, the strategist says the name out loud: "Run Left Safe."

02

Driver scrolls to it using the controller

In the disabled() period, use the left joystick (or configured button) to scroll the selector. Stop when the correct name is highlighted.

03

Programmer reads the name back from the Brain screen

Programmer walks to the robot, reads the Brain screen, and says it out loud: "Brain says Left Safe — confirmed." This is the two-person verification step.

04

Place the robot — sensor check as you do it

Place the robot in starting position and glance at the Brain screen. Distance sensor reading should be in range. Heading should be near 0°.

05

Never change last second unless critical

A last-second change under pressure causes more errors than it prevents. If there is genuine doubt, select "Do Nothing" — a safe auton beats a wrong aggressive one.

Advanced Tip — Visual Confirmation on the Brain Screen

Add a large-text confirmation to the top of your Brain screen display during disabled(). This gives everyone — driver, programmer, and coach — an instant visual confirmation of what's selected.

src/main.cpp — large confirmation display in disabled()

void disabled() { while (true) { // EZ Template auton selector draws the name on row 1–2 automatically // Add sensor readings below it // Visual battery warning int batt = pros::battery::get_capacity(); if (batt < 50) { pros::screen::set_pen(pros::Color::red); pros::screen::print(pros::E_TEXT_LARGE, 3, "LOW BATT: %d%% ", batt); } else { pros::screen::set_pen(pros::Color::white); pros::screen::print(pros::E_TEXT_MEDIUM, 3, "BATT: %d%% ", batt); } // Distance sensor + heading pros::screen::set_pen(pros::Color::white); pros::screen::print(pros::E_TEXT_MEDIUM, 4, "DIST: %d mm ", dist_sensor.get()); pros::screen::print(pros::E_TEXT_MEDIUM, 5, "HDG: %.1f deg ", chassis.drive_imu_get()); pros::delay(100); } }

Advanced Tip — Default Safe Routine

Register your safest routine first. If a driver accidentally powers on the robot and walks to the field without selecting, the first routine in the list runs. Make that a safe routine.

// First in the list = default if nothing is selected ez::as::auton_selector.autons_add({ Auton("Left Safe", left_safe), // ← FIRST = DEFAULT Auton("Right Safe", right_safe), Auton("Left Aggressive", left_aggressive), Auton("Skills Run", skills_run), // ← KEEP AT END Auton("Do Nothing", do_nothing), });

🔬 Check for Understanding

Your team is about to run quals. The strategist says "run Right Safe." The driver scrolls to it. Who should visually confirm the Brain screen before placing the robot?

Nobody — scrolling to it is enough

The drive team coach

The programmer — they walk to the robot, read the Brain screen, and say the name out loud

The driver again — they already saw it on screen while scrolling

Correct. Two-person verbal confirmation is the standard. The driver sees the screen while scrolling under pressure and can miss a one-step scroll error. The programmer walking to the robot and reading the name breaks the confirmation into a separate, deliberate action — which is what catches errors.

4 / 5

// Section 05

Common Failures & Team Habits

The four failures that repeat at every competition — and the one habit that prevents all of them.

Common Pre-Match Failures

Failure	Cause	Prevention
Wrong auton runs at match start	Auton selector not confirmed after last upload	Two-person confirmation before every match — engineer + strategist
Robot doesn't move in autonomous	IMU not calibrated, or wrong program slot selected	Run pre-match drive test; confirm program slot and sensor status on Brain screen
Robot drives wrong direction in auton	Robot placed in wrong starting orientation	Use tape markers or field perimeter reference for start position every match
Controller disconnects during match	Controller battery low or not paired to correct robot	Check controller LCD battery % before every match; confirm robot name shown
Autonomous runs at wrong field position	Red/blue side not checked — selected wrong alliance color route	Always confirm alliance color assignment before selecting auton routine

Common Failures

✖ Wrong Auton Selected

Driver selects "Left Aggressive" when the plan was "Left Safe." Robot scores 4 points and interferes with the alliance. Match lost by 2.

Fix: Two-person verbal confirmation. Strategist calls name → driver selects → programmer reads Brain screen and confirms out loud. Takes 8 seconds. Prevents this completely.

✖ Sensor Not Checked Before Match

Team placed robot but didn't look at the Brain screen. Distance sensor was reading 1999mm (sensor disconnected at pit). Robot drove straight into the wall.

Fix: Check live sensor value on Brain screen as part of robot placement — not after. It takes one glance. Seeing 1999mm means "sensor cable is loose" — easy to fix in 15 seconds if you catch it in time.

✖ Robot Not Square at Start

Robot placed slightly angled — about 4° off. By the time it reaches the scoring zone, the lateral error is 3 inches. Auton misses goal consistently for the whole event.

Fix: Use a physical reference for placement — tile seam, alliance wall edge, or a tape mark at practice. Check squareness visually from behind the robot. If the IMU heading reads more than 2° at start, re-seat.

✖ Skills Run Selected for Match

Programmer added "Skills Run" to the top of the selector list. Under pressure, driver scrolled one too few and ran skills instead of quals routine. 15-second match auton ran for 60 seconds.

Fix: Always put "Skills Run" at or near the end of the auton list. Never adjacent to your most-used routine. Two-person confirmation catches it anyway.

Build the Habit: Simulate Competition Setup Every Practice Run

The pre-match checklist only works if your team has done it hundreds of times before the competition. Build it into every practice session — not just events.

Team Practice Protocol

Before every practice run: power on the robot 3 minutes early
Driver selects the routine using the controller selector — never manual Brain screen launch
Programmer reads the name out loud from the Brain screen
Sensor values checked — distance and heading logged
Robot placed using a defined reference mark
Only then: run the routine

After 20 practice runs this way, the team can execute the full pre-match workflow in under 90 seconds under pressure. That's the goal.

⚙ STEM Highlight

Engineering: Standard Operating Procedures

The pre-match checklist is a Standard Operating Procedure (SOP) — a documented, repeatable process designed to reduce human error under pressure. Aviation, surgical teams, and manufacturing all use SOPs for the same reason: complex tasks under time pressure have predictable failure modes, and checklists catch them before they become incidents.

The two-person confirmation mirrors crew resource management from aviation — the principle that critical decisions require a second verification regardless of confidence level. The reason it works is not that people are careless. Working memory narrows under pressure. A checklist externalizes the procedure so working memory can focus on execution.

🎤 Interview line: "We built a pre-match SOP with two-person auton confirmation because human error under queue pressure is predictable. Turning it into a procedure — not just a habit — is how we removed selection errors from our competition record."

Key Takeaways

Practice ≠ competition environment. Lighting, tiles, walls, and battery all change. Your calibration process accounts for these — your code can't.
Sensor check is a two-second glance that catches disconnected cables, blocked beams, and starting position errors before they become match failures.
Auton naming exists for the driver, not the programmer. If the driver can't immediately identify the right routine under pressure, rename it.
Two-person confirmation prevents wrong selection entirely. Strategist calls it, driver selects it, programmer confirms it on the Brain screen. Three seconds. Zero selection errors.
Good teams practice the process, not just the code. Your code is ready. Practice the checklist until it's automatic.

Related Guides

🏁 Competition Template → ⚡ Sensor-Based Auton → 📏 Distance Sensor → 🔬 PID Diagnostics → 🔍 Robot Pre-Check →

▶ Next Step

Calibration complete. Now learn how to scout opponents and build an alliance selection strategy.

📊 Match Scouting Sheet →

5 / 5