Hello all,
Since I’ve been on the team we (3630) have always used an interative-based robot. While it has worked for us well in some respects, it seems to me like command-based programming is more popular and in some cases a little simpler. Am I thinking about this the right way? What should we keep in mind while making the decision to switch?
We. I love the command based system and have helped a few team move to it. I always point them to these. [http://FRC 2013 RobotBuilder: https://www.youtube.com/playlist?list=PLYA9eZLlgz7t9Oleid2wtlgnvhGObeKzp](http://FRC 2013 RobotBuilder: https://www.youtube.com/playlist?list=PLYA9eZLlgz7t9Oleid2wtlgnvhGObeKzp)
In my humble opinion (for what that’s worth), command based is much simpler to use that iterative if you do any parallel processing, because the command scheduler frees you from creating a state machine (or whatever other mechanism you choose) to take care of what needs to be happening each iteration. The following is meant to augment the description of command based programming on screen steps.
The development process I use with the team for Command Based is:
Decide what the subsystems are, what controls they contain, what they can do and what feedback they can provide.
Decide what discrete operations we need the robot to perform; these become commands. Note that a command can “require” one or more subsystems, which cause them to interrupt another command that currently is running on that subsystem. Decide how you know when a command is “done”. Decide what a command should do when it is done.
Make sure we have the subsystem methods to do the things and provide the feedback the commands need.
Rough out the commands design to incorporate the subsystem methods.
Code a command. We typically allow commands to call OI methods (using the static CommandBase’s OI object) to obtain Joystick axes and use them in the Execute() method to feed values to the Subsystem methods. Note that subsystems can have a default command that runs when no other command is running; our drive subsystem normal has a default command to use the joysticks to drive.
Hook your command to a OI button (you can also use SmartDashboard to launch commands if you’d rather) in OI.CPP.
Test
Go back to step 5 until out of commands
Test simultaneous commands that are supposed to run together
Write command groups to string multiple commands together. Test each.
Write autonomous routines using command groups.
IMHO, command based is not necessarily simpler. It appears so because it provides a framework for concurrency for which a lot of high school students may not be able to do without it. However, if you don’t need concurrency, iterative is a lot simpler concept wise. For our team, we don’t use command base nor do we use iterative. We have our own framework which resembles iterative for its simplicity in concept but also provides concurrency under the hook using cooperative multitasking. Our framework does not require beginners to understand concurrency. For advanced students who want to know more and/or contribute to the framework, they can dig deeper into the framework. Using our framework, our students can finish the teleop code within one day. For autonomous, we just basically write down the steps in English and make a state for each step using an event driven state machine provided by the framework. Then we just translate English one-to-one to the steps in each state.
I agree with the above post. I’ve used both command-based in 2016 and iterative in 2015 and 2017. Having used both, I can say with resounding certainty that iterative is much better, especially if you write out a solid framework first. I’m looking forward to maybe doing a write-up on it later, but for now all you need to know is that command-based is simple, but it adds a lot of (in my opinion) pointless code, and limits functionality. Whereas with the iterative template with a state machine like we use, there are many more possibilities, the sky’s the limit.
Can you give some examples of how command-based limits functionality?
My experience was exactly the opposite, I found that the team was writing a lot less code, and I can only think of one area where command-based causes some struggles. Yes, we had a framework we developed before adopting command-based, but that’s code our students had to own that they no longer have to.
I’m not the person you were quoting but I can see some areas where the command based framework is good for simple things, but breaks down quickly as things become more complex.
The command framework is great for writing a simple auto, like this:
But we have sensors to help us determine if we’ve correctly reached the gear, so command 4 would be more like “if peg sensor is activated then let go of the gear, else back up a bit, line up again, forward a bit, repeat until peg sensor activated”. The high-level command structure doesn’t really give you a way nicely pipeline this sort of decision making so you end up with supercommands that do a lot inside them, and you are now implementing custom state machines running inside each command, all underneath a hierarchy of other commands. It becomes a bit of a headache to keep track of.
We’ve used command based for six years now, sometimes with robot builder, sometimes just building on a template. In addition to being easier for many students to get their brains around, it also encourages writing code in small well defined modules. Iterative certainly doesn’t prevent modularization, but neither does it encourage it, and most new programmers need that encouragement - and a few old ones as well!
We used our own frame work that resembles Iterative but we enforced modularity by having the students break down the robot into subsystems and assign each subsystem to a subgroup of students who will own it. Since it is a team organization, it prevents writing monolithic code by a single person. It also encourages the groups to communicate with each other designing the interface for the other groups to call.
When were programming our three tote auto for 2015, we used a state machine. For actions like “drive forward for 5 seconds but at 1.4 second open the forks and at 1.6 lower the elevator and at 2.5 close the forks and at 3.0 raise the elevator and at 3.5 close the can holder but drive forward this whole time” it’s my opinion that it is a lot easier and more versatile to implement in iterative than command-based. Command based works great for actions like “drive forward then turn 60 degrees to the left then drive forward again then open the gear mechanism then drive backwards”, but for some complex autonomous sequences that is not enough. Some of our autos this year would’ve worked easily with command based, but the more complex time-sensitive ones would’ve been orders of magnitude more difficult to implement well with command based.
We did this as well, using the command and subsystem framework. Students were given different subsystems to own, and their deliverable was a Subsystem class that contained methods that could be used by Commands. They would write some basic Commands for unit testing or to bind to joystick buttons. Then another team of students responsible for writing the autonomous modes would use the Subsystems and Commands defined by the other students.
For example, one group of three girls owned the GearHandler subsystem, so they had to learn how to instantiate pneumatic cylinders, track their state, and so on. Their output was a subsystem with methods and commands like getArmState(), closeArms(), openArms(), etc. We had another group of students who worked on the Climber, another on the Camera subsystem, another on LED “Bling” signalling, etc.
Arguably there was a lot of overhead (tons of branches and commits in GitHub) but I like that everyone owned a little piece and learning how to work together like this is a vital part of real software development work.