Unit 1: Introduction
Unit 1 · Lesson 1
Welcome & Course Overview
You made it through setup. Now the actual work begins — and it's going to be more interesting, more frustrating, and more rewarding than you expect. Here's what this course is, what it isn't, and exactly where we're going.
By the end of this lesson, you will:
- Understand what makes FRC programming different from general software development
- Know the three principles this course is built on
- See the full course arc across all 13 units and understand why they're ordered the way they are
- Identify your starting point and know which units to focus on first
- Set a concrete, realistic goal for what you'll be able to build by the end of this course
Before We Start
I built this course because I've spent years watching capable, curious students get stuck — not because the concepts were too hard, but because nobody connected the code to the robot. They could write a loop, but had no idea why the loop period mattered to a motor. They could read a PID equation, but had never watched an arm oscillate because the gains were wrong.
This course is my attempt to fix that. Every lesson connects what you type to what physically happens on the robot. We'll talk about chains and gearboxes and CAN bus utilization alongside variables and method signatures — because in FRC, they are inseparable.
"Code cannot fix a broken gear. But code written without understanding the gear will break things that weren't broken."
— The guiding philosophy of this courseYou don't need to be an expert programmer to start. You need to be willing to build things, break things, figure out why they broke, and build them again. That's it. The rest follows.
What Makes FRC Programming Different
If you've learned to code before — in a class, through a tutorial, on your own — you already know something valuable. But FRC programming has constraints that most software courses never prepare you for.
- Your code controls physical hardware. A bug doesn't produce a wrong number on a screen — it can snap a chain, trip a breaker, or injure someone. The stakes are real and the feedback is immediate.
- You're working in a team. Multiple people touch the same codebase, and standards matter. Code that only the person who wrote it can understand is a liability, not an asset.
- You have a hard deadline. Kickoff is in January. The regional is in March. The code has to work on a specific robot, on a specific field, on a specific day — not eventually.
- Your development environment is the robot. You can't unit test a swerve module without a swerve module. You can't tune a PID controller without a mechanism to tune it on. Simulation helps, but physical iteration is unavoidable.
- The hardware changes every year. A new game, new field elements, new constraints. The skills you build here compound — but the specific implementations get rebuilt from scratch each season.
💡 This course is FRC-first
We teach Java not because it's the best language in the abstract, but because it's what WPILib uses and what the FRC community has converged on. Every concept we cover is explained in terms of how it applies to a robot. If you want to understand Java more broadly after this, the WPILib community has created a genuinely excellent foundation to build from.
Three Principles This Course Is Built On
👇 Click each card to understand what it means in practiceSystems-First
tap to learn what this means
What this means
We never explain a software concept without tracing it to the physical hardware it controls. When we learn about PID controllers, we're talking about an arm. When we learn about current limiting, we're talking about a chain that can snap. Code exists in context — we treat it that way.
Hardware-Aware
tap to learn what this means
What this means
Every lesson includes a System Check: what hardware and electrical state your code actually needs to function. Before you run a PID loop, is your encoder plugged in? Before you enable, is your battery charged? Good programmers check the whole stack — not just their code.
Team-Standard
tap to learn what this means
What this means
We teach the conventions, documentation habits, and code review practices that let a team of five programmers work on the same codebase without chaos. Being a good teammate is as important as being a good coder — this course treats both as skills worth developing deliberately.
The Full Course — Where We're Going
This course spans 13 units, from environment setup to competition readiness. The order is intentional: each unit builds on the one before it. Click any unit below to see what it covers and why it sits where it does in the sequence.
👇 Click any unit to preview what's inside
Unit 0
Setup & Environment
Unit 1 ← you are here
Introduction
Unit 2
Java Basics
Unit 3
Git & Version Control
Unit 4
Object-Oriented Programming
Unit 5
Basic FRC Coding
Unit 6
Command-Based Programming
Unit 7
Drivetrains & Swerve
Unit 8
Control Theory
Unit 9
Autonomous & Path Following
Unit 10
Vision & Localization
Unit 11
Advanced Architecture
Unit 12
Competition Readiness
Unit 13
Looking Ahead
← click a unit to preview it
🔍 Why this order?
Units 2–4 build the Java and engineering foundations you need before touching robot-specific APIs. Unit 5 is where code first moves a motor. Units 6–7 are where the architecture becomes professional. Units 8–10 are the advanced systems that separate competitive teams from the rest. Units 11–12 are what gets you to the championship field. You can't shortcut this sequence — each unit assumes fluency with the one before it.
Find Your Starting Point
This course is designed for programmers at any level — from students who have never written a line of code to experienced developers new to FRC. Click the profile that best describes you to get tailored guidance on how to approach the course.
New to programming
I have little or no coding experience
Welcome — you're in exactly the right place. This course starts from the ground up in Unit 2. Don't skip the Java basics because you're eager to get to robot code. The students who try to jump to Unit 5 without Unit 2 are the ones who get stuck in Unit 6 and can't figure out why.
Your path: Follow every unit in order. Don't rush. When a concept doesn't click the first time, that's normal — revisit the lesson, look at the linked resources, and ask in the community. Every professional programmer you've ever heard of learned this way.
- Give yourself extra time on Unit 2 (Java Basics) and Unit 4 (OOP)
- Do every Practice Prompt — these are where the real learning happens
- Find one more experienced programmer on your team to pair with, even informally
Know Java, new to FRC
I've coded before but never touched robot programming
Your Java fluency is a genuine advantage in Units 2–4 — those will feel like review. The material that will challenge you is in Units 5 onward, where the abstractions are robot-specific and the feedback is physical rather than textual.
Your path: Skim Units 2–4 for anything FRC-specific (there's more than you'd expect), then slow down at Unit 5. The hardest transition for experienced programmers is learning to think about hardware constraints alongside software logic — be patient with that shift.
- Read the System Check sections carefully — these are the hardware context you're missing
- Don't assume familiar patterns transfer directly; always check how WPILib does it
- Unit 6 (Command-Based) will likely be the most useful unit for you relative to time invested
Experienced FRC programmer
I've shipped robot code before — I'm here to fill gaps
This course will still have things for you — particularly in Units 8, 10, 11, and 12, which cover control theory, vision, simulation, and competition diagnostics at a depth most FRC resources skip. Use the unit overview (above) to find where your current knowledge has gaps and start there.
Your path: Jump to the units most relevant to your current season goals. If your team is struggling with autonomous reliability, go to Unit 9. If you've never implemented simulation, go to Unit 11. The lessons are designed to be self-contained enough for this approach to work.
- The Event Observation callout boxes contain competition and pit wisdom you may not have seen formalized before
- Unit 11 (AdvantageKit, simulation, IO layer) tends to be where experienced programmers find the most new ground
- Consider using the Practice Prompts as mentorship exercises to run with newer programmers on your team
Mentor or coach
I'm using this resource to support students on my team
This course is structured to work as a self-paced resource for students, but it's also designed to be used alongside mentoring. Each lesson's Practice Prompt is built to be either completed independently or reviewed in a session with a mentor. The quiz questions are calibrated to reveal the most common conceptual gaps — use them diagnostically.
Suggestions for team use:
- Assign units as prerequisites before giving students access to real robot hardware
- Use the "Good Question Checklist" from Unit 0, Lesson 5 before students post in external forums or ask you questions — it saves everyone time
- The System Check sections make excellent pre-work for your first build season hardware meeting
- Unit 12 (Competition Readiness) is worth reviewing with the whole programming subteam before your first event
What to Expect from This Course
A few honest things before you go further:
You will get stuck. Not because you're not good enough — because robotics programming is genuinely hard, and that's normal. The measure of a programmer isn't whether they get stuck; it's how fast they get unstuck. This course will teach you both the concepts and the debugging approach.
The pace is yours. Some students will finish Unit 2 in a weekend. Others will take two weeks. There's no right answer except finishing with actual understanding rather than surface familiarity. Surface familiarity is extremely visible at competition. Deep understanding is what keeps robots running.
The Practice Prompts are not optional. Reading is passive. Building something — even something small that doesn't work yet — is where retention happens. Every Practice Prompt is designed to take 30–60 minutes and produce something you can show to a teammate or mentor.
🔍 A note on "good enough"
In FRC, "good enough to pass inspection" and "good enough to win a regional" are very different bars. This course aims for the second one. That means we'll cover things that feel unnecessary until they're suddenly critical — like current limiting, or loop timing, or what happens to your PID controller when the battery sags under load. Those details are what separate robots that win from robots that lose in the finals.
Knowledge Check
Click an answer to check your understanding.
A student finishes reading Unit 5 and can write motor control code — but doesn't understand current limiting or CAN bus utilization. According to this course's philosophy, what is the problem with their learning?
The course teaches Command-Based programming in Unit 6, after TimedRobot in Unit 5. Why is it ordered this way rather than starting with Command-Based?
Which of the following best describes what "Team-Standard" means as a course principle?
💪 Practice Prompt
Set Your Intention
This is the only Practice Prompt in the course with no technical deliverable. Its output is a written document — two paragraphs and a list — that you'll revisit at the end of each unit.
- Where are you starting from? Write two to three sentences describing your current programming experience honestly. Not what you wish it were — what it actually is. What have you built before? What concepts feel shaky? What are you most nervous about?
- What do you want to be able to do? By the end of this course, what specific thing do you want to have built or understood? "Write better code" is not specific enough. "Implement a working swerve drive and tune it well enough that our drivers are happy with it" is specific. Write one sentence that specific.
- Click through every unit in the course roadmap above. Find the three units you're most curious about and write down why. Find the one you're most nervous about and write down what specifically worries you.
- Share it. Show this document to one person — a mentor, a teammate, a parent, anyone. Saying your goal out loud to another person changes how seriously you pursue it. This is not a soft suggestion.