Sources & confidence: Priority ordering and onboarding sequence reflect common V5RC practice and the structure used by EZ-Template's example project (drivetrain + IMU first). PROS API references for pros::lcd, pros::screen, and pros::Imu verified against pros.cs.purdue.edu/v5. Brain placement guidance synthesizes general V5RC ergonomics and game rules — VEX has not published Override-specific brain placement rules. The Override game manual drops Monday April 27, 2026; some brain placement constraints may be tightened by game-specific rules. Re-read this guide after Monday.
// Section 01

Sensor Onboarding Roadmap 📚

A scaffold for new V5RC teams: which sensors to introduce first, in what order, and how to test them. Plus where to mount your V5 Brain so programming and driving stay sane all season.
🎓 New-Team Friendly 🔧 Testing & Calibration 🏆 Override Season Prep

Why This Guide Exists

Most new V5RC teams either skip sensors entirely (everything on motor encoders) or try to install everything at once and end up debugging six things in parallel. Both paths waste competition season.

The right approach: build the sensor stack incrementally. Introduce each sensor when the team is ready to use the data it provides, and after the previous tier is reliable. This guide gives you that order, the testing patterns, and the practical mounting decisions you make once and live with for the season.

What This Guide Covers

Priority OrderWhich sensors to add first, with a rationale for each tier.
Onboarding PhasesRoughly how to phase sensor introduction across early/mid/late season.
V5 Brain Screen CalibrationThe PROS pros::lcd and pros::screen APIs you use to display sensor values for testing — the same screen you'll stare at during pit time.
Per-Sensor Calibration PatternsWhat to print, what to look for, what bad-vs-good looks like for each sensor type.
V5 Brain PlacementWhere to mount the Brain on the robot for code uploads, auton selection, and driver visibility.
New Team ChecklistA tournament-day checklist that catches the things that bite first-year teams.

Toolchain Assumed

This guide assumes VS Code + PROS + EZ-Template. Code examples are PROS C++. We don't cover Blocks. EZ-Template integration patterns are shown where relevant; LemLib equivalents are noted.

Related Guides

📷
AI Vision Sensor & AprilTags
Tier 5 in the priority stack
 🔮
V5 Optical Sensor
Tier 4 — in-mechanism color/proximity
 📍
GPS, Switches & Potentiometer
Tiers 2–6 across the stack
1 of 7
// Section 02
The Sensor Priority Stack 🎗️
The order matters. Each tier builds on the previous one. Don't skip ahead until the lower tiers are reliable on your robot.

The Six Tiers

1

Inertial Sensor (IMU) — Foundational

Smart Port. Required for any chassis library (EZ-Template, LemLib, OkapiLib). Provides heading, rotation, pitch/roll. Without an IMU, you cannot use EZ-Template's turn PID, swing, or odometry. Install this first, before any auton work begins.

2

Limit & Bumper Switches — Mechanism Safety

3-Wire ADI ports. Cheapest sensor VEX makes. Install at the end-of-travel of every motorized mechanism (lift, arm, tilter). Protects mechanisms from motor stalls and over-travel damage. Two switches on a lift is more impactful than one Optical Sensor. Add these as soon as you have any mechanism beyond the drivetrain.

3

Potentiometer V2 — Mechanism Position

3-Wire ADI port. Add when you have a mechanism with multiple discrete positions (load, score-low, score-mid, score-high). Enables one-button macros for the driver and reliable arm presets for auton. Particularly valuable when the mechanism could be back-driven (a Smart Motor encoder loses its zero if external force rotates the shaft while the brain is off; a potentiometer remembers).

4

V5 Rotation Sensor — Tracking Wheels

Smart Port. Add when you start using EZ-Template's odometry features or LemLib's tracking. Tracking wheels with V5 Rotation Sensors are how serious teams get repeatable autons. The IMU gives you heading; tracking wheels give you X/Y position. Together they make EZ-Template's pid_odom_set or LemLib's moveToPoint work.

5

V5 Optical Sensor — In-Mechanism Sensing

Smart Port. Add when your robot needs to know what it just picked up — alliance ring vs opponent ring, ring vs no-ring (proximity for intake stop). High-leverage for games with alliance-colored game elements (likely Override based on past V5RC patterns). See the Optical Sensor guide.

6

AI Vision Sensor & GPS — Navigation Layer

Smart Port. Both are advanced. AI Vision sees AprilTags and AI-classified objects in the field; GPS tracks absolute position from field code strips. Install only after Tiers 1–5 are working reliably. These are skills-run-grade upgrades that take significant tuning. See the AI Vision deep dive and the GPS Sensor deep dive.

Rationale for This Order

💡 Why Tier 1 = IMU

Without an IMU, your robot cannot turn to a heading reliably. EZ-Template's pid_turn_set and pid_odom_set require it. Encoder-only turning drifts severely on coast wheels. The IMU is the foundation everything else builds on. Skipping it makes every higher tier brittle.

💡 Why Tier 2 = Switches Before Anything Else

A bumper switch costs $10 for a 2-pack. A burned-out V5 Smart Motor from a stalled mechanism costs $40. A broken arm at a competition costs your team a match. Switches are insurance with the highest ROI of any sensor. They also teach new programmers about digital input, which is the simplest sensor type to reason about.

💡 Why GPS & AI Vision Last

Both require careful mounting (height, orientation, occlusion). Both have failure modes that look like working software (GPS reads stale values when occluded; AI Vision misses tags in poor lighting). A new team installing these before mastering simpler sensors will spend hours debugging "why doesn't my robot turn to the tag" when the issue is a wobbly chassis. Install them when your auton is already 80% reliable on Tiers 1–4.

What This Looks Like in EZ-Template

EZ-Template's example project structure already reflects this priority. The chassis constructor takes the IMU port (Tier 1) as a required parameter. Tracking wheels (Tier 4) are optional — you can use EZ-Template without them. Higher-tier sensors are not part of EZ-Template at all; you compose them into your code as separate pros::Optical, pros::AIVision, pros::Gps instances.

// EZ-Template chassis constructor — reflects Tier 1 + optional Tier 4
// EN4: rewrite in your own words for your notebook. ez::Drive chassis( {1, 2, 3}, // Left motors {-4, -5, -6}, // Right motors 7, // IMU port (Tier 1 -- REQUIRED) 4.125, // Wheel diameter 343.0 // Wheel RPM // Tracking wheel config (Tier 4) goes elsewhere via odom_tracker_*_set() ); // Tier 2-3-5-6 sensors are separate -- not in the chassis constructor pros::adi::DigitalIn lift_top_limit('A'); // Tier 2 pros::adi::Potentiometer arm_pot('B', pros::E_ADI_POT_V2); // Tier 3 pros::Optical optical(8); // Tier 5 pros::AIVision aivision(9); // Tier 6 pros::Gps gps(10); // Tier 6
2 of 7
// Section 03
Onboarding Phases 📅
A rough timeline for introducing sensors across the season. Adjust based on your team's schedule, but keep the order.
📋
The Override season runs 2026–27. The phases below assume a typical V5RC team meeting 2–3 times per week. Faster teams can compress; teams meeting once a week may need to extend.

Phase 1: Reveal & Build (Weeks 1–3)

Phase 2: First Mechanism (Weeks 3–5)

Phase 3: First Auton Routine (Weeks 4–6)

Phase 4: Repeatable Auton (Weeks 6–9)

Phase 5: Game-Element Sensing (Weeks 8–12)

Phase 6: Skills Run Polish (Weeks 12+)

What If You're Behind?

Pick the highest-leverage sensor you don't have, install it, ship it. The order above is ideal but not gospel. A Tier 5 Optical Sensor can deliver more match value than a Tier 4 tracking wheel for a specific game. Use judgment.

The only true rule: do not install Tier 6 sensors before Tier 1–2 are working. A new team trying GPS-corrected auton without an IMU has not skipped to the fun part — they've skipped to a debugging nightmare.

3 of 7
// Section 04
V5 Brain Screen for Calibration 📱
The Brain's built-in screen is your primary debugging tool. Every sensor on your robot should have a way to show its live values on the screen during pit time. Here's the PROS API and the patterns that make it useful.

Two PROS Screen APIs

PROS gives you two ways to draw to the V5 Brain screen:

pros::lcd (LLEMU)Legacy LCD Emulator. 8 lines of plain text. Dead simple. Use this for sensor calibration prints. Header: pros/llemu.hpp (included by default).
pros::screenRicher graphics: rectangles, circles, color, custom fonts, custom positions. Use for auton selectors and dashboards. Header: pros/screen.hpp.
LVGLFull-featured graphics library, accessible by including pros/apix.h. Powerful but complex. Conflicts with pros::lcd: per the PROS docs, you cannot use LVGL and LLEMU at the same time. Avoid for new teams.

The Standard Calibration Pattern

For sensor testing, use pros::lcd. It's 8 lines, plenty of space, and you can write to a specific line by number.

// PROS C++ — calibration print pattern
// EN4: rewrite in your own words for your notebook. #include "pros/llemu.hpp" #include "pros/imu.hpp" #include "pros/optical.hpp" #include "pros/adi.hpp" pros::Imu imu(7); pros::Optical optical(5); pros::adi::Potentiometer arm_pot('A', pros::E_ADI_POT_V2); pros::adi::DigitalIn lift_top('B'); void initialize() { pros::lcd::initialize(); // call ONCE before any print imu.reset(true); // calibrates the IMU; takes ~2 seconds optical.set_led_pwm(60); } // Background task: continuously updates the screen void calibration_print_task(void* p) { while (true) { pros::lcd::print(0, "IMU heading: %.2f deg", imu.get_heading()); pros::lcd::print(1, "IMU rotation: %.2f deg", imu.get_rotation()); pros::lcd::print(2, "Pot angle: %.1f deg", arm_pot.get_angle()); pros::lcd::print(3, "Lift top: %s", lift_top.get_value() ? "OUT" : "IN "); pros::lcd::print(4, "Optical hue: %.1f", optical.get_hue()); pros::lcd::print(5, "Optical prox: %d", optical.get_proximity()); pros::lcd::print(6, "Battery: %.0f%%", pros::battery::get_capacity()); pros::delay(50); // 20 Hz update -- plenty for human reading } } void start_calibration_print() { pros::Task t(calibration_print_task, nullptr, "calibration"); }

What to Print Per Sensor Tier

Tier 1 — IMU get_heading() – should be 0–360, never PROS_ERR.
get_rotation() – unbounded; resets to 0 only on tare_rotation().
is_calibrating() – should print "false" after ~2s startup.
Tier 2 — Switches get_value() – 0 when pressed, 1 when released.
Print as "PRESSED" / "RELEASED" for human readability, not raw 0/1.
Tier 3 — Potentiometer get_angle() – 0–333° (V2). Watch for the deadband — should never see jumps from 333 to 0 during normal mechanism travel.
Show alongside named positions: "Pot: 45.2 deg (LOAD)" or similar.
Tier 4 — Rotation Sensor / Tracking Chassis pose: chassis.odom_x_get(), odom_y_get(), odom_theta_get() (EZ-Template). Push robot manually, watch values track.
For LemLib: chassis.getPose().
Tier 5 — Optical Sensor Hue, saturation, brightness, proximity. All four together. Saturation tells you the LED is working; proximity tells you the object is close enough; hue and brightness tell you what you're looking at.
Tier 6 — AI Vision & GPS AI Vision: tag count, first tag's ID and position. GPS: X, Y, heading, error. Use 4–5 lines for these because there's more data per sensor.

Printing in Driver Code Without Conflict

If your driver code prints to the brain screen, the calibration task and driver code can compete for the same lines. Use a convention: dedicate specific lines to specific roles.

Brain Screen Auton Selector

EZ-Template includes a built-in auton selector that uses the brain screen + the bottom row of brain buttons. Per EZ-Template docs:

// EZ-Template auton selector pattern
// EN4: rewrite in your own words for your notebook. void initialize() { // ... ez::as::auton_selector.autons_add({ Auton("Red Left\nDoes the red left side", red_left_auton), Auton("Red Right\nDoes the red right side", red_right_auton), Auton("Blue Left\nDoes the blue left side", blue_left_auton), Auton("Blue Right\nDoes the blue right side", blue_right_auton), Auton("Skills\n60-second skills run", skills_auton), }); // Map brain screen buttons to navigate the selector pros::lcd::register_btn0_cb(ez::as::page_down); pros::lcd::register_btn2_cb(ez::as::page_up); } void autonomous() { chassis.drive_imu_reset(); chassis.drive_sensor_reset(); chassis.drive_brake_set(MOTOR_BRAKE_HOLD); ez::as::auton_selector.selected_auton_call(); // runs whichever was selected }

Bonus per EZ-Template: you can map external limit switches as page-up / page-down buttons via limit_switch_lcd_initialize(). Useful for Override pre-match config.

4 of 7
// Section 05
Per-Sensor Calibration Patterns ⚙️
For each sensor, what bad-vs-good readings look like, and the steps you do at every pit stop to confirm everything works.

IMU Calibration

Calibration triggerAutomatic on power-up. Takes ~2 seconds. Per VEX docs: do not move the robot during calibration. EZ-Template handles this in chassis.drive_imu_reset() at the start of auton.
What good looks likeHeading reads consistently as you rotate the robot manually. Heading at start position is 0 or whatever you set. Heading does NOT drift while the robot sits still.
What bad looks likeHeading drifts > 1° per minute while sitting still — usually a hardware issue or calibration during motion.
Sudden jumps in heading — a hard impact or the IMU coming loose.
Heading reads PROS_ERR or 0 forever — sensor not connected or in wrong port.
Pit-time checkRead brain screen IMU value. Note it. Pick up robot, rotate 90° by hand, set down. Verify the heading changed by ~90°.

PROS API to know:

imu.reset(true); // calibrate, blocking until done imu.tare_heading(); // set current heading to 0 imu.tare_rotation(); // set rotation accumulator to 0 imu.is_calibrating(); // true while calibrating imu.get_heading(); // 0-360 imu.get_rotation(); // unbounded

Switch Calibration

No analog calibration needed — switches are digital. The "calibration" is verifying mechanical alignment.

What good looks likeSwitch reads RELEASED (1) when mechanism is anywhere except the limit. Reads PRESSED (0) only when mechanism reaches the limit. State change is crisp, not flickering.
What bad looks likeReads PRESSED constantly — switch held down by zip-tie or installed too tight.
Reads RELEASED constantly — switch arm bent away from contact path, or wrong port.
Flickers between 0 and 1 — loose cable connection or marginal mechanical contact.
Pit-time checkMove mechanism manually through full range. Confirm switch reads RELEASED everywhere except at the limit, where it reads PRESSED. Wiggle the cable connector to confirm no flicker.

Potentiometer Calibration

What good looks likeAngle changes smoothly as the mechanism moves. No sudden jumps. Mechanism's lower physical limit reads a consistent angle, ditto for upper. The 27° deadband is OUTSIDE normal travel.
What bad looks likeAngle jumps from 333 to 0 mid-travel — mechanism rotates through the deadband. Re-orient the pot body using the arc slots.
Angle reads identical at two clearly different mechanism positions — pot is slipping on its shaft (loose grub screw or stripped D-hole).
Angle changes when you wiggle the cable but not the mechanism — intermittent connection.
Pit-time checkMove mechanism to known positions (down, mid, up). Confirm pot angle matches your stored constants for those positions. Re-record if values shifted.

Calibration utility code:

// EN4: rewrite for your notebook. // Use a controller button to log current pot angle in pit time if (master.get_digital_new_press(DIGITAL_X)) { double a = arm_pot.get_angle(); pros::lcd::print(7, "LOGGED angle: %.2f", a); printf("LOGGED arm angle: %.2f\n", a); // also goes to PROS terminal }

Optical Sensor Calibration

See the dedicated Optical Sensor mounting section. Summary:

  1. Set LED to 50–75% in initialize().
  2. Place each game element you care about at sensor-reading distance (< 100mm).
  3. Read and record hue, saturation, brightness, proximity per object.
  4. Build hue-range table (e.g., red ring = 350–15°).
  5. Re-calibrate at every venue — lighting changes hue readings.

AI Vision Calibration

See the AI Vision Sensor code section. Summary:

  1. Enable AprilTag detection in the AI Vision Utility (one-time setup via VEXcode), OR programmatically with aivision.enable_detection_types(pros::AivisionModeType::tags).
  2. Set the matching AprilTag family with set_tag_family().
  3. Print the count of tags and details of the first tag to the brain screen.
  4. Hold a printed AprilTag in front of the sensor. Confirm the ID matches what's printed on the tag.
  5. Move the tag left/right; the corner X coordinates should change accordingly.

GPS Calibration

What good looks likeX and Y change as you push the robot around the field. Heading is stable when sitting still. Error reads small (< 0.05m typically).
What bad looks likeX and Y stuck at 0.0 — sensor cannot see field code (occluded, wrong height, or no field strips).
Wild X/Y jumps — sensor too close to wall, or partial occlusion.
Error > 0.5m — sensor is barely seeing the strips. Adjust position.
Pit-time checkPlace robot at known field position. Read X and Y. Should match within a few cm of expected. Rotate robot 90°; heading should change ~90°.

Calibration sequence at a competition:

  1. Place robot at a known starting position on the field.
  2. Power on. Wait for GPS to acquire (~2 seconds with field code visible).
  3. Verify on brain screen: X, Y match expected. Error is small.
  4. If readings are wrong, check: (a) is the sensor right-side up? (b) is anything blocking the camera view? (c) is the sensor at the right height?
  5. If using offsets, verify your offset values match the actual sensor mounting on the robot.
5 of 7
// Section 06
V5 Brain Placement & Robot Ergonomics 🧠
Where you put the V5 Brain affects everything: code uploads, auton selection, driver visibility, cable routing, even how often you bend over to reach the SD card slot. Plan this once, live with it all season.
🔔
Override-specific rules pending. The Override game manual drops Monday April 27, 2026. VEX may publish brain placement constraints in the manual (e.g., Brain must be visible from a specific side, must be above the field tile by X inches, etc.). The guidance below is general V5RC ergonomics; verify against the Monday manual before final mounting.

What the Brain Needs Access To

  1. USB-C port — for code uploads from your laptop. Used 50+ times per season.
  2. Touchscreen — for auton selection, IMU calibration check, brain Devices menu. Used at every match.
  3. SD card slot — for SD card-saved auton routines (EZ-Template feature). Used occasionally.
  4. Power button — for power-cycling. Used at every match start.
  5. Smart Ports (21 of them) — for sensor and motor connections. Cables stay plugged in long-term.
  6. 3-Wire ADI ports (8 of them, A–H) — for switches, pot, etc. Stay plugged in long-term.
  7. Battery port — for the V5 battery. Plugged in long-term, but the battery itself swaps between matches.
  8. Radio — the controller radio plugs into the brain's radio port. Long-term connection.

Brain Placement Priorities (in Order)

1

Programmer Access (Highest Priority)

The USB-C port should be reachable WITHOUT removing any structural element of the robot. If you have to take off a cover, unmount a battery, or remove an arm to plug in your laptop, you will hate every code upload of the season — and you upload code dozens of times per practice. Mount the brain so the USB-C side faces an open edge of the robot.

2

Touchscreen Visible & Reachable

The screen needs to be visible from a standing position so the team can read sensor calibration values during pit time. It also needs to be tappable for auton selection at the start of every match. Mount the touchscreen facing up or sideways at a height between waist and chest.

3

Driver Visibility During Match

The driver should be able to glance at the brain screen during a match for status info (battery, mechanism state). This is less critical than 1 and 2, but matters for high-level driver skills runs. If brain orientation forces the driver to bend down to read the screen, they won't use the screen during matches.

4

Protected from Contact

The brain should not be on the front-most or outer-most plane of the robot where it'll take direct hits. Recess it inside the chassis frame, or behind structural members. Brain damage from collisions is rare but devastating.

5

Cable Routing Simplicity

The brain has cables going in many directions: motors front and rear, sensors all over, controller radio out the back. Place the brain centrally (not at one corner) so cable runs are short and there's less strain on connectors.

Common Brain Placements (V5RC Patterns)

Top-Center, Screen Up (Most Common)
Brain mounted on the top deck of the chassis, screen facing up, USB-C side accessible from one side. Pros: easy code uploads, screen visible from standing height, central cable routing. Cons: brain takes vertical space; if you have a low-lift mechanism, your lift might collide with the brain.
Side-Mounted, Screen Outward
Brain mounted vertically on a chassis side wall, screen facing outward. Pros: screen visible during driving from the driver's side; brain doesn't consume vertical space. Cons: USB-C and SD card slots may face a side wall — harder to access during code uploads.
Tilted Top-Mount (Driver-Friendly)
Brain on the top deck, but tilted ~30° toward the driver's side. Pros: optimal driver visibility from across the field. Cons: requires custom angle bracket; cables from a tilted brain are harder to route cleanly.
Recessed Below Top Deck
Brain mounted under a top plate, with a cutout for screen visibility. Pros: maximum protection from collisions; very low profile. Cons: harder to upload code (you may need to remove a cover); harder to read the screen from a distance.

What to Avoid

⚠️ Bad Brain Placements
  • Brain at the front edge of the robot. First thing to take collision damage. Also blocks the AI Vision Sensor or GPS Sensor view if those are also on the front.
  • Brain inside the intake or scoring mechanism. Game elements pile up on it; jams might damage the brain.
  • Brain upside-down or sideways with the touchscreen facing the floor. Cannot tap auton selector. Cannot read status.
  • Brain blocked by a wing, hood, or moving structure. When the wing extends, you can't reach the USB-C port. Plan for the worst-case mechanism position when checking access.
  • Brain at chassis floor level. Driver can't see the screen during a match. Brain takes more dust and tile fuzz than necessary.
  • Brain mounted next to the V5 battery in a way that requires removing the battery to access the brain. You change batteries between matches; you should not have to dismount the brain to do that.

SD Card & Battery Considerations

Cable Discipline (Often Skipped, Always Pays Off)

6 of 7
// Section 07
New-Team Tournament Checklist ✅
A pit-day checklist for first-year teams. Run through this before every match. Most failures are sensor or cable problems; this catches them.

Pre-Match Sensor Checklist

📱 Power-On Sequence
  1. Insert charged battery. Verify battery is fully seated.
  2. Power on V5 Brain. Wait for boot.
  3. Watch the brain screen as your code starts. If you see PROS_ERR, calibration failures, or stuck values, stop and debug.
  4. Wait for IMU calibration to complete (~2 seconds). Brain screen should show heading values updating.
  5. Check brain screen calibration prints (Section 04 of this guide). Confirm all sensors return live values.
🔌 Switch & Pot Quick Test
  1. Manually move each mechanism through full travel. Confirm potentiometer angle changes smoothly (no jumps).
  2. Manually trigger each limit/bumper switch. Confirm screen shows PRESSED state.
  3. Release the switch. Confirm screen shows RELEASED state.
  4. Wiggle the cable connector for each ADI port sensor. If readings flicker, replace the cable.
🔮 Optical Sensor Quick Test (if installed)
  1. Hold a known game element close to the sensor.
  2. Verify hue is in the expected range (per your calibration table).
  3. Verify proximity reads > 200 (sensor sees the object).
  4. Move object away. Verify proximity drops below 100.
📷 AI Vision Quick Test (if installed)
  1. Hold a printed AprilTag in front of the sensor.
  2. Confirm tag count on screen reads 1.
  3. Confirm tag ID matches what's printed on the AprilTag.
  4. Move the tag left/right. Confirm corner X coordinates change.
📍 GPS Quick Test (if installed)
  1. Place robot in a known starting location on the field.
  2. Power on. Wait ~2s.
  3. Verify X and Y on screen match the expected starting position.
  4. Verify heading is correct.
  5. If X/Y read 0.0 or wild values: check sensor orientation, height, occlusion.

Pre-Match Auton Selection

  1. Use brain buttons (or external limit switches if you wired them up) to navigate the auton selector.
  2. Confirm the SELECTED auton matches your match plan (alliance color, starting position).
  3. Visually confirm the team next to you is on the alliance color you set.

Pit-Time Diagnostics If Something Is Wrong

Robot doesn't move in opcontrolCheck: battery charged? Brain on? Code running (PROS terminal shows output)? Controller paired? Any motor temp errors on screen?
Robot turns the wrong way in autonIMU heading is reversed. Check if your motor port directions match your IMU mounting orientation. EZ-Template lets you negate motor ports in the chassis constructor.
Auton starts then stops immediatelyOften a switch reading TRUE when it shouldn't. If your auton has "wait until switch released" logic, a stuck switch hangs you. Check switch states on screen.
Mechanism doesn't reach correct positionPot calibration drifted, or pot is in deadband. Re-record current angles for known positions, update constants.
Auton ends too early / runs too longEZ-Template motion exit timeouts wrong, or sensor-triggered exit fired prematurely. Check brain screen during a test run to see what fired when.
Sensor reads PROS_ERRAlmost always wrong port number or unplugged cable. Verify against your subsystems.cpp port assignments.

End-of-Tournament Maintenance

Long-Season Maintenance

Final Word

Most V5RC matches are won by reliability, not by elaborate code. A simple auton with switch-zeroed mechanisms and pot-feedback positioning beats a complex GPS-AI-Vision auton that fails 30% of the time. Build sensors in the order this guide suggests, calibrate every pit visit, and your match performance will become consistent.

The team next to you with the AprilTag-corrected vision auton is impressive. The team that wins their division is the one whose limit switches always work.

Related Guides

📷
AI Vision Sensor & AprilTags
Tier 6 deep dive
 📍
V5 GPS Sensor
Tier 6 deep dive — absolute position
 🔮
V5 Optical Sensor
Tier 5 deep dive
 📍
GPS, Switches & Potentiometer
Tiers 2–3 and 6 deep dive
7 of 7 — Complete!
This site is an informational reference. RECF EN4 prohibits AI-generated content in engineering notebooks and programming code. Rewrite everything in your own words. About EN4 →  ·  References & Sources →
← ALL GUIDES