This season, our team is debating whether or not to switch from IterativeRobot to CommandBasedRobot. What are the pros and cons of each option?
When we transitioned from LabView to C++, we chose Command Based over Iterative for one major reason: RobotBuilder and the associated Command Based framework
We have a pretty limited level of programming expertise (but a large number of ‘programmers’ to keep busy) and the RobotBuilder/Command Based framework gives a nice structure and way to manage many different pieces. Also, the paradigm of subsystems and commands allowed us to easily split up “assignments” to different programmers without having to develop a similarly sophisticated framework in just IterativeRobot.
There are fans and haters of RobotBuilder, but it has worked well for us for the last 2 seasons and we plan to continue with Command Based this season.
We have also found that RobotBuilder provides more structure for students with little or no programming experience. It creates good templates with all the language nuances in place. This lets us discuss how to make the robot do what we want and without explaining lots of C++ before we even start. At the time, we were also making the jump from LabView to C++.
The command-based robot project which comes out of RobotBuilder provides good object-oriented skeleton for creating subsystems and commands.
That said, this is our third or fourth year using RobotBuilder, and it has had some problems over this run. We have always been able to find plenty of support, and one of our mentors has even made local changes to extend it for CAN Talons last year. These were pushed back to FIRST and the rest of CD (Java source code is available for RobotBuilder).
We are local here in San Jose, and please feel free to contact our team if you need more info or support.
Command based is much more robust, distributive, and reusable.
It is robust in that it lets you do more things, and creates a default architectureto do the m in. Distributive means that more than one person can work on it atthe same time. The bunch of files means that joe can work on one subsystem while jane works on another, and integrating them is fairly easy once you get the hang of it. And reuse means you will build a on term library. We published our drive base code from last year and then this year we just picked it up and dropped it in.
We have a work in progress development guide that helps keep track of how to build acommand based code. Lots still to fill in, but we found the online guides lacking a lot. Its at team5401.org under Resources -> Tutorials
If you have been using iterative and understand it, i would recommend sticking with it at least till off-season just so that you don’t need to learn anything too new in the middle of build season.
This is sound advice. I think Command-Based is pretty nifty as if you have a robust set of basic actions/commands programmed, it makes building automations and autonomous routines pretty easy. But there’s definitely quirks to the framework that can hang you up.
I definitely prefer CommandBased because of having commands and subsystems split out into separate files. Yes, managing all the files can be a little hard and the structure can get confusing (most of the time it’s me going “wait, did I declare that in this subsystem or that one??”) but overall, it keeps everything clean and spread out so that if you break something it’s easier to fix.
Not sure if you’ve read it, but this is the reading the previous head of programming had me read that inspired the use of the CommandBased robot: http://www.laputan.org/mud/ It’s an interesting read, I suggest you take a look.
Iterative is more straightforward. Once you chafe at the restrictions that iterative imposes on you, switching to CommandBased will probably feel like a breath of fresh air. Before these frameworks came out, it was really hard for a student programmer just learning programming to do anything with coding. Now, with a rudimentary understanding of C++, they can successfully create new commands and work on Subsystems. More experienced student programmers can do the whole thing.
Doing more than one thing at a time in Iterative is complicated (i.e. driving while moving an arm). In CommandBased, it’s easy.
I tend to avoid the RobotBuilder because I want to explain what we’re doing as we go along, but the code it emits is not all that different from what I would code by hand (that is, before you have to put your logic in).