Quote:
Originally Posted by DjScribbles
To me, what you've described sounds more like the role of a subsystem than a command; and I feel like that is one of the hangups I've got with the system, I believe the subsystem as a model makes is a more proper place to put business logic (such as a state machine that determines when to activate the roller while lowering the arm), but doing so reduces commands to such a trivial role that they just get in the way.
If you build this functionality into your command, then does that simply leave your subsystem as container classes for actuators and sensors?
|
Nearly all of our logic for a given subsystem is in the commands. When logic incorporates multiple subsystems we utilize CommandGroups. For example, our intake must be in a certain position to fire. Thus we have a CommandGroup that does:
Code:
addSequential(new DropIntakeCmd());
addSequential(new FireShooterCmd());
Because DropIntakeCmd isn't marked as finished until the sensor reads that the intake is in the proper position the logic works out.
This sort of construction allowed us to write our sequences and autons via flowcharting on a chalkboard.
However, after attempting CommandBase last year with C++ I can say that it was a bit more of a pain. Java is much much cleaner in my opinion.
Codebase for reference:
https://github.com/FRC125/NU14