[HN Gopher] PID Controller Explainer (2022)
___________________________________________________________________
PID Controller Explainer (2022)
Author : mean_mistreater
Score : 74 points
Date : 2024-04-06 07:58 UTC (15 hours ago)
(HTM) web link (ben.bolte.cc)
(TXT) w3m dump (ben.bolte.cc)
| cgg1 wrote:
| The most succinct and intuitive explanation I've found on PID is
| this one: https://www.youtube.com/watch?v=4Y7zG48uHRo
| dahart wrote:
| 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".
| dmfdmf wrote:
| 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.
| dahart wrote:
| 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.
| kortex wrote:
| 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.
| dahart wrote:
| 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. ;)
| entropie wrote:
| > but software doesn't necessarily.
|
| Is this true? I mean the delay may be inconsiderable but
| there is a delay, right?
| dahart wrote:
| 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.
| eadler wrote:
| Time delay is covered in the "How do PID controllers work?"
| section right after "A simple controller"
| anthomtb wrote:
| 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.
| ahepp wrote:
| 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?
| anthomtb wrote:
| Yes, thank you. Fixed it (in a still-clumsy way).
| dahart wrote:
| 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.
| dahart wrote:
| @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.
| ilayn wrote:
| PID success does not relate to time delay except the additional
| phase.
| ahepp wrote:
| 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.
| dahart wrote:
| 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.
| jcgrillo wrote:
| Any recommendations for an algorithm for safe online PID tuning?
| Maybe something involving pole placement or frequency response
| analysis?
| jopizio wrote:
| I've used this successfully for some hardware projects:
| https://pidtuner.com/#/
| jcgrillo wrote:
| 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.
| salamanderman wrote:
| 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...
| dan-robertson wrote:
| 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.
| waynesonfire wrote:
| Any sources that approach the subject from a mathematical
| formulation?
| kayson wrote:
| 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!
| blt wrote:
| 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.
| travisgriggs wrote:
| 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.
| robotnikman wrote:
| 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.
| niemandhier wrote:
| 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.
| gugagore wrote:
| 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.
| dreamcompiler wrote:
| 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.
___________________________________________________________________
(page generated 2024-04-06 23:01 UTC)