Unit 0 · Lesson 4

Deploying to a roboRIO for the First Time

This is the moment the three systems meet. Your code leaves your laptop, crosses a wire, lands on the roboRIO, and — if everything is right — makes something physical happen. Nothing in software development quite matches the first time a robot moves because of code you wrote.

By the end of this lesson, you will:

Explain what happens to your code between pressing Deploy and a motor spinning
Connect to the roboRIO via USB and confirm it is reachable
Complete a pre-deploy hardware and software checklist
Execute your first successful deploy using WPILib
Navigate the FRC Driver Station and enable the robot safely
Read and interpret deploy terminal output
Diagnose the five most common first-deploy failures

What Deployment Actually Does

When you click WPILib: Deploy Robot Code, several things happen in sequence — and understanding each step makes debugging failures much faster.

Gradle builds a fresh jar — your Java code is compiled and packaged into FRCUserProgram.jar.
WPILib opens an SSH connection to the roboRIO using the address derived from your team number: roborio-XXXX-frc.local over the network, or 172.22.11.2 over USB.
The jar is transferred to /home/lvuser/FRCUserProgram.jar on the roboRIO's filesystem.
WPILib restarts the robot program service — the roboRIO kills the old program and starts the new one.
Your code begins executing — robotInit() runs, the robot loop starts, and the robot enters Disabled mode waiting for the Driver Station.

💡 The roboRIO is a Linux computer

The roboRIO runs a real-time variant of Linux (NI Linux Real-Time). Your Java code runs on a JVM on top of that OS, managed by a systemd service called robotProgram. When you see "Restarting robot program..." in the deploy output, WPILib is issuing a systemctl restart robotProgram command over SSH. This is also why a brownout or unexpected power cycle restarts your program automatically — the service manager restarts it.

Connecting to the roboRIO

Before you can deploy, your laptop needs a path to the roboRIO. There are three ways to establish that connection — each with different tradeoffs.

👇 Click each card to compare methods

🔌

USB-B Cable

tap to compare

Use for: first deploy, pit work

Most reliable. Fixed IP 172.22.11.2. Works without a configured radio. Slightly slower transfer. Start here for your first deploy. The robot radio does not need to be present or powered.

🔗

Ethernet Tether

tap to compare

Use for: in-shop iteration

Fast and reliable. Direct cable from laptop to roboRIO ethernet port. Uses mDNS hostname roborio-XXXX-frc.local. Requires no radio. Best for rapid code iteration during practice.

📡

WiFi via Radio

tap to compare

Use for: competition, driver practice

Wireless freedom. Robot radio must be configured with your team number using the FRC Radio Configuration Utility (a separate tool). At competition, the FTA configures the field radios — use this mode during matches.

🔍 Event Note: USB in the Pit

In the pit and during hardware verification at events, USB is the reliable fallback — the radio often isn't configured yet, and the field network isn't available outside the playing field. Always keep a USB-B cable in your pit bag. More importantly, make sure your laptop actually has a USB-A port or bring the appropriate adapter. Modern thin laptops with only USB-C are a common source of "I can't connect to the robot" panic in the pits.

Pre-Deploy Checklist

Deploying to a live robot with unchecked hardware is how mechanisms break and people get hurt. Run through this checklist every time — especially for your first deploy. Click each item to check it off.

Pre-deploy checklist 0 / 7 complete

Build succeeds Run WPILib: Build Robot Code and confirm BUILD SUCCESSFUL before attempting deploy.

Team number is correct Verified in .wpilib/wpilib_preferences.json and in the FRC Driver Station.

roboRIO is imaged Running this season's NI image. Check the web dashboard at 172.22.11.2 (USB) or roborio-XXXX-frc.local.

Connection confirmed USB-B or Ethernet cable is seated. Driver Station shows robot communications (green).

Battery is charged and connected Battery reads above 12V in Driver Station. PDH/PDP main breaker is closed.

Robot is in a safe position Mechanisms are stowed or can move freely without hitting anything or anyone. No people in the robot's reach.

Someone is on the enable/disable button A person is ready at the Driver Station to immediately disable if anything unexpected happens.

✅

All checks passed — you're ready to deploy and enable safely.

Running the Deploy

Connect the USB-B cable
USB-B (the square connector) goes into the roboRIO. USB-A goes into your laptop. The roboRIO's status lights will blink briefly as it establishes the connection.
Confirm the connection
Open a browser and navigate to 172.22.11.2. You should see the roboRIO web dashboard. If the page loads, the connection is good. If not, try a different USB cable — roboRIO USB is notorious for being cable-sensitive.
Open WPILib VS Code and run deploy
Press Ctrl+Shift+P → WPILib: Deploy Robot Code. Alternatively, click the WPILib arrow icon in the status bar at the bottom of VS Code.
Watch the terminal output
Gradle builds the jar first, then transfers it to the roboRIO and restarts the robot program service. The full deploy takes 20–60 seconds on first run.
Confirm success
The terminal shows BUILD SUCCESSFUL and Robot code successfully deployed. The roboRIO's status light pattern changes as the new code starts running.

Connect to the robot's network
Connect your laptop to the robot radio's WiFi network (SSID is typically your team number), or plug an Ethernet cable directly from your laptop to the roboRIO's ethernet port.
Confirm the roboRIO is reachable
Open a terminal and ping the roboRIO:

ping roborio-2910-frc.local

You should see reply packets with response times. If ping times out, check the network connection and verify your team number is correct in WPILib preferences.
Run deploy
Ctrl+Shift+P → WPILib: Deploy Robot Code. Network deploy is faster than USB once the connection is established — typically 10–20 seconds for the file transfer.
Watch for the restart
After the jar transfers, WPILib restarts the robot program. You'll see the Driver Station briefly lose robot comms and reconnect as the new code starts up. This is normal.

💡 mDNS can be unreliable on some systems

Windows sometimes struggles to resolve roborio-XXXX-frc.local without the FRC Driver Station software installed — it provides the mDNS resolver. If network deploy fails but USB works, install the Driver Station first, then try again.

Reading the Deploy Output

Click any line in the terminal output below to learn what it means.

TERMINAL — WPILib: Deploy Robot Code

./gradlew deploy > Task :compileJava > Task :jar Connecting to roborio-2910-frc.local... Connected via SSH to 10.29.10.2 Copying FRCUserProgram.jar → /home/lvuser/ Copying shared libraries... Restarting robot program... Setting file permissions... BUILD SUCCESSFUL in 34s Robot code successfully deployed.

← click a line to explain it

The FRC Driver Station

The Driver Station (Windows only, installed separately from WPILib) is the interface between your operator and the robot. The robot will not accept enable commands from any other source. At competition, it communicates through the field's network. In the shop, you run it from your laptop.

Click any element in the mock Driver Station below to learn what it does and what to look for.

FRC Driver Station 2025 — Team 2910 ▪ Simulated view — click to explore

Communications

Robot Code

Joysticks

E-Stop

Battery

12.6 V

Team #

2910

Ping

3 ms

Loss

0.00 %

Mode

Disabled

← click any element above to learn what it does

💡 Joystick light: what it signals

If the Joysticks indicator is amber, the Driver Station doesn't see a connected HID device. A match-ready robot needs at least one controller configured so the drive team can operate it. Get this sorted during setup, well before your first match.

Enabling the Robot — Safely

After a successful deploy, the Driver Station shows all three status lights green: Communications, Robot Code, and Joysticks. At that point, you can enable. Before you press that button, read the entire paragraph below.

⚠️ Call it out before you enable

Championship teams have a verbal protocol for enabling: the programmer or drive coach calls "Enabling in 3... 2... 1..." loud enough for everyone in the area to hear. This is not a formality. When a robot with a swerve drive and a fully-extended arm enables unexpectedly, people get hurt. Build this habit from your very first enable, even if your robot can't do anything yet.

For your first deploy, your teleopPeriodic() and autonomousPeriodic() methods are empty — the robot will enable and do nothing. That's exactly right. A robot that enables and does nothing is a safe baseline.

What the roboRIO Status Light Means

Solid green: Robot code is running and the robot is enabled.
Blinking green (1Hz): Robot code is running, robot is disabled.
Blinking green (fast): Robot code is running but no Driver Station connection yet.
Blinking orange: roboRIO is booting — wait 30 seconds before trying to connect.
Solid red: No robot code is loaded or code crashed. Check your deploy output and Driver Station fault log.

Common First-Deploy Failures

"No robot found at roborio-XXXX-frc.local" — Wrong team number in wpilib_preferences.json, cable not connected, or roboRIO still booting. Wait 30 seconds and try USB.
"SSH connection refused" — roboRIO is reachable but not accepting connections. Power-cycle the roboRIO. If the problem persists, re-image the roboRIO.
"Build failed" before deploy even tries — Fix your compiler errors first. Deploy always builds first; if the build fails, no deploy happens.
Driver Station shows Robot Code light red after deploy — Your code crashed during robotInit(). Open the Driver Station log or look at the Driver Station's Console tab for the stack trace. A NullPointerException on startup almost always means you declared a hardware object (like a TalonFX) but forgot to initialize it before calling a method on it.
Robot enables but nothing moves — Your code is running, but a motor isn't receiving commands. Check: CAN IDs match physical configuration, the motor is enabled in your vendor tool (no firmware faults), and your teleopPeriodic() is actually calling the motor's set method.
Watchdog warning in Driver Station — Your periodic loop is taking longer than 20 ms. The robot will disable itself. Usually caused by a blocking call (like a Thread.sleep()) inside a periodic method. Never block inside a periodic function.

🔌 System Check

⚙️ Hardware Requirements — This Lesson Is Robot-Required

Unlike the previous lessons, you cannot complete this one with just a laptop. Here is what must be in place before your first deploy:

roboRIO: Powered by the PDH/PDP (not USB alone), imaged with the current season's NI image, and reachable at 172.22.11.2 over USB.
Battery: A charged 12V SLA battery reading above 11.5V under no load. Below 10V, the roboRIO may reset mid-deploy. This looks like a software failure but is actually an electrical one.
USB-B cable: The square-connector end goes into the roboRIO's USB-B port. Verify the cable is data-capable — some USB-B cables are charge-only and will not establish a connection.
Driver Station laptop: Windows only. FRC Driver Station software must be installed. The Driver Station must show your correct team number. This laptop can be the same machine you deploy from.
Motor controllers (for Unit 5): Not required for this lesson's empty deploy, but before you write any motor control code, confirm all CAN device IDs are set and unique using Phoenix Tuner X or REV Hardware Client.
Physical safety: If any mechanism is attached to the robot, ensure it is stowed or can move freely without hitting people or equipment. For your first deploy with an empty teleopPeriodic(), the robot will do nothing when enabled — but build the safety habit anyway.

Knowledge Check

Click an answer to check your understanding.

After a successful deploy, the Driver Station's Robot Code light stays red. What is the most likely cause?

1The deploy failed silently and no code was transferred
2The robot program crashed on startup — check the Driver Station console for a stack trace
3The team number in Driver Station doesn't match the team number in your code
4The roboRIO needs to be power-cycled after every deploy

Your deploy fails with "No robot found at roborio-2910-frc.local" but you can successfully ping 172.22.11.2. What does this tell you?

1The roboRIO is not powered on
2Your code has a compile error
3The roboRIO is reachable via USB but mDNS hostname resolution is failing — the wrong team number is probably set, or the mDNS resolver (installed with Driver Station) is missing
4The roboRIO needs to be re-imaged

The Driver Station shows a "Watchdog not fed" warning and the robot disables itself. Before changing any code, what should you check on the electrical side?

1Nothing — this is purely a software problem caused by slow code
2Battery voltage — a sagging battery under load can cause the roboRIO to slow down, making the loop appear to overrun even if the code itself is fast enough
3Whether the radio is configured correctly
4The USB cable connection quality

💪 Practice Prompt

Your First Successful Deploy

Work through each step in order. The goal is a robot that enables, stays enabled, and — for now — does nothing. That is a complete, correct result.

Complete the pre-deploy checklist from this lesson. Do not skip items. Write down anything you had to fix to make all seven checks pass.
Connect your laptop to the roboRIO via USB-B. Navigate to 172.22.11.2 in a browser. What information does the roboRIO web dashboard show? Record the image version and the roboRIO's IP address.
Deploy your TimedRobot project from Lesson 3. Record the total deploy time. Did it succeed on the first try? If not, what error did you get, and how did you resolve it?
Open the FRC Driver Station. Confirm all three status lights are green. Record what battery voltage it shows.
With someone ready at the Disable button: call "Enabling in 3... 2... 1...", then enable in TeleOp mode. The robot should enable and do nothing. Leave it enabled for 10 seconds, then disable. What did the roboRIO status light do when you enabled?
Bonus: Open the Driver Station's Messages tab during enable. What messages does your robot code print? (Hint: a fresh TimedRobot template prints nothing — what would you add to teleopInit() to confirm that method is being called?)