Hacker News Reader

Comment by dahart | Hacker News Reader

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.

View on HN

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"

Reply on news.ycombinator.com