Module 6: Discrete-time Control Systems

Module 6: Discrete-time Control Systems

This article is contained in Scilab Control Engineering Basics study module, which is used as course material for International Undergraduate Program in Electrical-Mechanical Manufacturing Engineering, Department of Mechanical Engineering, Kasetsart University.

Module Key Study Points

  • Learn the basics of a digital control system
  • Understand sampling process and aliasing problem
  • Learn how to convert from continuous-time to discrete-time system
  • Show how to use discrete-time transfer function block in an Xcos diagram

As we all know, most controllers nowadays are implemented digitally. So the continuous-time feedback diagram in needs to be changed to a hybrid form in Figure 1. Now we have two domains separated by the vertical dotted line; i.e., the controller side is discrete, and the plant side is continuous. To connect them together, we need additional components to convert the signals from one form to another. The block labeled DAC (Digital-to-Analog Converter) and ADC (Analog-to-Digital Converter) are commonly-used to serve this purpose. Most modern microcontrollers have built-in ADC units, but those with internal DAC’s are rare. Nevertheless, it is not difficult to find an external DAC chip with easy interface.



Figure 1 A digital control system

Note that Figure 1 shows a basic configuration. Some systems may differ slightly. For instance, motion control applications usually get feedback from motor encoders, which are digital in nature. In such case the ADC is not required. For some motor amplifier that receives a PWM (Pulse-Width-Modulation) input, the PWM unit then replaces the DAC. Nevertheless, the essence remains. The controller is digital. It is described either by difference equations, or by a Z- transfer function. Before we get into that, an important issue must be addressed.

Sampling Analog Signal

While a real world signal is continuous, a computer works with values stored in a bank of memory. At one moment in time, a value to be processed is addressed by a data pointer. So, as shown in Figure 2, the continuous signal x(t) has to be sampled into a sequence x[k], where integer k is the index, or the relative address of data to be selected by the pointer. The signal x(t) is sampled at fixed time interval \Delta, called the sampling period. (In some areas of engineering such as communication systems, multi-rate sampling may exist, but for digital control applications there is no use for such complicated schemes.)



Figure 2 Sampling a continuous signal

A question follows naturally. How often should we sample the signal x(t)? Common sense tells us the more frequent, the better, since it is obvious from Figure 6 if the samples x[k] are close together, they should represent x(t) very well. That is valid. But, well, we tend to forget one thing. The more frequent the sampling, the more data we have to keep. In a modern desktop PC this does not sound like a problem. But for embedded control applications, resources are expensive. The memory allocated for data process may be limited.

Let us investigate what happens if the sampling rate is too low. Figure 3 shows such a scenario. The original signal we want to sample is x(t). Undersampling causes the reconstructed signal x'(t) much different from the original. This problem is called aliasing. Another good example of aliasing is when we watch a movie, sometimes we notice a moving car with its wheels turn in the opposite direction. The film is an image sampling system. That happens when the frame rate is too slow relative to the angular velocity of the wheel.



Figure 3 Aliasing problem

So, how could we select a proper sampling frequency? Intuitively, we can guess from Figure 3 that if we sample at least twice the frequency of the red sine wave, things should work fine. That is in fact an established result, known as the Nyquist-Shannon Sampling Theorem. One could find the details elsewhere. Here we state only the essence, in plain English: the sampling rate must be at least twice the system bandwidth.

This sampling theorem only gives us a lower bound. Practically we would want a higher sampling rate, say, 10 times the system bandwidth. Of course, tradeoffs between sampling rate and amount of data memory need to be considered. Also, if a controller is working in real-time, it has to fetch a data point, do some processing, and output something. We have to make sure the whole algorithm could finish within the sampling time interval.

Figure 4 shows a basic structure for a real-time control algorithm. Notice that it has to be implemented as a timer interrupt service routine to achieve a fixed, precise sampling period.



Figure 4 A real-time control algorithm

Discrete System Representation

A continuous-time dynamical system can be represented in the time domain by a differential equation. We can use Laplace transform to find a representation in the frequency domain, called a transfer function. Similar mechanisms exist for discrete-time. A discrete-time dynamical system can be represented in time domain by a difference equation. The math tool to convert it to a transfer function is called Z-transform.

Figure 5 shows 3 basic elements of a discrete system: summer, multiplier, and delay. The first two operators behave the same as in continuous time. The third one is unique to discrete world, but nothing is complicated about it. Output from the D block is simply the input delayed by one sample. In Figure 5, let’s say the input to D is e[2], then the output of D equals e[1]. When we convert the system using Z-tranform, what comes out is a rational function of a complex variable z. Without going into the theory, the point to remember is the unit delay D transforms to z^-1 in the Z-domain.



Figure 5 Discrete system representation in time and frequency domain

As often the case, the control design is done in continuous-time domain. After the design process finishes, the S-domain transfer function (or continuous-time state space description) is converted to a discrete transfer function in Z-domain. Of course, you can discretize the continuous-time plant model as well, which may be particularly useful in case you want to simulate the plant in an embedded processor. In either case, Scilab command for this purpose is dscr.
Ex 1: From module 2 we have the plant transfer function for robot joint driven by DC motor

(1)   \begin{equation*}  P(s) = \frac{1}{10s^2 + 0.1s} \end{equation*}

and the lead-lag controller

(2)   \begin{equation*}  C(s) = 20000\frac{(s+0.01)}{(s+100)}   \end{equation*}

Construct these transfer functions in Scilab

-->s=poly(0,'s');
-->P=syslin('c',1/(10*s^2+0.1*s));  // plant
-->C=syslin('c',20000*(s+0.01)/(s+100));  // controller

Since dscr accepts data in state-space format, the transfer functions must be converted to state-space descriptions first

-->Pss = tf2ss(P);
-->Css = tf2ss(C);

Then discretize with sampling period T = 0.01 second

-->Pdss = dscr(Pss,0.01);
-->Cdss = dscr(Css, 0.01);

and convert back to transfer functions

-->Pd = ss2tf(Pdss)
Pd  =
    0.0000050 + 0.0000050z   
    ----------------------   
                         2   
     0.9999 - 1.9999z + z  
-->Cd = ss2tf(Cdss)
 Cd  = 
  - 19998.736 + 20000z   
    ------------------   
    - 0.3678794 + z

Note to MATLAB user: Obviously, the dscr command in Scilab is not quite convenient to use compared to c2d in MATLAB. First, it does not accept data directly in transfer function form. Second, c2d allows you to select discretization method such as ZOH, FOH, TUSTIN, etc. dscr, on the other hand, simply uses ZOH method. In case you want the TUSTIN method, there is another Scilab command cls2dls, which uses the same syntax as dscr. See Scilab help for more detail.

Closed-loop Stability

It is explained in a standard textbook in digital control systems that, generally speaking, the stability region of a discrete transfer function is inside a unit circle. So we can use this fact to determine whether closed-loop transfer function in Z-domain is stable or not. From the above plant and controller data already in Scilab workspace, we form the discrete-time complementary sensitivity transfer function

-->Ld = Cd*Pd; 
-->Td = Ld/(1+Ld)
Td  =
     0.0999933 + 0.0999967z     
    ------------------------    
                             2  
    0.4678592 - 1.267846z + z

and plot poles and zeros of Td

--> Td = syslin('d',Td)
-->plzr(Td)

that yields the plot in Figure 6. The poles and zeros are indicated by x and o, respectively.



Figure 6 discrete pole-zero map from plzr command

From Figure 6, since all poles are in unit circle, we conclude that the closed-loop system is stable.

If you want numerical values of the poles and zeros of a transfer function, Scilab has a command trzeros to compute zeros

-->trzeros(Td)
 ans  = 
  - 0.9999667

I still cannot find a specific command to compute poles from a transfer function. Anyway, with data already in transfer function form, all we need to do is to compute the roots of denominator polynomial of Td

-->roots(Td.den)
 ans  =
    0.633923 + 0.2569064i  
    0.633923 - 0.2569064i

Discrete-time or Hybrid Simulation

Discrete-time simulation, or an interconnection of discrete and continuous-time systems, can be performed in Xcos by using palettes in Discrete Time Systems group. For example, suppose we want to keep the robot joint DC motor plant as a continuous-time transfer function, and use a discrete-time controller Cd.

The Xcos model in Figure 7 shows how easy to create such a model. The only new player in this diagram is the DLR block from Discrete time system palette. The usage of this block is quite like its continuous-time counterpart, only that it requires a red-arrow signal from the system clock. The period of the clock must match the sampling time used for descritizing the controller, in this case, 0.01 second. Simply put the numerator and denominator data of Cd as block parameter.



Figure 7 hybridsim.zcos Xcos model for hybrid simulation

Running simulation yields the step reponse in Figure 8.



Figure 8 step response from hybrid simulation

Supplement