Quote:
Originally Posted by Joe Ross
We find it nice to have simple commands that don't need any outside input (so they can be run from SmartDashboard for debugging. Because of this, we make a complicated command (like your DeployArmCommand) and then make a bunch of commands that extend the complicated command and pass the appropriate data.
|
This would definitely help with our boiler-plate problem, we have a command for each of our arm positions, each is identical save for a single parameter; this would be a huge improvement there.
Quote:
Originally Posted by Joe Ross
If you use CommandGroups, the default command won't run until the CommandGroup finishes. However, you do have to think about your end and interrupted methods to make sure they don't do something you don't want when run in a sequence.
|
This is really one of the biggest annoyances I've had with adopting the pattern. For our shooter (wheel driven with a piston to fire), we have a spin-up command that sets the target RPM while the command is running, and stops the wheels when the command completes. In order to make this work, the shooter subsystem needed to be broken into two subsystem, one for the wheel motors and one for the piston, so that the Fire command did not interrupt the Spin-Up command. (Alternatives would have been having the spin up command interrupt/end without stopping the wheels, but then the default command or an on release command would have to pick up the slop)
This became a problem in autonomous as well, since the spin-up routine didn't end, a seperate command needed to be created to do the same thing, but with a different life-span. (I've since realized that adding this in parallel would have been the better solution, however the nuances of the parallel/sequential weren't clear at the time)