Best Way(s) to Implement a Delay in Command Groups
 

Today, my former team asked me what the best way to implement a delay in a command group is. They are well aware of the built in delays in the adding of the commands.

But they want there to be a period where the robot does absolutely nothing for a while for some reason (I assume to let the ball settle). They seem convinced
did not do what they wanted. I know one way to do it could be to make a command that does nothing but that seems a bit excessive, and I am not sure if you can make a command that doesn't require a subsystem (never have done that before) and don't know if that is fair game. So if someone could answer that, it would be cool also. Anyway, back to the real question, does anyone have a clean solution to this I could report back to them with?

Re: Best Way(s) to Implement a Delay in Command Groups
 

AddSequential(new WaitCommand(1)); //Wait 1 second.

Re: Best Way(s) to Implement a Delay in Command Groups
 

I discovered that it is best to not use Timer.delay() because that will pause your entire robot (Every other command and every other subsystem). My solution was to create a Wait command that accepts a timeout as an argument. It then sets its timeout (this.setTimeout(arg)) to the argument. Then isFinished() returns this.isTimedout(). This will effectively put a delay in the command group because they command won't finish until the timeout has elapsed.

Re: Best Way(s) to Implement a Delay in Command Groups
 

Our team uses the same approach mentioned by Joey1939. I've attached the .java file for the command we use. (You might want to just copy/paste the important bits - there's a lot of unnecessary RobotBuilder crap in here that we never cleaned out.)

We call it in command groups like so:

Re: Best Way(s) to Implement a Delay in Command Groups
 

We use:
This WaitCommand is built into the WPI Library.
Also, it is possible to have a command that does not require a subsystem, as we have done this before, but probably is not recommended.

Re: Best Way(s) to Implement a Delay in Command Groups
 

Wow, I had no idea that was even there. They really ought to put that in the ScreenSteps documentation somewhere...

Re: Best Way(s) to Implement a Delay in Command Groups
 

Why would this be a problem? Understandably, you could have two commands trying to use a subsystem at the same time. But I'm sure the WaitCommand itself doesn't require a subsystem, and neither do a lot of the commands that our team used this year.

Re: Best Way(s) to Implement a Delay in Command Groups
 

Our team uses States to determine what to do. Drive has a State Machine that is independent of the Shooter. Delays are implemented using timers. Set a timer, and check the time each loop.

Note: Having everything doing "nothing" requires a little thought. Do you disable the compressor so it does not run too? If you are moving, do you stop moving (and if so, how? Drop power abruptly, or gradually)? etc.