We are trying to set a Jaguar to position mode using an encoder and are confused as to the parameters. We know that we have to set the desired number of counts per revolution but we are confused as to what the P, I, and D for the parameters are. Please help us.
We know that they stand for Proportional, Integral, and Derivative, but we don’t know where these come from.
http://en.m.wikipedia.org/wiki/PID_controller
The Wikipedia page is very good.
If you’re like me and appreciate a visual aid in understanding these kinds of concepts, I would highly recommend watching a few youtube videos to understand the theory of it before trying to apply it. Conceptually, I’ve found this video (and the whole series) to be really beneficial when introducing new programmers to PID Theory.
Of course it might not technically answer your question in regards to application with a Jaguar, but the concept is really the most important part to grasp.
In addition, search through previous CD posts I’m sure you’ll find a more technical answer. Good Luck!
An encoder is not really the best solution if you’re trying to attain a specific, precise, position. Encoders tell you how fast you’re moving, and if they’re quadrature or gray code, in which direction. However, they don’t provide any useful feedback as you approach speed zero, which is where you need them to work if you’re shooting for a position. A potentiometer is probably a better solution for this.
We use encoders on all our arms and elevators due to the huge increase in resolution they allow. You don’t lose position at zero or low velocity at all. Unsure where you heard that.
If you are trying to infer linear position by the number of rotations (really number of the encoder ticks, so full or partial rotations) of the encoder - you’d need to have a way to provide a zero position first - pretty much each time you start the robot program. You might use a bump switch or some other type of fixed position sensor for this. Depending if you are using a set of chains, belts, or winch wire, you might have to also worry about some type of measurement hysteresis…
You might also try a linear magnetic encoder too, you’d get direct linear measurements instead of having to transform the rotational ticks into linear position.
Previous posts have already linked to in-depth explanations, so instead I’ll just give a crude summary.
At any given moment, the “error” of your system is the difference between your set point and your current location.
The ‘P’ term contributes to output in a manner proportional to the current error. That is, if you are below the set point, the ‘P’ term will be positive.
The ‘I’ term contributes to output in a manner proportional to the sum of all past error. That is, if the sum of the error values at every previous iteration of your control loop is negative, then the ‘I’ term will be positive.
the ‘D’ term contributes to output in a manner inversely proportional to the rate of change of the mechanism’s position. That is, if the mechanism is moving in the negative direction, then the ‘D’ term will be positive.
An easy way to think of this is that the ‘P’ term responds to where you are, the ‘I’ term responds to where you have been, and the ‘D’ term responds to where you’re going.
A layman’s explanation of the 3 tuning parameters: P, I, D.
CP = current position of your mechanism
TP = target position of where you want the mechanism
P term is a how far your CP is away from the TP, the farther it is (the longer that distance), the faster this will drive your mechanism to move towards TP.
I term is the length of time, how long your mechanism has been taking to get from the “beginning of time” (when you turned on the PID algorithm and gave it the TP) to now… the longer that time is, the faster this will drive your mechanism to move toward TP.
D term is how quickly the mechanism has been closing the distance between CP and TP. The faster the distance is being closed, D will try to slow down this rate.
There’s a general problem in any mechanical and sensor system in that there are always a delays in the system - delays in issuing the motor output signal to the motors actually responding and changing speed; delays in the sensors measuring distance/turns and feeding it back to the computer… By the time you’ve made the measurement and gotten it into the computer and your program, the mechanism has already moved on to some place else…
In this end, some system lead to overshoot and oscillation… Depending on what you need, whether your mechanism can accept overshoot and oscillations, that is the goal of a properly tuned PID system, to get your mechanism from CP to TP at the speed that you desired (or the amount of time desired) without much (or any) overshoot or oscillations…
It gets harder if you allow the TP to change mid-travel. It also gets harder if there is a lot of noise in the sensor system.
If your desired target has a tolerance that is wider than a couple of clicks of the encoder, and your system has enough drag (or a brake) to hold position with no actuator input, it can work. When either of these assumptions is not met, an encoder system will be jittery at best.
I don’t agree with your general point. An encoder will give you a change from one count to another at a specific, precise position. If that’s where your target is, that’s where your position will be driven to. It’s going to have exactly the same effect as any quantized position or velocity feedback measurement, encoder or otherwise. It seems to me that your objection is based on assuming coarse measurement resolution. That’s an issue whether you’re using encoders or potentiomenters or Hall effect magnetic sensors.
Thank you so much for all of the help. We understand what PID is now and are just working on fine tuning it 