Strange behavior of POVButtons

Hey everyone, our robot this year has massive pistons on both sides for climbing. I’ve been trying to attach a piston toggle operation to the Up and Down buttons on the D-pad using POVButtons like so:

Button climberPistonToggleFront = new POVButton(driverController, Controls.POV_CLIMBER_TOGGLE_FRONT);
Button climberPistonToggleBack = new POVButton(driverController, Controls.POV_CLIMBER_TOGGLE_BACK);

climberPistonToggleFront.whenPressed(new OperateClimber(OperateClimber.Side.FRONT));
climberPistonToggleBack.whenPressed(new OperateClimber(OperateClimber.Side.BACK));

(The OperateClimber command just toggles the states of the climber pistons on the specified side.)

I’ve found some strange results with this code. If the button is pressed and held down for more than a quarter of a second or so, everything will function normally and the pistons will be toggled. However, if the button was just quickly hit but not held down at all, the pistons would attempt to change state for a brief moment, but revert back to their original state once the button is released. I’m certain I haven’t attached any other commands to the buttons (e.g. whenReleased). and no other command requiring the climber subsystem should be running at the same time. Any ideas why this happens?

I just tested the code you posted, and assuming Controls.POV_CLIMBER_TOGGLE_FRONT=0 and Controls.POV_CLIMBER_TOGGLE_BACK=180, I observed no weird behavior.

Have you tried using print statements to try and figure out what is is being called causing the pistons to revert? Is there anything other than the OperateClimber command that interfaces with the pistons?

Are you able to post the rest of your code? There may be another command or method interacting with it.

I’ve done a full search and the OperateClimber command is the only one that requires the climber subsystem. The pistons are never interfaced directly other than through this command.

The only other thing that can possibly affect the pistons is a CommandGroup named AutoClimb, which involves a bunch of OperateClimber sequences. It is set to activate when the POV angle is 270 (left) for more than 0.5 seconds, so it shouldn’t activate…

Unfortunately we were not able to test with print statements just yet. But we do have robot logs for basically everything, so I will check that later and see if the command was started twice. You can find the rest of our code public on GitHub and OperateClimber can be found here.

What controller are you using for this sequence? Lots of commonly used controllers have suspect D-pads that could “bounce” between directions when pressed.

Another strange thing about the POVbuttons that @gixxy found a few weeks ago is that if the joystick gets disconnected, the API returns (IIRC) a 0 (north/up) rather than the -1 which means no buttons are pressed.

It looks like the bounce might be the issue. We’re using black Xbox controllers. A further inspection at the log files shows that OperateClimber was indeed started twice within a very short amount of time. I’m rather surprised that the built-in debounce didn’t handle this…

Yes, that is a bug. See https://github.com/wpilibsuite/allwpilib/issues/1642

Glad to hear it has been identified and a bugreport filed. Between work and my team prepping for competition last week, I hadn’t had time to fully test the issue out so I could confirm the bug.

2 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.