Programming

Today, we’re going to learn how to program a robot.

By the time we’re finished, you’ll have the Malfunctionz code on your computer, you’ll be able to change it, build it, put it on the robot, test it, and send your changes back to the team.

That’s a lot.

Let’s go.

Step 1: Get the Tools

FRC robots use a collection of programming tools called WPILib.

WPILib gives us:

  • VS Code for writing our code
  • Java and the tools needed to compile it
  • FRC-specific libraries
  • Tools for connecting to and programming the robot
  • Everything we need to build and deploy an FRC robot project

So that’s where we’re going to start.

Install WPILib

If you’d rather follow the official instructions, you can use the WPILib Installation Guide.
(WPILib Installation Guide: https://docs.wpilib.org/)

Otherwise:

  1. Download WPILib_Windows-2026.2.1.ISO.
    (WPILib download: https://github.com/wpilibsuite/allwpilib/releases)
  2. Right-click the downloaded ISO file and select Mount.
  3. Windows will mount it as though you inserted a disk into the computer.
  4. Open that drive and run WPILibInstaller.exe.
  5. Choose Install for all users and Download for this computer only.
  6. Let the installer finish.
  7. When you’re done, right-click the mounted drive in File Explorer and select Eject.

You should now have 2026 WPILib VS Code installed.

That’s our workshop.

Now we need some robot code.

Step 2: Meet Git and GitHub

Before we start changing code, there are two tools you need to know about:

Git and GitHub.

They are related, but they aren’t the same thing.

Git

Git keeps track of changes to our code.

Think of it as a really powerful save system.

Instead of eventually having folders named:

RobotCode

RobotCode-New

RobotCode-Fixed

RobotCode-Fixed2

RobotCode-Fixed2-ACTUALLY-WORKS

…Git keeps track of the history for us.

When we reach a point worth saving, we make a commit.

A commit is basically a named checkpoint that says:

This version worked. Remember this.

Git also lets several people work on the same project without everybody constantly overwriting everybody else’s files.

That’s rather important when you’re putting thirteen teenagers in a room with one robot.

GitHub

GitHub is where we share our Git repositories online.

Our team’s main copy of the code lives on GitHub.

You can make your own copy, download it to your computer, work on it, upload your changes, and eventually ask for those changes to become part of the team’s official code.

That’s the workflow we’re about to learn.

A Few Git Words

You’re going to encounter some new vocabulary.

You don’t need to memorize all of this right now.

  • Repository / Repo — A project and its history
  • Fork — Make your own copy of someone else’s GitHub repository
  • Clone — Download a repository onto your computer
  • Branch — Create a separate workspace where you can make changes safely
  • Commit — Save a named checkpoint
  • Fetch / Pull — Get changes other people have made
  • Push — Send your commits from your computer to GitHub
  • Pull Request — Ask for your changes to be reviewed and added to the team’s main repository

This will make much more sense after you’ve actually done it a few times.

If Git and GitHub are completely new to you, GitHub has a short video called A Brief Introduction to Git for Beginners.
(Video: https://www.youtube.com/)

There is also a hands-on GitHub Skills: Introduction to GitHub tutorial.
(GitHub Skills: https://skills.github.com/)

You don’t need to become a Git expert before programming the robot.

We’re going to learn it by using it.

Step 3: Find the Team’s Code

For this tutorial, we’re going to use our 2026Workbench project.

The team’s official repository is here:

2026Workbench
(https://github.com/9668Malfunctionz/2026Workbench)

This is the team’s copy.

We’re not going to start randomly changing that one.

Instead, we’re going to make you a copy.

Step 4: Fork It

Open the 2026Workbench repository on GitHub.

In the upper-right corner, find the button labeled Fork.

Click it.

If you don’t already have a GitHub account, GitHub will ask you to create one.

Once you’re finished, you should have your own copy of the repository in your GitHub account.

Something like:

https://github.com/YOURUSERNAME/2026Workbench

Excellent.

You now have your own copy of the robot code.

There’s just one problem.

It’s still on the Internet.

Let’s put it on your computer.

Step 5: Clone It

Open 2026 WPILib VS Code.

On the Welcome screen, look under Start and choose:

Clone Git Repository

When VS Code asks for the repository address, use the address for your fork:

https://github.com/YOURUSERNAME/2026Workbench.git

Choose somewhere sensible on your computer to save it.

VS Code will download the repository and open the project.

That download is called a clone.

So now we have:

Team repository → Your fork on GitHub → Your clone on your computer

We’re getting somewhere.

Step 6: Does It Build?

Before changing anything, let’s make sure the code we just downloaded actually works.

Build the project: Click on the search bar at the top of the screen >Show and Run Commands > WPILib: Build Robot Code

Watch the Terminal at the bottom of VS Code.

We’re looking for:

BUILD SUCCESSFUL

If you get that, congratulations.

You have successfully downloaded and built an FRC robot project.

If it doesn’t build, stop here and figure out why.

We haven’t changed anything yet, which means this is the easiest possible moment to solve the problem.

Step 7: Make Yourself a Branch

Now we’re about to start messing with working robot code.

Let’s give ourselves a safe place to do it.

Create a branch: Lower left corner, click on where it says “Main” next to the source control icon > Create a new Branch

A branch lets you experiment without immediately changing the main version of your project.

For your first experiments, a branch named something like:

just-testing

is perfectly fine.

As you get more comfortable with Git, it’s often better to name branches after what you’re working on:

add-limit-switch

test-intake-motor

fix-arm-control

The important thing is that we’re making our changes somewhere separate from the stable code.

If everything goes wonderfully, we can merge the changes later.

If everything catches metaphorical fire, we haven’t destroyed anything.

Step 8: Before Coding, Check for New Changes

There’s one problem with working on a team.

Other people keep doing things.

Someone may have changed the team’s code since you originally made your fork.

The team’s original repository is often called upstream.

Before starting new work, get into the habit of checking upstream for changes.

Fetch the upstream repository and merge any new changes into your branch.

That way you’re starting with the newest version of the team’s code instead of building something on top of code everyone else stopped using three days ago.

This will seem annoying until the first time it prevents an enormous merge mess.

Then you’ll understand.

Step 9: Let’s Find the Robot

Now we finally get to write some code.

Most of the Java code for the robot lives here:

src/main/java/frc/robot

Open that folder in the Explorer window.

You’ll see files such as:

Main.java
Robot.java

and sometimes folders containing things like:

subsystems

This is where the interesting stuff happens.

A subsystem represents some part of the robot.

For example, a robot might eventually have:

  • A drivetrain subsystem
  • An arm subsystem
  • An intake subsystem
  • A shooter subsystem

Instead of writing one enormous program containing everything the robot can possibly do, we divide the robot into understandable pieces.

For our 2026Workbench, we’re intentionally starting small so there are no subsystems.

The workbench gives us real FRC hardware to experiment with without needing an entire competition robot.

Step 10: Change Something

Here’s the fun part.

Pick something to work on.

Maybe we’re trying to:

  • Read an Xbox controller
  • Make a motor turn
  • Change its speed
  • Reverse its direction
  • Read a sensor
  • Add a limit switch
  • Make a button perform an action
  • Make the motor’s speed be based on how far you’re pulling the trigger on the controller

Make your change.

Don’t be afraid to experiment.

You are working on a branch, Git remembers what changed, and that’s exactly why we set all of this up before touching the code.

This is where programming actually happens:

Change something. See what happens. Learn something. Change it again.

Step 11: Build It Again

Before putting anything on a robot, build the project again.

We’re looking for our old friend:

BUILD SUCCESSFUL

If it doesn’t build, read the error.

Java errors can occasionally look like an ancient wizard placed a curse on your computer, but somewhere in all that red text is usually a clue.

Find the first useful error and start there.

Maybe you:

  • Misspelled something
  • Forgot a semicolon
  • Used the wrong variable
  • Forgot an import
  • Put something in the wrong place

Fix it.

Build again.

Repeat until:

BUILD SUCCESSFUL

Now we’re ready to find out whether the code actually does what we thought it would do.

Step 12: Put It on the Robot

Connect your computer to the same network as the robot.

In WPILib VS Code, choose:

Deploy Robot Code

WPILib will build your project and send it to the RoboRIO.

Now enable the robot and test your change.

Did the motor move?

Did the button work?

Did the sensor report what you expected?

Did absolutely nothing happen?

Did something happen that was significantly more exciting than you intended?

Welcome to robotics programming.

Step 13: Test, Change, Repeat

This is the real programming loop:

Code → Build → Deploy → Test

If it doesn’t work:

Change the code.

Build again.

Deploy again.

Test again.

You’re probably going to do this many times.

That’s normal.

Programming isn’t usually:

Write correct program → Finished.

It’s much more often:

I think this should work.

Nope.

Ohhhh.

Change something.

Better.

Why is it doing THAT?

Change something else.

YES.

When the robot finally does what you intended, you’ve earned the next step.

Step 14: Commit Your Work

Your code works.

Excellent.

Now let’s save a checkpoint.

Open the Source Control section in VS Code.

Git will show you the files you’ve changed.

Take a look at them.

Make sure you’re committing the things you actually intended to change.

Then write a short message explaining what you accomplished.

For example:

Add Xbox control for workbench motor

or:

Add limit switch to arm subsystem

Then Commit the changes.

Try not to use commit messages like:

stuff

changes

asdf

final

final2

Future You deserves better than that.

Step 15: Push It to GitHub

Your commit currently exists on your computer.

Now we need to send it back to your fork on GitHub.

Push your branch.

Now our journey looks like this:

You changed code locally → committed it → pushed it to your GitHub repository

Open your fork on GitHub and you should be able to see your branch and your new commit.

Your work is now safely stored online.

Step 16: Send It Back to the Team

Suppose your new code is good.

It builds.

You’ve tested it on the actual hardware.

Nothing caught fire.

And now we want your change to become part of the official Malfunctionz repository.

That’s what a Pull Request is for.

On GitHub, create a Pull Request from your branch back to the main 9668Malfunctionz/2026Workbench repository.

A Pull Request basically says:

Hey. I made this change. Can we add it to the team’s code?

Someone can review your changes, ask questions, suggest modifications, test them, and eventually merge them into the main project.

And just like that, code that began on your laptop becomes part of the robot.

You Just Did the Whole Thing

Think about what just happened.

You:

  1. Installed the FRC programming tools
  2. Found the team’s repository
  3. Forked it
  4. Cloned it
  5. Built it
  6. Created a branch
  7. Changed the robot code
  8. Built it again
  9. Deployed it to real hardware
  10. Tested it
  11. Committed your changes
  12. Pushed them to GitHub
  13. Created a Pull Request

That’s basically our programming workflow.

It looks like a lot when every step has a weird new name.

After you’ve done it several times, it becomes:

Fetch → Branch → Code → Build → Deploy → Test → Commit → Push → Pull Request

And most of your time will be spent in the middle:

Code → Build → Deploy → Test

over and over again until the robot finally does the thing.

Then you’ll make it do something harder.