Our climber mechanically cannot pass nor go past 2 setpoints, that being 0 and roughly 950,000 talon fx ticks. I have it currently so that there are three modes, past lower bound, in range, past upper bound. If it is in range the operator has full control over the motor, if it’s past the lower bound it will let the operator only go up or it will supply no voltage (percent output = 0 with braking). It is similar for the upper bound and it works okayish but the major problem is that even with braking it doesn’t stop instantly, the encoders don’t stop instantly which causes drift to build up over time from the true setpoints which eventually breaks the system. Sure I could just have it do it once, but as I learned the hard way if the operator accelerates extremely fast in either direction it will break the climber which CAN NOT happen at competition as it takes several hours to fix.
What I currently think could work is instead changing the zones to be deadband zones, -1 for lowerBound + deadband, 0 for in range, and upperBound + deadband. I’ll set the deadband to be 20% of my coast dirft then it will stop operator controls and switch to a critically damped PID sensor position closed loop, then after an elapsed time has passed after the steady state error is negligable, it will give the pilot controls back.
I’m asking if there’s some easier and/or more effective solution to this.
We have a similar scenario. Going down past our “0” causes stress on the system. To get past this hurdle we’ve installed limit switches to catch any (we don’t think there’s much drift but wanted to be safe) encoder drift.
Do you have the option of installing limit switch?
If you’re using the TalonFX augment your Talon configuration with reverse and forward soft limits, that way you’ll not be bound to the 20ms scheduler. You’ll at least get 1ms enforcement in the Talon.
This is very error prone in any mechanism like a climber that is prone to slippage, so I’d also recommend physical limit switches or something that can override the soft limits if necessary.
We use a combination of two things to solve this on our climber: “Homing” switch and profiled PID.
A (magnetic) switch is used to “home” the climber at the start of autonomous by moving “down” slow enough to not run past the switch. Hitting the switch establishes our “zero” aka “down” position.
From then on, we use PID to control the position, only allowing setpoints within the valid range of movement. With plain PID it would quickly get to the desired position but some over/undershoot could still place us outside of the permitted range. Using a ProfiledPIDController fixed that, it slows down as it advances the desired setpoint without over/undershoot.
You mentioned coast - I would consider going to brake mode unless there is some strong reason not to.
No point in having a lot of extra travel after the operator stops it.
Consider hard limit switches like several other folks have mentioned.
Consider hard bump stops at the very end to prevent mechanical over extension (“hard” being stopping the travel but you want to stop the mechanism from overextending in either direction and not necessarily rock hard - rubber feet or something like that would be reasonable to look at).
We are using our height to slow our max speed down when we get close to our limits so that when we are close to the bar the operator has only so much power available so as to not over travel our limit and homing switches. Then you can dial in that speed and distance to get the results you want
Add sensors adequate to automate the whole climb process. Even if you end up controlling the thing manually, you will want to use the sensors to keep from destroying your mechanism - and having them mounted and available means you can continually iterate towards a fully-automated climb routine (which should be the goal, no?).