Hopper subsystem manual override

[derickson2402]

The Hopper subsystem normally has a PID controller driving the lift, and a basic controller for the intake. This worked great during the 2020 season, until Murphy's Law came into play, the encoder was dislodged, and the axle was damaged, and the motor stalled.

In the event of situations like this, we need a manual override mode which runs the lift on basic PercentOutput. Additionally, there may be a good way to automatically trigger the override, for example if the goToPosition command does not complete in ~5 seconds or so, rumble the controllers and turn on the manual override mode.

See issue #23 for more info on the toggle switch implementation

[derickson2402]

90462b7 added a mechanism for disabling the Hopper subsystem, but this still needs to be wired up to button inputs. I am thinking that we should rely on the NetworkTables toggle. So we can do the following:

• Hopper.setEnabled(boolean) for disabling the robot, which calls Hopper.setAllNeutral()and toggles the 'subsystem enabled' toggle
• Button on Shuffleboard which is linked to the NetworkTables toggle
• Physical controller buttons can be connected to inline commands which call Hopper.setEnabled(false)
• Periodic Task in Hopper subsystem which runs a safety check and can call Hopper.setEnabled(false)

This way, all 3 methods will work equally as effectively, and will remain synchronized. Additionally, assuming that NetworkTables uses cached values in the event of network failure (see #30), the robot will still disable itself if something goes horribly wrong

[derickson2402]

This is mostly implemented, but there is no manual override which uses joysticks.

Additionally, the calibrate hopper command sequence should call setEnabled(true) at startup, so that it can be used to try to fix the Hopper if it were disabled because the encoder was moved.

[derickson2402]

During testing, found that the hopper lift can temporarily use up to 22 amps current draw when going from DOWN to UP, but this peak is only about 200ms long. The current every 20ms looked like this:

0
8
11
16
19
21
20
16
13
11
9
8
6

Therefore there should be 2 safety tests. One should probably be a time based test, so if current is higher than 20 for more than 500ms, then shut off. The other should automatically shut off if the current limit is reached ever, as this only happened when the setpoint was at least 500ticks farther than the mechanism could actually turn to.

Additionally, the software current limit of 30amps does work pretty well, and maybe should be lowered to 25?

[derickson2402]

Remember also that the stator current is negative when traveling downwards. The peak here seemed to be about 19 amps, and was approximately the same duration as traveling upwards.

[derickson2402]

Added a manual override command to the SmartDashboard, and then added an internal safety system which simply disables the Hopper. Fixed the button bindings as well

[derickson2402]

Idea for another safety check: keep track of the change in position over the last cycle, and if it is low but the error is high then decrement the safety score