Putting the 'I' in 'PID'

Hello All,
I have a question about the implementation of PID control. First, some context: I'm building a (hopefully) self-leveling quad-rotor rc helicopter,
with the intent of learning a bit about control systems while building something for entertainment's sake. I'm starting off by implementing a PID control on a PC tethered to the craft, which sits in a fixture in my basement that allows single-axis rotational movement. The tilt sensor is one of these: http://www.microstrain.com/3dm-gx1.aspx I've implemented the 'P' term and the 'D' term and after some trial-and-error, it's now somewhat stable, settling to level after a disturbance.
Now, I've decided to add the 'I' term, and realize now that there's something that I don't understand: does the integrator sum the error for _all_ time (i.e. as long as the controller has been running), or just for the "recent past"?
If it's for all time, then I don't see how the accumulated error ever gets 'zeroed-out' without overshoot.
If the sum is produced from recent past history, then how does one pick the length of the interval?
I'm just getting started here, so please speak slowly as though you were explaining this to a donkey.
Any advice is greatly appreciated,
Rick Armstrong, Portland, OR, USA
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Normally the integrator accumulates for all time but there are exceptions. Sometimes it is desirable to set the accumulator to 0 or any value. Sometimes you may want to keep the integrator from winding up when in saturation.

A normal PID will overshoot to unwind integrator excess if the system is a type 1 system (integrating). There is no need to overshoot on a type 0 system. ( non integrating). However with a few tweaks even type 1 systems don't need to overshoot.

A lead lag filter is like that. The integrator 'forgets' so is really no longer an integrator. What you are looking for is the time constant. Some PIDs express the integrator term as a time constant.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi Peter,

I'm not familiar with these system classifications (i.e. 'type 0, type 1'). Could you point me to a book that'll straighten me out? Also, when we say 'type 0 system', are we talking about the controller, or the controlled system?

I'm assuming that my little quad copter can be approximated as a second-order intertia-only system, with no damping, and no equilibrium point (if I balance it carefully). Does the idea of 'time constant' still apply?
Thanks,
Rick
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rick Armstrong wrote:

Hee haw, hee hee, haw haw haw hee.
Oh wait -- you meant that donkey part metaphorically, didn't you?
The integrator sums the error term for all time; in it's simplest forms a PID will overshoot to zero out accumulated error. There are various ways to prevent the overshoot in some circumstances, but it's difficult (if not impossible) to eliminate the overshoot for _all_ circumstances.
For something like that, I suspect that you can allow a long, small 'tail' of overshoot in the tilt response and still get satisfactory control out of it. As long as your overshoot is less than any disturbances that you'll get from external forces you really aren't going to care much that it's there.
I suspect also that you'll find that the dynamics change dramatically when you untether it -- as soon as you do that your lateral acceleration will mix with your tilt, which at the least will confuse things mightily. Putting a 2- or 3-axis gyro in there may make a world of difference to the ease of control.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi Tim,

Ok, that helps clear it up, but what if Hee haw + hee hee = hee awww heee awww? :)

That clears something up for me: I had sort of pictured the overshoot being an 'equal and opposite' motion, which would just be an oscillator.

Indeed, I'm assuming that once I try to fly the thing, it's possible that it'll try to crash itself into pieces. I'm not worried though; that's why I have duct tape and a soldering iron.

Actually, my sensor _does_ have a 3-axis gyro output, and one of my next tasks is to figure out how to make good use of it.
Thanks, Rick
P.S. I've got a copy of your book and am enjoying it. At some point, I plan to try out the frequency response measurement techniques you describe.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rick Armstrong wrote:

If you want to be experimental, there are several avenues you can explore. At one time or another, I've used all with success. They are not mutually exclusive.
If the actual error and the integrator have opposite signs and the actual error exceeds some small threshold, zero out the integrator.
If the output of the controller is about to saturate, modify the integrator value to bring it out of saturation.
See http://users.rcn.com/jyavins/servo.html
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I don't recommend this. Once you get to the point where you know how to tune the system it will cause more harm than good because you a have made the system non-linear.

This is much better. It is the trick I use. If the system is already in saturation and then there is USUALLY, no harm. However, if the integrator term is set back and the integrator time constant is too low then the integrator will take a long time to recover to the proper value once the system recovers.

This link has been posted a few times before and I still have issues with the claims made on this web page.
This is a another and I think better link link on the same topic http://www.stablesimulations.com/technotes/pdf.html
My link shows that Phelan's PDF controller is just a PI controller without a zero. I call this a I-P controller because the P term is subtracted from the control signal. The zero in the PI controller does two things. It increases the band width and will cause the system to over shoot in many cases depending on where the closed loop zero is relative to the closed loop poles. The PDF or I-P controller does not have a zero so its bandwidth is lower and therefore its response is slower, not faster as claimed in Jerry's link.
However, the I-P or PDF controller is a good option for Rick if over shoot can't be tolerated. Rick, if you want a simple explanation as to why the PDF or I-P will not over shoot then ask.
Jerry, if you want a simple example as to why the PDF is not faster than the PI then ask but you should know better. I can make, probably already have, a .pdf file on this topic. If you haven't noticed, most of my .pdf files that I have posted links to use a I-PD or I-PD2. Our motion control product supports PID and I-PD because sometime the I-PD is a better option than the PID when following arbitrary motion profiles like a position reference from a joystick.
There are too many PDFs in the last paragraph. PDF controllers and .pdf files.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Jerry said:

Peter said:

One thing I'm finding out by actually building the thing is that I've _already_ got non-linearities to deal with, right out-of-the-gate. I'm not too worried about another :)
Seriously though: "empty the accumulator at the zero-crossing" sounds like something that will probably work. I'll try it out and post my results.

That's a great explanation (I've run across that document during my initial googling when starting the project).

For my purposes, overshoot is ok as long as my craft doesn't crash and burn. For now, my goal is 'stable hover with some human assistance'. I _think_ my most important performance parameter is disturbance rejection (i.e. breezes and turbulence from prop wash).

Yes, please. It's not obvious to me from the text.

Indeed! PDF was an unlucky choice of acronyms for Phelan's control scheme.
Thanks,
Rick
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

See this link ftp://ftp.deltacompsys.com/public/NG/Mathcad%20-%20t0p1%20pi%20std.pdf
It is a simple example of how to control a type 0 ( non-integrating ) single pole system. My short hand for this is T0P1. In this example I compare PI and I-P control of the T0P1 system. I start by calculating the gains symbolically. I have shown how to do that using wxMaxima on other threads. Next I compute the matrices for the simulation and then I simulate PI control then I-P control and finally PI control using an incremental PI. If you look closely at the I-P example you can see that the proportional gain is subtracted from the control output so that even if the integrator windups up the total output does not cause the system to overshoot.
You can also see the incremental PI does not over shoot. In this case the changes in the proportional term are integrated along with the integrator term. As the error decreases the changes in the proportional term are negative and therefore subtract from the total integration of the control output terms.
BTW, just because the error goes to 0 doesn't mean the integrator isn't working on a type 0, non integrating, system. The integrator term is still none zero
Rick, this is the easy stuff. You need to understand your system before you can control it. That is the hard part. Do a google search for helicopters on this group. There have been others that have been interested in helicopter control. Gabe Spradlin comes to mind. He has his own site at www.controltheorypro.com
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, 19 Apr 2009 12:00:37 -0700 (PDT), pnachtwey

Thanks, I'll have a look.

Yeah, I realize that, but one of my initial goals* with this project is to see how far I can get towards a working flying 'copter _without_ working from a sophisticated aerodynamic model. Once I've done that, I'll circle back and see if I can improve on what I've done using a detailed model of the craft. Or I'll get bored and move on to another project, having got my feet wet in applied control theory (damp, maybe?).
Thanks,
Rick
* Alongside "have fun" and "impress my friends" :)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

MODELLING AND IDENTIFICATION OF A LABORATORY HELICOPTER
Use experiences of others, e.g.: See page 4
* http://msc.fe.uni-lj.si/Papers%5CMathmod06_Karer.pdf
* 3.4. The whole system - Simulink model and think about * 4. Measurements and identification of the parameters
--
Regards/Gre Jan C. Hoffmann
Microsoft-kompatibel/optimiert
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Thanks Jan, I'll have a look.
Rick
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rick,
I am doing exactly the same as you: building an autonomous quadrotor both as entertainment and to explore control theory. I'm ahead of you, perhaps, in that I have a graduate aeronautical engineering degree (with controls emphasis), but far behind you in that I don't have any hardware yet. Some thoughts:
* Quadrotors are a pretty active topic among both hobbyists and researchers. I can send you plenty of links to discussion groups, hobbyist sites, technical papers, and even grad and ugrad theses. I plan to use scicos/scilab to do the design (which you have via Tim's book). Of course you can always use MATLAB/SIMULINK if you (or your company) has access.
* I'm not aware of any quad that uses accelerometers/inclinometers only - for reasons that Tim explained. Also, if you want to be able to fly it yourself (or even if you just want a computer to fly it autonomously) the vehicle will need angular rate damping, which is directly sensed by the gyro. For orientation, you could integrate the gyro (yours is expensive enough that drift may not be an issue over the flight time of the vehicle). Most folks use sensor fusion algorithms to get the best out of several dissimilar sensors. Complementary filters are probably the easiest to understand, but look up "Kalman filters" when you're ready for a challenge. Here's something I just posted on comp filters on a quad discussion group:
http://www.rcgroups.com/forums/showpost.php?p 082524&postcount86
* Do not zero the integrator in your PID! That would be disastrous in your application. Having said that, you do need to implement some form of "anti-windup", as others have suggested, presuming you even need the I term.
* I have bemoaned (on this group, as a matter of fact :-) the dearth of good controls texts that would take the reader from almost zero knowledge to being able to understand enough theory to design something practical. I may just write one myself - but you wouldn't want to wait for me to do it, at the rate I'm going. The reason is the theory is based on a lot of intermeshed math from several different areas - linear algebra, complex analysis, differential equations, probability, etc (I'd say "beautiful" mathematics, but it may be heresy for an engineer to say so :-), so it becomes complicated to learn and teach. Its even hard to know where to start. As a result, the discipline often tends to be more Art than Science (as perhaps you can glean from the posts in this thread). I do not mean any of this as a criticism of anyone on this thread - especially Tim whose book is both very good on its own merits and occupies an important practical niche that most other books do not cover. (my hat's off to anyone who can actually accomplish something worthwhile, unlike people like me who only seem to be able to spout off on things in usenet posts :-). Another reference along the same lines as Tim's is
//books.google.com/books?id=kFbJFTWXDwcCpg=PP1dq=Control+System+Design +Guide,+Third+Edition:+Using+Your+Computer+to+Understand+and+Diagnose +Feedback+Controllers
Good luck! I will keep you posted on my (slow) progress if you do the same. Roy
p.s. Tim, I'm glad you said that re: fuzzy logic. In my years of formal controls education (in the late 80's early 90's), it never came up, not once. I was wondering if I was missing something, or if it was just overblown. On the other hand, if it works for folks like Rick who may not want to spend the time creating a model of his plant, then I'm all for it. After all, isn't PID just another "model-free" control law design technique?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi Roy

Ah, _that_ Roy :) I've been watching that thread for a while. Looks like you folks are moving along nicely!
I've constructed my quad based on the Old Man Mike recipe. Between OMM and Rusty's frame kit, I figure they've saved me many dozens of hours, and allowed me to get right to the part I'm interested in. The only reason I didn't start this project a long time ago was that I didn't want to spend the time and money figuring out which RC parts would work. When I stumbled on the OMM thread, I decided to pull the trigger. I admire those folks for bothering to post their experiences, to the benefit to others.

I'm going to tempt the wrath of the gods and try it. I'll let you know how it goes.

Thanks. I keep meaning to blog my progress, but when it comes to a choice between "working on the project" and "talking about working on the project", the former always wins (my free time is very limited).

I'm in the process of learning how to do this the Right Way; meanwhile I'm curious how far I can get through intuition and trial-and-error. That's the luxury of engineering on my own dime instead of a customer's.

I have a sneaking suspicion that real-world control problems are often solved like this:
1) Model the system to be controlled, assuming that the thing is LTI. 2) Find out that model is nearly useless in the actual physical world because nothing real is LTI. 3) Implement a controller and tweak parameters until it works. 4) Profit.
Rick
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi Rick

Yeah those guys are great. I feel bad that I am not able to contribute more (like you, my free time is limited). But I do plan on doing a very thorough write-up of my quadrotor eventually, and perhaps even start a blog/website (maybe after I am finished, or at least further along).

By all means, experiment. You shouldn't necessarily take anyone's word for anything (especially on folks on usenet :-). Here's my thoughts on what will happen: Either 1) you won't need very much integral control, and it won't matter. I must admit I have not tried to model the vehicle yet. It may be type 1 or higher. I think the guys on the rcgroups use small or non-exisitent I-terms. Or 2) You do need a significant amount of the integral term. At some point, the intergrator will just dump all its trim, and you as the R/C pilot and your controller will have to deal with it - perhaps very quickly to avoid a crash. Then, the integral may build up and it might happen all over again. This might happen once in your vehicle's lifetime, or it may happen many times a minute. That's the down side I see. I don't think I see any positives of this scheme, for our purposes. But, I could be wrong :-)

I fear you are correct. :-) On the other hand, if it works...

- Roy
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rick,
(a follow-on to keep the length of each post a little shorter)
A simple anti-windup scheme is just to limit the output of the integrator to a constant that less than the full range of your controller output. This way, when the error does change sign, the integrator will come out of saturation at its usual time constant. Of course, this approach has downsides as well, but it is simple to implement.Tim mentions this approach in his book, and similar but slightly more complicated approach. I have not determined which scheme I will use yet (presuming I need an integral at all). I do intend to emply some feedforward control - a direct path from the command to the controller output, bypassing the error (well, it may not be "direct"; it will probably have some kind of dynamic shaping). This way the vehicle won't need to build up error before a command is generated. Hopefully this will help to keep the integrator term less active.
- Roy
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Roy wrote:

Or it may happen once within a minute, and cause the end of the vehicle's lifetime...
-- snip --
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rick Armstrong wrote:

-- snip --

When you're doing it 'right', at some point early in the modeling process you check to see whether an LTI assumption will be valid and over what sorts of operating ranges. Then you decide whether you can blithely treat the system as linear, if you can decorate the controller with a few easy nonlinearities (like anti-windup in the integrator) and _otherwise_ treat the system as linear, or if you _really_ have to delve into the nonlinear control bag-o-tricks to make things work.
Sometimes (often, when you're dealing with an unfamiliar system or really trying to wring performance out of it) you have to do some design, remeasure, redesign cycles before you get it right*. This can take the form of tweaking if you're close to your goal, but too much undirected tweaking can lead you off into the pucker brush of control design land, where the only path to success lies in getting airlifted back to your starting place and redoing the process _correctly_.
My day job often involves coming in at the point where people realize that they're off in the pucker brush and don't _know_ how to do the design right. Often I can't get their system whipped entirely into shape, because often the problem is that the plant or processor is somehow deficient to the task at hand**, but I have _always_ been able to get significantly improved performance.
* It's like peeling an onion -- you peel off a layer of the problem and cry as you do it. Then you notice that the problem is still too big, so you peel off another layer and cry. You repeat as necessary until you have enough money saved up to start a basket-weaving supply house, or until the problem is solved, whichever comes first.
** This is another benefit of good system modeling -- if you can identify all of the issues that need to be dealt with, sometimes you'll find that you just won't get to your goal without changes to more than just the control algorithm. With proper up-front modeling you can discover this while there's still time for a mechanical design cycle.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

That's a funny (and apt) description of some of my tasks at my day job!
Rick
P.S. Thanks for the insights.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi Peter,

I'm having an algebra brain fart: on page one, I'm looking at the part where K_i ad K_p are each shown as functions of the plant params and the desired characteristic equation. I'm assuming that we set DiffCE 0 to do start out. Then setting s = 0 gets K_i = (lambda)^2 / K*alpha. How do we get K_p?
Thanks,
Rick
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Site Timeline

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.