DC Motor Control

Roger Aarenstrup
roger.aarenstrup@mathworks.com

CONTENTS

Contents ........................................................................................................................ I
Introduction.................................................................................................................II
1

The dc motor model..............................................................................................1

Speed control with pid..........................................................................................3

2.1

Continuous control .........................................................................................................3

2.2

Discrete Control..............................................................................................................4

2.3

Choosing parameters .....................................................................................................6

2.4

Hand Code testing ..........................................................................................................7

2.5

Using Simulink Control Design Products.....................................................................7

2.6

Rapid Prototyping ..........................................................................................................7

2.7

Fixed Point ......................................................................................................................8

2.8

Production Code Generation.........................................................................................8

Position control using state feedback pole placement .......................................9

3.1

Attempt 1 - state feedback and static gain ...................................................................9

3.2

Attempt 2 integral action ............................................................................................9

3.3

Attempt 3 Observer...................................................................................................10

3.4

Attempt4 The servo case...........................................................................................10

Model-based design Project...............................................................................12

4.1

The inputs......................................................................................................................12

4.2

Trajectory generation ..................................................................................................12

4.3

The feedback controller ...............................................................................................13

4.4

Components and architecture .....................................................................................14

4.5

Rapid prototyping ........................................................................................................14

4.6

Fixed-Point implementation ........................................................................................15

Considerations ....................................................................................................16
5.1

Bandwidth .....................................................................................................................16

5.2

Sample rate ...................................................................................................................18

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

II

THE DC MOTOR MODEL

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 non-linear 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.

figure1.

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.
2.1

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.

figure2.

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.

figure3.

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-based-design, 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.
2.2

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.
4

figure4.

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.

figure5.

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.
2.3

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.

2.4

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 antiwindup. 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.
2.5

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.
2.6

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 RealTime 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.

figure6.

example model that can be compiled for the xPC target for rapid-prototyping,
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-TheLoop.
2.7

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.
2.8

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 s-function 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.

3
POSITION CONTROL USING STATE
FEEDBACK POLE PLACEMENT
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.
3.1

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.
3.2

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 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, 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.
3.3

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.
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.
3.4

ATTEMPT4 THE SERVO CASE

This case is just to show an example of how the server control can be implemented.
This model will also be used as in input in the project described in the next section. The
10

example model is named d_ss_controller.mdl. The difference in this model is that all
states are used as inputs, not just the desired position. Since the acceleration is fed
forward we just control the small error we get from this and thus gets a far more efficient
controller. The trade off here is that we now need to calculate trajectories for the
position velocity and acceleration for the entire movement. Especially if a move can be
interrupted with another request, this can be quite complicated.

11

MODEL-BASED DESIGN PROJECT

In this section we are going to take the servo model above and use it in an entire
development workflow using model based design. Two development groups are involved
in this research and software groups. The research group develops the control algorithms
and then hands over requirements to the software group who will do the final
implementation.
One important concern here is the interface between the groups. How do they
communicate requirements and knowledge about the system? How far down the
development should researchers go? This has to be adapted to the local situation. In this
case the research group hands over models when they work in simulation, then the
software group tests it with rapid prototyping and makes final parameter tuning. Then
the software group develops the final c-code.

Complete
Integration & Test

Define
Requirements

System-Level
Integration & Test

System-Level
Specification

Subsystem
Design

Subsystem
Integration & Test

Subsystem
Implementation
figure7.

4.1

V-design model. The green line marks roughly the interface between the research group
and the software developer.

THE INPUTS

The research group provides the model (from attempt 4 above) and a MATLAB
algorithm for trajectory generation. In a real project they would probably also provide
some written requirements (In a document or a requirements management system) and
in the best cases also a test system for functional tests. The inputs can be found
in \3_mbd_project\a_inputs.

4.2

TRAJECTORY GENERATION

The first challenge for the software group is to take the MATLAB algorithm for
trajectory generation and implement it in a Simulink model. An embedded MATLAB
function block is of course
12

The trajectory generator or algorithm takes the current position, s0, the new desired
position, s2, the current velocity, v0, and the maximum allowed acceleration, a, and
outputs the time t1, t2 and the acceleration with the correct sign for the initial move. A
movement with maximum acceleration has two different phases, acceleration and
deceleration. If the movement starts at time 0, t1 marks when the acceleration should
change sign and the deceleration phase should start. The second output, t2, is the time
when the movement is complete. In the figure below an example of a complete
movement is presented. From the times t1 and t2, constant acceleration and the fact that
velocity is the integral of the acceleration and the position is the integral of the velocity it
is straight forward to calculate the trajectories.
Calculating t1 and t2 is a little bit tricky since there are several solutions to the
equations; do the math as an exercise.

figure8.

A typical trajectory where blue is the acceleration, green the velocity and red the
position.

Model a_traj_gen.mdl shows the implementation of the algorithm in Simulink. The

function is triggered since it only needs to be executed when a new desired position is
entered. When this model is tested it is time to add another function that will output the
actual trajectory. B_traj_gen.mdl shows the implementation. Please note how time is
handled. There is an integrator that is reset when the algorithm is triggered to set time to
zero. The output now is the desired acceleration, used for feed forward, velocity and
position.
4.3

THE FEEDBACK CONTROLLER

The next step is to add the controller to the trajectory generator model. This is
shown in model a_controller.mdl. Please not how from/goto blocks are used to avoid
intersections between signals. From/gotos should be tightly placed so it is possible to
follow the signal flow.
Now the input model in the a_inputs folder is reused again and instead of the
controller there a model reference block is inserted. This block references to the
controller model above, a_controller.mdl, and makes it possible to simulate them
together. The new model with the reference block is b_system.mdl.
13

What we have now is a closed loop system model that can be used for functional
tests. The controller is the part that will be implemented in the final software and can
now be viewed as a software specification.
4.4

COMPONENTS AND ARCHITECTURE

To be able to manage the implementation the controller is split into two

components, the controller and the trajectory generator. The result from this is that the
main controller model becomes a software architecture model and in it, two separate
models are used also with model reference. The models are located
in \3_mbd_project\d_achitecture\...
The two models, traj_gen.mdl and controller.mdl, we call components since they
are a well defined part of the software system. Split into component they can harbor their
own requirements, test system and be implemented independently (in parallel).
Components are also suitable to be handled in a configuration management system.
To each component there is an m-file with parameters related to that component.
This m-file is the start of a data dictionary for the component, describing the data
interface to the same.
Some subsystems can be included in a Simulink library and made available for many
models. These are called utilities since they are not components that are specific parts of
a system. Utilities can be a pid controller for example that can be reused by many and
tested thoroughly once and re-used. So components are implemented in models and
utilities in libraries.
4.5

RAPID PROTOTYPING

If not before this is a good time to test the controller against the real plant using
rapid prototyping (if available). In the folder d_architecture there is another model called
controller_rp, that uses model reference to reference the same models as the full system
does but instead of having a plant model it includes drivers for xPC target. This model
can be compiled and used for rapid prototyping on xPC target hardware.
Sometimes the configuration settings have to be different for simulation and for
code generation. In the models here thee are thus two configuration sets included. It is
possible to change configuration sets from model explorer for each model but take it as
an exercise to make a script that do changes all of them, perhaps from clicking on a
block in the top model.
Now, for rapid prototyping the rapid prototyping configuration (xpc_configuration)
set must be set for models:
Controller_rp.mdl
Traj_gen.mdl
Ss_controller.mdl

14

4.6

FIXED-POINT IMPLEMENTATION

From section 4.5 we now know that this controller actually works against the real
plant. This is good of course. However, we have only tested the algorithm by itself and a
good rapid prototyping result doesnt mean that we will actually be able to implement it
on our target micro controller reaching real-time performance.
This means that we now need to prepare the model for code generation with some
optimizations. The first step is to convert the model data types from double to integrer
fixed-point.

The fixed-point implementation can be tested by simulation and by rapid

prototyping.

doubles (verify by simulation and rp above)

Convert to fixed point (verify by simulation + rapid prototyping)
Prepare for code gen
Two data dictionaries, one for doubles and one for fix
Optimizations?
Component tests, coverage

15

CONSIDERATIONS
5.1

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.

figure9.

|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).
16

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.

figure10.

|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.
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.
17

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.

figure11.

Magnitude diagram of S, T and the open loop system

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.
5.2

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.

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