Re: Any PID experts ?
 

Thanks for all the input. We tried a number of combinations but gravity combined with the realities of a no-backturn gearbox (which leads to significant jumping going downwards as the backturn pins engage and disengage as the motor is turned on or off or reverses direction, we went back to KISS (dropped the PID code) and currently just go full speed up to within 5% of the target and power off. The no-backturn motor keeps us there. We did something similar going downwards but I believe are not going full power down. So far so good ...

I suspect a generic PID algorthim is aimed at systems that has largely symetrical responses on either side of the target but we were highly assymmetrical (especially with the anti-backlash) making a single set of tuning parameters hard pressed to do a good job in both directions

Re: Any PID experts ?
 

That's where the "gain scheduler" Palardy mentioned comes into play. It changes the tuning parameters based on measured conditions. In your case, the sign of the error would be used to determine which set of parameters (the "going up" or "going down" numbers) to employ.

Re: Any PID experts ?
 

This is where some feed-forward control comes in.

Feed-forward is a motor command in addition to the feedback motor command from the PID. Mathematically, it is:

MotorCommand = P*error + I*errorIntegral + D*derivative + feedForward

The feed forward command depends on the physics of the system, and can be as simple or as complicated as needed. For an elevator, it should be a fairly simple constant value used to fight gravity. Since F = m * g, and m and g are constant, F should be constant. Therefore, your motor command to fight gravity should be constant.

So, how do you find this constant value to fight gravity? In the case of the elevator, it's pretty easy: 1) set up a PID controller (the I-term is necessary for this), 2) command your set point to some arbitrary value, 3) wait until your system settles at the set point, 4) read the motor command that is keeping it still. Voila, you have your feed-forward constant.

What feed forward does for you is this:

Let's say you have the issue you're seeing: the elevator goes slowly up, but races down. In reality, to let it go down, you may not really want to command the motor in the down direction - you may only want to relax the upward command. The feed-forward takes care of this. In the elevator example, let's say you set your feed-forward constant at 0.10 PWM duty cycle in the up direction. If you command the elevator to go up 10 cm, the PID may command the motor up 0.07 and with the feed forward addition the total motor command would be 0.17. If you commanded the elevator DOWN 10 cm, the PID would command the motor the same 0.07 but in the down direction (with gravity it would go racing downward), but when you add the feed forward term, the motor would be commanded UP 0.03. Since it requires 0.10 to hold it steady, 0.03 up would result in gentle downward movement of the elevator.

I hope that makes some sense, it got a little long-winded.

For an arm, the feed forward term should be a function of the angle of the arm. For example, if 0 degrees represents the arm straight up, then the feed forward term should be C * sin(armAngle). If you do a little math to determine the torque at the motor as a function of arm angle, you'll see why C*sin(armAngle) makes sense.

In summary, if you can develop some simple physics equations of the system, you can come up with a feed-forward method that makes sense. The idea is that the feed-forward motor command should be what the physics say the motor command should be in a perfect world. The PID is then there to take up the slop and make up for errors and imperfections.

Re: Any PID experts ?
 

Not to toot my own horn, but I wrote this a while ago:
http://www.chiefdelphi.com/media/papers/1823

It's aimed at the old control system, so the code examples don't apply directly (the new controller doesn't have the same limitations in regard to math complexity) but the concepts are still valid. I'm in the process of rewriting this to be a bit cleaner with the new control system as the basis for the examples, but it'll be pretty similar to my original paper.

As stated in the paper, please feel free to contact me directly via email, PM or anything like that if you have any questions at all.

A fair point, I wasn't very clear about how the D term works in this paper, I really didn't touch well on the fact that it's usually a negative coefficient to help counteract overshoot by regulating speed, but on some systems, I've found a positive value works out well, depending on exactly what response you need, and if overshoot is acceptable, etc. I will be making this much clearer in the next version of the paper.

I really hope that helps, and again let me know if you have any specific questions,
Matt