ShuffleBoard vs Custom Dashboard

Hey everyone! I have been wanting to implement a custom dashboard for my team for a long time now, and I finally have the time to do it. However, I was wondering if my time would be better served simply putting together a ShuffleBoard configuration. What are the pros and cons of each? I’ll add that I am decently familiar with Desktop Application programming.

We’ve made a custom dashboard for a few years now as a webpage locally-hosted on the rio. It’s worked well for us, but I will say it’s a nontrivial amount of work for minimal gains. We reconsider every year whether it’s worth it and only implement it if we have extra programming manpower. As far as the actual implementation, I’ll tag @barel13

I thought it’d be nifty if we could have a networktables or something datasource for Grafana Live

1 Like

Shuffleboard is essentially stable abandonware at this point, and I don’t really recommend it given its persistent resource-usage issues (which is a pity, because I really like the API and design philosophy, enough that I wrote a wrapper library to invoke it through annotations).

Look for some new dashboard infrastructure to be available for the 2023 season to help support Shuffleboard-esque configure-display-from-robot-code functionality even when using custom dashboards.


Are we sure we want configure display from robot? I think it should be describe the data from the robot, but allow the configure the display from the display.

I think otherwise you have an unnecessary binding between the data and the display.

Maybe consider instead of describing “tabs” from the data side you configure tags or keywords.

You should be able to configure the display from both the robot code and the dashboard. There are valid use-cases for both.

Sometimes you want a robot to pull up a sensible default dashboard on the DS, but don’t want to go through the hassle of yanking the dashboard config from the DS computer on which it was defined. Sometimes you even want the robot to define its dashboard implicitly through its code structure, so that you don’t have to worry about populating the dashboard - this is super useful when doing quick-turnaround testing where the robot configuration might be changing rapidly and changing the dashboard to match would be a pain.

One of the key workflows Oblog (the aforementioned annotation binding library I wrote) supports is the ability to slap an annotation on a field in your robot code, and have it automatically pop up in a sensible place on the robot dashboard, with a sensible widget. This (or something comparably simple) is crucial functionality, to my mind. Oblog accomplishes this through a heap of runtime reflection (all at boot-time, though!); I’m hoping to make the “official” spec/implementation a little bit simpler.


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.