I haven't yet taken the time to watch this, because I like to allocate extra time for Fundamentals Friday and EEVAcademy videos.
However, my own experience is littered with frustrating examples of how to misuse PID controllers.
One particularly bad case was a communications dish controller that was intended to be a minor (5%) part of the software for a larger communications system. It was similar to other pointing systems we had previously made, only larger, heavier and faster. The "quick & dirty" prototype unit worked "well enough" with our existing PID-based controller, needing only an upgrade to the motor drive MOSFETs. The decision was made to evolve the design and build a pair of alpha units.
The alpha units, with a simpler and lighter mechanical design, started to have problems with both backlash and flexing when we started aggressive "full-spec" testing. A mechanical quick-fix would have scaled the unit to unacceptable weight, materials, power and performance costs (stronger mount needed larger motors, more power and so on). So the software team was told to "make it work", and we went down the rat-hole of trying to find the "magical" PID settings to get past our issues.
Based on our "success" with the prototype unit, we thought we were "so close" to a solution that "only a little more effort" would be needed. Based on our assurances, management scheduled an all-up full field demo for our launch customer (and development partner) who was literally on the other side of the world from us. We were so wrong. As the visit neared, we put in more and more time trying to get the dish to track to spec, with next to nothing to show for the effort.
Desperate and frustrated, two days before the demo I decided to throw out and replace all of our work. Well, OK, technically I removed nothing: I added a layer beneath the PID controller, so the PID controller would activate only when the lower-level controller failed. As you may have already guessed, the new controller was a bang-bang controller. And given my many hours with the system, I had by this time developed an internal (definitely non-numeric) model of the system dynamics that permitted me to dial it in very quickly.
I finished testing the code and the system just an hour before it all had to be loaded onto a truck for the demo. No, "finished" is too strong a word: I ran out of tests I could perform in the time remaining.
Remarkably, Murphy was absent that day, and the demo went off impressively well. Far, far better than I had personally expected. The customer was extremely pleased, and asked us to repeat the demo several times under changing conditions. The system just kept on working, all the way up to nearly DOUBLE our baseline performance spec, literally setting a new standard for our industry niche. It was a struggle for us not to show our own amazement.
So many lessons were learned from that fiasco:
First and foremost, we failed to stop at the beginning to re-assess the actual problem, by measuring the system's dynamics and developing a suitable model (starting with attaching lab-grade sensors and subjecting the system to step impulses and linear accelerations at various speeds). The MEs who designed it weren't able to do a full dynamic FEA (Finite Element Analysis), and were able to only assess the system under static loads.
Second, when things go wrong that are visible at the system level, the first thing to do is to hold a full team meeting, maybe even a full design review, before committing to any specific path. For this specific problem, everyone thought the hardware work was done, so the software team was in charge, rather than the electro-mechanical team. By "owning" the problem, we software folks basically prevented the MEs and EEs them from finishing their work.
Third, our "success" with the initial prototype was a total farce. That unit had lower-resolution position encoders and weaker motors than the final system, and it's data (and our processing of it) was simply inadequate to even compare to the actual system needs. But we convinced ourselves it was a huge step in the right direction, and made several important decisions based on that data. We again failed to provide useful feedback to the electro-mechanical team.
Fourth, we simply got lucky, massively and miraculously lucky. Yes, a bang-bang controller was absolutely appropriate, but it was BAD ENGINEERING. My work bypassed all of our engineering processes. Most importantly, my solution had no high-level analysis, it received no design review, and it had no formal test plan. In reality, it was only a tiny step above what you'd wipe off your butt.
Fortunately, I did gain vital understanding of the limits of PID controllers. So, there's that, at least.
If appropriate, after viewing the video I'll provide additional examples here and in the video comments.
Home
Help
Search
Login
Register
