Autonomous Systems Lab

Prof. Roland Siegwart

Bachelor-Thesis
Supervised by: Authors:
Konrad Rudin Sebastian Verling
Ulrich Schwesinger Julian Zilly
Konstantinos Alexis
Prof. Roland Siegwart
Modeling and Control of a
VTOL Glider
Spring Term 2013
Declaration of Originality
We hereby declare that the written work we have submitted entitled
Modeling and Control of a VTOL Glider
is original work which we alone have authored and which is written in our own words.
1
Authors
Sebastian Verling
Julian Zilly
Supervising lecturer
Konrad Rudin
Ulrich Schwesinger
Konstantinos Alexis
Prof. Roland Siegwart
With the signature we declare that we have been informed regarding normal academic citation
rules and that we have read and understood the information on Citation etiquette (http:
//www.ethz.ch/students/exams/plagiarism_s_en.pdf). The citation conventions usual to
the discipline in question here have been respected.
The above written work may be tested electronically for plagiarism.
Place and date Signature
Place and date Signature
1
Co-authored work: The signatures of all authors are required. Each signature attests to the originality of the
entire piece of written work in its nal form.
Abstract
In this bachelor thesis the modeling and control of the aircraft PacFlyer which was built within
the scope of a one-year student project at the Autonomous Systems Laboratory at ETH Zurich
is studied. The PacFlyer is a hybrid aircraft that can both take o and land vertically like a
helicopter as well as y in cruise like a regular airplane. The goal of this thesis is to enable the
aircraft to perform a fully controlled ight envelope with the aid of a pilot. This ight envelope
consists of a vertical take o in hover ight, a transition into cruise ight, a transition back to
hover ight and vertical landing.
The ight envelope of the aircraft is divided into three ight modes, namely hover, cruise and
transition. For all three modes a nonlinear grey box system model has been derived via a system
identication step of the actuator characteristics. A 6 degree of freedom rigid body model was
used to model the dynamics of the aircraft.
For hover a transformation to decouple the system has been developed. For both hover and
cruise mode cascaded PID controllers were used. To address the transition, strategies have been
developed to change from hover to cruise mode and vice versa by thoughtfully combining both
the hover and cruise model and controller.
The control strategy of all controllers was tested in simulation and partially experimentally
validated on the prototype.
ii
Acknowledgements
We want to thank our supervisors Konrad Rudin, Ulrich Schwesinger and Konstantinos Alexis
for their generous support during these last couple of months. We are also very thankful for the
eort of Prof. Roland Siegwart who has made the project possible in the rst place that this
thesis is based on. Furthermore, we want to express our gratitude towards our PacFlyer team
that has given us the fuel to work this motivated on the project and this thesis. We are happy
to have had the opportunity to work on a thesis with this kind of practical relevance.
iii
Contents
Symbols vii
1 Introduction 1
1.1 Formulation of the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 System Description 5
2.1 General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Flight modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Hover mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Cruise mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Transition mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Coordinate system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Hover Modeling and Control 13
3.1 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Modeling of actuator characteristics . . . . . . . . . . . . . . . . . . . . . 14
3.1.2 System dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Attitude controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.2 Position controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Simulation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Cruise Modeling and Control 29
4.1 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1 Control surface characteristics . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.2 Aerodynamics calculations tool . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.3 Rigid body dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1 Control modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Control scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Simulation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
iv
5 Transition Modeling and Control 37
5.1 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Simulation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6 Implementation and Testing 43
6.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7 Conclusion and Outlook 47
A Software structure 49
B Motor selection 54
B.1 Front motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
B.2 Rear motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
References 57
Symbols
Symbols
, , Roll, pitch and yaw angle

d
,
d
Desired roll and pitch angle, respectively

x
,
y
,
z
Respective torques around roll, pitch and yaw axis
Angular speed of a propeller/rotor
b
i
Thrust coecient
d
i
Drag torque coecient
L
...
Length of ... (front, back, side)
Rear tilt angle for yaw control in hover

...
Eciency of ...

...
Absolute value of torque of ...
F
z
Force in z - direction

x,y,z
Abbreviation for torques in x, y and z direction
T
x
Thrust in x - direction
T
y
Thrust in y - direction
T
z
Thrust in z - direction
T Total thrust
A
4x4
Placeholder for a 4 by 4 matrix
R
T
(z, ) Rotational matrix to account for yaw orientation
Angle of attack of air inow towards the wing
d Chord length
k
V
Motor speed constat
k

Motor torque constant

R
i
Inner resistance of the motor
I
0
No-load current
Indices
x x axis
y y axis
z z axis
vii
Acronyms and Abbreviations
ASL Autonomous Systems Laboratory
C/C++ Computer programming languages
CAD Computer Aided Design
CoG Center of Gravity
DMAVT Department of Mechanical and Process Engineering
DoF Degree of Freedom
EKF Extended Kalman Filter
ETH Eidgenossische Technische Hochschule (Swiss Federal Institute of Technology)
GCS Ground Control Station
IMU Inertial Measurement Unit
LQR Linear Quadratic Regulator
MIMO Multiple Input Multiple Output
PID Abbreviation for proportional, integral and derivate gains for control
PWM Pulse Width Modulation
RC Radio Control or Remote Control
RPM Revolutions per Minute
RSSI Received Signal Strength Indication
RTL Return to Launch
SISO Single Input Single Output
UAV Unmanned Aerial Vehicle
UKF Unscented Kalman Filter
VTOL Vertical Takeo and Landing
Chapter 1
Introduction
In the last couple of years science has made an unprecedented advance in sensing capabilities
as well as provided an almost ubiquitous presence of computing technology. Simultaneously,
knowledge in unmanned aerial vehicles (UAVs) has progressed considerably.
With these means available, a one-year-long focus project at the Autonomous Systems Labora-
tory at ETH Zurich of which the authors of this thesis were a part of set out to build an UAV with
vertical take o and landing (VTOL) capability. This aircraft is called PacFlyer. The developed
prototype was designed to combine the VTOL capability of a helicopter with the forward ight
eciency of an airplane. For take o and landing it employs a multicopter setup that hovers
and can transition into regular airplane ight. The multicopter setup of the PacFlyer used for
VTOL capability is a tricopter which has three rotors.
Applications of UAV aircraft are very diverse and could potentially range from tasks as diverse
as small parcel delivery to surveillance as well as general sensing applications. UAVs could be
used in hazardous environments to protect rescuers and gather critical information. Some ap-
plications that are already in use are domestic policing, natural resource exploration, wildlife
conservation and re detection. The project set out with the idea of small parcel delivery even
to remote places or villages where little or no infrastructure for transportation such as roads
or ight runways exists. To enable an aircraft to have good access to these places a VTOL
capable prototype was needed. A sample ight mission would therefore consist of vertical take
o, transition to cruise ight, traveling to the destination in cruise ight, transitioning back to
hover ight, landing vertically and vice versa. This would not only allow transporting goods
to remote places but also sending them from there, potentially allowing for trade. Developing
such an adaptable aircraft could potentially yield great benets by transporting parcels with e.g.
medicinal drug delivery to mentioned remote places.
1.1 Formulation of the problem
The bachelor thesis is written at the Autonomous Systems Laboratory of the Mechanical and
Process Engineering Department (DMAVT) at ETH Zurich and is based on the focus project
PacFlyer within the same institute. The goal of the work is to mathematically model, control and
stabilize the aircraft during its whole ight envelope. Specically the model should capture the
most relevant eects of the system, e.g. taking into account the characteristics of the actuators
such as saturations and actuator dynamics. Furthermore when suitable to the accompanying
1
Chapter 1. Introduction 2
project, the controllers should be implemented and tested in the dierent ight modes of the
ight envelope.
The ight envelope described before in the general introduction is divided into three ight modes,
namely hover, cruise and transition mode. The PacFlyer has to be modeled and controlled in
hover mode during take o and landing. In a next step the cruise mode should be modeled
and controlled. With a working controller and knowledge of both hover and cruise mode the
transition should be addressed. The transition of the two previous modes is achieved through a
simple intermediate controller or control strategy.
Methods such as cascaded PID control, a decoupling transformation and a position control
technique in hover are investigated as described by Astrom et al. [1], Guzzella [2] and Rudin [3]
and are used to control the aircraft in its ight modes.
1.2 Related work
The PacFlyer is a hybrid aircraft meaning it can be regarded as a dierent aircraft depending
on whether it is hovering or in cruise ight. Similar designs to the PacFlyer can be divided into
either multicopter setups, regular airplanes or similar hybrid aircraft that combine the rst two
designs.
Multicopter designs
On a more conceptual level, Barsk [4] deals with modeling and control of a tricopter with a model
predictive control approach. A tricopter is a multicopter with three rotors where one rotor is
able to tilt sideways. Similarly but more applied, Salazar-Cruz [5] shows the building, simulating
and physical testing of a tricopter design with real-time control.
Regular airplane designs
The concept of a regular airplane with standard control surfaces is widely and well understood
in the airplane community. Lectures such as Unmanned Aircraft Design, Modeling and Control
[3] at ETH Zurich explain the general modeling and control approaches for airplanes such as
cascaded PID control or optimal control approaches like LQR while the lecture Aircraft Stability
and Control at MIT [6] focuses more closely on airplane modeling and control concepts such
as PID or root locus control. Albaker and Rahim [7] deal with PID control of a xed-wing
UAV.Additionally, there are also books such as by Bryson [8] that deal with LQR control of
aircraft.
Hybrid designs
Carlson [9] demonstrated in the Orange Hawk Project a system that also has a tricopter mode
in hover and can change into cruise ight of a regular airplane in ight. This aircraft utilizes
a one wing design with three short arms outward on which the rotors are located. Similar to
the PacFlyer design, the Orange Hawk has front rotors that can tilt forward. Likewise, Fan,
Wand and Cai [10] describe a tricopter design with two attached wings that can perform high
speed ight. A very similar design to the focus project PacFlyer was developed by Ta, Fantoni
and Lozano [11]. It is a small airplane with three rotors, the two in the front being able to tilt
forward. This design was simulated but not experimentally validated.
3 1.3. Thesis outline
1.3 Thesis outline
The organization of the thesis is shown in the following.
Chapter 2 gives with a general description of the properties of the PacFlyer in its ight
modes. Here relevant actuators or control surfaces are already assigned to their respective
ight modes in which they are used. A general ight envelope overview is given.
Chapter 3, 4 and 5 deal with the individual ight modes hover, cruise and transition
respectively. These chapters deal with the modeling, the controller and the simulation for
the individual modes.
Chapter 6 presents the implementation and testing of the controllers and the results are
discussed.
Chapter 7 nally gives a conclusion and outlook to the thesis.
Chapter 1. Introduction 4
Chapter 2
System Description
The system PacFlyer regarded in this thesis is a hybrid between a regular plane and a tricopter-
like aircraft as explained in the introduction. This chapter focuses on the description of the system
with regard to aspects relevant to modeling and control and later implementation of the dierent
ight modes. The motors and servos and their placement will be discussed. Additionally, the
control surfaces for cruise ight will be mentioned. Another focus will be on the electrical parts
relevant for controlling the system i.e. the microprocessor and the sensors.
2.1 General description
Front propeller-assembly
Tilting-mechanism
Rear propeller-assembly
Electronics
Control surfaces
Tilt-servo
Figure 2.1: Illustration of the PacFlyer with its most important system components
5
Chapter 2. System Description 6
The PacFlyer will be regarded within the context of its dierent ight modes. In that context
the necessary parts to y in the dierent modes will be shown. Correspondingly, in gure 2.1
the most relevant parts of the aircraft are shown.
In gure 2.2 the schematics of the three ight modes hover, transition and cruise are illustrated.
The most important functional parts and main properties of the modes will be presented in
individual subsection for each mode.
Hover
Transition
Cruise
Figure 2.2: Illustration of the PacFlyer in its dierent ight modes - hover, transition and cruise
from bottom left to top right
2.2 Flight modes
The main properties of the three ight modes displayed in gure 2.2 will be explained in the
following.
2.2.1 Hover mode
In hover the PacFlyer is essentially a tricopter as displayed in gure 2.3. The two front propellers
and the rear propeller are pointing upwards while the rear propeller also has the ability to tilt
sideways with angle with a servo. In contrast to an airplane, manually steering a tricopter
or more generally a multicopter is a challenging task without electronic stabilization due to
cross-coupled system dynamics. A tricopter has strong cross-coupling within the system, e.g.
one motor thrust has an eect on multiple states such as attitude angles. Roughly however a
7 2.2. Flight modes
tricopter is controlled using dierential thrust of the front propellers to roll, dierential thrust of
the rear and the two front propellers to pitch and tilting of the rear propeller sideways to yaw.
Using geometric calculations the thrust distribution of the three propeller for this system is
shown in table 2.1 to hover at an equilibrium. Given this distribution stronger motors for the
front than the rear are required. For more detailed information about the motors see appendix
B.
Figure 2.3: PacFlyer in hover mode. Thrusts in orange, tilt angle to tilt the rear thrust around
x-axis.
Table 2.1: Thrust distribution of the front and rear propeller-motor-assemblies
Rotors Total thrust in percent %
Each main front rotor 37.9 %
Rear rotor 24.0 %
2.2.2 Cruise mode
In picture 2.4 the PacFlyer is illustrated in cruise ight mode. The aircraft in this mode works
like a regular airplane. The front propellers are tilted by 90

in the front in comparison to the

hover mode so they point in forward ight direction. The control surfaces are highlighted in
orange. The ailerons are deected antisymmetrically to control the roll motion, the elevator is
used to control the pitch motion and the rudder for the yaw motion. The two front propellers
are used to produce thrust and rotate with the same speed. The rear propeller is deactivated
during this mode. The dimensions of the aps were estimated as proposed by Raymer [12].
Chapter 2. System Description 8
Figure 2.4: PacFlyer congured for cruise ight. Control surfaces highlighted in orange, thrusts
in forward ight direction in red
2.2.3 Transition mode
During the transition mode displayed in gure 2.6 both the actuators and control surfaces of the
hover and the cruise mode are used. Additionally the tilting mechanism of the front propellers
shown in gure 2.5 is used to steer the angle of the front propeller in order to regulate the ratio
between the thrust in forward ight and upward direction. This angle has a range of 90

. All
elements such as forces and torques that are inuencing the system are illustrated in gure 2.6.
The mentioned tilting mechanism is one of the most essential hardware parts of the system, as
it provides the possibility of changing from the exible hover mode to the ecient cruise mode.
Due to complex mechanics and the importance of this part it was developed and is discussed
more thoroughly in another thesis by Lehmann [13].
2.3 Coordinate system
To make things more tangible and concrete for modeling a body coordinate system is set on the
aircraft and an earth-xed coordinate system is introduced. The coordinate systems explained
in the following are closely based on descriptions by Wendel [14]. The body coordinate system
is presented in the upcoming gure 2.7 and as the earth-xed system will be used in the further
discussion and chapters.
Using dierent coordinate systems allows the introduction of various forces and torques acting
on the aircraft in a simpler way. Specically, some forces are easier to model in the body-xed
frame shown in the gure 2.7 above. Whereas, some forces and torques are more easily modeled
using an earth-xed coordinate frame.
9 2.3. Coordinate system
Axis
Actuation
Figure 2.5: Tilting mechanism
Figure 2.6: Illustration of the PacFlyer in transition mode with tilting of front rotors (angle
displayed) and both hover and cruise forces
Chapter 2. System Description 10
Figure 2.7: Illustration of the PacFlyer with its body-xed coordinate system and respective
rotation angles as introduced by Leutenegger [3]
Body-xed frame
The body-xed coordinate system is xed to the aircraft. It has the x-axis along the
forward axis of the fuselage. The y-axis is alongside the right wing side (from back to front
view). Finally, the z-axis points downwards from the aircraft as illustrated in gure 2.7.
The center of the body frame is set to the quarter chord of the wing in forward direction
of the fuselage, in the center of the wing in the direction along the wing and at the height
of the wing in up or down direction.
The body-xed frame is mainly used to compute aerodynamic forces that depend on the
attitude of the PacFlyer. As the IMU measures accelerations in this coordinate system the
equations get simpler than in a xed frame. The thrust forces and resulting drag torques
are introduced in the body-xed coordinate system as well. A vector in the body frame is
denoted with a superscript b.
Earth-xed frame
The earth-xed frame is as the name says earth xed and meant to show where the aircraft
is relative to this xed observer point. For simulation purposes the frame can be regarded as
being placed a plane with z-direction downwards in the direction of the ground or gravity
and the x and y direction arbitrarily set. This is done because the simulations are not
conducted on a specic point on earth but rather in a virtual environment. While the
earth-xed frame remains immobile, the body-xed frame can move relative to the earth-
xed frame.The earth-xed frame can be used e.g. for the translational movement of the
body as well as for the gravity force acting in earth-xed frame z-direction on the center
of gravity. Furthermore, one often wants to follow a reference trajectory in the earth-xed
coordinate system. This frame also introduces the attitude of the system, which is dened
as the angle state of the body-xed frame relative to the earth-xed frame as shown with
the angles , and in gure 2.7. A vector in the earth-xed frame is denoted with a
11 2.4. Electronics
superscript e. Due to the resolution of the IMU the rotation of the earth is not taken into
account when measuring and the earth-xed frame is used.
While the IMU delivers data in the body-xed frame, data such as position are needed in the
inertial frame. Therefore a transformation between these two frames is used in the work presented
in this thesis. Overall Tait-Bryan angles are used to describe the attitude of the aircraft. For
a more detailed understanding of both Tait-Bryan angles and the transformation between the
presented coordinate frames refer to Leutenegger [3] and Wendel [14].
2.4 Electronics
With all physical parts discussed needed for the ight envelope, the essential electronic parts that
power and control the system still need to be addressed. In the following the microprocessor
controller and sensors will be described.
ArduPilot Mega 2.5
The circuit board used in the described system is an ArduPilot Mega 2.5. It consists of the
components described in table 2.2 For control purposes the most important part of this board
Table 2.2: ArduPilot Mega 2.5 components
Processor
Atmega 2560 by Atmel
On-board sensors
Barometer MS5611-01BA03
Magnetometer HMC5883L
Inertial Measurement Unit (IMU) MPU-6000
Ports
USB-Port
GPS-sensor connection
8 input-ports
8+3 PWM output-ports
Input-port for optical ow sensor ADNS-3080
Input-port for airspeed sensor MPXV7002DP
Input-port for telemetry kit
Additional features
16Mbit data ash AT45DB161D-MU
Chapter 2. System Description 12
is the IMU which contains a gyroscope and an accelerometer to measure angular velocity and
accelerations of the system respectively. To obtain the attitude angles shown in gure 2.7 the
IMU is rst calibrated around a manually set zero attitude. The attitude angles are then obtained
by integrating the angular velocities. Merging the data of the IMU with the measurements of the
GPS-Sensor, the barometer and the magnetometer one can also estimate velocity and position
of the system. To implement control algorithms and in the end calculate control signals using
the state data of the system the Atmega 2560 processor is used. The control signals are then
written to the PWM port of the actuators.
Chapter 3
Hover Modeling and Control
This chapter describes the PacFlyer in hover mode. The hover mode will be presented with a
rst overview about the modes modeling and control scheme. Then the modeling of the mode
itself will be discussed. Afterwards the controller will be presented in more detail. Finally, a
discussion of simulation and test results is made.
3.1 Modeling
Creating a control model of PacFlyer system makes it possible to test preliminary controller
designs before implementing them and also gives an understanding for the dynamics of the air-
craft. For the PacFlyer a grey-box modeling approach is chosen. The model is based on physical
considerations yet some parameters of the model will have to be determined experimentally.
Figure 3.1: Illustration of the complete model for hover with controller, system dynamics and
non-linearities of the actuators and mappings
In a rst step, a brief overview over the entire modeling is given in gure 3.1. Given the
overall structure of the system model the actuators with their dynamics and saturations, the
system dynamics and parameters will be explained. Figure 3.1 shows the hover simulation model
13
Chapter 3. Hover Modeling and Control 14
with actuator and system dynamics, saturations and mappings. The way the signals from the
controller travel through the model can be followed. Here the output signals of the controller are
the control signals that are inputs to the system to the left of gure 3.1. The system model for
the system dynamics is colored orange, the controller blue, the non-linearities grey and mappings
green. In the following the individual blocks and parameters of the model will be explained in
more detail.
Here is a short list of the most relevant criteria as well as assumptions for the system model in
hover that were taken into account as presented by Rudin [3].
The system model is based on a rigid body assumption
Interaction with the ground or other surfaces is neglected
Interaction with the environment is neglected (e.g. wind)
Friction and damping are neglected (Viscous Friction, Induced Drag, Turbulences)
Actuator/motor dynamics and saturation eects are taken into account based on measure-
ments
The propellers are assumed to be rigid
Hub forces and torques are neglected
Gyroscopic forces are neglected
The interaction between the accelerated air of the front propellers with the wings is not
considered
3.1.1 Modeling of actuator characteristics
This subsection illustrates the signal - output relationship of the actuators, their saturations and
dynamics. This essentially covers the rst 4 system blocks in gure 3.1 beginning on the left.
In order to make the system model as realistic as possible, actual physical tests of certain parts
were relied on for modeling. The tilt angle of the rear servo as well as the forces of the front
and rear propeller-assemblies are therefore mapped to the respective electrical signals that were
shown to result in these forces or tilt angle. These are the actuators needed for control of the
hover mode. The dynamics of the actuators as well as their saturations will be evaluated.
Actuator signal characteristics
When testing, all actuators (propeller-motor-assemblies and servos) exhibited a linear relation-
ship between either thrust force, drag torque or angle and the respective electrical signal. The
electrical signal used is a PWM (Pulse-Width Modulation) signal as described in more detail by
Andersson [15]. One of these linear relationships is shown in gure 3.2 as an example. To nd
the thrust to the corresponding PWM signal of the propeller-assemblies a setup with a scale to
measure thrust was used. Likewise, the angle of servos was measured with a digital angle gauge.
The received data was then interpolated with a linear function of the form y = a x +b and the
parameters a and b were determined.
15 3.1. Modeling
Figure 3.2: PWM signal to front thrust
The drag torque could not be directly measured with the material available and was thus calcu-
lated from the measured data. The calculated relationship for the drag is displayed in equations
3.1.1 and 3.1.2.
The mechanical power is calculated to be the used electrical power multiplied by the eciency
of the motor and the gearbox as described in the equation
P
mech
=
motor

gearbox
P
electric
. (3.1.1)
Having calculated the mechanical power one can now utilize the upcoming relationship 3.1.2 that
the drag torque is the same as the mechanical power divided by the angular speed

drag
=
P
mech

. (3.1.2)
The resulting relationship between the drag torque
drag
and the PWM signal is as mentioned
also found to be linear and hence modeled as such.
Actuator dynamics
In order to get a more realistic system model the actuator dynamics have also been looked at and
were included in the model. The measurements of step-like changes of the motors signals were
not signicant enough for modeling due to too much noise. Therefore the actuator dynamics
have been modeled with a mathematical model of the motors based on the motor specications
given in table B.1 and B.2 in the appendix B. This motor model is shown in gure 3.3 as it
was simulated in MATLAB/Simulink. The Simulink model is an adapted le provided by Prof.
Roland B uchi (Prof. R. B uchi 2013, pers. comm., unreferenced). The constants required for this
model are presented in table 3.1. The main motor dynamics equation is given by
d
dt

motor
=
1
J
_
_
U
a

motor
k
V
_
k

R
i

_
I
0
k

+
load
(
motor
)
_
_
. (3.1.3)
Chapter 3. Hover Modeling and Control 16
Table 3.1: Constants needed for actuator model
Symbol Name Unit
k
V
Speed constant rpm/V
R
i
Internal resistance
k

Torque constant N/mA

J propeller inertia kg m
2
I
0
no-load current A
The inertia J is calculated based on the weight and the dimensions of the propeller which
is approximated with a disc. The speed constant, internal resistance and the no-load current
is taken from the motor specication sheet. The torque constant can be calculated with the
following formula.
k

=
1
k
V
30

The voltage aecting the motor is then computed by

U
res
= U
a
U
induced
with U
induced
=
n
/k
V
the induced voltage, n as the revolutions per minute and U
a
the applied
voltage. The resulting current is then
I =
U
res
R
i
The therefore resulting torque is computed with

res
= Ik

drag
I
0
k

Dividing the resulting torque with the inertia results in the angular acceleration. Integrating
this result then provides the angular velocity in rad/s.
Figure 3.3: Simulink model of the actuator dynamics
17 3.1. Modeling
Actuator saturations
To more accurately model the real prototype saturations were taken into account. The identi-
cation of the actuators saturation limits is based on measurements. The saturation of the servos
are mechanical limits of the range. The brushless motors saturations are mainly due to overheat-
ing at very high rpm. The motors could drive at higher angular speeds but these high angular
speeds would require a high current which would heat the motor up too much and damage it.
In table 3.2 the saturations of the various actuators are shown quantitatively. Some of these
saturations have been set manually within the controller even though the actuators would have
a broader range as described in the case of the motor. Otherwise the actuators could damage
the system.
Table 3.2: Actuator saturations
Front motors 27N/6500rpm
Rear motor 17N/8700rpm
Rear tilt servo 15

Front tilt servo 0

to 90

Ailerons 25

Elevator 10

to 6.5

Rudder 20

Sensor noise
The sensor noise disturbing the measurements of the gyroscope and the accelerometer described
in section 2.4 was modeled based on information of the sensor data sheet of the IMU. According
to these information the total root mean square (RMS) noise of the gyroscope has a value of
0.05

/s and the noise of the accelerometer has a power spectral density of were considered during
the modeling of the whole system.
3.1.2 System dynamics
With all necessary subsystems modeled, the overall system dynamics can be looked at. The
parameters for the system dynamics will be dealt with afterwards. The body dynamics are
displayed by the two blocks to the very right of the overview gure 3.1. The system dynamics
modeling is closely based on the MATLAB/Simulink model of the Skysailor airplane of the
ASL at ETH Zurich [16] that is part of a lecture by Leutenegger [3]. Even though this is an
airplane model, the 6 DoF rigid body dynamics remain the same for any body with 6 DoF. A
few adaptations of the parameters were made to more realistically model the specic PacFlyer
aircraft. The modeling for the dynamics works as follows.
The input to the system dynamics part of the model, namely the green block to the right in gure
3.1 are the forces of the propeller-assemblies and the rear tilt angle. From these the resulting
forces and torques on the system are calculated by taking into account the geometry of the
aircraft and gravity. The forces and torques in the body frame that result from the propellers
and the tilting of the rear propeller with angle in the body frame are
Chapter 3. Hover Modeling and Control 18
_
_
_
_
_
_
_
_
F
x
F
y
F
z

z
_
_
_
_
_
_
_
_
b
=
_
_
_
_
_
_
_
_
0
F
back
sin()
F
fr
F
fl
F
rear
cos()
F
fr
L
s
+F
fl
L
s
F
fr
L
f
+F
fl
L
f
F
rear
cos() L
b

dragrear
sin()

dragright
+
dragleft
+
dragrear
cos() F
rear
L
b
_
_
_
_
_
_
_
_
b
. (3.1.4)
The forces F
fr
and F
fl
are the abbreviated form for the forces F
frontright
and F
frontleft
that
are generated by the front propeller-motor-assemblies displayed in gure 2.3.
Once arrived at the forces and torques the model describes the dynamics equations of the rigid
body and is thus essentially a double integrator as shown in the following dynamics equations.
Gravity is now also taken into account. This part is illustrated by the orange 6 DoF rigid body
model block in gure 3.1.
The following equation
_
_
u
v
w
_
_
b
=
_
_
r v q w +
1
M
F
x
g sin()
p w r u +
1
M
F
y
+g sin() cos()
q u p v +
1
M
F
z
+g cos() cos()
_
_
(3.1.5)
describes the rate of change over time of the bodys translational velocities. As the velocity is
the time derivative of the position this equation 3.1.4 displays the translational body dynamics
in the body coordinate frame. These dynamics have an Euler dynamics part as described by
Leutenegger [3] that incorporates the eect of the body angular rate p, q and r into transla-
tional body dynamics. The total mass of the aircraft is denoted with M, the gravitational earth
acceleration with g.
Once these body accelerations are integrated the actual body velocities can be obtained. From
this the translational velocities in the earth-xed frame can be calculated by transforming from
the body to earth-xed frame with the relationship
_
_
x
y
z
_
_
e
= R
e
b

_
_
u
v
w
_
_
b
. (3.1.6)
Similar to the translational case, the rate of change of the body angles is shown in equation 3.1.7
_
_
p
q
r
_
_
b
=
_
_
1
I
xx
(
x
q r (I
zz
I
yy
))
1
I
yy
(
y
p r (I
xx
I
zz
))
1
I
zz
(
z
p q (I
yy
I
xx
))
_
_
. (3.1.7)
As in the translational case in equation 3.1.6 the body angular rates can be multiplied by a
transformation matrix to obtain the inertial angular rates. The notation R
e
b
means that a
transformation from subscript body frame to the superscript earth-xed frame is conducted.
Rudin and Leuteneggger [3] as well as Wendel [14] deal with this transformation in more detail.
Obtaining a variable from its time derivative as the ones above requires integration. This way
the model simulates the dynamics of the aircraft as a double integrator and has the attitude,
angular rates, position and velocity as output.
19 3.2. Control
Estimating model parameters
To be able to accurately model the system dynamics a few parameters such as inertias, total
mass and the center of gravity have to be found. The actuators parameters have been regarded
in the respective subsection 4.1.1.
The center of gravity CoG, total mass M and inertias in matrix were rst predicted with a
function that modeled the dierent masses and inertias of the individual parts of the PacFlyer.
As a more sophisticated CAD model became available, the parameters were determined with it.
Once the prototype was built the center of gravity and total mass were measured. The total
mass presented below does however not consider the landing gear that was added for testing as
described in chapter 6. Given the small value for the non-diagonal entries of which are about a
factor of 200 smaller than the other entries their eect was neglected in the dynamics equations.
The parameters are
M
total
= 5.035 kg , CoG =
_
_
0.024
0
0.013
_
_
m, =
_
_
2.15 0 0.006
0 1.32 0
0.006 0 1.53
_
_
kg m
2
. (3.1.8)
3.2 Control
In the following the control in hover mode will be explained further. An overview over the control
scheme is given. Subsequently, the individual controllers will be explained in more detail.
Figure 3.4 gives a general insight into the control scheme. As illustrated a cascaded control
approach is adopted. The inner control loop contains an attitude and the outer loop a position
controller. The position controller sets the reference for the attitude controller. The detailed
description of both the attitude and the position controller and their respective reference signals
will be dealt with in the upcoming subsection 3.2.1 and 3.2.2. Finally, all control signals are
passed as an input signal into the system as described in the previous section 3.1.
Figure 3.4: Illustration of the structure of the general control approach
3.2.1 Attitude controller
Having gure 3.4 in mind, rst the inner attitude controller loop of the controller will be regarded
more closely. A more detailed illustration of this attitude controller is shown in gure 3.5.
For this inner controller a cascaded control approach was also adopted. In the inner loop of the
cascaded controller the angular rates are controlled with a PD controller. In the outer loop the
angles are controlled with a P controller. The input to the inner or outer loop is the dierence
between reference and actual rate or angle respectively. The output of the cascaded controller
Chapter 3. Hover Modeling and Control 20
after the angular rates controller block in gure 3.5 are the torques (torque signals) that the
system should achieve to stabilize its attitude angles , , .
For this controller design all angles are treated as separate SISO systems in the earth-xed frame.
This is possible because of a decoupling transformation that was developed and will be explained
in detail further below. This transformation maps the torques just mentioned and the thrust in
negative z-direction (pointing upward) to the forces of the propeller-assemblies and the rear tilt
angle. The transformation is therefore called Mapping to Actuators in gure 3.5. The desired
thrust in negative z-direction (pointing upward) that controls the altitude of the aircraft can be
either set manually by the pilot or is set by the position controller to stabilize the height of the
PacFlyer.
With the necessary forces and tilt angle in the rear obtained from the decoupling transformation
or mapping to actuators, the rear tilt angle and the propeller forces are mapped to their respective
electrical signals that are needed to generate them. This is illustrated by the green block to the
right in gure 3.5. The idea is to generate exactly the signals needed that will generate the
mapped forces of the propellers and the rear tilt angle in the system. This mapping is again
based on the tests discussed in subsection 4.1.1 and represents the exact inverse mapping to the
one found in the modeling subsection 4.1.1 about signal mapping. Therefore the two mappings
should cancel each other out. These signals are then nally the overall output of the controller
and serve as control signals to the aircraft system as displayed on the very right of gure 3.5.
Figure 3.5: Illustration of the structure of the attitude controller
Decoupling transformation for hover controller
As mentioned in the previous subsection 3.2.1 the attitude is controlled by treating the attitude
angles as three separate SISO systems. This is possible because of the decoupling transformation
or mapping that will be described in detail in the following.
The tricopter conguration in hover as described in section 2.2 is a MIMO system with strong
cross couplings of the inputs to the outputs and states of the system. To counteract this eect
a transformation was developed to decouple the system. This allows one to treat the system
as several separate SISO systems. For quadcopters this has already been achieved as shown by
Rudin [3]. Yet for the tricopter design one rst had to consider all the dynamics equations in
detail and then had to evaluate them. A walkthrough into the making of the transformation is
given below. Later an error analysis is given for the transformation.
21 3.2. Control
Figure 3.6: Illustration of the PacFlyer in hover mode with most important lengths. Thrusts
in orange, corresponding torques in black, tilt angle to tilt the rear thrust around the x-axis,
important lengths in red and labeled.
Given the system in gure 3.6 above, the dynamics equations are
_
_
_
_
F
z

z
_
_
_
_
=
_
_
_
_
F
fr
F
fl
F
rear
cos()
F
fr
L
s
+F
fl
L
s
F
fr
L
f
+F
fl
L
f
F
rear
cos() L
b

dragrear
sin()

dragright
+
dragleft
+
dragrear
cos() F
rear
L
b
_
_
_
_
. (3.2.1)
To make the drag torque a function of the corresponding force the following relationship 3.2.1
was used. This is necessary to have a working mapping between the forces F
z
and the torques

x,y,z
and the forces of the motors and the rear tilt angle .
is the angular speed of the individual propeller. b
i
is the thrust, d
i
the drag coecient that
corresponds to the angular speed. The mentioned relationship 3.2.1 between drag torque and
thrust is described as
T
i
= b
i

2
,
drag
i
= d
i

2

drag
i
= T
i

d
i
b
i
. (3.2.2)
Therefore the drag torque divided by the corresponding thrust was plotted for the PWM range
in which the regular ight takes place. The relationship was found to be almost constant as
predicted and the constant
d
i
/b
i
could be determined as shown in
k
front
=
d
front
b
front
, k
rear
=
d
rear
b
rear
.
Therefore the torques can be formed in the following way while taking into account the direction of
rotation of the propellers. When looking at the aircraft from above, the right rotor rotates clock-
Chapter 3. Hover Modeling and Control 22
wise while the left and the rear rotor rotate counterclockwise. The following torque relationships
are formed

frontright
= F
frontright
k
front

frontleft
= +F
frontleft
k
front

rear
= +F
rear
k
rear
.
With small angle approximation for the rear tilt angle << 1 the relationship
sin() = , cos() = 1
is assumed. The tilt angle has been shown to generally operate in a region of 15

. This has
been validated in simulation. Likewise, since the main use of tilting with angle is controlling
the yaw movement one can regard the created torque more closely. Under hovering condition
of the aircraft the torque in z-direction is around 3.3 N m at 15

. This has been shown to be

quite enough to stabilize the aircrafts yaw movement. Therefore the small angle approximation
is a valid simplication.
With all these relationships put together the nal matrix relationship is
_
_
_
_
F
z

z
_
_
_
_
=
_
_
_
_
1 1 1 0
L
s
L
s
0 0
L
f
L
f
L
b
k
rear
k
front
k
front
k
rear
L
b
_
_
_
_

_
_
_
_
F
rightfront
F
leftfront
F
rear
F
rear

_
_
_
_
. (3.2.3)
With this matrix relationship at hand, one only needs to invert it to obtain the desired decoupling
transformation. The decoupling relationship
_
_
_
_
F
rightfront
F
leftfront
F
rear
F
rear

_
_
_
_
= A
1
4x4

_
_
_
_
Fz

z
_
_
_
_
(3.2.4)
allows a mapping between the dierent torques and the force in z direction and the actuators
of the PacFlyer.
This in eect, decouples the system and allows one to treat the attitude angles and the height
as separate systems to be controlled.
Error estimation
An error assessment of the transformation was conducted to verify how well it is actually working.
For this a predened set of vectors of desired force F
z
and torques
x,y,z
were compared to the
result of what happens when this vector is rst mapped to the respective forces of the motors
and rear tilt angle and then used as an input to the system model. In theory with an ideal
and perfect transformation the result should be exactly what has been used as an input. With
the made assumptions in deriving the transformation this is not the case. The absolute error is
given by

errorabs
=
_
_
_
_
Fz

z
_
_
_
_
2

_
_
_
_
Fz

z
_
_
_
_
1
. (3.2.5)
23 3.2. Control
Where the rst vector denoted with subscript 2 is generated by transforming the reference vector
with subscript 1 as in
A
1
4x4

_
_
_
_
Fz

z
_
_
_
_
1
=
_
_
_
_
F
rightfront
F
leftfront
F
rear
F
rear

_
_
_
_
(3.2.6)
and using the result in the system. The vector with subscript 2 that is compared to the reference
vector 1 is found to be
_
_
_
_
Fz

z
_
_
_
_
2
=
_
_
_
_
F
fr
F
fl
F
rear
cos()
F
fr
L
s
+F
fl
L
s
F
fr
L
f
+F
fl
L
f
F
rear
cos() L
b

dragrear
sin()

dragright
+
dragleft
+
dragrear
cos() F
rear
L
b
_
_
_
_
. (3.2.7)
Figure 3.7: Graphical display of the relative error of the decoupling transformation of the torque
in z-direction
Most error evaluations show the same pattern. Relative errors are in the worst case around
20% in general but often exhibit sharp rises close to 0 N m input torque. At the same time the
absolute error is small around the points of sharp rises. A sample graph of the relative error
Chapter 3. Hover Modeling and Control 24
and absolute error is given in gure 3.7 and 3.8 respectively. The decoupling transformation
works well and has errors within reasonable limits which is ultimately proven by the robust ight
behavior experienced in hover mode testing described in chapter 6.
Figure 3.8: Graphical display of the absolute error in Nm of the decoupling transformation of
the torque in z-direction
3.2.2 Position controller
In a next step a position controller was developed. This controller sets the reference angle of the
attitude controller for the roll and pitch movement (angle and ) and the thrust in negative
z-direction and in this way controls the position. The yaw movement is not controlled by the
position controller. The gure 3.9 illustrates the general idea of the position controller. The
general body coordinates are hereby specied in gure 2.7.
The general idea for the hover controller is already in use for quadcopters as Rudin [3] states.
The same approach can be implemented for a tricopter setup as well. The concept of the position
controller is to have a total thrust pointing upward in the body system. The idea now is to tilt
the total thrust with certain body angles , so as to have the specied forces T
x
, T
y
in the
25 3.2. Control
forward and sideway direction. These forces in eect control the position of the aircraft. The
concept is illustrated in gure 3.9.
A nose down movement with a negative angle would tilt the total thrust forward and thus
accelerate the aircraft forward in x-direction. Likewise, a positive angle with which the aircraft
could be tilted around the forward x-axis would tilt the total thrust in positive y-direction along
the right wing and accelerate the PacFlyer in this direction. In this way the x and y position is
controlled. The z-height control is done by simply increasing or decreasing thrust in z-direction.
The total thrust is calculated with
T =
_
T
2
x
+T
2
y
+T
2
z
.
All thrusts T
x
, T
y
, T
z
are determined with a PID control design for the position. The necessary
angles , are then computed by evaluating the following transformation
1
T
R
T
(z, )
_
_
T
x
T
y
T
z
_
_
=
_
_
sin(
d
)cos(
d
)
sin(
d
)
cos(
d
)cos(
d
)
_
_
. (3.2.8)
The rotational matrix R
T
(z, ) is used to account for the rotation around the yaw axis with
angle . This ensures that the position is controlled in the earth-xed frame.
Figure 3.9: General idea of the position controller
Having calculated all thrusts the rotational transformation is evaluated with the desired angles
, as output. Finally, the outputs of the position controller are the two angles just mentioned
and the desired thrust in negative z-direction to stabilize the altitude. The angles control the
position in x and y direction and the thrust in negative z-direction controls the height of the
aircraft.
Chapter 3. Hover Modeling and Control 26
3.3 Simulation results
In the following subsections rst the attitude controller and then the position controller in sim-
ulation will be discussed. This should give a clearer picture on the kind of control authority the
user has over the system.
Attitude controller
In the gure 3.11a one can see the attitude controller for hover react to the disturbances displayed
on the right of the same gure. The attitude itself is shown on the left. Evidently, the controller
works well and is able to stabilize the attitude even though a strong disturbance torque of either
3 N m for pitch or 5 N m for roll is applied for two seconds each. The pilot of the PacFlyer
requested to only have yaw angular rate control instead of angle control. Therefore only the rate
of change of the angle around the yaw axis is controlled. All other angles are treated with the
described cascaded control loop approach mentioned in subsection 3.2.1.
0 5 10 15 20
50
0
50
time[s]
R
o
l
l
[

]
AttitudeRoll
0 5 10 15 20
0
20
40
time[s]
P
i
t
c
h
[

]
AttitudePitch
0 5 10 15 20
176
178
180
time[s]
Y
a
w
[

]
AttitudeYaw
(a) Attitude of the PacFlyer
0 5 10 15 20
0
5
time[s]
T
o
r
q
u
e

[
N
m
]
Disturbance Xdirection
0 5 10 15 20
0
2
4
time[s]
T
o
r
q
u
e

[
N
m
]
Disturbance Ydirection
0 5 10 15 20
1
0
1
time[s]
T
o
r
q
u
e

[
N
m
]
Disturbance Zdirection
(b) Disturbance torques of the PacFlyer
0 5 10 15 20
50
0
50
time[s]
A
n
g
u
l
a
r

r
a
t
e

[

/
s
]Angular rate body Xdirection
0 5 10 15 20
50
0
50
time[s]
A
n
g
u
l
a
r

r
a
t
e

[

/
s
]Angular rate body Ydirection
0 5 10 15 20
5
0
5
time[s]
A
n
g
u
l
a
r

r
a
t
e

[

/
s
]Angular rate body Zdirection
(c) Angular Rates (Body frame)
Figure 3.10: Attitude angles, angular rates and respective disturbances of the PacFlyer in hover
with attitude controller
27 3.3. Simulation results
Position controller
0 5 10 15 20 25 30
50
0
50
time[s]
R
o
l
l
[

]
AttitudeRoll
0 5 10 15 20 25 30
50
0
50
time[s]
P
i
t
c
h
[

]
AttitudePitch
0 5 10 15 20 25 30
175
180
185
time[s]
Y
a
w
[

]
AttitudeYaw
(a) Attidude
0 5 10 15 20 25 30
0
5
time[s]
T
o
r
q
u
e

[
N
m
]
Disturbance Xdirection
0 5 10 15 20 25 30
0
2
4
time[s]
T
o
r
q
u
e

[
N
m
]
Disturbance Ydirection
0 5 10 15 20 25 30
1
0
1
time[s]
T
o
r
q
u
e

[
N
m
]
Disturbance Zdirection
(b) Disturbances
0 5 10 15 20 25 30
30
20
10
time[s]
P
o
s
i
t
i
o
n

[
m
]
Position Xdirection
0 5 10 15 20 25 30
5
0
5
time[s]
P
o
s
i
t
i
o
n

[
m
]
Position Ydirection
0 5 10 15 20 25 30
200
199
198
time[s]
P
o
s
i
t
i
o
n

[
m
]
Position Zdirection
(c) Position
Figure 3.11: Positon controller simulation results
In gure 3.11 a simulation of the hover controller with combined position/attitude controller is
illustrated. It is shown to work properly. The disturbances to the right are rejected but have
to be counteracted more than with just the attitude controller since the original position has to
be reached again. For this simulation both the attitude and the position controller were active.
Otherwise the attitude would have been stable immediately after the disturbances as displayed
in gure 3.11a. The reference position was set to (200, 0, 200)
T
m. Again strong disturbances
are applied as in the attitude controller simulation.
Chapter 3. Hover Modeling and Control 28
Chapter 4
Cruise Modeling and Control
This chapter deals with the aircraft in cruise mode. Cruise ight is the mode which represents
the regular airplane ight. The cruise mode will be regarded in a brief overview, followed by
the modeling and control of the aircraft in cruise mode. Finally the performance of the cruise
controller will be evaluated in simulation.
4.1 Modeling
To test the characteristics of the aircraft in cruise ight a mathematical model has to be derived
rst. This then enables the user to test control designs and simulate them before physically
testing them. This introductory part of the section gives an overview over the system model in
cruise mode with the eects taken into account for modeling. Given the overall structure the
individual parts of the model will be dealt with in more detail.
Figure 4.1: Illustration of the complete model for cruise with controller, system model and
non-linearities
Figure 4.1 shows the system dynamics model, computational aerodynamics tool, speed scaler,
propeller input and saturations. To show the whole model with a closed control loop the attitude
29
Chapter 4. Cruise Modeling and Control 30
controller is also displayed. The system dynamics block is colored orange, the controller blue,
the speed scaler is grey and the aerodynamics tool is shown in green.
The following modeling subsections describe the individual modeling blocks of the overview gure
4.1.
To model the cruise mode of the PacFlyer system the following eects were considered respectively
neglected based on material by Rudin and Leutenegger [3].
System dynamics based on rigid body model
Interaction with ground and other solid objects are neglected
Aerodynamic forces (lift, drag) and torques of the main wing, the elevator and the rudder
respected
Drag of the fuselage is neglected
Drag of the extension booms and servo arms are neglected
Actuator limitations are considered
Propellers are assumed to be rigid
Gyroscopic forces and hub forces and torques are neglected
Inuence of the accelerated air of the propellers (alongside the wings) are neglected.
Similar to the hover mode model in 3.1 many of the system model assumptions remain the same
or similar, e.g. the system dynamics are also based on a rigid body model. The main and
crucial dierence is that the aerodynamic forces such as lift and drag of the main wing are now
considered as opposed to the hover model where these forces are neglected.
4.1.1 Control surface characteristics
The mapping of the control surface deections to PWM signals are based on measurements
with a digital angle gauge. Since the dependency of the control surface deection on the PWM
signals are almost linear this correlation was approximated by a linear function as was illustrated
similarly earlier in the hover mode in gure 3.2. From these measurements the limitations or
saturations of the servos range were found out as well. The saturations are displayed as a grey
block in the center of gure 4.1. The angle mapping itself was implemented on the microcontroller
but was not used in the model.
4.1.2 Aerodynamics calculations tool
With the control surfaces and various other variables such as the aircrafts velocity and attitude
one can calculate the aerodynamic forces and torques on the system.
The aerodynamic forces and torques could not be measured within the framework of the project,
but were calculated with a computational tool that was provided by Rudin and Leutenegger (K.
Rudin 2013, pers. comm., unreferenced). This aerodynamical force and torque calculation tool
is illustrated as the green block in gure 4.1. Eectively, the tool calculates the aerodynamic
forces and torques as a function of the following variables.
Inow velocity
Inow vortices
31 4.1. Modeling
Control surface deection
Propeller angular speed
More specically, the tool calculates the drag- lift-, and moment coecient for individual angle
of attacks, Reynolds numbers and ap deection based on Xfoil
1
to calculate a lookup table. For
Figure 4.2: Aerodynamics of a wing prole
simulation purposes this aerodynamic part then interpolates the current state of the system and
integrates the resulting forces and torques alongside the wing and estimates the propeller thrust
using blade element momentum theory. To estimate the downwash the vortex sheet theory has
been used. The aerodynamics tool fails however when the aircraft enters stall and generates
incorrect forces and torques.
4.1.3 Rigid body dynamics
The last system modeling block in gure 4.1 is the 6 DoF rigid body block shown in orange. It
describes the rigid body system dynamics as previously described for the hover mode in subsection
3.1.2. The gure 4.3 shows the rigid body model more closely together with aerodynamics tool
describes in subsection 4.1.2. Again as described for hover the forces and torques are input to
the system dynamics block. The system dynamics essentially represent a double integrator with
angular velocity, linear velocity, angles and position as output.
Figure 4.3: Cruise model
As described in the hover subsection 3.1.2 the parameters of the rigid body model, that is the
inertia and the weight, were estimated from the CAD model of the PacFlyer and measurements
of the prototype. For a more detailed treatment of the dynamics see the mentioned subsection
3.1.2.
1
A free computational program developed at MIT to evaluate the aerodynamic characteristics of airfoils
Chapter 4. Cruise Modeling and Control 32
4.2 Control
A controller is needed to stabilize and steer the system in general. In the case of cruise ight a
pilot can by himself also be able to stabilize the aircraft. When designing a controller it can be
tested on the system model before implementing and testing it on the physical prototype. The
dierent control modes that can be chosen for the cruise controller as well as dierent control
schemes will be discussed in the following. The whole model with controller can be regarded in
more detail in the gure 4.1. As the cruise ight mode is essentially the one of a regular airplane,
the controller is taken from the already implemented ArduPilot [17] for regular airplanes.
4.2.1 Control modes
For cruise ight there are four dierent control modes with which the aircraft can be steered all
of which are implemented and are taken from the ArduPilot [17]. Here is a brief description of
each one.
Manual: Directly passes the RC inputs to the actuators without feedback control. Used
for safety reasons and tests. The human pilot is the controller.
Stabilize: Tries to regulate the roll and the pitch angle automatically to zero; required for
autopilot mode
Auto: Flies to predened waypoints
RTL (return to launch): Return to launch coordinate; automatically activated when RC
loses control to system
4.2.2 Control scheme
Figure 4.4: Control Scheme for cruise ight
Figure 4.4 shows the basic idea of the control scheme for the cruise mode. As for the hover
controller, a cascaded control approach is used to realize the position controller. The inner loop
is an attitude controller for stable ight. At the outer loop an ArduPilot [17] bearing controller
sets a reference angle for roll and pitch to the attitude controller in order to reach specic
waypoints.
It additionally contains a speed scaler that scales the calculated control surface deection, since
for higher inow velocities the deections have much more eect. Therefore the system is more
33 4.2. Control
robust and will not begin to oscillate at higher speeds. The structure of this speed controller has
been adopted from the existing Arduplane [17] controller. The scaling factor is given by
= |

v
x
|.
Where is the speed scaler, a tuning parameter and v
x
the estimated speed in body x-direction.
The scaler gets limited with an upper and a lower bound. It then is multiplied with the control
input of the P and the D part of the controller and in this way scales some of variables of the
controller. The I is not scaled, as it could lead to a static error.
Attitude controller
The control strategy for the attitude in cruise ight is the same as for regular airplanes. In this
mode the PacFlyer has 4 control inputs to control the system.
Front propellers angular speed to regulate thrust in ight direction
Aileron deection to control the roll movements
Elevator deection to control the pitch movements
Rudder deection to control the yaw movements
As displayed in gure 2.4 the control surfaces ailerons, elevator and rudder control the attitude.
For reference the attitude angles are displayed in gure 2.7. The ailerons control the roll move-
ment with angle around the x-axis with an anti-symmetrical deection of both surfaces. The
pitch movement with angle is controlled by deecting the elevator. Finally, by deecting the
rudder the yaw movement with angle is controlled.
The inner attitude control loop is a simple PID controller that calculates the control surface
deection as a function of the angle error. As the system in the cruise mode is already almost
decoupled there is no need for a special decoupling as shown in the hover mode 3.2.1. Therefore
it is possible to control the system along one axis by only using one control surface conguration
as shown in the brief description in the previous paragraph. If there is for example an error along
the roll axis the controller deects the ailerons in a way to produce a torque to steer against this
error. With the current controller errors along the yaw axis are not regulated with the rudder.
The yaw can however be controlled manually by the pilot. For more detail to regulate the yaw
error see the upcoming part of the section 4.2.2.
Bearing controller
In order to y to a dened waypoint it is important to be able to y with a specic altitude and a
specic bearing or attitude. To achieve this, the outer control loop, i.e. the position controller
or bearing controller is used.
In gure 4.5 the functionality of the bearing controller is illustrated. Having a bearing error a
PID controller computes the reference angle. As the system is almost decoupled, these errors
can be looked at seperately as follows:
Given an altitude error the controller calculates a pitch angle reference to climb to the dened
altitude and Given the bearing error the controller calculates a roll angle reference to correct
the orientation ofthe system. These references are given an upper and lower saturation so as to
not destabilize the aircraft. Furthermore these angle references are then the input to the inner
attitude control loop.
Chapter 4. Cruise Modeling and Control 34
Figure 4.5: Position controller
4.3 Simulation results
In the following the cruise mode will be evaluated in simulation. First a simulation without
a controller will be conducted to assess the aerodynamic properties of the aircraft. Then the
PacFlyer is tested with the attitude controller for cruise under disturbances. Later the bearing
controller is evaluated.
Without controller
In gure 4.6 both the attitude and the position of the aircraft are displayed for a simulation with
all controllers turned o. One can see from the pitch attitude that the aircraft is aerodynamically
stable. When the system pitches downwards, the aerodynamic forces lead to a pitch upward
torque and vice versa. These movements have enough damping so that the oscillations around
the pitch axis decrease in amplitude with each oscillation. Small changes of the pitch angle of
5

are only achieved after a relatively long period of time of around 50 s.

0 10 20 30 40 50 60
40
20
0
time[s]
R
o
l
l
[

]
AttitudeRoll
0 10 20 30 40 50 60
40
20
0
time[s]
P
i
t
c
h
[

]
AttitudePitch
0 10 20 30 40 50 60
40
20
0
time[s]
Y
a
w
[

]
AttitudeYaw
(a) Simulation results of the attitude during cruise
without controller
0 10 20 30 40 50 60
0
2000
4000
time[s]
D
i
s
t
a
n
c
e

[
m
]
Position Xdirection
0 10 20 30 40 50 60
10
0
10
time[s]
D
i
s
t
a
n
c
e

[
m
]
Position Ydirection
0 10 20 30 40 50 60
500
0
500
time[s]
D
i
s
t
a
n
c
e

[
m
]
Position Zdirection
(b) Simulation results of the position during cruise
without controller
Figure 4.6: Simulation of the PacFlyer in cruise without controller
35 4.3. Simulation results
Attitude controller
0 5 10 15
0
10
20
30
tme|s|
R
o

|
Atttude-Ro
0 5 10 15
0
10
20
30
tme|s|
P

t
c
h
|

|
Atttude-Ptch
0 5 10 15
0
10
20
30
tme|s|
Y
a
w
|

|
Atttude-Yaw
0 5 10 15
0
100
200
tme|s|
M
o
m
e
n
t
|
N
m
|
Dsturbance X-drecton
0 5 10 15
0
50
100
tme|s|
M
o
m
e
n
t
|
N
m
|
Dsturbance Y-drecton
0 5 10 15
-1
0
1
tme|s|
M
o
m
e
n
t
|
N
m
|
Dsturbance Z-drecton
Figure 4.7: Simulation results for the attitude during hover with disturbances
In a next step the PacFlyer in cruise ight with attitude controller is simulated. In gure 4.7
the attitude along the three main axis directions is plotted against the time under inuence
of disturbances. As one can see the system has no problem handling this disturbances. The
controller achieves to regulate the roll and the pitch angles within about 2 to 3 s without causing
overshoot or miscellaneous unwanted eects.
Bearing controller
Figure 4.8 shows the results of the simulation of the bearing controller. When ying to a specic
waypoint one can calculate the needed bearing and altitude the system needs to y to the dened
waypoint. During this simulation the system tries to y with an altitude of 200 m and a yaw
bearing of 0

with initial conditions at altitude 180 m and 60

yaw bearing. The system can

reach the desired bearing within an acceptable range of time of around 10 s, without overshoots.
Chapter 4. Cruise Modeling and Control 36
0 5 10 15 20 25 30
50
0
50
time[s]
R
o
l
l
[

]
AttitudeRoll
0 5 10 15 20 25 30
0
10
20
time[s]
P
i
t
c
h
[

]
AttitudePitch
0 5 10 15 20 25 30
100
0
100
time[s]
Y
a
w
[

]
AttitudeYaw
(a) Attitude
0 5 10 15 20 25 30
0
500
1000
time[s]
D
i
s
t
a
n
c
e

[
m
]
Position Xdirection
0 5 10 15 20 25 30
0
50
100
time[s]
D
i
s
t
a
n
c
e

[
m
]
Position Ydirection
0 5 10 15 20 25 30
220
200
180
time[s]
D
i
s
t
a
n
c
e

[
m
]
Position Zdirection
(b) Position
Figure 4.8: Simulation result of bearing controller
Chapter 5
Transition Modeling and Control
In order to change from cruise mode to hover mode and vice versa a third ight mode i.e. the
transition is needed. This mode has to cope with the problem of integrating components of both
the hover and the cruise ight and is therefore more complicated. In the following sections the
general properties, the strategy to y during the transition phase as well as the modeling and
control during that time will be discussed. Concluding, simulation results for the transition from
hover to cruise and back will be presented and discussed.
5.1 Modeling
The transition mode combines both elements of the hover mode and the cruise mode and ideally
their interaction. Since the aerodynamic calculations get very complex during the transition
period, this has been worked on in much more detail in the context of another bachelor thesis by
Kober [18]. However, with the model used within this more control oriented thesis, it should be
possible to make some rough conclusions about the general feasibility of the transition. A detailed
graphic with both system model and controller is presented in gure 5.1. Within the scope of
this thesis the following simplications and restrictions for the system model in transition mode
were made or taken into account in addition to the ones made for the hover model in section 3.1
and the cruise model in section 4.1.
Drag of additional features such as landing gear is neglected.
Downwash of the airow of the propeller on the wing is neglected.
Same assumptions as for cruise model (see section 4.1)
At stall the aerodynamics calculations described in subsection 4.1.2 are not accurate.
The transition model as presented in gure 5.1 can be considered as both the hover and the
cruise model next to each other. All blocks that are present in the individual modes are now
present as well. In a nal step the forces and torques that the two models generate are combined
and serve as input to the 6 DoF rigid body model block shown in orange. To not account for the
propeller thrusts twice they are only considered for the hover model part as long as the hover
controller is active. Once deactivated the thrusts are introduced into the transition model from
the cruise mode part of the model in the block Propeller.
37
Chapter 5. Transition Modeling and Control 38
Figure 5.1: Illustration of the complete model for transition with controller, system model,
saturations and mappings
Due to the simplications presented above, mainly that the downwash of the propeller on the wing
is neglected, it is possible, that the real system will not act as expected. Therefore simulation
results should be taken as qualitative arguments for general feasibility of the transition while
having the risk of the made simplications in mind.
5.2 Control
Two control strategies were developed to handle the transition mode, one to transition from
hover to cruise and one from cruise to hover mode.
Hover to cruise transition strategy
In gure 5.2 the strategy to change from hover to cruise ight is presented. One slightly tilts the
front rotors to gain speed, until the wings carry most of its weight. This will be with a speed of
around 13 m/s, the stall speed of the system. During this phase both controllers the hover and
the cruise are activated. Afterwards the front propellers are tilted entirely to the front and the
hover controller will be deactivated.
Cruise to hover transition strategy
For the purpose of changing from cruise to hover ight, the idea is to slow down the front rotors,
tilt them upwards and carry on gliding. Then the hover controller gets activated and pitches
39 5.2. Control
Figure 5.2: Transition strategy, hover to cruise
the prototype backwards to reduce the speed, until it is in normal hover mode with little or no
forward speed. This process is illustrated in gure 5.3.
Figure 5.3: Transition strategy, cruise to hover
For the following simulations of the transition phase both the hover and the cruise ight controller
are active. Since the hover controller has to cope with increasing cross-coupling with increasing
tilt angles forward in ight direction of the front rotors, it is not advisable to have it fully active
at high tilt angles. The control authority of the hover controller gets lower with increasing tilt
angles. Roughly speaking e.g. the roll movement is stabilized in hover by having a dierential
thrust of the two front rotors. After tilting the rotors to the front the same dierential thrust
would also introduce a torque in z-direction and inuence the yaw movement. This is highly
undesirable as control authority is lost. Therefore for the simulation the front propellers were
tilted by only 20

with an active hover controller. Subsequently, the controller gets deactivated

and the propellers immediately tilt entirely to the front. The real system would not be able
to tilt the propeller as fast to the front or upwards. Some adaptations of the controller would
be required. Therefore a weigthing of the hover controller was implemented on the physical
prototype as
w =
_
_
_
1 if
front
< 20

1

front
20
20
if 20

<
front
< 40

0 if
front
> 40

with
front
as the tilt angle (0

equates to propeller pointing upwards) and w as the weighting

factor that scales the desired angular rates by multiplying them with factor w. As the cruise
controller has almost no control authority at low speeds there is no need for a weighting of the
cruise controller.
Chapter 5. Transition Modeling and Control 40
5.3 Simulation results
To test the mentioned control strategies simulations were of these were made. Again due to
simplications only general feasibility can be inferred from the results.
Hover to cruise transition
The simulation with this model to change from hover to cruise ight can be seen in gure 5.4. At
the beginning, the front rotors are tilted by 20

to the front until the system has a speed of 15 m/s.

Then the rotors are tilted completely to the front and the hover controller gets deactivated. The
result of the simulation shows, that the system accelerates to the desired velocity without getting
unstable.
0 5 10 15 20 25 30
-20
0
20
tme|s|
R
o

|
Atttude-Ro
0 5 10 15 20 25 30
-20
0
20
tme|s|
P

t
c
h
|

|
Atttude-Ptch
0 5 10 15 20 25 30
-20
0
20
tme|s|
Y
a
w
|

|
Atttude-Yaw
0 5 10 15 20 25 30
0
10
20
tme|s|
V
e

o
c

t
y
|
m
/
s
|
Veocty X-drecton
0 5 10 15 20 25 30
0
10
20
tme|s|
V
e

o
c

t
y
|
m
/
s
|
Veocty Y-drecton
0 5 10 15 20 25 30
-5
0
5
tme|s|
V
e

o
c

t
y
|
m
/
s
|
Veocty Z-drecton
Figure 5.4: Simulation of the transition from hover to cruise ight with attitude and velocity
displayed
Cruise to hover transition
To get a rough estimation of how perturbing the inuence of the aerodynamic forces and torques
are for the hover controller the following simulation was made. Here the initial speed is set to
20 m/s and the hover controller that regulates the speed to zero is activated (cruise controller
deactivated). The results are shown in gure 5.5. As seen in the plots, the controller succeeds
to slow down the system while stabilizing it. This data is therefore a good indicator that the
hover controller should not have too great diculties in stabilizing the system, while ying with
forward speed.
41 5.3. Simulation results
0 5 10 15 20 25 30
-20
0
20
tme|s|
R
o

|
Atttude-Ro
0 5 10 15 20 25 30
-20
0
20
tme|s|
P

t
c
h
|

|
Atttude-Ptch
0 5 10 15 20 25 30
-20
0
20
tme|s|
Y
a
w
|

|
Atttude-Yaw
0 5 10 15 20 25 30
0
10
20
tme|s|
V
e

o
c

t
y
|
m
/
s
|
Veocty X-drecton
0 5 10 15 20 25 30
0
10
20
tme|s|
V
e

o
c

t
y
|
m
/
s
|
Veocty Y-drecton
0 5 10 15 20 25 30
0
10
20
tme|s|
V
e

o
c

t
y
|
m
/
s
|
Veocty Z-drecton
Figure 5.5: Simulation of transition from cruise ight to hover with attitude and velocity dis-
played
Chapter 5. Transition Modeling and Control 42
Chapter 6
Implementation and Testing
With designed controllers for the dierent ight modes with satisfying simulation results, im-
plementing the controllers on a microprocessor and later prototype testing is an important next
step.
6.1 Implementation
As explained in chapter 2 an ArduPilot mega 2.5 microcontroller has been used as a platform to
implement the control algorithms. As explained in previous sections the controller has a cascaded
structure. Since there were problem with the computation time of the processor the controller
needed adaptations as with the whole control algorithm at 100 Hz the processor was not able
to meet all the task deadlines resulting in deactivation of the motors. Therefore now, the inner
control loop operates with 100 Hz and the outer loop mainly at 50 Hz. The subsequently done
tests proved that this is still fast enough to stabilize the system. For a more detailed insight in
the software structure refer to appendix A.
6.2 Testing
Due to time constraints in the accompanying student project only the hover controller was
experimentally validated. The testing of the PacFlyer in hover mode will therefore be described
in the following with a focus on the control aspects of testing. After implementing the simulation
based controller for the hover mode it could subsequently be tested.
The full testing of the hover mode includes the tuning of the hover attitude controller from
subsection 3.2.1, a brief discussion about the existing predened controllers namely the standard
Ardupilot controller [17] and a general assessment of the then used controller in hover ight.
To tune the controller further in experiment for hover mode, it is recommended to test the
system one degree of freedom at a time, as otherwise cross-coupling eects would complicate the
process. In gure 6.1 this test setup is shown. With this setting the hover controller gains for the
pitch and roll attitude could be tuned on the real system under inuence of manual disturbances
and target angles given with the RC. In the process of tuning, the self-made hover attitude
controller discussed in subsection 3.2.1 was compared to the predened tricopter controller of
the ArduPilot. As anticipated the performance of this predened controller was not satisfying,
since it was designed for a simple symmetric tricopter with three identical rotors. In fact because
the controller was tailored specically to a symmetric tricopter design it was not able to stabilize
43
Chapter 6. Implementation and Testing 44
the aircraft at all. This strongly supported the decision made before of designing a new hover
controller from scratch with a proper decoupling.
Fixed
(a) Tuning of pitch
Fixed
(b) Tuning of roll
Figure 6.1: Tuning 1 degree of freedom
With a controller that works at least for the individual degrees of freedom of the real system,
the full free system hover ight could be tested, as is shown in gure 6.2. For both indoor and
outdoor tests ight gears were used as displayed in gure 6.2 and 6.3. These were used for robust
testing purposes but were not included in the modeling since the aircraft is designed to eventually
y without the landing gear. The roll and pitch controller gains did not need any further tuning,
since the result of the single axis attitude controller were already satisfying. The yaw controller
gain needed little adaptions to make it more aggressive, which was to be expected, as it was not
tuned on the real system before.
All in all the simulation based gains were already able to control the aircraft. A great change
was done for the derivative part of the inner angular rate loop. Due to too much noise this part
was given less weight and now has a value around
1
/10 of the simulation based value. All other
gains were also tuned but remain within the same order of magnitude.
After tuning the free system, one could observe irregular small oscillations of the prototype
during this indoor test. The higher the aircraft ew the less oscillations it had. The reason for
these oscillations are the propeller induced turbulences of the air in combination of the small
volume of air in the room. During the outdoor tests as shown in gure 6.3 with logged ight data
in gure 6.4 these oscillations disappeared, which supports the theory above. The performance
of the hover controller outdoors was better than expected, allowed a well controlled hover ight
and was fully satisfying.
In gure 6.4 a plot of the logged attitude data during one test ight is shown. The roll and pitch
axes are very stable and never above an angle of 15

. The low frequency oscillations are due

to the navigation inputs of the pilot to y the system. During this test the pilot performed an
S-curve ight which can be seen in the yaw angle in the plot.
45 6.2. Testing
Figure 6.2: Tuning of the free system
Figure 6.3: Outdoor hover test
Chapter 6. Implementation and Testing 46
235 240 245 250 255 260 265
20
0
20
40
60
80
100
120
140
160
180
200
SCurve
Time [s]
A
n
g
l
e

[

]


Roll
Pitch
Yaw
Figure 6.4: Logging data of outdoor hover test
Chapter 7
Conclusion and Outlook
The bachelor thesis clearly demonstrated the theoretical feasibility of a controlled ight envelope
for the aircraft PacFlyer that was developed in a one-year-long student project. The hover
mode was experimentally validated.
All three ight modes hover, cruise and transition have been mathematically modeled and con-
trollers for these modes were developed. These have shown to be working well in simulation.
The hover and cruise mode were modeled accurately taking into account similar designs and
concepts. However, the transition model is strongly simplied and therefore serves more as a
general guideline than a precise prediction of reality.
All three controllers were also implemented on the actual prototype. The controller for the
hover mode was then experimentally tested and showed to work very well and allow for a stable
controlled ight. Further tests for cruise and transition mode will still have to be performed due
to time constraints within the student project. With regard to future work, dierent control
concepts such as model predictive control, optimal control methods such as a linear-quadratic
gaussian controller or even nonlinear control concepts could be used. In the long run autonomous
take o and landing could be realized. Regarding the hardware, a faster microprocessor than
the currently used Atmega 2560 would allow the use of more complex control algorithms or a
higher controller frequency. In a further step the weight of the aircraft could be reduced and the
thrust of the propeller-assemblies increased. This would provide the aircraft with more control
authority. With a working controller and either a ground-station or localization and mapping
algorithms one might then be able to use the PacFlyer for missions such as the agricultural
mapping of crops on elds with a camera.
In conclusion, the thesis shows that the aircraft concept PacFlyer can most likely perform a
whole ight envelope with vertical take o, a transition to cruise ight and back and nally a
vertical landing. To this date a controlled hover ight of the PacFlyer was successfully tested
permitted by the work presented in this thesis.
47
Chapter 7. Conclusion and Outlook 48
Appendix A
Software structure
In this section the structure of the software is presented as described by Faude and B uchele [19].
A cascaded control approach was adopted. The software has loops with dierent rates as shown
in the following gures. For control issues the most important loops are the inner 100 Hz and
the outer 50 Hz loop that were addressed in chapter 6. The slow loops mentioned in gure A.4
have no important meaning for this thesis. For more details on the software see the mentioned
reference to Faude and B uchele [19].
49
Appendix A. Software structure 50
Initialize ArduPlane
Reset
Calibrating IMU, barometer
Initializing motors
Runs +1
2 IMU Samples ready?
100 Hz Loop
# Runs odd?
50 Hz Loop
5 x 10 Hz Loop
# Runs
>= 100 ?
Reset # Runs
Accumulate compass sensor
data
Time left
>= 1 ms ?
1 Hz Loop
Programmablauf
N
J
N
J
J
N
N
J
Init
Main Loop @ 100Hz
Figure A.1: Main Structure of the Software
51
fast_loop()
100 Hz Loop
Rear radio control
Read IMU and update
attitude
Hover ?
J
N
Transition ?
J
N
Hover controller
Motor-, servo drive
return
Transition controller
Motor-, servo drive
Error
Cruise ?
J
N
Cruise controller
Motor-, servo drive Failsafe
Figure A.2: Structure of the 100Hz loop
Appendix A. Software structure 52
fifty_hz_loop()
50 Hz Loop
return
Hover mode
J
N
Motor Control
Logging flight data
Send messages to GCS
Check failsafe conditions
Calculate Bearing error
Update flightmode for cruise
Recieve data from GCS
Send flight data and onboard
parameter to GCS
Figure A.3: Structure of the 50 Hz loop
53
Medium Loop (10 Hz)
Update GPS-data
Calculate ground speed
Read magnetometer
Run 1
Read flight mode
Run 2
Read airspeed sensor
Read RSSI
Read barometer
->altitude
Run 3
Logging
Run 4
Read current and voltage
Call slow loops
Run 5
Main loop calls with 50 Hz one of five medium-runs 10 Hz per medium-run
Read control mode
Tiltmechanism control
Navigation
medium_loop()
return
Figure A.4: Structure of the 10 Hz loop
Appendix B
Motor selection
For the actuation of the three rotors it was decided to use brushless DC motors. In order to
drive them an electronic speed control (ESC) is needed. Via PWM signal it is possible to give
the desired value to the ESC, which then steers the motor. It was determined to use the Castle
Phoenix ICE Lite 50 as it matches the requirements of the projects system specications and
does not need additional cooling.
Figure B.1: Castle Phoenix ICE Lite 50
B.1 Front motors
During the project the design had to be changed from a variable pitch rotor to a xed pitch one.
Therefore also the motors had to be adapted as with the new rotors a higher propeller speed
is needed. The winner of the motor evaluation was nally the Turnigy Multistar 4830-480 kV.
The detailed specications can be seen in gure B.1. These specications are needed to derive a
physical model in order to simulate the actuator dynamics and additionally provide information
about the maximum power, to estimate the saturations.
54
55 B.2. Rear motor
Table B.1: Turnigy Multistar 4830-480 kV
Turnigy 4830-480 kV
Internal resistance 0.06
No-load current 1.2 A
Motor speed constant (k
V
) 480 rpm/V
Weight 154 g
Maximum power 680 W
Figure B.2: Turnigy Multistar 4830-480 kV
B.2 Rear motor
As the rear rotor is smaller than the front rotors it also has to spin faster to achieve a similar
thrust. Hence also another motor would be more ecient. It was decided to use the Scorpion
SII-3014-830kv with the specications seen in table B.2.
Figure B.3: Scorpion SII-3014-830kv
Table B.2: Scorpion SII-3014-830kv
Scorpion SII-3014-830kv
Internal resistance 0.042
No-load current 1.06 A
Motor speed constant (k
V
) 830 rpm/V
Weight 129 g
Maximum continuous power 550 W
Appendix B. Motor selection 56
References
[1] K. J. Astrom, Control System Design. California Institute of Technology, Pasadena, USA,
2002.
Available: http://www.cds.caltech.edu/murray/courses/cds101/fa02/caltech/astrom-
ch6.pdf.
[2] L. Guzzella, Analysis and Synthesis of Single-Input Single-Output Control Systems. Zurich:
vdf Hochschulverlag, 3rd ed., 2011.
[3] R. Siegwart, S. Leutenegger, and K. Rudin, Unmanned Aircraft Design, Modeling and
Control. Lecture Notes at ETH Z urich, 2013.
Available: http://www.asl.ethz.ch/education/master/aircraft/.
[4] K.-J. Barsk, Model Predictive Control of a Tricopter, Master thesis, Linkopings Univer-
sitet, Linkoping, Sweden, 2012.
[5] S. Salazar-Cruz, F. Kendoul, R. Lozano, and I. Fantoni, Real-Time Control of a Small-
Scale Helicopter Having Three Rotors, in Proceedings of the 2006 IEEE/RSJ International
Conference on Intelligent Robots and Systems, (Beijing, China), IEEE, October 2006.
[6] J. P. How, Aircraft stability and control. Lecture Notes at MIT Opencourseware, 2004.
Available http://ocw.mit.edu/courses/aeronautics-and-astronautics/16-333-aircraft-
stability-and-control-fall-2004/index.htm.
[7] B. M. Albaker and N. A. Rahim, Flight path pid control for propeller-driven xed-wing un-
manned aerial vehicles, International Journal of the Physical Sciences, vol. 6(8), pp. 1947
1964, April 2011.
Available: http://www.academicjournals.org/IJPS.
[8] A. E. Bryson, Control of Spacecraft and Aircraft. Princeton University Press, 1994.
[9] S. Carlson, Introduction to the Orange Hawk Project. Webpage, March 2013.
Available: http://www.diydrones.com/proles/blogs/the-orange-hawk-tricopter-ying-
wing-vtol-uav.
[10] P. Fan, X. Wang, and K.-Y. Cai, Design and Control of a Tri-Rotor Aircraft, in 8th IEEE
International Conference on Control and Automation, (Xiamen, China), pp. 19721977,
IEEE, June 2010.
[11] D. A. Ta, I. Fantoni, and R. Lozano, Modeling and Control of a Tilt tri-rotor Airplane,
in American Control Conference, (Fairmont Queen Elizabeth, Montreal, Canada), AACC,
June 2012.
57
References 58
[12] D. P. Raymer, Aircraft Design: A Conceptual Approach. AIAA, 4th ed., 2006.
[13] D. Lehmann, Mechanical Design of a Rotor Tilt Mechanism for a VTOL UAV, Bachelor
thesis, ETH Z urich, Zurich, Switzerland, 2013.
[14] J. Wendel, Integrierte Navigationssysteme. Munich, Germany: Oldenbourg Wis-
senschaftsverlag GmbH, 2007.
[15] G. Andersson, Elektrotechnik II. Lecture Notes at ETH Zurich, 2012.
Available: http://www.eeh.ee.ethz.ch/en/eeh/education/courses/viewcourse/227-0076-00l-
1.html.
[16] A. Noth, Design of Solar Powered Airplanes for Continuous Flight. PhD thesis, ETH Z urich.
No. 18010, 2008.
[17] DIY Drones Development Team, ArduPilot v2.70, 2013.
Available: http://ardupilot.com.
[18] S. Kober, Aerodynamic Analysis of a Tri-tiltrotor VTOL UAV, Bachelor thesis, ETH
Z urich, Zurich, Switzerland, 2013.
[19] M. Faude and R. B uchele, Bachelorarbeit Elektrotechnik ETH-Fokusprojekt PacFlyer,
Bachelor thesis, ZHAW Winterthur, Winterthur, Switzerland, 2013.