Modify the lift position controller to stop when readching end of travel

[jcorcoran]

The PID lift commands should have some sort of governor which would stop them from continuing to command through a hard stop (fully raised/fully lowered).

I supposed this capability could alternatively be implemented within the subsystem, but this may result in the controllers winding up when they can't reach their destination position. Open loop control (drive with joystick) would be unaffected.

[NotInControl]

Move the Logic into the subsystem, all of it, such that the joystick or the position controller has no idea about the break or the hardstop.

All the joystick or controller command should do is pass a PWM percent to the drive command of the lift subsystem, the lift subsystem (drive method in particular) will determine if the motor should be cut due to a hardstop, or if the lift brake should be enabled/disabled.

Essentially, it should just be as simple as copying the logic in the liftWithJoystick logic into the drive method of the Lift subsystem, and doing some code clean up.

The controllers we have don't wind up, so there is no problem there. Also, the position controller will be limited such that it can not command higher or lower than the nominal upper and lower hardstop values,

[jcorcoran]

I'm fine with moving the break and hard stop constraints into the lift.drive method.

I understand that you're not going to intentionally command the lift to a value outside of the normal range (say -2"), but since we are using an absolute encoder, you don't necessarily know whether or not your zero is off. You may be trying to command to 0.0" of travel, but actually may need to drive through the hard stop to achieve that destination. This is related to the end of my comment in #80. Whether or not there's windup, you would still have an active command from the controller, it would never reach its destination, so it would never complete. That's got to lead to problems when you're using the commands in a sequence (like auto mode).

[NotInControl]

Yea, see my comment to #80, I think by doing that, we avoid the situation of trying to command to an unreachable destination due to an uncalibrated sensor, and preventing a command from not reaching its setpoint.

For further protection, also in auto, I plan to put timeouts on all the commands including the PID controller commands, to prevent a command from holding up the rest of the routine, in the event of something honkey going on.