WPILib 2027 · FRC + FTC · a visual guide

SystemCore

One robot controller for both programs, a new driver station, and the biggest set of breaking changes in years — drawn out, piece by piece.

2027Required in FRC.
The roboRIO retires.
Pi CM5The board inside.
Far more headroom.
4Languages: Java, C++,
Python, and blocks.
4Tools retired.
Better ones replace them.

Drawn from the NEMC 2026 session “SystemCore Software: Preparing for the Transition,” presented by the WPILib team. Watch it →

Part 1

Start here

What SystemCore is, when it arrives, and whether it changes anything for your team.

What it is

Same robot brain for FRC and FTC

SystemCore is a new robot controller built specifically for FIRST, and it is shared across both FRC and FTC. That single fact drives almost everything else: because both programs run the same hardware, they can now run the same software library, and what a student learns in one program carries directly into the other.

The changeover happens at different speeds. FRC gets a hard cutover — SystemCore is required starting in the 2027 season, and the roboRIO stops being competition-legal. FTC gets a gradual one, starting a season later, with the old control hubs staying legal alongside for several years.

2026202720282029 →
FRC
roboRIO
SystemCore — required
FTC
REV Control Hub — still legal for a few seasons
SystemCore legal — fall 2027
Jan 2027: the roboRIO stops being competition-legal in FRC. SystemCore Previous controller
Fig. 1Two different transitions. FRC swaps controllers in one offseason; FTC overlaps old and new hardware for years, and also allows a hybrid setup — SystemCore for control, REV expansion hubs for power.
Who it affects

Mostly Java teams, and now FTC too

In 2026, 93% of FRC teams programmed in Java, with the rest mainly C++ and Python. FTC is far more mixed — Android Studio with Java, browser-based OnBot Java, and blocks all have real populations. Both sets of teams land on the same library in 2027.

93%of FRC teams used Java
in the 2026 season
2009the season WPILib
came into wide use
1shared library across
FRC and FTC
Part 2

The hardware

What you physically get, and what the extra processing power buys you.

The controller

What is on the board

SystemCore is built on a Raspberry Pi Compute Module 5 — substantially more processor, memory, and onboard storage than either the roboRIO or the REV Control Hub. A lot of the ports that needed add-on hardware before are simply on the board now. Click any part to see what it does.

SYSTEMCORE 5 × CAN 6 × SMART IO USB USB-C I²C BRIDGE 10.15.02.2 CODE: OK BATT 12.4V WI-FI RASPBERRY PI COMPUTE MODULE 5

Pick a port

Every connector on this board used to need something extra — a CAN adapter, an expansion hub, a co-processor, a laptop. Tap any highlighted part of the diagram to see what it replaces.

Tip: the diagram is keyboard-navigable — Tab to a port, then press Enter.

Fig. 2SystemCore, drawn schematically — port positions are simplified. The compute module, screen, and radio are all onboard; only the FRC field radio stays external.

Code on the robot

Tools that needed a desktop can now be served from the controller itself over Wi-Fi: VS Code and the blocks editor in a browser, plus web versions of AdvantageScope and Elastic. A Chromebook is enough.

Vision without a co-processor

AprilTag pipelines run on the controller, configured through a Limelight-style web interface. Object detection needs the add-on Hailo AI module. Budget roughly one Limelight 4 of processing power.

Room to be sloppy

Loop overruns, out-of-memory errors, and Java garbage-collection pauses all get much harder to hit. The performance ceiling stops being the thing that shapes your code.

FTC only

FTC robots pair SystemCore with a second board. MotionCore is the power and communication hub: it takes the 18 V battery, connects to SystemCore over the bridge, and hands out combined CAN-and-power connections to the new A301 brushless motor.

SYSTEMCORE bridge: power + data MOTIONCORE 18 V battery 3 × encoder 20 × CAN + power A301 MOTOR ▪ abs + rel encoders ▪ 3 control modes ▪ gearbox options ▪ 15-tooth spline
Fig. 3MotionCore is the FTC half of the pair: battery in, bridge to SystemCore, and 20 ports that carry CAN and power on one connector. FRC robots keep their existing power distribution instead. For the first couple of seasons FTC teams can also run a hybrid — SystemCore for control, REV expansion hubs for power.
Part 3

What changes in your code

Three changes you will meet the first time you open a 2027 project.

Field coordinates

The field origin moves to the middle

For years, FRC field coordinates started at the blue alliance wall. In 2027 the origin moves to the center of the field. This sounds like paperwork until you write an autonomous routine that has to work from both alliances — then it is the difference between subtracting from the field length and flipping a sign.

BLUE WALL RED WALL +X +Y (0, 0) (4.1, 2.1) (-4.1, -2.1)
Scoring pose, blue side(4.1, 2.1)
Same pose, red side(-4.1, -2.1)
To flip alliances you writepose.times(-1)
Fig. 4With the origin at the center, a pose and its mirror image differ only in sign, so flipping an autonomous path between alliances is one negation instead of a subtraction that depends on the field's exact dimensions. The coordinates are an example, drawn on a field of roughly recent FRC proportions — 2027 field dimensions have not been published.
Logging

Getting numbers off the robot

You cannot debug a robot by watching it move. You need its numbers — what angle the arm believed it was at, what the encoder read, whether the camera saw a tag. And those numbers are wanted by two different people at two different times.

  • The driver, right now. A few values on a screen during the match: battery, whether the shooter is up to speed, whether the robot knows where it is.
  • You, twenty minutes later. Everything, in a file, so you can scrub back through the match and find the moment the arm stopped.

The old SmartDashboard API made those feel like two separate chores. The telemetry API that replaces it makes them one line of code, written without deciding which case you are serving:

telemetry.log("arm/angle", 42.7);

A name and a value. It works out how to store it — numbers and booleans, poses and other geometry, unit-typed values, and your own types once you teach it how. Where the value goes is set up separately, and that is the part worth understanding.

YOUR ROBOT CODE telemetry.log( "arm/angle", 42.7); the slash makes a folder arm/ angle setpoint drive/ speed you route by folder, not by rewriting code WATCH IT NOW NetworkTables → driver dashboard, live AdvantageScope radio bandwidth is scarce — send only what drivers need READ IT LATER DataLog → file on a USB drive plugged into the robot disk is cheap — record everything
Fig. 5Both destinations can run at once, and each folder can go to either or both — so the usual setup is to record everything to the file while streaming only the handful of values the drivers actually look at. Java teams can skip the log call entirely and use Epilog's annotation-based logging. One naming note for FTC: this is not the FTC SDK's “telemetry.” Driver-station text still exists, it is just called something else here.
Program structure

Op modes: your autonomous chooser, built in

An op mode is a driver-selectable program option, and it is the idea FTC has used for years arriving in FRC. Each one is its own class with its own lifecycle methods, and the driver station shows them in dropdowns — autonomous, teleop, and utility, which is the old test mode renamed. One op mode is active at a time.

For FRC teams this replaces the SendableChooser you used to publish to a dashboard. In match mode the driver station picks your autonomous op mode, then switches itself to your selected teleop op mode when autonomous ends. Robot code can also add options programmatically — one class registering both a left-side and right-side variant, for instance.

start() periodic() end() +disabledPeriodic()

Fig. 6Pick a mode, then an op mode — the others grey out. OpModeRobot replaces TimedRobot as the base class, but it is optional: TimedRobot still works if you would rather not change.
Why this pairs with Commands V3

Triggers and default commands created inside an op mode are automatically scoped to it — they activate when that op mode is selected and are torn down when you switch away. A competition teleop and a demo teleop can have entirely different button bindings with no conditional logic. That framework has its own visual guide; it is optional too, and Commands V2 keeps working for the next few seasons.

Part 4

What changes around your code

The programs you use to drive, log, debug, and write robot code.

Driver station

One application, both programs, any operating system

FRC and FTC had separate driver station software; merging the controller means merging those too. The replacement is written by the WPILib team and runs on Windows, macOS, and Linux, with a compact touch layout for driver-hub style tablets. FRC teams on an actual field still need Windows — that is an FMS requirement, not a WPILib one.

WPILib Driver StationWindows · macOS · Linux
Op modes
AutonomousLeft Trench ▾
TeleopCompetition ▾
UtilitySystems Check ▾

Your autonomous chooser, no dashboard required.

TeleopAutonomous Utilitywas testMatchwas practice
Blue 2
Status
CommsOK
CodeOK
Battery12.4 V
Ping4 ms
From robot codeArm homed · 3 tags in view
AlertElevator encoder not zeroed
Logs → WPILogOpen AdvantageScope ↗
Fig. 7The merged driver station, sketched. Op mode dropdowns replace the dashboard chooser; test mode is renamed utility and practice mode is renamed match. Robot code can publish status text and alerts straight to this window, and AdvantageScope opens inside it.
  • Consistent joysticks. Button IDs map identically on every operating system, so plugging into a MacBook instead of a Windows laptop does not change your code. Far more gamepads are supported.
  • Modes you already know, renamed. Teleop and autonomous are unchanged; test mode is now utility mode; practice mode is now match mode — and in FTC, match mode is what runs real matches, since there is no FMS.
  • AdvantageScope inside. Logs are written in the WPILog format and a built-in web version of AdvantageScope opens with a button, including joystick visualization of what your drivers actually did.
  • Status where drivers can see it. Robot code can publish plain text and alerts to the driver station, next to ping times, battery voltage, and console output.
Retired tools

Four tools are being retired

Each of these had low usage and a better-maintained replacement. Retiring them is the same instinct as the rest of 2027: make the breaking changes once, in one season, rather than a few every year.

SmartDashboardPublishing API replaced by the telemetry API; display replaced by Elastic.
Elastic + telemetry APIA driver dashboard built for match use, fed by a simpler logging call.
ShuffleboardAging, and largely superseded for both live view and analysis.
AdvantageScopeNow bundled into the driver station as a web app, one click away.
RobotBuilderGenerated project scaffolding that no longer matches how teams write code.
No direct replacement namedThe talk cited low usage and better alternatives without naming one. Project templates and the new blocks editor cover most of what teams used it for.
PathWeaverPath authoring long since outgrown by community tools.
No direct replacement namedAgain cited as low-usage with better alternatives available — in practice, the community trajectory tools most teams already use.
Blocks

Blocks that are really Python

WPILib 2027 supports four languages: Java, C++, Python, and a new block-based option built on Google Blockly — the same idea as Scratch or the SPIKE Prime editor many students meet in elementary school. It matters most for FTC, where a large share of teams start in blocks.

The design goal is stated as “raise the floor, don't lower the ceiling”: blocks should get a beginner to a working robot, and every block shows the Python it generates, so moving on to text is a translation rather than a fresh start. Blocks also split into mechanisms and share code between op modes, so a blocks project does not have to be one giant pile.

What the student drags
when op mode “Drive Forward” starts
repeat while
encoder distance < 2.0
set drive motor to 0.5
set drive motor to 0.0
What it generates
def start(self):
    while self.encoder.get_distance() < 2.0:
        self.drive_motor.set(0.5)
    self.drive_motor.set(0.0)
Fig. 8Blocks generate WPILib Python, shown side by side as you build. Illustrative — the editor's exact appearance is still changing.
Part 5

Getting ready

Everything below works today, on a laptop, with no SystemCore in the building.

Checklist

What you can do before the hardware exists

01
Install the 2027 alpha

WPILib 2027 alphas are public and install through the normal installer. Everything below works without a SystemCore.

02
Run desktop simulation

Full simulation lets you try the new APIs, the coordinate change, op modes, and Commands V3 on a laptop.

03
Try the new driver station

Alpha builds are downloadable now. Point it at a simulated robot and get familiar with the mode selectors before kickoff.

04
FTC: start with AdvantageScope

It now reads several FTC SDK log formats, so you can pick up the analysis tooling a full season before switching libraries.

05
Follow along, or help

Development happens in public on GitHub. Contributions are not limited to the library — the installer, tools, and docs all need people.

Read this as a forecast

Everything here comes from an alpha-period talk. The presenters were explicit that details may change in response to testing feedback, and that pricing and availability will be announced on the FIRST community blog rather than guessed at. Treat specifics as current intent, not a promise.