8th Vienna International Conference on Mathematical Modelling

8th Vienna18International
February Conference
- 20, 2015. Vienna on Mathematical
University Modelling
of Technology, Vienna,
8th Vienna18International
February Conference
- 20, 2015. Vienna on Mathematical
University Modelling
of Technology, Vienna,
Austria
February 18 - 20, 2015. Vienna Available
University of online at
Technology, www.sciencedirect.com
Vienna,
Austria
Austria

ScienceDirect
IFAC-PapersOnLine 48-1 (2015) 067–072
Co-Simulation
Co-Simulation of of Matlab
Matlab and
and FlightGear
FlightGear
Co-Simulation
for Identificationof Matlab
and and FlightGear
Control of Aircraft
for
for Identification
Identification and
and Control
Control of
of Aircraft
Aircraft
∗ ∗ ∗
Guilherme Aschauer ∗ Alexander Schirrer ∗ Martin Kozek ∗
Guilherme Aschauer ∗∗ Alexander Schirrer ∗∗ Martin Kozek ∗∗
Guilherme Aschauer Alexander Schirrer Martin Kozek
∗
∗ Inst. of Mechanics & Mechatronics, Vienna University of Technology,
Inst. of Mechanics & Mechatronics, Vienna University of Technology,
∗
∗ Inst. of Mechanics & Mechatronics, Austria Vienna University of Technology,
Austria
e-mail: guilherme.aschauer@tuwien.ac.at
Austria
e-mail: guilherme.aschauer@tuwien.ac.at
e-mail: guilherme.aschauer@tuwien.ac.at
Abstract: The paper outlines the development of a co-simulation solution of Matlab and Flight-
Abstract: The paper outlines the development of a co-simulation solution of Matlab and Flight-
Gear in which
Abstract: Thethe the
papercommunication between these
outlines the development of aprograms
co-simulation is done via UDP
solution without
of Matlab andneeding
Flight-
Gear in which communication between these programs is done via UDP without needing
further
Gear toolsets. Thecommunication
simulation and between renderingthese is done by FlightGear. Flight measurement signals
further toolsets. The simulation and rendering is done by FlightGear. Flight measurementneeding
in which the programs is done via UDP without signals
are senttoolsets.
further to Matlab, The which in turn
simulation andsends back actuator
rendering is done byinput values computed
FlightGear. Flight by a flight control
measurement signals
are sent to Matlab, which in turn sends back actuator input values computed by a flight control
system.
are First,
sent First,
to Matlab,gray-boxwhich models
in turn of the aircraft dynamics are identified for different altitudes for
system. gray-box models of sends back actuator
the aircraft dynamics input
are values
identified computed by a flight
for different control
altitudes for
longitudinal
system. and
First,and lateral
gray-box dynamics so that gain-scheduled controllers can be used. The output
longitudinal lateral models
dynamics of the aircraft
so that dynamics arecontrollers
gain-scheduled identified can for different
be used. altitudes
The output for
quantities to be controlled
longitudinal are altitude and heading and three state-space controllers (MPC,
quantities toand lateral dynamics
be controlled so that
are altitude and gain-scheduled
heading and controllers
three state-space can be controllers
used. The (MPC,output
LQR and a gain-scheduled
quantities LQR) are designed and compared by tracking twocontrollers
reference signals
LQR and atogain-scheduled
be controlled LQR) are altitude and heading
are designed and three
and compared by state-space
tracking two reference (MPC, signals
including
LQR and steps
a and ramps. LQR)
gain-scheduled At theare enddesigned
the robustness
and of the controllers
compared by tracking aretwoverified by flying
reference in
signals
including steps and ramps. At the end the robustness of the controllers are verified by flying in
turbulent
including stepsweather conditions.
andconditions.
ramps. At the end the robustness of the controllers are verified by flying in
turbulent weather
turbulent
© 2015, IFAC weather conditions.
(International Federation of Automatic Control) Hosting by Elsevier Ltd. All rights reserved.
Keywords: Aerospace computer control, Automated guided vehicles, Co-Simulation, Parameter
Keywords: Aerospace computer control, Automated guided vehicles, Co-Simulation, Parameter
estimation, LQR control
Keywords: method, LQG control method, Predictive control
estimation,Aerospace
LQR control computer
method, control, Automated
LQG control guided
method, vehicles,control
Predictive Co-Simulation, Parameter
estimation, LQR control method, LQG control method, Predictive control
1. INTRODUCTION sufficiently well and still the results have to be taken with
1. INTRODUCTION sufficiently well and still the results have to be taken with
1. INTRODUCTION caution. well and still the results have to be taken with
sufficiently
caution.
Considerable progress has been made in the past few years caution. This study will show how it is possible to run FlightGear
Considerable progress has 1 been made in the past few years2 This study will show how it is possible to run FlightGear
in affordable (X-Plane
Considerable progress has 1 ) or freely
been madeavailable
in the (FlightGear
past few years 2) or X-Plane in co-simulation with Matlab
in affordable (X-Plane
realistic flight(X-Plane
) or
simulation software.
1
1
freely available
Both programs
(FlightGear 2
2
)
promise) This study will
or X-Plane show how it is
in co-simulation possible
with Matlab to using the UDP
run FlightGear
using the UDP
in affordable
realistic flight simulation) software.
or freely available
Both programs promise communication
(FlightGear or protocol. Thiswith approach
communication protocol. This approach allows to run UDP
X-Plane in co-simulation Matlab allows
using to the
run both
both
a large
realistic degree
flight of realism
simulation and
software. are even
Both used
programs in training
promise programs
communication on different
protocol. platforms
This as
approach long as
allows they
to runare in
both
a large degree of realism and are even used in training programs on different platforms as long as they are in
cockpits
a large for pilots.
degree of FlightGear
realism and offers
are even theused
choicein between
training
cockpits for pilots. FlightGear offers the choice between the the
same local
programs
same on
local
network.platforms
different
network.
In order toasobtain
In order to long
obtain
high
as
high
flexibility,
they are in
flexibility,
several well-established
cockpits for pilots. FlightGear flight dynamics
offers the models
choice (FDM)
between on Simulink and especially the Aerospace Toolbox have not
several well-established flight dynamics models (FDM) on the same local network. In order to
Simulink and especially the Aerospace Toolbox have not obtain high flexibility,
the basis of mostly nonlinear equations of motion
(FDM)like on been used since the latterthe one is so far only working
several
the basis
JSBSim
well-established
of mostly nonlinear
(Berndt (2004))
flight dynamics
or the
equations
usage
models
of
of motion
a user-defined
like Simulink
been usedand since especially
the latter oneAerospace Toolbox
is so far only workinghavewith
not
with
the basis of mostly nonlinear equations of motion like FlightGear
been used
JSBSim (Berndt (2004)) or the usage of a user-defined FlightGear and is not a standard package of Matlab. and
since is
the not a
latter standard
one is so package
far only of Matlab.
working withIf
model. This
JSBSim is helpful
(Berndt (2004))where or the highly
usagespecialized aircraft Matlab
of a user-defined If
model. This is helpful where highly specialized aircraft FlightGear is notand available,
is not the
a main functionality
standard package ofofMatlab.
the script If
like
model. lighter-than-air
This is helpful aircraft
whereare used,specialized
highly or a custom Matlab is not available, the main functionality
set can easily be implemented in C++ or any other high-level
aircraft of the script
like lighter-than-air aircraft are used, or a custom set Matlab is not available, the main functionality
can easily be implemented in C++ or any other high-level of the script
of
likeequations is available,
lighter-than-air aircraft andarewhere
used,FlightGear
or a custom is just
set programming language. in C++ or any other high-level
of equations is available, and where FlightGear is just can easily be implemented
programming language.
used
of for
equationsvisualization
is purposes
available, and and
where for providing
FlightGear realistic
is just programming language.
used for visualization purposes and for providing realistic The flight simulator sends flight attitude data and receives
environmental
used for conditions.
visualization purposesThe drawback
and for of this approach
providing realistic
environmental conditions. The drawback of this approach The flight simulator sends flight attitude data and receives
actuator input values (throttle,
is that the userconditions.
environmental has to provide
is that the user has to provide
all the coefficients
The drawback used in The
of this approach
all the coefficients used in actuator flightinput
simulator
valuessends flight elevator,
(throttle, elevator,
aileron,
attitude data andand
aileron,
rud-
receives
and rud-
der). After establishing a working connection between the
the
is FDM,
thethat
FDM,
including
theincluding a parametrization
user has atoparametrization
provide all the over over different
coefficients
different in der). After establishing a working connection betweenrud-
flight
used
flight
actuator input values (throttle, elevator, aileron, and the
parameters to increase the degree of realism. two programs,
der). After identification
establishing a runs are
working made for between
connection longitudinalthe
the FDM, including a parametrization
parameters to increase the degree of realism. over different flight two programs, identification runs are made for longitudinal
parameters to increase the degree of realism. and
two lateral motion
programs, independent
identification runs ofareeach
madeother
for for different
longitudinal
A completely different approach is taken by X-Plane where and lateral motion independent of each other for different
A completely different approach is taken by X-Plane where altitudes and lateral
altitudes
with a chirp
motion
with a chirp
signal overlaid
independent
signal overlaidof eachwithother
low-pass filtered
for different
with low-pass filtered
instead
A of
completely an FDM
different the blade-element-theory
approach is taken by is
X-Plane applied.
where white
altitudesnoise as
with input
a chirp data to
signal guarantee
overlaid sufficient
with low-pass excitation
filtered
instead of an FDM the blade-element-theory is applied. white noise as input data to guarantee sufficient excitation
Here, the
instead of geometry
an FDM of the
the aircraft has to beis modeled
blade-element-theory applied. in thenoise
relevant frequency areas. Withsufficient
this input/output
Here, the geometry of the aircraft has to be modeled white as input data to guarantee excitation
in detail the because theof forces and moments directly in thea relevant
are modeled frequency areas. With this input/output
Here,
in detail geometry
because the aircraft
the forces and momentshas to be are directly data in
data
model estimation
thea relevant frequencyprocess
model estimation areas. can
process Withbe
can
performed,
bethis input/output
performed,
using
using
calculated
in detail on its
because elements
the forces (e. g.
and wings).
moments Thisare offers the
directly a black-box model or, preferably, a gray-box model since
calculated on its elements (e. g. wings). This offers the data a modelmodel
a black-box estimation process can
or, preferably, be performed,
a gray-box model using
since
possibility
calculated to
on investigate
its elements the approximate
(e. g. wings). flying
This behavior
offers the the
a equations
black-box of
model motion
or, for standard
preferably, a aircraft
gray-box dynamics
model are
since
possibility to investigate the approximate flying behavior the equations of motion for standard aircraft dynamics are
of a newly developed
possibility to investigate aircraft
the without having
approximate to build
flying and available (e. g. Brockhaus (2001)). These models are the
behavior
of a newly developed aircraft without having to build and the equations
available (e. of
g. motion
Brockhaus for standard
(2001)). aircraft
These dynamics
models are are
the
testa newly
of a prototype.
developed Obtaining a mathematical
aircraft without having tomodel build andcan starting point for the control design process. In this work,
test a prototype. Obtaining a mathematical model can available (e. g. Brockhaus (2001)). These
starting point for the control design process. In this work, models are the
also
test be easier withObtaining
a prototype. this approach since one doesmodel
a mathematical not need three different
can starting point for reference tracking
the control designcontrollers
process. (heading
In this work,and
also be easier with this approach since one does not need three different reference tracking controllers (heading and
specific knowledge
also be easier with of of the
thisthe implemented/modeled
approach since one does not physical
need altitude)
three have reference
different been used: a model
tracking predictive
controllers controller
(heading and
specific knowledge implemented/modeled physical altitude) have been used: a model predictive controller
processesknowledge
specific but can rely of on
thethe computations of X-Plane
implemented/modeled and (MPC), an LQR controller, and a scheduled LQR con-
physical
processes but can rely on the computations of X-Plane and altitude) have been used: a model predictive controller
try to obtain a black- or thegray-box model from input andand (MPC),The an LQR controller, and a scheduled LQR con-
processes
try to obtain but can rely on
a black- computations
or gray-box model from input and troller.
of X-Plane (MPC),
troller. The an LQRmodelscontroller,
and controllers
models and controllers and a are then validated
scheduled
are LQR con-
then validated
by
by
output
try to data.
obtain Of
a course,
black- or the geometry
gray-box model has to
from be modeled
input and flying
troller. through
The turbulent
models and weather
controllers conditions
are then with reference
validated by
output data. Of course, the geometry has to be modeled flying through turbulent weather conditions with reference
output data. Of course, the geometry has to be modeled test flyingsignals
through including
turbulent steps and ramps.
weather conditionsThe with
airplane used
reference
test signals including steps and ramps. The airplane used
throughout
test this papersteps
signals including is a Concorde
ramps. which is theoreti-
1 www.x-plane.com throughout this paper is aand Concorde The airplane
which used
is theoreti-
1 www.x-plane.com cally capable
throughout of
this flying
paper at
is supersonic
a Concorde speed.
which However,
is the
theoreti-
2 www.flightgear.org
1
1
2 www.flightgear.org
cally capable of flying at supersonic speed. However, the
www.x-plane.com cally capable of flying at supersonic speed. However, the
2
2 www.flightgear.org
Copyright
2405-8963 © © 2015,
2015, IFAC (International Federation of Automatic Control)67 Hosting by Elsevier Ltd. All rights reserved.
Copyright © 2015,IFAC
IFAC 67
Peer review©under
Copyright 2015,responsibility
IFAC of International Federation of Automatic
67 Control.
10.1016/j.ifacol.2015.05.071
MATHMOD 2015
68
February 18 - 20, 2015. Vienna, AustriaGuilherme Aschauer et al. / IFAC-PapersOnLine 48-1 (2015) 067–072
present study only considers subsonic operation. Future
work could consist of an adaptive controller which is not
only dependent on altitude (as used in this work) but also
on speed, so that a transition from sub- to supersonic
flight would be possible. Since the aerodynamic center of
lift of the Concorde changes when this happens, fuel is
transferred inside the plane to different tanks in order
to shape balance and trim. This of course changes the
center of gravity and therefore the flight behavior. So the
challenging task of designing an efficient controller which is
capable of flying the plane in sub- and supersonic domains
was not considered in this paper.
A co-simulation coupling between X-Plane and Matlab
has already been established for example by Ribeiro and
Oliveira (2010), who, however, only investigated the roll
dynamics for creating a roll attitude autopilot system.
Nusyirwan (2011) developed a connection between Mat-
lab and FlightGear by using Python. A custom set of
equations was used for the flight dynamics and a simple
PID altitude-hold and heading-hold was developed. The
visualization is done via FlightGear on a multi-monitor
setup. Sorton and Hammaker (2005) used FlightGear with
a custom flight dynamics model in JSBSim and Matlab
with a C++ interface for the simulation of an autonomous
unmanned aerial vehicle and afterwards a Hardware-in-
the-Loop testing was done with a self-developed actuator.
In this work the flight calculations are done by FlightGear
and this program is assumed to be a black box to Matlab,
just as a real plane would be. This approach benefits from
the high degree of realism provided by FlightGear which
already uses well-established, realistic FDMs, which are
based on the nonlinear equations of motion and therefore
avoids the use of potentially over-simplified flight dynam-
ics models. Also, different planes and flying objects can be
used. Since just a computer with Matlab and FlightGear
is needed, the developed framework has high potential
in educational use as different controllers can easily be
implemented and tested on potentially highly challenging
plants (for example fighter aircrafts in their nonlinear
operation area or the already mentioned transition from
sub- to supersonic speeds).
2. METHODOLOGY
The linearized equations of motion are taken from Brock-
haus (2001) and are extended with a fifth state (alti-
tude respectively heading) which also functions as the
controlled output afterwards. The linearized longitudinal
dynamics are described by:
ẋLon = ALon,4×4 xLon + BLon,4×2 uLon (1)
where the specific entries of the matrices A and B depend
on the altitude and have to be estimated. The state vector
T
xLon = [ q, α, v, γ ] consists of the quantities pitch rate q,
the angle of attack α, the velocity v, and the angle of climb
γ. In some books (e. g. Stevens and Lewis (2003)) instead
of γ the pitch angle θ is used, but since the linearized
relation γ = θ − α holds, both choices are valid. The input
T
quantities uLon = [ δF , η ] are the throttle δF and the
elevator η. A fifth state — the altitude — is introduced
and its derivative is only dependent on γ.
The lateral dynamics are described by:
68
ẋLat = ALat,4×4 xLat + BLat,4×2 uLat (2)
T
The state vector xLat = [ r, β, p, φ ] now consists of the
yaw rate r, the sideslip angle β, the roll rate p, and the
roll angle φ. The introduced output state is the heading Ψ
(often also called yaw) and its derivative is only dependent
T
on the yaw rate r. The input quantities uLat = [ ξ, ζ ] are
the aileron ξ and the rudder ζ. These two sets of equations
are the linearized equations of motion for a conventional
aircraft linearized around level-trimmed flight conditions.
Then the longitudinal and lateral dynamics are mutually
decoupled.
The angle of attack α and the sideslip angle β are called
aerodynamic angles and describe the direction of the
relative wind from the airplane-fixed coordinate system
through the body’s center of mass. Roll, pitch, and yaw
describe the orientation of the airplane in space with angles
about the center of mass and are also referred to as the
aircraft’s principal axes. The angle of climb γ is defined as
the vertical angle between the flight path and the Earth.
One can also interpret it as the ratio between the height
change and the distance covered. Therefore, the altitude
change is (linearly) only dependent on γ.
Both continuous-time models are of the standard form
ẋ(t) = Ac x(t) + Bc u(t), (3)
y(t) = Cx(t). (4)
Since the state vectors consist of physical states, the C
matrices just select the output states. The discrete version
of the state equation is written as:
x(k + 1) = Ad x(k) + Bd u(k), (5)
y(k) = Cx(k). (6)
The computation of the discrete state space matrices is
possible from their continuous counterparts and depends
on the sampling time Ts as for example shown in Ogata
(1995):
Ad = expm (Ac Ts ), (7)
 
Ts
Bd = expm (Ac τ ) dτ Bc = A−1 c (Ad − I) Bc , (8)
τ =0
where a zero-order-hold (piecewise constant) input u is
assumed and expm denotes the matrix exponential. Since
the output of most black-box estimation procedures is a
discrete-time representation of the system dynamics, from
now on the index d is omitted when referring to the state
space matrices.
After the estimation and validation of a model different
controllers are designed. The discrete-time LQR (linear
quadratic regulator) minimizes a cost function of the
following form:
∞
 
J= x(k)T Qx(k) + u(k)T Ru(k) , (9)
k=0
where Q > 0 and R > 0 are the weighting matrices for
the state error and input actions. The state vectors are
augmented by the integrated output error to account for
offset errors, changing operating conditions such as fuel
usage and wind as well as model mismatch. As shown in
Ogata (1995) an optimal solution of the form:
u(k) = −Kx(k), (10)
 MATHMOD 2015
February 18 - 20, 2015. Vienna, AustriaGuilherme Aschauer et al. / IFAC-PapersOnLine 48-1 (2015) 067–072 69

exists, with K obtained from the solution of the associated

Riccati equation, FlightGear
 −1 T
K = R + BTP B B P A, actuator flight
  −1 T 
P = Q + A P − P B R + BTP B
T
B P A, input attitude
data data
which minimizes the cost function (9). The integrator in
discrete time is realized by the Forward-Euler formula: Matlab
xi (k + 1) = xi (k) + Ts e(k),
where e(k) is the control error between the reference r(k) Fig. 1. UDP communication block diagram
and the output y(k):
can be chosen freely and was set to 0.1 s. Care must be
e(k) = r(k) − y(k). taken that Matlab does not take longer than that amount
In the gain-scheduled version of the LQR controller, the of time to compute and send the actuator input values,
gain matrix K is computed for different altitudes and because otherwise the packages are being buffered and
then linearly interpolated between two resulting gains Matlab receives out-dated flight attitude data which may
depending on the actual altitude. lead to unintended flight behavior due to wrong actuator
inputs calculations by the controller. A simplified outline
The second controller used is an MPC (model predictive of the communication is shown in Figure 1. A sample file
controller), also called receding horizon controller. In every that describes the communication protocol used between
iteration, a (constrained) optimization problem is solved Matlab and FlightGear is shown in Listing 1.
and the first step of the resulting control strategy is
applied. A prediction horizon np is specified as the number Listing 1. Example communication protocol file
of time instants (samples) for which the predicted output
<? xml version = " 1.0 " ? >
yp is calculated when control action is applied for nc < PropertyList >
samples. Often, nc is chosen much shorter than np to < generic >
reduce computation time since the optimization problem < binary_mode > true </ binary_mode >
size has to be solved faster than the sampling time Ts < lin e_separa tor > </ line_s eparator >
< var_separator > </ var_separator >
which was set to 0.1 s in this work. The implementation < input >
of the predictive controller follows the approach in Wang < chunk >
(2009) in which the differences of the control and state < node >/ controls / engines / engine / throttle </ node >
vectors are used: < name > throttle </ name >
< type > float </ type >
∆x(k) = x(k) − x(k − 1), < format >% f </ format >
∆u(k) = u(k) − u(k − 1). </ chunk >
< chunk >
Then the augmented state vector is defined as < node >/ controls / flight / elevator </ node >
 T < name > elevator </ name >
xaug (k) = ∆x(k)T , y(k)T < type > float </ type >
to finally obtain an augmented state space model on which < format >% f </ format >
</ chunk >
the optimization process is based:
       </ input >
∆x(k + 1) A 0 ∆x(k) B < output >
= + ∆u(k), < chunk >
y(k + 1) CA I y(k) CB
  < node >/ position / altitude - ft </ node >

∆x(k) < name > altitude - ft </ name >
y(k) = 0 I < type > float </ type >
y(k) < format >% f </ format >
With this approach, integrators are implicitly added for </ chunk >
</ output >
the outputs. Then a constrained optimization problem </ generic >
is formulated that is solved by quadratic programming. </ PropertyList >
Limitations on the absolute values as well as on the rate
of change of the actuator inputs and plant outputs can In this example FlightGear receives the throttle and ele-
directly be cast into linear inequality constraints. vator input values and sends the current altitude. This is
done on UDP ports that have to be specified via parame-
3. FRAMEWORK ters when FlightGear is started, as well as the rate at which
packets are sent. More values can easily be accessed by
The main part of the communication between Matlab and adding them in chunk blocks inside the protocol definition.
FlightGear is done via UDP (user datagram protocol),
an IP-based network protocol with a simple transmission Additionally, FlightGear can start a local HTTP server to
model and very little overhead. There is no handshake manipulate a large number of variables that can be read
dialogue before a communication and therefore no guar- out and written to in a normal web browser as well as by
antee of successful delivery and ordering. Also, packages opening URLs from inside Matlab. Opening the URL
can be received out of order, a missing package cannot be
detected easily, and there is no error checking provided http://localhost:5505/controls/gear/
within the protocol itself. In real-time systems with time- brake-parking?value=1&submit=update,
sensitive applications, UDP is often used when package for example enables the parking brake if the server has
loss is preferable to waiting for resent packages. The sam- been started on port 5505. If the variable should only be
pling time at which FlightGear sends and receives data read then the part of the URL after the question mark has

69
MATHMOD 2015
February 18 - 20, 2015. Vienna, AustriaGuilherme Aschauer et al. / IFAC-PapersOnLine 48-1 (2015) 067–072
70

to be omitted. Thus all FlightGear variables can either be 0.1

1.1

Elevator,Throttle
accessed via UDP or HTTP. The latter option has the
advantage of manipulating variables only when there is a 0 1
need to do so. It is therefore not necessary to send data at −0.1
every sample interval in UDP packages. On the other hand, 0.9
if called repeatedly, the HTTP operations are too slow for −0.2
real-time usage. So this option is chosen to control the −0.3
0.8
autopilot, the flaps during take-off, and the parking brake. 0 50 100 150 200 250 300
Inside Matlab, the communication is done via two UDP time (s)
objects (one for reading and one for writing) which have

density (dB/Hz)
20

power spectral
to match the ports specified in FlightGear. Then these 0
objects can be treated like normal files by calling fread −20
and fwrite. URLs are called by the command url and no −40
further initialization has to be done. −60

A sample command line execution of FlightGear with −80

0 0.5 1 1.5 2 2.5 3
providing some options is: frequency (Hz)
fgfs --turbulence=0 --wind=0@0 --aircraft=Concorde
--timeofday=noon --httpd=5505 --enable-clock-freeze
--generic=socket,out,10,localhost,5501,udp,simple Fig. 2. Throttle (gray) and elevator (black) input for
--generic=socket,in,10,,5502,udp,simple obtaining identification data and their power spectra

This starts FlightGear with the Concorde aircraft in r e  xi u x y

paused mode (clock freeze) standing on the standard air-
port with mild weather conditions (no wind and turbu-
lence). A local webserver is started on port 5505 to access
the property tree for getting access to all internal variables
via a web browser. On port 5501 FlightGear sends UDP
packages at a rate of 10 Hz in the form described in the file
simple.xml and on port 5502 it waits for UDP packages.
4. MODELLING
Highly accurate nonlinear sets of equations exist to de-
scribe the standard flight motion of an aircraft (see for ex-
ample, Stevens and Lewis (2003) and Brockhaus (2001)).
As long as the plane is flying in conditions usually occuring
during scheduled flights, a linearized version of these equa-
tions are sufficient for long-distance maneuvers like head-
ing and altitude changes. Brockhaus (2001) lists the state
matrices for lateral and longitudinal dynamics for different
flight conditions for six different aircraft. Throughout this
paper, the Concorde was used because an initial model
for the estimation process could be obtained from the
literature and the model of the airplane in FlightGear
is sufficiently accurate. Furthermore, more advanced con-
trollers capable of supersonic flight could be developed in
the future.
In order to obtain input/output data for the estimation
process the plane’s built-in autopilot is used to reach
steady state conditions on a specified altitude. After turn-
ing off the autopilot, the actuators for the longitudinal
dynamics (throttle and elevator) are excited with a chirp
signal overlaid with low-pass filtered white noise, and the
input and output (the whole state vector) are logged via
Matlab and stored in a matrix. Then the procedure with
reaching steady state with the autopilot and excitation
is repeated for the lateral dynamics (aileron and rudder).
Care has to be taken that there are no relevant signal
contents above the Nyquist frequency which is half the
sampling frequency. An example of a throttle and elevator
input action as well as their power spectra are depicted in
Figure 2.
K FlightGear C
−
Fig. 3. Integrating LQR controller with full state feeback
Figure 2 shows that there are no relevant information
above 0.5 Hz and 1.5 Hz for the throttle and elevator
inputs, respectively. The aileron and rudder characteristics
are similar to the elevator since their time constants
are on a comparable scale. Higher frequency inputs not
violating the Nyquist criterion are possible, but show no
relevant dynamical effects on the aircraft for the modeling
goals. The dynamics of the throttle-actuated thrust are
even slower than those of the other actuators and so
there is no need for high-frequency inputs. At this point
it also has to be mentioned that at the moment the
model of the Concorde in FlightGear does not seem
to represent realistic actuator dynamics except for the
throttle and rudder inputs, which also discourages the use
of high-frequency inputs.
Excitation runs are then made for different altitudes, each
2000 m, starting at 2000 m until 16 000 m. At high alti-
tudes the excitation runs had to be repeated occasionally,
because the estimation process sometimes failed. One pos-
sible reason for this is the trans-sonic speed regime reached
even without using the afterburner.
5. CONTROLLER AND OBSERVER DESIGN
The first tested controller type are LQR controllers with
integration of the output error and full state feedback. The
structure is shown in Figure 3.
The curled magenta lines indicate UDP communication
while the rest of the block diagram is processed in Matlab.
The reference value r is either the heading Ψr for the
lateral or the reference altitude Hr for the longitudinal
dynamics. Since both dynamics are linearly decoupled, two
separate controllers are designed. The integrated output
error is appended to the state vector. The new state vector
is multiplied by the controller gain matrix K obtained

70
 MATHMOD 2015
February 18 - 20, 2015. Vienna, AustriaGuilherme Aschauer et al. / IFAC-PapersOnLine 48-1 (2015) 067–072 71

·10−2
Disturbance

pitch rate
Noise 5

x ym 0
r e  i u y
K FlightGear −5
− 0 50 100 150 200 250 300
·10−2
ŷ OBSERVER 4
2

alpha
+
H −
0
−2
−4
+ x̂k+1 x̂k ŷ 0 50 100 150 200 250 300
B + +
z −1 C 1
0.9

speed
0.8
x̂ 0.7
A 0.6
0 50 100 150 200 250 300
·10−2
5

gamma
Fig. 4. Integrating LQR controller with state observer 0
−5
−10
using Matlab’s lqi command. In case that not the entire 0 50 100 150 200 250 300

state vectors are measurable, an observer is utilized to re- 0.55

altitude
construct the states. Here, a standard Luenberger-observer 0.5

is designed for demonstration purposes. The uncertainty 0.45

of the process model and appearance of the measurement 0 50 100 150 200 250 300

noise is just considered with one parameter during the
design process. This parameter describes to which ex-
tent the system relies on the measurements in favor of
its own process model. Since the measurement noise has
artificially been added in Matlab its standard deviation
is perfectly known and the process noise’s deviation can
be estimated depending on the weather conditions (in the
Matlab model, no wind and weather data were taken into
account). These two variables were used to additionally
build a Kalman filter to calculate the optimal observer gain
matrix H. The full configuration is shown in Figure 4 but
the outer feedback loop of the estimated output ŷ to the
reference was omitted for clarity and space reasons. Again,
the curled magenta lines indicate UDP communication be-
tween Matlab and FlightGear. The controller and observer
gains for MPC and LQR have been chosen to achieve
acceptable performance for small- to medium-sized steps
(maximum of 40 degrees change in heading direction and
4000 m in altitude). Larger reference steps would require
a feed-forward command shaping, lowering the feedback
gains, or implementing error saturations and anti-reset
windup logics in Matlab. When full state feedback was
used, all five states were considered measurable without
noise and directly used to calculate the next input action.
When observers were used, only the heading and altitude
were measured and additionally overlaid by noise. This
means that four states had to be estimated from one noisy
measurement.
6. RESULTS
The identification process results are highly satisfying,
although sometimes the excitation process has to be re-
peated for higher altitudes, presumably because the plane
is too close to Mach 1. Most of the time, though, and espe-
cially for altitudes below 14 000 m, the estimation results
are in good agreement with the measurement data as can
be seen in Figure 5 where the measurements are compared
with the output of the estimated model for the vertical
dynamics at 10 000 m. The root-mean-squared-error-based
fit values for these examples are as follows:
time (s)
Fig. 5. Comparison between the (normalized) input/out-
put data (gray) and the the output of the estimated
model (black).
pitch rate 82.6 % yaw rate 89.9 %
alpha 78.3 % sideslip angle 96.6 %
speed 89.7 % roll rate 88.7 %
gamma 85.6 % roll angle 93.2 %
altitude 88.5 % heading 86.0 %.
The estimation results for different altitudes and also for
the horizontal dynamics are of similar, high quality. After
designing the controllers, a flight path with changing ref-
erence altitude and heading values was created to be used
by all three controller types. For the predictive controller
the control horizon was set to 15 samples (1.5 s) and the
prediction horizon was set to 300 samples. With these
values it was just possible to run the co-simulation on a
standard notebook in simulated real-time. At first, mild
weather conditions were assumed for the validation of the
controllers. The results are plotted in Figure 6 for the
scheduled LQR case with full state feedback. No further
parameter tuning was done after the controllers showed
satisfying behaviour (following a reference trajectory in
turbulent weather conditions). Especially after about 850 s
in Figure 6 the mutual influence of the lateral and longitu-
denal dynamics on each other can be seen. During a turn
maneuver (ramp for changing the heading) the aircraft’s
motion was disturbed by a large step in the reference
altitude which led to large elevator action and the plane
leaving the linear operation range where both dynamics
are decoupled.
Then, the same runs were repeated with enabled turbu-
lences (they were set to 0.75 in a range from zero to
one). With these severe disturbances even FlightGear’s
built-in autopilot had sometimes trouble with reaching
respectively holding the desired heading. Figure 7 shows
a part of the same reference flight path as Figure 6, but
in turbulent weather conditions using a model predictive
controller. Only the altitude and heading were measurable

71
MATHMOD 2015
February 18 - 20, 2015. Vienna, AustriaGuilherme Aschauer et al. / IFAC-PapersOnLine 48-1 (2015) 067–072
72

14
altitude (km)

12
10
8
6
4
30
heading (◦ )

20
10
0
−10
0.3 0.03
0.2 0.02
actuators

0.1 0.01
0 0
−0.1 −0.01
−0.2 −0.02
elevator aileron
−0.3 −0.03

0 100 200 300 400 500 600 700 800 900 1000 1100 1200
time (s)

Fig. 6. Reference trajectory (dashed line) and real altitude and heading by an integrating scheduled LQR controller
with full state feedback (all states measurable without noise) and mild weather conditions. The third plot shows
the normalized actuator input values (between −1 and 1) of the elevator (black) and aileron (red).
12
heading (◦ )altitude (km)

10
8 tor FlightGear offers great flexibility in accessing internal
6 variables via external interfaces and it was shown that
4
2 an aircraft can be controlled with Matlab. The whole
30
20
10
0
0.2
0
−0.2
400 600
time (s)
Fig. 7. Reference trajectory (dashed line) and real altitude
and heading by a model predictive controller with
a state estimator (only altitude and heading were
measurable and corrupted by noise).
but corrupted with white noise, and the other states had to
be estimated. Depending on how aggressive the controller
is tuned the actuators seem to be excited with highly
dynamic inputs. However, further investigations showed
that the maximum rate of change of the elevator was
less than 10◦ per second, and for the aileron and rudder
commands even less demanding inputs were observed.
The lateral dynamics are much more influenced by severe
turbulence and appear noisy while the error dynamics of
the longitudinal dynamics are less affected by gusts. A
cause for the strong weather influence on the heading is
also the larger penalty imposed on the aileron and rudder
inputs in the optimization problem when designing the
controllers. They were chosen to avoid large roll angles
which give rise to nonlinear dynamics and sometimes led
to crashes, especially when combined with low speeds due
to climbing maneuvers.
7. CONCLUSION
The developed framework is able to establish a connection
between FlightGear and Matlab and works with different
types of aircraft. The realistic, open-source flight simula-
process of starting FlightGear, selecting a specific aircraft,
establishing a UDP connection, take-off, identification,
controller design and following a reference trajectory is
all fully automated by a Matlab script, which offers the
possibility to easily design scheduled controllers. Different
types of controllers and state observers have been imple-
elevator mented and their performance tested on a well visualized,
800 1000 1150
complex dynamic system. The design task can be made
more challenging by changing weather conditions, failure
of aircraft parts, leaving the linear operating range or
guaranteeing passenger comfort, and thus lends itself to
use cases in control education.
REFERENCES
Berndt, J.S. (2004). JSBSim: An Open Source Flight
Dynamics Model in C++. In AIAA Modeling and Sim-
ulation Technologies Conference and Exhibit. Citeseer,
Providence, Rhode Island.
Brockhaus, R. (2001). Flugregelung. Springer, 2nd edition.
Nusyirwan, I.F. (2011). Engineering flight simulator using
Matlab, Python and Flightgear. In Simtect. Melbourne,
Australia.
Ogata, K. (1995). Discrete-Time Control Systems. Pren-
tice Hall, 2nd edition.
Ribeiro, L. and Oliveira, N.M.F. (2010). UAV autopilot
controllers test platform using Matlab/Simulink and
X-Plane. In Frontiers in Education Conference (FIE),
2010 IEEE, S2H–1–S2H–6.
Sorton, E. and Hammaker, S. (2005). Simulated flight
testing of an autonomous unmanned aerial vehicle using
Flightgear. In Infotech@Aerospace, 2005 AIAA.
Stevens, B.L. and Lewis, F.L. (2003). Aircraft Control and
Simulation. Wiley-Interscience.
Wang, L. (2009). Model Predictive Control System Design
and Implementation Using Matlab. Springer, 1st edition.

72