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
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 0. 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
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":
This sounds like a general rule when taking a continuous controller into discrete time, or doesn't this apply to my case?
Thanks again,
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.
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

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.