I recently went to a seminar hosted by Team 20 for RobotBuilder. I’m not to sure on my opinon on it and would like for others to tell me what they think of it! So please tell me, is your team going to use it? if yes How?
~Programmer from Team 3044

Personally, no, but it’s great for training younger/less experienced programmers or to help transition from Labview to Java.

No, but it does allow me to demonstrate concepts to new kids in a way that bad drawings on a white board can’t.

My team personally was thinking of just using it to start the program, especially with our new programers

For those wondering what is being considered here (like me, for instance) refer to this location at WPI Lib. Google insisted on dividing the two words and also netted this interesting, if a bit ancient, link.

Gee Whiz, a whole 'nother avenue for exploration. Thanks guys, I guess. :smiley:

We beta tested RobotBuilder with the C++ environment so I’ll offer my perspective of it’s usefulness.

I’m not a programmer but I have written a lot of code in Assembly Language, Basic, C and Ladder Logic. When the cRIO came along in 2009, I started with the simplest program that would compile and crammed a lot of sequential C code into the environment. It worked but it wasn’t very inspiring for future programmers. Then a young student committed to learn C++ properly and he started creating properly structured programs. Now he has graduated we could easily slip back to sloppy structure.

Enter Robotbuilder. Instead of starting with a minimal program and trying to adding things, Robotbuilder lets you list all of the subsystems that your team has decided are important for your robot. you can enter the motor controllers and solenoids for outputs and limit switches and potentiometers for feedback and the operator inputs necessary to operate it. All this is independent of program syntax or structure. Then Robotbuilder creates the proper structure for the program for both Java and C++ and allows you to pass the structure to either NetBeans or Windriver. At this point the program doesn’t make anything move but the structure is all there. Then you can start adding the code connect outputs to inputs to make things happen.

Another advantage of using Robotbuilder is to aid in wiring and troubleshooting the robot. Most years with our team, the wiring gets done before the controls drawings are made and when the software people start to trying to make anything work many things are misplaced or just defective. PID loops are especially difficult to determine problems with motor and encoder direction etc. so troubleshooting takes hours.

To counter these problems, Robotbuilder lets you generate a wiring list so the wiring people have the right information to hook things up. Then, with Smartdashboard, the Livewindow screen is populated with controls for each device you configured. You can see each input and operate each motor independently to find all the physical problems before you have to write code. this has the potential of saving hours trying to isolate code problems from hardware problems.

How does it work? As with any completely new concept, we ran into lots of problems getting things to work. If all the bugs get worked out by kickoff this will be a great boon for new teams and teams that lost their programming expertise. If there are still bugs it could be worse than just creating a minimal program.

Back to the original question, we will use Robotbuilder as that is the only way it will get stressed and debugged. If I understand it I can help new teams that use it because their structure will be predictable. At this point the Java version of all this is more stable than the C++ version so all this should apply to both.

I hope enough competent programmers use these tools to help make them stable as quickly as possible.

I didn’t even know this tool existed… This will be an amazing help once build season starts, if only to keep us accountable to the high-level design. I do have one issue though, and I’d like to request a feature.

My request is to have an option to export to the same directory where the .yml is stored. I’d like to be able to store it in a git repository with the rest of the project, but currently there are two problems: a) the export path is absolute, meaning that if two people clone the same repository in different places, they’ll have to maintain separate export paths (almost more trouble than it’s worth), and b) when I tried to trick RobotBuilder into exporting into a relative path by changing the .yml to use “.” as the export directory, it output to the directory I was running it from (~/sunspotfrcsdk/tools/). While this second behavior makes sense from an implementation standpoint, it isn’t helpful to users like myself and makes what would otherwise be a tremendously useful tool sadly impractical.

If any of you know how to contact the devs with feature requests, let me know how or just point them to this post! :wink:

RobotBuilder is built to generate classes for the CommandBasedRobot template. If you’re using that part of WPIlib anyway, RobotBuilder will be a nicer frontend for it than the standard netbeans plugin, and some of its features will be nice, but it’s otherwise useless. Otherwise, I doubt it’s worth switching just for RobotBuilder, especially given that it’s two week from kickoff.

tl;dr use if it you’re using Commands already, otherwise stay away

I wouldn’t necessarily agree – besides the fact that there’s few reasons not to use command-based in the first place, RobotBuilder also outputs wiring diagrams for the mechanical/electrical teams to follow.

What would you consider to be the top 3 reasons, and why?

I posted it in the beta bug tracker. I also posted that the public RobotBuilder project doesn’t appear to accept tracker entries except from project members.

Let me first say that I’m sure there’s many FRC teams to whom much of this wouldn’t apply, and who could create equivalent or superior solutions on their own. For most teams though, it’s analogous to using the kitbot on steroids vs a homebrew chassis, and using a standard model with modifications to fit specific needs will ultimately work better than developing a custom solution, while reducing overhead and allowing you to focus on the stuff that matters most.

  1. Structure. All the code pertaining to the Operator Interface goes in one file. All the code pertaining to the Drivetrain goes in another. Newer programmers tend to find smaller blocks more easily digestible and less intimidating than monolithic chunks of code, ime.

  2. Extensibility. While it takes more time, effort, and complexity to get the basic functions of the robot set up than it does with Iterative, it’s generally faster to add new functions to the robot once that’s done. Once you have the commands written, it could literally take less than an hour to write a fully functional autonomous program by stringing them together, whilst using parts of those same routines in teleop as well.

  3. Because that’s the direction FRC programming seems to be heading in, and the documentation is becoming increasingly tailored for it. Not an issue for some teams with lots of older code to look back at, or teams with great programming mentors, or students with lots of programming experience. Many newer teams don’t have any of those, and and for them the best-documented solution is probably the best one.

Thanks! That’s exactly what we’re trying to do with RobotBuilder.

I’ll pass it on.

F22Rapture: We wrote a program from scratch for GearsBot (the VEX robot that’s used to show off new code) in less than an hour. Writing code for a FRC robot won’t take that little time, but it should certainly be a lot faster than it’s been in the past.

An update on the post I made above:

A new Beta version of Robotbuilder, WPILib for C++, and Smartdashboard were released a few days ago and we were able to test it for a couple of hours.

Many of the bugs I alluded to above were fixed. The things we had trouble with may be related to misunderstanding and ignorance rather than real problems.

Our perspective is that Robotbuilder is useful with or without Command based structure. We tried Command structure last year but defaulted back to our old methods because we didn’t have time to learn it properly.

Robotbuilder creates code based on the Iterative structure that I prefer because of my Programmable Logic Controller background. managing multiple subsystems with minimal overhead is much easier once you are used to it. We are still unsure whether we will use the Command structure this year but we will use Robotbuilder.

The Livewindow feature works now with a new Test Mode and I’m looking forward to this enabling new teams as well as our newer members to get more involved with debugging. We didn’t have time to test a PID loop but we will before kickoff.

I’m much more hopeful that this will be a great addition to the FIRST programming world.

Thanks for putting this kind of effort into making programming more approachable . Since most schools in the country don’t have serious programming classes, this really empowers the students. I look forward to trying this for Java development in FRC.