Middle is about 1/4 the way between down and up (closer to down)
We control the arm with encoders on AM-2971 motors. When we tell the arm to go from up to middle, it gets to the position fine, but when we go from down to middle, it undershoots and only goes about halfway.
The current PID is 2, 0, 0.
What can we change to make the arm not undershoot when moving the short distance between down and middle?
There’s going to be a lot of guesswork involved, no matter what you do.
A good method to start with (it’s in no way optimal, but often good enough), is the Ziegler-Nichols method.
Basically, set all three of P, I, and D to 0. Then, raise P (this can be by any amount, again, see guesswork) until there is oscillation around the setpoint. Then, increase D until the oscillation stops. If you’re noticing a lot of friction in the system so it never quite gets to the setpoint, add some I to compensate.
Take note, however, that long arms are tricky. The gravitational forces acting to pull the arm down vary nonlinearly based on the arm position - this makes it difficult to control, since it’s difficult to model. That’s not saying it’s uncontrollable, but it’ll take more work to make smooth.
Your initial problem is not that surprising. For an arm with a large angular displacement, the gravity torque is directed and proportional to the cosine of the arm’s angle to the horizontal. This is going to give very different behavior up vs down. As stated above, tune P (and possibly I) so that the oscillation center is correct, then increase D to dampen the oscillations. P and I may require minor mods after increasing D, but probably not too severely.
For the benefit of those new to PID who may be confused by the above statement, it is not true as a general proposition.
There are many combinations of values for the gains which will cause the system to do exactly as described in the original post:
*When we tell the arm to go from up to middle, it gets to the position fine, but when we go from down to middle, it undershoots and only goes about halfway. *
When you combine a PID control solution with a real device, there are many situations that result it stabilizing at a point that is not the setpoint. To elaborate, if you were using only P to attempt to get to a setpoint when lifting an object, the system would most likely stabilize below the setpoint. The small power generated when near but not at the setpoint in this case would likely be too little lift the load the last bit.
Also, one of the main purposes of this forum is to help people with problems. That wasn’t condescension, it was being helpful.
There are a couple answers I usually give to this.
Don’t use I unless you have tried P and D extensively and can’t get it to converge to the actual goal but can get it to converge close but not close enough. I rarely use I on 971’s robots, and when I do, the loops end up being much more complicated and hard to reason about.
Start with 0.00001 for P (then D then I) and multiply them by a factor of 2 each time. I tend to round from 4 to 10 when multiplying to keep it easy. You’ll quickly cover the space and learn what matters. One of my colleagues just multiplies by 10 each time.
Use the method recommended by plnyyanks
You can also choose to gain-schedule your PID gains based on if you are above or below the goal. That would mean that you have 2 different coefficients depending on if the arm is below or above your setpoint. Unless you have mastered normal PID, I wouldn’t try this. (I needed to do this on 254’s 2011 elevator and claw to get them to converge nicely with PD)