After a year of development, Team BumbleB 3339 is excited to announce BumbleBoard — a high-performance, customizable, and reliable dashboard alternative built with React.
We developed BumbleBoard to meet the demanding needs for FRC teams, ensuring low latency, intuitive customization, and powerful new features. After extensive testing during the 2024 season, we’re confident it can enhance your team’s experience both on and off the field.
Why BumbleBoard?
Performance First: Powered by React’s virtual DOM and our optimized architecture, BumbleBoard minimizes latency for seamless real-time updates during matches.
Built for Customization: Create a dashboard that works for your team with a highly flexible and easy-to-use interface. For examle:
– Control the canvas grid size.
– Make your own theme.
– Tabs can be drag-and-drop.
Key features
Supports multiple entries in a single graph widget.
Includes indicators for string entries, such as enums, for better clarity.
Supports drag-to-select widgets.
Retains all the familiar Shuffleboard features and improves upon them.
And more!
Current Status
While BumbleBoard isn’t currently open-source, we’re gauging community interest. If there’s sufficient demand, we’re open to making it available to the FRC community.
Looking Forward
We’d love to hear your thoughts and feedback!
What features would you like to see in an FRC dashboard?
What specific challenges or limitations do you encounter with Shuffleboard that you would like to see addressed?
Feel free to ask questions or share your dashboard requirements. We’re here to discuss how BumbleBoard might help your team!
Closed source and windows only are both large negatives.
What positives does this give over Elastic? Elastic is the modern standard for a dashboard- it’s well maintained, open source, and bundled with the WPILib installer.
I don’t see the advantage of using this over Elastic, especially since from what I can tell, it’s extremely similar or even identical to Elastic in terms of visual design and functionality.
Closed Source and Windows-Only:
BumbleBoard is currently closed-source and Windows-only because this is our first release, and we wanted to focus on delivering a stable, high-performance experience. However, if there’s sufficient demand, we’re open to making BumbleBoard cross-platform and open-source in the future. In fact, we’re already planning improvements, and a new release is expected next month.
Comparison with Elastic:
We began developing BumbleBoard before Elastic was released, and when it was, Elastic didn’t meet our specific requirements. BumbleBoard was designed to include unique features that Elastic currently lacks. For examle:
Support for multiple entries in the same graph and Text indicators for displaying values like enums, states, or other text-based data.
Elastic certainly has its strengths. However, BumbleBoard is designed to meet more requirements, and we believe it offers unique benefits for teams looking for specific functionality.
We’d love to hear your feedback after you will try BumbleBoard
Omission of these features is intentional. The modern WPILib ecosystem distinguishes between “driver” dashboards (auton selector, camera streams, indicator lights) and “programmer” dashboards (post-match analysis and debugging tools). Elastic is a driver dashboard, so it omits diagnostic features that would distract drivers mid-match (the driver’s role is to drive, not troubleshoot). One could argue Elastic shouldn’t have a plot widget at all.
The other concern with serving both purposes in one tool is maintenance burden; that’s how WPILib’s SmartDashboard, SFX, and Shuffleboard dashboards died. Saying no to some features can help projects stay maintainable in the long-term.
It doesn’t really have to be better or distinguishable from elastic tbh. It’s 3339’s tool that they’re releasing out to the public in case anyone finds it useful.
It may be worthwhile to remember this is a High School robotics program with the goal of inspiring students to build skills in STEAM fields. Shifting the tone of this thread to educating rather than just pure criticism of the project would serve Amit & the community better.
Let’s encourage, educate, and build up students so they can grow to be meaningful contributors to FIRST, and beyond. Releasing open-source code can be intimidating, especially for a new programmer. Students are excited about the projects they work on, I’d be disheartened if as a high schooler I shared what I built and it was met with nothing but critique.
BumbleBoard can serve as both a “driver” and “programmer” dashboard. Like Shuffleboard, it allows users to create and switch between different layouts, making it easy to adapt the interface to specific needs — whether for drivers during matches or programmers for debugging and analysis.
We originally created BumbleBoard to meet the specific needs of our team. Once it was finished, we liked using it and thought others might find it useful too. That’s why we decided to share it with the community.
Hi,
I am a mentor of the BumbleB’s software team.
As written by our students, we were not trying to compete with any other dashboard. We thought it would be good to have a single dashboard to be used while practicing at home, debugging the software, calibrating systems, working in the pit and serving the drive team during the game, mainly because it will be in constant use and thus will become more powerful and stable with time.
I agree that it has pros and cons, but this was the approach we chose.
It made us work harder on the architecture and the variaty and customization of widgets, as well as on the performance needed for debugging which are more challenging than drive team requirements.
We ended up with a result, the students were vey proud of (as well as myself), and we thought other teams that like our approach may benefit from it.
In the spirit of FIRST we hope other teams will enjoy our work, and if not, this is OK as well …
We would appreciate any constructive criticism that will contribute to making BumbleBoard better.
does R303 even allow this sort of non-vendor closed-source thing? it seems pretty clear that you have to publish “source” files for “robot software” written in advance. the term “robot software” is not defined anywhere, so you could argue that it means RoboRio software, but I would argue the opposite.
Fair. TBH i don’t really care what CD thinks, i just want HQ to clarify the rule. I mean, it would also be cool to clarify the part of that rule that led to so much argument several months ago, with “clean room” claims from non-disclosers, etc. Do you know who might be able to nudge that along at HQ?
Now that I think about it, this is one of the only “hyped” CD topics that FIRST didn’t solve/address. Amazing to see how well FIRST handled all of these, and hopefully how they’ll handle this one.
There are people far more connected than myself. Maybe I will get more connected when I finish this blasted PhD and have more time.
However I tend to use the Q&A to “force” a response from HQ (or at least the GCD) on a few things, in theory we at least then have a precedent which is better than nothing. E.g. TPU and hard plastic studs last season.
