For a robotic BLDC motor velocity control application, I moved to using a linear ADRC (Active Disturbance Rejection Control) [0] controller. It is not much more complex to implement that a PID, but at least in my context it handles changing real-world environmental conditions with a correctness which I could not achieve with a PID however much I tried to tune 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.
I once tried to make a RC toy car so that it has proportional speed controls. I used some hall effect sensors to measure the speed at which the wheels are rotating and used it to compute the PWM signal that should be fed to the motor.
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.
I use an MT6701 magnetic rotary sensor mounted on the motor shaft, running in AB[Z] mode. This is used to measure the angle of the motor, and generate the correct PWM signals for the three motor coils. My inner current-control loop runs at 15kHz, using a PI controller.
The fascination of programmer types with classical control and estimation topics is endlessly interesting as someone who studied control and estimation and hangs out here for interest in the programming. For me it was surprising to see that JEPA is a model predictive control algorithm it an almost literal sense; I guess I’m happy to have studied what I chose when I was 18.
I signed up for one of the first MOOCs ever, about self driving cars by Sebastian Thrun, and of course PID was part of the curriculum.
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.
> 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.
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.
Pretty easy to tune really - almost never use derivative, increase the proportional until oscillations occur then halve it, add a little integral, not so much it oscillates.
It’s very intuitively appealing. We like it at my university for teaching first years how to build a line following robot. It’s one of the first times you can get students to really get that “ah” moment when they realise what they can do with code—it can affect the real world!
>> For me it was surprising to see that JEPA is a model predictive control algorithm it an almost literal sense; I guess I’m happy to have studied what I chose when I was 18.
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.
Yeah, kind of hilarious to me that this was posted here. I suppose if you’ve never encountered control systems at all before they are quite simple, elegant, and cool, but I’m surprised any technical person hasn’t come across them at some point.
I think CS degrees are a bit light on classical theory in the modern day. In Australia CS degrees are what they say on the tin, but in America it seems almost as if CS degrees are anywhere from cybernetics to pure software development
Interesting generalization; that’s almost the opposite of my experience.
A common hiring anecdote we share with people outside tech is literally: “A CS degree doesn’t teach you how to code.”
For me, ~25 years ago in the UC system, it was all math/science/theory-oriented. Some C++/Java that was introduced to get you through all that theory. Learning how to code/actual software engineering comes with practical experience.
My CS degree was a software engineering degree in a trench coat. I went back to give a guest lecture a decade later and the curriculum had changed to be more theory-focused.
(I am quite happy to have gotten the software engineering education.)
I wouldn't underestimate the value of introductory submissions! Every topic is familiar to some users, no topic is familiar to all users, and let's not forget that newcomers, who still have everything to learn, are particularly welcome.
I used it in metal detector (direct frequency measurement kind). It works really well. I (and you probably too) half assed pid controllers before you even know what it is. But it makes perfect sense. Proportional part reacts to the acute difference, derivative adjusts it when your controller is already going right direction to limit overshoot, and integral part improves cases when the difference is small but persist for long time. Learn them and use them, they're good tool.
My personal exposure to the PID algorithm was my GPU fan. There is supposed to be some sort of internal fan curve to control it's speed but mine was not working, crashes everywhere. I Could still set the speed by hand. and while I was putting together a sort of hacky user space fan curve I had an epiphany. I Don't actually want a fan curve. I want to set an ideal temperature and have the computer figure out what fan speed is needed to maintain it. So I learned more about control logic than I was really prepared for and my user space fan speed script has a cute little PID controller to do just that. (technically for fan thermals you really only need a PD controller. No anticipatory preload needed. but who's counting)
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.
> 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).
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.
At least for me, it's not about the wiki link. I'm here for the comments, the stories, anecdotes, related deep Diving links and general chit chat.
If you view the link as "this is the control systems thread for today", all the upvoter make a lot more sense.
yeah, this is the true gold of hacker news: learn about a new concept from the post, and then have knowledge multiplied by discussion across a range of experience levels from curious readers, to daily practitioners, and sometimes even p99.99 top experts in a field.
I did a lab exercise (part of physics curriculum) with a PID controller once. It controlled a small electric motor with a small flywheel (i.e. not much inertia). We hand-tuned the parameters with potentiometers. The effect was quite impressive: the flywheel kept spinning at the same speed when we touched it, even with moderate force. It felt like there was a huge motor driving it because the RPM just wouldn't budge. It was still not hard to stop it completely (small motor after all), but it felt very stiff before that point.
Thanks to the advice of a colleague who had studied control theory, I once used PID controllers to manage autoscaling compute resources downstream of a lot of message queues. We used plenty of more typical autoscaling systems too, but for some workloads, PID controllers were ideal—when we had thousands of compute clusters across many queues, they minimized the state that needed to be stored between scaling system polls while effectively smoothing out the scale up/down rate to minimize resource waste and pointless whipsawing.
I think the more valuable topic to study is feedback control loop in general as a part of control theory: gain, stability/oscillation damping, overshoot, hysteresis/minimum commit, and noise filtering strategies (low pass, Kalman, etc). Those are just very useful general concepts applicable to any kind of long running systems.
The actual PID controllers ,however, are actually really finicky to tune, and hard to reason about directly. Good for simple linear systems, but it falls apart as real life systems tend to be complex and nonlinear.
Oh! My first job out of college had me implementing PID control for a two axis rotary control tables. The design had counter weights (think dumbbell shaped). I was the dumbbell implementing this and as I was young, had almost 168 hrs a week to work on this.
OMG! I spent so much time trying to tune this and it would occasionally enter these oscillatory states back and forth. Unfortunately the device on the turntables cost about $500k….
It was such a painful experience.
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).
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.
This isn’t meant to be an attack, but almost everything you say here is false.
> 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.
I saw a crazy stat somewhere like some large fraction of the industrial PID controllers that are actually deployed in plants are completely untuned--that is, just running default settings. I think it was a book about tuning PID controllers, but I don't have the exact citation handy..
I’d totally believe that. You can buy devices that even tune themselves automatically, using model-free methods like Ziegler-nichols. I’m not familiar with the domains where you would use that sort of thing, but I guess it would be applications that aren’t safety-critical, maybe air conditioning or something like that. I bet many people put the thing in place, and then it works well enough that they never even click the “tune” button
I don't have a good intuition about the what makes a problem sensitive to tuning, is it possible there are a large number of control problems where proper tuning doesn't matter much? Or the deleterious effects of improper tuning (like oscillations or overshoot) are masked somehow?
EDIT: I guess intuitively, big (lots of inertia) damped systems are probably pretty safe--you can do all kinds of crazy things with the control input and it won't really have much effect. The only way you could go wrong is drift.. Anything that is inherently stable seems like it should be "easy"--like a high-wing monoplane with lots of dihedral angle, you release all control inputs and it defaults to straight and level flight.
Yes, you’re absolutely right, systems that are default-stable are much easier to tune, and large inertia does make the system more stable. For those sorts of systems, any minimal feedback is often enough to get the performance you want. If you have high requirements you might need something fancier, but frankly most systems don’t have high performance requirements. Having very fast feedback loops helps too, so with digital controllers getting better and better you can be a bit sloppier with control design and it will still work.
There are indeed a large number of control problems where proper tuning doesn't matter much. I think we’ve built many of our tools to be “easy” to work with, and one aspect of this is that they’re intentionally made in a way that’s easy to control. Another factor here is that the “difficult” problems need some serious thought, which require research, measurement, and advanced degrees, making them more expensive. Many of these are just not worth the cost (yet). And even if you _do_ design a well-performing complex controller, you need to hire controls engineers to maintain and update it as designs change. I _love_ using LQR, optimal control, robust control, etc, but can almost never justify it. As a result, probably 90%+ of control applications by count just use PID. The remaining 10% are of course where most of the research happens, they’re much more fun.
was about to comment similar things! PID is relatively straightforward to tune. Also a lot of the time you just need a PI controller. D can be problematic depending on what noise you have.
> we will replace most PIDs with a small neural network for almost all industrial applications
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.
It's very dated by now, but The Control System Design Guide by George Ellis is a pretty good hands-on book about designing and analyzing control systems. It goes well beyond the basic PID stuff, but I found it very helpful when I was getting a Mechatronics certificate 20+ years go. TBH, it's the most accessible book on the subject that I've ever read.
For a robotic BLDC motor velocity control application, I moved to using a linear ADRC (Active Disturbance Rejection Control) [0] controller. It is not much more complex to implement that a PID, but at least in my context it handles changing real-world environmental conditions with a correctness which I could not achieve with a PID however much I tried to tune 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!)
I once tried to make a RC toy car so that it has proportional speed controls. I used some hall effect sensors to measure the speed at which the wheels are rotating and used it to compute the PWM signal that should be fed to the motor.
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.
I use an MT6701 magnetic rotary sensor mounted on the motor shaft, running in AB[Z] mode. This is used to measure the angle of the motor, and generate the correct PWM signals for the three motor coils. My inner current-control loop runs at 15kHz, using a PI controller.
The fascination of programmer types with classical control and estimation topics is endlessly interesting as someone who studied control and estimation and hangs out here for interest in the programming. For me it was surprising to see that JEPA is a model predictive control algorithm it an almost literal sense; I guess I’m happy to have studied what I chose when I was 18.
I signed up for one of the first MOOCs ever, about self driving cars by Sebastian Thrun, and of course PID was part of the curriculum.
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.
> 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.
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...
Pretty easy to tune really - almost never use derivative, increase the proportional until oscillations occur then halve it, add a little integral, not so much it oscillates.
PI controllers (D = 0) are not hard to tune, but if the system has enough inertia to need a D term, then it gets complicated.
It’s very intuitively appealing. We like it at my university for teaching first years how to build a line following robot. It’s one of the first times you can get students to really get that “ah” moment when they realise what they can do with code—it can affect the real world!
Whatever happened to this guy?
Sounds like he made a bag with the first AI craze and retired.
>> For me it was surprising to see that JEPA is a model predictive control algorithm it an almost literal sense; I guess I’m happy to have studied what I chose when I was 18.
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.
This classic programming text book discusses computational analogs of the "signals" in signal-processing systems.
https://mitp-content-server.mit.edu/books/content/sectbyfn/b...
Yeah, kind of hilarious to me that this was posted here. I suppose if you’ve never encountered control systems at all before they are quite simple, elegant, and cool, but I’m surprised any technical person hasn’t come across them at some point.
I think CS degrees are a bit light on classical theory in the modern day. In Australia CS degrees are what they say on the tin, but in America it seems almost as if CS degrees are anywhere from cybernetics to pure software development
Interesting generalization; that’s almost the opposite of my experience.
A common hiring anecdote we share with people outside tech is literally: “A CS degree doesn’t teach you how to code.”
For me, ~25 years ago in the UC system, it was all math/science/theory-oriented. Some C++/Java that was introduced to get you through all that theory. Learning how to code/actual software engineering comes with practical experience.
My CS degree was a software engineering degree in a trench coat. I went back to give a guest lecture a decade later and the curriculum had changed to be more theory-focused.
(I am quite happy to have gotten the software engineering education.)
That hasn’t been my experience in the US, either personally or from talking to others who took CS degrees.
Keep in mind that plenty of people on HN and in the industry did not take CS degrees in college. We did learn about PIDs, if briefly.
I wouldn't underestimate the value of introductory submissions! Every topic is familiar to some users, no topic is familiar to all users, and let's not forget that newcomers, who still have everything to learn, are particularly welcome.
I've encountered control systems and PID controls, and I still find PID elegant and cool.
https://xkcd.com/1053/
Also <https://xkcd.com/2501/>.
I used it in metal detector (direct frequency measurement kind). It works really well. I (and you probably too) half assed pid controllers before you even know what it is. But it makes perfect sense. Proportional part reacts to the acute difference, derivative adjusts it when your controller is already going right direction to limit overshoot, and integral part improves cases when the difference is small but persist for long time. Learn them and use them, they're good tool.
Almost always a good analysis will find a control strategy which performs better than PID...
But the benefit of PID is it is fairly easy to tune and works in a really wide range of situations.
And it is most of the time not overkill
My personal exposure to the PID algorithm was my GPU fan. There is supposed to be some sort of internal fan curve to control it's speed but mine was not working, crashes everywhere. I Could still set the speed by hand. and while I was putting together a sort of hacky user space fan curve I had an epiphany. I Don't actually want a fan curve. I want to set an ideal temperature and have the computer figure out what fan speed is needed to maintain it. So I learned more about control logic than I was really prepared for and my user space fan speed script has a cute little PID controller to do just that. (technically for fan thermals you really only need a PD controller. No anticipatory preload needed. but who's counting)
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.
> 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).
That might have been easier solved with eg. an adjustable voltage regulator (like good 'ol LM317?) with a temperature sensor in the feedback circuit.
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)
why not just set maximum speed and forget about it?
Fan noise.
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.
There are two types of nerd - one who optimized fan speeds and one who just lets ‘er rip for max compute ;)
Honest question: are wiki links to any technical topic post worthy now?
At least for me, it's not about the wiki link. I'm here for the comments, the stories, anecdotes, related deep Diving links and general chit chat. If you view the link as "this is the control systems thread for today", all the upvoter make a lot more sense.
yeah, this is the true gold of hacker news: learn about a new concept from the post, and then have knowledge multiplied by discussion across a range of experience levels from curious readers, to daily practitioners, and sometimes even p99.99 top experts in a field.
I think you can post more or less whatever you want.
Whether it gets upvoted depends on a lot of things.
For example, I will upvote this submission, but not your comment.
Why the hell not ?
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.
Sometimes even wiki links to non-technical, obscure articles.
Not that I am complaining, I come to this place to learn cool stuff, and there isn’t enough of it.
Obligatory link to PID without a PhD: https://www.wescottdesign.com/articles/pid/pidWithoutAPhd.pd...
comments like this are why i come to hacker news
thank you!
I did a lab exercise (part of physics curriculum) with a PID controller once. It controlled a small electric motor with a small flywheel (i.e. not much inertia). We hand-tuned the parameters with potentiometers. The effect was quite impressive: the flywheel kept spinning at the same speed when we touched it, even with moderate force. It felt like there was a huge motor driving it because the RPM just wouldn't budge. It was still not hard to stop it completely (small motor after all), but it felt very stiff before that point.
Thanks to the advice of a colleague who had studied control theory, I once used PID controllers to manage autoscaling compute resources downstream of a lot of message queues. We used plenty of more typical autoscaling systems too, but for some workloads, PID controllers were ideal—when we had thousands of compute clusters across many queues, they minimized the state that needed to be stored between scaling system polls while effectively smoothing out the scale up/down rate to minimize resource waste and pointless whipsawing.
„How To Build a Thrust Vectored Model Rocket“ has a good section on this IIRC: https://www.youtube.com/watch?v=4cw9K9yuIyU
I think the more valuable topic to study is feedback control loop in general as a part of control theory: gain, stability/oscillation damping, overshoot, hysteresis/minimum commit, and noise filtering strategies (low pass, Kalman, etc). Those are just very useful general concepts applicable to any kind of long running systems.
The actual PID controllers ,however, are actually really finicky to tune, and hard to reason about directly. Good for simple linear systems, but it falls apart as real life systems tend to be complex and nonlinear.
Oh! My first job out of college had me implementing PID control for a two axis rotary control tables. The design had counter weights (think dumbbell shaped). I was the dumbbell implementing this and as I was young, had almost 168 hrs a week to work on this. OMG! I spent so much time trying to tune this and it would occasionally enter these oscillatory states back and forth. Unfortunately the device on the turntables cost about $500k…. It was such a painful experience.
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).
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.
This isn’t meant to be an attack, but almost everything you say here is false.
> 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.
I saw a crazy stat somewhere like some large fraction of the industrial PID controllers that are actually deployed in plants are completely untuned--that is, just running default settings. I think it was a book about tuning PID controllers, but I don't have the exact citation handy..
I’d totally believe that. You can buy devices that even tune themselves automatically, using model-free methods like Ziegler-nichols. I’m not familiar with the domains where you would use that sort of thing, but I guess it would be applications that aren’t safety-critical, maybe air conditioning or something like that. I bet many people put the thing in place, and then it works well enough that they never even click the “tune” button
I don't have a good intuition about the what makes a problem sensitive to tuning, is it possible there are a large number of control problems where proper tuning doesn't matter much? Or the deleterious effects of improper tuning (like oscillations or overshoot) are masked somehow?
EDIT: I guess intuitively, big (lots of inertia) damped systems are probably pretty safe--you can do all kinds of crazy things with the control input and it won't really have much effect. The only way you could go wrong is drift.. Anything that is inherently stable seems like it should be "easy"--like a high-wing monoplane with lots of dihedral angle, you release all control inputs and it defaults to straight and level flight.
Yes, you’re absolutely right, systems that are default-stable are much easier to tune, and large inertia does make the system more stable. For those sorts of systems, any minimal feedback is often enough to get the performance you want. If you have high requirements you might need something fancier, but frankly most systems don’t have high performance requirements. Having very fast feedback loops helps too, so with digital controllers getting better and better you can be a bit sloppier with control design and it will still work.
There are indeed a large number of control problems where proper tuning doesn't matter much. I think we’ve built many of our tools to be “easy” to work with, and one aspect of this is that they’re intentionally made in a way that’s easy to control. Another factor here is that the “difficult” problems need some serious thought, which require research, measurement, and advanced degrees, making them more expensive. Many of these are just not worth the cost (yet). And even if you _do_ design a well-performing complex controller, you need to hire controls engineers to maintain and update it as designs change. I _love_ using LQR, optimal control, robust control, etc, but can almost never justify it. As a result, probably 90%+ of control applications by count just use PID. The remaining 10% are of course where most of the research happens, they’re much more fun.
There are more than one set of tuning settings, depending whether optimised for start up, steady state, minimum overshoot etc
was about to comment similar things! PID is relatively straightforward to tune. Also a lot of the time you just need a PI controller. D can be problematic depending on what noise you have.
> we will replace most PIDs with a small neural network for almost all industrial applications
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...
> Of course, no one tunes them by hand anymore
in the industry, maybe. Otherwise, FRC competitions are seeing a LOT of manually tuned PIDs
> Eventually, I suspect we will replace most PIDs with a small neural network for almost all industrial applications
With or without serverless lambda architecture bitcoins ?
Depends on how they address the side fumbling between the Spurving bearing and the Dingle arm, vis-a-vis the lotuso-toroidal damping force.
Only as long as you get the encabulatory turbo gradients correct. But don't use sinusoidial flux inhibitors for that, they suck!
I wanna know more about particle swarm . Btw i tuned my line follower with a customgui/pypidtune+mujoco
https://en.wikipedia.org/wiki/Particle_swarm_optimization
Jesus christ. The wretched control system paper we had for B-Tech computer science!
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!
It's very dated by now, but The Control System Design Guide by George Ellis is a pretty good hands-on book about designing and analyzing control systems. It goes well beyond the basic PID stuff, but I found it very helpful when I was getting a Mechatronics certificate 20+ years go. TBH, it's the most accessible book on the subject that I've ever read.
Terry Davis implements a PID controller for a rocket in SimStructure: https://youtu.be/25hLohVZdME?t=207
A brilliant mind failed by society. Thank you for the link.
[dead]