Simple explanation for PID controller?

[Guest]

How does messing with the variables affect a PID controller? I know what "proportional" does, kinda understand what "derriatave" does, but not much about "integral". Could someone give a relatively simple explanation for the derriatave and integral? Finding a way to plot it on a graph would be helpful as well.

[Green Baron]

Simplest i can imagine, without any graphical help: a course correction.

You measure a difference between "should be" and "is". So you apply in a first step a correction that brings you towards an intersection between your current course and your "should be" course in a finite time. In a second step, shortly before you actually cross your "should be", you apply a second correction that adjusts your intersecting course to match the "should be" course.

Don't we do this every day ? ;-)

A PID controller would do this constantly. Of course (off course :-)) in a manner that does not lead to resonance or over- or under-correction.

 

Edited October 22, 2018 by Green Baron

[Gaarst]

Think of a PID controller as controlling a deviation in the craft's trajectory. P is proportional, so a PID will apply more correction the further you deviate from your original point; I is integral, in this case integrated over time, so the PID also applies a correction proportional to how long you have been away from your stable point; D is derivative, so speed, so the PID will also act stronger the faster you are deviating from the stable point.
You can also think of it as accounting for present, past and future deviations respectively: P for how far you currently are from the original path, I for how far you have been until now, and D for how far you will be in the near future.

The parameters affect how much the PID responds to each individual type of deviation. It's a bit vague but basically you want them tuned properly to quickly correct a deviation without overshooting; depending on the behaviour of the controller you can guess which ones to increase or decrease to tune your PID. There are a few methods to tune a PID quicker and more accurately than manual guessing and tweaking.

The Wikipedia article on PID controllers is fairly complete but you need bases in control theory to properly understand all of it. Still, there are a few graphs that can help you understand how the parameters affect the response of the PID.

Edited October 23, 2018 by Gaarst

[K^2]

EDIT: I've made an interactive example of the following in a Google Drive spreadsheet. You won't be able to edit it, but if you want to play with the inputs, you should be able to save a copy to your own drive, so long as you are signed in to Google. There are two boxes that describe initial state of the system and the PID parameters. These are the values you can play with to see how it affects response of the system.

Link to the spreadsheet

The computations are done via a dirty Velocity Verlet integration, but it's good enough for this demo as it turns out. 

Original text with way more math follows:

I don't know if I can give a simple explanation, but I can try for one that can be logically followed and with pictures! PID can apply to many different states, but it's easiest to think about position of something. Lets start with PD terms. The idea is that we have an object that's initially at some position x₀ moving with some velocity v₀ and we want to bring it to x = 0 and keep it there. So we can write down equation for position of the object x(t) before we tried anything as function of time:

x(t) = x₀ + v₀t

We are also interested in the rate of change of position x, which is velocity v(t), but we often denote as x'(t) to explicitly specify that it's the rate of change of x. If you look at Wikipedia article on derivatives, you can probably follow along, but in either case, the correct expression is:

v(t) = x'(t) = v₀

None of this is what we want, though, as we want x(t) to go to zero. Simplest thing we can think of is to push on object towards the center, and the force should probably be proportional to how far we moved the object. It's fairly arbitrary what to set proportionality constant as, but typical choice is to have F = -ω²m x(t). Here, ω is related to time scale on which you want the system to react, and m is the mass/inertia of the system. Together, m/ω² is the P term in the PID. Using Newton's third law, we can write down the equation for the rate of change of velocity, which is also known as acceleration, or second derivative of position x''(t).

a(t) = x''(t) = F/m = -ω² x(t)

And rearrange it slightly to take it to standard form:

x''(t) + ω² x(t) = 0 subject to x(0) = x₀, x'(0) = v₀

That's a differential equation, and solving these is outside of the scope. But the solution to this has fairly straight forward form.

x(t) = x₀cos(ωt) + v₀sin(ωt)

So that's a start, but the object isn't staying at x = 0, it overshoots it. And the reason is pretty simple. If the object is already moving towards center, we shouldn't be pushing it to move even faster. In fact, we should be slowing it down. So we augment the force with a damping term which simulates friction. Intuitively, you expect something oscillating back and forward to slow down and settle at zero if you have some friction. And there are different ways to express it, but the mathematically simplest is to introduce a damping term ζ. The reason is that ζ = 1 gives us optimal decay towards x = 0 without any rebound or being too slow. Without getting into too much math, the D term comes out to 2ζωm, giving us the drag force F_D = -2ζωm x'(t). This gives us the new differential equation.

x''(t) + 2ζω x'(t) + ω² x(t) = 0 subject to x(0) = x₀, x'(0) = v₀

And again, without getting into the math of how this is solved, for ζ = 1, the solution is:

x(t) = (x₀ + (v₀ + x₀ω)t)e^-ωt

So this does precisely what we want with just the PD terms. Which brings up a question, why do we care about the I term? Well, real world tends to be nowhere near as clean. Realistically, there are always additional forces acting on whatever it is that we are trying to control. Imagine that there is some force pushing on the object in the positive x direction. We plug in all the same PD values, and this happens.

Not a total disaster, but if we were using this for some sort of steering, we're definitely off course. And this is where the I term comes in. The general idea is that since the object is definitely at rest, only the P term is currently holding it where it is. Which means that the force we're generating due to P term is equal to the force acting on the object. So the average displacement over time tells us something about the correction we have to apply. The total area under the curve, also known as the integral, is the relevant quantity here. I'm not going to get into the math of it. But let me throw in the I term just to show the end result.

Note that it definitely overshot the zero, and now slowly making the way back. It suggests that my tuning of this PID isn't great. But unlike just the PD portion, where I could upfront say what the good values are given reaction time I want, once you throw in the I term, things get a little worse. I would have to have some advance knowledge of the typical forces we're likely to encounter and make some assumptions based on that. Alternatively, you can do what a lot of people do and just play with numbers until you get something that works.

Edited October 24, 2018 by K^2

[kerbiloid]

One should mention:

https://ksp-kos.github.io/KOS/tutorials/pidloops.html

(Though, maybe that was the cause of the question.)

[Nuke]

i played with pid controllers awhile back and found i could get good results by doing the following. i should point out that this was some time ago and this is all from memory. the system was a 1 axis self leveling platform, the actuator was a servo i had modified, first by wiring the motor directly to an h-bridge, with the potentiometer going into an adc. i was using an arduino though i dont remember which one. the platform was made from lego. in addition to the feedback on the potentiometer i was also using an accelerometer to "find down" in order to calculate the angle of the platform relative to gravity. 

all values initially to 1. bring up p until you get the response you want from the system. set it as fast as you can ignoring any oscillations, provided it doesnt loop around (for linear systems this will never happen so take this with a grain of salt). its actually a good idea to monitor power consumption, as you can reduce the rate to save power (which places a constraint on your design). once satisfied bring up the d to reduce both frequency and magnitude of the oscilation. keep in mind you arent trying to completely eliminate it. strike a balance between speed and stability. if you dont get the results you want you should start over and try a different p value.  from there start tuning the i to get rid of the overshoot and eliminate the oscilation. my results were not perfect but the system was able to stay level enough keep a marble from rolling off the platform. 

[Mad Rocket Scientist]

So in a real application, you would send current position and velocity to the PID, then it would return a magnitude and direction to apply a corrective force, which you would turn into moving hardware, right? So how frequently do you run the controller's program?

Edited October 26, 2018 by Mad Rocket Scientist

[K^2]

12 minutes ago, Mad Rocket Scientist said:

So in a real application, you would send current position and velocity to the PID, then it would return a magnitude and direction to apply a corrective force, which you would turn into moving hardware, right? So how frequently do you run the controller's program?

Depends on how quickly and how precisely you need corrections. You probably want at least an order of magnitude between reaction time and update frequency. So if you need course corrections to take within a second, tenth of a second is probably fine. But again, depending on just how precise you want it.

In practice, update frequency of PID algorithm is almost never a limiting factor. You can even build an analog circuit that performs PID, outputting directly to a servo. And even with a chip, it's a very simple algorithm. The most basic micro controller can run it hundreds of thousands of times per second without breaking a sweat. So your limiting factors will have more to do with mechanical systems and sensors. For example, some sensors become "noisy" if you increase sampling rate too much, so they start generating errors. If you have a straight up PID hooked up to that, your control output will be bouncing all over the place as well, and that can be bad for your systems. So you can either decrease sampling rate to get better measurements, or filter your senor input. (Or both, in practice.) Either way, your response time will get worse.

Mechanical limitations are easier to understand. There's only so fast you can make various servos move before you either break something mechanically, or burn out the motors. If fins on your rocket take 100ms to respond, there is no need to update your PID a million times per second.

The errors resulting from PID update times being discrete are very similar to what you get in numerical integration. Moreover, basic PID essentially gives you Euler Method, which is the most error-prone of them all. Fortunately, the damping term in the PID is the very thing that helps you not experience too much problem with it. If D term is too low and P is too high, PID will start oscillating with higher and higher amplitude. But if your D term is close to critical damping of the P term, and P is small enough to give you at least a few updates within the response time, these numerical errors just make response time slightly sub-optimal and/or cause tiny overshoots.

I would point you to the spreadsheet I posted above, but because I was lazy and only set it to 10 updates per second, I actually modified the PID algorithm slightly to reduce integration errors. So you'd have to go to some really silly P and D values before it's obvious.

[Mad Rocket Scientist]

That makes sense, thanks.

Edited October 26, 2018 by Mad Rocket Scientist