Ability to not have a named command be interrupted when path ends

[Gold872]

Is your feature request related to a problem? Please describe.
For some paths, I have commands that are meant to run between paths, such as intaking, spinning a shooter, etc. However, when there's event markers for commands like intaking at the end of a path, they are interrupted when the path ends, which will prevent them from running for the duration they need to run.

In the case of the intake, I want the command to run until either a sensor is triggered or it hits a timeout. Having it stop when the path ends prevents it from fully intaking the note.

Describe the solution you'd like
Add a second method for registering a command that takes in a parameter for whether or not it should be interrupted when a path ends. For safety reasons, this parameter can default to true. An example of how this method will be used is:

NamedCommands.registerCommand("Intake", intake.intakeUntilSensor().withTimeout(2.5), false);

[mjansen4857]

So there’s an edge case here where you have a command that shouldn’t be interruptable running when a path with a non-zero end velocity ends. In that case it still has to be interrupted to make sure it can properly transition to the next path.

[Gold872]

These paths don't have a non-zero end velocity, they stop at the piece and the next path moves them to a shooting spot. Does this edge case still apply?

[mjansen4857]

Maybe not for your use case but for others. Basically I'm saying it would be possible to put an event marker for a "non interruptible" command in a path that is supposed to end with a non-zero velocity. There's really no choice but to still interrupt that command in that case.

[Gold872]

I'm very confused, does the command only get interrupted in my use case where the end velocity is 0?

it would be possible to put an event marker for a "non interruptible" command in a path that is supposed to end with a non-zero velocity

Does this already exist or is it something that could exist?

There's really no choice but to still interrupt that command in that case.

For my case or the one non-zero velocity case?

[mjansen4857]

For the non-zero end vel case. For those paths, the robot would need to transition to the next path immediately. Otherwise, it would just keep driving while waiting for commands to end.

Also, this isn't really doable on a per-command basis when registering like that because of the structure of how event marker commands get built. It would have to be on a per event marker basis with a check in the GUI or something.

Honestly, your best bet is probably just to continue whatever you want to keep running when doing commands in between paths. So for instance, have an event marker that runs the intake, then after following that path, add another command that runs the intake and waits for your sensor/timeout. That's what we've done personally last year. I also think that its more readable that way. Then you know that there will be something running between paths instead of some event marker somewhere causing a delay between paths that isn't obviously visible.

[WarrenReynolds]

There used to a Schedule command that was good for situations like this. We have used it in the past when we had a problem of commands running conditionally from inside other commands, which would cause interrupts and cancel the whole command group.

I know this is not the same situation for you, but I think it might solve your problem. I think they are called Proxy Commands now. Maybe you can have a command in your command map that runs at a marker at the end of your path (either at the 0.99 or 1.0 mark) and from inside its logic (ie in the command init function) it launches the command/s you want to run as proxy commands. (ie openIntake, or intakeUntilLoaded,etc). Then if the command group from path following ends because the path ended, it won't matter as the intake command will continue to be running as a separate command in the scheduler, not a part of the path following group.

You might probably find that launching the proxy will interrupt the whole group due to intake requirements if the intake is used somewhere else in the path following, but this shouldn't matter as path following was about to end anyway.

Food for thought.

[mjansen4857]

I think this would be possible with #676, so I'll close this in favor of that solution.