Nonlinear Control of an Aerobatic RC Airplane
MASSA CHUSETTS INSTITUTE
by
0 F TECHNOLOGY
Joshua John Bialkowski
J UN 2 3 2010
B.S., Georgia Institute of Technology (2007)
LIBRARIES
Submitted to the Department of Aeronautics and Astronautics
in partial fulfillment of the requirements for the degree of
Master of Science in Aeronautics and Astronautics
ARCHIVES
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
May 2010
@ Massachusetts Institute of Technology 2010. All rights reserved.
Author ..........
.~.
D
.....-.--...--.-.ar
autics and Astronautics
May 21, 2010
o%
Certified by.....
Prof Emilio Frazzoli
Associate Professor of Aeronautics and Astronautics
Thesis Supervisor
/
Accepted by.............
/
/
IA
Eytan H. Modiano
Associate Professor of Aeronautics and Astronautics
Chair, Committee on Graduate Students
Nonlinear Control of an Aerobatic RC Airplane
by
Joshua John Bialkowski
Submitted to the Department of Aeronautics and Astronautics
on May 21, 2010, in partial fulfillment of the
requirements for the degree of
Master of Science in Aeronautics and Astronautics
Abstract
An automatic flight controller based on the ideas of backstepping is applied to an
aerobatic RC airplane. The controller asymptotically tracks a time-parameterized
position reference, and depends on an orientation look-up rule to detemine the vehicle
orientation from a desired acceleration. A coordinated-flight look-up rule compatible
with the controller provides a nominal level of capability for traditional flight trajectories. A generalized coordinated look-up rule compatible with the controller provides
more advanced capability, including stability for high angle of attack and hovering
maneuvers, at the expense of an additional requirement from the reference trajectory.
Basic simulation results are used to verify the controller, and a simulation software
framework is described which will enable more extensive simulation and provide a
platform for the final controller implementation.
Thesis Supervisor: Prof. Emilio Frazzoli
Title: Associate Professor of Aeronautics and Astronautics
4
Acknowledgments
Foremost, I thank my family for supporting me in my academic pursuits and always
taking an interest in my work, even if I couldn't always provide a simple explanation
of what that was.
I also thank my advisor, Emilio Frazzoli for the many excellent ideas and the advice
he has given me, as well as the other professors here at MIT: Jon How, John Deyst,
and Jean-Jaques Slotine, who have provided me with the foundations of everything
I've learned in this field.
Thank you also to my professors from Georgia Tech's Aerospace Engineering department, especially J.P. Clarke, Wassim Haddad, Panagiotis Tsiotras, Eric Johnson,
and Jerry Seitzman, for the excellent education that has prepared me well for my
graduate studies.
Lastly, I would like to thank the contributors, maintainers, and communities of the
many open-source software packages that made it possible to produce this document,
and that I've used in my research. In particular, thank you Irrlicht, wxWidgets, and
FFMPEG communities for these excellent libraries I have used in my simulations,
the GIT and SVN communities for the invaluable version control software that I've
used. Thank you LaTeX, Tikz/PGF, and Inkscape maintainers and communities for
the fantastic software that made creating this document possible.
6
Contents
I Introduction
1.1
M otivation . . . . . . . . . . . . . . . . . .
1.2
Problem Description ..............
1.3
Previous Work
1.4
Overview of Chapters . . . . . . . . . . . .
. . . . . . . . . . . . . . .
17
2 Aircraft Model
3
2.1
The Aircraft . . . . . . . . . . . . . . . . .
17
2.2
Aerodynamic Model
. . . . . . . . . . . .
20
2.3
Propeller Model . . . . . . . . . . . . . . .
24
2.4
Complete Force Model . . . . . . . . . . .
25
2.5
Finite Section Model . . . . . . . . . . . .
25
State Parametrization
27
State .........................
27
3.1
4 Design of a Non-linear Controller Inspired by Backstepping
31
4.1
Overview of Backstepping
. . . . . . . . . . . . . . . . . . . .
31
4.2
Backstepping Applied to Flight Control . . . . . . . . . . . . .
33
4.3
Translational Controller
. . . . . . . . . . . . . . . . . . . . .
35
4.4
Orientation Controller
. . . . . . . . . . . . . . . . . . . . . .
36
4.5
Backstepping the Acceleration . . . . . . . . . . . . . . . . . .
38
7
5
6
7
8
Coordinated Flight
43
5.1
Orientation Look-up
5.2
Lower-bound Saturation on Acceleration
. . . . . . . . . . . . . . . .
47
5.3
Simulation Results and Limitations . . . . . . . . . . . . . . . . . . .
48
. . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3-Coordinated Flight
51
6.1
Definition of 3-Coordinated Flight . . . . . . . . . . . . . . . . . . . .
52
6.2
#-Coordinated
Orientation Solution . . . . . . . . . . . . . . . . . . .
53
6.3
Simulation Results and Limitations . . . . . . . . . . . . . . . . . . .
56
Simulation Architecture
59
7.1
A rchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
7.2
Object-Oriented Design. . . . . . . . . . . . . . . . . . . . . . . . . .
62
7.3
Visualization
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
7.4
Math Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
7.5
User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
Conclusions
67
8.1
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
8.2
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
A Aerodynamic Force Modeling
71
A.1 Two-Dimensional Thin Airfoil Theory . . . . . . . . . . . . . . . . . .
71
A.2 Prandtl's Lifting Line Method . . . . . . . . . . . . . . . . . . . . . .
76
B Proofs from Chapter 4
B.1
87
Proof of Geometric Relationship Between a Vector and Rotation . . .
87
B.2 Proof of Finite Limit . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
List of Figures
1-1
Recon Through a City . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1-2
Task Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2-1
Nexus Photograph
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2-2
Nexus Solid Model
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2-3
Modeling Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2-4
Body Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2-5
Velocity Components . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2-6 Velocity Components in Prop Wake . . . . . . . . . . . . . . . . . . .
23
2-7
Finite Element Model . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2-8
Quarter Chord
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4-1
General Non-linear System . . . . . . . . . . . . . . . . . . . . . . . .
32
4-2
Applied Inner Control
. . . . . . . . . . . . . . . . . . . . . . . . . .
32
4-3
Backstepped Input . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4-4
Backstepping Block Diagram . . . . . . . . . . . . . . . . . . . . . . .
34
5-1
Coordinated Flight . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5-2
Coordinated Free Body Diagram
. . . . . . . . . . . . . . . . . . . .
44
5-3
Feasible Accelerations
. . . . . . . . . . . . . . . . . . . . . . . . . .
48
5-4
Following a Helical Trajectory . . . . . . . . . . . . . . . . . . . . . .
49
5-5
Hover-Hover Trajectory . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5-6
Angular Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6-1
#-Coordination
52
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-2
Multi-point Hover . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
7-1
Scenario . . . . . . . . . . . . . . .
. . . . . . . . . .
60
7-2
Nexus Data Flow . . . . . . . . . .
. . . . . . . . . .
62
7-3
Visualization
. . . . . . . .. . . . .
. . . . . . . . . .
63
7-4
Thread Separation
. . . . . . . . . .
65
A-i
Lifting Element as a Streamline
. . . . .
71
A-2 Vortex Sheet Model of Flat Plate
. . . . .
72
A-3 Downwash Due to Vortex Element
. . . . .
72
A-4 Change of Variables . . . . . . . . .
. . . . .
73
A-5 Circulation Line Integral . . . . . .
. . . . .
74
A-6 Geometry of Forces . . . . . . . . .
. . . . .
75
A-7 Wing as a Bound Vortex . . . . . .
. . . . .
77
A-8 Finite Vortices . . . . . . . . . . . .
. . . . .
77
A-9 Vortex Sheet . . . . . . . . . . . . .
. . . . .
77
A-10 Induced Angle of Attack . . . . . .
. . . . .
78
A-11 Change of Variables . . . . . . . . .
. . . . .
80
A-12 Circulation Result . . . . . . . . . .
. . . . .
85
A-13 Lift Coefficient Result
. . . . .
85
. . . . . . . . .
. . . . . . .
B-1 Geometry of Vector Relationship
.
B-2 View From r . . . . . . . . . . . . .
List of Tables
Component Mass Properties . . . . . . . . . . . . . . . . . . . . . . .
19
2.2 Nexus Moments of Inertia . . . . . . . . . . . . . . . . . . . . . . . .
20
2.1
12
Chapter 1
Introduction
1.1
Motivation
The history of Unmanned Aerial Vehicles (UAVs) is short, and their marketability is
still being tested as their commercial use rises.
T raditionally,
their use has been most
prominent in places where an autonomous flight vehicle can replace a human piloted
one. In many cases, the mission parameters remain the same as for a human piloted
mission, only the human pilot is taken out of the equation (to reduce the chance of
injury or loss of life, for instance). A UAV's applicability to its mission, therefore, is
often centered around its ability to perform like a traditional aircraft. Naturally, this
leads their design and manufacture to somewhat mimic that of unmanned aircraft.
However, as the public become more aware of their use and their potential, UAVs
have begun to realize applicability in their own right. Carrying a human pilot often
yields certain restrictions on how the craft is used, but without a human pilot as a
factor, there is growing demand for vehicles that stretch the bounds of this performance envelope.
There are many cases where small UAVs show significant potential. If we think
about military applications, remote piloted drones are already used extensively for reconnaissance and munitions deployment. In reconnaissance missions in particular, the
ability to deploy a large number of small vehicles to search a large area and identify
potential threats, or potential target locations can greatly reduce the manpower required for the task. An example mission might require a vehicle flying into a crowded
city, maneuvering through various obstacles, observing certain locations, and then
returning, as shown in figure 1-1. This kind of a mission may lead to some conflicting design requirements. The desire maneuver around buildings, and the potential
need to stop and perform extended observations would tend to require a rotorcraft,
capable of quick maneuvering and ability to hover. The desire to fly in from a remote
location, or traverse large distances, would tend to require a fixed wing aircraft for
better efficiency.
a-/
Figure 1-1: Recon Through a City
Figure 1-2: Task Assignment
A more commercial example might be the use of UAVs for pickup and delivery
over a large area. If we think of a multi-agent task assignment type of situation, where
we have many aircraft flying from a depot, arriving pick up locations, acquiring the
cargo, and then flying to deliver location (illustrated in figure 1-2), we again see the
conflicting need for high maneuverability, as well as high efficiency.
One way to address these kinds of needs, is to use somewhat conventional aircraft,
in an unconventional manner.
In particular, small airplane-like UAVs with high
thrust-to-weight ratio, can conceivably achieve high maneuverability and hovering
like a helicopter, but retain the high efficiency of level flight for traversing large
distances. However, designing an automatic controller capable of both traditional
flight, and advanced maneuvering, presents a serious challenge. This document seeks
to address the problem of designing such a controller, that naturally and efficiently
can control a high thrust-to-weight ratio aircraft in a manner that is consistent for
both steady level flight and high angle-of-attack maneuvering.
1.2
Problem Description
The aircraft considered here is a commercial, off-the-shelf remote control (RC) aircraft designed for hobbyist aerobatic pilots. We aim to design a controller for this
aircraft that will track a prescribed time-parametrized position trajectory, with provable asymptotic stability.
1.3
Previous Work
The feasibility of achieving hover and level flight for these kinds of vehicles has been
demonstrated. In [2], Frank et al. present a linear controller with gain scheduling
to provide similar capabilities as those considered here. Other non-linear techniques
have been applied to vehicles that are similar. In [5], Hauser, Sastry, and Meyer
present a nonlinear controller for a V/STOL aircraft using input-output feedback linearization. They demonstrate an approximate dynamic inversion method that allows
for controllability despite "slightly" non-minimum phase behavior. In [4], Hauser and
Hindman present a treatment of highly maneuverable aircraft on a state manifold
that allows for generating aggressive feasible trajectories. Furthermore, backstepping
has been extended to dynamic systems on manifolds. In [3], Frazzoli, Dahleh, and
Feron present a nonlinear control design for autonomous helicopters that is based on
backstepping. It is this design that serves as a basis for the design presented here.
The general theory of integrator backstepping is outlined in many textbooks on
non-linear control, such as Khalil's [7]. The treatment of aerodynamics used in modeling the vehicle can found in textbooks by Anderson [6] and Bertin and Smith [1].
Recent work by Russel, Cory, and Tedrake [12] has validated the simple aerodynamic
model for these types of planes even at high angle of attack. Nelson's textbook [10]
provides a useful look at modeling control surfaces for a fixed wing aircraft. Prouty's
textbook [11] includes an introduction to momentum theory that is is used in modeling the propeller's influence on the vehicle dynamics. Lastly, the use of homogeneous
coordinates to describe the vehicle state and rigid body equations is presented in
Murray's et al. textbook [9].
1.4
Overview of Chapters
In chapter 2, the manufactured characteristics of the aircraft are noted, and the
process of modeling the physical parameters is outlined and results recorded. Also
in this chapter, a model for the flight dynamics is presented. Details on some of the
calculations and methods used are given in appendix A. Chapter 4 details the design
of a backstepping inspired controller for trajectory tracking, based on the model in
chapter 2, and using a generic definition of an orientation look-up rule with assumed
characteristics. Some of the tangential details of this design are verified in appendix
B. Chapters 5 and 6 present details for two orientation look-up rules compatible with
the design in chapter 4, and some conclusions about each. Chapter 7 presents details
of a simulation architecture that was built to verify the control design, and some
additional applications intended for that architecture. Chapter 8 provides some brief
concluding remarks about this design, and some extensions for future work that is
planned.
Chapter 2
Aircraft Model
The vehicle targeted for implementation and demonstration of this controller design
is an off-the-shelf indoor flight competition RC airplane made by Nexus. This chapter
will describe the details of the plane and its operation, and the dynamic model that
was developed for it.
2.1
The Aircraft
The Nexus ARF Indoor 3D Plane is a foam construction aerobatic airplane. The
ARF acronym stands for "Almost Ready to Fly", meaning the electronics (servos, receiver, battery, engine controller, and engine) were not part of the kit. It is primarily
composed of a set of 3mm Depron foam sheets, with 0.05" (1.2mm) carbon fiber rod
struts. The airplane is outfitted with three Futaba S3108m servos, a Axi Gold Line
2203/52 engine and an 8" Graupner Slow-Fly propeller with 4.5" pitch. The radio
receiver is a GWS micro 4 receiving a standard radio control style Pulse-Position
FM signal, and generating Pulse-Width Modulated servo and motor commands. The
engine is controlled via a JETI Advance Plus 18 Electronic Speed Control (ESC). A
photo of the outfitted aircraft is shown in figure 2-1.
The three servos actuating the control surfaces do so in the traditional manner.
One channel actuates the elevator, one actuates the rudder, and a third actuates the
ailerons. The ailerons are linked so the left aileron is deflected equal in magnitude
but opposite in direction to the right.
Figure 2-2: Nexus Solid Model
Figure 2-1: Nexus Photograph
The Nexus has a 32" (81.28cm) wingspan, is 35j" (90.17cm) long, and has a wing
area of 272 in 2 (1755 cm 2 ). The reported weight, including a nominal set of electronics, is 4.8oz (136g)
In order to create an estimate of the mass properties of the vehicle, a complete
solid model was composed in Solidworks
@,
a rendering of which is shown in figure
2-2. The model includes accurate placement of servos, engine controller, battery,
motor, and propeller. The mass and location of the mass center of each of these components are given in table 2.1. The reference frame for the location measurements
has its origin at the nose of the aircraft, at the edge of the horizontal foam sheet,
and coincides with the centerline of the aircraft's body. The x-axis is positive toward
the tail, the y-axis is positive toward the starboard wing, and the z-axis is positive
toward the cockpit, as shown in figure 2-3.
component
Engine Controller
Receiver
Battery
Servo (Aileron)
Servo (Elevator)
Servo (Rutter)
Motor
Propeller
Vehicle
mass (g)
7
4.2
42.5
8.5
8.5
8.5
18.5
21.9
121
x (cm)
10.5
-0.9
17.6
17.0
22.0
26.8
-0.9
-2.7
11.25
y (cm)
-0.4
-0.0
0.1
0.0
0.1
0.6
-0.0
0.0
0.13
z (cm)
-2.4
0.0
0.4
-1.1
-0.6
-2.8
0.0
0.0
-0.38
Table 2.1: Component Mass Properties
The Depron foam was modeled as a solid with density 0.0359 kg/m 3 . The propeller was modeled as a solid with density 1300 kg/rn 3 , a standard value for Nylon
plastics. The propeller was weighed to be 23 g and the model, given this density, was
estimated to be 21.8g. The foam elements contribute 0.052g to the total weight of
the aircraft. All of the electronics were modeled as being uniform density with center
of mass coincident with that estimated by observation.
Figure 2-3: Modeling Frame
Figure 2-4: Body Frame
The center of mass was reported by Solidworks to be at a location 11.2 cm away
from the nose along the center-line, 1.2 mm away from the center line along the starboard wing, and 3.8 mm away from the wing-plane on the bottom side. Solidworks
reports that the model has an expected total mass of 121 g, and provides the second
moment of inertia tensor recorded in table 2.2. This tensor is described in a coordinate system located at the vehicle's center of mass, with the x-axis along the vehicle
centerline and positive in the direction outward of the nose, the y-axis along the
wingspan and positive in the direction of the starboard wing, and the z-axis pointed
out of the bottom-side of the aircraft (a traditional aircraft coordinate system), as
illustrated in 2-4.
Nexus Inertia Tensor (kg-m 2 )
9.59e-5
-3.57e-6
-4.71e-5
-3.57e-6
1.3e-3
-3.44e-6
-4.71e-5
-3.44e-6
1.25e-3
Table 2.2: Nexus Moments of Inertia
We also note that the reported principal axes are very close to the axes of our
chosen body coordinate frame, and that it would be reasonable to assume the cross
moment of inertia terms are zero. Therefore we will use for the inertia matrix the
following.
[Iz
0.099 0 0
0 0
0
0
2.2
I,,
0
0 IZZ
=
0
0
1.3
0
- 10-3kg-m 2
0 1.25
Aerodynamic Model
In order to derive an effective controllable force model of the aircraft, we will ignore
the small effects of the vehicle's angular velocity on the aerodynamic forces. Thus, we
assume that the aerodynamic forces are a function only of the velocity of the vehicle's
center of mass, and its orientation with respect to that velocity.
Since the aircraft is composed of essentially a collection of 3mm thick foam plates,
and because we expect the vehicle to fly at relatively low speeds, a simple flat-plate extension to inviscid, thin-airfoil aerodynamic theory is employed. Aerodynamic forces
on an aircraft are frequently written using non-dimensional coefficients
[6,
Section
1.5, page 20] as follows.
1 =cq.C,
(2.1)
d =cqCd.
(2.2)
Here q, is the dynamic pressure, c is the surface length of the aerodynamic surface,
C is called the coefficient of lift, and
Cd
is called the coefficient of drag, and 1 and
d are the two-dimensional lift and drag per-unit-span. Lift is defined to be the force
perpendicular to the free-stream velocity, and drag in the direction of of the freestream. The dynamic pressure is a function of the free-stream velocity and of the air
density.
q0
2 )KO
2
(2.3)
However, since we will be dealing with orientations of the vehicle well outside
the "low angle-of-attack" regime, and because our vehicle is a pair of orthogonal
flat plates, it is more convenient to define simply the force perpendicular to the flat
plate, so we will denote the two-dimensional force per-unit-span on the flat plate by
f
= cq.C f .
Note that Cf (lower-case 'f' subscript) is frequently used to denote the skin friction
coefficient, which is quite different then the meaning we have assigned to it here. The
two-dimensional force coefficient for a thin airfoil in incompressible, inviscid flow is
proportional to the sine of the angle of attack by the following.
Cf = 27r sin a
(2.4)
The derivation for this flat-place force model follows that in [6, Section 4.7, pages
298-304], though makes no assumption about small angles-of-attack. The details of
the derivation for this model are given in appendix A.1.
Of course, for a three dimensional body a two-dimensional lift model is insufficient. We can quantify the force generated in a three-dimensional flow by considering
the two-dimensional model, and by accounting for the change in local angle of attack
due to the downwash over the wing, caused by air bleeding over the tips and circulating toward the centerline. We apply Prandtl's lifting line method, as described in
[6, Section 5.3, pages 360-3861 to achieve this characterization. While the method is
typically given for low angles-of-attack, where a simple analytical solution exists, we
can extend the model to arbitrary angles of attack by using a numerical method. See
appendix A.2 for a description of this method and the algorithm used. The output
of algorithm A.1 yields an estimate for the constant term of the force coefficient kF
so that the net force over a flat plate is given by the following, where S is the surface
area of the plate.
F =q.SCF
(2.5)
CF =kF Sina
(2-6)
Note that this implicitly ignores the cross wind on each plate (the y-component
of velocity for the horizontal plate, and the z-component of velocity for the vertical
plate). Therefore, in a three-dimensional context, we do not in fact use V in equation
2.6, but rather its projection onto the alternate principal plane (in the xz-plane for the
horizontal plate, and the yz-plane for the vertical plate). If we decompose the freestream velocity into components along the vehicle body frame, then for the horizontal
body plate, this indicates a geometric relationship with the velocity vector illustrated
in figure 2-5. Note that the components of the free-stream velocity vs, vy, v, have the
same magnitude as the respective components of the vehicle's velocity measured at
its center of mass and represented in the body frame. We will use the same variables
to describe each.
Figure 2-5: Velocity Components
From the geometry illustrated in figure 2-5, we can identify a relationship between the components of the vehicle's velocity, and the magnitude and angle of the
velocity needed for applying the force model in equation 2.6. We can apply the same
relationship for the vertical flat plate section.
+V2
=2
V2
Vh
Vx +
vz
Va,
2
2 +V2
v =Vx +y
sin av
(2.7)
(2.8)
Va,
We must also consider the effects of the propeller on the flow field. We will
ignore the complicated aerodynamics near the propeller, and consider only the farfield contribution to the velocity. We will model the propeller's effects as an additive
component of flow in the vehicle's body x-direction, as illustrated in figure 2-6.
Figure 2-6: Velocity Components in Prop Wake
From the geometry in figure 2-6, we can again identify a relationship among the
components of the vehicle's velocity, and the contribution of the propeller to the flow,
and the magnitude and angle of the velocity needed for applying the force model
in equation 2.6. We again extend this same relationship for the vertical flat plate
section.
v=(v.,
sin a,
=
Vx
+
vp) 2
+
V 2, =(Vx
V2
+
sin av, = -V
Vz
+ VP
ex +v
(2.9)
v,)2 + V2
(2.10)
(
Then, in order to complete our force model for the Nexus, we split the force
coefficient identified in equation 2.6 into one part outside of the propeller wake, and
one part inside of the propeller wake. We can then use the definitions from equations
2.7 through 2.10 to find the force on the horizontal plate represented in the vehicle
body frame (Fbh), and the force on the vertical plate represented in the vehicle body
frame (Fbv). Note that we have shown, in generic terms, qj sin(a,) = kV 2 (v/V)
yielding the following.
Fbh
F
2.3
-
= -
+ khpvhp) vz
(2.11)
(kuvv + kVPvVP) v,
(2.12)
(khvh
Propeller Model
The propeller is aligned with the vehicle's body x-axis, and so we will model its force
contribution as having only a component in that direction. We will assume that the
thrust is commanded directly, with no dynamics of its own, and we can estimate
the flow contributions of the propeller, by applying simple momentum theory as
described in [11, Section 1.1, pages 1-101. From this theory the far-field velocity due
to the thrust of the propeller is a function of the Thrust, T, the air density, p, and
the area of the propeller disc, Ar,.
V
2.4
(2.13)
pA2T
prop
Complete Force Model
Since the aerodynamic forces are orthogonal to their respective plate sections, and
the thrust is aligned with the body x-axis, it is easy to see that the net force acting
on the vehicle, represented in the vehicle body frame, is simply the aggregate of these
three contributions.
F = [T Fv
2.5
(2.14)
Fbh]
Finite Section Model
It was assumed that the angular velocity of the vehicle does not contribute significantly to the generation of aerodynamic forces on the vehicle. It is useful to validate
this assumption in simulation, so while we allow this assumption in the development
of a controller for this vehicle, we also implement a higher-fidelity model to account for
these effects during simulation. In the process of determining the force coefficients as
outlined in A.2, we generate a collection of sectional lift coefficients for a finite division
of the lifting surfaces planform. Therefore, we can model the aerodynamic forces generated over the body by summing the individual contribution of these finite elements
(which are illustrated in figure 2-7), fully accounting for all contributions to the local
flow speed (the velocity of the vehicle's center of mass, the angular velocity of the
vehicle, and the propeller if the element in question is within the propeller's wake).
This high-fidelity model is composed of a collection of vectors:
,
the span-wise (y)
location of each element's aerodynamic center, x'c, the x location of each element's
aerodynamic center (assumed to be at the quarter chord), and c' the chord-length of
each section.
0
-0.4
-0.-0.4
-0.6
-0.8-0.5
-0.6
-.
0.5
0
-0.8
-0.4
-0.2
Figure 2-7: Finite Element Model
0
0.2
0.4
y (m, body axis)
y (m, body axis)
Figure 2-8: Quarter Chord
The local velocity vector at a given element i of the horizontal plate then can
be described according to its position p, and the vehicle's angular velocity w (both
expressed in the body frame) as follows:
V = Vo, + W x p + I (P) v
0 0}T
(2.15)
Here, I(p) is an indicator function, evaluating to 1 if the location p is within the
propeller wake, and 0 otherwise. Then the force contribution of that element can be
found by decomposing the local velocity and applying equation 2.6
Chapter 3
State Parametrization
3.1
State
In order to fully describe the pose of the vehicle we need to keep track of both its position and its orientation. The orientation can be fully described by the rotation matrix
R describing a transformation from body coordinates to inertial coordinates. The position can be described by a vector i from the origin of the inertial coordinate frame
to the center of mass of the vehicle, expressed in coordinates of the inertial frame.
The complete pose then can be described by an element g of the Special Euclidean
group in three-dimensions, SE(3). In homogeneous coordinates, in accordance with
the formulation in [9],
(3.1)
g =
L0
1
The derivative of this state is given by the equation
a
=
g( where the twist (
encodes the angular velocity W and velocity ' represented in the body frame.
(3.2)
0
0
In the above, & is the 3 x 3 matrix composed of the elements of W such that
cui= c x
, commonly referred to as the cross-product matrix of W.
Z
0
-W.,
-WY
or
0
.(3.3)
The full state then can be represented as the pair of matrices (g,(). The dynamics
of a Newtonian rigid body represented in this manner are described as follows:
MV
J6
=
-W x MV + Zb(g, 5,U)
-
x JbU-- J, + M(g,(,u)
(3.4)
(3.5)
Where Jb is the inertia tensor of the vehicle, m is the vehicle mass, Mb are the
moments in the body frame, and F are the forces in the body frame. A propeller
driven airplane is not quite a rigid body and the inertia of the rotating mass (at
the propeller) contributes an additional moment on the vehicle, so equation 3.5 is
corrected as:
Jb)
=
-L x (Jba
-
Jr,)
+ MA(g, (, U)
(3.6)
Where Jr is the inertia of the rotating propeller, and wr is the rotation rate of the
propeller, both represented in the body coordinate frame.
This parametrization is chosen for a number of reasons.
Because the goal of
this controller is to track a reference trajectory, for slowly time varying paths the
configuration of the vehicle will be close to its hovering dynamics, with the nose
pointed up. However quickly varying paths will lead the system to naturally evolve
into steady-level-flight-like motion. Therefore we need a parametrization that is not
singular over full 90' rotations. This state definition has the advantage of being robust
to numerical sensitivity at large rotations in contrast to an Euler-angle representation,
and the inherent group-behavior slows the propagation of numerical error, and reduces
the complexity in software implementation.
30
Chapter 4
Design of a Non-linear Controller
Inspired by Backstepping
We would like to design a controller for the Nexus aircraft that tracks a prescribed
time-parametrized position reference trajectory given by p,(t), a vector describing the
translation of the vehicle's center of mass from some inertial origin. We have at our
disposal the ability to manipulate the orientation and the thrust of the vehicle. We
will assume that we can achieve any moment desired to effect any desired orientation.
Our goal then in designing a controller is to realize a moment M and a thrust command, T that achieves the desired trajectory. We also assume that at any point in
time, we can measure with perfect accuracy the full state of the system. We approach
this complex problem by simplifying it into simpler control modules. The following
design closely resembles the design in [3] targeting autonomous helicopters, with the
significant difference of the presence of aerodynamic forces in addition to the thrust.
4.1
Overview of Backstepping
As outlined in [7, Section 14.3, pages 589-6031, the processes of integrator backstepping involves a nonlinear system with state r/ and control input u, as illustrated in
figure 4-1 with the following form:
(4.1)
//=f (rq) + g(n)(
=U
S
g()
±
(4.2)
f
f(.)
Figure 4-1: General Non-linear System
If there is a known control law (=
(rq), with 0(0)
=
0, that can stabilize 'q, then
we can think of the components of the system to the right of the first integrator as
a virtual subsystem as illustrated in figure 4-2. We can apply the stabilizing control
law to create a stable closed-loop subsystem, and then think of the actual input to
this subsystem, (, as a disturbance relative to the desired input 0(r7).
f(. + g.)4(.)
Figure 4-2: Applied Inner Control
We do this by separating ( into
(( - #(r/))
+
#(rq),
putting the dynamic equations
in the following form:
/=
[f(rq) + g(r)#(7)]
+ g(17) [( -
(r1)]
(4.3)
(4.4)
Then, as illustrated in figure 4-3, we can backstep the desired input through the
integrator, and compose a virtual input to the system by summing the actual input
with the derivative of the desired subsystem input.
-4q)
.f~o
Figure 4-3: Backstepped Input
This yields a change of variables that allows us to rewrite the dynamics in the
following form, in which the first equation has an asymptotically stable origin when
the input is zero.
[f(7) + g(7)(7)] + g(r)z
V=
z=u -
4.2
=v
(4.5)
(4.6)
Backstepping Applied to Flight Control
We can apply this same backstepping concept in a block manner for flight control.
We start by considering the dynamic relationship between the system commands that
we have at our disposal, and the trajectory that it will follow given those commands.
Then we look for a way to incrementally reduce the complexity of this relationship.
In the case of this Nexus aircraft, we can do this by essentially asking three separate
questions.
1. If we could directly command the net force of the vehicle, then what would that
command be in order to track the reference trajectory?
2. If we know what we want the net force of the vehicle to be, and what the
vehicle's current velocity is, what orientation and thrust should the vehicle
assume in order to generate that net force?
3. If we knew what we wanted the orientation of the vehicle to be, what moment
should we generate in order to reach that orientation?
These three questions reveal that there are two essentially separate sets of dynamics, and one additional relationship that glues them together. The vehicle's position
is governed by its translational dynamics, which are essentially a collection of double
integrators responding to the net force vector on the vehicle. The net force on the
vehicle is the sum of the propeller thrust, and the aerodynamic forces. The aerodynamic forces are a function of the vehicle's orientation with respect to its current
velocity, and the orientation, in turn, is governed by the orientation dynamics, which
form an integrator on the group SO(3) responding to the net moment on the vehicle.
The net moment, in addition to the thrust, is something we control. We can consider
these three relationships as two separate virtual systems, and one correspondence,
where the output of one acts as the input of the next.
Position 0
P
Tanslational
Aerodynamics
Orientation
Td
Tanslational
Loku
OrientaniMn
Figure 4-4: Backstepping Block Diagram
Considering the system as the composition of these virtual subsystems leads us to
the natural idea of designing three separate and corresponding controller modules: a
translational controller, a state look-up rule, and an orientation controller. Each one
can be view as a controller for the virtual system it is related to, and the output of
each controller module serves as a reference for the next one in the chain. If we can
design a stable controller for the translational dynamics, then we can backstep that
control command through the look-up rule, and through the orientation dynamics,
to create a stabilizing control for tracking the desired trajectory. This concept is
illustrated in the block diagram in figure 4-4.
4.3
Translational Controller
If we assume that we can produce any arbitrary net force on the vehicle, and thus any
acceleration, then the design of a stabilizing translational controller is quite straight
forward. In particular, a simple proportional-derivative (PD) control law will suffice.
We can write the relationship between the position of the vehicle p and its derivatives
in the familiar form of i
Ax + Bu.
=
= +
S0
0
p
0
(4.7)
I
Since we are concerned with tracking a trajectory, it is convenient to consider the
translational error, rather than the absolution position of the vehicle. If the trajectory
we wish to follow is given by p,(t), we define the translational error as P = p - pr(t).
In this case the error dynamics are given by the following system.
.j =
_P
0 0
[. +
_P
I
(i-p,).
(4.8)
Note that at this point, we are considering P to be a command that we feed the
system. Therefore, we apply a linear feedback control law in the following form.
P = Pr- Kj - K#
(4.9)
If we insert equation 4.9 into equation 4.8, we observe a closed-loop system for
the error dynamics given by the following.
=D(4.10)
0.
p -Kp
-KD
This is a time-invariant linear system in a familiar form. If we denote the aggregate
error vector
[P by the variable -, then the system can be rewritten as.
(4.11)
For any positive definite, symmetric matrix,
Q, if
there exists a unique positive-
definite solution to the Lyapunov equation ATP + PAT =-Q, then A is asymptotically stable. A Lyapunov function for this system is given by 4.12, indicating that
the translational state error will converge to zero exponentially fast.
(4.12)
V = -1 TPY
2
t =T
(AP + PAT) y
=
-yTQy
(4.13)
We can find Kp and KD in a number of different ways. One way is to make
them both diagonal, in which case the x-, y-, and z-channel errors are decoupled, and
then we can apply classical control theory to choose the magnitude of the diagonal
elements Kp, and Kd,i from some classically inspired performance requirements. It is
also possible to find a stabilizing Kp and KD directly from the solution to a Riccati
equation per LQR [8].
4.4
Orientation Controller
The nominal orientation controller is similarly straightforward to design. Recall that
we describe the orientation by a rotation matrix R transforming a vector in the vehicle
body-frame to an equivalent vector in the inertial frame. As R E SO(3), we can take
advantage of the group behavior of SO(3) to relate the dynamics of R to the angular
velocity w expressed in the vehicle body-frame.
R = Rc
(4.14)
We assume that we can produce any moment, and so the angular acceleration
b, is our control input. We also assume that the orientation reference R, is at least
twice differentiable with respect to time, yielding continuous angular velocity W, and
angular acceleration b,. The "hat" operator
(^)
transforms a vector in R3 into a
3 x 3 matrix, such that, for two vectors x, y E R3 , then iy = x x y. We define
the orientation error by f2 E so(3), given by
composed of {xlx E R3,
IX|I
n2 = log(RRT).
The set so(3) c R3 is
E [0,7r]}. The logarithm map log(R) SO(3)
'-+
so(3) is
given by the following.
0(R) = arccos
trace(R)
2
-
1
(4.15)
R32- R23
log(R) =
s (R)
2 sin (6(R))
R 13
- R31
(4.16)
R 2 1 - R 12
In order to simplify the notation, however, it is more convenient to consider the
orientation error by its normalized direction i and magnitude 0, such that f2 = & .
We define a desired angular velocity
velocity error as D
=
w
-
Wd.
Wd
--
w - kof. Then we define the angular
A Lyapunov function candidate for the orientation
block is given by V, defined here.
Vo = E(RRT) + I&T&
2
(4.17)
The function 8(R) is a measure of the group error on SO(3) and is defined by
1 - cos(I Ilog(R) ||). If R is the composition of two rotation matrices representing
orientations, then
E is a normalized
measure of the smallest magnitude rotation from
one orientation to the other (analogous to the two-norm in a Euclidean space, which
is a measure of the smallest magnitude translation from one point to another). Note
that it is a positive definite function about the identity rotation matrix. Also note
that, by equation 4.16 above, its definition reduces to 1(R) = (3 - traceR)/2. Its
derivative with respect to time is given by equation 4.18.
E)(RRT)
= sin6 -fT R,(w - wr)
(4.18)
Then the derivative of the Lyapunov candidate is given by the following.
V0 = sin Oi TR
+
(4.19)
CT-
Then we propose the following nominal orientation control law, which yields a
derivative of V given by 4.21.
W =
W, -
kCD - sinGfifTR,
(4.20)
(4.21)
V0 = -kJ&TU
4.5
Backstepping the Acceleration
If we can define an orientation look-up rule such that j(R, T) is invertible, then we
can use the attitude R as a control input to the translational block. In this case we
define a desired thrust Td and orientation Rd, which, together with its derivatives, we
feed as the orientation reference to the orientation controller. It is worth noting that,
although thrust can be commanded directly, in order to ensure that the system has
constant relative degree, we'll extend the dynamics so that we treat its derivatives as
the control input.
In order to use a Lyapunov analysis to design a stable controller, we must ensure
that the dynamics of the orientation block are sufficiently fast that they overcome
the error dynamics of the translational block. So we will first consider as a candidate
Lyapunov function, a summation of V and V.
V1
=
1
2
VT+ V0 = -P7
1
2
+ O(RR) + - DT&
(4.22)
However we cannot strictly enforce the translational acceleration given by the
block controller design in equation 4.9 since we cannot instantaneously change the
orientation, so instead we define
Pd
as the desired acceleration, according equation
4.9. Then the translational dynamics are given in equation 4.23, with By
1
0
0=
11
,
and the time derivative of V is given in equation 4.24.
A-y-y + By (P - Pda)
(4.23)
Vi =0V±' T PBy(p -p-a)+Vo
(4.24)
In order for equation 4.22 to be a Lyapunov function, we must have that
IVt+VoI >
-TPB(p - fi'd). We can achieve this by augmenting the orientation error feedback,
as in [3], to exactly cancel out the offending terms. Following the method in [3], the
acceleration error can be decomposed into a part depending on the orientation error,
and a part that doesn't.
P - Pd =
(4.25)
RF - RdFbd
= RF - (Rd - R)Fbd - RFbd
(4.26)
(R - Rd)Fbd
(4.27)
=
R(F -
Fbd) +
The part depending on the orientation error can be broken down into its components as follows.
(fR - Rd)Fbd = (fR - Rd)(Tde1 - Fvde2
-
Fbhde3)
(4.28)
From the geometry of rotations, we can show that for any unit vector ei, the
following is true (see section B.1 in appendix B for a justification).
(R - Rd)ei
=
tan
(r x (R +
And by rearranging terms we have the following:
Rd)ei)
(4.29)
TPB(r x (R + Rd)ei)
= fT ((R
+ Rd)ei x BTPy)
-y
(4.30)
y TPBY(R - Rd)ei = tan 0 fT((R + Rd)ei x BTP-y)
(4.31)
And finally
We will therefore use this expression to augment the orientation dynamics offsetting the components of equation 4.28. The other term in equation 4.27 can be
decomposed as follows.
R(Fb - Fd,) = (T - Td)Rel ± (Fo - FV )Re 2 + (Fbh
-
Fbhd)Re3
(4.32)
The first term which is dependent on the thrust will be used to augment the
thrust dynamics. The second do not yield an obvious decomposition for either the
orientation or the thrust, so we will offset these by matching their magnitude, in the
direction of steepest descent on the orientation error. A candidate Lyapunov function
for the system is the following:
2TPT + koe(RRd ) + I(I|In|2
+kTT
Td| 2 + I II2
-
(4.33)
where 17 is the augmented angular velocity error, and C is the augmented thrust
rate error:
7 = W -
Wd -
-
C= i
and:
TdF1 -
(Fbv - Fbv,)G
1
-
FbvF2 -
Zad- -H
kT
1
2 -
FbhdF3
(Fbh
-
Fbhd)G3
(4.34)
(4.35)
Fi =
1
Rd((R + Rd)ei
2
2k0 cos
Gi =
RV/(ke sins>)Hi
x
(4.36)
yTPB)
(4.37)
H, = yTPB,,Rei
(4.38)
We note that (Fi - Fbid)Gi is continuous despite having sin 9 in the denominator
because the expression has a finite limit at 9
0 (for justification see section B.2 in
appendix B). It is obvious that V is non-negative, since P is positive definite, and
6 is positive definite with respect to orientation error. Furthermore, since all the
terms in V are non-negative, V
that -y =
[0
=
0 implies that all terms are zero. This implies
0 0 T is a zero vector. In turn, from their definitions (equations
4.36 through 4.38), F, G, and Hi must be zero. Then from the definition of the
augmented errors, equations 4.34 and 4.35, the angular velocity and thrust rate errors
must also be zero. Furthermore,
(T - Td) 2
=
e=
0 implies that the orientation error is zero, and
0 implies that the thrust error is zero. Therefore, if V = 0, then all
the state errors are zero, and so V is positive definite. The time derivative of the
Lyapunov candidate is given by the following:
V = -TQy
+
TPB,(j - Pd)
+ q + kT(T - Td)(T
-
+ k sin dfT Rd(W
-
Wd)
Td) + CTC
(4.39)
We can ensure that V is negative semidefinite by imposing the following:
=
-k,7
= -kgC
- ko sin &?Rd
(4.40)
- kT(T -
(4.41)
Td)
Then by applying the identity sin a = 2 sin C/2 cos 0/2, the 7T term has the fol-
lowing expansion.
/Tr/ =-k
7
/Tr
-
ko sin #f(w -
Wd) -
Td tan 5f ((R + Rd)el x BTP-y)
- Fvd tan 5i"((R + Rd)e 2 x BTPY)
- FbhdtanOf ((R + R)e
x BTP'y)
3
- (F&V - FbVd )yTPBRe2
-
(Fbh
(4.42)
Fbhd)>TPBRe
3
-
And (( expands to :
CC = -k(C
- kT(T - Td)(T
-
Td) - (T - Td)-y T PBRe
1
(4.43)
So that that the derivative of the Lyapunov function candidate simplifies to the
following:
f
= -7TQy - kg/Tr/ - kc
2
< 0
(4.44)
This indicates that the time derivative of the Lyapunov function is negative
semidefinite. Taking higher derivatives of V indicates a unique invariant set consisting of only the origin, and by LaSalle's principle the system is asymptotically
stable. The control inputs then are as follows.
T=Td+ -H
kT
Mb
- k( - k(T - Td)
W X (JbW -
Jb+
JW,) + Jb
[TdF1 -
FbVdF
(4.45)
[-kg/r - ko sin OjTRd(w
2
-
FbhdF3 -
(FbV -
-
Fa)H
Wd) + bd]
2
-
(Fbh -
Fbhd)Hs] (4.46)
Chapter 5
Coordinated Flight
In the derivation of the controller, Rd was assumed to be known, invertible, and twice
differentiable, though it was not specifically defined. We now approach the problem of
designing a suitable orientation look-up law to satisfy these requirements. We require
that the orientation given by the look-up law generates an acceleration that matches
that output by the translational controller, given the vehicle's current velocity. We
will denote the acceleration command as Pd (desired acceleration), and the vehicles
velocity, represented in the body frame, as v. We will describe its orientation by a
rotation matrix R transforming a vector in the vehicle's body frame to an equivalent
vector in the inertial frame. The problem, then, is to find an expression deriving Rd
given Pd, R, and v.
At any given velocity, the set of orientations that satisfy a desired acceleration are
not generally singleton. We must then design additional restrictions to prune down
this set.
5.1
Orientation Look-up
One such restriction that is commonly used in flight vehicles is the restriction to
"coordinated" acceleration, where the net acceleration is completely contained in the
body x-z plane, as illustrated in figure 5-1. This is convenient for manned vehicles
because it ensures that the accelerations felt by the pilot are only into his chair, and
he doesn't experience lateral accelerations.
Figure 5-1: Coordinated Flight
The calculation for the orientation that satisfies Pd is quite straight forward. Since
there can be no lateral acceleration, we know that the aerodynamic forces on the
vertical body section must be zero, and therefore the vehicle must be flying with no
side-slip, and the velocity is also constrained to the body x-z plane. As illustrated in
figure 5-2, if we consider the system from a reference frame oriented with the x-axis
along the direction of the velocity, and with the y-axis perpendicular to both the
x-axis and the direction of the acceleration, the problem resolves to solving for the
angle of attack such that the magnitude of the desired acceleration in the body z-axis
is equal to the aerodynamic force of the horizontal plate. Then the thrust required is
equal to the projection of the desired acceleration onto the body x-axis.
,m(P-g)
Figure 5-2: Coordinated Free Body Diagram
From the geometry in figure 5-2, if the angle between the desired acceleration and
the direction of the velocity is 0, then the angle of attack a is found by solving the
following pair of equations.
m(Pd- g) cos(O- a) = T
(5.1)
m(Pd - g) sin(O - a) = khV 2 sin(a)
(5.2)
The solution of which is given by equation 5.3 below.
tan(a) =
m(iid - g)sin 9
V-(d
) S
kh V2 + m(Pd -
(5.3)
g) COS 0
The orientation command, then, is a composition of the rotation given by a, and
the rotation matrix describing the velocity frame.
Rd =
(5.4)
RvRc
with
cos a
ROL
0
-sina
0 sin a
1
0
(5.5)
0 cosa
The velocity frame is defined such that the x-axis is aligned with the current
velocity vector, vi in the inertial frame, the y-axis is orthogonal to both the x-axis
and the acceleration command, and the z-axis follows from the x-axis and the y-axis.
We can define these axes by the unit vectors x, y, and z in the equations below.
x = v/ivIl
y =ii:X X d~
Pdj
..
z = xxy
(5.6)
Then rotation matrix describing the orientation of the velocity frame is given
simply by column-concatenating these three vectors.
RV = Ix y z(
(5.7)
The angular velocity is given by the Lie Algebra so(3) associated with SO(3).
w(=
(TR
The "vee" operator (v) is the inverse of the "hat" operator
(5.8)
(^),
selecting the
elements of w from the skew symmetric matrix RTR, whose diagonal elements are
zero. The angular acceleration can be found by applying the product rule.
R = R& + Rw'
d
= (RT R - RTRZ)
(5.9)
The derivatives of the orientation matrix are given by the product rule based on
its definition.
R = RRa + RRa
(5.10)
R RRa
(5.11)
+2R+Ra + R&R
The derivatives of the velocity frame components are as follows, where?) = 1/mF.
-
1/IloVI3(VT?)V
-(Vxiid)
T=
T
eivs+
+
/IIVxPdi13 [i)
x
(5.12)
1/lvIlin
x 3d + v x
1
d]
(v X Pd) + 1 /IlvxdI| |[ x Pd + v X Pd]
r
The derivatives of the a rotation matrix is given by the following.
(5.13)
(5.14)
sin a 0 cosa
0
d
0
0
(5.15)
-cos a 0 -sin a
-sina
0
cos a
0
0
0
ha
-[cos
a
-cos a 0 -sin a-
sin a
62
0
0
a+
-
sin a
- cos
(5.16)
a
The derivative of the angle of attack is found by the following.
2
-m(Pd - g) sin 0
sec 2(a)& =
(khV
2
..
.
hV+MdCOSMP
+ m(Pd - g) cos o)2k.
mid sin 0 + m(Pd - g)-4 sin
kVmji-(5.17)
+
kh V2 +
mn(Pd -
d
dtCOS)
(
g) COS 0
where
d sin =
dt
d
d COS 6 =
dt
1
(v x P d)T
XP
. ..
||v||||Pdjl liv XpdlI
1..
||v||||a||
((, T
-+a
j VoT )
(5.18)
(5.19)
The second derivatives are likewise found by successive application of the product
and composition rules.
5.2
Lower-bound Saturation on Acceleration
It should be noted that, in the derivation of the control law, we assumed that the
look-up rule was invertible for any given acceleration command Pd. This is not strictly
achievable, and while the coordinated look-up can satisfy most desired accelerations,
there is a range of infeasible accelerations that it cannot achieve. In particular, for an
acceleration whose direction makes an angle with the current velocity greater than
900 , there is a lower bound on the achievable magnitude, as illustrated in figure 5-3.
0.8
0.6-
Feasible
-Pn
0.4
0.2
Infeasible
0
1
-0.5
0
0.5
Figure 5-3: Feasible Accelerations
This lower-bound saturation is due to the fact that the aerodynamic forces scale
with the vehicle's velocity, and grow with the angle of attack, and because we do not
have the power to generate negative thrust. This limits the set of feasible trajectories
for which we can guarantee tracking, to those that leave some finite margin on this
lower-bound.
5.3
Simulation Results and Limitations
Validation of the controller design using the orientation look-up was done by simulating the controller along a helical trajectory. The position over time is plotted in figure
5-4 demonstrating the vehicle holding a coordinated trim over a period of 30 seconds.
3.53
.
2.5
2
5
5
y, (M)
-5
-10
z, (M)
Figure 5-4: Following a Helical Trajectory
Using a coordinated look-up has the advantage of being relatively straightforward,
and corresponding well to a traditional approach for aircraft control. However, for
aggressive maneuvers, a coordinated orientation may not be the best choice. If the
velocity is too small, the velocity frame becomes undefined. We can work around
this limitation by arbitrarily replacing R, with the identity matrix, but in the case of
trajectories that involve periods of hovering, small disturbances in the position can
lead to very large moment commands. Since we require that all acceleration be in the
body x-z plane, a small error in the vehicle's y-axis will require up to a 90' rotation
in order to compensate. To demonstrate this, the coordinated orientation look-up
was applied to a simple point-to-point hover trajectory, with a transition period in
between, as illustrated in figure 5-5. The trajectory holds a constant position for four
seconds, transitions (with continuous derivatives) to a constant velocity segment, and
then back to hover at eight seconds, where it remains.
Hover
Transition
Hover
6
8
time t sec
Figure 5-5: Hover-Hover Trajectory
Figure 5-6: Angular Acceleration
The angular acceleration of the vehicle over this trajectory is shown in figure
5-6. It demonstrates that, as expected, during hover there are very large moment
commands generated. The model used in this simulation did not involve any simulated
estimator noise so round-off error and numerical precision were enough to stimulate
small position errors and lead to these high moment commands as the airplane rolls
back and forth to make small corrections.
Chapter 6
#-Coordinated Flight
In addressing the limitations of a coordinated look-up rule, it is useful to look at an
alternate definition of coordinated flight. As defined earlier, coordinated flight means
that all of the acceleration is contained in the body x-z plane. This is a restriction
of two degrees of freedom in orientation, and then we solve for the third from the
perspective of the "velocity" frame. If we think about the orientation of the vehicle
using an Euler angle parametrization, then this is equivalent to specifying a number
of initial rotations, such that the vehicle matches the velocity frame, and then solving
for the final rotation. In particular, the velocity frame can be represented first by a
rotation about the z-axis (yaw) such that the vehicle is oriented with the body y-axis
at a 900 angle with the projection of the velocity on the inertial x-y plane. Then, a
second rotation about the y-axis (pitch) aligns the vehicle x-axis with the direction of
the velocity. And finally a third rotation about the x-axis (roll) aligns the body x-z
plane with the desired acceleration vector. From there we solve for the final rotation
about the y-axis (pitch) that generates the desired acceleration.
A key realization is that, after the initial yaw rotation, if we observe the direction
of the projection of the y-axis onto the inertial x-y plane, the subsequent pitch, roll,
and pitch rotations do not affect this direction. Furthermore, following the initial yaw
rotation, the other rotations are a convenience for simplifying the solution process,
and are not further restrictions on the orientation. In fact, if we were to specify only
the first yaw rotation (such that the vehicle is oriented with the body y-axis at a 900
angle with the projection of the velocity on the inertial x-y plane), then coordinated
flight solution is the unique orientation that satisfies the desired acceleration. We can
use this idea to generalize the concept of coordinated flight.
6.1
Definition of
#-Coordinated Flight
Given that the vehicle center of mass has current velocity in the inertial frame vi and
given a desired acceleration vector Pd, then for a particular parameter
/
E [0, 27r], the
/3-coordinated orientation is the orientation that generates the desired acceleration Pd
at vi, given that the projection of the body y-axis on the inertial x-y plane makes an
angle
3 with
the inertial x-axis.
y (body)
x (body)
z
Figure 6-1:
t
projected
Iwmng axis
#-Coordination
Given this definition, we note that the traditional definition of coordinated flight
is equivalent to /-coordinated flight where
/
is everywhere defined according to the
following.
#traditional =
where:
2
-
asin
ei x v,
||i v,||I
(6.1)
1
v=
0
01
el=
0 1 0 vi
0
(6.2)
-0
-0 0 0-
We can relax the restriction to traditional coordinated flight in favor of -coordinated
flight for the orientation look-up if a suitable
#
reference is provided. In essence, this
off-loads a piece of the responsibility of the controller onto the trajectory designer.
6.2
#-Coordinated Orientation Solution
We seek to find the orientation Rd that satisfies the desired acceleration from the
translational controller Pd and the projection of the body y-axis onto the inertial xyplane makes an angle
#
(provided by the reference trajectory) with the inertial x-axis,
given that the vehicle's velocity in the inertial frame is vi. We will use a 3-1-2 Euler
angle parametrization of Rd, since the angle
#
essentially tells us the first rotation
in this parametrization. The principle rotation matrices about each axis are given in
equation 6.3 below.
[1
0
0
R1 (#) = 0 cos#
1
-sin #
cos0
R2 ()=
cos#
[0 sin#
cos@ -sin@ 01
R3 (0) =
sin @ cost
[ 0
0
0
0 sin0'
1 0
0
[-sin0 0 cos j
(6.3)
1
Then we can describe the desired orientation Rd via the composition of the the
three Euler angle rotations.
Rd
= R 3 (0)R 1(#)R 2 (6)
(6.4)
In order for the desired acceleration to be satisfied, Rd must be such that mpd
RdFb, or equivalently:
=
R2 (9)TR 1 ($)T R 3(O)T Pam = [T -Fb
-Fbh]
(6.5)
Since /, Pd, and m are all known to us, let us define the partially oriented desired
force as b = R3 (O)TPdm. Then, applying the force model with F, = kevyvxy and
Fbh = khvzovz,
we have the following.
b1 cos9 + b2 sin 9 - b3 sin 9 cos# = T
b2 cos $ + b3 sin #
b1 sin 0 - b2 cos 9 sin 4 + b3 cos 9 cos
=
(6.6)
-kvyvxy
(6.7)
-kvvx,
(6.8)
With only two unknowns, the equation 6.6 is superfluous, so we will focus on
equations 6.7 and 6.8. The velocity terms in these equations are with expressed in
the body frame. In particular:
Vy vz
[vX
=
R 2 (0)TR1(#)TR(3)Tvi
(6.9)
Again we note that 3 is known, so we define the partially oriented inertial velocity
as v = R3 (3)TVi. Then we have the following.
vX =v, cos 0 + v/3, sin 9 - v, sin 9 cos
(6.10)
vY =vO cos # + voz sin
(6.11)
Vz =vlx sin 9 -vy
cos 9 sin # + vpcos 0 cos
(6.12)
Substituting equation 6.10 through 6.12 into equations 6.7 and 6.8 we obtain two
equations in 0 and
#.
Solving equation 6.8 for 0 reveals the following.
v X+± (vpV sin
Vz
tan96
=
b2 sin # - b3 cos
# + vz cos #)2
# + kh(V3 sin 4
b1 + khVexVx
(6.13)
- V/z cos
#)vZ
Substituting this into equation 6.7 we find an expression for
#
=-
A
B
b2 + b3 tan#
(6.15)
q#+ vgz sin #
(6.16)
(veB2 + vI2A) 2
A ±+
B
+v2
=
-k,(vp, + v,,tan #)
#
numerically via any one-dimensional line-search. Once
We can then solve for
# is
(.4
alone.
Vi = voy sin # + v/, cos
V2 = vcos
(6.14)
(6.17)
known, we can substitute its value into equation 6.14 to find 9, and thus Rd.
Despite lacking an analytical way to find
#, we can
still calculate Wd and cd. We do
this by differentiating equation 6.17 to find an expression for q, and again perform
a line-search to find its value. From there we can find 9. We can then find the time
derivative of the rotation matrix, Rd, from the following formulas. In order to keep
the formulas legible, the following shorthand is used: s, = sin x, cx = cos x.
OR
-sco + cfps 4 so
COCO
s)so + COSOCO
=-cyce - S/3soso
-SpcO
C13S9 - S3s0CO
0
0
[
OR
=
R
=
0
[s3%SO
ccso
-soso - cO
-s 13so
sIckCO
-cs
cpccoI
(6.19)
-sc 0 O
-c3so + sps0co 0
ss8 + cpscp 0
ce0c 0
(6.18)
0
08
-c3c -sps0s
spco - cps3Sso
-c'Oso
(6.20)
_
Again, the angular velocity is given by the Lie Algebra so(3) associated with
SO(3), so that Rd = RdCd, and Wd = (RT~A)v, where:
Na + R+ DR
The same strategy is applied to find
6.3
6
(6.21)
)d well.
Simulation Results and Limitations
We note that the 3-coordinated orientation look-up suffers from the same lower-bound
saturation limitation of the coordinated trajectory. The lack of an analytical expression for calculating the orientation makes it difficult to determine what the magnitude
of that saturation is. However, the magnitude of the lower bound saturation bound
from coordinated flight is a more restrictive bound than it is in /3-coordinated, so
we can provide a loose margin on what is feasible for a /-coordinated trajectory by
instituting the same margin as would be required for a coordinated trajectory.
In order to validate the the controller, it was simulated with the same point-topoint trajectory as that in figure 5-5, and did not exhibit the high angular rates. The
orientation error was arbitrarily close to zero. Furthermore, in order to demonstrate
the usefulness of this control design, the controller was simulated with a four-point
hover trajectory, illustrated in figure 6-2. Like in the point-to-point trajectory, the
position of the aircraft is generated using a cubic spline so that the position reference
is everywhere four times differentiable. The
/
reference was also generated using a
spline to ensure that it was everywhere twice differentiable.
I
0
y,
0
2
(mn)
2
x, (Im)
Figure 6-2: Multi-point Hover
As illustrated in the figure, the trajectory is composed of four points with the
position held for ten seconds, and a smooth transition in between each point. At
each of the hovering points, the 3 reference smoothly rotates over a 900 change. Figure 6-2 records the position of the vehicle in three dimensions over the length of the
simulation. The projection of the vehicle y-axis on the inertial x-y plane is shown in
increments of 15* during the hovering points, and at increments of 0.5 m of horizontal
distance along the transition period.
As a final note, in the derivation of the 3-coordinated look-up, it was mentioned
that any line-search algorithm could be used to find <$. In the controller implemented
for simulation, a bisection algorithm was used with tolerance of 10-6 degrees (yielding
27 iterations per search).
58
Chapter 7
Simulation Architecture
The process of taking an automated controller from design to implementation can
be quite involved. In addition to the development of a theoretical design, it is often
necessary to go through a number of separate comprehensive exercises to validate the
system model and simulate the control system with various levels of relaxed assumptions before finally implementing the controller on the physical system. There are a
number of useful general purpose tools available for an engineer to approach these
tasks, but an unfortunate side effect of this process is that a significant amount of the
work must be duplicated. General purpose tools like Matlab and its Simulink have
greatly reduced the work load in this process, but are notably laking in the ability to
interact with other tools. In particular, it is often difficult to provide adequate visualizations for a Matlab simulation, or to quickly port the code to another environment.
It is common in academic robotic test-beds to work with many vehicles that do
not have the payload capacity to carry sophisticated computational equipment, and
the controllers are often implemented on a separate machine communicating with
the device wirelessly. In such a case, it can be quite advantageous to have a system
whereby the same machine (or equivalent machines) can be seamlessly switched between running a simulation of the system, or operating on the physical system itself.
Consider a simple scenario illustrated in 7-1.
Physical
Vehicle
Physical
Sensors
Estimator
Simulated
Vehicle
Controller
Simulated
Sensors
Figure 7-1: Scenario
If the estimator and controller are implemented on a PC, then there is likely
no significant difference between capturing actual sensor data and sending control
commands to the physical system, and capturing simulated sensor data and sending
control commands to a simulated vehicle. With the proper architecture, it is feasible
that the difference between enabling the simulation path (solid path in the figure)
and the real-time physical system path (dashed path) could be quite small. In order
to take advantage of this fact, in the process of simulating and validating the controller investigated here, a comprehensive and reusable software infrastructure was
developed in order to provide a tool more suitable for simulating, visualizing, and
integrating automatic control research in academic testbeds.
7.1
Architecture
The Aerobat simulation framework is a software utility written in C++ that aims to
allow a unified platform for developing, testing, simulating, and implementing control
architectures for small autonomous vehicles. The goal of the software is three fold:
first, to provide a framework for reusing code between testing, simulation, and implementation; second, to provide a platform for visualizing robotic vehicle (in particular,
flight vehicle) simulations; and third, to provide for building a library of reusable
test-bed components (vehicle models, estimators, and controllers).
Aerobat utilizes a hierarchical object model in order to achieve modularity. An
implementation of each object in the hierarchy exists for the Nexus and for the controller derived in previous chapters, so they will be used as an example to explain the
architecture.
At the root is a world object that determines whether the system is running as a
model tester, as a simulation, or as a real-time system. For the Nexus simulation this
is a flight simulator world capable of managing a single vehicle, estimator, controller,
and trajectory. At runtime, the user can select which, among an available list of
implemented classes, of each to use. There exists a C++ interface for each of these
components, and a global interface registry that contains a list of all classes compiled
into the program that implement these interfaces. For instance, the Vehicle interface is implemented by two separate classes that simulate the Nexus. The first is
a class that implements the simplified aerodynamic model used in the derivation of
the controller, and the second implements the higher fidelity finite-element flat-plate
model. There is a dependency relationship between the components that is enforced
by the flight simulator world. Depending on which vehicle is selected, only those
estimators that are compatible with that vehicle are available for use. Likewise, given
a particular estimator, only those controllers that are compatible with that estimator
are presented for use, and the same goes for trajectories.
Each component, when instantiated by the world object, is given the opportunity
to register itself with the other components. For the Nexus simulation, this results
in a data flow illustrated in figure 7-2. When the simulation is run, the world object
updates each component once per iteration of the simulation loop. When.the vehicle
is updated, it propagates its state according to its dynamic model. When the estimator is updated, it queries the vehicle model for its current state, and then updates
its estimate, currently only by adding user-configurable noise. When the trajectory
is updated, it advances its reference to the corresponding simulation time. When
the controller is updated, it polls the estimator for the current vehicle state, and the
trajectory for the current position reference, calculates new control commands, and
writes those commands to the vehicle.
Timing Update
fSi111ator
(Vehicle
)
)
Estimator
(rajectory
)
Controlle
Get Ref.
Get State
Get State
Set Controls
Figure 7-2: Nexus Data Flow
7.2
Object-Oriented Design
Aerobat takes advantage of object oriented concepts in order to reduce the effort of
expanding the system with additional components. The components that are already
implemented all extend from a set of abstract stub classes that implement much of
the common interface structure. For example, each of the Nexus models derive from
a common NexusModel stub class, which in turn derives from a RigidBody stub class.
The RigidBody stub class implements the common elements of a rigid body state (i.e.
position, orientation, velocity, angular velocity, etc.), as well as the code to propagate
the model via Newtonian dynamics. It polls the derived class to calculate the internal
forces, so the only requirement for adding a new rigid body model to Aerobat is to
derive the stub class and implement the force and moment models.
7.3
Visualization
One especially difficult aspect of simulating a flying vehicle is understanding its orientations. Especially in the case of aggressive maneuvering, trying to plot information
about the vehicle's orientation can be insufficient for gaining an understanding of
where a problem lies. In many cases it is more valuable to have a qualitative under-
standing. For this reason a large part of the Aerobat development was focused on
providing the ability to render a view of the simulation in three dimensions.
Aerobat is built on top of the Irrlicht library, an open-source, cross-platform scenegraph rendering engine in C++. The scene graph paradigm is a way of organizing
data for a scene via a hierarchical graph. The graph is traversed by the rendering
system each time the scene is to be rendered, in order to build the visible scene. Each
node in the graph contains information about about its position and orientation relative to its parent node, along with various pieces of information on how it should be
drawn. Aerobat takes advantage of this system by implementing custom scene nodes
for each visualizable component of the simulation. Each of these custom scene nodes
is a sub-tree of visualizable elements that are intrinsically dependent on each other.
Figure 7-3: Visualization
To illustrate, the scene node for the Nexus model, illustrated in figure 7-3 is
composed of the textured mesh for the airframe, the actuated control surfaces, and
a number of conditionally visible debugging components. It can display vectors illustrating its current velocity, acceleration, net forces, body-coordinate system, the
inertial coordinate system (translated to its current position), and the projection of
its wing axis on the inertial frame. The trajectories are visualized by a simple path
drawn in the scene, along with a red sphere to indicate the current position of the
reference, according to the simulation time. The controller also has a visualizable
component. The desired orientation is rendered as a translucent version of the Nexus
mesh, with the center of mass coincident to that of the actual vehicle, in order to qualitatively assess the meaning of the orientation error at any given time. The controller
node also contains a number of debugging components, including visible vectors that
display all the same information as the actual vehicle node.
The scene graph is managed by an internal object to the Irrlicht library, but
Aerobat implements its own scene manager as a wrapper around Irrlicht in order to
map objects in the simulation to objects in the scene graph. It can then synchronize
the state of the visualization node and the object in the simulation. A class that
has a visualizable component communicates this fact to the simulation world by
implementing the Visualizable interface. When the simulation world instantiates
any of the component's it checks to see if the component is Visualizable, and
registers it with the scene manager if it is.
7.4
Math Library
In order to facilitate the integration of multiple different hardware platforms, and in
order to allow the code for different elements to be written in a manner consistent
with their mathematical counter-parts, a minimal set of linear algebra classes was
developed from scratch. There are two main purposes for the Aerobat math library.
First is to take advantage of C++'s overloaded operators to the full extent in order
to implement mathematics in code in as readable a manner as possible. While these
classes do not present the level of optimized performance of the plethora of BLAS
packages available, it greatly improves upon the readability of the code and facilitates
quickly developing correctly working applications, which is far more important for a
prototyping environment.
The second reason for creating the math library is to eliminate the confusion of
working between the many popular parametrizations of SO(3).
The math library
contains classes for all of the popular parametrization, and provides constructors,
accessors, and mutators for all of rotation matrices, quaternions, Euler angles, and
rotation vectors. Furthermore, the quaternion and rotation matrix group operations
are implemented with all C++ operators overloaded for all other classes where these
operations are defined, allowing vector transformations to be easy to implement,
debug, and comprehend in code. The math library also implements an inheritable
concept of reference frames. Any object that inherits from the reference frame class
inherits methods for calculating its relative configuration g E SE(3) with respect to
any member of its ancestry. This allows seamless integration when working with local
and global reference frames, and any intermediate frames.
7.5
User Interface
The framework embraces the concept of Model-View-Controller (MVC) design for
Graphical User Interface (GUI) applications. It is an unfortunate overloading of terminology, but here "model" refers to the underlying software components, "view"
refers to the display of information to the user, and "control" refers to the user input
interface.
Aerobat
Thread
J
4E
Simulation
World
Model
Estimator
RLC
Figure 7-4: Thread Separation
Controller
The GUI is powered by the wxWidgets library which provides a common crossplatform API for developing GUI applications that use the underlying operating
system's native GUI controls. As illustrated in figure 7-4, each of the three main
components (if active) are run in a separate thread. This ensures that the simulation
or real-time system is not subject to the low-resolution timer of the GUI messaging system, and that the rendering engine can be enabled or disabled depending on
whether or not the system is running a simulation or a real-time system. Any object
being managed by the Aerobat thread can have user configurable options. A class
communicates whether or not it has this feature by implementing the Conf igurable
interface, through which the GUI manager can instantiate the object's GUI when a
user requests it.
Chapter 8
Conclusions
8.1
Conclusions
In conclusion, the controller studied here has a number of desirable properties. It uses
a consistent treatment of the vehicle state over the full envelope of feasible trajectories,
and has provable asymptotic stability. In addition, the coordinated look-up applies
this controller to traditional flight trajectories and can be used in many applications.
Furthermore, an unconventional type of coordination is presented that applies this
controller to more demanding trajectories, including very high angle of attack maneuvers. The design with both orientation look-up rules has been validated in simple
simulations, and an extensible simulation framework was developed to enable more
exhaustive simulation analysis, and to aid in the eventual implementation.
8.2
Future Work
The controller design presented here is motivated by some very immediate potential
applications. The most important extension of this work will be to carry out flight
experiments on this vehicle in order to address a number of concerns. In particular,
when applied to the real system, how does the controller perform compared to the
expected performance from the model? What affect will the moment and thrust saturations have on our ability to realize the capabilities of this design? Also, will the
domain of attraction be large enough for trajectories of interest that this controller
can be used in the desired applications? Along these same lines, how well will this
controller perform compared to other designs? This design has the distinct advantage of a consistent treatment of the entire flight envelope. While that feature may
be an excellent logical advantage, will it also lead to performance gains compared, for
instance, to gain-scheduled LQR? These are all questions which can be answered by
testing the controller in the laboratory.
In addition, there are some interesting possible extensions to the ideas presented in
this design. It was noted that coordinated flight is a relatively strict specialization of
restricting the space of orientations that are considered for the look-up. Furthermore,
an alternate, less restrictive rule was designed to address some of the limitations of
traditional coordination. However, we can think each of these look up rules in terms
of some optimization problems. In particular both the coordinated look-up and the
/3-coordinated look-up are the solution to a minimization subject to RF = Pd, where
we can express the cost function for the coordinated look-up as Jc = FK, and for the
/-coordinated look-up J0 = asinlIRe 2 x el - 3. This raises an interesting question:
are there other cost functions we could consider in order to generate a look-up rule?
One potential consideration would be too pick the orientation closest to the current
orientation (subject to the desired acceleration constraint). This has the advantage
of reducing the demand on the momentum-generating capabilities of the aircraft. We
could also consider including in the cost the velocity weighted orientation error with
respect to the coordinated orientation. This would tend to drive the vehicle toward
a coordinated orientation when its velocity is high, but would allow some other consideration to dominate when the velocity is low.
Lastly, the simulation framework that was developed for this work was explicitly
designed to be extensible for use on similar applications. The contribution of academic multi-vehicle testbeds has been proved to the industry. The potential for a
complimentary virtual multi-vehicle testbed to integrate modeling, simulation, and
testing in a coherent process is very promising.
70
Appendix
Aerodynamic
A
Force
Modeling
Here we derive some of the equations used in the simple force model for the Nexus
aircraft.
A.1
Two-Dimensional Thin Airfoil Theory
The following derivation is based on that in [6, Section 4.7, pages 298-304], with the
assumptions on small angle of attack removed, and the extension made to net force
coefficients.
We can derive an expression for the aerodynamic force generated by a flat plate
in inviscid, incompressible flow, by specialization of thin-airfoil theory. We start with
the realization is that the surfaces of the plate must be streamlines of the flow. For
thin plates, we approximate the thickness as zero, and we can state that the center
of the plate itself is a streamline, as depicted in figure A-1.
Figure A-1: Lifting Element as a Streamline
We define a coordinate system with the origin located at the leading edge of the
plate, with the x-axis positive along the plate's chord, and with the z-axis perpendicular to the plate's surface. We assign Voo to be the magnitude of the freestream
velocity and a to be the angle of attack. The length of the plate's chord is c. We
then proceed to model the disturbance of the free-stream flow caused by the lifting
element, by replacing the lifting element with a collection of elementary flows. In particular, we will model flat plate by a vortex sheet spanning its chord, with vorticity
along the y-axis. This is illustrated in figure A-2.
aC
X
Figure A-2: Vortex Sheet Model of Flat Plate
Since the plate's chord is a streamline, the component of stream velocity perpendicular to the chord must be zero. The magnitude of that component is equal to the
magnitude of the freestream velocity in that direction, plus the magnitude of the flow
induced by the vortex sheet. The magnitude of the freestream velocity perpendicular
to the plate's surface is V sin(a), and we will use w(x) to describe the magnitude of
the flow induced by the vortex sheet.
0
-
c-x,--------
x
Figure A-3: Downwash Due to Vortex Element
Consider then an infinitesimal element of the vortex sheet located at position (
and having magnitude -(x)d(, as illustrated in figure A-3. The velocity of a flow
distance r away from a pure vortex is equal to 27rr, so the contribution this element
has on w(x) is dw( ).
(.
(A. 1)
2Y(-)
27r(x - ()
dw( ) = -
We integrate over the length of the chord to find the total contribution of the
stream velocity by the vortex sheet at location x.
-
w(x) =
/y
(C)d<
(A.2)
fo 27r(x - ()
And since the total stream velocity perpendicular to the plate must be zero at all
x we have the following.
_1
V.sin(a) = -
27r
(A.3)
-()d<
fc0(X
- ()
We can simplify the process of evaluating this integral by applying a change of
variables whereby we define x to be the projection of a vector of length .2 on the
x-axis, as we vary its angle with the x-axis from 0 to 7r, as illustrated in figure A-4.
c
x
xt
>
Figure A-4: Change of Variables
Then the following equations hold.
d = sin d9
2
=-(1 - cos 0)
2
c
x =-(1 - cos 0.')
2
(A.4)
(A.5)
And equation A.3 becomes as follows.
V 0 sin a =
-y(O) sin OdO
2I7r f
(cos 0 - cos OX)
(A.6)
Solving for -y and applying the Kutta Condition (-y(O) = 0) gives the following
vorticity distribution.
y(0) = 2 sin aV
1
+ cos(O)
sin 0
(A.7)
From the Kutta-Joukowski theorem, there exists an aerodynamic force per unit
length over the wing that is proportional to the circulation of a control surface taken
relatively far away from the wing, and perpendicular to the freestream velocity.
l = pVor
(A.8)
The circulation is defined as the line integral of the projection of the flow velocity
around a control surface encompassing the the airfoil as illustrated in figure A-5
F = -
V - ds
(A.9)
C1
Figure A-5: Circulation Line Integral
Uniform flow has zero contribution to circulation, and a pure vortex contributes
exactly its magnitude, regardless of the shape of the control surface. Therefore the
circulation is just the integral of the of the magnitude of the infinitesimal vortex
elements. We have to be careful how we take the integral though because the KuttaJoukowski theorem is derived in the reference of the freestream velocity. Therefore
we integrate along dx cos a instead of simply dx. In terms of our changed variables
we have the following.
dx cos a=
2
cos a sin 6dO
74
(A.10)
The circulation then is given by the following.
I =- I
2 0
.
2V. sin a
smn 0
cos a sin OdO
(A.11)
=cV,,, sin a cos a fo(1 + cos 6)d6 = 7rcV,, sin a cos a
(A.12)
We compare equation A.8 to the non-dimensional characterization of lift below.
1=IV2
-p""cC,
(A.13)
pV7rc
00= sin a cos a = -p2cC,
2
(A.14)
1
This yields the following.
And thus the two-dimensional coefficient of lift is given by
(A.15)
C = 27r sin a cos a
We now return to the assumption that the flow is inviscid. Without the interaction
of friction, and because the plate is flat, we know that it cannot produce a force in
the lateral direction (with respect to its own reference frame). Therefore, the lift is
simply the geometric projection of the net force along the axis perpendicular to the
freestream, as illustrated in figure A-6.
C
Figure A-6: Geometry of Forces
From this geometric analysis we see the following is true.
x
Ci =Cf cos a = 27r sin a cos a
(A.16)
Cd =Cf sin a
(A.17)
Therefore the coefficient of drag, and the coefficient of net force must be as follows.
A.2
Cf =27r sin a
(A.18)
Cd =27r sin 2 a
(A.19)
Prandtl's Lifting Line Method
The following derivation and algorithm follows that of [6, Section 5.3, pages 360-386
with the exception that no small angle assumptions are applied.
We can quantify the force generated in a three-dimensional flow by considering
the change in local angle of attack due to the downwash of flow bleeding over the
tips of the wings. We will assume that the effects induce a constant change in the
sectional lift coefficient, such that the lift generated by the body at a given angle of
attack a is found by the following.
L =qooC, (a)
CL (a) =kcL sin(a) cos(a)
(A.20)
(A.21)
We apply Prandtl's lifting line method, as described in [6, Section 5.3, pages
360-386] to achieve this characterization. The method begins with noting that, via
the Kutta-Joukowski theorem, an elementary bound vortex of length b with vorticity (magnitude) of F experiences a force perpendicular to the free-stream velocity
according to the following law.
(A.22)
L = pVool'
From Helmholtz's theorem, we know that a vortex cannot end in a fluid. We then
model a finite wing of length b as a bound vortex centered at our vehicle's center line
and extending ±
along the y-axis, and then turning at the tip forming two trailing
vortices in a horse-shoe shape as shown in figure A-7.
Figure A-7: Wing as a Bound Vortex
If we leave the model at this, we will find the downwash at the wingtips is infinite
in magnitude so we consider replacing the single horseshoe vortex with a series of
super-imposed horseshoe vortices with different magnitudes, as shown in figure A-8.
Figure A-8: Finite Vortices
Figure A-9: Vortex Sheet
Note that the vorticity on each segment increases by an amount equal to the
vorticity of the vortex that was added to that segment. We can then extend this idea
by superimposing an increasing number of vortices of smaller and smaller size. In the
limit as the number of vortices go to infinity, the magnitudes become a continuous
function along the span, dF(y). The change in circulation of the bound vortex over
an infinitesimal length of span dy is then dF(y) so that the model is consistent. At
some location along the y-axis, yo, the contribution to the downwash by an elemental
segment dx of one of the vortex filaments is found by the Biot-Savart law.
dV =
X r
(A.23)
Here r is the vector from the element to the point on the y-axis at yo. By integrating equation A.23 along the length of the vortex, we find that the total contribution
of a vortex filament at y to the downwash at a location on the y-axis at yo is given
by the following.
dw=-(dF/dy)dy
47r(yo - y)
(A.24)
Then the total downwash at yo is found by integrating over all vortex filaments.
w(yo) =
47r
y
--b/2 yo ~~y
(A.25)
dy
As illustrated in figure A-10 the downwash at yo induces a change in the local
angle of attack aj.
Of
j.
C
3
w(YO)
Figure A-10: Induced Angle of Attack
The effective angle of attack can be found geometrically by the following equation.
tan aeff (yo) =V sin(a) w(yo)
V cos(a)
(A.26)
Applying the Kutta-Joukowski theorem, we know that the sectional lift must be
equal to the aerodynamic force derived from the circulation around this lifting section.
L' = p.V.F(yo) = p.V.c(yo)r sin(aeff) cos(aeff)
(A.27)
Applying the trigonometric identity sin x cos x = 1 sin(2x), we have the following.
12
L' = p2V.F(yo) =p.V.c(yo)r sin(2aeff)
(A.28)
By simplifying this expression, we can then relate the effective angle of attack,
which is a function of the downwash (by equation A.25) to the circulation at a given
station yo.
F(yo)
=
2-Voc(yo)7rsin(2aeff)
(A.29)
Following Prandtl's model, we could assume the circulation has an elliptical distribution.
(A.30)
1-
F(Y) = FO
This distribution satisfies a number of mathematical and intuitive restrictions.
The circulation and lift go to zero at the wing tips, and increases as we move toward
the center of the planform. Furthermore, evaluating the integral in equation A.25
yields a constant downwash over the span of the wing.
w(yo)
=
-P
2b
(A.31)
However, it can be shown that an elliptical lift distribution (and thus an elliptical
circulation distribution) implies that the wing planform is elliptical. This is not true
in general, but since the elliptical distribution has such nice properties, let us assume
that a general distribution will be 'somewhat elliptical'. Now consider a change of
variables such that y =-
cos 6 as illustrated in figure A-11.
z
Figure A-11: Change of Variables
Then the circulation can be expressed as follows.
IF(0) = Fo sin 9
(A.32)
The dependence of the circulation on the sine of the angle hints that a Fourier
sine series may make a reasonable expression for a general circulation distribution
along a finite wing. So we then assume that the actual lift distribution is given by
the following.
F (0)
=
2bVo, E A, sin(n)
(A.33)
We can take as many terms N as needed for a desired level of accuracy in our
estimate. Now we must address the problem of solving for what the coefficients of
equation A.33 are. First, let us observe that equation A.33 is differentiable, and
that since y
=
- cos0, the differential relation between y and 0 is dy =
sin d6.
Therefore the derivative of the circulation along the span of the wing is given by the
following.
dF
d(yo) =2bVo
dF
dy
(YO)
=V.
N
N
dO
nZAn cos(nO) -
(A.34)
nAnco(O)
(A.35)
sin 0
The solution process is motivated by the consistency condition given in equation
A.29. For any proposed coefficients A, we can find the circulation distribution that
they imply by equation A.33. Then from equation A.35 we can find the derivative
of the circulation, which we plug into equation A.25 to find the downwash at each
point along the span. We use this downwash to find the effective angle of attack via
equation A.26. And then we calculate the circulation at this station by A.29. In
order for A to provide the circulation distribution of our wing planform, the output
of equation A.29 must be consistent with the input implied by A.
In order to solve then for A, we will apply an iterated numerical algorithm that
starts with an assumed set of coefficients Ao and follows the flow of the above equations to calculate the error in the consistency condition. The algorithm provides
feedback on that error to update the estimate of A until it converges to a stable
solution. We perform this iterative method of a range of angles of attack, and then
find a least squares fit for the whole-body lift coefficient.
Before describing the algorithm it is useful to make a few alternate definitions.
We define the velocity normalized circulation F as F/V,
and velocity normalized
downwash w(yo) as w(y,)/V,. With our Fourier approximation of F, this yields the
following.
N
F(0) =2b
A,, sin(nO)
(A.36)
1
dI (yo) =
d(y
nAn
(A.37)
sin 0
1
W(Yo) =
/
47r
-5/2
YO - Y
dy
(A.38)
Note that equation A.36 can be expressed as a linear equation. If we define the
vector I
i = i Vi = 1 ... N, the vector 9 to contain the parameter O for each of the n
span-wise locations, and the matrix F = sine
(OIT)
then the vector of the circulation
evaluated at each of those locations is given by F = FA. Here, the function sine is
the element-wise sin function. Also, we can describe how close the two circulation
distributions F and 1 are by the sum of the square of their errors.
r ='
=
- f) T T-(A.39)
(F- - f) T (FZ_ - ]F)
(.0
Furthermore, since the circulation has a linear relationship in the coefficients,
given a desired arbitrary distribution Fd, we can find a close approximation (in a
least-squares sense) in the form of our sine series by applying the linear least-squares
rule to find the coefficients.
Ad = (FTF)~1 FTd
(A.41)
Based on the definition of velocity normalized downwash in equation A.38, the
effective angle of attack then has the following geometric relationship.
tan aeff (yo)
-
sin(a) - w(y)
cos(a)
(A.42)
The consistency condition relating the derived normalized circulation, according
to the Kutta-Joukowski theorem to the angle of attack from the assumed normalized
circulation has the following form.
F(Yo)
(A.43)
-c(yo)c(aeff)
2
The integral in equation A.38 can be evaluated numerically over n (finite) sections
of width Ay along the wing span by using Simpson's rule.
=
(YO)
(ddy)
1(YO)
f2
-b/2 yo- Y
47r
(A.44)
(d1/dy)j-i1
47r1Y 3y
YO - yj_1
(dF/dy), ± (dF/dy) j +1
YO- Yj
yo Y
- j+1
(A.45)
Note that if we are evaluating the downwash at station i (yo = yi) then there is a
singularity where i =
j
- 1, j, j + 1. We can address this by approximating the con-
tribution to the total downwash by these terms with the average of the contribution
from the left and the right side.
Given these definitions, the algorithm to calculate the circulation profile at a
given geometric angle of attack a is given below in algorithm A.1. We can find the
whole-body lift coefficient by applying algorithm A.1 at a range of angles-of-attack,
and then performing linear least squares to find the best fit of the result to the form
CL(a) = k sin(2a). If we input a range of geometric angles of attack given by a, and
algorithm A.1 generates a vector of lift coefficients CL, we can calculate the constant
of proportionality via the following equation.
k
sin
sine(2a)T sine(2d)
83
(A.46)
Algorithm A.I Calculate CL(a)
Require: A,
c~,/y,
,
a. kd
N < length(A)
n -= length(Q)
r <= 1, dr <= 1
#0; i=< acos(jyi)
F
-- sine
(JT)
while IdrI > 0.1% AND r > 0.01% do
F1| T
= [A.36}(Oi)
j
.-
=[A.371(yi)
| wi <= [A.45](yi, Ay)
aeff I aeff5 <=
[A.421(a, y )
c I, <- 7r sin(2aeffi)
F I Fj <- [A.431(ci, ci)
r o -= r
r 4- [A.40 (it, T)
dr <-
F <-
r
ro
IF+
kd
-
A < [A.41](F, Pd)
end while
CL
<= (Ei cicii) / (E c)
return CL
As an example, algorithm A. 1 was run on the nexus planform at an angle of
attack of a = 10, starting with an elliptical distribution (Ao = 1; Ai = 0, i = 2... 5),
with a desired resolution of N
=
5. The algorithm converged to within 0.3% after
196 iterations, at which point the marginal gain was below 0.01%. The resulting
distribution is illustrated in figure A-12 (solid) compared to the initial elliptical guess
(dashed). The algorithm was then repeated at increments of 10, and the resulting
lift coefficient at each angle of attack are shown in figure A-13, along with the least
squares fit to the data.
0.02
r=0.003
dr=-0.0
%
0.01-
0.005
0
-1
-0.5
0
y (normalized)
0.5
1
Figure A-12: Circulation Result
0
20
40
60
80
a (*)
Figure A-13: Lift Coefficient Result
86
Appendix B
Proofs from Chapter 4
Proof of Geometric Relationship Between
B.1
Vector and Rotation
This section will derive the following: for any unit vector v, and a rotation described
by a (unit) axis r and an angle 0 E [0, 7r), the relationship between v and the vector
v', found by rotating v an angle 9 about r is given by the following.
v - v' = tano/2(r x (v + v'))
(B.1)
First we note that, by definition, the cross product r x (v + v') is perpendicular
to both r and (v + v)'. We then show that, if r / v, then (v - v') is parallel to
r x (v + v)', by showing that (v - v') is perpendicular to both r and (v + v').
(v
-
by distributive property of dot product
(B.2)
vr= IIvIIIIrII cos a
where a is the angle between v and r
(B.3)
v'- r
because a is preserved by a rotation about r
(B.4)
so (v - v') I r
(B.5)
v') r
=
=
v - r - v'- r
||v|||r| cos a
(V -v') - r =0
We now show that (v - v') is perpendicular to (v + v').
(v - v') - (v + v') = (v
-
S-v-v-v
=1-v-
(B.6)
v') - + (v + v') -v'
v'
+v-v
+
v*-v
-
-v
*v
(B.7)
(B.8)
1
-o0
(B.9)
Furthermore, by the right-hand rule for rotations and for cross-products, and
because 0 < -r we see that (v - v') is in the same direction as r x (v + v').
/
r X (V+ V' r-
v'r-
/
-
V, + v '
Figure B-1: Geometry of Vector Relationship
From the perspective of a frame perpendicular to r, if r makes an angle a with
the v, we can see that the magnitude of (v - v') is given by the equation B.10.
Furthermore, we note that the point where (v + v') intersects with the line segment
from v to v' is exactly half the distance from the origin to (v + v'). Therefore, if
(v + v') makes an angle 3 with r, then from the geometry we see that equation B.11
holds.
VV
0~
02
"
||L)V
V- v'|| = 2 sin a Sin 0/2
sin a cos 0/2
Figure B-2: View From r
= 1/21
V+ v'Ilsin #
(B. 10)
(B.11)
We further note the following relationships.
sina = ||r x vi
sino
#=
r x
(B.12)
v +I v'
V+v/
(B.13)
||v + V'||
Applying equations B.13 and B.13 to B.11, we see the following.
rx
||v +v'||
211rxvl cosO/2
(B.14)
||v +v'||
We showed above that r x (v + v') is in the same direction as v - v'. Therefore
it is also true that r x
v+V'
is in the same direction as v - v'. Equation B. 14 gives
us an expression for the magnitude of that vector, which we can use to normalize it,
giving us a unit vector in the direction of v - v'. Furthermore, equation B.10 gives us
an expression for the magnitude of v - v'. We can calculate an expression for v - v'
by multiplying its magnitude, by a unit vector in the correct direction. Therefore, we
have the following:
V- V'
__2||r
=
x v||sinO/2||v +v'||
2=rxVIIS/2
2||Jr
xI
v| COS 0/2
rx
v +v'
v/
(B.15)
||v + V'||)
(B.16)
tan /2(r x (v + v'))
We have shown this is true for v 4 r, but when v = r then v' = v, and the cross
product r x (v + v') = r x 2r = 0, so the equation holds even when v = r.
B.2
Proof of Finite Limit
This section will justify the claim that, for current orientation R and desired orientation Rd, with a magnitude of the group error 0, the limit limO.
Fbi-Fbid/sinO
is finite.
We will justify the claim for the horizontal body plate (i = h), though the argument
is the same for the vertical body plate (i = v). We start by expanding out the force
model as follows:
lim Fbh - Fbhd = im khVzVz - VzdVXZd
0-*0
sin6
->O
sin 0
(B.17)
We then note that the velocity in the body frame can be related to the velocity
in the desired frame by the following:
v
=
RTRdVd
=
exp(Or)vd
(B.18)
Where the exponential of a rotation vector with magnitude 6 and unit direction
r is given by Rodrigues's formula, in which we apply the "hat" operator ( ^ ), which
generates a skew symmetric matrix with zero diagonal whose elements are composed
of the elements of its argument, such that fx = v x x.
exp(or) = [13 + f sin 6±+
When R = Rd, V
= Vd
2 (1
- cos )]
(B.19)
and the limit has indeterminate form o/o. Therefore, we
apply L'Hospital's rule to evaluate the limit.
lim k vzVxz
0-*0
-
VzdVxzd
sin 0
= lim kh dez
0-+0
v
cos 9
dv
(B.20)
Applying Rodrigues's formula to equation B. 18, we have the following derivatives
for the components of v.
d
dO
= e T2Va) sin 6 + (eT iVd) cos 0
(e f v1
(B.21)
d
o= (eY2vd)
d
v =
Then, since
V2
=
sin 6 + (e2ivd) cos 6
(eT?2 vd) sin 9 +
(efvd) cos 0
v2 + V2 the limit becomes the following:
(B.22)
(B.23)
dv
lim k
dO Vz
+ V dv2 Z
o
Cos 0
0-+0
dO
- limkoVsz
K[(eTf 2vd)
sin 0 + (ePvd) cos 01
0-0
(B.24)
Cos 0
vz vx [(e ? 2vd) sin 0 + (eTfvd) cos 01
cos 0
VXZ
vz vz
[(ei 2 va) sin 0 + (e3vd) cos 01
cos 0
Vxz
(B.25)
(B.26)
Evaluating at 0 = 0 we get the following.
lim kh
0-0
dv
dOxz
+ V dvxz
+
Cos 0
Skh
XZ (eTiva)
+
vxez
Vxz
(e
1Vd
+ vz (egTVd)
Vxz
(B.27)
92
Bibliography
[1] John J. Bertin and Michael L. Smith. Aerodynamics for Engineers. Prentice-Hall,
Upper Saddle River, NJ, third edition, 1998.
[2] Adrian Frank, James S McGrew, Mario Valenti, Daniel Levine, and Jonathan P.
How. Hover, transition, and level flight control design for a single-propellor
indoor airplane. In AIAA Guidance, Navigation and Control Conference and
Exhibit, 2007.
[3] E. Frazzoli, M.A. Dahleh, and E. Feron. Trajectory tracking control design for
autonomous helicopters using a backstepping algorithm. In American Control
Conference, 2000. Proceedings of the 2000, volume 6, pages 4102 -4107 vol.6,
2000.
[4] J. Hauser and R. Hindman. Aggressive flight maneuvers. In Decision and Control,
1997., Proceedings of the 36th IEEE Conference on, volume 5, pages 4186 -4191
vol.5, 10-12 1997.
[5] John Hauser, Shankar Sastry, and George Meyer. Nonlinear control design for
slightly non-minimum phase systems: Application to v/stol aircraft. Automatica,
28(4):665-679, January 1992.
[6] John D. Anderson Jr. Fundamentals of Aerodynamics. McGraw-Hill, New York,
NY, third edition, 2001.
[7] Hassan K. Khalil. Nonlinear Systems. Prentice Hall, Upper Saddle River, New
Jersey, third edition, 2000.
[8] Donald E. Kirk. Optimal Control Theory, An Introduction. Dover, Mineola,
New York, thirteenth edition, 1998.
[9] Richard M. Murray, Zexiang Li, and Shankar S. Sastry. A Mathematical
Introduction to Robotic Manipulation. CRC, 1 edition, March 1994.
[10] Robert C. Nelson. Flight Stability and Automatic Control. McGraw Hill, Singapore, second edition, 1998.
[11] Prouty. Helicopter Performance, Stability, and Control.
Florida, fourth edition, 10 October 2005.
Krieger, Malabar,
[12] John W. Roberts, Rick Cory, and Russ Tedrake. On the controllability of fixedwing perching. In ACC'09: Proceedings of the 2009 conference on American
Control Conference, pages 2018-2023, Piscataway, NJ, USA, 2009. IEEE Press.