allwpilib icon indicating copy to clipboard operation
allwpilib copied to clipboard

Dynamic interruption behavior based on incoming command

Open LightspeedLazer opened this issue 4 months ago • 0 comments

Is your feature request related to a problem? Please describe. The current interruption behavior logic is a black and white "This command can be canceled" or "This command can't be canceled". This can be an issue especially if you have complex command logic and want to enforce certain rules on when certain commands can be scheduled.

Describe the solution you'd like Command.getInterruptionBehavior gets a parameter that is the incoming command.

public InterruptionBehavior getInterruptionBehavior(Command incomingCommand) {
    return InterruptionBehavior.kCancelSelf;
}

This allows the currently running command to decide if it should cancel or not. This is nice for when you want to enforce a command hierarchy without having to have extra code at every schedule site.

Command.withInterruptionBehavior would take in a Function<Command,InterruptionBehavior> instead of just InterruptionBehavior.

Additional context #6510 would help this a lot as it would be easier to identify which commands should cancel the current command.

public Command feed() {
    return startEnd(
        this::startFeed,
        this::stopIntake
    )
    .withTags(FEED_TAG)
    .withInterruptionBehavior((incoming) -> (incoming.hasTags(Intake.INTAKE_TAG) ? InterruptionBehavior.kCancelIncoming : InterruptionBehavior.kCancelSelf))
    .withName("Feed");
}

LightspeedLazer avatar Apr 11 '24 22:04 LightspeedLazer