I think that PID hits a certain sweet spot between cleverness, ease of implementation and practical utility that makes it catnip for the typical programmer's mind.
I liked it so much that when we had to implement it, I downloaded an open source driving simulator to see it work there instead of the simpler python environment we were using.
It's easy to implement, but hard to tune.
PID controllers can be built from analog pneumatic components, and often are.[1] This predates computer control. The I term is called "Reset" and the D term is called "Rate" in classical control.
[1] https://control.com/textbook/closed-loop-control/pneumatic-p...
Sounds like he made a bag with the first AI craze and retired.
It's sold as something completely different though that will revolutionize autonomous decision-making which it clearly isn't, it's just trying to re-invent the wheel but with neural nets this time around.
I'll confess I didn't understand what you meant with the part of your comment after the semi-colon.
https://mitp-content-server.mit.edu/books/content/sectbyfn/b...
Of course, no one tunes them by hand anymore for these reasons, relying instead on optimization techniques like particle swarm to find the best set of coefficients for a given steady state condition. Eventually, I suspect we will replace most PIDs with a small neural network for almost all industrial applications (a handful of nodes is sufficient). The neural network is also easier to adapt to changing conditions.
> PIDs are great but notoriously hard to tune. They require deep insight into the underlying physical phenomena to get right. They are also rather rigid and cannot adjust well to a changing environment (temperature and humidity can fluctuate dramatically between summer and winter in some climates).
This is not true. PID controllers are often the least dependent on the physical characteristics. They can be tuned with heuristic methods like Ziegler-nichols, often with no knowledge of the actual system.
> Of course, no one tunes them by hand anymore for these reasons, relying instead on optimization techniques like particle swarm to find the best set of coefficients for a given steady state condition.
This is also not true. In the Amazon consumer robotics group we still tuned pid by hand. I’ve _never_ heard of tuning pid with particle swarm, that seems very silly, difficult, and overkill. If you’re going to use an optimization technique, you might as well move to a better controller structure like LQR. I have seen particle swarm used as an estimator, as an alternative to a kalman filter, but never seen it used for tuning.
> Eventually, I suspect we will replace most PIDs with a small neural network for almost all industrial applications (a handful of nodes is sufficient). The neural network is also easier to adapt to changing conditions.
This sounds unlikely to me. Classic control techniques give guarantees that a neural net just can’t. For example, things are provably stable under some assumptions. With a neural net you get no such guarantee. Also, it would be harder to debug and understand, and it would take more memory and compute. I can’t imagine a world where we replace pid with neural nets, they’re fit for very different purposes.
Source: have a masters in controls, worked in robotics in controls team, still do consulting in this area when I have time, and I love it all.
A similar argument was made in the early 90's/late 80's for using Fuzzy Logic (https://en.wikipedia.org/wiki/Fuzzy_logic) instead of classical control algorithms, including PID.
I'm sure many here will remember the late Bob Pease of National Semiconductor writing articles[1] against this, mainly due to the inability of the designer to predict the behavior of the system. Believe it or not, being able to logically reason about how an algorithm that's controlling tens of thousands of $$$ of product in process is actually important.
[1] https://www.electronicdesign.com/technologies/embedded/digit...
in the industry, maybe. Otherwise, FRC competitions are seeing a LOT of manually tuned PIDs
With or without serverless lambda architecture bitcoins ?
I do sort of suspect a fan thermal control curve is a PID response curve written out in long hand but don't really have the math to prove it.
No, a fan response curve is kinda-sorta a P controller. It does not take into account 1) how quickly the temperature is rising or dropping (D) 2) the time passed since the system has drifted from the target temp (I).
No futzing with software needed.
Reminds me of Dave "EEVblog" Jones' in his "always give negative feedback" T-shirt.
(for those who don't know: it's a reference to opamps)
My computer sits next to my desk, so I want it to be as quiet as possible. This means the fan should run as the lowest speed which maintains a reasonable temperature, so at the very least there should be some kind of mapping between temperature and fan speed.
However, a rapidly-changing fan speed results in a more annoying sound than a slightly faster fan, and chip temperatures can ramp fast, so a simple linear mapping between temperature and fan speed isn't enough. To get a quiet fan in an environment where you are, say, loading the CPU to 100% for 100ms every second, the fan controller should be able to average out the heat production and let the fan run at a steady speed. After all, the cooler is a big chunk of metal, so its temperature will never ramp as fast as the core itself, so a rapid fan speed response is pointless.
Whether it gets upvoted depends on a lot of things.
For example, I will upvote this submission, but not your comment.
I still learn a lot from wikipedia. Maybe it's not useful for those who are experts in every thing. I am not one of them.
Not that I am complaining, I come to this place to learn cool stuff, and there isn’t enough of it.
Still uses a PID for BLDC motor coil current control, as this control loop is much more predictable.
Currently using the proportional part only from a PID for position control, but this may change in the future.
[0] https://en.wikipedia.org/wiki/Active_disturbance_rejection_c... (although this isn't a very useful reference if you want the implementation maths!)
But the interference from the PWM signal appeared to mess with the speed sensor readouts that I couldn't make it work.
Can what you describe be used to solve it? If you would be kind enough to describe it, that would be great.
But the benefit of PID is it is fairly easy to tune and works in a really wide range of situations.
The text book jumped right on to the integrals and derivations without even a whisper on what the thing is supposed to be useful for!
I want to understand this so much now, but the memories of that paper is such a turn off!
