Effect of discretization on feedback controllers

Hi all,

I'm doing research in mobile robotics, and I have very little knowledge of control theory. However, I am currently trying to use feedback controllers to guide the robot along a given trajectory. The trajectory defines the position, velocity and accelerations in the coordinate space x,y over time, and the robot expects translational and rotational velocity commands.

I have tried different feedback controller designs, and they worked really well:

formatting link
17 in 8 is one controller, eqs. 21/22 are two others

These controllers seem to have nice theoretical properties, like exponential convergence and Lyanpunov stability. But what happens if such feedback controllers are executed in discretized time steps? Are there stability properties or error bounds that apply in this case? Are there general answers to this questions, or are they different for each stability property, or even for each controller?

Thanks for any answers, references or other help

Boris

Reply to
Boris Lau
Loading thread data ...

Lots of things. A discrete-time controller is a different animal than a continuous-time one, because you're sampling the input and because you're introducing delay both as part of the sampling process and because of any processing that you do. In general, if you sample fast enough then the difference between a discrete-time controller and a continuous-time one will be smaller than the other differences between theory and practice in your system, and can be ignored. This effect may or may not occur after you have spent more money than you can afford on computing hardware.

Just as with a continuous-time controller, yes.

They'll be different for each property and controller -- and they'll change depending on your sampling rate as well. This is why I generally prefer to characterize my system in the continuous-time domain then do my design in the discrete-time domain. Many experienced people are uncomfortable with this approach however, so you'll see a lot of designs that start with a continuous-time controller then approximate it in discrete time.

Reply to
Tim Wescott

There are two things that happen.

  1. As mentioned above, the sample intervals can have a big affect on the response.
  2. The feed back is not linear. Digital sampling turns a linear ramp into little stair steps. The finer the feedback resolution the closer the feedback will represent a linear ramp.

I agree that every system is different but there are general procedures that will allow you to tune a system and determine if it is stable. Tuning the s-domain is easy because it is easy to calculate the gains symbolically. In the digital domain the gains are affected by the sample interval. Assume all the closed loop poles are going to be at -10 in the s domain. One can calculate the location in the z domain, exp(-10*T). The digital controller gains will approach those calculated for the analog controller as the sample interval approaches

  1. The digital controller gains will be less than the analog controller as the sample interval increases. One can verify this by writing a program to tune a controller by placing the closed loop poles at a specific location in the z domain. Use Ackermann's method to do this. If the pole locations are kept constant but the sample interval is varied you will see what I mean.

=46rom this you would think the idea is to minimize the sample interval but there are problems with that too. As the sample time approaches

0, the ability to calculate accurate derivatives goes down UNLESS the resolution is also made finer by a proportional amount. The control output will change in quantized jumps proportional to the ratio of feed back resolution to the sample interval if only a derivative gain is used. If a second derivative is used the control output will change in quantized steps proportional the the resolution/T^2.

There is hope, we can design an observer to estimate and smooth the state feedback and remove most of the stair step quantizing. Since we are assuming we have the plant model from system identification, we can use this model to design the observer.

Peter Nachtwey

Reply to
pnachtwey

yes, but is there a bound on the error, or any other thing I can say?

I see. Well, this seems to be the case here, since the controller works alright and I'd like to keep on using it.

By the way, I've found this in another thread:

Sam wrote regarding "Re: Digital implementation of a control design": > If your controllers bandwidth is much greater than the relative > bandwidth of the system you are controlling then your continuous time > design will do fine. Another way of saying this is if your sampling > frequency is high enough (meaning much faster than the fastest > dynamics of your process--more than 10 times) then you will come very > close to the desired continuous time design. Also, remember that eigC > = exp(eigC*Ts) > Where eigC is the continuous time eigenvalues of your system (the one > you designed) and Ts is the Sampling Interval (1/Fs or 1/sampling > frequency).

This sounds like a general rule when taking a continuous controller into discrete time, or doesn't this apply to my case?

Thanks again,

Boris

Reply to
Boris Lau

It requires that the sample rate be much higher than might otherwise be needed. If that doesn't increase the cost or the response time of the necessary filters out of bounds, then it applies.

Jerry

Reply to
Jerry Avins

There are some fairly good hand-waving arguments that you can use if you want to do approximations. Mostly, you can take the delay effect of the zero-order-hold on the output DAC and check to see if it's phase shift is going to cause grief to your loop -- if not, you're probably in business.

It's this hand-waving that makes me prefer to design directly in the digital domain, but to each their own...

It's general, yes, and I use it all the time. From a practical perspective it's a good starting point, but for _really_ precise control you want to exceed the 10x factor, perhaps even bumping it up to 100x if you can. You can do better than this rule of thumb by evaluating the system as a continuous-time one with a one-half or one sample pure delay in it, and see if you're going to get decent performance.

From a theoretical standpoint it's all still hand-waving to some extent

-- what's the fastest dynamic in your process, after all? Just about any real process has an effectively infinite number of dynamics, so the real quote should be "the fastest important dynamic". Once you insert that qualifier in there, you're back to hand-waving.

Reply to
Tim Wescott

I want to learing from it.

formatting link

Reply to
www.ningbo-electric.com

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.