Knowledge-based simulation model generation for control law designapplied 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 softwaredevelopment framework, this article discusses the development of a simulation modelgeneration method. As a basis, the application of knowledge-based engineering (KBE) issuggested, requiring the definition of an ontology to capture the various domain conceptsand relationships. The initial knowledge base represents concepts and relations to createmodels with Modelica, the object-oriented modelling language used to construct thesimulation model. The need for physics-based, high-fidelity simulation models using thelatest design parameters is illustrated by investigating the model of a quadrotor UAV. Theresults show that the obtained model can form the basis for control design and that theapproach provides means to integrate the dynamics analysis and control design into amodelling framework using a combination of object-oriented component modelling andKBE principles.
According to Van Amerongen, ‘mechatronic design deals with the integrated design of amechanical system and its embedded control system’ [1]. With the advances in computingcapabilities, the role of the embedded control system in the mechatronic system design isbecoming more and more prominent. The ‘traditional’ sequential design approach, in whichmechanical, electrical, electronics and software components are designed and optimizedsequentially, 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. Apartfrom passenger jets, using software with millions of lines of code, and modern fighter jetsthat require computers to be able to fly in the first place, software has enabled the use ofunmanned aerial vehicles (UAVs). UAVs come in a range of sizes, forms and purposes, fromthe fixed-wing Global Hawk, with a wingspan of 35 m and with a primary focus on militarysurveillance and intelligence gathering, to the X-Ufo quadrotor, a remotely controlled toy of50 cm wide weighing less than 350 g [2] (Figure 1). However, all UAVs share thecharacteristic that flight is either remotely controlled by a pilot on the ground, or performedautonomously. In the first case the pilot uses the signals from on-board visual sensors to fly
Mathematical and Computer Modelling of Dynamical SystemsVol. 16, No. 3, June 2010, 241–256
the aircraft. In the second case, a combination of visual, inertial and positioning sensors isused to guide the aircraft along its predefined path, in the mean time performing additionaltasks when required. Autonomous flight is obtained by a combination of control softwareacting like an auto-pilot, and ‘external input’ that defines the flight profile and the tasks to beperformed during the mission.
As controller design can often not be performed without a suitable dynamic model of theaircraft, these models should be available from early on in the design process. Using controltheory, the control algorithms are subsequently developed and implemented as software. Totest and verify the control software, a mix of hardware- and software-based test setups can beapplied, ranging from full software-based simulations to prototype hardware tests. Acommon practice in aircraft design is the use of ‘Iron birds’, which combine the real aircraftsystems 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. Dueto the large amount of systems, it is not possible to model and simulate the behaviour of all ofthem, 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 frameworkfor mechatronic systems, with a focus on control software. To test the method, it is applied toa quadrotor UAV model, which is subsequently used for further analysis.
In Section 3, the performed research project and its relation to a control software designframework will be introduced, followed by an overview of related research. Section 4discusses the simulation model generation process. In Section 5, the model for the quadrotorUAV 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 modelsfocuses on various subjects. The application of knowledge engineering for the developmentof 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 byMilton [5]. Here, a KBS is defined as being a ‘computer program that uses Artificial
(a) (b)
Figure 1. Examples of unmanned aerial vehicles. (a) Northrop Grumman RQ-4 Global Hawk [3].(b) Silverlit X-Ufo [2].
242 M.J. Foeken and M. Voskuijl
Intelligence techniques to solve complex problems that would normally be solved by aperson with specific expertise’. The use of expert knowledge in engineering applicationsenables 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 togenerate finite element models for structural analysis using a dedicated KBE modelling anddevelopment 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, andargue that there is a need for a taxonomy of component classes to handle the complexityassociated 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 organizationof modelling elements in terms of assumption classes, which group elements based on thesame physical principles, and approximation relationships [8], indicating if an elementprovides a simplified description of another element. The resulting library is tangled aswell. To enable component reuse, the application of web-based hierarchical libraries isintroduced by Bernardi and Santucci [9]. In this case, the hierarchy is based only onabstraction 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 bemaintained. The interaction between objects is port-based, and connected they representboth 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 arepossibly built up from other sub-models. On the contrary, the method of Nayak [8] is basedon equation fragments describing the behaviour of an element and to create the model of acomplete system the equations are combined in a single system. This requires a consistentnaming of constants and variables throughout the entire library. With a port-based approachthis 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 automaticmodel 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. Thisprinciple 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 frameworkto capture the interaction in component-based design is presented by Lee and Xiong [13]. Toprevent connecting incompatible components, the interaction type is checked, which is a taskthat 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 natureof mechatronic systems, an automatic control software generation framework has beenproposed previously [14,15]. Depicted in Figure 2, the framework contains a combinationof 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. Thedesign process as represented by the work flow diagram in Figure 2 starts with a functionmodel, representing the intention of the designer, and subsequently a system model is builtup from mechatronic components. Further requirement and system decomposition results in
Mathematical and Computer Modelling of Dynamical Systems 243
Integration framework
Functional
model
Function modeling (modes, communication, user interaction)
Mechanical
embodiment design
Function model
Qualitative
behaviour
generation
Mechatronics feature-
based product definitionQualitative
behaviours
Mechatronics
feature modeling
Quantitative
behaviour generationController design
Control software
Control code
generation
Control model
generation
Controller model
and prototype
Mechanical CAD
model and prototype
Software level
verification
Hardware and machine
level verification
Quantitative
behaviour
Control model
Figure 2. Architecture of the integration framework. The white blocks represent tools to be furtherdeveloped. Dashed-line blocks correspond to existing commercial software tools.
244 M.J. Foeken and M. Voskuijl
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 issynthesized. To verify the obtained control software, the system model is used to generatesuitable simulation and verification models. Once implemented in software, the backbonealso 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 ‘modellingelement’ or ‘fragment’ to a part of the model of the system.
Labelled as ‘Control Model Generation’ in Figure 2, part of the supported developmentprocess consists of creating models used for control algorithm and control software designand verification. Often referred to as plant or simulation models, these can come in the formof system dynamics models or finite-element models. Although an integrated finite elementsimulation, taking into account structural, aerodynamic and electrical physical phenomenamight 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, thesedifferent types of simulations can be used in a sequential order. For example lift, drag andmoment coefficients and stability derivatives determined by using computational fluiddynamics (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 oftenrequired, where fidelity is defined as accuracy. The highest fidelity is reached when theuncertainty 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 isrelated to. For the initial implementation, the Systems Modelling Language (SysML) hasbeen proposed [14]. SysML is an extension of UML, with a focus on systems engineeringapplications, providing means to model and analyse (non-software) systems [17]. Thelanguage specification describes diagrams and elements to model requirements, functions,use cases, system decomposition and hierarchy, among others, based on the object-orientedprogramming paradigm. Being a visual language, SysML provides a transparent way todevelop and give an overview of both the function decomposition and the systemsarchitecture.
With the possibility to store the obtained models in an XML-based format in which theobject-oriented structure of the model is retained, the models can be processed with customtools based on generic XML processing methods to transform them into other models, whileusing the associated model or analysis data.
4. Control model generation
In the framework, the multi-disciplinary system architecture is built up from mechatronicsystem components, as introduced in the previous section. However, in control design thesystem is often represented as a set of (linear) transfer functions, either in the time or in thefrequency domain. The link between the parameters in this representation and those of thephysical 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 thesecan 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 physicalsystems and is based on differential and algebraic equations. It supports non-causal andobject-oriented modelling techniques, and as such stimulates the reuse of modelling
Mathematical and Computer Modelling of Dynamical Systems 245
knowledge. In contrast to the use of transfer functions, with this ‘physical modelling’paradigm a component-based model corresponding to physical elements, using parametersdirectly related to the real world, can be obtained. These parameters can then be obtained viathe integration framework, which binds the model data and analysis results directly to thesystem components. As often control design relies on linear models at certain designconditions, the obtained non-linear model must be linearized.
The relation between elements on system component, control and mathematical modelcan be represented as in Figure 3, adapted from Ref. [7]. Although a direct, one-to-onemapping from system component to modelling element is relatively straightforward, thiskind of mapping ignores the possible interaction occurring in or between elements ofdifferent domains. As a single system component can show behaviour in different physicsdomains, for example, the mechanical and aerodynamic domain, a combination of elementswill be required to obtain the correct interaction. For example, the main functionality of aDC-motor is to act as a torque generator. However, when attached to a rotor it will also serveas 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, therelative vertical position of the rotors with respect to the overall centre of gravity has a strongeffect 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 technicalcomponents.
(2) These components must have one or multiple representations in the physicalmodelling world, see Figure 3.
ComponentMechatronic
system
Physical
description
Modelica
element
Equation
1
1..*
1 1..*
1 1..*
1
1..*
Physical
component
classes
1 1..*
System model
Control model
Mathematics
Figure 3. Relationships between components and elements at different viewpoints.
246 M.J. Foeken and M. Voskuijl
(3) When connecting elements, the port compatibility must be checked to prevent thecoupling of incompatible elements.
(4) Not only the intended behaviour, but also ‘secondary’ or ‘unintended’ behaviourmust be recognized and included.
To handle the fourth requirement, the interfaces of the component should not be fixed to themain 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 betweendomains.
The solution presented in Ref. [12] links physical phenomena, for example, gravity orthermal radiation, to components in a library. When the system is built up by instantiatingthese components, a qualitative reasoner reasons out all possible behaviour [18]. In combi-nation with a model representing the intended behaviour, the unpredictable interactions arediscovered. The knowledge base containing the model elements, physical phenomena andrelated concepts is implemented in the Knowledge Intensive Engineering Framework(KIEF) [19]. In general, a knowledge base is built up from concepts, attributes of theseconcepts, values, and the relationships between concepts. Most knowledge bases can berepresented as a diagram in which concepts are connected through relations, see Figure 5, orby 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 usingphysical phenomena linked to system components can be extended to quantitative simula-tion model elements linked to these components. Whether a certain subelement is requiredfor a certain system depends then on, for example, the relative position in case of heatradiation, 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.
Mathematical and Computer Modelling of Dynamical Systems 247
depend on the system’s implementation. By categorizing the components, for example, asproposed by Breunese et al. [7], such that for each technical component all associatedphysics domains are known, a reasoner can determine which related modelling elementsare required, based on geometric data.
4.2. Knowledge base development
The creation of a knowledge base containing the systems components and relations startswith the identification of the applicable concepts and their relationships. Such an ontologydefines what concepts can be found in the domain, and what kind of relations between theseconcepts exist. The three levels indicated in Figure 3 each form a domain by itself for which aseparate 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 generationprocess, 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 andconceptual knowledge. The former is related to expertise on performing tasks, whereas thelatter is related to expertise on concepts and the relationship between these concepts [5].
Based on theModelica language specification, the concepts and relations in the ontologyare restricted such that only ‘structurally’ correct models can be created with it. In general, aModelica 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 classinstances, equations and connections and algorithms. Similar to bond graphs, the connectionbetween physical components have the dimension of energy or power, whereas the input toactuators and the output of sensors is a data stream.
Based on the ontology, a database containing Modelica libraries is created, providing aninsight 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 classattributes 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
Quad Rotor.Controllers
Quad Rotor.Drives
Quad Rotor.Environment
Quad Rotor.Rotors
Quad Rotor.Rotors.partial Rotor
Quad Rotor.Rotors.partial Rotor J
Quad Rotor.Rotors.partial Rotor omega
Quad Rotor.Rotors.partial Rotor frame_b
Quad Rotor.Rotors.partial Rotor flange_a
Quad Rotor.Rotors.partial Rotor force And Torque
Quad Rotor.Rotors.partial Rotor inertia
connect (force And Torque.frame_b, frame_b)
connect (intertia.flange_a, flange_a)
Quad Rotor.Rotors.Simple Rotor
Quad Rotor.Rotors.Density Rotor
Quad Rotor.Rotors.Inflow Rotor
Quad Rotor.Sensors
Quad Rotor.Utilities
Quad Rotor.Body
Quad Rotor.Quad Rotor Assembly
Figure 5. Quadrotor modelling elements library as part of knowledge base.
248 M.J. Foeken and M. Voskuijl
the taxonomy of the library, but provides no additional information about the relationbetween components.
Due to the nature of the Modelica language, a class specialization hierarchy based ononly class inheritance relations is not possible, as the variability of parameters might changein 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 specializationand approximation relations between classes, something that is easily managed in theknowledge base. Similarly, the classes are grouped by their applicable physics principles,giving both insight into the underlying assumptions and indicating to which domain theconnected model fragments should belong [8].
Whereas the ontology should be applicable to mechatronic systems in general, theknowledge base will be system or application domain specific, as the type of componentsand their various representations can vary significantly between engineering domains.
4.3. Tool implementation
Although the knowledge base contains a categorization of both the Modelica modellingelements and the system components, to be able to use this database an additional tool isrequired, which incorporates the process knowledge related to the actual creation andtransformation 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 isaccessed to find the associated modelling fragments in the involved physics domains. Tobe able to construct the final Modelica model, the required model parameters should beavailable. Either in the architecture model itself, or otherwise accessible through the designframework which uses the same architecture model as a backbone to exchange data. Thelatter is however not implemented at this point, but is part of ongoing research.
Subsequently, the associated model elements are retrieved from the knowledge base andthe 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, therequired model parameters are determined and the associated values are added, based onmatching parameter names.
In Section 6, we discuss the possibility of replacing part of the SysML-based architectureand function model with a ‘product model’ developed on a dedicated KBE platform, whichhas 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. Asthe four actuators are used both for propulsion and control purposes, and there are no othermoving components, the dynamics are mainly determined by these rotor actuators, thesupportive structure and the aerodynamics of these. The type and quality of the sensorsstrongly 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 fromthe following components:
Mathematical and Computer Modelling of Dynamical Systems 249
� environmental effects, that is, gravity and aerodynamics� body with mass, inertia and area� four actuators consisting of a DCmotor, 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 beentaken 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 gyroscopiceffects have a large influence on the dynamics of the system. Furthermore, the effect ofaerodynamic drag on the body cannot be discarded despite the low flight speeds. Adescription of an accurate simulation model used for testing and validation purposes in theMatlab/Simulink environment is given by Bouabdallah and Siegwart [21].
In the generated model, the body of the quadrotor is assumed to consist of a singlebodyShape to which the rotors are attached at a fixed distance of the centre of gravity. Theaerodynamic forces acting on the body are modelled in a separate submodel, for which thelocal air density is calculated by a separate function. The data used for this example is basedon the quadrotor design used in Ref. [14]. The composition of the rotor actuator assembly isgiven in Figure 6.
The rotor models in the library are all based on a single partial rotor model containing theconnectors and the inertia elements, which is extended with various methods to calculate therotor forces and moments. To balance the torque around the top axis, two clockwise and twocounterclockwise rotating actuators are needed. Figure 7 gives a schematic overview of thesystem.
The simplest way to calculate the thrust and torque of a single rotor is given inEquation 1, only taking into account a variable rotor speed Ω. The constants b and d arethe thrust and torque constants, respectively, determined by experiment or by CFD analysis.
Figure 6. Actuator assembly on quadrotor UAV. (a) Actuator assembly components. (b) Modelicamodel of actuator assembly.
250 M.J. Foeken and M. Voskuijl
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 usethe local airspeed and flow directions to calculate the 3D forces and moments at the rotorhub. 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]:
CT ¼ σa4þ 6μ2
24θ0 � 1þ μ2
8θtw � 1
4λ
� �(2a)
CQ ¼ σa1þ μ2
8aCd þ λ
1
6θ0 � 1
8θtw � 1
4λ
� �� �(2b)
Figure 8 visualizes the required angles and velocities. The solidity σ is a measure for whatpart of the rotor disc is covered by the rotor blades, and θ0 and θtw are the root pitch angle andthe blade twist angle, respectively. a is the derivative of the lift coefficient CLwith respect tothe blade’s angle of attack α. Similarly, the force and moment coefficients in the local x and ydirection are determined. The rotor force and moments then become:
F ¼ ρAΩ2R2 ChX ChY CT½ �T (3a)
Q ¼ ρAΩ2R3 CrX CrY CQ
� �T(3b)
where ρ is the local air density calculated by a separate function, A the area of the rotor disk andR the rotor radius. To take into account ground effects, which increase the efficiency of the
Xb
Yb
Zb
V
Xe
Ye
Ze
Ω4
Ω3
T4
T3
Ω2
Ω1
T1
T2
Figure 7. Schematic of quadrotor UAV.
θ0 αloc al
U
blade root
blade tip
(a)
αdisk
T
V cos α
V sin α
v
Rotor disk plane
V
μ = V cos α / ΩR
λ = (V sin α + v) / ΩR
(b)
θ0
θtw
Figure 8. Angles and velocities of rotor [22]. (a) Rotor blade orientation. (b) Rotor disk velocity andorientation.
Mathematical and Computer Modelling of Dynamical Systems 251
rotor when the distance between the rotor and the ground plane is less than 2R, the thrust can bedivided by a factor 1� R2
16h2 . Although the interaction between the rotors at low altitudes mighthave 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 elementmethod, applies a discretization to the rotor blades, and calculates the forces andmoments oneach blade segment based on the local flow field. This, however, increases the computationtime significantly, and is therefore not considered in this article.
Although on system component level the input to the actuators and the output of sensorswill be an electrical current, using either an analogue or digital signal, the model represents thisas a stream of data which can directly be used for control purposes, see Figure 9. The sensorpackage used in the example consists of an inertial measurement unit (IMU), containing threegyroscopes and a tri-axial accelerometer and a magnetic compass. Additional sensors could bebarometric 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 themagnetic compass is modelled as a separate model. Each require parameters describing thesampling time and the noise and bias characteristics. Pseudo random noise can be addedusing an external C function.
5.2. Trim routine results
The obtained non-linear models can be further used for control law design purposes, usinglinearization or system identification techniques. As a first step, to find the condition in whichsteady flight is achieved, a generic rotorcraft trim routine is used, based on the Jacobianmethod, 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 �c, containing the four control inputs and the roll,pitch and yaw angle of the system are perturbed, for a fixed flight speed, turn rate, flight pathangle and/or sideslip angle. The control inputs are the overall thrust and the torques in thedirection of the three body axes, which can be inverted to the approximate rotor speed foreach rotor. The perturbed control vector values fix the rotor speeds, velocities, Euler anglesand rotation rates, which are subsequently used in the model, from which the in-body
SensorPackage]QuadRotor]metsyS[ibd [
<<subsystem>> : ElectronicsSub [1]
<<subsystem>> : SensorSub [1]
<<block>> : Compass [1]
: I2CData
<<block>> : IMU [1]
: AnalogData
<<block>> : VoltageRegulator [3 ]
: ElectricalPower
: ElectricalPower
<<block>> : Battery [1]
<<block>> : Body [1]
: MechEnergy
(a) (b)
acc
magneto
gyro
Data streamsIMU components
Compass
Mechanical connectors
Figure 9. Sensor package on quadrotor UAV. (a) Sensor assembly on system component level.(b) Modelica model of sensor assembly.
252 M.J. Foeken and M. Voskuijl
accelerations and the side-slip angle are retrieved. With the Jacobian method, the controlvector is subsequently updated until a steady-state flight condition is reached, in which theaccelerations are 0. As an initial guess, the hover condition is used, which only requires thethrust input, resulting in four equal rotor speeds.
Using a trim routine the steady flight condition for a fixed turn rate, flight path angle orsideslip angle, for a range of flight speeds is determined. In Figure 10 the control inputs for aflight 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 thelocal flow field for each rotor, the required thrust input and rotor speeds are reduced, as thecomponent of the flight speed perpendicular to the rotor becomes larger, and the thrust thusincreases. As expected, the body pitch angle, which is positive nose up, decreases forincreasing 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 onthe velocities, measured in the body reference frame, and the attitude of the UAV. With the
0 1 2 3 4 50.5
0.6
0.7
0.8
0.9
Th
rust in
pu
t [N
]
0 1 2 3 4 5−1
−0.5
0
0.5
1x 10−6
Ro
ll in
pu
t [N
m]
0 1 2 3 4 5−2
0
2
4
6
Pitch
in
pu
t [N
m]
Airspeed, ue [m/s]
BasicInflow
0 1 2 3 4 5−1
−0.5
0
0.5
1
Ya
w in
pu
t [N
m]
Airspeed, ue [m/s]
(a)
0 1 2 3 4 50.5
0.6
0.7
0.8
0.9
Th
rust in
pu
t [N
]
0 1 2 3 4 5−1
−0.5
0
0.5
1
Ro
ll in
pu
t [N
m]
−2
0
2
4
6
Pitch
in
pu
t [N
m]
BasicInflow
−1
−0.5
0
0.5
1
Ya
w in
pu
t [N
m]
(b)
x 10−6x 10−7
0 1 2 3 4 5
Airspeed, ue [m/s]
0 1 2 3 4 5
Airspeed, ue [m/s]
x 10−7 x 10−6
x 10−6
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.
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 translationalvelocities in a turn.
Mathematical and Computer Modelling of Dynamical Systems 253
capability to hover, a 3�/s turn with 0 airspeed corresponds to a turn around the top axis. Inforward, level flight, when the aircraft has a small pitch angle, there is a small component ofthe 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, thatthere are both advantages and disadvantages in the use of Modelica as a systems modellinglanguage during (automated) controller design. Foremost, the analysis of the model requiresan external tool, in this case Matlab/Simulink. The routines used to trim and linearize thequadrotor model need a set of model-specific parameters and data to run, and because not allmodel states are directly accessible within Matlab/Simulink, extra ‘sensors’ are to be addedto the model.
On the other hand, in terms of modelling the system, Modelica fits in the three-layeredmodelling approach of Figure 3. The object-oriented modelling paradigm enables easylibrary development, and the typing and structure of the Modelica language makes it suitableto store models as ‘static’ knowledge in a knowledge base, where it can be supplementedwith additional concepts and relationships. Such a database helps the person modelling asystem, 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 designapproach 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 hasintroduced a knowledge-based approach for generating simulation models as part of thisframework, and illustrated the need for, and advantages of such an approach by consideringthe development of non-linear simulation models of a quadrotor UAV.
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5−1
0
1R
oll
rate
,
p [
de
g/s
]
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5−1
0
1
Pitch
ra
te,
q [
de
g/s
]
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5−1
0
1
Ya
w r
ate
,
r [d
eg
/s]
Airspeed, ue [m/s]
(a)
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5−0.4
−0.2
0
0.2
Ro
ll ra
te,
p [
de
g/s
]
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5−0.2
−0.1
0
Pitch
ra
te,
q [
de
g/s
]
2.95
3
Ya
w r
ate
,
r [d
eg
/s]
(b)Airspeed, ue [m/s]
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
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.
254 M.J. Foeken and M. Voskuijl
The development of an ontology underlying the knowledge base was started at the levelof the modelling language and is extended with the concepts and relations representing themechatronic system components and their attributes. To be able to include the representationof the behaviour of a component in various domains, knowledge on the applicable physicsprinciples is added, as well as approximation and specialization relations.
To be able to directly incorporate geometrical data, the use of a KBE modellingenvironment [24] to develop the system model is considered. This environment supportsparametric CAD modelling using object-oriented programming techniques, similar to theparadigm 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 theresults can be used in the Modelica model.
AcknowledgementsThe 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 SciencesMeeting and Exhibit, AIAA-2007-0967, Reno, NV, 2007.
[7] A. Breunese, J. Top, J. Broenink, and J. Akkermans, Libraries of reusable models: theory andapplication, Simulation 71 (1998), pp. 7–22.
[8] P. Nayak, Automated Modeling of Physical Systems, No. 1003 in Lecture Notes in ArtificialIntelligence, Springer, Heidelberg, Germany, 1995.
[9] F. Bernardi and J. Santucci,Model design using hierarchical web-based libraries, Proceedings ofthe 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-baseddesign, Eng. Comput. 17 (2001), pp. 112–128.
[11] V.-C. Liang and C.J.J. Paredis, A Port Ontology for Automated Model Composition, Proceedingsof 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 theverification of automatically generated mechatronic control software, IEEE/ASME InternationalConference 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 formechatronic systems control design, IEEE/ASME International Conference on Mechatronic andEmbedded Systems and Applications, IEEE, Beijing, China, October 2008.
Mathematical and Computer Modelling of Dynamical Systems 255
[16] W. Johnson and J. Sinsay, Rotorcraft conceptual design environment, Proceedings of the 3rdInternational Basic Research Conference on Rotorcraft Technology, Nanjing, China, October2009.
[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 August2010).
[21] S. Bouabdallah and R. Siegwart, 2007,Design and control of a miniature quadrotor. Advances inUnmanned 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).
256 M.J. Foeken and M. Voskuijl
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.
