Objective

Understand whether this curriculum is aimed at you, what it assumes you already know, and what you will be able to do by the end of it.

This is not a beginner's course. It is the second course.

If you have never touched a V5 Brain, never written a line of C++, and never driven a robot in a competition, this curriculum will not meet you where you are. Start somewhere else — build a simple chassis, write a VEXcode program that makes it move, go to a local event, and come back.

If you are returning for a competitive season and the gap between where you are and where the top teams at your events are feels wide and undefined, this curriculum is for you. Our job is to take you from:

"I can make the robot move."

to:

"I can identify a competitive engineering problem, propose three solutions, choose one with a decision matrix, CAD it, build it, program it in C++ on PROS with LemLib, tune it, test it, document it in a rubric-aligned notebook, and win matches with it."

That is a long journey. It has five strands running in parallel: Coding, Building & Engineering, CAD, Project Management, and the Engineering Notebook. None of them are optional. The teams you are competing against at the top of the bracket treat all five as first-class.

📐 Engineering tip. You do not need to be a natural programmer. You do not need to be a natural builder. You need to be willing to work in explicit, dated, documented design cycles — and to let the curriculum tell you to go fix a build problem in the middle of a coding lesson when the two are linked.

What this curriculum assumes

• You have built a drivetrain before, even a bad one.
• You have written a VEXcode C++ program that reads a sensor and moves a motor.
• You have been to at least one competition.
• You have access to a team of at least two people. Some lessons are genuinely hard to do alone.
• You have access to a V5 Brain, motors, a controller, and enough metal and wheels to build one full robot.

What you will be able to do at the end

• Write, tune, and field a fully autonomous routine in C++ using PROS and LemLib, with odometry and state machine recovery.
• Build a drivetrain that is square, stiff, low-friction, and repeatable — and diagnose which of those four properties is failing when something goes wrong.
• Use OnShape to sketch, model, and assemble a robot before touching metal, including running a CAD-first design review.
• Run your team as a series of sprints with explicit design cycles, a PIL, and retrospectives.
• Write an engineering notebook that hits all ten criteria of the REC rubric with evidence, not filler.

What this curriculum will not give you

It will not give you a "winning robot for this year's game." Those designs go stale the moment the season changes. It will give you the skills to build one for any game.

It will not expose you to every possible motion-control algorithm or every CAD tool. We pick depth over breadth on purpose. A student who finishes this curriculum will understand PID in their bones; they will have seen Ramsete and Monte Carlo localisation only in outline.

It will not tell you that your ideas are good. It will make you test them.

Next up: The tech stack, and why we chose it. You need to understand the tools you are committing to before the first technical tutorial.

Objective

Understand the six tools this curriculum commits to, why each one was chosen, and why we do not teach alternatives alongside them.

Decisions propagate. Pick well once.

Every technical decision in a VRC season propagates. The CAD tool you pick decides whether a student can open your robot file from any browser at lunchtime without installing anything. The programming environment you pick decides whether two programmers can work on the same autonomous routine in the same week. The version-control habit you form in week one decides whether your November codebase is recoverable in March.

A curriculum that hedges — that says "here is how you do this in VEXcode, and also in PROS, and also in Robot Mesh" — is a curriculum that trains indecision. Students finish it having seen four tools and being fluent in none of them. We do not do that. We pick one stack and teach it deeply.

📐 Engineering tip. Depth beats breadth on a competitive team. A student who knows one motion library cold will out-ship a student who knows three motion libraries superficially — every single time.

The stack

Every one of these is used by real top-bracket teams. Every one of them is free for students. Every one of them runs on the hardware the average school already has.

Why not the alternatives

VEXcode. Single-file, single-author, single-session. You outgrow it the moment your program passes 300 lines or your team grows past one person. We migrate students off it in Chapter II Tier 1 and never look back.

Fusion 360 or SolidWorks. Both are excellent CAD tools. Neither has OnShape's real-time collaborative editing. When five students can edit the same document at once, the team runs CAD reviews three times as often as a team passing a .sldprt file around on a USB stick. That cadence advantage compounds.

JAR-Template or other home-grown motion libraries. These were important in their time and taught a generation of programmers how odometry works. LemLib is where the ecosystem is now. Pick one and go deep — we picked LemLib.

Google Docs for code. This sounds absurd until you see a team actually doing it mid-season because "it's easier." It is not easier. It is a trap. Code lives in Git, full stop.

💡 Coding tip. If your team is still emailing main.cpp around, freeze the next build session and make Git the only thing you set up that day. Every hour you spend unblocking the team from "who has the latest?" is an hour you could have spent tuning a PID.

A note on Shapr3D

Shapr3D is a geometry-based modelling tool with a touch-first interface that is genuinely interesting pedagogically. A future version of this curriculum may introduce it as an alternate CAD track. For now, OnShape is the only tool we teach, because every hour we spend hedging between CAD tools is an hour we do not spend teaching sketches-as-planning in the one tool we do commit to.

Independent exercise

Install three of the six tools today: Visual Studio Code, Git, and an OnShape account. Do not worry about PROS or LemLib yet — those get installed in Chapter II Tier 1 as part of the first real lesson. The purpose of this exercise is to remove "I haven't set up my laptop" as a reason to not start the actual curriculum.

Next up: The four doctrines. Before any technical tutorial, you need the four principles every technical decision will be evaluated against.

Objective

Learn the four principles every technical tutorial in this curriculum inherits, so that when a later lesson refers to "Doctrine 2" you already know what it means.

Concept

A doctrine is a principle that is not optional. It is something the curriculum has decided is true, and every technical lesson downstream of it assumes you agree. You will see these four cited by name throughout the rest of the strands. When a tutorial says "refer back to Doctrine 2," it is not optional reading — it is the reason the lesson is structured the way it is.

Read these now. You will re-read them whenever a diagnostic lesson points you back to them.

Doctrine 1 — Prototype before you CAD. CAD before you build. Build the frame first.

Mechanical work has an order of operations. Skipping any step forces you to rework everything downstream of it.

• Prototype uncovers the problems your imagination cannot. A roller that looks perfect in your head will dead-zone with a real game object in your hand. There is no substitute.
• CAD uncovers the problems the prototype did not. Interference between subsystems, the gear ratio you cannot actually fit inside the sizing box, the pneumatic pivot whose geometry will not complete its arc.
• Build the frame first uncovers the alignment problems that would have cost you an entire season of friction if you had started filling in subsystems on an unsquared chassis. Every square drivetrain in the top bracket started as a frame that was measured, squared, and verified before any mechanism touched it.

The teams that ship broken robots to events skipped one of these three. The teams that do not, did not.

🔧 Build tip. Prototyping is not "making a small version of the real thing." It is cardboard, hot glue, and a zip-tie test at full scale in twenty minutes. You do not need the geometry to be pretty — you need it to survive contact with an actual game object and tell you what you got wrong.

Doctrine 2 — Readings vs. Robot vs. Ground

There are three layers of truth on a robot. Problems live at exactly one of them. Diagnosing at the wrong layer wastes weeks.

• Readings ↔ Robot. Does what the sensor reports match what the robot actually did? If your odometry says the robot moved 24 inches and you measure with a tape and it moved 24 inches, this layer is fine. If they disagree, this is a calibration or unit-conversion problem. This is a code problem.
• Robot ↔ Ground. Does what the robot actually did match what the field saw? If the robot moved 24 inches but ended up 2 inches off its target, this is a mechanics problem — wheel slip, drift, friction, bent axle, loose motor mount. This is a build problem.
• Readings ↔ Ground. An illusion. You cannot fix this layer directly. You fix it by fixing the two layers above.

The first skill of a competitive programmer is knowing which layer is lying to them before they open their IDE. When a later tutorial tells you "this is a Readings–Robot problem, not a Robot–Ground problem," it is telling you which layer to look at — because the student who fixes the wrong layer wastes an afternoon.

💡 Coding tip. Before you tune a PID, ask: are the readings wrong, or is the robot wrong? Tuning gains against a drivetrain that is racking under load is tuning a feedback loop against a lie. The PID cannot win.

Doctrine 3 — Sandwich everything. Brace everything. Box everything. Don't overbrace anything.

Friction eats matches. Slop eats matches. A cantilevered axle bends under load, a non-boxed C-channel twists under torque, an off-centre screw propagates misalignment through every mechanism it touches. The top builders sandwich their loads between two supports, brace their long runs, and box their C-channels into torsional boxes the moment torque becomes a factor.

But: overbracing adds weight, adds cost, and — most importantly — hides the fact that your design was bad. A well-designed mechanism needs the right amount of bracing in the right places. A badly-designed mechanism needs to be redesigned, not wrapped in extra metal. The craft is knowing exactly how much is enough and where.

The Chapter III tutorials on bracing and boxing teach this in detail. For now, memorise the slogan:

🔧 Build tip. Sandwich, brace, box — but not more. If you cannot explain why a particular brace is carrying a particular load, you do not need the brace; you need a different design.

Doctrine 4 — Iterate by design cycles, not by vibes

A competitive season is not one build. It is five or more. Each cycle starts with a problem you identified, a brainstorm you ran, a decision matrix you filled in, a CAD you sketched, a build you made, a test you measured, and a reflection you wrote down — and the reflection feeds directly into the next cycle's problem statement.

A team that runs explicit, dated, documented design cycles beats a team that runs on vibes, even if the vibes team has better builders on paper. The reason is compounding: a team on cycle five in January has already solved and moved past four problems that the vibes team is still debating. The documentation is not for the judges. The documentation is for the team itself — so that the problem solved in cycle two does not quietly reappear in cycle four.

This is why Chapter V (Project Management) and Chapter VI (Engineering Notebook) are full peers of the technical strands, not afterthoughts. The cycle is the mechanism by which technical work actually compounds.

⚡ Competition tip. The single strongest predictor of which team ends up on the finals stage in March is not which team had the best week-one robot. It is which team is on cycle five by January. Compounding beats headstart.

Independent exercise

Pick one thing your current robot does badly. Assign it to exactly one doctrine. Which doctrine was violated? Be specific.

• A frame that racks under load is a violation of Doctrine 3 (bracing) upstream of a violation of Doctrine 1 (build the frame first).
• A lateral PID that cannot settle is a violation of Doctrine 2 — you cannot tune a lateral PID on an unsquared drivetrain. The Readings layer is being asked to compensate for a Robot–Ground problem.

Write the diagnosis in one paragraph in your notebook.

Next up: The seven non-negotiables. The authoring rules the curriculum itself agrees to follow — so you know exactly what you are getting from every tutorial.

Objective

Understand the seven authoring rules this curriculum agrees to, so you know what to expect from every tutorial you read — and what to expect us to never do.

Concept

These are not rules for the student. They are rules for the curriculum author — the contract this material agrees to honour in every tutorial it produces. You are reading them because it is fair for you to know, and because several of them will affect how you use the material.

1. No season or game is named

You will never see "Push Back," "High Stakes," "Over Under," "Spin Up," "Tipping Point," or any other specific VRC game mentioned in a student-facing lesson. Problems are framed generically. Sizing constraints are "your current season's maximum robot footprint." Game objects are "the pieces you are asked to score." Field elements are "the structures your robot interacts with."

This is deliberate and it is permanent. A curriculum that teaches "how to win this year" goes stale on the day the new game is announced. A curriculum that teaches skills goes stale never.

It also means: you will have to translate. When a lesson says "sketch the game object," you look at your current game manual and decide what the game object is. That translation step is part of the skill being taught.

2. Physics lives where it is used

There is no standalone physics module. You will not find a lesson titled "Physics of Gears." You will find gear ratio physics taught the first time the curriculum asks you to decide between a high-speed and a high-torque drivetrain, because that is the first time the physics actually affects a decision you are making. You will find friction physics taught the first time you audit a drivetrain for drag, because that is the first time the heat-and-motor-damage consequences matter. You will find pneumatics geometry taught the first time you need to decide whether a piston's stroke length can actually complete your arm's arc.

The trade-off: if you want to read all the physics in one place, you cannot. The benefit: you remember the physics, because every time you learned some of it, it came with a robot consequence.

📐 Engineering tip. Physics-in-situ is the single most important pedagogical decision in this curriculum. It is the reason students come out of it able to reason about new problems, not just recite facts about old ones.

3. One stack, no hedging

C++, Visual Studio Code, PROS, LemLib, OnShape, Git. No alternatives will be presented. If you come in with a preference for VEXcode or Fusion 360 or a different motion library, the curriculum will ask you to switch. This is not because the alternatives are bad; it is because splitting attention across two tools halves the depth at which you learn either one.

4. Every tutorial closes a loop

Every tutorial has the same five-section structure: Objective → Concept → Guided practice → Independent exercise → Reflection prompt. You know what you are supposed to learn, you learn it, you watch it demonstrated, you do it yourself, and you write down what happened. If any of those five are missing, treat the tutorial as incomplete and tell the author.

5. Every reflection prompt is notebook-ready

The reflection at the end of every tutorial is written so that you can transcribe it directly into your engineering notebook. You will not have to translate or reframe it. This is how the technical strands feed the notebook strand without being redundant work.

6. Every tutorial has explicit prerequisites

If a lesson depends on another lesson — in the same strand or in a different one — that dependency is named at the top of the file. When you see "Prerequisites: Strand 2 L2.4," treat it as a hard dependency. Tutorials assume their prerequisites are complete, and diagnostic chains will fail if you try to skip.

7. Source notebooks are never cited to students

The curriculum author read a substantial archive of real team engineering notebooks as research — PIL frameworks, build iteration logs, Innovate Award submissions, programming write-ups. You will never see a specific notebook referenced by team number in a student-facing tutorial. You will see the principle, not the exemplar. This is because the notebooks belong to the teams that wrote them, and because the best teaching material abstracts the pattern rather than pointing at the example.

What this means for you: when a tutorial says "a strong PIL entry looks like this," the example was written from scratch by the curriculum author to demonstrate the pattern. You can trust that the pattern is real because the pattern came from real notebooks — but you will not find "936A did it this way."

Independent exercise

Pick any tutorial you have seen so far (including the welcome tutorial you just read). Check it against the seven rules above. Does it name a specific game? Does it keep physics in situ? Does it follow the five-section structure? Does it list prerequisites? Does it cite a specific source notebook?

If you find any violation, note it. The author wants to know.

Next up: How to use this curriculum — the order to run the strands in, how to treat cross-strand dependencies, and what a typical week looks like.

Objective

Know the order to run the five strands in, how to treat cross-strand dependencies, and what a typical week looks like once you are working through the material.

Do not read this linearly. It is not a book.

This curriculum is five strands that run in parallel, and the dependencies between them are explicit. Trying to read it end-to-end like a textbook is the single fastest way to lose a month.

The first week

Your first week has a specific order:

1. Read all six sections of Chapter I (you are doing that now).
2. Go to Chapter V (Project Management) and run PM.1 through PM.4. This sets up your season: sprint structure, stand-up ritual, retrospective cadence, and most importantly the Problem Identification Log. Every technical strand assumes you are running a PIL. If you are not, the other strands have nowhere to record the problems they surface.
3. Go to Chapter VI (Engineering Notebook) and run N1.1 through N1.4. This sets up your notebook container. By the end of N1.4 your notebook is ready to receive its first technical entry.
4. Open Chapter II (Coding) at Tier 0 or Tier 1. If your team already has a working VEXcode program, skip Tier 0 and go straight to L1.1. Install PROS and LemLib by the end of the week.
5. Open Chapter III (Building) at Tier 1. Start the prototype-first mindset. This tier teaches how to use sketches and cardboard to answer questions before touching metal.
6. Open Chapter IV (CAD) at Tier 0. Get every team member into OnShape and make sure your team document is set up.

By the end of week one, every student on the team should have: a PIL with at least one entry, a set-up engineering notebook, a local PROS project, a build-log page, and an OnShape account in the team organisation.

The running rhythm

After week one, you are in the running phase. A typical week looks like:

• Monday: Sprint planning (PM.6). Decide what problems from the PIL will be worked on this week. Distribute to strand owners.
• Tuesday through Friday: Technical work in strands 1–3. Stand-ups happen every working session (PM.7). Notebook entries are written the day the work happens (N3 series).
• Saturday or end of week: Sprint retrospective (PM.9). What moved, what stalled, what goes into next week's PIL.

Each strand has internal lessons that you pull in as your team reaches them. You do not pre-schedule every lesson. You schedule the next lesson when the team needs it.

Cross-strand dependencies are instructions, not suggestions

Several lessons have explicit prerequisites in another strand. For example:

• Chapter II L3.3 (lateral PID tuning) depends on Chapter III L2.1 (frame first) and L2.2 (squaring the frame). If your drivetrain is not yet square, do not start L3.3. You will waste days trying to tune a PID against a frame that is lying to you.
• Chapter II L4.4 (tracking wheels) depends on Chapter III L3.2 (screw theory) and L3.5 (boxing). A tracking-wheel mount that is wobbly is a sensor that lies.
• Chapter II L2.3 (inertial sensor) depends on Chapter III L5.1 (electronics placement). An IMU bolted to a flexible panel will give you heading values that drift whenever the robot accelerates.
• Chapter IV L1.4 (sketching pneumatic geometry) depends on Chapter III L4.5 (pneumatics physics). You cannot CAD a pneumatic mechanism without knowing why the piston stroke, the pivot distance, and the arm length are geometrically interdependent.

When a tutorial says "prerequisites," treat the cross-strand ones exactly like the same-strand ones. Go do the upstream lesson first.

⚡ Competition tip. The teams that show up at events with PID-tuned autonomous routines that work reliably are not the ones who tuned harder. They are the ones whose drivetrain was square before the tuning started. Cross-strand dependencies are where the real compounding happens.

When to skip

You may skip:

• Tier 0 in any strand if your team has the prerequisite knowledge. Tier 0 is a refresh tier for returning students who have not touched the material in a while.
• Stretch lessons (explicitly flagged — e.g. Chapter II L5.6–L5.8 on motion profiling, Bézier paths, and MCL). These are for teams that have mastered everything else and have remaining bandwidth. Most teams do not reach them.

You may NOT skip:

• Any physics block lesson in Chapter III. These carry the consequences-first reasoning. Skipping them produces teams that pick gear ratios based on what the captain's favourite team did, and then burn out motors in week eight.
• The project-management flagship lessons (PM.4 — PIL, PM.10 — cross-strand dependency map, PM.11 — cadence). Without these, the strands drift out of sync and you wake up in February with a tuned PID on a frame that was rebuilt in January.
• Any lesson another lesson explicitly depends on. Prerequisite chains exist because the author watched students fail when they tried to skip.

How long does it take

Honest answer: the full curriculum takes a motivated team the better part of a competitive season to work through end-to-end. You will not finish it in a month. You should not try. The point is to internalise the loops — design cycle, notebook entry, strand handoff — not to check off 120 tutorials as fast as possible.

A team that runs Tier 1 of each strand in parallel, does two sprints worth of PM rituals, and produces ten real notebook entries in the first month is on track.

Independent exercise

Draw a diagram of your own first week using the ordering above. Put names next to each task — who on the team is reading Chapter II, who is reading Chapter III, who owns setting up the PIL. By the end of the week, everyone should have touched every strand at least once, but specific ownership makes sure no strand gets skipped.

Next up: What this curriculum is not. The explicit limits of what you are signing up for — so you calibrate your expectations now instead of being surprised later.

Objective

Know what this curriculum is explicitly not, so that you do not come to it expecting something it is not trying to be.

Concept

It is useful, maybe even honest, to be clear about what a piece of teaching material is not. This curriculum has specific limits, and you will save time by understanding them now.

It is not a "how to win this year's game" guide

Every VRC season has guides that teach you the optimal scoring strategy for the current game. Those guides are valuable in their time and worthless the day the next game is announced. This curriculum deliberately contains zero of that content. You will not find a section on how to rank in driver skills for the current season, or which mechanism wins the most matches at a regional this month, or which alliance-selection strategy is optimal for the current field layout.

What you get instead: the skills that let you figure out those answers for any game. If you can read a field spec, identify the engineering problems it creates, sketch three mechanism options, decision-matrix them, prototype the winner, CAD it, build it, program it, tune it, test it, and reflect on it — you can do that for the current game, the next one, and the one after that.

It is not a VEXcode tutorial

We assume you came in already knowing what a motor is, what a while loop is, what a controller button reads, and roughly how to string those together into a functioning VEXcode program. The curriculum's first technical lesson is "leave VEXcode." If that first step does not make sense to you — if you do not yet have a working VEXcode program to leave behind — you are not the audience for this curriculum yet. Come back when you do.

It is not a beginners' course

A beginner needs a different pedagogy than this. Beginners need scaffolding, low-stakes exploration, and the patience to get a single motor spinning before anything else happens. This curriculum assumes all of that is already in your background. It moves fast because it is the second course, not the first one.

📐 Engineering tip. If you are a mentor weighing this curriculum for a brand-new team, do not hand it to them. Hand them a beginners' course for their first season and hand them this one on the first day of their second.

It is not exhaustive

We pick depth over breadth on purpose. A student who finishes this curriculum will:

• Know PID in their bones — theory, tuning order, diagnostic chain, the three layers of truth. They will not have seen every possible control algorithm, and some of the ones they have seen (Bézier curves, Ramsete, Monte Carlo localisation) will be sketched in outline rather than mastered.
• Know OnShape well enough to plan, model, assemble, drawing-export, and design-review a full robot. They will not have been taught a second CAD tool.
• Know the VRC metal and plastic fabrication vocabulary cold — C-channels, standoffs, shaft collars, the screw theory, the bracing rules, the friction audit. They will not have learned TIG welding or machine-shop milling.
• Know how to write a notebook entry against every criterion on the REC rubric. They will not have written one for any other evaluation framework.

If you need breadth — if your goal is to survey the whole field of robotics and pick where to specialise — this is the wrong curriculum. Pick a breadth course first and come back later.

It is not a substitute for a mentor

A student working through this alone will make it most of the way, but not all the way. There are judgment calls that a good mentor catches in ten seconds and that a solo student will not notice for a month: "your drivetrain is not actually square, look at this gap," or "your PIL entries are all identifying the symptom and not the root cause," or "you are about to over-gear for a motor that cannot take that current under match load."

If you have a mentor, this curriculum gives both of you a shared vocabulary and a shared reading order. If you do not have one, the curriculum will still work, but you should be extra rigorous with the reflection prompts and the rubric self-checks — they exist specifically to catch the things a solo student misses.

It is not finished

This is a v0 curriculum. It has gaps. The curriculum author has flagged every tutorial that was written from scratch without a strong source behind it, and those are the ones most likely to need revision after you work through them. If something does not work, that is valuable information — the author wants to hear about it.

Coming up next

You have finished orientation. The curriculum now fans out into five parallel strands. Before you start any of the technical strands, set up your season's project management.

• Go to Chapter V — Project Management and run PM.1 through PM.4. You need a Problem Identification Log before the technical strands will have anywhere to record problems.
• Then go to Chapter VI — Engineering Notebook and run N1.1 through N1.4 to set up your notebook container.
• Then open Chapter II — Coding, Chapter III — Building & Engineering, and Chapter IV — CAD in parallel. They run together, not sequentially.