I’m still not convinced that putting a ton of decisions and multiple states in one command is in the true spirit of Command-Based. @Oblarg could tell me “it’s okay” but I still coach my team to try for one state per command and put the if statements in the isFinished. (And switch etc. are problematic except in a subsystem that defines a FSM controller that really is hard to define using simpler command-based techniques). (I’m not talking about the composed group commands that use sequential and parallel to perform a complex operation.)
OP may be interested in my variety of examples I’ve put together in response to another CD thread. And Should you have State in Subsystems? (Java) - #7 by Jedi_4 has a nice example from their 2024 robot.
That post by @Jedi_4 inspired me to present a simpler example and to dust off an old FSM example. It uses command-based to create a Moore FSM of a transition being current state + Trigger → Command that is the new state. It’s in the MooreLikeFSM.java subsystem of https://github.com/tom131313/Example-LED with several examples included.
That FSM code looks complicated (bloated) only in its repetition since it has 8 states and 14 triggers that are essentially identical. It’s the Knight Rider Kitt red LED scanner. It runs in sim mode.
(Sorry I didn’t implement the time lapsed gradient fade of the scanner - that adds more bloat to the example but I still might do it when I have more time. It might be very easy since the upcoming WPILib LED routines do a lot of heavy lifting for you.)
