Our team uses command-based Java to program our robot. Our auto is a CommandGroup containing multiple commands to be run mostly sequentially (a few parallel). Sometimes, our auto “skips” a command, seemingly without reason. We do use encoders and a gyro, but they all reset at the initialization of each command (I was concerned that the Scheduler could erroneously be seeing a true isFinished condition before the Command executed, since I know the command-based scheduler is not the best piece of software in the world). I reset some of them in the end() and interrupted() of the commands as well.
As an example, in an auto that should drive forward, turn, drive forward again, and do some more things, it sometimes just starts by turning and then progressing through the rest of the auto. I can link to our code once I push it (we just returned from MSC tonight). Occasionally, adding a Wait() command (custom timed command that waits for the specified number of seconds) fixes the issue, but not always.
You say you are using some parallel commands. I remember that the first time I looked at these, I found it to be counterintuitive. AddParallel() runs a command in parallel with the FOLLOWING commands until an addSequential() completes the parallel set.
Assuming that you’re getting that part right (especially as it sounds intermittent), I would put some logging entries in each method call of the various commands in auto to see if the command is actually being started but terminating instantly, or is truly being bypassed.
If you link your code that would be great. I do have a couple of questions though.
How do your commands end? Is it based off of timeouts or a certain tolerance of your encoders? What control system do you use? (PID, motion profiling, etc.). When do you reset your encoders? Does this only happen at the beginning of auto, or does it happen randomly throughout the routine?