repeated poles

I think you're connecting too many issues, and missing others.

Can you stabilize a system that has three stable, repeated roots? Clearly, the answer is yes, even if you just use proportional control and don't get too ambitious.

If you have two plants, one with a double root and one with a triple root, can you wrap them with PID controllers and get equivalent performance? Probably not. Your second-order system can, in theory, be closed at as high a frequency as you want with a PID controller. In reality, you'll be limited by some dynamics that you haven't modeled, linear or non, or you'll find that it isn't the bandwidth that's limiting you as much as your actuator saturation. In contrast, your third-order system will hit 180 degrees phase margin with just a PID no matter what -- if you stick to a PID controller you'll find that the maximum loop closure frequency will be dictated by the plant, not by you. If you try a double differentiator you'll find all sorts of nonlinearities and unmodeled dynamics jumping out of the woodwork and saying "boo!".

Will three repeated roots "drown out" nonlinearities better than two? Probably not. Poles don't tend to "drown out" nonlinearities so much as they obscure the nonlinear effects, which generally make it more, rather than less, difficult to do a good job of control.

There are many websites that provide free space where you can post your data and then put links here to those files. I have my own FTP site where I put my files.

The resulting closed loop transfer function has 4 poles. My calculations show that if all four poles are placed at -2.25 you will have a critically damped responsed when Ki=25.629 Kp=18.563 and Kd=3.375. If you want to be more aggressive with the tuning then a second derivative will be required or an underdamped response will result. The poles will start to diverge. Two poles will stay on the negative real axis and the other two will become complex. In this case you may as well just use a PI.

I agree with TIm. The 3 pole system requires a second derivative which requires calculating the acceleration from the feedback device or using an accelerometer. The feedback resolution better be very fine ( 1 micron ) if one is to use the position feedback to calculate the actual acceleration. We can use observers to do this. One can also use an output filter too but this complicates the gain calculations. I have posted links to example problems where the second derivative was required. I ignored reality because my Mathcad will compute accelerations using almost perfect 17 digit precision numbers. A reality check would limit my feedback resolution to 1 to

Peter Nachtwey

Gentlemen, thanks for the response. I have some questions:

Peter, you said you posted links to examples where second derivative control was required, where is the link?

What do you mean by a "a very high frequency component"? Why would the quantization cause the output to have a very high frequency component? Why would this "high frequency component" excite the unmodeled nonlinearities.

For the record I know NOTHING about digital control, so if the above statement has to do with implementation issue, I would not be familiar with such issues. I have never looked at a z transform, learned what a zero-order-hold is, nor ever implemented a controller in reality (on a microcontroller). Yes, I know this is a huge shortcoming in my education, but once I am done my theoretical work for my thesis I am going to build a test bed to test out my controls algorithms where I will most definitely have to implement my controller on a microcontroller. I promise I will not become one of those "ivory tower theoreticians" that doesn't know beans about the real world. I am starting to learn more about controls implementation in the real world.

Real digital systems tend to have 'noise' due to quantizing of the feedback. This 'noise' occurs at every sample. The controllers derivative gains tend to amplify this 'noise'. Since the controller sample rates are very high the 'noise' happens at a relatively high freqency that 'excites' unmodeled poles. In reality there are few systems with just two or three poles as in your problem. Hopefully the extra poles and zeros are far enough to the left in the s domain where they can be ignored. Otherwise we would need controller with several gains and feedback devices that can caclulate all the required derivatives. This clearly can not happen so we hope the high frequency poles can be ignored as long as we don't inject high frequency noise into the sytem.

Designing a motion controller is a lot of work. I know. What do you plan to prove? One can learn a lot just using something like Mathcad or Mathematica and not doing the hardware design. What one needs to do is to learn how to use the truncate function to limit Mathcad's 17 digit precision to that of the feeback device you wish to simulate. When I first started using Mathcad I did some simulation that seem to indicate that I could have very high gains. Much higher than what I could achieve on my physical systems. It wasn't until I started reducing the resolution that my simulations started to match reality.

Do a search on the newsgroups for ftp.deltacompsys.com. You will find the threads where I put links to my FTP site. It is best to read the threads to see the context or explainations of what the examples are trying to show.

Here is one link that I posted on a PLC forum where someone was asking if they could control a motor with a 300 pulse per revolution encoder. ftp://ftp.deltacompsys.com/public/PDF/Mathcad%20-%20t1p1%20pid%20mrplc.pdf There are two simulations. One has 40000 counts per revolution and the other 300 counts per revolution. Notice only the trunc function. This is extreme. You can see how the output goes wild in the low resolution example.

Peter Nachtwey

(...)

(...)

When you iluminate red plane with green light, what can you see? Green will be absorbed and you will find that plane is black. Is it true?

While identifying the plant we can't see just the response to the excitation spectrum frequencies. Excite the model with impulse or step or sine. Look at each of the input signals frequency spectrum.

What is easy to achieve in practice that is low frequencie excitation input signal. (signals that have low bandwidth) Thus we know only our model response to this low frequencies and we know nothing about higher frequencies response. This is unmodelled dynamic of our plant. (also nonlinearities are mostly HF part of the real plant) If we are sure there will be no such HF disturbances in our control system then we can feel quite safe. But if we put into a feedback something that amplify or create noise then the unmodeled dynamic will answer to this noise.

Look at the freq. spectrum of quantizied signal. This tiny steps produce many of noise. (analog filters needed in discret control systems)

I'm going to argue terminology with Peter, although not effects.

Real digital systems quantize their feedback (and their drive, and all their internal variables for that matter). This is not, in and of itself, noise. What it _is_, is a nonlinearity, and one that would be very nasty if it were bigger. Quantization effects can be nasty enough.

Quantization is often _modeled_, and well, as a noise that is added to the signal at the point of quantization -- this allows you to turn a nonlinear model of an otherwise linear system into a linear one with an extra noise input. The quantization noise is usually treated as a uniformly-distributed random variable. As long as you're careful about the spectrum that you assign to your quantization noise (it's safe to assume that it's perverse and picks the worst possible frequency) then this is a good way to treat quantization.

Sometimes quantization is better modeled as a teeny little relay stage

-- that is, a stage that only takes on one of two values. This can be a good way to understand why some systems oscillate just a hair when they should be dead stable.

Nitpicking done: Peter's conclusions are entirely correct, only the form of the explanation bunches my shorts.

You'll run across the discussion of quantization noise in just about any text on digital control and many on digital signal processing. This includes my book, which discusses ways to deal with quantization and other nonlinear effects.

Not so much the unmodeled nonlinearities as the unmodeled poles, although you could easily run into saturation (which _is_ a nonlinearity) if your output was whacking back and forth due to sensor quantization.

Consider a chunk of lowly aluminum. Now drive that piece of aluminum with a speaker-coil force motor, and monitor it's position with an LVDT. In theory, the input/output relationship is that of a double integrator. In reality, the speaker coil and it's driving amplifier have a 1st- or 2nd-order low-pass characteristic. Moreover, in reality that innocent-looking chunk of aluminum will have at least one whopping big, way underdamped resonance that'll interfere with your control system. Have you ever tapped a chunk of aluminum with a hammer? They make great bells -- that "riiiinnnnnnnnnngggggg" you hear is the sound that your control system will make if you don't take the resonance into account.

Do it sooner rather than later -- I've learned more theory as a consequence of bumping into practical problems than I ever did sitting in school looking at the pretty math.

Thanks for the responses.

For your little block there, the transfer function is

y/u = 1/s^2

which as you pointed out a double integrator. If it is truly "a block" (such as a 10" by 10" cube) the natural vibration frequency will be so high, I would think the controller would not excite the natural frequency to a point where we care. On the other hand if the block of aluminum was not really a block, but rather a slender rod with a big end (think of a car intake valve but with a bigger valve, and the input is applied at the small end), then the big end of the rod has some inertia so as our voice coil motor moves the rod back and forth there may be induced vibration in the rod. In this case, if we stayed with our 1/s^2 transfer function and did not model the axial vibration of the rod, I could totally see a simple controller exciting the natural frequency of the system and getting "a ring". Note I am not disputing your claim or exmaple, I am more clarifying how probable it would be to get "a ring", where all a ring is, is the unmodeled vibrations creeping into the system in an unwanted fashion.

I like the explanation of how quantization is a nonlinearity, and when modeled as a noise the derivative gains could amplify said noise. I am familiar with this phenomena in the sense it is good to have a rate (velocity) controller with high frequency rolloff (on the magnitude portion of the bode diagram) so that the noise (which is usually at a much higher frequency than any mechanical vibration) will be mitigated, rather than amplified. That is why most controllers (or all "advanced" controllers such as H2, H infinity) have a strictly proper form such as

H(s) = (s + c)/((s+a)(s+b))

The above controller has a high frequency rolloff of -20 dB/decade, which will suppress any high frequency noise due to sensing/ quantization.

Although the math is pretty, it is only half the story. The other half is in the real world. In my Aerospace grad program my controllers have to be implemented, rather then just simulated before I can graduate.

James Forbes

No problem, that is why I wrote 'noise' instead of noise. What term do you want to use?

I don't understand the uniformly distributed statement. I simulate quantizing non-linearities by truncating the feedback positions to the resolution of the scale. This is how an encoder would behave. The noise sprectrum is dependent on the counts/sec and the samples/sec. There are speeds at which one can get a low beat frequency. This would happen when the counts/sec is almost equal to the sample frequency. If I get 4.5 counts per update then one scan I will get 4 counts and the next I will get 5 and then 4 again. The noise frequency is half the sample rate. If I get 9.9 counts per scan I will get 9 then 10, 10 ,10, 10,10 ,10,10,10,10 counts per scan before repeating the cycle. Now the 'noise' frequency is 1/10 th the sample rate. One can see there is a relationship between the sample rate and the counts/sec. I don't see how I can call this uniformly distributed or Gaussian or anything. Perhaps some out there has a term for this.

This beat frequency due to quantizing non-linearities has bothered me for a long time. People use Kalman filters to estimate better positions, velocities and accelerations but the measurement noise is not Gaussian. I think most people just ignore this.

I know I called the quantizing non-linearity effects 'noise'. Quantizing 'noise' just seems to flow much better than quantizing non- linearity effects. I notice you used the term too.

Peter Nachtwey

I try to use 'quantization noise'; if I have time or I'm not sure of the audience I point out it's not 'real' noise, i.e. it's not a random process.

Uniformly distributed because if you take an ADC reading then the actual value being applied to the ADC is anywhere within +/- one LSB. Hence, a uniform probability density makes a pretty good model.

Are you distinguishing between the frequency spectrum and the probability distribution?

This is part of what gets me excruciatingly pedantic, sometimes.

A Kalman filter is the best linear filter to use to minimize mean-squared error assuming you know tons about the system; given that the tools are there to generate them easily a Kalman filter is often a good compromise between an estimator that's good enough and a design cycle that's short enough.

One should keep it in mind, however, that a Kalman filter is only optimal if you know the plant characteristics exactly, and the noise is Gaussian, and your cost function is mean-squared or weighted mean squared. If these conditions don't hold then you shouldn't necessarily run screaming from the Kalman filter, but you shouldn't necessarily adopt it without reservation, either.

Not only is the changing beat frequency from quantization an issue, but if you are aiming for a plant that doesn't move, you can find your system oscillating around one or more quantization steps somewhere in your system. This is why, when I analyze a system's response to quantization noise, I don't assume that it's white -- I pick the worst-case frequency, and assume it's all concentrated there. This isn't just due to pessimism

-- often you will find that the noise _is_ concentrated there, either because the system finds the frequency, or because the nature of the sampling process generates an alias.

Yea, it was a bad example. More likely, it's a block that's hollow, with something interesting, expensive, and precise inside (else why would we want to position it with a speaker-coil actuator?). In a good design effort there would have been a mechanical engineer, or a team of them, that sweated bullets to get the resonant frequency up, but most likely the resonant frequency would still be there and would be a big barrier to getting the performance that we want.

That's not the only reason -- often you'll find that a plant's phase uncertainty increases faster with frequency than it's amplitude response drops. To make the system close at a moderate frequency without getting high-frequency instability problems you need to be careful about your differentiator roll-off; sometimes (but not often) you have to put a high-frequency low-pass in there just for stability.

So you need the roll-off for two reasons.

Good. You've got sensible people setting your curriculum.

Here is something to occupy your time. I have control solutions to the system you provided. Two of the solutions require the second derivative. This shows the advantages of the second derivative and the some of the extra effort it takes to implement it. ftp://ftp.deltacompsys.com/public/NG/Mathcad%20-%20t0p3.pdf

Yes this should be un-modeled poles. Notice the example example with the second derivative gain without the output filter. Do you think the frequency of the control output is high enough? That would excite the un-modeled poles like Mikolaj suggested.

Study this. Ask questions.

Do it in software first.

The real knowledge is in industry anyway. What the professors teach is just to get you started.

Peter Nachtwey