Putting the 'I' in 'PID'

I blush. Not out of false modesty, but because I neglected to plug the damn thing. Here, I'll correct that:

I'm not sure you still can -- thanks for reminding me. I #1 son hard at work reformatting all of the articles on my website; I can add this to his to-do list.

(it's interesting to watch him work. He ran my whole Master's thesis through OCR, then tidied it up -- including entering all the equations into an equation editor. He didn't have the vaguest notion of what the stuff _meant_, but you can give him an integral or an infinite sum and he knows how to tell OpenOffice how to typeset it. He's going to hit calculus one of these days and finally realize what all those pothooks and squiggles mean -- I wonder if it'll help, hinder, or not make a difference).

I've learned this the hard way several times by now, and it hurt every time (I'm slow). I think the time between lessons increases exponentially, but there's an unfortunate early termination to the experiment somewhere between 60 and 100 years, so I'll never know for sure.

No, I got seduced by paying work. It's still an ongoing project, though, for all that it's simmering gently on the back burner.

(For those of you who are wondering, Ben attended a class that I gave for Oregon Institute of Technology aimed at teaching control theory to embedded software engineers. Ben decided that the class needed a lab exercise, so he generously built a propeller on a stick that could be used to learn many ramifications of controlling real things in the real world. I've been developing it further, into something that can be produced economically in modest volumes, but more immediate profits have intervened for now.)

Hi Ben,

Already have it and am studying it.

Ah, but no teacher can predict what knowledge gaps a student will have! I get the feeling from reading Tim's book that it's aimed at someone who has at least a minimal clue already. For example, the answer to my original question was one that is _not_ in the book, and the answer is probably pretty obvious to someone who's implemented a PID controller _once_. My experience is that I can stare at the equations ad infinitum, but until I bang my knuckles on something, I just won't know what I'm looking at.

Hmm. You're making me think that "add a little deadband to work around tilt sensor noise" is a _bad_ thing :0

That's actually one of the tests I had planned once I've successfully implemented the 'I' part.

Thanks,

Rick

...

I'll correct the correction:

...

Jerry

Thank you, Jerry.

I don't think so.

You don't need to I have done all the work in the pdf file ftp://ftp.deltacompsys.com/public/NG/Mathcad%20-%20t0p1%20pi%20std.pdf

That is what is shown on page 4/9

You can see the control signal and the integrator term ramp up as you say.

That is what is shown. The integrator winds up to about 40volt of output but the proportional terms subtracts from the integrator term. In this case the control output will not be zero because it is a non- integrating system.

Now you are pulling a JCH on me. I can reduce the time constants of a PID too.

I have done that in the pdf but I used the same gains for both the PI and I-P. I can move the closed loop poles farther to the left to increase the gains. Eventually both the PI and I-P will be limited by the feed back resolution and any non-linearities due to quantizing. The PI and I-P will react to this in a similar way.

Look at my example. I made step jumps in the velocity set point and the control output does go into saturation. The PI comes out of saturation OK but then it overshoots the set point whereas the I-P handles this situation nicely as claimed.

All things being equal the PI will respond faster than the I-P. Look at the Bode plot. It is clear the PI has a higher bandwidth and less phase lag at higher frequencies. They will both react to disturbances the same way.

Peter Nachtwey

"Rick Armstrong" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

MODELLING AND IDENTIFICATION OF A LABORATORY HELICOPTER

Use experiences of others, e.g.: See page 4

• formatting link
• 3.4. The whole system - Simulink model and think about
• 4. Measurements and identification of the parameters

Thanks Jan, I'll have a look.

Rick

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:

• 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

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?

That's because there are no suitable substitutes for thinking. Pease is very amusing on the subject of fuzzy logic.

Cheers

Phil Hobbs

The linear settling behaviour of a loop is generally dominated by the lowest-frequency pole or zero. Adding a very small amount of I to a P loop makes it settle slower, but more accurately. Dialling up the I term makes matters better until it starts reducing the phase margin.

Cheers,

Phil Hobbs

That is because you are thinking in terms of changing the gains one at at time. I prefer to think about moving the poles to get the desired response and then calculate the controller gains from the desired closed loop pole locations. If you follow this approach then the zero (s) caused by the PID will add phase lead that offset the phase lag caused by the integrator term.

Peter Nachtwey

I was actually thinking about the P/I crossover zero moving up in frequency as the I gain is increased, starting with a properly-designed P loop.

Cheers

Phil Hobbs

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 =

Thanks,

Rick

Yes

Setting s to 0 has nothing to do with it. The two characteristic equations must be equal for all values of s, therefore the coefficients for each power of s must be the same.

See this recent thread because it applies to you too. How to get PID Padameters for a "lowpass with integrator" process

Hi 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:

Rick

Ok, got it now.

I'll give it a read.

Thanks for your help, Rick

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

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

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

-- snip --