What does the dashboard for your robot look like?

With robot software becoming more advanced, and with team’s robots collecting more data on their own and relaying it back to drivers, What does your robot’s dashboard look like? Does it include a field map with your robot’s position on it? Speed? Hood Angle? Status Lights? Camera Feeds? I’m curious what data people choose to have on their dashboards on their robots.


our dashboard is a default shuffleboard with a mess of buttons and readouts to test mechanisms, most of which dont do anything anymore lol. for real though, our drivers dont want to take their eyes off the field so any status we need to show is on our robots leds


Google Photos

We created a custom dashboard in ImGui with some basic plots for shooter speed and hood angle along with a field display.


We have the status of the two sensors in the conveyor, auto route, limelight feed (not that we use it since we auto align and shoot), and a webcam feed for the intake

1 Like

We used shuffleboard with this info:
Boolean of if ball is loaded
Text of what color
Boolean if at target shooting rpm
Boolean if shooting close (we used pneumatics for our shooter angle so it only had two states)
Text of match time
Selector for auto

All of these really big so it can easily be seen without having to focus on it

uhh…why is the robot targeting your HP? lol Do you update the field map with the robot location during the match?

Yes, big readable text is important.

The robot initializes to (0,0) when we start code and resets to the correct location when we run auto / shoot from the fender in teleop.

Yes, the view dynamically updates as the robot moves around; I just took the picture in the pit during startup


Here is a picture of our dashboard. We use shuffleboard. A lot of it is mostly debugging print outs that can be helpful in diagnosing issues during a match, however I would say a lot isn’t used and could probably be removed or updated.

Here are some of the things it includes:

  • Our limelight stream and a camera plugged into the roborio’s USB port.
  • Our auto selector
  • instant commands to override some of our automation.
  • Shooter information including alignment offsets and shooter speed
  • On the fly shooter adjustment buttons

During PNW district champs we added the ability to adjust our shooter equation on the fly as we noticed inconsistencies in cargo were heavily effecting our shooting.


It’s possible to have the dashboard be very different at times – for example, in test mode vs. in auto/teleop. It’s also possible to click a button and open up a new tab. We had a tab for each swerve module, one for the drive subsystem, etc. – but, the majority of the stuff was only up in test mode. Further, we had graphs for tuning controllers (PID, Trapezoidal, etc.) that were on tabs that only opened up if something else was clicked. This approach meant we could eliminate most of the clutter (and processing) during a match, yet could control individual actuators (kind of like with Phoenix Tuner or REV Hardware Client) from test mode. This was done with Shuffleboard.

1 Like

Almost everything was just for the drive coach to help debug the most common issues in real time.

I’m particularly proud of those gauges though, just because they can be comprehended on 3 levels:

  1. Fast & Coarse: Bar is either Green or Red, for pre-defined ranges of “OK” and “Not-OK”.
  2. Medium: You can observe the size of the bar and its motion to derive some basic info about how the value is changing.
  3. Slow & Precise: Read the big number under it.

The concentric circles and arrows for our swerve modules is something I was introduced to back in my college days and carried forward into FRC.

The auto selector purposefully separates the “user input” and “feedback from robot” parts so we can program it in a way that guarantees if the robot has processed the command for auto mode, the dashboard won’t report anything.


what’s the drawer of jello on the left


In case the drive coach gets hangry


You don’t take a drawer of jello out to the field? My friend, you have not yet lived.

It’s plastic, designed to look red and cool.


dangit I wish I had thought of that when I coached


Incredible dashboard! Can you explain how you have done it? Or can you publish the related code? Thanks.

1 Like

Sure thing! 2022 robot code is here.

Some key points of interest:

  1. Here’s the web content that actually forms the “front end” of what you see in the picture
  2. Here’s the webserver that serves those files up to any browser that requests the webpage.
  3. Here’s the back-end implementation of something that is almost NetworkTables 4, for streaming data from robot to dashboard.

If you want to try for yourself, it should be as simple as:

  1. Clone the repo
  2. hit F5 in vs code and launch in simulation
  3. Once the robot code is running, point a web browser to localhost:5805.
  4. Enable in Autonomous to see shiny things move around

The background: Way back in 2016, we put in time to invent our own web-based dashboard (heavily borrowed from something 254 had done in previous years). No real competitive advantage to it, just a fun side project that turned out to be fairly useful. It involved a custom websockets protocol that was completely outside NetworkTables.

We evolved it over time, most signifigantly incorporating @Oblarg’s oblog annotation-based methods for marking “This class member is important, put it on dashboards”.

In summer 2021, we had time to revamp the whole thing. A lot of the work was front-end, but we also took the time to align the data protocol and architecture to @Peter_Johnson 's in-flight NT4 specification. If you notice, what we have is (mostly) compliant with a version of the spec from last summer, not quite latest. But it’s close.

The goal is that when NT4 and oblog-like features are mainlined to WPILib (ideally this summer?), it’ll take out ~75% of the back-end code you see in our repo. Pending how well that transition goes, I’m hoping to contribute at least lessons-learned (if not some code) toward WPILib’s longer term goals of supporting web-based dashboards.

To be clear: I’d not recommending our approach to anyone. It was born out of a dislike for SmartDashboard, and a lot of spare time and luck. But it might be a good exercise to study one particular way of getting data from the robot to the driver’s eyes in a particularly shiny way.


Thanks for sharing! When l open you project , there seems to have some errors.

Do l need to update the pathplannerlib myself?

Edit: l change the PathplannerLib to 2022.2.1 and the bug is fixed. That’s strange.

We made a custom HTML dashboard this year to show the driver useful information during the match

In the top left corner is the driver camera. The top right corner has the targeting info, with the targeting camera and booleans for the stages of ready-to-fire. The balls were shot automatically when all three turned green. The bottom right corner shows the position and color of the balls held by the robot. And the bottom left corner shows the robot’s position on the field according to its onboard odometry. There is also a match clock at the top in case the coach can’t see the official timer on the far side of the field.

We also made two other web dashboards for use at home.

Our shooter utility helped us retune our flywheel distance-velocity function quickly and accurately. We could save five “preset” velocities and directly set the flywheel speed to those with a single click. Then we could make fine adjustments until we were satisfied with the slider at the bottom. The graph on the right allowed us to monitor the responsiveness of the PID to ensure that the flywheel was actually hitting the speed it was being set to. Note that all the m/s should be rpm.

The ValueTuner dashboard allows us to change constants for different mechanisms on the robot in real-time without having to redeploy code each time. This was very useful for tuning PIDs, timing automation routines, etc.


These look really cool, are there links to code for them?