D C M O TO R C O N TR O L

Roger Aarenstrup
roger.aarenstrup@mathworks.com

CONTENTS

Introduction.................................................................................................2 The dc motor model....................................................................................3 Speed control with pid.................................................................................5 Continuous control......................................................................................5 Discrete Control..........................................................................................6 Choosing parameters..................................................................................8 Hand Code testing.......................................................................................9 Using Simulink Control Design Products......................................................9 Rapid Prototyping........................................................................................9 Fixed Point................................................................................................10 Production Code Generation.....................................................................10 Position control using state feedback pole placement...............................12 Attempt 1 - state feedback and static gain ..............................................12 Attempt 2 integral action........................................................................12 Attempt 3 Observer................................................................................13 Attempt4 The servo case........................................................................14 Considerations...........................................................................................15 Bandwidth.................................................................................................15 Sample rate...............................................................................................17 References................................................................................................ 19

INTRODUCTION

This example describes how to develop speed and position control systems for a DC motor with a load. Various methods are used and the focus is on how to model and implement the various parts and not of parameter tuning. An important thing to note is that a good controller is not just a text book implementation but requires a number of additional parts to work properly. It is a good idea to go through this text together with the models and some control design literature that gives more details about the theory. Please see the references chapter for some suitable books. This text and models come with absolutely no guarantee if you find anything incorrect please let me know: Roger.aarenstrup@mathworks.com

T H E D C M O TO R M O D E L

The models used here can be downloaded from matlab central with the link; http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?
objectId=11829&objectType=file

The model is a quite simple linear DC motor model with a flexible load. In the library there are MATLAB files describing a state-space representation of the model. How to derive them is described in many control system books and also in the control system toolbox documentation:
http://www.mathworks.com/access/helpdesk/help/toolbox/control/getstart/buil dmo4.html

The model described there doesnt include the flexible load how to add that is described here and in the models included. I have found that a linear model is good enough for many control systems with DC motors. Modeling is not about making the most detailed model but to make a model good enough for the task. There are a few things worth to notice. I have taken the dc motor parameters from the maxon motors product catalog. In the future I hope that it is possible to download models directly from their web page, just like it now is possible to download CAD models over the mechanics. In the catalog there is no specific value for the mechanical damping. Using the common expression for the mechanical time constant, Tm = bm/Jm, where bm is the mechanical damping and Jm is the rotor inertia doesnt give the correct no-load-current. This might be due to nonlinear parts here. I used simulations to estimate a mechanical damping that gives a close match for the mechanical rise time and no-load-current. If you know more about this, please let me know. The figure below presents the DC motor model and load. The load is represented by a double integrator with inertia. Since it is coupled with the motor rotor through a somewhat flexible link there will be a spring action if the positions of the rotor and the load differ. The difference in position (angle) is thus feed back as a counter torque multiplied by the spring constant. The same is true for the damping. The difference in velocities between the two bodies will damp the system. For details, please see the real model.

we

Figure, DC motor model with flexible load.

SPEED CONTROL WITH PID

In this chapter we will use model elaboration to go from a crude model to a discrete implementation of a PID based control system for a DC motor with load.

CONTINUOUS CONTROL

This first attempt to control the dc motor and load uses a continuous time (LaPlace representation) PID with approximate derivative, see figure below. See model a_pid_cont.mdl for the complete model. When tuning the parameters it is important to consider the control signal (output from the controller) to make sure it wont exceed the limits of the amplifier. To meet this for the entire step the controller gain (proportional) has to be quite low, we will see how to improve this further on.

Figure, PID with approximate derivative (from a_pid_cont.mdl).

In some cases it is not desirable to derive the commanded input signal because it might be a step or similar that will give bad results when derived. In the next model b_pid_cont.mdl a variant of the PID controller is used where only the output of the plant is derived.

Figure, PID with approximate derivative of the plant output. Note that the derivative part uses only y, the output from the plant, and not the error. (from b_pid_cont.mdl)

Now, lets add some more details to the model. This is model-baseddesign, MBD, where more and more details are added until the final implementation is reached. And during development the model can be verified continuously by Simulation and later code generation. Lets add a simple model of an amplifier. The amplifier works as a low-pass filter and a saturation of the output signal. Sometimes it is useful to use an amplifier that can output a voltage larger than the nominal voltage for the dc motor, to improve control during short periods of time. Lets also add the tachometer model. The resulting model is c_pid_cont.mdl. It is often a good idea not to have a pure step as input because the step can cause spikes and might excite modes in the system. To make the reference signal more smooth a simple low-pas filter is added. However, it is usually a good idea to calculate a function, as polynomials for example, for the input. The main result from a simulation with this more detailed model is that there are now ripple on the output caused by the tachometer.

DISCRETE CONTROL

To be able to implement the controller on a micro processor we first need to convert it to discrete time in Simulink. There are a number of different way to do that, the one chosen here is taken from [1]. See d_pid.mdl for a model example. Here sample time colors are turned on

showing that the controller part is discrete with a sample time of 100 us. More about choosing sample times later. The sample time is set in a model callback, called when the model is loaded. In the discrete version the derivative part depends only on the plant output, just like the second continuous version. It is also advantageous, in many cases, to let the proportional gain only to depend on a part of the commanded signal. This factor is also introduced in the discrete controller and is called b.

Figure, Discrete PID controller. (From d_pid_disc.mdl) Lets continue with anti-windup for the integrator. There are several ways to add anti-windup for an integrator. The easiest way is to just limit the internal state of the integrator to a reasonable value, this can be done directly in the Discrete-Time Integrator Block. It is also possible to just stop updating the integrator state when the actuator is saturated. Since windup generally is a problem because there is an actuator (amplifier) that has a bounded (non-linear) output, another way is to take the difference between the input to the actuator and subtract that from the output of the actuator and feed that signal back to the integrator path in the controller. This means that if the actuator is saturated the feedback will decrease the integral action. An advantage with this method is that it can be applied to any kind of actuators, not just actuators with limited output.

The last case above is implemented in the next model. The implementation is mainly to demonstrate how to implement anti-windup, since there is not any real windup problem in this model. You can experiment with the input to see if you get windup. The new controller, in the figure below and model file e_pid_cont.mdl, uses a model of the actuator, a saturation block, to get the saturated value. Another way would be to measure the actual value but that would add costs.

Figure, Discrete PID with anti-windup. (See e_pid_disc.mdl) The model with this controller, e_pid.mdl, also samples the reference signal from an external source and isolates the sampled parts that will later be implemented on a micro controller.

CHOOSING PARAMETERS

There are a number of parameters that have to be chosen for the discrete PID controller; K, Ti, Td, Tt, b, N, Umin, Umax and Ts. Parameter tuning and selection is not the purpose of this tutorial but I include some guidelines. For the controller parameters, K, Ti, Td and Ti, there are several methods to choose from, see [1]. Tt, the integrator anti-windup feedback, is related to Ti and can sometimes be equal to it but typically it is 0.1-0.5 Ti [1].

Parameter b, how much of the reference signal to be used for the proportional gain, should be in the interval 0.1 to 1. N is typically 3-20 but can be as high as 100. Umin and Umax, the saturation points for the actuator model in the controller, should be as close to the real actuator as possible. Ts, the sample time, is related to many things. For PID controllers it has to be lower than for PI for example. It is also related to disturbances. In the examples above I use 100 us which is probably faster than necessary.
HAND CODE TESTING

Now if youre not using any advanced tools for code generation and you are using a floating point processor, you can write an equivalent discrete controller in c-code and include it, with an s-function block, in the simulation to verify the implementation. In the model directory there is a c-file with the discrete controller implemented, without anti-windup. You can compile from matlab with: mex sfun_wrp_pid.c handcode_pid.c The file sfun_wrp_pid.c is an s-function wrapper for the controller handling the interface between Simulink and the controller code. Now you can experiment and verify your final implementation so you are sure it works before messing with the real hardware, use model f_pid_disc.mdl. If you have a fixed-point processor you should first model the controller using Simulink Fixed Point then you can do the same thing with it, see later section about fixed-point.
USING SIMULINK CONTROL DESIGN PRODUCTS

There are several tools from the MathWorks that can be used for control design. The most widely used is Control System Toolbox that includes many useful tools. For Simulink there are three products in particular that are the most useful; Simulink Control Design, Simulink Parameter Estimation and Simulink Response optimization. With the response optimization tool for example you can specify a desired time domain response and let Simulink optimize the controller parameters to fit the desired response.
RAPID PROTOTYPING

Models dont always describe the real system perfectly. Before putting effort in the final implementation it is generally a good idea to test it with the real plant. This is done by rapid prototyping where code is automatically generated from Simulink with Real-Time Workshop and downloaded to a target system like the xPC target box. Then you can try the implementation of the controller and tune parameters against the real plant.

Figure, example model that can be compiled for the xPC target for rapidprototyping, g_pid_disc.mdl.

If you on the other hand have the controller implemented on the target processor and want to test it you can compile the plant instead of the controller and run the plant on the xPC target against your processor. In this way you can verify your implementation before you have the plant and without damaging it. This is called Hardware-In-The-Loop.

FIXED POINT

If you are using a fixed-point processor it is now time to convert the floating point model to fixed point using Simulink Fixed-Point. It is out of the scope here to show that.

PRODUCTION CODE GENERATION

The next step would be to produce code that is suitable for production. It can of course be hand coded, like the one we used before in an sfunction but there are a number of big advantages using production code generation with Real-Time Workshop Embedded Coder. It is not just a time saving thing; you also avoid hand coding error that is usually random to the nature. If you have to change your controller later it is a lot easier to just regenerate the code than starting a project to re-write some old hand code. It is also a lot harder to make sure that the final implementation actually matches the simulated version. I Simulink you do bit-accurate simulations. In the next section there is example code produced by Real-Time Workshop Embedded Coder in the Controller_ert_rtw folder.

10

11

P O S I T I O N C O N T R O L U S I N G S TAT E F E E D B A CK P O L E P L A C E M E N T

Now we are going to make a position controller instead of speed controller. In this version we will use a different amplifier that controls the current fed to the dc motor instead of the voltage. The current is measured in the amplifier and with a simple feedback the current is controlled. This provides a great advantage since the torque of the dc motor is directly proportional to the current through the torque constant Kt. The result is that we can neglect the electrical part of the dc motor and thus have one state less in our control design, saving computational time and development effort. In the file ss_dc_motor_load.m there is a reduced state space model for this new application. The file also includes the control design code for the models in this part. The idea is to feed all states back with a vector gain L, by doing so it is possible to use a method to place the closed loop poles on desired locations. Pole placement is very efficient in getting desired performance but might not give optimal solutions for power consumption for example. It is also not suitable for higher order systems. Higher order can be 5-7 and up. In these cases an LQG approach might be a better choice. But for the DC motor with load in this case a pole placement approach works fine.

ATTEMPT 1 - STATE FEEDBACK AND STATIC GAIN

The first approach can be seen in a_ss_controller.mdl, and in the file ss_dc_motor_load.m it is called attempt 1. Here the four closed loop poles are placed on the positive real axis (discrete systems are stable when poles are inside the unit circle) on 0.9875, 0.9863, 0.9850 and 0.9838. For the pole placement algorithm to work well the poles cant be too close to each other. When simulating only this part, without the Kstat constant, gives a reasonable result. However the static gain is quite high, ca 478.4. Usually it is desirable to have a static gain of 1. By just adding the Kstat = 1/478.4 this is corrected. The Kstat can be obtained by simulation or by calculating the closed loop static gain, as in the ss_dc_motor_load.m file. This gives a quite reasonable result and the design is very easy, compared to PID tuning. However, the static gain will be sensitive to model errors and also there is nothing that compensates for disturbances in this first approach.

ATTEMPT 2 INTEGRAL ACTION

As always to get a static gain to be 1 and to reduce sensitivity to disturbances we introduce integral action. This integral part should have an anti-windup mechanism similar to the PID version but that is not handled here, take it as an exercise to add it. By introducing an integrator

12

we introduce one more state in our model, see attempt 2 in ss_dc_motor_load.m. The integrator should be connected to the error of the output we need to control, in this case the position of the load. It is, however, more common that an encoder is attached to the rotor of the DC motor than to the load. Also since the static position of the load and the rotor is equal, it is possible to use the rotor encoder instead of the position of the load for the integral action. Now we have one more pole to place because of the integrator. Where should we put it? It is tempting to make it faster (closer to 0) than the other poles not to interfere with the response time of the system. However, by doing so will increase the sensitivity to disturbances significantly. A better choice is to put it slightly slower than the rest. This will make the system response somewhat slower also but less sensitive to disturbances. This is acceptable for the control case but not for the servo case. In the servo case we will not track the reference signal fast enough. So what should we do? If we keep the feed forward gain Kff we will introduce a zero in the closed loop system. By selecting that zero carefully we can use it to cancel the slower pole introduced by the integrator. By doing the symbolic math it turns out that cancellation happens when Kff = Lint / (pint 1). Where Lint is the feeback for the integrator and pint is the pole placed for the integrator. See ss_dc_motor_load.m file for how this is done. I would also like to remind you that the Simulink Control Design tool that creates a linear model is a very efficient tool to examine any verify designs. Just select inputs and outputs and create the linear model. Then you can watch poles and zeroes, step response, bode plots etc, with the LTI Viewer.

ATTEMPT 3 OBSERVER

In attempt 2 we got a quite nice result, we have control over the movement and we are not very sensitive to disturbances and modeling errors. However, to control we use information about all four states plus the output we are trying to control. This information is easy to obtain in the model for simulation but in a real system that would requite us to measure all the states which generally is not possible or suitable. The solution is to use an observer. The observer takes the input to the amplifier and the output from the encoder and calculates an estimation of the states. Those states can then be used by our controller. Model c_ss_controller.mdl shows how this can be implemented. It turns out that obtaining an observer from the state-space model of the plant is very similar to designing the feedback gain. See attempt 3 in ss_dc_motor_load.m. An input is added for the measured position and then the same pole placement is applied and we get the observer. Please see reference literature for details. To make the observer work well together with the controller its poles should be placed quite a lot closer to 0 or even in the negative real axis. See c_ss_controller.mdl.

13

Note 1! This case illustrates how efficient simulation tools are for designing control systems. We can design the initial controller and verify it by simulation then add details, model elaboration, such as the observer and simulate again to verify. Without simulation tools we need to implement the entire controller with observer without possibility to verify the implementation nor the parameters for it. If we add rapid prototyping to test the algorithm and tune parameters we have probably saved 90% development time. Note 2! The reason why an observer, with both input and output from the real plant, is used instead of just a model over the plant is that with the feedback K, we are more robust to modeling errors.

ATTEMPT4 THE SERVO CASE

This case is just to show an example of how the server control can be implemented. I refer to literature about how to design these controllers, for example [1]. The example model is named d_ss_controller.mdl.

14

C O N S I D E R AT I O N S

BANDWIDTH

Here we will make three different definitions of bandwidth, see [2] for more details. Definition 1: Bandwidth is the frequency area in which control is effective [1 2]. Usually we want the lower frequency to be 0, since we dont want any static error, we can then call 2 = B the bandwidth. The word effective is not clear but here we assume that it means that we gain something by using the controller in this area. If T is the closed loop system, S is the sensitivity function (S=1-T), r is the reference input, y is the output and e is the error, e = y r, we get the following: y=Tr e = y r = (T 1) r = -S r From this we see that T should be as close to 1 as possible. S should be as low as possible, since it tells how much of the error that affects the output. This is very interesting because it gives us two more precise definitions of bandwidth. We start with the one based on y = T r. If we say that control is effective as long as |T(j)|> - 3 dB, the bandwidth will be the frequency where |T(j)| crosses 3 dB from above. |T(j)| is plotted in the figure below.

15

Figure, |T(j)| for the system in model c_ss_controller.mdl. It is position input to encoder output that is plotted. The S and T functions are defined in the ss_dc_motor_load.m file and can be examined with ltiview(S, T). From the figure we can see that the bandwidth, according to the definition above, is somewhere between 50 and 60 rad/s. The bandwidth is directly related to the poles we placed. If you increase the frequency of the poles you will get a higher bandwidth. So with this definition we can specify our bandwidth with the poles we select for the controller. This definition is also good since it is similar to how bandwidth is defined in other application areas such as signal processing. Definition 2: Bandwidth, BT, is the frequency where |T(j)| crosses 3 dB from above. Now lets examine the sensitivity function instead. The error e = -S r. Since we want the error to be as small as possible we want |S(j)| to be as small as possible. If we consider it small when smaller than 3 dB we get another definition of bandwidth. The figure below shows S and from it we can see that the bandwidth would be approximately 25 rad/s.

Figure, |S(j)| for the system in model c_ss_controller.mdl. It is position input to encoder output that is plotted. Definition 3: Bandwidth, BS, is the frequency where |S(j)| crosses 3 dB from below.

16

The later definition seems to be the preferable one. Just considering the amplitude of T is not enough; the phase must also be under consideration. If you plot T with its phase diagram you can see that the phase is almost -180 in the area of the bandwidth. This suggests that control there might not improve the system performance. However, considering the sensitivity function instead, that we want to be small, and if it is small enough we dont have to care about the phase.

In the next figure the magnitude diagrams of S, T and the open loop system are plotted together. As you can see the open loop systems cross over frequency is just in between the bandwidth frequencies for S and T.

Figure, Magnitude diagram of S, T and the open loop system

SAMPLE RATE

So what sample rate should be used? It depends on the system dynamics, disturbances etc. In this case we have a bandwidth from the second definition, from T, of 60 rad/s (about 10 Hz). We also have a frequency of the flexible load of about 3000 rad/s. 3000 rad/s is about 477 Hz. According to some (there are many) rule of thumb you should sample 10-40 times faster than the dynamics and that would mean 4.8 48 kHz. In the models here I have chosen 100 us or 10 kHz as sample rate.

17

18

REFERENCES

[1] strm, Karl, Wittenmark, Bjrn, Computer Controlled Systems, Prentice Hall, 1990. [2] Skogestad, Postlethwaite, Multivariable Feedback Control, Wiley, 1997. [3] Glad, Ljung, Reglerteori, Studentlitteratur, 1997.

19