PID: what is it exactly?

[Wildcats1378]

Hey guys,

I've been trying to upgrade my Labview knowledge over the last few days in prep. for the kickoff. I've found quite a bit of threads on here about PID controllers and such, and yet I'm still finding it difficult to understand what exactly they do, and how they are useful in FRC and Robotics.

I've looked at this
https://decibel.ni.com/content/servl...20Tutorial.pdf

My (probably wrong) current understanding is that you set a value, and the PID loop will read what the actual value is and adjust the motor to match the set value?

A really dumbed down, simple explanation of what is going on would be wonderful

Thanks

[nathan_hui]

Essentially, yes. And unless you plan on writing your own PID loop, you can treat it as a black box that will automatically adjust the motor speed to match the setpoint.

To be honest, that's not exactly what happens. PID takes the speed or position of the motor from the encoder and calculates the difference (or error as I will refer to it from now on) from the setpoint. It uses that error to calculate how much to adjust the motor's power to meet the setpoint. PID comes from the Proportional, Integral, and Derivative terms used to control how PID calculates the setpoint. I'm not too familiar with the NI LabView implementation of PID, so I can't really tell you any more. If you want to learn more about PID and control theory, see http://www.controlguru.com/pages/table.html

[F22Rapture]

Examples of PID:

Cruise control
Thermostats
Ship steering
Autopilot
Industrial pressure regulators

[ttldomination]

Originally Posted by Wildcats1378

A really dumbed down, simple explanation of what is going on would be wonderful

Let's use a real life example to indicate the functionality of this control scheme. Let's say you're driving a car, and in 1/4 of a mile, you must stop.

Now, the not-so-smart person will gun it for the entire 1/4 of a mile, and then slam the brakes at the last minute in hopes of stopping at the right location. As you can guess, this is awful as it means terrible overshooting, and in turn, terrible performance.

However, the smart person might go pretty fast for say 1/8 of a mile, and then proceed to decelerate over the last 1/8 of a mile. Now, doing this method, you're much more likely to hit your spot. And, even if you miss the target, you will most likely very slowly move your car on target.

A PID does the same thing as the smart person. It evaluates feedback from the system to determine how much it has to 'gun' the system.

This whitepaper is a short, 2 page document explaining each term, and the extremely simple, FRC related math behind each term.

- Sunny G.

[apalrd]

A PID controller is a form of feedback controller. In general, a feedback controller takes sensor data and command data and sends commands to an actuator to control the system.

A PID controller does this using two inputs: 'setpoint' and 'sensor'. Setpoint is where you want to be, sensor is the measured position (or velocity for velocity PID) of where you are. The PID controller outputs a motor control, but the output is of arbitrary scale. In fact, all of the units used are of arbitrary scale, the only requirement is that setpoint and sensor be of the same units.

The PID controller is named as such because it has three terms: P, I, and D.
The PID controller first calculates the 'error' as the difference between the setpoint and sensor (a single subtract operation). This number is how far you are from where you want to be.

P is the Proportional term. It is named because it sets the output proportional to the error. The proportion is controlled by kP, the proportional gain. As the system approaches the setpoint, the proportional term will reduce power to slow down, hopefully getting close or stopping at the right place. Unfortunately, if it overshoots or undershoots a little, it usually can't do anything about it, because the power output is so low. In many FRC cases, this is the only term you need.

I and D are calculus terms. It helps but is not required to know calculus to understand them.

I is the Integral term. You first integrate the error over time, and the I terms contribution to the output is then proportional to this integrated error, by kI. This will cause the integral term to 'wind up' as the system takes a long time to move, so if it gets close to the target and sits still for a long time, the integrator will start to wind up and push it to the target. The math is:
I += (error * dt * kI);
-You need to know dt, the loop time. If you think of integration as a bar graph, with the X axis as time and the Y axis as the error * gain at that time, with all of the bars touching, dt is the width of the bars. If it's always the same, you can not care about dt, but in FRC with the cRio, the timing usually sucks a lot.

D is the Derivative term. This term works against the other two to slow down motion when the system is moving too fast and approaching the target. At high errors it is drowned out by the P term, since the P term will well exceed the maximum motor, and you limit the entire controller as a whole after adding the terms. IF you'd have calculus, it's literally just (de/dt) * kD, de is calculated as error - error_last, and dt is the loop time. kD is the derivative gain. This term cares a LOT about noise, so it really needs dt. Think of this method of calculating the drivative of the secant line between this time step (error now) and the last time step (error_last).

When each term is done, you add them all together, limit it to the range of the motor, and you are done. I usually write the controller from scratch for every subsystem that needs it, because I like to add code to control the I term, and the implementation of this varies by subsystem. Simply setting a bounds (+-43 worked well for 8-bit Vex robots, that's about 1/3 max motor power), sometimes it's more complicated (e.g. the shooter controller this year used a linear interpolation to find the limit, as error increased, the maximum error term dropped off to 0 as error was 200rpm).

I see far too many people try to stuff the stock PID class into every case, and treat it like a gold box. To prove that it's so simple it dosen't need a class of it's own, I will write it in 7 non-framework lines of c code:

double error,p,i,d,motor,error_last,setpoint,sensor;
sensor = ger_analog_value();
setpoint = 20;
#define kP 0.3
#define Ki 0.4
#define Kd 4
//Begin actual code
error = setpoint - sensor;
p = error * kP;
i += (error * kI);
d = ((error - error_last) / dt) * kD;
motor = p + i + d;
motor = limit(motor,127,-127);
error_last = error;
//See? 7 lines

Note: Also, cruise control is usually more complicated than just PID, or possibly does not even use PID at all. The system I worked with used a LUT on the error to determine acceleration, which it then converted to torque. In addition, cruise control must also control other things like shifting (for automatic cars), and in some cases even brakes (adaptive cruise systems are especially fond of brake intervention).

[pfreivald]

A(n over-)simplified version of PID control (which others can feel free to correct or elaborate upon):

What it is: It's a way to get motors to do what you want them to do efficiently and smoothly.

What it does (as opposed to how it works):

The problem: Suppose you are a bending unit (named Bender Bending Rodriquez, for example), and you want to use your robotic arm, motor controlled, to lift a refreshing, foamy, and energy-filled beverage to your mouth. You can't just give the motor voltage willy-nilly until it arrives at your mouth, or you'll end up with operating near stall and possibly lighting your roboarm on fire, or slamming yourself in the face with the aforementioned lofty beverage (possibly spilling it, which would be tragic), etc. What you need is some kind of control.

The solutions:

P -- Proportional Control

Your voltage is at least related to speed, though this may be nonlinear depending on lots of variables (controllers, motors, mechanical setup, friction effects, etc). Let's assume that the general relationship that an increase in voltage generally results in an increase in speed.

The first thing we want to do is avoid destroying your beautiful face, or spilling the beverage (or both), by causing the arm to overshoot the target value.

So step one in your quest to refresh yourself is to measure the difference between where the arm is (distressingly far from your mouth) and where you want it to be (at your mouth). Call this "error".

The voltage you give the motor can then be made Proportional to the error, so that you supply more voltage further away, and correspondingly less voltage as you draw near.

And so this is what you do, and what you find is that the lofty beverage asymptotically approaches your mouth, but doesn't get there. Due to frictional effects and pesky mathematics, the speed approaches zero faster than the voltage does, and two things may occur:

#1. the motor runs at close to stall, drawing a lot of current (inefficient and possibly ouchy of the fire variety), and,

#2. the beverage remains tantalizing out of reach of your robolips -- it undershoots.

Solution:

I -- Integral Control

Measure not only the error of the arm, but also how much that error has changed since the last time you checked (which you can do really fast because you're not a meatbag, you're a robot, Bender.)

If the error has not changed as much as you wanted it to, add a little voltage. Do this over and over again, really fast, and you have yourself what approximately amounts to an Integration. [I mean, he's no Farnsworth, but that Newton guy was pretty smart. (Leibniz, too).] Voila! You've got enough voltage!

And yet, two things may occur:

1. as these little bits of voltage stack up, you get enough energy per charge to get that arm going again -- but you might smack yourself in the teeth with the bottle, as (for example) the static friction gives way to (weaker) kinetic friction, and or that pesky inertia gets involved. You've overshot, and,

2. as you shoot past your target error value, P and I become negative, so your arm switches direction and goes the other way... And overshoots, moving too low, causing the values to switch signs, so it comes back up and hits you in the face again, and then drops too low... You've got an oscillation, and while your mouth control might theoretically be good enough to steal sips on the way by, this ridiculous motion won't impress the robo-floozies, and that's not good enough for you, Bender.

Solution:

D -- Derivative Control

Whoa, there, Nelly! That arm's going a little bonkers now, and you're getting frustrated by the lack of liquid refreshment and robot-running ethanol... frustrated enough, perhaps, to kill all humans--but for that you need energy, and thus the lofty beverage! You've got it up to your face, but you can't hold it in position long enough to slake your thirst.

So what you want to do is damp things down, chill them out a bit. So what you do now is measure how fast the error is changing -- take its Derivative. (This is the calculus term derivative, so we're back to Newton and Leibniz). If the error is changing too fast, you cut the voltage. You can do this very quickly, again, because you're not a meatbag, you're a robot, Bender.

The Derivative control compensates for the overshoots of the Integral control, which compensates for the undershoots of the Proportional control, and the combination of the three (though all three are not always needed) results in a smooth, efficient motion that draws exactly as much current as it needs to, and gets that beverage right where it needs to be -- in your craw.

That was easy, wasn't it?

[Ether]

Originally Posted by pfreivald

#1. the motor runs at close to stall (as motors do not "hold position" well), and draws a lot of current...

Solution:

I -- Integral Control

The inquiring reader may be left with the impression that you are saying that adding an I term solves the problem of high motor current required to hold a poorly balanced arm in position.

[Ether]

Originally Posted by apalrd

Note: Also, cruise control is usually more complicated than just PID, or possibly does not even use PID at all. The system I worked with used a LUT on the error to determine acceleration...

The reader who doesn't know what PID is, almost certainly doesn't know what LUT is.

[Ether]

Originally Posted by F22Rapture

...Thermostats

The thermostat controlling your home furnace is probably a bang-bang controller, not PID.

[pfreivald]

Originally Posted by Ether

The inquiring reader may be left with the impression that you are saying that adding an I term solves the problem of high motor current required to hold a poorly balanced arm in position.

Noted and edited.

[tr6scott]

http://www.inpharmix.com/jps/PID_Con...ms_Robots.html

Really good write up of PID used to Line Follow on a FLL NXT. I was able to use this guide, and get two 6th grade programmers to understand PID, and program one in NXT.

We also did this in Labview with the NXT toolkit 2 years ago when we made the step up to FRC, and needed to learn the basics of Labview.

Really helped when the autonomous our first year in FRC was line following for Logomotion.

Neither student has Calc yet, but both have a grasp on PID, and tuning K's.

[EDIT] {Remembered we really only programmed a PI for the line follow, it was very good, and we also learned to zero the I term when the error changed signs. }

[apalrd]

Ok, I didn't talk about the process for determining the gains.

There are several methods for tuning the gains. This is the method I use. The first step is to determine which terms you need.

P only:
If you only need P, you initially ask yourself this question:
-At what point would I start to slow down the motor of I was driving the mechanism manually? What is the value of Error at this point (irrelevant of sign)
-What is the range of my motor(in FRC this number is usually +-1, sometimes it's 127 in 8-bit systems)
-Divide these numbers. Motor on top, Error on bottom. Then, at that exact error, the Motor will be the maximum motor possible. At less error, you will get less power. At more error, you won't get more because you've saturated the output.
Once you've got an initial ballpark gain, you can run the system through various error and range tests (By setting the starting position and setpoint to different things and letting it try to find the position). You manually tweak as necessary. It's a balancing act between overshoot and time to target, you need to prioritize as you wish.

PI:
-Start with P only and get a good P gain
-Decrease P slightly (90% or so of what it was) and add I. I, in many of my PI position controllers, is roughly 10% of P.
-If you are getting oscillation, look at the windup of the integral (graphs help here). Limiting the max range of the in positional controllers is usually a good thing.
-It's mostly just playing around with the numbers until you're happy.

PID:
-I have not manually tuned a PID controller before. I use the Ultimate Stability ("Zeigler-Nichols") auto-tuning method when I need all three terms. I recommend reading about it elsewhere, it basically goes like this:
-Find the P gain at which the system oscillates at the same amplitude indefinitely. This is the Ultimate Gain (kU)
-Find the period of oscillation. In my case, timing was in loops (timing was deterministic enough for no dt-compensated math), so I counted loops in my data captures between peaks of the oscillation. If I was multiplying I and D by dt, I would use Milliseconds (or the units of dt) instead.
-Use some magic formulas which I found on The Internet to determine the gains for P, I, and D. I found the Internet (I particularly liked this site for these numbers). Note that you end up with tI and tD, you need to convert them to kI and kD. kI = kP / tI, kD = kP*tD

This method worked well for all of the VRC arms I tuned (many). My tolerances were rather large (+-1" at the end of a 24" arm) and I was useful to deal with varying weight. I tuned with one game piece, since I could hold two game pieces, and it seemed to be close enough.




(Note: An LUT is a Look-Up Table. Basically all control systems I deal with in Powertrain are heavily based on interpolated lookup tables.)

[Wildcats1378]

Awesome. Very much thanks for helping understand this. I haven't had access to our programming computer, but now that I actually understand what is actually going on, I'm sure I can figure out there ample code and work from there.

[RyanN]

Also check out Fuzzy Logic. Apparently it's not as popular in the US as PID, but is still a very useful form of closed loop control.

Fuzzy logic works on the concepts of human thinking. You have responses for certain errors, same as the error with PID (set - process). You then look at your error as, for example:

Very High
High
A little High
Looking good
A little Low
Low
Very Low

Then you have responses for each of those conditions. You can add in other dimensions. Kind of like making a PD controller.

My error is very high, so correct very fast.
My error is high, and my rate of change is really fast, so correct slower.
etc...

Fuzzy Logic handles extremes, well... extremely well. PID has a tendency to go a little crazy with too much error, or with too slow of correction. This is mainly due to the integrator. The integrator may work great with a small error, but with larger errors, it will integrate, and integrate, and integrate, until it integrates so much that it completely overshoots your set-point, making it under-damped, or unstable.

Also, you might consider a bang-bang in your PID. It works really well for speed control, such as how fast your shooter is spinning. It can reduce oscillations and overshoot, while also getting to your steady-state faster than with a over-dampened response.

Anyway, I have to run, so none of this was previewed for complete correctness. Add comments, fix my mistakes, or give me a thank you. All is welcome!

[Michael Hill]

This is a great tutorial on dealing with nuances with PID control:

http://brettbeauregard.com/blog/2011...-introduction/

It's written with arduino in mind, but the algorithm can be easily ported to anything.