Command Based vs Simple Robot

[heya101]

I was having this discussion with someone else on our programming team deciding on which direction we should head for our design for programming this year in java.

He would like to use the template based on SimpleRobot (From what I can tell this is the most editable option??) and I kinda wanted to try Command because of how for me personally it seems a lot more organized.

His argument was that he thought Command was redundant if we would only use 4 subsystems (Drive-train, shooter, elevator, intake) and it would make more sense to stay with his design path since he could change it in a much more freely.

My question is what are the pros and cons between using the two options (Which one might be more powerful)? From what I've searched simple is a more open option while command is much more rigid and structured.

[jesusrambo]

I'd recommend using commandbase. Simple is a lot less flexible, and has much less compartmentalization of all your code. Command based gives you the benefit of the structure, some more flexibility with commands/subsystems, and the biggest benefit -- you can reuse your code the next year with command based, since it's all so compartmentalized you can just keep and tweak the parts you're reusing.

[jfitz0807]

I'm new to using java for the robot this year. When people talk about a "command based" robot are they referring to the IterativeRobot or is there another extension?

[BigJ]

Originally Posted by jfitz0807

I'm new to using java for the robot this year. When people talk about a "command based" robot are they referring to the IterativeRobot or is there another extension?

"Command-based" is a seperate architectural template from Simple and Iterative.

Check it out here. (Java uses the same stuff basically)

[heya101]

Do you think with four subsystems (DriveTrain, Intake, Elevator, and Shooter) Command would be redundant? Also is it possible to integrate, say 1 subsystem and command, into a simpleRobot template?

[gixxy]

I was against the Command Based Template at the beginning for the same reason. However looking back on it, the time saved and time using the CommandBased Structure was great. It is a great structure well built and simple to use once you know some basic Java.

The programming team is always the one on crunch time at the end when the physical design is done. Unless you are able to really get a format/structure together on your own (Probably would have had to been done offseason) then go ahead with it, otherwise I would highly stress the Command Based Structure.

[jwiederspan]

We moved to Command-based this season, and it is a little more difficult for the new programmers to get used to but MUCH better for a team to work on and much more flexible than our old code.
1) Having subsystems (and commands) in separate files made it much easier to separate out the work. We agreed on the public interfaces and then each person could tweak and improve behind the scenes as needed;
2) The subsystems become somewhat modular, so you will probably find yourself each year picking and choosing from those used in previous years and they will be easier to incorporate;
3) It is much more flexible because your commands compete individually for resources instead of having the entire code base need to know what state things are currently in; and
4) It is better programming - since our goal is to get the kids excited about programming, telling them that they are using programming concepts that don't get introduced until the second year of computer science classes at most colleges usually gets them very excited.

[omalleyj]

Originally Posted by jesusrambo

I'd recommend using commandbase. Simple is a lot less flexible, and has much less compartmentalization of all your code. Command based gives you the benefit of the structure, some more flexibility with commands/subsystems, and the biggest benefit -- you can reuse your code the next year with command based, since it's all so compartmentalized you can just keep and tweak the parts you're reusing.

I feel the command based approach is helpful for teams that do not have seasoned Java help, but most of the comments above are incorrect or misleading.

Flexible means you can do something in one that you can't do in the other. I am hard put to think of anything you cannot do in both.

Command enforces (or at least coerces) good object oriented practices, and if you were to throw all your code into the SimpleRobot class it (Command) would be more compartmentalized, but you should not do that. If you break up each subsystem to be its own class (as you should) everything is nicely encapsulated and modular.

This year we have classes for the drivetrain, shooter, climber, camera, utilities, and an interface for constants. Last year we had the same except for climber, and could have reused nearly everything. We don't because different students code different classes and do it from scratch, for the learning experience.

So by all means use command based programming, but not for the reasons above. It is helpful for those with limited resources, but for those who can afford it, it is probably more helpful to learn the techniques that underly it by coding it themselves.

[Joe Ross]

Originally Posted by heya101

His argument was that he thought Command was redundant if we would only use 4 subsystems (Drive-train, shooter, elevator, intake) and it would make more sense to stay with his design path since he could change it in a much more freely.

I would encourage you to think of the number of commands, rather then the number of subsystems when determining the complexity of your robot. Subsystems are a nice way to keep like hardware encapsulated together, but aren't really that important.

[java4first]

I agree completely with "omalleyj" ... we had a session with WPI at the end of the summer for several programming mentors from different teams in our area, and I think the general consensus was that this was great for rookie teams and teams without strong programming mentors - but it didn't seem that much different from what we were already doing (e.g., we already had 'subsystems' with well defined interfaces - we just weren't calling them that). But, as with all software - there are lots of ways to do the same thing, and you should go with what works for you.

[jesusrambo]

Originally Posted by java4first

I agree completely with "omalleyj" ... we had a session with WPI at the end of the summer for several programming mentors from different teams in our area, and I think the general consensus was that this was great for rookie teams and teams without strong programming mentors - but it didn't seem that much different from what we were already doing (e.g., we already had 'subsystems' with well defined interfaces - we just weren't calling them that). But, as with all software - there are lots of ways to do the same thing, and you should go with what works for you.

Why would you redo the entire structure by yourself then, if it's the same thing? We have two PhDs helping mentor the programming department, and they're still fans of using it over simple or iterative.

[Ether]

Originally Posted by jesusrambo

We have two PhDs helping mentor the programming department, and they're still fans of using it over simple or iterative.

What are their names? I'd like to read their dissertations.

[jesusrambo]

Originally Posted by Ether

What are their names? I'd like to read their dissertations.

Sure, I'll PM it to you.

[omalleyj]

Originally Posted by jesusrambo

Why would you redo the entire structure by yourself then, if it's the same thing? We have two PhDs helping mentor the programming department, and they're still fans of using it over simple or iterative.

Use what you feel adds value to your program. I feel, and it sounds like java4first feels (don't want to put words in his mouth), that building from the ground up adds value to our program.

Its like doing web design, no one really 'needs' to write pages of html anymore, but there are interesting things to be learned by doing so.

Use what works for you, but if you are going to offer guidance to others, be accurate in your assessment of the choices.