This is my bad because Alice and I rushed this feature out at the last seconds, but there is a "magic number" in the intake until stall code.
We use a timer to have the intake keep intaking after the drivers let go of the button.
The way the debouncer detects stalls, is done only in the if statements for these two cases (intaking with button, and intaking after button). So, we have to reset the debouncer when not in those cases. This is done here:
This is my bad because Alice and I rushed this feature out at the last seconds, but there is a "magic number" in the intake until stall code.
We use a timer to have the intake keep intaking after the drivers let go of the button. The way the debouncer detects stalls, is done only in the if statements for these two cases (intaking with button, and intaking after button). So, we have to reset the debouncer when not in those cases. This is done here:
https://github.com/frc2399/2023-Season/blob/07b4d2d64e547168fe4f461191fdd8ea29167a8c/src/main/java/frc/robot/commands/intake/StallIntakeCmd.java#L74-L77 (p.s. there's probably a world where the debouncer is outside the if statements and doesn't need to be reset separatley)
Problem is, that 1.0 is the same 1.0 (now 1.5) as, because for some reason wpilibs timer doesn't take in the timeout value to the constructor and you have to pass it as an argument?? https://github.com/frc2399/2023-Season/blob/07b4d2d64e547168fe4f461191fdd8ea29167a8c/src/main/java/frc/robot/commands/intake/StallIntakeCmd.java#L63-L64
So that number in two places was a "magic number". It should have been a constant, but we were rushed.
This is why I am always insist on good coding practices and cleanup: it has real effects on the performance of the robot.
Make a constant called whatever you'd like
EXTRA_INTAKE_DURATION = 1.5at the top ofStallIntakeCommand, and use that for both timers.