Which one do you use? Yes, I’m aware that Command-Based uses IterativeRobot, but I’m more referring to whether your team uses Command-Based or not.
Please feel free to explain why too, to help teams that don’t know which one to go with.
I’ll start off with my reasons to use IterativeRobot instead of Command-Based. Note that this is my opinion only and I completely understand the benefits of both systems.
We use iterative because it lets us do things like this. We can make as many “Robot” classes and switch between them with a simple array. Along with this, we can use this class to call all of the methods within it, and catch any errors. This eliminates a lot of the frustration that comes with NetConsole and Netbeans being needed to debug. Using Iterative also lets us custom tune loops, threads and other things that are kind of “taken care of” in Command-Based. For a lot of people it makes it easier, but I’m a big fan of our custom loop times, delays and fixed-rate execution. Sure we could do it in command-based, but then a lot of the point of command-based is gone.
The part of command-based (well, the idea) we use is Commands. Yes I know that sounds ridiculous, but we have this class that lets us call run() anywhere we need to. We have some basic commands that perform actions on interfaces (“SetteableNumber”, “SetteableBoolean”, etc.). It lets us not get clogged up in commands that use specific subsystems. (eg. requires())
Iterative also makes Gordian deadly simple to use. Calling new Gordian(stringFromFile).run() in autonomousInit() beats anything else I’ve ever used.
I also hate the performance of Scheduler. We spent a lot of time dealing with problems I’ve found rooted in Scheduler not running consistently. (Specifically SmartDashboard buttons)
1 Like
We use command-based because it provides a framework with some degree of abstraction which is also fairly well documented and supported.
Our software team usually consists of 1-2 students plus me, and I’d rather act as a mentor than a programmer. My job is to be a safety net, giving the students a sense of confidence so they can try to solve problems that they may not attempt if the success of the season was solely on their shoulders.
If we were creating much more sophisticated robots then I see the advantages of a bespoke framework, but command-based provides a good sandbox for learning about OO-design, modularity and maintainability.
We use IterativeRobot. This is mostly because we switched to Java last year (so we’ve used it for two years) and it worked well enough for us both years.
I see the Command-Based framework as writing a large amount of code for you, which makes it much harder to debug when a program doesn’t work.
We also have a Java class being taught separately at our school, so we can require that all Software students are taking this class or have equivalent experience, so that we don’t need to worry about teaching anyone how to program.
We haven’t actually programmed our robot using the Command-Based framework yet, but if we’re going to use a complex framework, we’d rather write the framework ourselves during the preseason (and release it, of course), so that we have someone on our team who knows how the framework works and how to extend it.
We use IterativeRobot, C++
From what I’ve seen, I think command-based is easier to use for “simple” stuff. Being able to use command groups, having the built in sequential/parallel functions makes it pretty simple for teams to get fairly complex behavior from their machines.
That said, the implementation of command-based, command groups, and the like does make doing some stuff harder…
I mentioned it in another thread a while ago, but to reiterate… our climbing sequence was really easy to create as a command-based sequence - each step followed the next, and we ended up at the top of the pyramid. However, we encountered some difficulties adding more complex behavior to the sequence. For example, how do we tell it to stop the sequence halfway through and restart? How do we tell it to back up one step? In the end, we determined that adding these behaviors was something we didn’t have time to do (including testing to make sure they worked as intended with no side-effects!). As a result, there were a couple of matches this season where we were unable to successfully climb.
Now, if we had set this up iteratively, it would have been a little harder initially, as we would have had to create the sequential/parallel structure we used, using internal variables and conditionals. However, it would have been very easy for us to then manipulate those variables to adjust our position in the sequence.