This document discusses using knowledge-based engineering principles to automatically generate simulation models for control system design. It presents a method to create physics-based models in Modelica from a knowledge base representing concepts and relationships. As a case study, the method is applied to generate a simulation model of a quadrotor unmanned aerial vehicle. The results show the model can be used for control design and the approach integrates dynamics analysis and control design into a modeling framework using object-oriented modeling and knowledge-based engineering.

1. Mathematical and Computer Modelling of Dynamical Systems
Vol. 16, No. 3, June 2010, 241–256
Knowledge-based simulation model generation for control law design
applied to a quadrotor UAV
M.J. Foeken* and M. Voskuijl
Faculty of Aerospace Engineering, Delft University of Technology, Kluyverweg 1,
2629HS, Delft, The Netherlands
(Received 30 December 2010; final version received 17 June 2010)
Like for all mechatronic systems, the role of control software in unmanned aerial vehicle
(UAV) design is becoming more important. As part of an automated control software
development framework, this article discusses the development of a simulation model
generation method. As a basis, the application of knowledge-based engineering (KBE) is
suggested, requiring the definition of an ontology to capture the various domain concepts
and relationships. The initial knowledge base represents concepts and relations to create
models with Modelica, the object-oriented modelling language used to construct the
simulation model. The need for physics-based, high-fidelity simulation models using the
latest design parameters is illustrated by investigating the model of a quadrotor UAV. The
results show that the obtained model can form the basis for control design and that the
approach provides means to integrate the dynamics analysis and control design into a
modelling framework using a combination of object-oriented component modelling and
KBE principles.
Keywords: controller design; knowledge-based engineering; unmanned aerial vehicle
1. Introduction
According to Van Amerongen, ‘mechatronic design deals with the integrated design of a
mechanical system and its embedded control system’ [1]. With the advances in computing
capabilities, the role of the embedded control system in the mechatronic system design is
becoming more and more prominent. The ‘traditional’ sequential design approach, in which
mechanical, electrical, electronics and software components are designed and optimized
sequentially, is therefore becoming less suitable.
The increasingly important role of control software is prominent in the aerospace field,
where both aircraft and spacecraft operations benefit from the application of software. Apart
from passenger jets, using software with millions of lines of code, and modern fighter jets
that require computers to be able to fly in the first place, software has enabled the use of
unmanned aerial vehicles (UAVs). UAVs come in a range of sizes, forms and purposes, from
the fixed-wing Global Hawk, with a wingspan of 35 m and with a primary focus on military
surveillance and intelligence gathering, to the X-Ufo quadrotor, a remotely controlled toy of
50 cm wide weighing less than 350 g [2] (Figure 1). However, all UAVs share the
characteristic that flight is either remotely controlled by a pilot on the ground, or performed
autonomously. In the first case the pilot uses the signals from on-board visual sensors to fly
*Corresponding author. Email: m.j.foeken@tudelft.nl
ISSN 1387-3954 print/ISSN 1744-5051 online
© 2010 Taylor & Francis
DOI: 10.1080/13873954.2010.506745
http://www.informaworld.com

2. 242 M.J. Foeken and M. Voskuijl
(a) (b)
Figure 1. Examples of unmanned aerial vehicles. (a) Northrop Grumman RQ-4 Global Hawk [3].
(b) Silverlit X-Ufo [2].
the aircraft. In the second case, a combination of visual, inertial and positioning sensors is
used to guide the aircraft along its predefined path, in the mean time performing additional
tasks when required. Autonomous flight is obtained by a combination of control software
acting like an auto-pilot, and ‘external input’ that defines the flight profile and the tasks to be
performed during the mission.
As controller design can often not be performed without a suitable dynamic model of the
aircraft, these models should be available from early on in the design process. Using control
theory, the control algorithms are subsequently developed and implemented as software. To
test and verify the control software, a mix of hardware- and software-based test setups can be
applied, ranging from full software-based simulations to prototype hardware tests. A
common practice in aircraft design is the use of ‘Iron birds’, which combine the real aircraft
systems hardware with a virtual flight environment. In this way, the control of the electric,
hydraulic and other systems can be tested without having to perform an actual flight test. Due
to the large amount of systems, it is not possible to model and simulate the behaviour of all of
them, therefore, a combination of hardware and software is used.
In this article, a simulation model generation method is proposed, based on a combina-
tion of the object-oriented modelling language Modelica and the application of knowledge-
based systems (KBS) principles. The methods are developed as part of a design framework
for mechatronic systems, with a focus on control software. To test the method, it is applied to
a quadrotor UAV model, which is subsequently used for further analysis.
In Section 3, the performed research project and its relation to a control software design
framework will be introduced, followed by an overview of related research. Section 4
discusses the simulation model generation process. In Section 5, the model for the quadrotor
UAV case study is discussed and the results of applying a trim routine are presented. Finally,
in Section 6 the conclusions are drawn.
2. Literature review
The application of knowledge-based techniques in the development of simulation models
focuses on various subjects. The application of knowledge engineering for the development
of conceptual simulation models is discussed by Zhou et al. [4], focussing on how to capture,
represent and organize the required knowledge. A general introduction on KBS is given by
Milton [5]. Here, a KBS is defined as being a ‘computer program that uses Artificial

3. Mathematical and Computer Modelling of Dynamical Systems 243
Intelligence techniques to solve complex problems that would normally be solved by a
person with specific expertise’. The use of expert knowledge in engineering applications
enables the automation of that part of the design and analysis process that is repetitive, non-
creative and time-consuming. This can be supported by applying knowledge-based engi-
neering (KBE) techniques and tools, featuring rule-based design and object-oriented pro-
gramming [6]. La Rocca provides an example of how these principles can be applied to
generate finite element models for structural analysis using a dedicated KBE modelling and
development platform and automated meshing algorithms [6].
A considerable amount of knowledge reuse can be obtained by library development.
Breunese et al. [7] describe the architecture of a library of reusable simulation models, and
argue that there is a need for a taxonomy of component classes to handle the complexity
associated with large libraries. The structure of the library is not restricted to be tree-like,
instead, a tangled structure can also be obtained. Similarly, Nayak discusses the organization
of modelling elements in terms of assumption classes, which group elements based on the
same physical principles, and approximation relationships [8], indicating if an element
provides a simplified description of another element. The resulting library is tangled as
well. To enable component reuse, the application of web-based hierarchical libraries is
introduced by Bernardi and Santucci [9]. In this case, the hierarchy is based only on
abstraction levels, which might reduce the complexity of library, but offers less flexibility.
The aforementioned component classes and modelling elements come in various types.
For example, the Composable Object concept combines different views in a single object
[10]. Using parametric descriptions, the consistency between form and behaviour can be
maintained. The interaction between objects is port-based, and connected they represent
both a system-level design description and a virtual prototype of the system. Due to the port-
based approach, views can be replaced by more elaborate models if necessary, which are
possibly built up from other sub-models. On the contrary, the method of Nayak [8] is based
on equation fragments describing the behaviour of an element and to create the model of a
complete system the equations are combined in a single system. This requires a consistent
naming of constants and variables throughout the entire library. With a port-based approach
this is less of an issue, as the interaction takes places via a predefined set of port elements.
With this in mind, Liang and Paredis [11] discuss a port ontology in light of automatic
model composition and the need to take into account the type of interaction taking place.
Often, these interaction models depend on the parameters of both subsystems involved. This
principle is also applied by D’Amelio and Tomiyama [12] to discover unpredictable interac-
tions in and between system components, based on qualitative physics. Similarly, a framework
to capture the interaction in component-based design is presented by Lee and Xiong [13]. To
prevent connecting incompatible components, the interaction type is checked, which is a task
that a KBE system should be able to handle relatively straightforward.
3. Control software generation framework
To support the development of control software and to cope with the multidisciplinary nature
of mechatronic systems, an automatic control software generation framework has been
proposed previously [14,15]. Depicted in Figure 2, the framework contains a combination
of to-be-developed and existing commercial tools, supported by a high-level model descrip-
tion providing both a functional view on the system, as well as an integration platform. The
design process as represented by the work flow diagram in Figure 2 starts with a function
model, representing the intention of the designer, and subsequently a system model is built
up from mechatronic components. Further requirement and system decomposition results in

4. 244 M.J. Foeken and M. Voskuijl
Functional
model
Integration framework
Function modeling (modes, communication, user interaction)
Function model
Qualitative
Mechatronics
behaviour
feature modeling
generation
Mechatronics feature- Qualitative
based product definition behaviours
Mechanical Quantitative
Controller design
embodiment design behaviour generation
Quantitative
behaviour
Control code Control model
generation generation
Mechanical CAD Controller model
Control software Control model
model and prototype and prototype
Software level Hardware and machine
verification level verification
Figure 2. Architecture of the integration framework. The white blocks represent tools to be further
developed. Dashed-line blocks correspond to existing commercial software tools.

5. Mathematical and Computer Modelling of Dynamical Systems 245
a system specification serving as the backbone for further detailed design and analysis.
Combined, the function and system models are analysed using qualitative reasoning tech-
niques to determine the required control strategy, from which the control software is
synthesized. To verify the obtained control software, the system model is used to generate
suitable simulation and verification models. Once implemented in software, the backbone
also facilitates the exchange of data between involved tools and actors.
For clarification, we from now on use the term ‘object’ when we refer to the program-
ming concept, whereas ‘component’ refers to a technical system component, and ‘modelling
element’ or ‘fragment’ to a part of the model of the system.
Labelled as ‘Control Model Generation’ in Figure 2, part of the supported development
process consists of creating models used for control algorithm and control software design
and verification. Often referred to as plant or simulation models, these can come in the form
of system dynamics models or finite-element models. Although an integrated finite element
simulation, taking into account structural, aerodynamic and electrical physical phenomena
might be attractive in terms of accuracy, the computational effort and time required for large-
scale systems makes them unsuitable for controller design and verification. Instead, these
different types of simulations can be used in a sequential order. For example lift, drag and
moment coefficients and stability derivatives determined by using computational fluid
dynamics (CFD) methods can be used in flight mechanics models during controller design.
There is not always a need for the highest fidelity model; instead, the ‘right’ fidelity is often
required, where fidelity is defined as accuracy. The highest fidelity is reached when the
uncertainty of the model is within the error bound of the experimental data [16].
In the current framework, the analysis data is directly tied to the system components it is
related to. For the initial implementation, the Systems Modelling Language (SysML) has
been proposed [14]. SysML is an extension of UML, with a focus on systems engineering
applications, providing means to model and analyse (non-software) systems [17]. The
language specification describes diagrams and elements to model requirements, functions,
use cases, system decomposition and hierarchy, among others, based on the object-oriented
programming paradigm. Being a visual language, SysML provides a transparent way to
develop and give an overview of both the function decomposition and the systems
architecture.
With the possibility to store the obtained models in an XML-based format in which the
object-oriented structure of the model is retained, the models can be processed with custom
tools based on generic XML processing methods to transform them into other models, while
using the associated model or analysis data.
4. Control model generation
In the framework, the multi-disciplinary system architecture is built up from mechatronic
system components, as introduced in the previous section. However, in control design the
system is often represented as a set of (linear) transfer functions, either in the time or in the
frequency domain. The link between the parameters in this representation and those of the
physical system can be small, in the sense that the former have no direct physical meaning,
but are based in the mathematical domain. For a simple mass-spring-damper system these
can still be traced back to parameters of the original system, but for more complex systems,
this becomes troublesome, if not impossible.
The Modelica language has been designed to model large, complex and hybrid physical
systems and is based on differential and algebraic equations. It supports non-causal and
object-oriented modelling techniques, and as such stimulates the reuse of modelling

6. 246 M.J. Foeken and M. Voskuijl
Mechatronic 1 1..*
Component
system
1
System model
1..*
Physical 1 1..* 1 1..*
Physical Modelica
component
description element
classes
1
Control model
1..*
Equation
Mathematics
Figure 3. Relationships between components and elements at different viewpoints.
knowledge. In contrast to the use of transfer functions, with this ‘physical modelling’
paradigm a component-based model corresponding to physical elements, using parameters
directly related to the real world, can be obtained. These parameters can then be obtained via
the integration framework, which binds the model data and analysis results directly to the
system components. As often control design relies on linear models at certain design
conditions, the obtained non-linear model must be linearized.
The relation between elements on system component, control and mathematical model
can be represented as in Figure 3, adapted from Ref. [7]. Although a direct, one-to-one
mapping from system component to modelling element is relatively straightforward, this
kind of mapping ignores the possible interaction occurring in or between elements of
different domains. As a single system component can show behaviour in different physics
domains, for example, the mechanical and aerodynamic domain, a combination of elements
will be required to obtain the correct interaction. For example, the main functionality of a
DC-motor is to act as a torque generator. However, when attached to a rotor it will also serve
as an element introducing the aerodynamic forces into the structure, for which the dimen-
sions of the DC-motor might come into play. For example, in the case of a quadrotor, the
relative vertical position of the rotors with respect to the overall centre of gravity has a strong
effect on the stability.
4.1. Requirements
To be able to generate control models in the context of the software development framework,
the following requirements have been recognized:
(1) It must be possible to build up the system architecture from elementary technical
components.
(2) These components must have one or multiple representations in the physical
modelling world, see Figure 3.

7. Mathematical and Computer Modelling of Dynamical Systems 247
(3) When connecting elements, the port compatibility must be checked to prevent the
coupling of incompatible elements.
(4) Not only the intended behaviour, but also ‘secondary’ or ‘unintended’ behaviour
must be recognized and included.
To handle the fourth requirement, the interfaces of the component should not be fixed to the
main behaviour of the component, or those that fulfil the main, expected, functionality.
D’Amelio and Tomiyama [12] denote the additional interaction as ‘unpredictable interac-
tion’, resulting in behaviour which occurs either within a domain or by interactions between
domains.
The solution presented in Ref. [12] links physical phenomena, for example, gravity or
thermal radiation, to components in a library. When the system is built up by instantiating
these components, a qualitative reasoner reasons out all possible behaviour [18]. In combi-
nation with a model representing the intended behaviour, the unpredictable interactions are
discovered. The knowledge base containing the model elements, physical phenomena and
related concepts is implemented in the Knowledge Intensive Engineering Framework
(KIEF) [19]. In general, a knowledge base is built up from concepts, attributes of these
concepts, values, and the relationships between concepts. Most knowledge bases can be
represented as a diagram in which concepts are connected through relations, see Figure 5, or
by means of a frame focussing on attributes, as in Figure 4 [5].
Although the method shown in Ref. [12] is based on qualitative physics, the idea of using
physical phenomena linked to system components can be extended to quantitative simula-
tion model elements linked to these components. Whether a certain subelement is required
for a certain system depends then on, for example, the relative position in case of heat
radiation, or on whether two components make physical contact. The interface of a compo-
nent should therefore not be fixed nor restricted to only the intended connections, but must
Figure 4. Partial rotor model as stored in knowledge base.

8. 248 M.J. Foeken and M. Voskuijl
depend on the system’s implementation. By categorizing the components, for example, as
proposed by Breunese et al. [7], such that for each technical component all associated
physics domains are known, a reasoner can determine which related modelling elements
are required, based on geometric data.
4.2. Knowledge base development
The creation of a knowledge base containing the systems components and relations starts
with the identification of the applicable concepts and their relationships. Such an ontology
defines what concepts can be found in the domain, and what kind of relations between these
concepts exist. The three levels indicated in Figure 3 each form a domain by itself for which a
separate ontology can be created, which can subsequently be linked to each other.
As a first step for setting up the knowledge base supporting the model generation
process, a language ontology for Modelica models has been created. For this, Epistemics’
PCPack [20] has been used; a tool to capture, structure and re-use both procedural and
conceptual knowledge. The former is related to expertise on performing tasks, whereas the
latter is related to expertise on concepts and the relationship between these concepts [5].
Based on the Modelica language specification, the concepts and relations in the ontology
are restricted such that only ‘structurally’ correct models can be created with it. In general, a
Modelica class represents the behaviour of a particular aspect of a physical system compo-
nent. It contains a declaration of elements, which include component definitions or class
instances, equations and connections and algorithms. Similar to bond graphs, the connection
between physical components have the dimension of energy or power, whereas the input to
actuators and the output of sensors is a data stream.
Based on the ontology, a database containing Modelica libraries is created, providing an
insight into both the relationships between and the properties of classes. Figure 4 shows the
‘partialRotor’ model in the PCPack interface. The frame representation contains the class
attributes and values as well as related class and element definitions. The ‘partialRotor’
model is part of a library of quadrotor specific components, see Figure 5. This tree represents
Quad Rotor.Rotors.partial Rotor J
Quad Rotor.Controllers
Quad Rotor.Rotors.partial Rotor omega
Quad Rotor.Drives
Quad Rotor.Rotors.partial Rotor flange_a
Quad Rotor.Environment
Quad Rotor.Rotors.partial Rotor
Quad Rotor.Rotors.partial Rotor frame_b
Quad Rotor.Rotors
Quad Rotor.Rotors.Simple Rotor
Quad Rotor
Quad Rotor.Rotors.partial Rotor force And Torque
Quad Rotor.Sensors
Quad Rotor.Rotors.Density Rotor
Quad Rotor.Rotors.partial Rotor inertia
Quad Rotor.Utilities
Quad Rotor.Rotors.Inflow Rotor
connect (force And Torque.frame_b, frame_b)
Quad Rotor.Body
connect (intertia.flange_a, flange_a)
Quad Rotor.Quad Rotor Assembly
Figure 5. Quadrotor modelling elements library as part of knowledge base.

9. Mathematical and Computer Modelling of Dynamical Systems 249
the taxonomy of the library, but provides no additional information about the relation
between components.
Due to the nature of the Modelica language, a class specialization hierarchy based on
only class inheritance relations is not possible, as the variability of parameters might change
in a more detailed model (e.g. the resistance becomes variable when changing from a non-
heated to a heated resistor). This problem is circumvented by using additional specialization
and approximation relations between classes, something that is easily managed in the
knowledge base. Similarly, the classes are grouped by their applicable physics principles,
giving both insight into the underlying assumptions and indicating to which domain the
connected model fragments should belong [8].
Whereas the ontology should be applicable to mechatronic systems in general, the
knowledge base will be system or application domain specific, as the type of components
and their various representations can vary significantly between engineering domains.
4.3. Tool implementation
Although the knowledge base contains a categorization of both the Modelica modelling
elements and the system components, to be able to use this database an additional tool is
required, which incorporates the process knowledge related to the actual creation and
transformation of models.
The initial step contains the interpretation of the architecture model designed in SysML,
from which the possible interfaces are derived. Subsequently, the knowledge base is
accessed to find the associated modelling fragments in the involved physics domains. To
be able to construct the final Modelica model, the required model parameters should be
available. Either in the architecture model itself, or otherwise accessible through the design
framework which uses the same architecture model as a backbone to exchange data. The
latter is however not implemented at this point, but is part of ongoing research.
Subsequently, the associated model elements are retrieved from the knowledge base and
the ports of each are found. The port compatibility between elements is checked and non-
connected ports are made available at the model’s top level. For each model element, the
required model parameters are determined and the associated values are added, based on
matching parameter names.
In Section 6, we discuss the possibility of replacing part of the SysML-based architecture
and function model with a ‘product model’ developed on a dedicated KBE platform, which
has object-oriented modelling and CAD capabilities, such that both parameters and geo-
metric data are directly available for further processing.
5. Example application results
5.1. Modelling of quadrotor UAV
More than for fixed-wing UAVs, quad- or multirotor UAVs are highly componentized. As
the four actuators are used both for propulsion and control purposes, and there are no other
moving components, the dynamics are mainly determined by these rotor actuators, the
supportive structure and the aerodynamics of these. The type and quality of the sensors
strongly influences the amount of autonomy that can be achieved.
In its most basic form, the dynamics model of the quadrotor UAV can be built up from
the following components:

10. 250 M.J. Foeken and M. Voskuijl
bdd [Model] QuadRotor [ ActuatorAssembly]
<<subsystem>>
ActuatorAssembly
1 1 1
+dCMotor
p
+rotor
+gear gear
1 1 1 dc Motor
<<block>> <<block>> <<block>>
rotor
DCMotor Gear Rotor
n
values values values
R : Resistance gearRatio : double airfoil : String
alpha : T emperatureCoefficient efficiency : double rotorRadius : Length
Jt : Inertia chord : Length
k :T orquePerAmpere bladeTwist : Angle
C : HeatCapacity bladeTwistDistribution : String bodyShape
G : ThermalConductance numberOfBlades : Integer
fixedTranslati....
a b
d : RotationalDamping thrustCoeff : double a 0 b
dragCoeff : double r = 0.01
Jr : Inertia r = 0.03
frame_b
(a) (b)
Figure 6. Actuator assembly on quadrotor UAV. (a) Actuator assembly components. (b) Modelica
model of actuator assembly.
environmental effects, that is, gravity and aerodynamics
body with mass, inertia and area
four actuators consisting of a DC motor, gear and rotor, taking into account gyroscopic
effects, see Figure 6
sensor package, taking into account drift and noise characteristics, see Figure 9
The effect of electrical and thermodynamical phenomena on system behaviour has not been
taken into account at this point, nor the electrical and control hardware subsystems.
Although the main effect of the rotor is the creation of thrust and torque, the gyroscopic
effects have a large influence on the dynamics of the system. Furthermore, the effect of
aerodynamic drag on the body cannot be discarded despite the low flight speeds. A
description of an accurate simulation model used for testing and validation purposes in the
Matlab/Simulink environment is given by Bouabdallah and Siegwart [21].
In the generated model, the body of the quadrotor is assumed to consist of a single
bodyShape to which the rotors are attached at a fixed distance of the centre of gravity. The
aerodynamic forces acting on the body are modelled in a separate submodel, for which the
local air density is calculated by a separate function. The data used for this example is based
on the quadrotor design used in Ref. [14]. The composition of the rotor actuator assembly is
given in Figure 6.
The rotor models in the library are all based on a single partial rotor model containing the
connectors and the inertia elements, which is extended with various methods to calculate the
rotor forces and moments. To balance the torque around the top axis, two clockwise and two
counterclockwise rotating actuators are needed. Figure 7 gives a schematic overview of the
system.
The simplest way to calculate the thrust and torque of a single rotor is given in
Equation 1, only taking into account a variable rotor speed Ω. The constants b and d are
the thrust and torque constants, respectively, determined by experiment or by CFD analysis.
F ¼ Ω2 ½ 0 0 b ŠT (1a)
Q ¼ Ω2 ½ 0 0 d ŠT (1b)

11. Mathematical and Computer Modelling of Dynamical Systems 251
T1
T4
Ω1
Ω4 V
Xb
T2
T3 Yb
Xe
Ye Zb Ω2
Ω3
Ze
Figure 7. Schematic of quadrotor UAV.
The effect of altitude, flight speed and flight direction on the rotor performance is, however,
significant, such that these variables will have to be taken into account. Equations 2–3 use
the local airspeed and flow directions to calculate the 3D forces and moments at the rotor
hub. Here, λ is the dimensionless rotor inflow velocity, μ the dimensionless in-plane velocity,
with subscript X and Y denoting the decomposition in local x and y axis direction, respec-
tively. The thrust and torque coefficient are defined in Ref. [22]:
4 þ 6μ2 1 þ μ2 1
CT ¼ σa θ0 À θtw À λ (2a)
24 8 4
1 þ μ2 1 1 1
CQ ¼ σa Cd þ λ θ0 À θtw À λ (2b)
8a 6 8 4
Figure 8 visualizes the required angles and velocities. The solidity σ is a measure for what
part of the rotor disc is covered by the rotor blades, and θ0 and θtw are the root pitch angle and
the blade twist angle, respectively. a is the derivative of the lift coefficient CL with respect to
the blade’s angle of attack α. Similarly, the force and moment coefficients in the local x and y
direction are determined. The rotor force and moments then become:
F ¼ ρAΩ2 R2 ½ ChX ChY C T ŠT (3a)
 ÃT
Q ¼ ρAΩ2 R3 CrX CrY CQ (3b)
where ρ is the local air density calculated by a separate function, A the area of the rotor disk and
R the rotor radius. To take into account ground effects, which increase the efficiency of the
θtw
θ0 T
os α
bla Vc e
de plan
tip α or disk
Vs
in Rot
θ0 αloc al
V
bla
de v
roo
U t αdisk μ = V cos α / ΩR
λ = (V sin α + v) / ΩR
(a) (b)
Figure 8. Angles and velocities of rotor [22]. (a) Rotor blade orientation. (b) Rotor disk velocity and
orientation.

12. 252 M.J. Foeken and M. Voskuijl
ibd [System] QuadRotor [ SensorPackage]
block
: Body [1]
gyro
: MechEnergy
subsystem
: ElectronicsSub [1] IMU components Data streams
subsystem block acc
: SensorSub [1] : Battery [1]
block block : ElectricalPower
: Compass [1] : IMU [1]
Mechanical connectors
block magneto
: VoltageRegulator [3 ]
: I2CData : AnalogData
: ElectricalPower
Compass
(a) (b)
Figure 9. Sensor package on quadrotor UAV. (a) Sensor assembly on system component level.
(b) Modelica model of sensor assembly.
rotor when the distance between the rotor and the ground plane is less than 2R, the thrust can be
R2
divided by a factor 1 À 16h2 . Although the interaction between the rotors at low altitudes might
have effect on the controllability of the system, this interaction is not considered.
A third method to calculate the rotor forces and moments, known as the blade element
method, applies a discretization to the rotor blades, and calculates the forces and moments on
each blade segment based on the local flow field. This, however, increases the computation
time significantly, and is therefore not considered in this article.
Although on system component level the input to the actuators and the output of sensors
will be an electrical current, using either an analogue or digital signal, the model represents this
as a stream of data which can directly be used for control purposes, see Figure 9. The sensor
package used in the example consists of an inertial measurement unit (IMU), containing three
gyroscopes and a tri-axial accelerometer and a magnetic compass. Additional sensors could be
barometric or infrared altitude sensors and infrared distance sensors for indoor flight.
The IMU is represented by a three-axis gyro and a three-axis accelerometer, whereas the
magnetic compass is modelled as a separate model. Each require parameters describing the
sampling time and the noise and bias characteristics. Pseudo random noise can be added
using an external C function.
5.2. Trim routine results
The obtained non-linear models can be further used for control law design purposes, using
linearization or system identification techniques. As a first step, to find the condition in which
steady flight is achieved, a generic rotorcraft trim routine is used, based on the Jacobian
method, which uses numerical perturbation of the model in combination with a Newton–
Raphson iteration scheme [23]. For this end, the Dymola–Matlab/Simulink toolbox is used.
To this end, the control input vector , containing the four control inputs and the roll,
c
pitch and yaw angle of the system are perturbed, for a fixed flight speed, turn rate, flight path
angle and/or sideslip angle. The control inputs are the overall thrust and the torques in the
direction of the three body axes, which can be inverted to the approximate rotor speed for
each rotor. The perturbed control vector values fix the rotor speeds, velocities, Euler angles
and rotation rates, which are subsequently used in the model, from which the in-body

13. Mathematical and Computer Modelling of Dynamical Systems 253
accelerations and the side-slip angle are retrieved. With the Jacobian method, the control
vector is subsequently updated until a steady-state flight condition is reached, in which the
accelerations are 0. As an initial guess, the hover condition is used, which only requires the
thrust input, resulting in four equal rotor speeds.
Using a trim routine the steady flight condition for a fixed turn rate, flight path angle or
sideslip angle, for a range of flight speeds is determined. In Figure 10 the control inputs for a
flight speed 0–5 m/s in forward flight and in a 3 /s turn are given.
Comparing the two rotor inflow models, Figure 10 shows that by taking into account the
local flow field for each rotor, the required thrust input and rotor speeds are reduced, as the
component of the flight speed perpendicular to the rotor becomes larger, and the thrust thus
increases. As expected, the body pitch angle, which is positive nose up, decreases for
increasing flight speed, controlled with a small pitch input.
For the body states and rotation rates, as seen in Figures 11 and 12, there is no effect on
the velocities, measured in the body reference frame, and the attitude of the UAV. With the
x 10−6 x 10−6
0.9 1 0.9 1
Thrust input [N]
Thrust input [N]
Roll input [Nm]
Roll input [Nm]
0.8 0.5 0.8 0.5
0.7 0 0.7 0
0.6 −0.5 0.6 −0.5
0.5 −1 0.5 −1
0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5
x 10−7 x 10−6 x 10−7 x 10−6
6 1 6 1
Pitch input [Nm]
Basic
Pitch input [Nm]
Yaw input [Nm]
4 Inflow 0.5 4 Yaw input [Nm] 0.5
2 0 2 0
0 −0.5 0 Basic −0.5
Inflow
−2 −1 −2 −1
0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5
Airspeed, ue [m/s] Airspeed, ue [m/s] Airspeed, ue [m/s] Airspeed, ue [m/s]
(a) (b)
Figure 10. Results of trim routine, for an airspeed 0–5 m/s. Left in forward flight, right in a 3 /s turn.
(a) Control inputs in forward flight. (b) Control inputs in a turn.
1 6 4 6
Basic
Roll angle,
Roll angle,
0.5 4 3 Inflow
φ [deg]
u [m/s]
u [m/s]
4
φ [deg]
0 2
−0.5 Basic 2 1 2
Inflow
−1 0 0 0
0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5
0 1 5 1
Pitch angle,
Pitch angle,
−2 0.5 0.5
θ [deg]
0
θ [deg]
v [m/s]
v [m/s]
−4 0 0
−6 −0.5 −5 −0.5
−8 −1 −10 −1
0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5
1 0.5 1 0.5
Yaw angle,
Yaw angle,
0.5 0.5
ψ[deg]
ψ [deg]
w [m/s]
w [m/s]
0 0
0 0
−0.5 −0.5 −0.5 −0.5
−1 −1 −1 −1
0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5
Airspeed, ue [m/s] Airspeed, ue [m/s] Airspeed, ue [m/s] Airspeed, ue [m/s]
(a) (b)
Figure 11. Results of trim routine, for an airspeed 0–5 m/s. Left in forward flight, right in a 3 /s turn.
(a) Rotation angles and translational velocities in forward flight. (b) Rotation angles and translational
velocities in a turn.

14. 254 M.J. Foeken and M. Voskuijl
Roll rate, 1
Roll rate,
p [deg/s]
p [deg/s]
0.2
0 0
−0.2
−1 −0.4
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
1 0
Pitch rate,
Pitch rate,
q [deg/s]
q [deg/s]
0 −0.1
−1 −0.2
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
1
Yaw rate,
Yaw rate,
r [deg/s]
r [deg/s]
0 3
−1 2.95
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
Airspeed, ue [m/s] Airspeed, ue [m/s]
(a) (b)
Figure 12. Results of trim routine, for an airspeed 0–5 m/s. Left in forward flight, right in a 3 /s turn.
(a) Rotation rates in body-axis system in forward flight. (b) Rotation rates in body-axis system in a turn.
capability to hover, a 3 /s turn with 0 airspeed corresponds to a turn around the top axis. In
forward, level flight, when the aircraft has a small pitch angle, there is a small component of
the velocity in the body z-axis (positive downward, see Figure 7).
5.3. Discussion
The results of the trim routine are qualitatively correct. The exercise shows, however, that
there are both advantages and disadvantages in the use of Modelica as a systems modelling
language during (automated) controller design. Foremost, the analysis of the model requires
an external tool, in this case Matlab/Simulink. The routines used to trim and linearize the
quadrotor model need a set of model-specific parameters and data to run, and because not all
model states are directly accessible within Matlab/Simulink, extra ‘sensors’ are to be added
to the model.
On the other hand, in terms of modelling the system, Modelica fits in the three-layered
modelling approach of Figure 3. The object-oriented modelling paradigm enables easy
library development, and the typing and structure of the Modelica language makes it suitable
to store models as ‘static’ knowledge in a knowledge base, where it can be supplemented
with additional concepts and relationships. Such a database helps the person modelling a
system, as well as enables automation of tasks by making the library available in a computer-
readable format (i.e. XML).
6. Conclusions and future work
The increasing importance of control software in mechatronic systems requires a design
approach that addresses both simultaneous multi-disciplinary involvement as well as multi-
disciplinary architecture design. Based on this idea, a framework supporting the develop-
ment of control software for mechatronic systems was previously proposed. This article has
introduced a knowledge-based approach for generating simulation models as part of this
framework, and illustrated the need for, and advantages of such an approach by considering
the development of non-linear simulation models of a quadrotor UAV.

15. Mathematical and Computer Modelling of Dynamical Systems 255
The development of an ontology underlying the knowledge base was started at the level
of the modelling language and is extended with the concepts and relations representing the
mechatronic system components and their attributes. To be able to include the representation
of the behaviour of a component in various domains, knowledge on the applicable physics
principles is added, as well as approximation and specialization relations.
To be able to directly incorporate geometrical data, the use of a KBE modelling
environment [24] to develop the system model is considered. This environment supports
parametric CAD modelling using object-oriented programming techniques, similar to the
paradigm supported by SysML. It adds, however, the capability to derive geometric proper-
ties and process the model for finite-element analysis purposes, among others, of which the
results can be used in the Modelica model.
Acknowledgements
The authors gratefully acknowledge the support of the Dutch Innovation Oriented Research Program
‘Integrated Product Creation and Realization (IOP-IPCR)’ of the Dutch Ministry of Economic Affairs.
References
[1] J. Van Amerongen and P. Breedveld, Modeling of physical systems for the design and control of
mechatronic systems, Ann. Rev. Control 27 (2003), pp. 87–117.
[2] Silverlit Toys Manufactory Ltd., X-Ufo; available at http://www.silverlit-flyingclub.com/xufo.
htm (Accessed 6 August 2010).
[3] A.F. Link, RQ-4 Global Hawk; available at http://www.af.mil/photos/ (Accessed 6 August 2010).
[4] M. Zhou, Y. Son, and Z. Chen, Knowledge representation for conceptual simulation modeling,
Proceedings of the 2004 Winter Simulation Conference, Washington, DC, USA, 2004,
pp. 450–458.
[5] N. Milton, Knowledge Technologies, Polimetrica, Milan, Italy, 2008.
[6] G. La Rocca and M. Van Tooren, A Knowledge Based Engineering Approach to Support
Automatic Generation of FE Models in Aircraft Design, in 45th AIAA Aerospace Sciences
Meeting and Exhibit, AIAA-2007-0967, Reno, NV, 2007.
[7] A. Breunese, J. Top, J. Broenink, and J. Akkermans, Libraries of reusable models: theory and
application, Simulation 71 (1998), pp. 7–22.
[8] P. Nayak, Automated Modeling of Physical Systems, No. 1003 in Lecture Notes in Artificial
Intelligence, Springer, Heidelberg, Germany, 1995.
[9] F. Bernardi and J. Santucci, Model design using hierarchical web-based libraries, Proceedings of
the 39th Conference on Design Automation, New Orleans, LA, 2002, pp. 14–17.
[10] C. Paredis, A. Diaz-Calderon, R. Sinha, and P. Khosla, Composable models for simulation-based
design, Eng. Comput. 17 (2001), pp. 112–128.
[11] V.-C. Liang and C.J.J. Paredis, A Port Ontology for Automated Model Composition, Proceedings
of the 2003 Winter Simulation Conference, New Orleans, Louisiana, USA, December 2003,
pp. 613–622.
[12] V. D’Amelio and T. Tomiyama, Predicting the unpredictable problems in mechatronics design,
Proceedings of the International Conference on Engineering Design, Paris, France, August 2007.
[13] E. Lee and Y. Xiong, System-level types for component-based design, Lect. Notes Comput. Sci.
2211 (2001), pp. 237–253.
[14] M. Foeken, M. Voskuijl, A. Alvarez Cabrera, and M. Van Tooren, Model generation for the
verification of automatically generated mechatronic control software, IEEE/ASME International
Conference on Mechatronic and Embedded Systems and Applications, IEEE, Beijing, China,
October 2008.
[15] A. Alvarez Cabrera, M. Erden, M. Foeken, and T. Tomiyama, On high-level model integration for
mechatronic systems control design, IEEE/ASME International Conference on Mechatronic and
Embedded Systems and Applications, IEEE, Beijing, China, October 2008.

16. 256 M.J. Foeken and M. Voskuijl
[16] W. Johnson and J. Sinsay, Rotorcraft conceptual design environment, Proceedings of the 3rd
International Basic Research Conference on Rotorcraft Technology, Nanjing, China, October
2009.
[17] Object Management Group, OMG SysML; software available at http://www.omgsysml.org/
(Accessed 6 August 2010).
[18] K. Forbus, Qualitative process theory, Artif. Intell. 24 (1984), pp. 85–168.
[19] M. Yoshioka, Y. Umeda, H. Takeda, Y. Shimomura, Y. Nomaguchi, and T. Tomiyama, Physical
concept ontology for the knowledge intensive engineering framework, Adv. Eng. Inform. (2007),
pp. 95–113.
[20] Epistemics, PCPack; software available at http://www.epistemics.co.uk (Accessed 6 August
2010).
[21] S. Bouabdallah and R. Siegwart, 2007, Design and control of a miniature quadrotor. Advances in
Unmanned Aerial Vehicles, Springer, The Netherlands, pp. 171–210.
[22] W. Johnson, Helicopter Theory, Courier Dover Publications, New York, NY, USA, 1994.
[23] M. Dreier, Introduction to Helicopter and Tiltrotor Flight Simulation, AIAA Education Series,
Reston, VA, USA, 2007.
[24] Genworks International, GDL; software available at http://www.genworks.com (Accessed 6
August 2010).

17. Copyright of Mathematical Computer Modelling of Dynamical Systems is the property of Taylor Francis
Ltd and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright
holder's express written permission. However, users may print, download, or email articles for individual use.