PID Controller Explainer (2022) | Hacker News Reader

PID Controller Explainer (2022)

ben.bolte.cc

In the ‘what is a PID controller’ section, it doesn’t mention time delay. PID controllers solve problems where there is a time delay in the system between inputs and corresponding outputs. If there is no time delay, then a PID controller won’t help.

My favorite analogy is a suspension, like a car or mountain bike shock absorber. A PID controller is basically a unitless suspension system. P is like the spring, I is (sort of) like the compression damping and D is like the rebound damping, again, sort-of. Tune those 3 values and you’ll have a smooth ride and be able to respond to big bumps. The analogy to a physical suspension isn’t precisely perfect, but to a first approximation, a PID really is just a digital shock absorber.

Why won't it help if there is no delay? What system truly has no time delay and no inertia?

PID systems are basically a differential equation and optimal coefficients are just solutions to that system which maximize responsiveness and minimize ringing, so I would think the effect of decreasing time delay just adjusts the Ki and Kd to account for the smaller Tc value.

All physical systems have time delay, but software doesn’t necessarily. I bumped into PID controllers writing software for video games where I had the option to not have a time delay in the system, if I wanted to do something less physically realistic. In a game, you can (and I often did) use a proportional-only controller for certain things. Then I got surprised when that didn’t work, after a time delay was introduced. I mainly called out the time delay because the delay is what causes the problem that needs solving, so it seems reasonable and important to state. But I wouldn’t argue with anyone who said the delay part seems obvious. ;)

> but software doesn’t necessarily.

Is this true? I mean the delay may be inconsiderable but there is a delay, right?

It depends entirely on what you’re doing in software, but yes it’s true that you don’t always have a delay. Your simulation doesn’t have to involve time at all, so that’s one way you might not have delays. But if you do have a simulation involving time, and your update of some entity in the system can change it’s behavior instantaneously, then there’s no delay. Like I said, in a game you can choose whether your AI has to follow physics or not. It is easy to make a non-physical car that can turn instantaneously. When you do that, a P-controller works just fine. As soon as you make it follow physics, which adds time delay between input and response, then you have to have the I & D terms, otherwise your car will be unstable. In video games it’s very common for cameras to try to follow something (like your avatar) smoothly using a P controller, they are a good example of a very common bit of software that has no delay - they can follow and turn without being subject to physics, and thus they generally don’t need the I & D terms of a PID controller.

not necessarily. feedforward path delay can be zero. typical mistake done while modeling feedback systems in SW.

I have tuned mountain bike suspension (recently) and took undergrad control systems theory class (ages ago). And I am struggling with the PID analogy here.

It seems to me that a suspension system has two separate PD controllers which share the same P factor (spring rate), but have the sign reversed in one direction. Then independent control rates on the velocity, as all suspension systems with which I am familiar allow separate rebound and compression damping control. That is, the compression side would be something like P + CD * dp/dt and rebound of -P + CR * dp/dt. (little "p" is position).

Maybe I just need to stew on this one a little longer though.

If our variable here is position (which I'm assuming since the spring rate is proportional), wouldn't the damper settings be a coefficient of the derivative term?

Yes, thank you. Fixed it (in a still-clumsy way).

There are different ways to think about it, and I don’t quite get what you mean about 2 separate PD controllers, but that might also be a valid analogy. This is partly why I qualified my comments about the I and D terms with “sort-of” ;). But I’m also trying to boil it down to the simplest analogy possible, and I might sacrifice a little precision along the way. The mechanism and forces of PIDs do not exactly correspond to physical suspensions, but if you stand back and look at it, they are surprisingly similar at a conceptual level. The most important part is that the problems are the same, it’s a system that’s trying to smooth out the bumps and prevent overshoot. PID controllers are more abstract than suspensions, and they can be used in ways that feel different, but the basic problem is more or less one of absorbing shocks smoothly. Like your oven or your thermostat, they’re trying to keep the temperature you set and minimize overshoot and oscillation, even though they only have a binary on/off output mechanism.

Here’s how I think about it: the P term is the spring. In a physical spring the force is quadratic in position or “error”, while a PID controller’s P term is linear. No reason you can’t make a P controller quadratic or anything you want, but the analogy between P and the spring seems clear enough to me.

Now compression damping is trying to slow down or resist fast compression and prevent overshooting, prevent having too much spring force from accumulating on the rebound. Sometimes there are even separate high and low speed compression damping mechanisms (I’m sure you know that). In a PID controller, the D term is also designed to resist proportional changes from happening too fast, it resists change in proportion to how fast things are changing.

And back to physical suspension again, rebound damping is designed to prevent rebound force from accumulating. You want to return to neutral position as fast as possible without a rebound force. The idea is to balance 2 different goals: 1- don’t buck you off the bike, and 2- don’t let the suspension pack down and stop working. The PID controller’s I term does this, in a way, it prevents the pack-down by monitoring the average position and if it stays too far away from neutral for too long, it pushes things back to neutral.

If you’re paying attention, you might notice I swapped I & D in my analogy here compared to above. It can (sort-of) be argued either way, which maybe goes to your point that the analogy ain’t perfect, and you could maybe look at it as 2 PD terms. I think it’s best not to try to fix the analogy, but just to see it as a very blunt instrument for understanding - a suspension and a thermostat and a robot steering a car all have a common type of problem to understand and at least conceptually, a solution that looks similar from a distance.

@anthomtb, Oh I get it now! You’re right, and your analogy is better than mine from a physical perspective. A bike suspension really is just a PD controller with independently adjustable D coefficients, depending on sign.

Maybe it’s valuable to think of suspension pack-down and controller drift as the same problem, or maybe not. They have similarities, but they’re not the same problem. My thinking of the I term as preventing pack-down is perhaps the main justification for saying a PID controller is like a suspension. But, on a real bike, packdown is being solved by the spring (P) and tuning the rebound (D), and drift isn’t something that happens.

Are you saying that a PID controller would not work in a system without time delay? Or in a system without time delay, a PID controller would function identically to a simpler controller (A proportional-only controller perhaps)?

My understanding and experience has been that large time delays force less aggressive tuning of the controller. I've been meaning to experiment with model based controllers to try and improve the responsiveness of the system.

I’m saying PID controllers are unnecessary and don’t help solve any problems if there’s no time delay (which can happen in software). The I and D terms are based on time, i.e. integrating/differentiating with respect to time, so talking about time delay is perhaps obvious, but it wasn’t obvious to me the first time I heard about PID controllers, and even in the article we’re commenting on, the problem statement isn’t super clear. I think the time delay is the most important part to understand, the time delay is what causes the problems that PID controllers are designed to solve. And yeah, exactly, a proportional-only controller is fine for vehicle steering, for example, if you have a fictional vehicle that can make instantaneous changes in angle.

I don't know that it's the time delay that's important, as much as unknown external forces acting on the system? If the problem was just that it took a known amount of time for the vehicle's angle to change, wouldn't we be able to compute open loop control solutions in advance?

Well if you have unknown external forces acting on the system, but the response to those forces is instantaneous, then a PID controller isn’t the right solution. A much simpler proportional controller with little to no tuning will do the entire job. Note that in a software system that uses discrete time-step samples, “instantaneous” means the system’s complete final response to the input is produced during the same time step that the input change was detected. If the response is produced more than 0 time steps later, then there is a delay.

On the other hand, even if you have known forces that take a known amount of time, a PID controller might be the right solution if the integrals you have to solve are unsolveable and/or just difficult. One problem with that idea is that it’s easy to get slightly wrong when complex physics is involved, and slightly wrong output can have unbounded catastrophically wrong consequences. You’d still want to monitor the inputs and responses, and so you’d end up with a PID controller even if you did try to pre-compute the solution.

However, vehicle steering does not take a known amount of time to complete, it takes an unknown amount of time, and there are many dimensions and variables. So, yes implicitly in PID controller land, you have a good point in the sense that part of the idea is that the inputs and response times are unknown. If the inputs were known and the solution was exactly computable and the exact answer was reliable, then you could use some kind of pre-integrator instead of a PID controller. But, I think it’s still fair to say that time delay is the main cause of the problem that PID controllers are designed to solve, because unknown inputs without time delays are not PID controller problems.

PID success does not relate to time delay except the additional phase.

Time delay is covered in the "How do PID controllers work?" section right after "A simple controller"

The most succinct and intuitive explanation I’ve found on PID is this one: https://www.youtube.com/watch?v=4Y7zG48uHRo

Just watched, and yes this is a very good explanation. My intro to PID controllers was when writing AI vehicle steering for video games. I wasn’t taught about PID controllers in my CS degrees, so I started naively with what I would later learn is a P controller, and then got really surprised when lowering the gain turned into larger error. Like trying to smooth out the steering makes the problem worse, it was surprising to me. I told a very smart guy near me what I’d learned and he was like, “Oh yeah, you just need a PID controller”.

I used to design PID process controllers in industry. In watching this vid I realized one reason that designing a self-driving car is so difficult. Toward the end, in the process control diagram, he has [Vehicle] as the controlled process. This reminds me of the old math joke about "assume a spherical cow". The difficulty with a self-driving car is that it isn't just the vehicle that has to be controlled but [Vehicle + Current Road] so the controlled process is not just difficult to model but that it is changing all the time and sometimes rapidly.

I ended up learning about PID's when playing the game From the Depths, where you have to use PID's alongside thruster mechanisms to keep your craft balanced. It felt like I picked up how they worked better by using a 'hands on' example of them, in this case a game.

PID controllers are one way to control systems described by differential equations.

Given a certain desired value of the solution they can be used to force the dynamics to converge towards that value.

For certain types mostly linear equations they are the optimal way to achieve this.

I have no idea why, but the topic is almost never presented that way. Instead people talk about valves and pistons and whatsoever, but in the end it’s just that:

You have an ODE and some desired value for the solution ; you have some control over the inhomogeneous part. PID control is just a tried and well understood way of excepting this control.

The integral term handles an unknown (or unmodeled) additive error. So in that sense, you don't have the differential equation and you still apply PID.

I've always found it interesting how PID system theory and especially tuning seems so empirical, especially in how it's taught.

We deal with similar kinds of feedback systems all the time in integrated circuit design (see: Phase Locked Loops), but they're evaluated theoretically, and by extension, I think, more rigorously. I'm sure this is largely due to the fact that what we're controlling has very well-defined, well-understood, and simple behavior, where "PID" controllers are often used in far more complex, multi-part systems like motor/speed control, temperature, etc.

And while I think there's a lot of value in developing that kind of intuition, I've run into a handful of junior engineers at my company who don't deeply understand what's happening in the system and draw incorrect conclusions or make dangerous decisions.

As one example, I saw a presentation showing an oscillation at the output of a tuning system when the sensing element was moved further away from the controller. with changing amplitude based on what the sampling rate was. The engineer had no idea why this was the case - moving the sensor away was introducing a distributed, continuous-time pole into the system, whose location in the discrete time, sampled system was moving with sample rate, and changing the feedback systems phase margin based on its proximity to the other discrete poles/zeros from the PID. Even worse, he didn't realize that in the extreme, the system could go completely unstable with in bounded oscillation!

Yeah, the ideal-ness of electronics is much better than other systems like mechanisms, chemical plants, etc. In systems with substantial unmodeled effects the principled methods for tuning don't work as well. But I agree that knowing the theory is still super important sometimes.

For me, PID is one of those “algorithms” that has cool abstract analogies with life in general. I see it as a simple mathematical expression to how we react to things. Do we act “in the moment” (P), or with more conservatism and restraint waiting for consensus (I) , or speculatively skating to the puck (D).

Sometimes when I look at why different individuals react differently to the same observations, it’s interesting to speculate how their P, I, and D weights are resulting in different conclusions.

I liked https://www.wescottdesign.com/articles/pid/pidWithoutAPhd.pd... though I’ve not looked at the OP so I don’t know how it compares.

If you study linear control theory and you can characterize the dynamics of the system you're trying to control, you can just solve the differential equations analytically with a Laplace transform* and write down the proper values of the coefficients instead of searching for them.

*or Z transform if the system is discrete

Furthermore, the equations will tell you whether you even need the "I" and "D" parts of PID.

Yup you can even make PI^mD^n controllers... the challenge comes in the linearization.... recently we struggled with the backlash in a gearbox... with a long chain of small backlashes... we estimated the state of every pair... treated as an inertial system with no K and a short travel until the next moment locked in after e.g. .1 to 2 degrees.

The higher level system (surgery robot) also had a closed loop so we didnt have to be perfect, but cleaning up gave higher bandwidth.

PID controller widely used in mid-high tier espresso machines to keep water output temp constant https://1024kilobyte.com/blog/2020/3/3/new-project-coffeepid...

Any recommendations for an algorithm for safe online PID tuning? Maybe something involving pole placement or frequency response analysis?

It really is mostly empirical, especially since any real system has limits on the amount of proportional, derivative, or integral control authority you can apply. Still, every controls student is taught Zeigler Nichols, and are simultaneously told by their professors that nobody uses it. https://en.m.wikipedia.org/wiki/Ziegler%E2%80%93Nichols_meth...

I've used this successfully for some hardware projects: https://pidtuner.com/#/

That looks like it's using the step response, which is on for an offline tuner but it wouldn't work for online tuning. Think of an automotive cruise control--to measure the step response the controller would have to floor it, which wouldn't be safe. I'm looking for something that slowly, continuously optimizes the tuning parameters as the controller is running.

Any sources that approach the subject from a mathematical formulation?

Feedback Systems is probably the book you are looking for:

https://fbswiki.org/wiki/index.php/Feedback_Systems:_An_Intr...

https://vanhunteradams.com/PID/PID_Analytical.html

(In full disclosure, this is a resource that I put together)

Reply on news.ycombinator.com