What do you think about current limiting the liftController?

[NotInControl]

@jcorcoran

What your opinion on this? In the Lift PID controller we add a check to only drive the lift if the current draw on the lift motors is not above some current value say (65A) (stall condition).

The point of this would be in some autonomous event, if something went wrong, when we are lowering the lift on an object that we can not move or detect, The lift would still try to go down.

I am thinking we add this to the isFinish() command of the Lift PID so that if the current threshold is exceeded that particular PID command stops.

I don't know if I want to add this to the liftSubsystem instead, but at this moment in time, I think I want to avoid adding this logic to the subsystem. I am always of the opinion to let the drivers have full manual control when it makes sense, including if they need to muscle the lift to do something, that the PID controller cant do.

What do you think? I think the new lift stalls out instead of skipping teeth when driving into an object, but I haven't tested that yet, just some simple observations.

[jcorcoran]

I'd need to see what the current draw looks like when the lift is stalled vs when its operating normally.

If there is enough separation between normal operating conditions and the stalled condition then it sounds like a reasonable thing to do.

I don't nesc. like adding it into a command, especially one used in a command group, because subsequent commands will run operating under the assumption that the lift is in a certain position.

1 enhancement to command groups on my list is a way to break out of a

sequence (not just a command) if a failure has occurred in one of the steps along the way.

Do we know at what limits the PDP current sensor saturates?

[NotInControl]

you can disable the scheduler if you detect a fault in one of the commands... like for this scenario, if the current were too high, you could do scheduler.getinstance().disable();.. this should stop the robot in its tracks in auto.

the scheduler will re-enable in teleop init, because we call scheduler.enable() in teleop init.

Since only 1 command in auto should be running, you may be able to get away with calling the removeAll method on the scheduler as well, if you detect a fault in one of the commands.

The fault detection should make use of the isAutonomous() method, so that no fault checking is done in teleop.

If you want to leave the scheduler running, and the command is apart of a command group, the commandGroup would need to be canceled. Not sure of a clean way to do that, because I don't know of a way to get a reference of the current running command.

Since the lift is probably the biggest liability, we can add something in the isFinished() block to check the current, and stop the scheduler, only during Auto.,, if that's something you think we should be doing.