Putting the 'I' in 'PID'



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.
2*lambda=alpha+K*alpha*Kp
See this recent thread because it applies to you too. How to get PID Padameters for a "lowpass with integrator" process http://groups.google.com/group/sci.engr.control/browse_frm/thread/49ab4f796f72c43a # Wolfgang just went through the same exercise but his 'plant' or motor system is doing position control so his transfer function is has an extra s in the denominator to integrate velocity in to position. Wolfgang can tune his motor now. Wolfgang and I finished up his thread here because the spammers are running the use groups. http://www.eng-tips.com/threadminder.cfm?pid=1438
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Ok, got it now.

I'll give it a read.
Thanks for your help, Rick
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

%First, thanks for citing my webpage in your discussion. %It's true that the PDF structure results in identical closed loop poles for equivalent gains in a PID structure %and that the difference is that the PID introduces closed loop zeros, but the PDF does not. The book "Modern Control Systems" by Dorf provides %an excellent graph of how closed loop zeros affect overshoot with respect to the damped natural frequency. Since the PDF eliminates zeros introduced %by the controller you eliminate any risk that the controller will be the source of overshoot but other system aspects can also lead to overshoot 1) zeros in the %original system itself 2) insufficient damping caused by improperly tuned closed loop dynamics (poles) of the system and 3) nonlinear things like saturation and %not providing mechanisms in the integrator to prevent windup. Dorf can address the first two, but you may have to look to other references for anti-windup controls - it's not too difficult.
% Getting back to your original question regarding the integrator in PID controls. You only need integration only if you are trying to achieve an accurate attitude of your hovercraft at steady state. An unbalanced %structure will require a steady non-zero torque by your thruster logic. This steady value can only be achieved by either knowing what the imbalance is, and adding it to the control or by using the integrator. % The non-zero error (from the difference of level and what the attitude sensor measures) will integrate up until this constant component is met and level attitude is achieved at which time the error is reduced very near %zero. The integrator will continue to correct to trim this error back to zero. But if your gain in the integrator component is too aggressive, the attitude will overshoot as it tries to achieve the equilibrium of level %and the control may hunt. Nonlinearity can result in a steady state oscillation or limit cycle as the integrator dithers the attitude back and forth. Reducing the integrator gain or increasing the P or D gains may %dampen out the oscillation.
%One last comment. Although you picked a very interesting model to learn controls, you also picked a very interesting and challenging problem. The rigid body inertia of the hovercraft with regards to attitude controls is %known as the double integrator problem. A single rotor, as in a helicopter adds some intrinsic damping by its gyroscopic restoring moments, but multiple thrusters don't provide this advantage. I would recommend %using nested loops. I believe your attitude sensor also has gyro (rate outputs). Design yourself an inner rate loop using these gyros, then an outer loop using attitude. the inner loop will give you an adjustment of %damping and greater stability. There's also the question of coupling. If your mechanical system is not decoupled with respect to the roll and pitch axes, angular rates can couple from one axis into another and result %in instability. Alignment and decoupling are important. So I've said enough other than good luck with your controls project.
% Mike Borrello
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sat, 18 Apr 2009 11:32:06 -0700, Rick Armstrong wrote:

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).
--
http://www.wescottdesign.com

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Tim Wescott wrote:

That's because there are no suitable substitutes for thinking. Pease is very amusing on the subject of fuzzy logic.
Cheers
Phil Hobbs
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Jerry, how to you explain the fact that the PI control is clearly 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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
pnachtwey wrote:

We have different systems in mind. (My Phelan book was never returned, and I don't want to derive everything from the beginning. I've been retired for years.) Ignoring the operation of the bounds loops, you can think if Phelan's approach as a final amplifier with proportional feedback only (or a derivative also if the load has significant inertia) driven by an integrator with a short time constant whose input is the error signal. A step command causes a ramp to the final amplifier, not a step that will saturate it. When the load approaches its final position, the proportional feedback exactly matches the integrator's output, so there is no need to discharge the integrator to avoid overshoot.
It takes about the same number of time constants to settle as a standard PID, but the actual time constants are much shorter. If you analyze in time constants, the "advantage" can be negative, but if you plot the response in seconds, the superiority is evident.
Real systems don't stay in the proportional region. The bounding circuits that I describe produce a response that is very nearly "bang-bang".
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 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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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

--
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
Hi Jan,

Makes sense, thanks.
Rick
P.S. What's the "AW:" in the subject line of your reply mean?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

AW = German for Re. AW = Antwort
--
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
JCH wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Apr 24, 12:57pm, 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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
pnachtwey wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Thu, 16 Apr 2009 23:40:17 -0700, Rick Armstrong wrote:

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.
--
http://www.wescottdesign.com

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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)=COi(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)=COi(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=Kc/Ti or I can rearrange this and say Ti=Kc/Ki. If you from above Kc on a temperature controller is the same as proportional gain on a motor controller so Kp=Kc and therefore Ti=Kp/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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

You've already gotten some good advice. I will fill in some holes I saw in the other replies:
1. Buy Tim's book. Sure, you can just keep asking questions here and get the answers one reply at a time, but it's faster to read the book. Be sure to download the errata. (I still need to test Tim's claim that you can print the errata pdf on stickers and paste them right into the book!)
2. Beware any temptation to "help" your controller by directly clamping things that aren't doing "what you want". Usually the misbehavior you are trying to fix is due to a larger design issue (such as instability) and your attempts to solve it by brute force will only make things worse. I learned this the hard way before I learned #1 above.

Think about what happens if you hang a small weight from one corner of your vehicle. The integral term is essentially what "learns" that one rotor needs to driver harder to compensate. Tim: It's too bad we didn't think to make a video of the demo with the doorstop... Did you ever finish the new, improved version?
--
Ben Jackson AD7GD
< snipped-for-privacy@ben.com>
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.