Sources & confidence: EZ-Template installation and chassis API verified at ez-robotics.github.io/EZ-Template. LemLib chassis constructor and OdomSensors API verified at the official LemLib documentation and GitHub. PROS template architecture (one chassis library = one PROS template) verified against PROS documentation. RECF EN4 student-centred policy on libraries verified against the LemLib FAQ — teams using a library must understand its algorithms at a high level.
// Section 01
Toolchain Onboarding for V5RC 🛠️
Four tools, one stack. Visual Studio Code is your editor. PROS is your runtime. EZ-Template (or LemLib) is your chassis library. This guide walks new team members through each, what they do, and how they fit together.
🎓 New-Team Friendly🎯 Spartan Design Stack📚 Good Practice
The Stack at a Glance
VS Code
The editor where you write your C++ code. Free, cross-platform, Microsoft-maintained. Has a PROS extension that integrates the build/upload workflow.
PROS
The operating system / runtime that runs on the V5 Brain. Provides the C++ API for motors, sensors, tasks, etc. Open-source, maintained by Purdue SIGBots. Underneath: FreeRTOS.
EZ-Template
A PROS template (library) for chassis movement. Wraps drivetrain motors and the IMU into a chassis object. Provides PID drive, turn, swing, odometry, auton selector. Spartan Design's primary chassis library.
LemLib
A PROS template that competes with EZ-Template. Similar feature set, different API style. Inspired by EZ-Template and OkapiLib. Alternative to EZ-Template, not a complement.
The Three Big Questions This Guide Answers
How do I install all four? — Sections 02–05.
Can I use EZ-Template AND LemLib in the same project? — Section 06. Short answer: technically yes, practically no, and we recommend against it.
What does good practice look like? — Section 07. Project structure, naming, version control, code review.
Why This Stack Specifically
Spartan Design uses VS Code + PROS + EZ-Template because:
VS Code is the same editor used in industry. Your team is learning a transferable skill, not a VEX-only environment.
PROS gives you the full power of C++ — pointers, classes, threads, the standard library. VEXcode hides those for accessibility; PROS exposes them for control.
EZ-Template handles drivetrain plumbing so your team writes auton logic, not PID loops. EZ-Template is a popular choice in the V5RC community and has plug-and-play example projects, a built-in auton selector, live PID tuning, and odometry.
This guide doesn't try to talk you out of any of these choices. It teaches you how to use them well.
Your editor. Free. Cross-platform (Windows, macOS, Linux, Chromebook with Linux container). The same VS Code that professional engineers use daily.
What VS Code Does
Edits your C++ code with syntax highlighting, autocomplete, and inline error checking.
Manages your project files in a tree view.
Hosts the PROS extension, which integrates the PROS build/upload commands into the editor.
Hosts the integrated terminal, where you run command-line tools (PROS CLI, git, etc.).
Provides Git source control integration so your team can version your code.
What VS Code does NOT do: compile or upload your code by itself. The PROS toolchain handles that, invoked through VS Code commands.
Installation Steps
Download VS Code from code.visualstudio.com. Install with default settings.
Open VS Code. Go to the Extensions panel (left sidebar, blocks icon).
Search for "PROS". Install the official PROS extension (published by purduesigbots).
The PROS extension will prompt you to install the PROS CLI and the toolchain (the C++ compiler and tools targeting the V5 Brain). Accept the prompts.
On first install, this can take 10–30 minutes depending on your network. The toolchain is large.
Recommended VS Code Extensions
PROS
The official PROS extension. Required for V5RC work in this stack.
C/C++ (Microsoft)
Adds IntelliSense, debugging support, and proper C++ syntax handling. Required for autocomplete to work on PROS APIs.
GitLens
Optional but highly useful. Shows git blame inline (who wrote which line, when). Speeds up code review.
Better Comments
Optional. Highlights TODO, FIXME, and other comment markers in distinct colors. Great for shared codebases.
Live Share
Optional. Lets multiple team members edit the same file in real time. Useful for pair programming.
Day-One Setup Tips
Configure auto-save. Settings → search "auto save" → set to onFocusChange. Stops you losing edits when switching windows.
Set tab size to 4 or 2 consistently across the team. Mixed indentation makes git diffs noisy.
Set up the PROS terminal in VS Code. Terminal → New Terminal opens a built-in terminal. Use this instead of your system terminal for PROS commands — it inherits VS Code's project context.
Set up format-on-save with the C/C++ extension. Pre-empts style debates.
What Goes Wrong
⚠️ Common First-Day Issues
PROS CLI not in PATH. The PROS extension installs the CLI but sometimes doesn't add it to your shell's PATH. Reopen VS Code, or restart your terminal.
IntelliSense red squiggles everywhere. Usually means C/C++ extension hasn't found the PROS includes. Run PROS > Conductor > Apply Template to refresh.
Build fails immediately. Check that you're inside an actual PROS project (there should be a project.pros file in the root). VS Code can be opened without a project — PROS commands then fail.
USB-C cable doesn't connect. Some USB-C cables are charge-only and lack data lines. Use the cable that came with your V5 Brain, or known-good data cables.
2 of 7
// Section 03
PROS ⚙️
Purdue Robotics Operating System. Open-source firmware/runtime for the V5 Brain, plus a CLI and a C++ API. Maintained by Purdue SIGBots. The base layer of everything else in this stack.
What PROS Provides
A runtime on the V5 Brain. Manages tasks, scheduling, and memory. Underneath: FreeRTOS.
A C++ API for every V5 hardware element — motors (pros::Motor), IMU (pros::Imu), AI Vision (pros::AIVision), Optical Sensor (pros::Optical), GPS (pros::Gps), ADI ports (pros::adi::DigitalIn, pros::adi::Potentiometer), brain screen (pros::lcd, pros::screen), controller (pros::Controller).
A CLI for project creation, building, uploading, and managing templates.
A template system for adding libraries to your project (EZ-Template and LemLib are PROS templates).
Project Structure
A standard PROS project looks like this:
my-project/
src/
main.cpp // your code: initialize(), opcontrol(), autonomous()
subsystems.cpp // your sensor and motor definitions
autons.cpp // your auton routines
include/
main.h // includes pros/api.h and EZ-Template
subsystems.hpp // extern declarations of your motors/sensors
firmware/
EZ-Template@x.x.x.zip // installed PROS templates
project.pros // PROS project metadata
Makefile // build script (rarely edited)
The Three PROS Lifecycle Functions
Every PROS project defines three functions. The runtime calls them at the right time:
1
initialize()
Runs once at brain power-on, before anything else. Use for: sensor calibration (IMU especially), display initialization, starting background tasks. Blocking calls here are OK — the brain is not in a match yet.
2
autonomous()
Runs once when the autonomous period starts (15 seconds in match, 60 seconds in skills). Your auton routine goes here. Returns when the routine finishes; runtime stops calling it.
3
opcontrol()
Runs in a loop during the driver-controlled period. Reads controller input, sets motor power, runs driver-assist macros. Should NOT block — structure as a while(true) { ... pros::delay(20); } loop.
Common PROS CLI Commands
prosv5 conduct new my-project # create a new project
prosv5 build # compile your code
prosv5 upload # upload to V5 Brain (must be plugged in)
prosv5 mu # build + upload + run terminal in one command
prosv5 terminal # open serial terminal to brain (printf output)
prosv5 conduct apply EZ-Template # add EZ-Template to project
VS Code's PROS extension provides GUI buttons for build/upload, but the CLI is faster once you're comfortable with it.
Why PROS Over VEXcode
Real C++. Pointers, classes, templates, the standard library. VEXcode wraps these.
Real tasks. True multi-threading via FreeRTOS. Run sensor monitoring in a background task while the main code does other things.
Real version control. A PROS project is a folder. Git tracks it cleanly. VEXcode projects are harder to share via git.
Open templates ecosystem. EZ-Template, LemLib, OkapiLib, and many community libraries are PROS-only.
The trade: PROS is harder for absolute beginners. VEXcode's drag-and-drop blocks make "make the robot move forward" trivial. PROS makes "coordinate three subsystems with sensor feedback" tractable. Different tools for different stages.
3 of 7
// Section 04
EZ-Template 🏌
Spartan Design's primary chassis library. A PROS template that wraps drivetrain motors + IMU into a chassis object with PID drive, turn, swing, and async motion. Created by EZ-Robotics, MIT-licensed, actively maintained.
What EZ-Template Provides
PID drive / turn / swing / arc primitives — tell the chassis to drive 24 inches, turn 90 degrees, etc., and EZ-Template handles the math.
Odometry with Pure Pursuit and Boomerang motion algorithms (with optional tracking wheels).
Asynchronous motion — start a motion, do something else (sensor checks, mechanism control), wait for completion later.
Joystick control modes — tank, single-stick arcade, dual-stick arcade, with optional input curves.
Auton selector — touchscreen-based, with brain-button or external-switch navigation.
Live PID tuner — adjust kP, kI, kD with the controller while the robot moves.
Tug-of-war detection, overheat detection, slew control — safety features for competition robustness.
Installation
Open your PROS project in VS Code.
Open VS Code's integrated terminal.
Run: prosv5 conduct fetch https://github.com/EZ-Robotics/EZ-Template/releases/latest/download/EZ-Template@latest.zip (URL pattern; check ez-robotics.github.io/EZ-Template for the current release URL).
Run: prosv5 conduct apply EZ-Template to apply the template to your project.
EZ-Template publishes a complete example project at github.com/EZ-Robotics/EZ-Template-Example. Easier path: clone that repo and rename it for your project.
The Chassis Constructor
From EZ-Template's installation tutorial:
// EZ-Template chassis constructor
// EN4: rewrite in your own words for your notebook.
ez::Drive chassis(
// Drive motors. The first motor is used as the "sensing" motor.
{1, 2, 3}, // Left chassis ports (negative port = reversed)
{-4, -5, -6}, // Right chassis ports (negative port = reversed)
7, // IMU port
4.125, // Wheel diameter (4" wheels w/o screw holes are actually 4.125)
343.0 // Wheel RPM = motor cartridge * (motor gear / wheel gear)
);
That's it — you've declared a chassis with 6 drive motors and an IMU. The chassis object now has dozens of methods (chassis.pid_drive_set, chassis.opcontrol_tank, etc.).
The example project is plug-and-play. A new programmer can have a working drive in 30 minutes.
The auton selector ships in the box. No need to build one yourself.
The live PID tuner saves hours. Tune kP/kI/kD on the controller without re-uploading.
Documentation is good. The official tutorials at ez-robotics.github.io/EZ-Template walk through everything.
Community. Discord server with active maintainers. Bug fixes ship quickly.
What EZ-Template Does NOT Do
Same as we've said in the sensor guides: EZ-Template wraps the chassis only. It does NOT wrap:
The Optical Sensor
The AI Vision Sensor
The GPS Sensor
Limit/bumper switches
Potentiometers
Custom subsystems (intake, lift, claw, climb)
For all of those you use the standard PROS API (pros::Optical, etc.) and compose them with EZ-Template chassis calls in your auton code. See the sensor onboarding roadmap.
4 of 7
// Section 05
LemLib 🌿
An alternative chassis library to EZ-Template. Same problem space, different API. Inspired by EZ-Template and OkapiLib. Worth knowing about even if you stay on EZ-Template.
What LemLib Provides
Odometry-first chassis design. LemLib's primary motion primitive is "move to (x, y, theta)" rather than "drive N inches." All movement happens in field coordinates.
Pure Pursuit path following with imported path files (from path planners like PATH.JERRYIO).
Boomerang motion to pose (move to a target X/Y AND face a specific direction).
Tracking wheel support via V5 Rotation Sensors or ADI Encoders.
IMU integration via the OdomSensors struct.
Per the LemLib README: it's an open-source PROS template "inspired by EZ-Template and OkapiLib."
Installation
Same PROS project structure as EZ-Template.
Run: prosv5 conduct fetch [LemLib release URL] — check the LemLib GitHub for the current latest release URL.
Run: prosv5 conduct apply LemLib.
Follow the LemLib chassis setup tutorial (currently at the LemLib documentation).
The LemLib Chassis Constructor
LemLib uses a more decomposed setup than EZ-Template. From the LemLib docs:
void my_auton() {
chassis.setPose(0, 0, 0); // X, Y, theta in inches/degrees
chassis.moveToPoint(24, 0, 4000); // X, Y, timeout in ms
chassis.waitUntilDone();
chassis.turnToHeading(90, 2000);
chassis.waitUntilDone();
chassis.moveToPose(24, 24, 90, 4000); // move to pose AND face heading
chassis.waitUntilDone();
}
Spartan Design recommendation: do NOT use both libraries in the same project. Pick one. The reasons are technical, organizational, and pedagogical. All three matter.
Why It's Technically Possible
EZ-Template and LemLib are both PROS templates. PROS allows multiple templates in one project. There's no compiler error from including both. You could write code that creates both an ez::Drive chassis_ez and a lemlib::Chassis chassis_lem in the same file.
Why It's Practically Bad
⚙ Reason 1: Both Libraries Want to Own the Drivetrain
EZ-Template's chassis object holds references to the drive motors. LemLib's Chassis object holds MotorGroup references to the same motors. If both try to drive the same motors at the same time, the last write wins — you get jitter, opposing forces, or completely unpredictable behavior. You'd have to manually arbitrate which library "owns" the drive at each moment, defeating the purpose of using a library.
⚙ Reason 2: Both Calibrate the IMU
EZ-Template calls imu.reset() at chassis construction. LemLib calls imu.calibrate() via chassis.calibrate(). If both try to calibrate the IMU at startup, you'll get a calibration race — one finishes, the other starts a new one, and your "ready" signal lies. Per the LemLib chassis header: "this should only be necessary if you are using a different library that calibrates the IMU" — the project authors are aware of this exact conflict.
⚙ Reason 3: Two Odometry Estimates That Disagree
If both libraries are tracking position from the same wheel encoders + IMU, they'll produce two slightly different estimates due to differences in their integration math, sample timing, and filter implementations. Your code now has to choose which one to trust at any given moment — an unsolvable problem for new programmers.
⚙ Reason 4: Confused Code Reviews and Onboarding
A new team member reading chassis_ez.pid_drive_set(24_in) on one line and chassis_lem.moveToPoint(24, 0, 4000) on the next has to learn both APIs to understand the auton. That doubles the onboarding burden. For RECF EN4 reviews, you have to explain to judges why both exist — with no good answer.
⚙ Reason 5: Larger Binary & Slower Builds
Including both adds compile time and binary size. Not catastrophic on the V5 Brain (it has plenty of flash), but unnecessary.
The Only Defensible "Both" Pattern
There is one narrow case where having both installed (but not actively running) might be acceptable: a temporary migration. Example: your team is moving from EZ-Template to LemLib. For a few weeks, you have both installed while you port one auton routine at a time. Even then:
Only ONE library's chassis is alive in memory at any moment.
You're committed to fully removing the loser at the end of the migration.
The transition is short (weeks, not months).
This is the only pattern Spartan Design considers acceptable. Any longer coexistence is a sign of indecision, not engineering.
What If We Want Features From Both?
Look for those features somewhere else:
Want LemLib's Pure Pursuit but stay on EZ-Template? EZ-Template now has Pure Pursuit and Boomerang built in (per the EZ-Template release notes). No need to add LemLib.
Want EZ-Template's auton selector but use LemLib? Write a simple selector yourself using pros::lcd. The full code is ~50 lines.
Want EZ-Template's live PID tuner but use LemLib? LemLib doesn't have one. Use printf to a PROS terminal and re-upload after each adjustment. Slower, but it works.
How to Actually Decide
Pick one library based on the comparison in Section 05.
Use it for an entire season.
At end-of-season, in your post-season retrospective, evaluate whether the other library would have served better.
Migrate before the next season if you decide to switch.
Don't mix them mid-season. Don't maintain a compromise project that uses bits of each. Pick. Commit. Reassess later.
6 of 7
// Section 07
What Good Practice Looks Like 🏆
Concrete patterns that separate teams who win from teams who debug. None of these are unique to V5RC — they're standard software engineering practice scaled to the season.
1. Project Layout
Spread your code across files by responsibility, not by season:
src/
main.cpp # initialize(), opcontrol(), autonomous() — thin
subsystems.cpp # motor / sensor instance definitions
autons/
red_left.cpp # one auton per file
red_right.cpp
blue_left.cpp
blue_right.cpp
skills.cpp
mechanisms/
arm.cpp # arm subsystem (with its sensor task)
intake.cpp # intake subsystem
climb.cpp # climb subsystem
utilities/
calibration.cpp # brain screen calibration prints
color_classify.cpp # Optical Sensor color classification
include/
subsystems.hpp # extern declarations matching subsystems.cpp
autons.hpp
mechanisms/
arm.hpp
intake.hpp
climb.hpp
This means every file has a single, obvious purpose. New team members can find "the arm code" without reading main.cpp.
2. Naming & Constants
Use named constants for ports.constexpr int IMU_PORT = 7; not magic numbers scattered across files.
Use named constants for sensor calibration values.constexpr double ARM_LOAD_DEG = 18.5; — updated in one place.
Group constants in a header.include/constants.hpp holds all robot-specific numbers. Easy to audit; easy to update for a new robot.
Use snake_case for variables and functions, UPPER_SNAKE_CASE for constants. Pick a convention, stick to it.
3. Version Control (Git)
For full setup and workflow details — including the team-mentor pull-request flow, conflict resolution, recovery patterns, and competition-day Git checklist — see the dedicated Git & GitHub Workflow Deep Dive. The bullets below are the high-level rules; the deep dive is what your programming mentor and team should read first.
Every team should use Git, even small teams. Reasons:
You can roll back when an auton change breaks everything 10 minutes before a match.
Multiple programmers can work in parallel without overwriting each other.
Code history becomes evidence in your engineering notebook.
The minimum useful workflow:
Create a private GitHub repo for your team's code.
Every programmer commits their changes at the end of every session, with a meaningful commit message.
Before competition, tag the working version (e.g., v1.0-statefair) so you can return to it.
Don't commit binaries or compiled output. Add a .gitignore for bin/ and similar.
4. Code Reviews
For every auton change, have a second team member read the diff before uploading to the brain. Catches typos, port confusions, sign errors.
For every new mechanism, have the strategist or a senior programmer review the design before implementing.
Code review is also EN4-friendly: judges love seeing review comments and team discussion in your notebook.
Print every sensor's live value to the V5 Brain screen.
Calibrate at every venue. Don't hard-code thresholds.
Always provide a manual override for sensor-dependent macros (in case the sensor fails mid-match).
6. Test Discipline
Run every auton routine at least 5 times back-to-back before a tournament. Consistency is what wins, not peak performance.
Test under tournament-equivalent conditions. Battery should be at the level you'd be using mid-tournament (i.e., not freshly charged). Lighting should match a real venue. Field tile should be reasonable.
Keep a regression list. Every time you fix a bug, write down what it was. Re-test the bug fix at the next session and after every major code change.
7. Engineering Notebook Integration
Every session, write down what you tested and the results. Numbers, not impressions.
Code commits should reference notebook entries (and vice versa). Reviewers can trace decisions.
8. Pre-Match Checklist Discipline
Per the sensor roadmap checklist: every match should follow the same power-on, sensor-test, auton-selection sequence. Discipline beats heroics.
The Single Most Important Principle
🎯
Reliability beats sophistication. A simple, well-tuned auton that works 95% of the time wins more matches than a vision-corrected, GPS-resetted, AI-classified auton that works 60% of the time. Build robust before you build clever. Most of the practices in this section are about making your robot boring — in the best way.