The FRC Software Toolbox: Driver Station, Dashboards, AdvantageScope & SysId

Writing robot code is only half the job. The other half is the constellation of desktop apps you use to deploy that code, drive the robot, watch what it's doing, and figure out why it just drove into a wall. Most of these tools are free, most ship with WPILib, and learning them early is one of the fastest ways to look like a veteran programmer at your first competition. Here's the toolbox, what each piece does, and when you actually reach for it.

The FRC Driver Station: the one tool you can't skip

Everything starts here. The FRC Driver Station is the only software allowed to control the state of your robot during a match, and it's the program your drive team stares at all weekend. It ships inside the FRC Game Tools, a package distributed by NI (National Instruments) that also includes the roboRIO Imaging Tool and the LabVIEW runtime the Driver Station needs. The Game Tools run on Windows 10 or 11 only — there is no Mac or Linux build — so your drive laptop must be a Windows machine. You can grab it from the FRC Game Tools install guide.

What the Driver Station actually does, per the WPILib Driver Station docs:

• Enables and disables the robot. A disabled robot cannot move; this is your single most important safety control.
• Selects the operation mode: TeleOperated runs your teleop code, Autonomous runs your auto routine, Practice cycles through the real match sequence (auto, then teleop, with the right timing), and Test runs test-only code that never runs in a real match.
• Reads your joysticks and gamepads and forwards their inputs to the robot.
• Shows four critical status indicators — Communications (is the laptop talking to the roboRIO?), Robot Code (is your program running?), Joysticks (is at least one controller detected?), and Battery Voltage with a live history plot.
• Logs everything. The Driver Station records match logs and a stream of errors and warnings you can replay later in the Log File Viewer.

You set your team number in the Setup tab; this tells the Driver Station the mDNS name to look for your roboRIO at. At a competition the field's FMS (Field Management System) takes over enabling and disabling, but the Driver Station is still the program that connects you to the field. If you learn nothing else, learn to read those four status indicators — most "the robot won't move" panics are solved by noticing which one is red.

Dashboards: how you see what the robot sees

A dashboard displays live data from your robot — sensor values, camera streams, a chooser for which autonomous to run. FRC has several, and they fall into two buckets: driver dashboards (clean, glanceable, used behind the glass during a match) and programmer dashboards (dense, diagnostic, used at the bench). The Choosing a Dashboard guide is the official starting point.

Shuffleboard and SmartDashboard (legacy)

For years Shuffleboard and the older SmartDashboard were the default driver dashboards. They are now gone: the WPILib docs record that both were removed for the 2027 season — Shuffleboard for lacking a maintainer and having resource-utilization issues, and SmartDashboard because it relied on the old NetworkTables v3 protocol. If you're starting fresh today, learn Elastic instead — but you'll still see Shuffleboard in older tutorials and on veteran teams' laptops. (Removal timelines like this can shift, so when in doubt check the current WPILib documentation for the season you're on.)

Glass — the programmer's microscope

Glass is WPILib's official data-visualization tool, and the docs are explicit that it's "meant to be used as a programmer's tool rather than a proper dashboard in a competition environment." It focuses on high-performance real-time plotting and pose visualization — the Field2d widget draws your robot's position on a top-down field, which is the single best way to debug odometry. You launch it from VS Code via the WPILib Command Palette. Reach for Glass when you want to watch a value change in real time while you tune something at the bench.

Elastic — the modern driver dashboard

Elastic, built by Team 353, is the dashboard most teams now put in front of their drivers. The Elastic docs describe it as a drag-and-drop dashboard of resizable card widgets, designed for "a high pressure competition environment." It reads data over NetworkTables (NT4), automatically grabs the robot's IP from the Driver Station, supports camera streams, and offers a full-screen mode for behind-the-glass use. Use Elastic to build your driver's match view: an autonomous chooser, key sensor readouts, and a camera feed.

AdvantageScope — logging and replay, the popular one

AdvantageScope, made by Team 6328 (Littleton Robotics), has become the de-facto standard for FRC log analysis, and since the 2024 season it ships bundled inside the WPILib installer. The AdvantageScope docs call it a "robot diagnostics, log review/analysis, and data visualization application."

Its superpower is replay. During a live connection it streams NetworkTables (NT4) data; afterward it opens recorded logs so you can scrub back through a match and see exactly what every sensor reported, frame by frame. It reads an unusually wide range of formats — WPILib data logs (.wpilog), Driver Station logs, CTRE Hoot logs, and REV REVLOG logs among them. Its visualization tabs include line graphs, a 2D and 3D field view with custom robot models, swerve vector displays, a joystick viewer, a console, and synchronized video playback so you can line up your match footage with the data. When the robot did something weird and you don't know why, AdvantageScope is how you find out. (It pairs especially well with the same team's AdvantageKit logging framework, though AdvantageKit is not required.)

SysId: stop guessing your tuning numbers

Good control — smooth driving, an arm that holds position, an elevator that doesn't slam — depends on accurate feedforward constants. SysId (System Identification) is the WPILib tool that measures these for you instead of making you guess. Per the SysId introduction, it runs your mechanism through controlled tests, records the data, and fits a mathematical model.

You add a SysIdRoutine to your robot code (described in Creating a Routine) with a Config and a Mechanism object. SysId then runs two kinds of tests, each forwards and backwards — four tests in total:

• Quasistatic — the mechanism is sped up so slowly that acceleration is negligible.
• Dynamic — a constant step voltage is applied so you can measure how it accelerates.

From the logged data, SysId computes feedforward gains: kS (static friction), kV (velocity), and kA (acceleration) for every mechanism, plus kG (gravity) for arms and elevators that have to fight their own weight. You feed these numbers into WPILib's feedforward and PIDController classes. Run SysId once per mechanism early in the build season, write down the gains, and your closed-loop control gets dramatically easier.

roboRIO Imaging Tool and vendor utilities

Two more categories round out the toolbox.

The roboRIO Imaging Tool, included in the NI Game Tools, flashes (images) the firmware on your roboRIO — the robot's main controller — and sets its team number. You run it once when you first set up a roboRIO, and again if a firmware update or a corrupted image ever requires it.

Your motor controllers and CAN devices have their own configuration apps:

• REV Hardware Client — REV's tool for updating firmware and configuring REV devices like the SPARK MAX and SPARK Flex motor controllers. The REV docs describe it auto-detecting connected devices and pulling the latest firmware.
• CTRE Phoenix Tuner X — CTR Electronics' app to "update, configure, analyze, and control" their CAN devices, including Talon FX controllers (the Kraken X60 uses an integrated Talon FX), the CANcoder, and the Pigeon 2 gyro. The Phoenix 6 Tuner docs cover firmware updates, assigning CAN IDs, self-tests, live plotting, and "blipping" a motor to confirm it's wired right. Tuner X runs on Windows, macOS, Android, and iOS.

Whenever you add a CAN motor controller or sensor to the robot, you'll open one of these to give it a unique CAN ID and update its firmware — a step that prevents a huge fraction of "device not found" errors. Note that exact part numbers and which devices a vendor supports shift each season, so confirm against the current vendor docs before a build.

Putting it together

A typical workflow: image the roboRIO and set CAN IDs with the Imaging Tool, REV Hardware Client, and Phoenix Tuner X; deploy code and control the robot with the Driver Station; debug live at the bench with Glass; give your drivers a clean match view in Elastic; characterize mechanisms with SysId; and after every match, replay the logs in AdvantageScope to see what really happened. None of these require writing more robot code to use — they're force multipliers that make the code you already wrote far easier to get right.

Ready to put these tools to work? Start with our Programming track to learn the robot code that feeds them all.