Acknowledgments: The Teams That Made This Possible
This course was not built alone. It draws on years of open-source code, publicly shared knowledge, and community generosity from some of the best engineering minds in FRC. Before the technical work begins, we name them — and explain what you owe them.
By the end of this lesson, you will:
- Know which teams and individuals contributed most to the knowledge base this course draws from
- Understand why elite FRC teams choose to open-source their competition code
- Know where to find the original work that informs each major unit of this course
- Understand what "paying it forward" looks like at the student level — and why it matters
A Personal Note
I have been programming FRC robots for a long time. I am a mentor, a community volunteer, and someone who has sat in a pit at midnight trying to figure out why a swerve module was drifting. None of the knowledge in this course is mine alone — most of it was learned by reading other people's code, asking questions on Chief Delphi, and being lucky enough to be mentored by people who were generous with their time.
The FRC programming community has a culture of sharing that is genuinely unusual. The teams at the top of the game — the ones who win World Championships — post their entire robot codebase publicly at the end of every season. Not because they have to. Because they believe the rising tide lifts all boats, and because they remember what it was like to be a student programmer staring at a blank Robot.java file.
"The best teams in FRC got there because someone shared code with them. Paying that forward is part of how you earn the right to call yourself part of this community."
This lesson is the course's way of saying thank you — and setting the expectation that you will eventually do the same.
Why Elite Teams Share Their Code
If sharing your robot code helps your competition, why do the best teams do it? Because the calculation is different than it looks.
When every team has access to quality patterns and examples, regional competition improves across the board. Better events make FRC more visible, attract more sponsors, and sustain the program that elite teams also depend on.
Posting your code publicly creates a feedback loop. When thousands of engineers can read your subsystems and commands, you write better code — knowing it will be read holds you to a higher standard than internal review alone.
Team 254 shares code, Team 6328 reads it and builds on it, publishes AdvantageKit, and 254 integrates AdvantageKit. The knowledge is circular. Teams that contribute get to draw from a pool that grows larger every year than anything they could build alone.
Open-sourcing code doesn't give away your real competitive advantage — your drive team's skill, your shop's ability to build precision mechanisms, your strategy, your scouting system, and the thousand hours of practice your students put in. Code is necessary but not sufficient. The teams who win consistently win because of everything code enables, not because they have code that nobody else can read.
The Teams and Contributors
Click any card to see what this team contributed to FRC knowledge and where their work appears in this course.
👇 Click a card to expand itThe home team for this curriculum. Team 2910 is a multiple World Championship finalist and consistent Championship-level competitor. Their robot code — particularly their swerve drive implementation, Command-Based architecture, and AdvantageKit integration — forms the direct foundation of this course's examples and philosophy.
The "systems-first" approach woven through every lesson reflects how 2910's programming mentors train students: you don't write motor control code without understanding what the motor is attached to and what it's trying to accomplish.
Appears in: Units 5, 6, 7, 8, 11, 12The most decorated team in FRC history. Team 254 pioneered the superstructure patterns, state machine architectures, and autonomous reliability techniques that every serious FRC team now draws from. Their annual code releases — available on GitHub after each season — have shaped what "production-quality" FRC code looks like.
Many of the control theory concepts in Unit 8 were developed and refined by 254's mentors, several of whom have gone on to careers in robotics, autonomous vehicles, and spacecraft engineering.
Appears in: Units 6, 7, 8, 9, 11Creators of AdvantageKit, AdvantageScope, and the deterministic logging and simulation-first development approach that Unit 11 is built on. Team 6328 has done more to advance the software engineering discipline within FRC than any other team in the modern era.
Their open technical blog posts, GitHub repositories, and presentations at events like FRC Conference have made sophisticated software architecture accessible to teams at every level. If you've ever wanted to know what your robot was doing three seconds before it crashed, that capability exists because of 6328.
Appears in: Units 6, 9, 10, 11, 12The WPILib contributors — led by WPI but including dozens of community members — maintain the library that makes FRC Java programming possible in the first place. They do this for free, as volunteers, while holding down jobs and careers. Every year they update WPILib for the new season, fix bugs, add simulation tools, and respond to GitHub issues from teams around the world.
The WPILib documentation is one of the best technical resources in all of amateur robotics. The people who write it care deeply about student education, and it shows. This course cites it constantly and would not exist without it.
Appears in: Every unitPathPlanner was created and is maintained by a single developer — an FRC alumnus — who built the autonomous path planning tool that has become the de facto standard for FRC. Before PathPlanner, creating and integrating smooth autonomous paths required significant custom math. After PathPlanner, it became accessible to any team willing to read the documentation.
The PathPlanner GUI, the Java library, and the constraint tuning workflow covered in Unit 9 are entirely his work. The FRC community owes him an enormous amount, and he accepts GitHub issues graciously.
Appears in: Unit 9PhotonVision is a free, open-source vision processing platform built specifically for FRC. Before it existed, teams who wanted AprilTag detection and pose estimation had to build their own pipelines on top of OpenCV — a significant barrier for most teams. PhotonVision made that capability available to every team, regardless of budget or computer vision experience.
The PhotonVision team actively engages with the FRC community, maintains excellent documentation, and responds to GitHub issues throughout the build season. Unit 10's vision and localization content is built on their work.
Appears in: Unit 10Cross The Road Electronics produces the TalonFX motor controller, CANcoder, and Pigeon 2 IMU — the hardware backbone of many Championship-level drivetrains. Their engineers are active on Chief Delphi, responsive on GitHub, and have consistently improved their API with FRC programmer feedback.
Phoenix 6 represents a major improvement over Phoenix 5 in terms of API clarity and Signal API design. CTRE's Phoenix Tuner X tool and their technical documentation are used throughout Units 5, 7, 8, and 12.
Appears in: Units 2, 5, 7, 8, 11, 12REV Robotics produces the SparkMax and SparkFlex motor controllers, the NEO and NEO Vortex brushless motors, and the Through Bore Encoder. Their hardware is widely used for mechanism motors across FRC, and their REVLib Java API and REV Hardware Client are used throughout this course.
REV's education resources and their willingness to work directly with FRC teams on technical questions have made their hardware more accessible than it might otherwise be. Their engineering team actively engages with the FRC community on Chief Delphi.
Appears in: Units 2, 5, 8, 11, 12Chief Delphi has been running since 2003. The accumulated knowledge on that forum — the threads about brownout prevention, the discussions of swerve kinematics, the mentor-to-mentor technical debates — represents an irreplaceable archive of how FRC programming has evolved over two decades.
Several specific threads on Chief Delphi directly informed lessons in this course. The community of mentors, alumni, and vendors who answer questions there generously and without compensation are a foundational part of what makes FRC programming learnable by students who don't have full-time robotics engineers in the room.
Referenced in: Units 0, 5, 6, 7, 8, 9You Are Part of This Chain
Every programmer who has benefited from this community was once exactly where you are — starting from scratch, not knowing the difference between a periodic function and a lifecycle method, wondering why their motor wasn't responding. Most of them went on to contribute something back: a forum post that answered someone else's question, a well-documented subsystem in a public repo, a piece of documentation that made a concept click for a student they never met.
This course is part of that chain. Here is what "paying it forward" looks like at your level, right now:
Meaningful variable names, honest comments, consistent formatting. Code that future teammates — and future you — can maintain without calling you on the phone. This is the minimum bar, and it matters more than any advanced technique.
On Chief Delphi, on your team's Discord, or in person to a newer student on your subteam. The knowledge you have right now — even if it feels basic — is knowledge someone else doesn't have yet.
At the end of each season, ask your team's leadership about publishing your robot code on GitHub. Not every team is ready to do this — there are legitimate reasons to wait. But if you can, do it. Someone will learn from it.
WPILib, PhotonVision, PathPlanner, and vendor libraries are maintained by volunteers. If you find a bug and file a clear, reproducible report with a minimal example, you've contributed to a tool that thousands of teams rely on. That's not a small thing.
The most effective way to solidify your own understanding is to teach it. When a new student joins your programming subteam next season, offer to walk them through the code. You'll be surprised how much you learn in the process.
🔌 System Check
Unit 1 was orientation. Unit 2 is where Java syntax begins. Before your first lesson in Unit 2, confirm the following:
- Your development environment is intact. WPILib VS Code opens, your Unit 0 project builds, and
java -versionreports OpenJDK 17 in the WPILib terminal. - You have a study plan from Unit 1, Lesson 1. You wrote down where you're starting from and what you want to build. If you didn't, do it now — five minutes before Unit 2 is better than never.
- You've starred or bookmarked the repositories above. Team 2910, 6328, and 254's GitHub pages. You won't need them for Unit 2, but you'll want them close when Unit 6 starts.
- You've joined the WPILib Discord. Unit 2 is where your first real questions will appear. The #java-programming channel has patient, experienced people who will help — as long as you ask good questions (Unit 0, Lesson 5).
Knowledge Check
Click an answer to check your understanding.
Trace the Chain
This prompt asks you to find the original sources — not descriptions of them.
- Open GitHub and navigate to the most recent public robot repository from Team 6328. Find the file that contains their drivetrain subsystem. What are the first three imports at the top of that file? Write them down — you'll see them again in Unit 7.
- Open the WPILib Javadoc (from Unit 0, Lesson 5 resources). Search for
TimedRobot. Read the class-level documentation comment at the top of the page. In your own words, what does it say this class provides that isn't in the documentation forIterativeRobotBase? - Find one Chief Delphi thread that has been referenced or replied to by a member of the WPILib team or a vendor engineer (CTRE or REV). Read the full thread. What was the question, and how did the expert's answer differ from the other responses in the thread?
- Look at your team's existing robot code (if your team has any). Is it publicly visible on GitHub? If not — is it private, or does the repository not exist? Write down one thing you would want to document or clean up in that code before making it public. If your team has no code yet, use Team 2910's most recent repo and write down one thing you'd want to understand before contributing to a codebase like that.
- Optional but meaningful: Write a two-sentence thank-you message — not a post, just for yourself — to one of the contributors listed in this lesson. The exercise of writing it, even if you never send it, forces you to articulate what specifically they contributed and why it matters to your learning. Keep it. Read it again when Unit 11 is hard.