RobotBuilder Successor: Request for Community Collaboration

Technical Programming
1

tl;dr: Check out the proof of concept demo at slfc.dev/command-bindings/ and post your feedback here

Programming an FRC robot needs a lower barrier to entry

RobotBuilder was created back in 2012 as a tool to generate code projects and the skeleton code for a command-based robot program with subsystem and command classes defined based on input in the GUI. What it didn’t do was provide a way to define the behavior of those commands, which left a lot of room for error for inexperienced programmers.

It’s been ten years and RobotBuilder’s maintenance can be best described as “life support”. It has the barest support for the command framework, and no support for all the new additions to the software stack that have been made since it was created. Its use has, unsurprisingly, diminished significantly. Only 87 teams used it last year out of 3,225 registered teams. 2020 usage was even worse, with only 35 teams of 3,914 (less than 1%!).

Its niche, however, is still very much needed. I often see posts on this forum and on the discord from programmers trying to figure out how to do some simple action or how to structure their code and think, “man, this wouldn’t have been a problem if RobotBuilder had been kept up to date”

So, on that note…

I’ve been hacking on a sketch of an idea in the same vein as RobotBuilder. It started as a UI for binding commands to controller buttons (thus the name “command-bindings”), and eventually feature crept its way into something that would be very close to RobotBuilder. I’ve decided to take it all the way, and make it a proper replacement.

A proof-of-concept demo is live at slfc.dev/command-bindings/. It’s not feature-complete but is enough to give an idea of where it’s heading.

Goals

  1. Tight integration with the WPILib vscode extension. The goal is for this to be used as the default way to create new robot programs. The current new project tool would still be available as an advanced option for experienced programmers
  2. Make the easiest, most obvious way to do something be the correct way of doing it. It’s easy to use loops and naive thread sleeps when you’re not familiar with the command framework or WPILib in general
  3. And most ambitiously: Go from zero to driving without writing a single line of code, in less than 10 minutes.

Where you come in

I don’t want ownership and maintenance to be solely on me and my availability; it needs to be self-sustaining in some way so it doesn’t suffer from bitrot like many (or, honestly, most) WPILib tools have.

  • Feedback on architecture. The proof of concept started from a controller-based orientation, then pivoted to a component → subsystem → action → command model. Anything that doesn’t fit into that model (for example, how will RAMSETE controllers, path following, and pose estimators fit in?) would need to be looked at to find the best way to integrate them
  • Collaboration. Community ownership of and contributions to features and core design (internal APIs, data structures, and so on). This isn’t going to be a one-man show
  • Setting goals. Driving features that we should support (and, conversely, ones that we shouldn’t )
  • Feedback. Even if you don’t want to write any code, just trying out the app to see if you can get code that does what you need is itself very valuable. See if you can rewrite the code for this year’s robot, or just try making a new project from scratch and see how far you can get

Links

Demo: https://slfc.dev/command-bindings/
Github: https://github.com/SamCarlberg/command-bindings (React, TypeScript)

The project name is subject to change, since it’s now more than just binding commands. I’ll update the links if it changes

18 Likes
2

Progress up to this point: basic UI and code generation for implementing behavior for commands. It’s possible to pipe sensor output into a PID controller, then feed the controller’s output into motors to make it move. Commands can bind to actions and be sent to a dashboard or bound to a controller button.

These changes have been pushed to the github repository and are now live on the demo site: https://slfc.dev/command-bindings/

The drivebase template has been updated to include this behavior by default, for demonstration purposes.

3 Likes
3

This looks very interesting! I have an idea regarding the UI: instead of the current system you have, which requires multiple clicks to change any code, what if you used Google’s blockly open source project? I don’t have deep enough insight into your project or how blockly works to say whether or not the change would be smooth, but to my knowledge blockly operates fully on the frontend, can generate custom code, and can save the blocks in json format for future loading.

4

I wasn’t aware of blockly when I started. It looks interesting, but one of my goals for the project is to communicate with concepts more than code. Blockly doesn’t look to be as useful when operating on higher level concepts.

5

Well i must admit those numbers are surprisingly low. As a member that feels like I’m one of the life support administrators and how I present a large group seminar on Robotbuilder usually 3 times a year with countless one on one session I don’t want to loose a tool like Robotbuilder. I wonder if you had accesse to the tracking data with team numbers if the heat map of team locations would glow over Minnesota.

With the low numbers I do ask myself how many teams might use Robotbuilder to spin up some quick test code that doesn’t make it to their competition code. I probably create a few dozen applications a year myself.

I will go check out this tool and I promote it when its ready for prime time. Thanks for identifying that there is a need for this type of application.

1 Like
6

funny thing is I was looking at robot builder yesterday to see what it could do and I was awfully confused on how you get further than defining things. I really did think that everything could be done in robot builder (as it should be). Very cool idea.

1 Like
7

Im getting a cert error trying to visit the site:

image
image991×629 18.3 KB

8

Yikes! Thanks for letting me know, it should be fixed now.

1 Like
9

Looks good to me now! Thanks

10

You don’t. RobotBuilder will generate the project and your classes, and some things like button bindings and dashboard data. But it’s up to you to write all the code needed to actually do things. There’s no way to define behaviors for commands and the subsystems they use. A key goal for the rewrite is to let users set up common of subsystem behavior without having to write any code themselves.

11

yeah I had figured that out

12

New update: components can include templates that can be used to add new states, actions, and commands to the subsystem when the component is created. Right now, only the Differential Drive component supports templates, but the PID Controller is another great target for templating. Defining a new atTarget state, along with a setTarget and a moveToTarget action, all bound to a single command that takes in a setpoint and runs until the controller has hit the target position.

In the long term, templates like these will be crucial for reducing the amount of FRC programming knowledge required to use the more advanced parts of the library.

These changes are live on the demo site and have been pushed to the github repository
slfc.dev/command-bindings/

4 Likes
13

Blockly does allow you to define your own blocks. Depending on how high-level you want to go though it might be hard to describe the sorts of concepts you want however.

I’m imagining though that defining new commands and subsystems could be their own blocks, and common WPILib classes could be blocks too, though there does become a point where it becomes more cumbersome than it might be worth.

14

The goal is very high level. Right now, the interface maps pretty cleanly 1-to-1 to the code. My aim is to have an interface that lets you say “drive motor X based on the output of sensor Y” or “extend this piston when I press the right bumper on the operator controller” and have it spit out a set of relevant components, actions, and commands. Rather than working up from the bottom and focusing on code → commands → OI, I want this to be top-down and make the lower-level stuff accessible, but not be the default way of interacting with the application

15

Seems like an extreme oversight to not have CANSparkMAX’s, TalonSRX’s, and VictorSPX’s no?

16

Remember this is a demo of the early stages of progress. Other types of motor controllers will be supported in the future, but spending time on those isn’t terribly helpful for nailing down the core data and logic for more important things like templates

1 Like
17

Can simulation be added? (Maybe based on a checkbox or something?)

Having generated simulation code would really raise the floor for using sim. Though I admit that vendor simulation is a problem.

1 Like
18

That’s partly why I added it to YAGSL. It is extremely helpful especially for swerve. I would love to learn Mechanism2d but haven’t had an excuse to yet.

19

Yep, simulation’s on the roadmap