we want to disable some of the buttons on the non-driver controller when our robot goes into “climber mode”. basically, the climber is mounted on our intake/shooter and when we want to climb the subsystems driver will press a button to “enableClimberMode”. when this happens we want to disable or remap all buttons that move or run the shooter. i remember doing this a few years back, but i cannot find the methods to do that in the current wpilib library. i think it was something like “clearAllButtonBindings()”.
looking at the class EventLoop, i do see a method clear() that will clear all bindings, but when we run this, we get an error (exception) indicating we cannot call this method while the event loop is active. i didn’t see any way of “de-activating” the eventloop other than replacing the active loop, which did not seem to be a good way of accomplishing this.
so, the question is: how can we disable some of the buttons (or all of them and we’ll just rebind those buttons we want)?
Instead of unbinding or rebinding, you could instead use logical combinations (composing) of the button trigger and the global condition. E.g. myJoystick.a().and(() -> !buttonsDisabled).onTrue(...)
This may be a really weird way of doing it, I’m no expert, but maybe you could create a command that does nothing but requires all subsystems not used in climber mode and make it cancel all incoming commands requiring those subsystem. Then run that in parallel with your climber mode command? 
seems inelegant but it may work.
Using multiple EventLoops and either switching them or running them externally is the intended use form.
In this case, you could have an EventLoop for everything you want to disable in climber mode, and conditionally run it directly (this can be done in a RunCommand that is scheduled as long as you want, or in one of the periodic functions). Just be careful that stopping polling of a binding won’t make an unsafe state – such a shooter bound to whileTrue on a loop that stops being polled might continue running with no binding to stop it.
This error happens when you’re trying to modify the bindings from inside a binding, and is intended to safeguard from concurrent modification issues and exceptions thrown from the underlying Java collections. Whether the loop is set as the CommandScheduler’s active loop isn’t relevant to this error.
All that said, composing triggers (Peter’s suggestion in the first comment) is probably the simpler way to do this.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.