FRC Driver Dashboards: Shuffleboard vs Elastic vs Glass

A driver dashboard is the screen your drive team stares at for the length of a match while everything is on fire. It is where the operators find out whether the intake is jammed, which autonomous routine is selected, how much battery is left, and what the camera sees. Robot code that publishes nothing useful drives blind, and a cluttered dashboard nobody can read under match pressure is almost as bad.

This guide covers what an FRC dashboard is, how the main options compare — the default Driver Station dashboard, SmartDashboard, Shuffleboard, Glass, Elastic, and AdvantageScope — how to publish data from robot code over NetworkTables, and how to design a layout your operators can use when the field goes live. Two of the classic dashboards are on their way out, so which tool you standardize on matters more than it did a couple of seasons ago.

What a driver dashboard actually is

Every FRC dashboard is a NetworkTables client. Your robot program runs a NetworkTables server on the roboRIO; the dashboard runs on the driver station laptop and connects to it over the field network. When your code writes a value — a number, a boolean, a string, a robot pose — it publishes that value to a NetworkTables key, and any connected dashboard can subscribe to that key and draw it. The dashboard never talks to your mechanisms directly; it only reads and writes NetworkTables entries. For the roboRIO side of that connection, see the roboRIO guide.

That single idea — NetworkTables in the middle — is why you can swap dashboards freely: the same SmartDashboard.putNumber(...) call feeds whatever dashboard your driver station is running. It also explains the split in the tooling. Some of these programs are driver dashboards meant to live behind the glass during a match; others are programmer tools meant for the pit and shop. They all speak NetworkTables, but they are built for very different jobs.

The dashboards at a glance

Here is the current landscape. "Bundled" means the tool installs with the standard WPILib installation rather than being a separate download.

Two things jump out. First, both SmartDashboard and Shuffleboard are deprecated and, per WPILib, are slated for removal in 2027 — so a team choosing a dashboard today should not build its long-term workflow on either. Second, the tool most teams now reach for as a match dashboard, Elastic, was not written by WPILib at all; it is a community project that WPILib now bundles.

The default Driver Station dashboard

The FRC Driver Station application itself can launch a dashboard for you. On the Setup tab there is a Dashboard Type setting that controls what the DS launches when it starts: Default, SmartDashboard, Shuffleboard, Remote, and custom LabVIEW options. By default the Driver Station launches the LabVIEW dashboard. For LabVIEW teams that is a reasonable starting point; for Java and C++ teams it is mostly a historical artifact. The practical takeaway is that the Dashboard Type dropdown is how you make a dashboard open automatically alongside the Driver Station.

SmartDashboard

SmartDashboard is the oldest of the widget dashboards. WPILib describes it as a simple and efficient dashboard that uses relatively few computer resources and displays NetworkTables data with a variety of widgets without bogging down the driver station computer. It lacks the polish of the newer tools, but it is light, and for years it was the default answer for "put a number on the screen."

Its limitation is now also its expiration date: SmartDashboard connects over the older NetworkTables 3 protocol — support for which WPILib has now removed — and that, together with a lack of maintenance, is why it is deprecated and slated for removal in 2027. It still works, and its publishing API is the one most WPILib examples use, but it is not where a new team should invest.

Shuffleboard

Shuffleboard was the intended successor to SmartDashboard and is described by WPILib as a straightforward, easily customizable, drive-team-focused dashboard. It displays NetworkTables data using a variety of widgets that can be positioned and controlled directly from robot code, and it adds real drive-team features on top: multiple tabs, match recording and playback, and advanced custom widgets.

Shuffleboard runs on NetworkTables 4, so the protocol is not the problem — upkeep is. WPILib has deprecated it and slated it for removal in 2027, citing a lack of a maintainer and resource-utilization issues, and it can feel heavy on an older laptop. A polished layout will serve you this season, but new work is better spent on Elastic.

Glass

Glass is a robot data visualization tool whose interface is very similar to the WPILib Simulation GUI. WPILib is explicit that, in its current state, it is meant as a programmer's tool rather than a proper competition dashboard, with a focus on high-performance real-time plotting. Tellingly, Glass does not even appear in the Driver Station's Dashboard Type list.

Glass excels in the pit and on the bench:

• Real-time plots of any numeric NetworkTables value — the best tool in the suite for watching a PID response or a velocity curve as it happens.
• The Field2d widget for visualizing your robot's estimated pose on the field.
• The Mechanism2d widget for a live stick-figure view of an arm, elevator, or turret.
• A raw NetworkTables tree view so you can see every key your code is publishing.

Reach for Glass while writing and tuning code; it is covered in the FRC software tools overview.

Elastic

Elastic is a simple and modern dashboard made by Team 353. WPILib describes it as a Shuffleboard alternative meant to serve as a competition dashboard that can also be used for testing, and its headline capability is draggable, resizable card widgets — a genuine drag-and-drop layout built for a high-pressure environment. It is a NetworkTables 4 client and is now available directly from the WPILib Command Palette. Its feature list reads like a checklist for a match dashboard:

• Viewing data from any NT4 topic through a range of widgets.
• Draggable, resizable card widgets — build a layout by dragging keys onto the canvas.
• A customizable color scheme with over 20 variants.
• Optimized camera streams that automatically deactivate when not shown, to save bandwidth and CPU.
• Automatic IP retrieval from the FRC Driver Station, so it connects without manual configuration.

Elastic also ships a small helper, ElasticLib, that lets robot code push pop-up notifications to the dashboard (INFO / WARNING / ERROR) — handy for surfacing a "battery low" or "vision lost" alert the drive team can't miss. Between the modern UI, its maintenance status, and being bundled, Elastic is what most competitive teams now standardize on behind the glass.

AdvantageScope

AdvantageScope is not a live match dashboard — it is a diagnostics and log-analysis application. It reads live robot data, but its real strength is reading WPILib data logs (.wpilog) and Driver Station logs (.dslog / .dsevents) so you can scrub through a match on a timeline afterward. It is the tool you open after a competition to figure out why the robot did the weird thing — not one your operator watches during a match.

Which one should your team run behind the glass?

• Match dashboard (behind the glass): Elastic — modern, maintained, bundled, and built for exactly this.
• Programming and tuning: Glass, for its real-time plots, Field2d, and Mechanism2d.
• Post-match analysis: AdvantageScope, for log review.
• Legacy layouts you already trust: Shuffleboard works this season, but don't start new work on it (and SmartDashboard is on the same 2027 clock).

You never change robot code to switch — everything reads the same NetworkTables data, so develop with Glass on the bench and run Elastic at competition.

Publishing data from robot code

All of the following are Java; the C++ and Python equivalents are nearly identical and are in the WPILib docs. For a broader intro to structuring robot code, see the programming tutorial.

The simple way: SmartDashboard / NetworkTables

The most common pattern is a direct put call. This works no matter which dashboard you are running, because it just writes a NetworkTables key:

import edu.wpi.first.wpilibj.smartdashboard.SmartDashboard;

SmartDashboard.putBoolean("Intake Loaded", intake.hasGamePiece());
SmartDashboard.putNumber("Arm Angle", arm.getAngleDegrees());
SmartDashboard.putString("Drive Mode", drivetrain.getModeName());

Call these periodically (for example in robotPeriodic()) so the values stay current. Each key shows up under the SmartDashboard/ table, and Shuffleboard, Glass, and Elastic can all subscribe to it — despite the class name, this is just a NetworkTables write, not something tied to the SmartDashboard app.

Sending an autonomous chooser

Almost every team needs to pick an autonomous routine before the match. SendableChooser renders as a dropdown on the dashboard:

import edu.wpi.first.wpilibj.smartdashboard.SendableChooser;
import edu.wpi.first.wpilibj.smartdashboard.SmartDashboard;

private final SendableChooser<String> m_chooser = new SendableChooser<>();

// In robotInit():
m_chooser.setDefaultOption("Default Auto", kDefaultAuto);
m_chooser.addOption("My Auto", kCustomAuto);
SmartDashboard.putData("Auto choices", m_chooser);

// When autonomous starts:
String selected = m_chooser.getSelected();

Put the chooser on a pre-match tab so it is impossible to miss, and read getSelected() at the start of autonomous rather than caching it early, so a last-second change still takes effect.

Sending the field and robot pose

Field2d gives you a top-down map of the field with your robot drawn on it — one of the highest-value things you can show a driver. It is published like any other Sendable and displays in Glass, Shuffleboard, and Elastic:

import edu.wpi.first.wpilibj.smartdashboard.Field2d;
import edu.wpi.first.wpilibj.smartdashboard.SmartDashboard;

private final Field2d m_field = new Field2d();

// Once, at startup:
SmartDashboard.putData("Field", m_field);

// Every loop, after updating odometry:
m_field.setRobotPose(m_odometry.getPoseMeters());

Laying out widgets from code: the Shuffleboard API

The put calls above drop keys onto the dashboard in no particular arrangement. Shuffleboard adds an API that lets robot code choose the tab, widget type, size, and position, so the layout is reproducible and version-controlled instead of hand-arranged at every event:

import edu.wpi.first.wpilibj.shuffleboard.Shuffleboard;
import edu.wpi.first.wpilibj.shuffleboard.BuiltInWidgets;
import java.util.Map;

Shuffleboard.getTab("Drive")
    .add("Max Speed", 1)
    .withWidget(BuiltInWidgets.kNumberSlider)
    .withProperties(Map.of("min", 0, "max", 1))
    .withSize(2, 1)
    .withPosition(0, 0);

withSize(2, 1) makes the widget two columns wide and one row tall; withPosition(0, 0) places its top-left corner in the grid (rows and columns are 0-indexed). One rule worth remembering: if you set the position of any widget on a tab, set it on every widget on that tab, or they will overlap.

The dashboard is also a two-way pipe. A slider or text field can feed a value into robot code — great for tuning without redeploying. Grab a GenericEntry when you add the widget, then read it each loop, always with a safe default so a disconnected dashboard can't feed your drivetrain a garbage number:

import edu.wpi.first.networktables.GenericEntry;

private final GenericEntry m_maxSpeed =
    Shuffleboard.getTab("Drive").add("Max Speed", 1).getEntry();

public void drive(double left, double right) {
  double max = m_maxSpeed.getDouble(1.0); // 1.0 is the fallback default
  m_drive.tankDrive(left * max, right * max);
}

If you position widgets from code, keep the layout definitions together in one place — a configureDashboard() method or a dedicated class. Scattering Shuffleboard.getTab(...) calls across ten subsystems makes the match-day layout impossible to reason about.

Designing a match-day layout

The hardest part of a dashboard is not the code — it is deciding what not to show. During a match your operators have no time to read, only to glance, so design for a two-second glance from someone whose adrenaline is spiking.

Put pre-match and in-match information in separate tabs. A pre-round tab holds the autonomous chooser, alliance/position selectors, and pit-checklist readouts; your match tab holds only what matters while driving. Both Shuffleboard and Elastic support tabs — use them.

Turn states into colors, not numbers. A driver cannot parse "3.7" mid-match, but they can see a big green box turn red. Publish booleans for states like "game piece loaded," "at target," and "ready to score," and render them as large color widgets. Reserve numeric readouts for the two or three values that genuinely need a number, like battery voltage and a mechanism setpoint.

Make the camera and the field the biggest things on screen. A live camera stream and a Field2d pose map are the two most useful match-day elements for most robots, so size them generously. Elastic's camera streams deactivate automatically when hidden, so keep secondary cameras on another tab to save bandwidth. If your vision comes from a coprocessor, the Limelight setup guide covers getting that stream and its targeting data onto the dashboard. And always show battery voltage — a browning-out battery explains a huge fraction of "the robot got weird" moments, and you want to catch it live.

Here is a reasonable starting layout for a match tab:

Practice with the real dashboard the way you practice driving. Run a full match on your practice field with the exact layout you'll use at competition, and cut anything nobody looked at. If a widget never earned a glance in practice, it is clutter on match day. Where you have it, use recording — Shuffleboard can play back a match and AdvantageScope can replay a data log — so you can review what the dashboard showed at the moment something went wrong.

Frequently asked questions

Is Shuffleboard being removed?

Yes. WPILib has deprecated Shuffleboard and it is slated for removal in 2027, citing a lack of a maintainer and resource-utilization issues. It still works for the current season, but new teams should build their match layout in Elastic rather than investing in Shuffleboard.

What is the difference between SmartDashboard and Shuffleboard?

SmartDashboard is the older, lightweight dashboard that uses few computer resources but connects over the legacy NetworkTables 3 protocol. Shuffleboard is the more capable drive-team dashboard with tabs, recording, and code-driven layouts on NetworkTables 4. Both are deprecated and slated for removal in 2027.

Should I use Elastic or Glass?

Use Elastic as your competition dashboard behind the glass — it is built for drivers, with drag-and-drop widgets and optimized camera streams. Use Glass as a programmer's tool for real-time plotting, Field2d, and Mechanism2d while you write and tune code. They read the same NetworkTables data, so you can use both.

How do I get data onto the dashboard?

Publish it from robot code with NetworkTables. The simplest way is SmartDashboard.putNumber("name", value) (and putBoolean / putString), called periodically. Any connected dashboard can then display that key.

Which dashboard does the Driver Station open automatically?

The FRC Driver Station has a Dashboard Type setting on its Setup tab (Default, SmartDashboard, Shuffleboard, Remote, and LabVIEW options). By default it launches the LabVIEW dashboard; change the setting to have it auto-launch SmartDashboard or Shuffleboard, or run Elastic or Glass yourself.

Can the dashboard send values back to the robot?

Yes. Widgets like sliders and text fields write back to NetworkTables, and robot code can read them — for example by grabbing a GenericEntry from Shuffleboard.getTab(...).add(...).getEntry() and calling getDouble(default) each loop. This is the standard way to tune constants without redeploying.

Pick the dashboard that matches the job — Elastic behind the glass, Glass on the bench, AdvantageScope for the post-mortem — publish clean data from robot code, and design the match layout for a two-second glance. Do that and your drive team will spend the match reacting to the robot instead of squinting at it. For more walkthroughs, browse the full guides library.