Putting the 'I' in 'PID'

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

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.

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

Jerry

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

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

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

The 'I' term is generally worsening the close loop behavior. 'I' has only one task: Get the control error e to zero.

If e is zero then 'I' (Integration) does not work any more.

'I' works always in a way to correcting the control error e. Then yI = Integration e dt = 0 for e=0

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

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.

Hi Jerry,

Yes, in fact, one of my goals with this goofy project is to get a feel for a few different control schemes in a real system.

Makes sense.

I'm an occasional lurker over at comp.dsp and your article made me curious about I-PD control, and was one of the reasons I started building this thing. I've got a copy of Phelan's book, and I intend to try implementing I-PD next.

I considered "Fuzzy Control" but one of my friends shamed me out of it by saying "dude, that's *so* *eighties*!!!" ;)

Thanks,

Rick

Hi Jan,

Makes sense, thanks.

Rick

P.S. What's the "AW:" in the subject line of your reply mean?

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

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

AW = German for Re. AW = Antwort

Fuzzy control provides a good structured way to develop a controller when you just can't describe the plant or controller mathematically. It has a very small chance of doing a better job than a 'real' control design if you do have a good mathematical description of the plant and can develop a good mathematical description of the controller.

For what you're doing you should be able to capture the behavior of your system mathematically. Ergo, it's not a good candidate for fuzzy control.

(I don't have a lot of respect for a lot of fuzzy control practitioners. It has been used with success in difficult control problems, and my hat's off to those guys. But it was conceived as, and is used by too many as a way around doing the hard work of actually wrapping your brain around the problem. It's _fine_ to use if it's not humanly possible to wrap your brain around the problem, but as far as I can see it's just not a suitable substitute for thinking).

When you get it working will you come out to one of my model flying club meetings in the Redland/Beavercreek area and demonstrate it? Several of our members would love the "gee whiz" factor, and one of our helicopter pilots produces his own line of electronic accessories for heli flyers -- he'd be all over it (once he elbows me out of the way).

What's the street price for that tilt sensor? I've been looking at doing something like this myself (for a working scale model of an X-22A), but more with model airplane quality (and priced) sensors rather than UAV.

Heck yeah! It might be a while yet; I travel a _lot_ for work, so I'm only able to work on it in fits and starts. My goal is to have it flying (i.e. hovering without crashing) this summer, before the weather turns back to normal for NW Oregon. My email is 'rick at radiantflux dot com'.

It's in the neigborhood of $1k. We had a stack of them sitting idle at work, and my employers have been very generous in letting me borrow one.

Rick

I have a question about the integrator and how long it sums the error. In PLCs there are usually PID blocks which are used for control. The P, I, and D each have settings. The I settings are "gain" and "time". If the integrator is supposed to sum forever, what is the "time" setting actually doing?

Andy

In a motor control system the integrator is expressed as a gain. On most PLCs the integrator is expressed as a time constant which is just give you some idea how long it will take for the integrator to wind up to a new value for type 0, non-integrating systems, like velocity and temperature control systems. It takes 5 integrator time constants to wind up or down to be within %1 of the new value. On a motor control PID the integrator term is expressed as COi(n)=3DCOi(n-1)+Ki*T*(SP(n)-PV(n)) Where: COi is the integrator contribution to the control output Ki is the integrator gain T is the sample time SP is the set point or target PV is the process value or actual

Temperature and PLC people express the same thing just a little differently COi(n)=3DCOi(n-1)+Kc*(T/Ti)*(SP(n)-PV(n)) Where: Kc is the controller gain which is the same as the proportional gain,Kp, on a motor PID. Ti is the integrator time constant. This has units of time. In PLC it is minutes.

The two equations are almost identical but you can see that Ki on the motor PID does the same as Kc/Ti on the temperature PID. Therefore Ki=3DKc/Ti or I can rearrange this and say Ti=3DKc/Ki. If you from above Kc on a temperature controller is the same as proportional gain on a motor controller so Kp=3DKc and therefore Ti=3DKp/Ki or the ratio between the two gains.

If you want to make the system respond quickly to changes you want to make Ti as small as possible but usually you will not be able to get the integrator time constant too much lower than the system time constant.

The reason why the motor control and the PLC people have different ways of expressing the same thing is because motor system have time constants in a few milliseconds and temperature control systems have time constants expressed in minutes. In many cases the PLC PID can't express time constants small enough for motor applications.

Peter Nachtwey

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

Peter Nachtwey

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" :)

faster than the I-P control when using the same gains. There is something wrong with your claims.

(1) Critical damping with faster settling time than PID can achieve with overshoot.

Look at the pdf file I posted on another response. I don't see how your claim can be justified.

(2) No integrator windup. No matter what overload conditions occur, the system never needs to "recover control".

I agree with this.

(3) Not only is there no steady-state error, OK

the control system can be made immune to steady-state departure from the ideal response to a ramp by adding a higher-order derivative.

I think I know what you are trying to say here but it isn't clear. Explain. I think you are suggesting a different type of feed forward where the SP is run though a lead filter. This exaggerates the motion of the SP and compensates for the lag introduced by the I-P low pass filter effect. It is kind of like leading the donkey around with a carrot while riding on a cart pulled by the donkey but exaggerating the angles so the donkey ends up walking where you want him to.

(4) The response to load variations is better than PID. I don't see it. Why is it better? Mathematically I just can't see it. An PI or I-P functions exactly the same once at the set point and there are no errors. The zero introduced by the PI only affects control when the SP moves.

The advantages that I see to the I-P is that it does work better when the SP changes in undefined ways. For instance steps, by a joy stick, or is noisy. I-P control is used in the inner loop of a cascaded loop. Often the outer loop generates a noisy reference for the inner loop that causes the inner loop's D term be erratic when in the forward path. Using a I-PD in this case allows one to crank up the gains because the noise is now filtered by the I-PDs low pass filter effect. One can get by without a motion profile generator. The closed loop system responds like a two or three pole low pass filter. If one gets tricky the velocity can be limited by limiting the error the integrator term sees.

Peter Nachtwey