AIAA Modeling and Simulation Technologies Conference and Exhibit AIAA 2007-6616

20 - 23 August 2007, Hilton Head, South Carolina

Development of a Modular, Generic Helicopter Flight

Dynamics Model for Real-Time Simulations

W. R. M. Van Hoydonck∗ and M. D. Pavel†

Delft University of Technology, P.O. Box 5058, 2600 GB Delft, The Netherlands

The purpose of this paper is to present an ongoing effort to develop a helicopter flight
dynamics model (called Helix) that has sufficient detail to model helicopters with semi-
rigid or articulated rotors in any configuration, while still being fast enough so that it
can run in real-time on a single desktop computer. The flight dynamics model is based
on a previous in-house model, but this is modified to such an extend that it allows us to
simulate all helicopter configurations. A blade element approach is utilized for the blade
aerodynamics and for the rotor inflow model, both Pitt-Peters and Peters-He dynamic
inflow models are available. For real-time and off-line simulations, DUECAa and Simulink
are utilized. Due to the extensive use of both in-house and open-source software, it is a
cost effective and flexible solution for visualization, feedback control design, flight dynamics
model development and handling qualities research in an academic environment.

Nomenclature

R Turn radius in trim √

V Total linear velocity (= u2 + v 2 + w2 )
α Fuselage angle of attack
β Fuselage angle of sideslip
β0 Rotor coning angle (non-rotating frame)
β1c Rotor longitudinal tilt angle (non-rotating frame)
β1s Rotor lateral tilt angle (non-rotating frame)
γ Flight path angle
Θ Fuselage pitch angle
θcoll Pilot collective pitch control
θlat Pilot lateral cyclic control
θlong Pilot longitudinal cyclic control
θpedal Pilot pedal control
λ0 Uniform inflow component
λ1c Longitudinal inflow component
λ1s Lateral inflow component
µ Aerodynamic angle of roll
τ Inflow time constant
Φ Fuselage roll angle
Ψ Fuselage heading angle p
Ω Complete angular velocity (= p2 + q 2 + r2 )

∗ Ph.D. Student, Design, Integration and Operations of Aircraft and Rotorcraft, Faculty of Aerospace Engineering.
† Assistant Professor, Design, Integration and Operations of Aircraft and Rotorcraft, Faculty of Aerospace Engineering.
a Delft University Environment for Control and Activation

1 of 18

American
Copyright © 2007 by Van Hoydonck & Pavel. Published by the American Institute of Aeronautics
Institute of Aeronautics and Astronautics
and Astronautics, Inc., with permission.
 I. Introduction
At the Delft University of Technology, the SIMONA simulator1 became operational five years ago. It
was designed as a general purpose research simulator suitable for different types and categories of fixed wing
aircraft and helicopters. In the early stages of its planning and development, an effort was underway at the
chair of Dynamics and Control of Aerospace Vehicles to develop a high fidelity helicopter flight dynamics
model for real-time simulation purposes.2 More recently, the incentive behind helicopter flight dynamics
simulation has changed towards using (unmanned) helicopters as a subject to explore and develop new control
theories and concepts.3 Due to its widely varying stability characteristics throughout the flight envelope,
helicopters are an ideal subject for that purpose. In contrast, the chair of Design, Integration and Operations
of Aircraft and Rotorcraft has focused more on fundamental research into helicopter aerodynamics4 and flight
dynamics.5 Over the years, this has resulted in several flight dynamics models of varying fidelity, mainly
aimed at off-line simulations.
An area of research where all of these topics play an equilly important role are helicopter handling
qualities investigations. For this, it is of utmost importance to utilize a flight dynamics model that on the
one hand has a sufficient level of detail and on the other hand, runs fast enough to allow for real-time
execution. For articulated helicopters, the rotor dynamics are well separated from the fuselage dynamics,
and handling qualities investigations can be done with realtively simple flight dynamics models. However,
for hingless and bearingless rotor designs, there are significant differences in responses and handling qualities
characteristics when a model is upgraded to include body-rotor couplings.6
Over the years, a number of comprehensive helicopter flight dynamics codes have been developed capable
of predicting the helicopter behaviour in different situations (see Kunz7 for a good overview). However, little
attention has been paid to creating a flexible solution needed for real-time simulation. The core requirements
for the helicopter flight dynamics model that is presented in this paper are listed below:
• ability to simulate different helicopters configurations without the need to change the code;
• stand-alone offline execution for trim and stability analyses;
• interface with DUECA for real-time simulation;
• interface with Simulink for controller design;
• low cost and ability to run on commodity hardware.
There are multiple ways to add flexibility to a flight dynamics model. One way to achieve flexibility is to
divide a mathematical model in modules that are linked together throught data-flows. This concept allows
easy restructuring of the simulation so that various modules can be interchanged, thus altering for instance
the detail of part of the simulation.8 A disadvantage of this particular approach is that a graphical tool like
Simulink is required to compose the flight dynamics model from its various modules.
Another way to add flexibility to a flight dynamics model is the path taken by the open-source flight
dynamics model JSBSim.9 Here, a generic, completely data-driven flight dynamics model framework is used
that allows aircraft configurations to be specified in data files. This way, no new program code is needed to
model an arbitrary configuration. This approach is used in the helicopter flight dynamics model described
in this paper.
In the following sections, some background will be given on the architecture of Helix, where the main
focus will be on data storage. Then, the simulation environment will be discussed, after which the analysis
and visualization capabilities in Helix are highlighted.

II. Architecture
In this section, an overview is given of the architecture of the flight dynamics model. Since the key
concept is data storage, first the file format that was chosen to store the helicopter configurations will be
discussed. The program is written in Fortran 90/95, some programming concepts introduced in this language
are highlighted.

II.A. Data Storage

Before programming started on the core of the flight dynamics model, some requirements were identified for
the file format that would contains the helicopter configuration data. These are listed below:

2 of 18

American Institute of Aeronautics and Astronautics

structure The input file format should reflect the hierarchical structure as it is stored in-memory during
simulations.
comments It should be possible to freely add comments between the data.
encoding The data should be stored in a human-readable format, editable with a simple text editor.
interoperability The format should not be tied to a particular operating system or software vendor.
A file format that satisfies all of the above requirements is the Extensible Markup Language XML.10 Once
the format was chosen, an XML-parser had to be found (or written from scratch). Since the flight dynamics
model is coded in Fortran, the easiest would be a parser written entirely in Fortran. After a search, the
following three Fortran 90/95 parsers were found on the web:
xml-fortran Author: Arjen Markus11
XML Author: Mart Rentmeester12
xmlf90 Authors: Alberto Garcia and Jon Wakelin13
The three parsers were evaluated and xmlf90 was selected. This was based on the fact that seemed like
the most mature parser, with fairly complete SAX and DOM interfaces and an extensive set of examples
and documentation. At the time of writing, a fourth XML-parser (FoX, a fork of xmlf90) has emerged that
is under active development.14 In the future, a switch might be made to this parser, since the xml-parser by
Garcia and Wakelin is not developed any further.
Initially, the SAX (Simple API for XML) interface of xmlf90 was used, but due to its inefficiency (the xml
file had to be parsed twice, first to determine the configuration so that an appropriate amount of memory
could be allocated and a second time to populate the newly allocated data structures) a switch was made to
the more flexible DOM (Document Object Model) interface. With the DOM method, an XML file is parsed
as a whole, while retaining the structure of the file in memory. Once the file is parsed completely, it is easy
to search for nodes with a certain name and allocate the appropriate amount of memory for the variable or
derived type that will hold the data below that node.

II.B. Relation with other XML-based Flight-Dynamics Model File Formats

There is an XML-standard in development for the interchange of aerospace vehicle flight dynamics models
(DAVE-ML, Dynamic Aerospace Vehicle Exchange Markup Language), jointly developed by NASA and the
Modeling and Simulation Technical Committee of the AIAA. Its primary intent is to significantly expedite
the process of “rehosting” a simulation model from one facility to another.15 At present, only one major
element of DAVE-ML has been defined: the function definition element, or DAVEfunc, used to describe
static models such as aerodynamic and and inertia models. One of the mandatory elements in DAVEfunc is
the <fileHeader>-element, containing information about the source of the data that is stored in the XML
file. This element is also used in Helix, an example is given below:
<fileHeader>
<author> Wim Van Hoydonck </author>
<fileCreationDate date="2006-12-15" />
<fileVersion> $Rev: 400 $ </fileVersion>
<description> Models the SA-330 Puma Helicopter </description>
<reference
refID="REF01"
author="Gareth D. Padfield"
title="Helicopter Flight Dynamics"
accession="0-632-05607-X"
date="1996-01-01" />
</fileHeader>

There is however a fundamental difference in the purpose of DAVE-ML’s use of XML and Helix’ use of
XML. The main use of DAVE-ML is to facilitate the exchange of flight dynamics models between simulation
facilities, where the actual code to run the model is generated from the XML-file (e.g. DAVEtools16 ). Helix
on the other hand, directly uses the XML file as input, without an intermediate step that converts the

3 of 18

American Institute of Aeronautics and Astronautics

data to simulation code. The flight dynamics model does not contain specific parts that tie it to a specific
architecture or simulator, it is portable to any computer system that contains a modern Fortran compiler.
The purpose of using XML in Helix is exactly the same as with JSBSim9 and as much as possible, the
same sections are used. This was however not possible for the most important section, the rotor. The
differences are mainly due to the different modelling approach used in JSBSim and Helix, where the former
uses the coefficient build-up method, whereas the latter mainly uses a blade element approach or strip theory
to calculate forces and moments. In the following section, some more detail is given about the structure of
the XML format used in Helix.

II.C. XML Data File Structure

To make it clear that the XML format used is not compatible with JSBSim (but comparable), a different
top-level tag is used that holds all data. This is the <hfdm_config>-element (helicopter flight dynamics
model configuration) as opposed to JSBSim’s <fdm_config>-element. A complete example for the SA-330
Puma helicopter is given in Appendix A.
Then, there are six subelements, shown below. The first one contains the file header and was discussed
in the previous section. The other sections will be elaborated on below, differences and similarities with
JSBSim’s format will be highlighted.

<hfdm_config>
<fileHeader>
...
</fileHeader
<mass_balance>
...
</mass_balance>
<metrics>
...
</metrics>
<ground_reactions>
...
</ground_reactions>
<propulsion>
...
</propulsion>
<aero_surfaces>
...
</aero_surfaces>
</hfdm_config>

mass balance The <mass_balance>-element contains data about the mass and inertia distribution of
the complete aircraft defined by an intertia matrix and a mass value. In addition, it is possible to add
pointmasses by means of a <location>- and a <mass>-element to model extra cargo or pilots/passengers.
There is one difference with JSBSim regarding the <location>-element that is worth mentioning. In JSBSim,
the location elements are all defined in the same axis system. This is not the case in Helix, where more
flexibility is needed.

metrics In JSBSim, the metrics section contains data about the positions, areas and arms of the different
aerodynamic surfaces, such as the wing chord, wing span and wing area. Furthermore it contains the
coordinates of the pilot eyepoint location. In Helix, the metics section contains the eyepoint location and the
expected ranges of the four pilot control input values. At the moment, these range limits are only enforced
during real-time simulation.

ground reactions The ground reactions element contains a contact element for every landing gear strut.
It is similar to the contact element in JSBSim, with the exception that the data related to the strut is kept
separate from the tire data. At the time of writing, ground reactions have not been modeled.

4 of 18

American Institute of Aeronautics and Astronautics

propulsion This element is the most important of all elements, since it contains all data related to
the (main) rotor and tail rotor models. The rotor-element has five attributes, of which the three most
important are its name, its rotational direction and the number of blades. This element has six sub elements,
the swash plate phase angle element, the control mixing element (to be discussed below), a nom rot speed
element, a radius element, three location elements that define the position of the rotor hub and a blade
element. This last one has two subelements, a structural and an aerodynamic element. Next to the rotor-
element, there is a tail rotor element that stores the configuration of an actuator disc model. In the future,
the propulsion element will also contain engine configurations.

aero surfaces At the moment, the aero surfaces element contains definitions about the geometry and
aerodynamic properties of the stabilizers and fuselages. The main difference with the definitions in the
propulsion elements is that the stabilizers and fuselage are stateless. There is no difference between a
horizontal or vertical stabilizer, they are defined by a translation that fixes the root chord with respect
to the body-fixed frame of reference. Then, a rotation around the X-axis defines its orientation, after
which another translation to its centre of pressure defines the point where the local forces and moments are
calculatedb .

II.C.1. Units
Every element in the configuration file that models a quantity (such as a mass or a length) is represented by
a value and a unit. An example is given below,
<mass unit="kg"> 10.0 </mass>

Similar quantities that belong together (e.g. the individual coordinates in a location element) are grouped
together inside a parent element, inheriting the unit from that parent element.
The base units for length, mass, time, electric current and thermodynamic temperature are respectively
metre, kilogram, second, ampere and kelvin. The derived quantity plane angle is added to this set of base
quantities and it has the radian as unit. Input values that have degrees as unit are converted to radiansc . This
is less confusing that strictly following the SI-convention, since output quantities such as angular velocities
will have values expressed in rad/s instead of 1/s.
Values in the input file can be given standard SI units or custom US units, taking the error-prone task
of converting values from the one to the other system off the shoulders of the user. Internally, all data is
converted to SI units, and all output has SI-values.

II.C.2. Pilot Input Conversions

To convert control stick input into rotor inputs, flight controls are fed through a so-called mixing-unit. It
combines the collective, cyclic and pedal inputs applied by the pilot to proportional output to the main
and tail rotor controls. An example of the control mixing for the UH-60A Black Hawk helicopter can be
found in Ref. 17. Due to its canted tail rotor (that provides 2.5% of the lift in hover), there are some
additional couplings between the longitudinal and lateral motions of the aircraft. The mechanical mixing
unit is designed to counter some of the adverse effects of the canted tail rotor. The control system logic for
this helicopter is shown in Fig. 1.
Under the assumption that mechanical control mixing units can be represented by linear transformations
between pilot inputs and blade pitch inputs, for every rotor, a gain matrix and bias vector can be defined
to convert between the pilot inputs and blade pitch angles. In the above case, the gain matrices and bias
vectors for the main and tail rotor would look as follows,
 
    coll  
θ0 1.6 0.0 0.0 0.0 9.9
  lat 
 
θ1c  = −0.256 1.6 0.0 0.0  · + 0.0 (1)
    

 long 
θ1s MR 0.404 0.0 −2.83 1.63 G 0.0 B
pedal pilot
b This is also the case for the rotor model.
c In the official International System of Units, the plane angle is treated as a derived quantity (radian) with unit m · m−1 = 1

5 of 18

American Institute of Aeronautics and Astronautics

 Figure 1: UH-60A mechanical mixing (from Ref. 17)

 
    coll  
θ0 1.6 0.0 0.0 −5.54 7.0
  lat 
 
θ1c  = 0.0 0.0 0.0 0.0  ·  + 0.0 (2)
    

 long 
θ1s T R 0.0 0.0 0.0 0.0 G 0.0 B
pedal pilot
In the XML-input file, every rotor has a <control_mixing> section that defines the gain matrix and bias
vector in the above linear transformation (see also Appendix A),
<control_mixing>
<!-- order : collective, lat. cyclic, long. cyclic, pedal -->
<gain_matrix unit="deg">
<theta_0> 25.0 0.0 0.0 0.0 </theta_0>
<theta_1c> 0.0 7.0 0.0 0.0 </theta_1c>
<theta_1s> 0.0 0.0 15.0 0.0 </theta_1s>
</gain_matrix>
<bias_vector unit="deg">
<theta_0> 0.0 </theta_0>
<theta_1c> 0.0 </theta_1c>
<theta_1s> 0.0 </theta_1s>
</bias_vector>
</control_mixing>

II.D. Essential Fortran Concepts

Since the end of the 70’s of the previous century, the primary programming language for scientists and
engineers has been FORTRAN 77. Since its inception, a huge amount of libraries and programs have been
written with it. In the mean time, C++ introduced the object-oriented paradigm to a wider audience, where
not the routines, but the data itself (the objects) is central. It became clear that FORTRAN 77 needed
a major update to reflect the changes in programming practice since its inception. A major update was
released in 1992 and another minor update was published in 1997. These two updates are together known
as Fortran 90/95. The features essential to Helix that were introduced with these two revisions are shortly
discussed below.

II.D.1. Modules
Fortran 90 introduced the module program unit. It contains specifications and definitions that can be made
accessible to other program units by a USE statement referencing the name of the target module. In addition,
accessibility can be limited to specific parts. By encapsulating subroutines and functions in modules, the

6 of 18

American Institute of Aeronautics and Astronautics

compiler is able to type-check procedure calls, i.e. make it possible to determine if you are calling a subroutine
with the right arguments (similar to header files in C/C++ that contain prototypes of procedures).

II.D.2. Allocatable and Automatic Arrays

Fortran provides the ability to dynamically allocate arrays during program execution. Two types of dynamics
arrays are available: allocatable and automatic arrays. Using allocatable arrays, it is possible to allocate
and deallocate storage as required. Automatic arrays allow local arrays in a procedure to have a different
size and shape every time the procedure is invoked.
As an example, the original LAPACK subroutine dgeevx18 that calculates the eigenvalues of a general
N-by-N nonsymmetric matrix A and optionally, the left and/or right eigenvectors, needs 23 arguments. The
Fortran 95 interface that is part of the Intel Math Kernel Library19 (only) needs 13 arguments, which reduces
the chance that the programmer makes mistakes.

II.D.3. Derived Types

You can create additional data types, known as derived types, from intrinsic data types and other derived
types. These data types can e.g. be used to group all data related to a certain part of a program. In addition
to this, derived types can have allocatable subcomponents (both intrinsic data types and derived types)d
which makes it possible to create objects that reflect the structure of the problem at hand.
For example, one could group all variables related to data logging in a derived type. This would include
variables such as the filename, the type of file to write, the status of the file (opened or not), some logicals
defining what data to write, the size of the output array and its format. One would put this derived type in
the specification part of a module, together with the procedures that operate on an instance of this derived
type (initialization, open the file, write the data and close it again). Depending on the need, one or more
instances could be created of this derived type in another program unit. This way, all pecularities of data
logging would be hidden from the main programe.

II.D.4. Keyword and Optional Arguments

Since Fortran 90, procedures can have keyword and optional arguments. The default values of the optional
arguments are, unlinke in Python or C, defined inside the body of the procedure. New inquiry intrinsic
functions are defined to test for the presence of optional arguments. Optional arguments can also be supplied
as keyword = value pairs, which sets no constraints on the order of arguments supplied to a procedure.

II.D.5. Concluding Remarks

In this section, some new features of Fortran 90/95 were briefly discussed. These features have been essential
in the development of Helix. Compared to FORTRAN 77, it is a lot more pleasant in use, mainly due to the
formatting changes (free-format source code, lower-case variables, long variable names, longer lines, in-line
comments) that were introduced with Fortran 90. The object-oriented capabilities that are provided through
modules and derived types do not implement every single feature of Object-Oriented Programming, but for
engineering and scientific programming tasks, it is quite sufficientf .
In areas where its capabilities are not sufficient, one could make use of libraries and programs written in
other languages, since iterfacing it (especially with other compiled languages) is faily simple as long as some
basic rules are followedg .

III. Simulation Environment

The simulation environment that is utilized to test various controller concepts and create pilot mathemat-
ical models is Simulink. There are two distinct strategies for executing Fortran code from within Simulink.
One is from a Level 1 Fortran-Mex (F-Mex) S-function, the other is from a level 2 gateway S-function written
d Allocatable subcomponents of derived types were introduced with Fortran 95.
e This is the equivalent of a class in Python or C++.
f Parametric derived types as defined in the Fortran 2003 standard would be a welcome addition.
g Fortran 2003 contains an intrinsic module ISO C BINDING to make reliable communication with C possible.

7 of 18

American Institute of Aeronautics and Astronautics

in C. The original S-function interface was called the Level 1 API. As the capabilities of Simulink grew, the
S-function API was rearchitectured into the more extensible Level 2 API. The Level 1 API is still available,
but it is wiser to use the newer Level 2 API, since it allows S-functions to have all capabilities of a full
Simulink model.
For real-time simulations, the C++ middleware package DUECA20 is used. This software package is
specifically designed for the implementation of simulations and simulator experiments. It uses a publish-
subscribe mechanism to set up the communication, by which it supports a modular and flexible program
design.
Both environments make use of the same dual-sided interface. On the one hand, it consists of some
high-level Fortran subroutines that provide initialization, trim calculation, state derivative calculation and
output calculations. On the other hand, the interface consists of routines that implement these functions
using the API of either Simulink or DUECA. For Simulink, the interface is written in C, and for DUECA,
it consists of a single C++ class.
The flight dynamics model has been used in this year’s Master course on Flight and Space Simulation,
where students have to work in small groups to build a complete real-time simulation using DUECA. With
only some limited data available (trim values in forward flight and linear models for the same velocity range),
controllers had to be created for care-free/precise control and navigation.

Figure 2: Desktop Real-time Simulation Environment showing: an OpenGL window with a basic heads-up
display, DUSIME control panel and kst showing an overhead view of the flight path.

The first author of this paper participated in this course (to get acquainted with DUECA). The idea
behind the controller was to stabilize the helicopter at every flight speed when the controls were not touched
by the pilot, which enables the ”pilot” to fly hands free. This was achieved by approximating the trim curves
of the controls and attitudes with third- and fourth-order polynomials as a function of forward speed. On
top of this, two additional autopilot functions were created. Other members of the group constructed the
outside visuals, a navigation display (to see the other team’s helicopters) and aural feedback. Figure 2 shows
the desktop real-time simulation environment: in the upper-left corner an OpenGL window with a heads-up
display, in the upper right corner kst (see Section IV.C.1) showing a top-down view of the flown path and
in the lower-right corner, the DUSIME control panel.

8 of 18

American Institute of Aeronautics and Astronautics

 IV. Analysis and Visualization
IV.A. Helicopter Trim
The trim condition of a helicopter (or aircraft in general) is a combination of states and control inputs for
which the forces and moments are in equilibrium and at the same time satisfy a given flight condition. The
algorithm that is described in this section can trim a helicopter model with an arbitrary configuration (e.g.
single main and tail rotor, tandem rotors or coaxial) in the most general steady free-flight condition.

IV.A.1. The Most General Steady Motion

Steady motion requires that the time derivatives of all state variables involved in the equations of motion21
are zero (i.e., u̇ = v̇ = ẇ = 0; ṗ = q̇ = ṙ = 0; and Θ̇ = Φ̇ = 0). For a general 6 degree of freedom body,
this leads to the following set of equilibrium equations,

X = mg sin Θ + m (w q − v r) (3)
Y = −mg cos Θ sin Φ + m (u r − w p) (4)
Z = −mg cos Θ cos Φ + m (v p − u q) (5)
L = −Ixz p q − (Iy − Iz ) q r (6)
M = −Ixz (r2 − p2 ) − (Iz − Ix ) r p (7)
N = Ixz q r − (Ix − Iy ) p q (8)

It follows that only the angular velocity Ψ̇ may have a nonzero value. Then, the resultant angular velocity
of the airplane is around an earth-fixed vertical axis. The kinematic relations for the body-fixed angular
velocities22 reduce to

p = −Ψ̇ sin Θ (9)

q = Ψ̇ cos Θ sin Φ (10)
r = Ψ̇ cos Θ cos Φ (11)

The complete angular velocity Ω then equates to Ψ̇h . In terms of the Euler angles defining the air path
axis,22 we get
Ω = Ẋ and γ̇ = µ̇ = 0 (12)
Therefore, the flight path angle γ and the aerodynamic angle of roll µ are also independent of time. Another
observation that follows from the above is that Ẋ has the same magnitude as Ψ̇, namely

Ψ̇ = Ẋ = Ω (13)

So, in trimmed flight, the difference between Ψ̇ and Ẋ is zero and the difference between Ψ and X is a
(nonzero) constant. This difference, named χ, is used as an extra parameter defining the track angle. In
Fig. 3, a graphical representation of the relationship between the angles Θ, Φ, α, β, γ, χ, X and Ψ in
trimmed flight is given, with all angles drawn on a sphere with radius V . Xe and Ze are two of the three
axes of the moving Earth axis system or local horizon system. Xcg is the X-axis of the centre of gravity
frame of reference of the helicopter.
By transforming the air speed vector to the body axis, the velocity components follow as,

u = V (cos Θ cos γ cos χ + sin Θ sin γ) (14a)

v = V (sin Φ (sin Θ cos γ cos χ − cos Θ sin γ) + cos Φ cos γ sin χ) (14b)
w = V (cos Φ (sin Θ cos γ cos χ − cos Θ sin γ) − sin Φ cos γ sin χ) (14c)
p
hΩ ≡ p2 + q 2 + r 2 = Ψ̇

9 of 18

American Institute of Aeronautics and Astronautics

 Xcg
α

β Φ
Θ
Xe
V
γ Xa X Ψ
Ze
XΨ
χ

Figure 3: Trimmed flight with non-zero flight track angle χ

IV.A.2. Kinematic Constraints

In Helix, the flight condition for trim is a steady helical turn (see Fig. 4). The helicopter state can be
prescribed by a certain airspeed V , a flight path angle γ (positive up), the altitude h, the radius of turn
R, the turn direction (clockwise or counterclockwise, as seen from above) and the flight track angle χ. The
radius of turn is related to the total angular velocity as follows,
V cos γ
Ω= (15)
R
Mathematically, rectilinear flight can be defined with the above variables when the turn radius R is infinite.
As a result, the total angular velocity Ω in Eq. (15) equals zero in this flight condition.
V
Ω
V cos γ
XΨ χ V cos γ
Ψ R= Ω
Xe

h
Ze

Figure 4: Helicoidal motion

IV.A.3. Implementation
The trim procedure used is a first order, modular Newton iteration. Three routines are available to trim
different parts of a helicopter. The top level trim routine drives the rigid body accelerations to zero. The
two other routines ensure that the main rotor and tail rotor derivatives are driven to zero. This division
ensures that (in theory) it is possible to easily trim any viable helicopter configurationi.

Fuselage trim The trim variable vector v̄heli for the top level (fuselage) trim routine consists of the four
controls and the fuselage pitch and roll angles,

v̄heli = (Θ Φ θcoll θlat θlong θpedal )T (16)

i Several normal and tandem helicopter configurations have been tested.

10 of 18

American Institute of Aeronautics and Astronautics

The solution criterion vector for the fuselage z̄heli contains the rigid body accelerations,

z̄heli = (u̇ v̇ ẇ ṗ q̇ ṙ)T (17)

which should be zero in trimmed flight.

Rotor trim For a rotor, a trim routine drives all rotor state derivatives to zero. As an example, for a
rotor that has second order flap dynamics and three state inflow dynamics, the trim variable vector would
be
v̄rotor = (λ0 λ1s λ1c β0 β1s β1c β̇0 β̇1s β̇1c )T (18)
The solution criterion vector z̄rotor consists of the derivatives of the states in v̄rotor ,

z̄rotor = (λ̇0 λ̇1s λ̇1c β̇0 β̇1s β̇1c β̈0 β̈1s β̈1c )T (19)

and just like for the fuselage, these derivatives should be zero.

Tail rotor trim The dynamics of the tail rotor inflow is modeled using quasi-dynamic inflow, where a
time constant τ is used to represent the apparent mass effect of the air surrounding it. The trim variable
vector v̄tr is
v̄tr = v̄tr = λ0T R (20)
The solution variable z̄tr is the time derivative of the uniform inflow, which must be zero.
The division between fuselage and rotors is done because of the fact that the blade equations are implicit,
i.e., they contain, next to the helicopter linear and angular velocities, also the derivatives of these states, or

ẋrotor = f (ẋheli , xheli , xrotor , t) (21)

But since one of the goals of the trim routine is to find a state where ẋheli is (near) zero, these terms are
removed from the rotor state equations during trim, which in essence reduces Eq. 21 to

ẋrotor = f (xheli , xrotor , t) (22)

This simplification greatly increases the stability (and speed) by which the trim routine is able to find a
solutionj .

IV.B. Reduced-Order Linear Model Extraction

To gain a better understanding of the inherent characteristics of helicopter (in)stability, it is important
to study linear approximations to the general nonlinear motion. By using small perturbation theory, the
helicopter simulation model can be linearized around a previously trimmed flight condition. The general
structure of a linear model can be written as

ẋ − Ax = Bu (23)

Inhere, A is the system matrix and B is the control matrix.

Fig. 5 shows the flow diagram of the linearization routine. At the moment, the state vector of the
linear models only contains the body states, rotors are retrimmed before summing the disturbed forces and
moments. This ensures that extracted linear models show good agreement with the nonlinear model in time
simulations over a longer period of time. Short-term (< 2 seconds) behaviour may be quite different, though.
To be able to study the decoupled longitudinal and lateral dynamics, the following order is used for the state
vector x,
x = (u w q Θ | v p Φ r | Ψ)T (24)
For a flat-earth approximation of the equations of motion, the heading angle Ψ does not influence the stability
derivatives. However, it is retained here since it could be of used for controller design or inverse simulations.
j In general, there are two trim solutions, one in which the helicopter flies/hovers upside-down and a normal, upright solution.

The one that is found by the trim algorithm depends upon the initial value of the fuselage roll angle, zero or 180 degrees.

11 of 18

American Institute of Aeronautics and Astronautics

 Main Rotor

Trim Σ
Trimmed States Disturbed
& Tail Rotor Forces
Disturbances &
Moments

FUS–VF–HS

Nondimensionalisation
Stability Derivatives &
Trim Corrections

Figure 5: Flow diagram of the linearisation routine, with steady-state rotor emulation

IV.C. Data Visualization

In order to quickly visualize the results of the different analyses, a module has been added that interfaces
Helix with the PLplot library.23 This library be used from within compiled languages such as C, C++,
Fortran and Java, and interactively from interpreted languages such as Octave, Python, Perl and Tcl. It
supports a variety of output file devices such as Postscript, png, jpeg and others, as well as interactive devices
such as xwin, tk, gcw, xterm, . . . .

Figure 6: Sample graphical output from Plplot with Gnome Canvas Widget driver (actual plot area in
inverted colours)

At the moment, three categories of output are available. One of these (fuselage trim results for the
SA-330 Puma) is shown in Fig. 6. Root-locus plots (coupled and uncoupled) of the linear model eigenvalues
can be shown as a function of one of the trim variables. All these results can also be saved directly to M-files,

12 of 18

American Institute of Aeronautics and Astronautics

for further processing with MATLAB.

IV.C.1. On-line Visualization – Strip-Charts

During real-time simulations, it is important to monitor the states of the helicopter flight dynamics model.
The first requirement for this is to get the data out of the flight dynamics model in a standard way. This is
achieved by writing states and controls (user selectable) in comma-separated-variable (csv) format to a file.
The second requirement is to display the last part of that data (say the last 20 seconds) on screen. For this,
kst is used, an open-source real-time large-dataset viewing and plotting tool for Linux.24 Kst can attach
itself to a file and update plot windows whenever new data is written to the file.
For example, suppose one wants to look at pilot control behaviour during a real-time session. With time
in the first column, the four controls are written to a file named pilot ctrls.csv. Launching kst with the
following command from a terminal (plot column 2 to 5 against column 1 in a window where the plots are
divided over 2 columns):
$ kst -x 1 -y 2 -y 3 -y 4 -y 5 -m 2 pilot_ctrls.csv &
will result in a window with four graphs that are updated in real time (see Fig. 7). The labels and axis
limits of these graphs can then be set using kstcmd, a JavaScript interpreter that is part of kst.

Figure 7: Pilot control output during a real-time desktop simulation session with a bare (no SCAS) SA-330
Puma model as visualized with kst

V. Conclusions
In this paper, an overview is given of a modular, generic flight dynamics model that is in development
at Delft University of Technology. To achieve the intended flexibility, XML is used for data storage. The
programming language chosen for the core of the flight dynamics model is Fortran 90/95. The object-
oriented capabilities that are available through modules and derived types are sufficient for most engineering
and scientific programming tasks.
On a fidelity scale, the present model includes 6 Degrees Of Freedom (DOF) body motion, 3-DOF flap
dynamics, 6-DOF rotor inflow dynamics and 1-DOF tail rotor inflow dynamics. It is planned to use this model
together with the high-fidelity COTS software package FLIGHTLAB25 and with special-purpose analytical
models developed to gain fundamental understanding of helicopter dynamics.
Off-line analysis capabilities include trim and reduced-order model extraction and for the simulation
environment, DUECA and Simulink are utilized. Due to the extensive use of both in-house and open-source
software, it is a cost effective and flexible solution for visualization, feedback control design, flight dynamics
model development and handling qualities research in an academic environment.

13 of 18

American Institute of Aeronautics and Astronautics

 VI. Acknowledgements
The authors would like to thank M.M. (René) van Paassen for the initial implementation of the DUECA
interface.

References
1 Advani, S. K., van Zuylen, E., and Bettendorf, S., “SIMONA - A Reconfigurable and Versatile Research Facility,” Tech.

Rep. AIAA-1997-3809, 1997.

2 van Gool, P. C. A., Customizing the Aerospatiale SA-330 Puma Flight Control System, M.Sc. Thesis, Delft University

of Technology, Sept. 1992.

3 Voorsluijs, G. M., “Linear and Parameter-dependent Robust Control Techniques applied to a Helicopter UAV,” Tech.

Rep. AIAA-2004-4909, 2004.

4 van Holten, T., “Upgrading of Classical Lifting-Line Theory to Obtain Accurate Flight Mechanical Helicopter Models:

Improved Correction for Sweep Effects,” Advances in Rotorcraft Technology, CP – 592 , AGARD Conference Proceedings,
AGARD, Neuilly sur Seine, 1997.
5 Pavel, M. D., On the Necessary Degrees of Freedom for Helicopter and Wind Turbine Low-Frequency Mode Modeling,

Ph.D. Thesis, Delft University of Technology, Delft, 2001.

6 Pavel, M. D., “Prediction of the Necessary Degrees of Freedom for Helicopter Real-time Simulation Models,” Tech. Rep.

AIAA-2005-6206, 2005.
7 Kunz, D. L., “Comprehensive Rotorcraft Analysis: Past, Present and Future,” Tech. Rep. AIAA-2005-2244, 2005.
8 Voorsluijs, G. M., A Modular Generic Helicopter Model, M.Sc. Thesis, Delft University of Technology, May 2003.
9 “JSBSim, Open Source Flight Dynamics Model in C++,” http://jsbsim.sourceforge.net/, July 2007.
10 “XML Extensible Markup Language,” http://www.w3.org/XML/, July 2007.
11 “xml-fortran,” http://xml-fortran.sourceforge.net/, July 2007.
12 “XML,” http://nn-online.org/code/xml/, July 2007.
13 “xmlf90,” http://lcdx00.wm.lc.ehu.es/ag/xml/, July 2007.
14 “FoX,” http://www.uszla.me.uk/FoX/, July 2007.
15 Anon., “Dynamic Aerospace Vehicle Exchange Markup Language (DAVE-ML) Reference, Version 1.9b3,” Tech. Rep.

NASA TM-81238, July 2007.

16 “DAVEtools, Java Utility Programs to Manipulate DAVE-ML Files,” http://daveml.nasa.gov/DAVEtools.html, July

2007.
17 Jensen, P. T. and Curtiss Jr., H. C., “An Analytically Linearized Helicopter Model with Improved Modeling Accuracy

- Interim Report, August 1, 1990 – August 1, 1991,” Tech. Rep. NASA-CR-188715, Princeton University, Department of
Mechanical and Aerospace Engineering, Princeton, Aug. 1991.
18 “LAPACK, Linear Algebra PACKage,” http://www.netlib.org/lapack/, July 2007.
19 “Intel Math Kernel Library,” http://www.intel.com/cd/software/products/asmo-na/eng/perflib/219769.htm, July

2007.
20 van Paassen, M. M., Stroosma, O., and Delatour, J., “DUECA – Data-Driven Activation in Distributed Real-Time

Computation,” Tech. Rep. AIAA-2000-4503, 2000.

21 Padfield, G. D., Helicopter Flight Dynamics, Blackwell Science Ltd., Oxford, 2000.
22 Ruijgrok, G. J. J., Elements of Airplane Performance, Delft University Press, Delft, 1990.
23 “PLplot – a Scientific Plotting Library,” http://plplot.sourceforge.net/, July 2007.
24 “kst, Real-time Data Plotter and Analyzer,” http://kst.kde.org, July 2007.
25 DuVal, R. W., “A Real-Time Multi-Body Dynamics Architecture for Rotorcraft Simulation,” The Challenge of Realistic

Rotorcraft Simulation, RAes Conference, London, UK, Nov. 2001.

14 of 18

American Institute of Aeronautics and Astronautics

 A. SA-330 Puma Configuration File
<?xml version="1.0"?>
<hfdm_config>
<fileHeader>
<author> Wim Van Hoydonck </author>
<fileCreationDate date="2006-12-15" />
<fileVersion> $Rev: 414 $ </fileVersion>
<description> Models the SA-330 Puma Helicopter </description>
<reference
refID="REF01"
author="Wim Van Hoydonck"
title="Development and Validation of a Numerical Blade Element Helicopter Model in Support of Maritime Operations"
date="2006-08-18" />
<reference
refID="REF02"
author="Gareth D. Padfield"
title="Helicopter Flight Dynamics"
accession="0-632-05607-X"
date="1996-01-01" />
</fileHeader>
<mass_balance>
<ixx unit="kg-m^2"> 9638.0 </ixx>
<iyy unit="kg-m^2"> 33240.0 </iyy>
<izz unit="kg-m^2"> 25889.0 </izz>
<ixy unit="kg-m^2"> 0.0 </ixy>
<ixz unit="kg-m^2"> 2226.0 </ixz>
<iyz unit="kg-m^2"> 0.0 </iyz>
<mass unit="kg"> 5805.0 </mass>
<location name="cg_origin" transformation_type="translation" unit="m" ref_frame="body_fixed">
<x> 0.5978 </x>
<y> 0.0 </y>
<z> -1.48782 </z>
</location>
<!-- everything below this line adds mass and inertia to the above values and moves the cg to a new spot -->
<pointmass name="Pilot">
<mass unit="kg"> 85 </mass>
<location name="POINTMASS" transformation_type="translation" unit="m" ref_frame="body_fixed">
<x> 3.0 </x>
<y> 1.0 </y>
<z> -0.75 </z>
</location>
</pointmass>
</mass_balance>
<metrics>
<location name="eyepoint" transformation_type="translation" unit="m" ref_frame="body_fixed">
<x> 2.0 </x>
<y> 1.0 </y>
<z> -2.0 </z>
</location>
<control name="pilot_collective">
<range unit="-">
<min> 0.0 </min>
<max> 1.0 </max>
</range>
</control>
<control name="pilot_longitudinal_cyclic">
<range unit="-">
<min> -1.0 </min>
<max> 1.0 </max>
</range>
</control>
<control name="pilot_lateral_cyclic">
<range unit="-">
<min> -1.0 </min>
<max> 1.0 </max>
</range>
</control>
<control name="pilot_pedal">
<range unit="-">
<min> -1.0 </min>
<max> 1.0 </max>
</range>
</control>
</metrics>
<ground_reactions>
</ground_reactions>
<propulsion>
<rotor name="main" rot_dir="cw" blades="4" orientation="fixed" hinge_sequence="l-f-p">
<swash_plate_phase_angle unit="deg"> 0.0 </swash_plate_phase_angle>
<control_mixing>
<!-- order : collective, lat. cyclic, long. cyclic, pedal -->
<gain_matrix unit="deg">

15 of 18

American Institute of Aeronautics and Astronautics

 <theta_0> 25.0 0.0 0.0 0.0 </theta_0>
<theta_1c> 0.0 7.0 0.0 0.0 </theta_1c>
<theta_1s> 0.0 0.0 15.0 0.0 </theta_1s>
</gain_matrix>
<bias_vector unit="deg">
<theta_0> 0.0 </theta_0>
<theta_1c> 0.0 </theta_1c>
<theta_1s> 0.0 </theta_1s>
</bias_vector>
</control_mixing>
<nom_rot_speed unit="rad/sec"> 28.3 </nom_rot_speed>
<radius unit="m"> 7.5 </radius>
<!-- position of nacelle origin -->
<location name="nacelle_origin" transformation_type="translation" unit="m" ref_frame="body_fixed">
<x> 0.546 </x>
<y> 0.0 </y>
<z> -2.186 </z>
</location>
<!-- rotation around y-axis of nacelle_origin for orientation of shaft -->
<location name="shaft_origin" transformation_type="rotation" unit="deg" ref_frame="rotor_origin">
<x> 0.0 </x>
<y> -5.0 </y>
<z> 0.0 </z>
</location>
<!-- position of hub centre wrt nacelle origin (along z-axis) -->
<location name="hub_body" transformation_type="translation" unit="m" ref_frame="shaft_origin">
<x> 0.0 </x>
<y> 0.0 </y>
<z> -1.184 </z>
</location>
<blade discretization="equal_annuli" segments="15">
<structural model="articulated rigid blade">
<description> Rigid blade model with flap hinge at nonzero hinge offset from hub centre </description>
<precone unit="deg"> 0.0 </precone>
<pitch_flap_coupling unit="deg"> 0.0 </pitch_flap_coupling>
<mass unit="kg"> 68.0 </mass>
<first_moment unit="kg-m"> 256 </first_moment>
<inertia unit="kg-m^2"> 1280.0 </inertia>
<hinge_offset unit="m"> 0.3 </hinge_offset>
<!-- twist : variant="quadratic" or variant="sqrt" or variant="linear" -->
<!-- twist : starts_at="cuff" or starts_at="centre" -->
<twist unit="deg" variant="linear" starts_at="centre"> -8.0 </twist>
<root_chord unit="m"> 0.54 </root_chord>
<tip_chord unit="m"> 0.54 </tip_chord>
<root_cutout unit="m"> 1.45 </root_cutout>
<flap_spring_stiffness unit="N-m/rad"> 33032.0 </flap_spring_stiffness>
<flap_damping unit="N-m-s/rad"> 0.0 </flap_damping>
</structural>
<aerodynamic model="full range steady angle of attack">
<description> Full-range static airfoil characteristics for lift, drag and moment taken from Leishman </description>
<small_aoa>
<range unit="deg">
<min> -12.0 </min>
<max> 12.0 </max>
</range>
<cl_alpha unit="1/rad"> 5.7 </cl_alpha>
<alpha_l0 unit="deg"> 0.0 </alpha_l0>
<cd0 unit="-"> 0.0077 </cd0>
<cd1 unit="1/rad"> -0.0216 </cd1>
<cd2 unit="1/rad^2"> 0.4 </cd2>
<cm0 unit="-"> 0.0 </cm0>
</small_aoa>
<large_aoa>
<cl_A unit="-"> 1.175 </cl_A>
<cm_B unit="-"> -0.5 </cm_B>
<cm_C unit="-"> 0.11 </cm_C>
<cd_D unit="-"> 1.135 </cd_D>
<cd_E unit="-"> -1.05 </cd_E>
</large_aoa>
</aerodynamic>
</blade>
<!-- <inflow> is now defined in inflow_models.xml -->
</rotor>
<tail_rotor name="tail" type="pusher" blades="5">
<radius unit="m"> 1.56 </radius>
<chord unit="m"> 0.18 </chord>
<rot_speed parent="main" type="rotor" attribute="nom_rot_speed"> 4.82 </rot_speed>
<!-- blockage_factor = 1.0 - 0.75*vf_area / (pi * tr % radius) (see padfield p. 142)
??Rewrite this towards some kind of function?? -->
<blockage_factor parent="vertical_fin" type="stabilizer" attribute="area" />
<control_mixing>
<!-- order : collective, lat. cyclic, long. cyclic, pedal -->
<gain_matrix unit="deg">

16 of 18

American Institute of Aeronautics and Astronautics

 <theta_0> 10.0 0.0 0.0 20.0 </theta_0>
<theta_1c> 0.0 0.0 0.0 0.0 </theta_1c>
<theta_1s> 0.0 0.0 0.0 0.0 </theta_1s>
</gain_matrix>
<bias_vector unit="deg">
<theta_0> 0.0 </theta_0>
<theta_1c> 0.0 </theta_1c>
<theta_1s> 0.0 </theta_1s>
</bias_vector>
</control_mixing>
<location name="tr_loc" transformation_type="translation" unit="m" ref_frame="body_fixed">
<x> -8.928 </x>
<y> 0.63 </y>
<z> -2.869 </z>
</location>
<location name="tr_orient" transformation_type="orientation" unit="deg" ref_frame="tr_loc">
<x> 0.0 </x>
<y> 0.0 </y>
<z> 0.0 </z>
</location>
<inflow_time_constant unit="-"> 0.024 </inflow_time_constant>
<inflow_type> quasi dynamic uniform inflow </inflow_type>
<lift_curve_slope unit="1/rad"> 5.7 </lift_curve_slope>
</tail_rotor>
<engine>
</engine>
</propulsion>
<aero_surfaces>
<stabilizer name="vertical_fin" movable="0">
<location name="stab_loc" transformation_type="translation" unit="m" ref_frame="body_fixed">
<x> -8.563 </x>
<y> 0.0 </y>
<z> -1.460 </z>
</location>
<location name="stab_rot" transformation_type="rotation" unit="deg" ref_frame="stab_loc">
<x> 270.0 </x>
<y> 0.0 </y>
<z> 0.0 </z>
</location>
<location name="stab_ac" transformation_type="translation" unit="m" ref_frame="stab_rot">
<x> 0.0 </x>
<y> 1.0 </y>
<z> 0.0 </z>
</location>
<area unit="m^2"> 1.395 </area>
<taper_ratio unit="-"> 0.72 </taper_ratio>
<aspect_ratio unit="-"> 4.4 </aspect_ratio>
<aerodynamic model="full range steady angle of attack">
<description> Full-range static airfoil characteristics for lift, drag and moment taken from Leishman </description>
<small_aoa>
<range unit="deg">
<min> -10.0 </min>
<max> 15.0 </max>
</range>
<cl_alpha unit="1/rad"> 6.0 </cl_alpha>
<alpha_l0 unit="deg"> 1.0 </alpha_l0>
<cd0 unit="-"> 0.0 </cd0>
<cd1 unit="1/rad"> 0.0 </cd1>
<cd2 unit="1/rad^2"> 0.0 </cd2>
<cm0 unit="-"> 0.0 </cm0>
</small_aoa>
<large_aoa>
<cl_A unit="-"> 1.175 </cl_A>
<cm_B unit="-"> -0.5 </cm_B>
<cm_C unit="-"> 0.11 </cm_C>
<cd_D unit="-"> 1.135 </cd_D>
<cd_E unit="-"> -1.05 </cd_E>
</large_aoa>
</aerodynamic>
</stabilizer>
<stabilizer name="horizontal_fin" movable="0">
<location name="stab_loc" transformation_type="translation" unit="m" ref_frame="body_fixed">
<x> -8.928 </x>
<y> 0.0 </y>
<z> -2.460 </z>
</location>
<location name="stab_rot" transformation_type="rotation" unit="deg" ref_frame="stab_loc">
<x> 180.0 </x>
<y> 0.0 </y>
<z> 0.0 </z>
</location>
<location name="stab_ac" transformation_type="translation" unit="m" ref_frame="stab_rot">
<x> 0.0 </x>

17 of 18

American Institute of Aeronautics and Astronautics

 <y> 0.5024 </y>
<z> 0.0 </z>
</location>
<area unit="m^2"> 1.335 </area>
<taper_ratio unit="-"> 0.7 </taper_ratio>
<aspect_ratio unit="-"> 4.5 </aspect_ratio>
<aerodynamic model="full range steady angle of attack">
<description> Full-range static airfoil characteristics for lift, drag and moment taken from Leishman </description>
<small_aoa>
<range unit="deg">
<min> -15.0 </min>
<max> 15.0 </max>
</range>
<cl_alpha unit="1/rad"> 6.0 </cl_alpha>
<alpha_l0 unit="deg"> -0.0 </alpha_l0>
<cd0 unit="-"> 0.0 </cd0>
<cd1 unit="1/rad"> 0.0 </cd1>
<cd2 unit="1/rad^2"> 0.0 </cd2>
<cm0 unit="-"> 0.0 </cm0>
</small_aoa>
<large_aoa>
<cl_A unit="-"> 1.175 </cl_A>
<cm_B unit="-"> -0.5 </cm_B>
<cm_C unit="-"> 0.11 </cm_C>
<cd_D unit="-"> 1.135 </cd_D>
<cd_E unit="-"> -1.05 </cd_E>
</large_aoa>
</aerodynamic>
</stabilizer>
<fuselage name="fus" model="flat-plate_equivalent">
<location name="fus_loc" transformation_type="translation" unit="m" ref_frame="body_fixed">
<x> 0.5978 </x>
<y> 0.0 </y>
<z> -1.48782 </z>
</location>
<f0x unit="m^2"> 1.8 </f0x>
<f0y unit="m^2"> 7.9 </f0y>
<f0z unit="m^2"> 5.0 </f0z>
<K unit="-"> 0.83 </K>
<volume unit="-"> 6.11 </volume>
</fuselage>
</aero_surfaces>
</hfdm_config>

18 of 18

American Institute of Aeronautics and Astronautics