Stanford University
AA241X: Final Report
June 12, 2013
Team Infinity Eye
Authors:
Harrison Chau, Hakki Karakas, Robert Karol, DongHyun Kim, Guilherme Loures, Devina
Sanjaya, and Manu Sharma
This report is compiled and revised by Devina, and edited by Harrison
Table of Contents
List of Figures
iii
List of Tables
iv
1 Design of our airplane (analysis done
by Devina)
1.1 Weight Breakdown . . . . . . . . . .
1.2 Design Requirements . . . . . . . . .
1.3 Wing Loading Calculation . . . . . .
1.4 Wing Geometry Calculation . . . . .
1.5 Airplane Dimensions . . . . . . . . .
1.6 Airplane Inertias . . . . . . . . . . .
by Hakki and written part revised
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Performance analysis of our airplane (analysis done by Hakki
part revised by Devina)
2.1 Center of Gravity and Lift-to-Drag Ratio Calculation . . . . . .
2.2 Trim Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Power Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Lift-to-Drag Ratio Measurement . . . . . . . . . . . . . . . . . .
2.5 Climb and Turning Performance . . . . . . . . . . . . . . . . . .
2.6 Damping Ratios and Frequencies . . . . . . . . . . . . . . . . .
2.7 Stability Derivatives (Harrison) . . . . . . . . . . . . . . . . . .
3 Manufacturing and construction process (Hakki and Manu)
3.1 Material Selection . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Improvements From Initial Prototype (Manu and Devina) . . .
3.3 XFLR5 Model (Hakki, written part by Devina) . . . . . . . . .
3.4 Building Process . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Description of Building Process . . . . . . . . . . . . . .
3.4.2 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . .
3.5 Flight Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Observation . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2 Lessons Learned (Devina) . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
and written
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
7
8
8
10
11
11
.
.
.
.
.
.
.
.
.
13
13
13
15
15
15
16
16
16
17
4 Mission plan/ strategy (Devina and Robert)
4.1 State Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Dynamics and Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Waypoint Following . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Path Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Beacon Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 MATLAB-based Simulation of Mission Plan (any updates after PS2 was done
by Devina) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
1
1
1
2
3
4
5
17
18
18
19
20
20
21
4.6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.2 Energy Consumption Estimation . . . . . . . . . . . . . . . . . . . .
4.6.3 Static and Dynamic Path Planning Algorithm . . . . . . . . . . . . .
4.6.4 Expected Simulated Score . . . . . . . . . . . . . . . . . . . . . . . .
MATLAB/ SIMULINK-based Simulation of Flight Path (Manu and Guilherme)
21
21
22
22
24
5 Final control system design (Robert, helped: Devina, Hakki, and Harrison,
written part revised by Devina)
5.1 Longitudinal and Lateral Aircraft Dynamics . . . . . . . . . . . . . . . . . .
5.2 Control Law and Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Advantanges and Disadvantages of Using Modern Control . . . . . . . . . .
5.4 Choice of Dynamics Model and Debugging Process . . . . . . . . . . . . . .
5.5 Attempt to Implement Line Tracking (written by DongHyun) . . . . . . . .
5.6 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
28
29
31
31
32
32
4.7
6 Experimental result and observation from all autonomous flights in the
competition (Robert)
33
7 Experimental and Simulated Score (Devina)
7.1 Complete Mission with Bixler 2 . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Attempt to Complete a Mission with our own Airplane . . . . . . . . . . . .
38
39
40
8 Website and archived files (Devina, Hakki, Harrison, Manu, and Robert) 41
Appendix: Results from MATLAB Simulation of Mission Plan (Devina)
ii
42
List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Wing loading vs. Thrust/Weight plot . . . . . . . . . . . . . . . . . .
Lift Distribution Without Fuselage . . . . . . . . . . . . . . . . . . .
Dimensions of our proposed airplane . . . . . . . . . . . . . . . . . .
Weight distribution and location of center of gravity . . . . . . . . . .
Aerodynamic performance polars of our proposed airplane . . . . . .
Required power at various velocities . . . . . . . . . . . . . . . . . . .
Altitude vs. time during flight test . . . . . . . . . . . . . . . . . . .
Airspeed vs. time during flight test . . . . . . . . . . . . . . . . . . .
Required power at various climb gradients . . . . . . . . . . . . . . .
First airplane design . . . . . . . . . . . . . . . . . . . . . . . . . . .
Final airplane design . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rebuilt airplane and Bixler 2 . . . . . . . . . . . . . . . . . . . . . .
Complete static path and field of view . . . . . . . . . . . . . . . . .
Sample flight paths . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample altitude vs. time plot . . . . . . . . . . . . . . . . . . . . . .
Simulating environment overview . . . . . . . . . . . . . . . . . . . .
Simulating environment Dynamics block . . . . . . . . . . . . . . . .
Sample flight paths . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . .
Line tracking algorithm . . . . . . . . . . . . . . . . . . . . . . . . . .
Experimental result from a full mission with Bixler 2 . . . . . . . . .
Aileron, elevator, rudder, and throttle commands vs. time for Bixler 2
Experimental result from a mission with our own airplane . . . . . .
Aileron, elevator, rudder, and throttle commands vs. time for our own
Simulated path for a complete mission with Bixler 2 . . . . . . . . . .
Simulated path for a mission with our airplane . . . . . . . . . . . . .
iii
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
airplane
. . . .
. . . .
3
3
4
5
7
8
9
9
10
14
14
15
19
23
24
25
26
27
30
32
34
35
36
37
40
41
List of Tables
1
2
3
4
5
6
7
8
9
10
11
Component-by-component mass breakdown of our final airplane design
Initial design parameters . . . . . . . . . . . . . . . . . . . . . . . . . .
Inertias of our proposed airplane . . . . . . . . . . . . . . . . . . . . . .
Damping ratios and frequencies analysis of our proposed airplane . . .
Non-dimensional derivatives of our final aircraft . . . . . . . . . . . . .
Statistical result from 30 simulation cases . . . . . . . . . . . . . . . . .
True beacon location for a complete mission with Bixler 2 . . . . . . .
Simulation result for a complete mission with Bixer 2 . . . . . . . . . .
True beacon location for a mission with our own airplane . . . . . . . .
Simulation result for a mission with our airplane . . . . . . . . . . . . .
Data from path planning simulation . . . . . . . . . . . . . . . . . . . .
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
6
11
12
24
39
39
40
41
43
1
Design of our airplane (analysis done by Hakki and
written part revised by Devina)
In this section, we detail the design process of our airplane. This section includes the threeview drawing and physical characteristics of our final airplane design.
1.1
Weight Breakdown
Weight is an important property to consider during the design process. Foam was chosen as
the material, instead of balsa, since the maximum saving in mass from using balsa is only
about 20-30 grams, and foam is less fragile and is easier to fix. The manufacturing and
construction process is described in detail in section 3. Table 1 details the estimated and
measured component-by-component mass of our final airplane. The total weight is 5.15 N.
Component
Motor
Propeller
Battery
ESC
Telemetry Radio
Ardupilot
Wing
Fuselage
Boom
Tails
Total
Measured Mass (g)
60
10
80
20
20
115
110
60
20
30
525
Table 1: Component-by-component mass breakdown of our final airplane design
1.2
Design Requirements
In designing the airplane, we choose some important speeds for our airplane to ensure safe,
efficient flights. First, we set our stall speed to be low to ensure that the airplane can fly
slowly without stalling and landing without damaging the airplane. Second, we set our cruise
speed (Vcruise ) to be 8 m/s to ensure high cruise range so that we can increase our coverage
area without flying very slow. These speeds were chosen because our best endurance speed
is very close to our stall speed (Vstall ), which is 5.25 m/s. Although we choose not to fly at
our best speed, we will not suffer high penalty by flying a little faster. In addition to speeds,
we also chose our cruise altitude (hcruise ), aspect ratio of the wing (AR) and climb gradient
(G). Table 2 summarizes our initial design parameters.
1
Parameters
Vstall
Vcruise
hcruise
AR
G
Initialized Value
5.6 m/s
8 m/s
400 ft
8.76
0.261 rad
Table 2: Initial design parameters
1.3
Wing Loading Calculation
Based on our design requirements, we constructed our wing loading (W/S) vs. thrust-toweight ratio (T /W ) graph. We will use this graph to choose our W/S value. Thus, based
on the weight of the airplane and the thrust specified by the manufacturer or our propeller,
we determined the wing area. This analysis is based on Raymer’s airplane design method.
Equations 1, 2, and 3 are used to construct our W/S vs. T /W graph. These equations
ensure that we satisfy our stall speed constraint, best range cruise speed constraint, and rate
of climb constraint, respectively.
2
(W/S)stall = 0.5ρVstall
CLmax
(W/S)cruise = q
(W/S)climb
q
π(AR)eCDp
s
CDp
1
= (T /W − G) + q(AR)e (T /W − G)2 − 4
2
π(AR)e
(1)
(2)
(3)
Figure 1 shows our W/S vs. T /W graph. The blue vertical line corresponds to stall speed
constraint, the vertical red line corresponds to cruise speed constraint, the horizontal yellow
line corresponds to propulsion constraint, and the green curve corresponds to climb constraint. Here, we can see that we have more than enough thrust to choose the highest W/S,
but W/S is constrained by stall speed. Using equation 1, we obtain
(W/S)stall = 0.5 × 1.223 × 5.62 × 1.1988 = 22.98 N/m2 .
This is the value we will further use for our calculations. So, our wing loading is
W/S = 22.98 N/m2 .
2
Figure 1: Wing loading vs. Thrust/Weight plot
1.4
Wing Geometry Calculation
Based on our W/S and W , we obtain the reference area (Sref ) to be 0.2238 m2 . Using
this value and our chosen AR, we found the wing span (b) of our airplane to be 1.4 m.
Using XFLR5, we determined the dimensions of our wing. We aim to get an elliptical lift
distribution on the wings at cruise speed. Figure 2 shows the lift distribution without the
fuselage. The dashed line is a perfect ellipse, and the solid line is our lift distribution. Here,
we can see that the lift distribution is very close to an ellipse.
Figure 2: Lift Distribution Without Fuselage
3
1.5
Airplane Dimensions
After we designed our wing and fuselage, we used XFLR5 to design tail surfaces. We then
created our model in XFLR5 with using our design dimensions. We used SD7032 airfoil
for the wings which is low reynolds number airfoil. Our fuselage is designed to blend with
the wing. The fuselage uses NACA 0021 airfoil. Our propeller is mounted on the nose of
the airplane. Figure 3 shows dimensions of our proposed airplane, and figure 4 shows the
positions of the weights and center of gravity (CG).
Figure 3: Dimensions of our proposed airplane
4
Figure 4: Weight distribution and location of center of gravity
Other important design parameters are below.
Sref = 0.2238
Svertical = 0.0163
Shorizontal = 0.0487
Incidence of horizontal tail to fuselage = 0◦
M AC = 168.64
Static Margin = 22.4%
1.6
m2
m2
m2
mm
Airplane Inertias
Table 3 shows the calculated inertias for our proposed airplane.
5
Inertias
Ixx
Iyy
Izz
Ixz
(104 kg.mm2 )
1.557
1.524
3.031
0
Table 3: Inertias of our proposed airplane
2
Performance analysis of our airplane (analysis done
by Hakki and written part revised by Devina)
In this portion of the report, we detail our performance analysis. This section includes
calculations for center of gravity and lift-to-drag ratio (L/D), trim, required power, damping
ratios and frequencies, and stability derivatives.
2.1
Center of Gravity and Lift-to-Drag Ratio Calculation
First, we calculated our best cruise CL value to get the best cruise speed for our airplane.
p
CLbestcruise = π(AR)CDp = 0.9899
q
Vbestcruise = 0.5ρSref CWL,best
= 6.19 m/s
cruise
Now, we need to calculate the drag at this speed and the CL values. Parasitic drag of the
airplane is calculated to be 0.0356. Therefore,
CD = CDp +
2
CL
π(AR)e
= 0.0807
Recall that from section 1.3, we found that CLmax = 1.1988 . Thus, the maximum lift-to-drag
ratio is
(L/D)max = CL /CD = 12.26
Since we are not flying at our best cruise speed, we calculated L/D at our cruise speed (= 8
m/s) to make sure that this design still flies effectively at our cruise speed. Note that since
this speed is higher than best cruise speed, the L/D will be lower. Assuming that the change
in parasitic drag is negligible with small speed increment, we only need to calculate new CL
value to calculate L/D at 8 m/s. Thus,
CLcruise =
(L/D)cruise =
W
= 0.5949
2
0.5ρSref Vcruise
CL
= 0.5103/0.445 = 11.46
CD
So, by flying faster, we lose 6.9% of (L/D)max , which is reasonable.
6
2.2
Trim Analysis
We chose to perform the trim analysis not at our best cruise speed because our best cruise
speed results in CL = 1.06, which is very high. To trim the airplane at this speed in vortex
lattice method, the CG point is adjusted to be a little back of the 25% mean aerodynamic
chord (M AC). Figure 5 shows aerodynamic performance polars of our proposed airplane.
The green dot is our trimmed point.
(a) CL vs. α
(b) CL vs. CD
(c) Cm vs. α
Figure 5: Aerodynamic performance polars of our proposed airplane
7
2.3
Power Analysis
To calculate the required power, we assume the overall efficiency of the propulsion system
to be 40%. We also took in to account the power usage for autopilot, GPS, and telemetry
system, which is nearly 30% of total required power. First, we calculate CD value at flight
speed to find drag. For a level flight, thrust is equal to drag. The required power can be
calculated using thrust and velocity (see equation 4).
P = T V = DV
(4)
Thus, the required power is shown in equation 5
Preq = P/ηoverall
(5)
Figure 6 shows the relation between power and velocity and the required power at our design
point.
Figure 6: Required power at various velocities
The required power at our design point is 19.49 W. Using this value and accounting energy
loss from the climb we can calculate total flight time for our airplane.
ttotal = (Etotal − Eclimb )/Preq + tclimb = 7.82 min
2.4
Lift-to-Drag Ratio Measurement
Figures 7 and 8 show our flight test data of our own aircraft. This set of data is obtained
from our third flight test, as explained on section 3.5.
8
Figure 7: Altitude vs. time during flight test
Figure 8: Airspeed vs. time during flight test
From these data, we can see that we tried to fly the airplane at different altitude and try to
do several maneuvers to make sure the airplane flies well. From the airspeed data, we can
see that we started by flying slowly, and the airspeed was between 4 m/s and 6 m/s (see
airspeed when 200 s ≤ t ≤ 500 s). Looking at the altitude plot, we can see that at about 350
s and 425 s, the aircraft drops to lower altitude and speed increases. The drop in altitude
shows that the airplane stalled and we increase the throttle and brought the airplane back
up. Between 200 s and 500 s, the airspeed is between 5 m/s and 6 m/s. Averaging these
9
values, we found that our stall speed is about 5.5 m/s. Thus, the measured maximum lift
coefficient is
CLmax =
W
2
0.5ρSref Vstall
= 1.2592
In section 2, we found that our calculated CLmax = 1.1988, which is about 4.8% lower than
the measured CLmax . Thus, we can conclude that our calculation agrees with our flight test
data.
2.5
Climb and Turning Performance
Recall that our climb gradient is 0.261 rad. At this climb gradient, the required power is
71.1 W. Figure 9 shows the required power at various climb gradients.
Figure 9: Required power at various climb gradients
10
Next, we calculated our max turning rate to use in our autopilot. Assuming our load factor
is 2 (reasonable for RC airplanes), we obtain
ψmax =
2.6
√
g n2 −1
V
= 2.124 rad/s = 121.7 deg/s
Damping Ratios and Frequencies
Table 4 shows damping ratios and frequencies of our airplane. We obtained this value from
XFLR5.
Mode
Damping Ratio
Short period
Phugoid
Dutch roll
Spiral
Roll
0.844
0.051
0.321
0.000
0.000
Undamped Natural
Frequency (Hz)
1.445
0.172
0.854
0.000
0.000
Damped Natural
Frequency (Hz)
2.697
0.173
0.902
0.000
0.000
Table 4: Damping ratios and frequencies analysis of our proposed airplane
2.7
Stability Derivatives (Harrison)
Table 5 shows stability derivatives of our airplane. We obtained these values from XFLR5.
In section 5, we will explain how we use these values in our control system.
11
Parameters Values
CXu
-0.05323
CLu
0.00073
Cmu
-0.00336
CXa
0.38066
CLa
5.31148
Cm a
-1.18992
CXq
-0.20547
CLq
9.18399
Cm q
-17.33060
C Yb
-0.23315
Clb
-0.00870
Cnb
0.07130
C Yp
0.02730
Clp
-0.52685
Cnp
-0.08458
C Yr
0.18916
0.15434
Clr
-0.05512
Cnr
CeXd
-0.00954
CeYd
0
CeZd
0.5524
Celd
0
-1.54597
Cemd
Cend
0
CaXd
0
CaYd
0
CaZd
0
0.34850
Cald
Camd
0
Cand
-0.0398
CrXd
0
CrYd
0.12026
CrZd
0
Crld
-0.00529
Crmd
0
Crnd
-0.03893
Table 5: Non-dimensional derivatives of our final aircraft
12
3
Manufacturing and construction process (Hakki and
Manu)
In this portion of the report, we details our manufacturing and construction process. This
section includes the discussion on the choice of material, XLFR5 model, building process,
and flight testing. For pictures and videos, please visit our website: infinity-eye.com.
3.1
Material Selection
We designed and built our first airplane using blue foam since it is easy to work with. The
total mass of the aircraft is around 570 grams. While we knew that making a balsa airplane
would give us some weight benefit, we were more inclined to stick with foam as our main
material for all our airplanes. To further reduce the weight, we redesigned the fuselage joints
to make it act as a part of wing. Our fuselage was cut in foam cutter with a standard NACA
airfoil profile with chord length of 320 mm.
Our new and final design was only 530-540 grams in total, and was very close and even
lighter than some other balsa airframes designed by other teams in the class. One thing that
we gained using foam was crashworthiness. In spite multiple fatal crashes, our airplanes survived minor crashes while a balsa airframe would be destroyed and take a lot of time to repair.
Overall, using foam, carbon fiber spars, and some epoxy and superglue made most of the
airplane and the result were great. It could have been done better by reinforcing with some
micro carbon fiber rods in the structure, especially in the fuselage to avoid cracks.
3.2
Improvements From Initial Prototype (Manu and Devina)
After testing our initial aircraft prototype, we found several problems and improvements
are needed. The biggest problem was the CG is far too behind. Constrained by the design
of fuselage and wing, which we chose for simplicity and lowest possible weight and drag,
the motor had to be placed over 6 inches forward. To overcome this, we redesigned the
configuration such that this time the wing was moved back by few inches. The second
problem was that the tail had lot of flutter due to a long and slender boom. This problem
was overcome by reducing the size of vertical tail and length of tail boom. Our initial aircraft
prototype is shown in figure 10. After these design change were made, we build the new
airframe. Below is the picture of our final airplane. (see figure 11).
13
Figure 10: First airplane design
Figure 11: Final airplane design
Due to an unfortunate crash two days before the final day of the competition, we built
another airplane for the mission. This design should be the same as shown in figure 11, but
since we did not have access to PRL lab since it was late at night, we did not sand down
part of the fuselage. Also, due to lack of manpower and limited time, on Monday we flew
Bixler 2 for a complete mission and only part of a mission with our own airplane. Figure 12
shows our rebuilt airplane and Bixler 2.
14
Figure 12: Rebuilt airplane and Bixler 2
3.3
XFLR5 Model (Hakki, written part by Devina)
The three-dimensional model of our airplane design was built using XLFR5. We chose
to use XFLR5 to build the model because the software allows us to specify aerodynamic
properties, such as chord length, span, airfoil shape, dihedral, sweep, etc., and it calculates
other properties, such as aspect ratio, reference area, etc. Also, by building the model in
XFLR5, we can use this model for vortex lattice method analysis in AVL and XFOIL.
3.4
Building Process
In this section, we describe our building process and state lessons we learned.
3.4.1
Description of Building Process
We decided to take a very simple and easy approach to build the airframe by using mostly
blue foam and carbon fiber spars. To design the blended fuselage with blue foam, we cut
a hollow NACA 0021 airfoil with chord length of 320 mm and thickness of 10mm. This
would become the center section of fuselage accompanied by two similar sections on each
side semi-hollowed by hot iron. After gluing the sections, we sanded the fuselage at Product
Realization Lab to reach proper blend with the wing section. The greatest advantage of
blending the fuselage and keeping the main fuselage length to only 320 mm was weight. We
found out that the total weight of aircraft frame including wing, spars and tail sections was
around 200 grams.
Our aircraft has T-tail and we joined the tail with fuselage with a very simple construction
15
a square carbon fiber boom. Our servos were mounted on the T tails itself, which mode the
CG move aft but we will move the servos into the fuselage in our next design. Nevertheless,
we added little weight at the nose to compensate for aft CG movement. Overall, the build
of the aircraft was really simple and we were successful in making a lighter aircraft then our
expectations.
3.4.2
Lessons Learned
Firstly, we should have included a slight dihedral to reduce the airplane sensitivity to roll so
that the pilot can control the airplane more easily. However, the lack of dihedral was not a
problem at all for an autopilot. There are two options to add some dihedral to the airplane:
1. Add two small outboard sections at an angle to give the whole wing some effective
dihedral angle
2. Install the wing with an angle which may be little challenging due to spar running
across the fuselage
To get better stability in roll, we could also move the CG down in the height from the
centroid of the wing. Secondly, we learned that we should use better methods to connect
wings, boom and motor mount to fuselage. Currently we used epoxy to glue them, but it
is not reliable for frequent use. Thirdly, we should use solve the vibration (flutter) for the
tail better. There are many ways the tail can be more strengthened without compromising
weight, such as using micro carbon fiber rods on lateral and longitudinal sections of tails to
give better rigidity.
3.5
Flight Tests
In this section, we detail our observation from flight testing our own aircraft and the lessons
learned from flight testing. Since we did more flight tests with Bixler 2, we will talk in more
detail about the lesson learned from Bixler 2 flight tests.
3.5.1
Observation
We begin new test flights with the airframe following similar flight envelope testing as we
mentioned in Homework 2. The aircraft flew as expected. The roll is extremely sensitive and
has not improved from the previous prototype, but our autopilot can control the roll stability.
Flight 1: Slow ascent and Descent Powered Flight 100 m (Hakki and Manu)
At throttle of about 30%, the aircraft took off upwind and the aircraft behaved very stable
and flew steady. Due to its light weight, it had tendency to gain altitude without additional
throttle (due to winds) but we landed safely. Successful flight.
Flight 2: Full Round Course Flight at Lake Lagunita (Hakki and Manu)
During the next flight, we expanded our envelope to rather full course flight. We flew the
16
airplane at about 10 m/s (gusty winds). The aircraft behaved really well and responded very
well up elevator and ailerons.
Flight 3: Another Full Round Course Flight at Lake Lagunita (Hakki and Devina)
From previous flight data, we found that we placed the pitot tube too close to the propeller,
and thus the data is affected by the downwash from the propeller. So, for this flight, we
place the pitot tube farther away and repeat the test done in flight 2. During the flight, we
observed that the airplane likes to roll due to the lack of dihedral.
3.5.2
Lessons Learned (Devina)
From multiple flight tests, we found that once we got the autopilot to work, the autopilot can
fly both our airplane and Bixler 2 better than us, especially during high wind. The autopilot
did a better job in keeping the airplane stable than we can. We also tried the following with
our autopilot on Bixler 2:
1. Taking off with autopilot
2. Flying Bixler 2 when ground speed 2 m/s and air speed is about 11 m/s
Thus, we know that our autopilot is capable of flying the airplane during high wind, and
our autopilot will work for any remote-controlled airplanes as long as we input the correct
stability derivatives to change the dynamics of the airplane. Note that we did not tune any
gain when we transition from Bixler 2 to our own airplane. Even so, some tuning might be
needed depending on the airplane design.
4
Mission plan/ strategy (Devina and Robert)
In this portion of our report, we detail our mission plan/ strategy that we used in the MATLAB simulation and in the mission. We also include MATLAB simulation that focuses on
the mission plan and excludes any dynamics of the airplane and MATLAB/ SIMULINK
simulation that simulates the dynamics of the airplane and takes in the location of the waypoints generated by the MATLAB simulation. We used only the MATLAB simulation for
implementing our mission plan in arduino since the MATLAB/ SIMULINK simulation was
not ready in time.
Our mission plan consists of five important components: state estimation, a stabilizing
controller, the ability to perform waypoint tracking, a path planning method, and beacon
estimation. We will detail our thoughts on each component and describe the simplified
algorithm that is implemented in arduino if any.
17
4.1
State Estimation
For our mission plan, we consider the following states:
• x: x-location
• y: y-location
• z: z-location
• ẋ: x-velocity
• ẏ: y-velocity
• ż: z-velocity
• φ: roll
• θ: pitch
• ψ: yaw
• φ̇: roll rate
• θ̇: pitch rate
• ψ̇: yaw rate
• α: angle of attack
• β: side slip angle
• h: altitude
• ḣ: rate of change of altitude
In the MATLAB Our state estimation method is to estimate the variables by using the raw
sensor data, and perform a numerical integration / rotation scheme in order to estimate the
remaining state variables.
4.2
Dynamics and Controls
We are using LQR for lateral and longitudinal controls (see section 5 for details). The
dynamics model of the aircraft was based on Automatic Control of Aircraft and MIssiles by
Blakelock.
18
4.3
Waypoint Following
Our MATLAB simulation (CompleteOpenLoopPath.m) generates a set of waypoints for our
static path planning. These points determined our initial flight path until the airplane finds
all beacons. Figure 13 (generated using CompleteOpenLoopPath.m) shows the complete
static path with the field of view. This trajectory will allow us to efficiently scout out
the beacons, and since we will have no prior knowledge about the locations, no dynamic
waypoints will be needed. If the airplane completes the static loop, the aircraft will be
spiraling up to the maximum altitude of 400 ft. The green color indicates the first part of
the static path, and the purple color indicates the second part of the static path.
150
100
y (m)
50
0
−50
−100
−150
−200
−150
−100
−50
0
x (m)
50
100
150
200
Figure 13: Complete static path and field of view
Once all beacons are seen, the waypoints will be generated dynamically based on our cost
function that takes into account the amount of energy used to visit the beacon and the
percent increase in accuracy. The path planning will be discussed in more detail in the next
section (see section 4.4).
Unfortunately, we did not have enough manpower and time to implement the dynamic
waypoint following. For our mission, we used a set of waypoints generated by the MATLAB
simulation for static path planning (with slight modification)
and three points that at our
Student Version of MATLAB
estimated beacon location after all three beacons are seen. Since MATLAB simulation does
not take into account the dynamic of the airplane, we used flight test to modify the waypoints.
We found that we needed to delete the second waypoint since the airplane is not capable of
making such a sharp turn and the extra distance allows the autopilot to stabilize and make
a smooth turn. By following these waypoints, the airplane will cover most of Lake Lagunita,
and once the airplane finds all three beacons, the airplane will go back and forth between
19
three beacons; no cost function applied here. Since waypoint following worked well, we did
not implement line tracking. We did try to implement line tracking, but it did not work so
well, and due to limited time, we used waypoint following instead.
4.4
Path Planning
In MATLAB simulation (openlooppath.m), the path planning is a two tiered approach.
First, the aircraft will follow the static open-loop path (spiral path as shown in the previous
section) for scouting the three beacons offline. As soon as all beacons are found, a dynamic
path planning algorithm will switch in. This planning algorithm will calculate an expected
reward of scouting each beacon. This reward will be calculated based on the current estimated error, as well as the energy used of taking more measurements at that site. The
plane will remain at the same altitude as at the last altitude in static open-loop path, and
then take more measurement as needed; the necessity of visiting which beacon to take extra
picture is determined by a cost function that takes into account the amount of energy spent
to visit the beacon and the improvement in our estimation. The aircraft will fly back and
forth and take more picture until the estimated error is around 3 meters, the flight time is
about 7 minutes, or all energy in the battery is used. These constraints are based on our
score calculation that take the error to be minimum of 3 meters and our experimental result
of endurance time. There is no optimization done for the path planning.
Our path planning that is implemented in arduino is a little different; we simplified our path
planning due to limited time. Similar to our MATLAB simulation, we have the airplane
start flying in a spiral path. However, there’s no cost function applied here. So, the airplane
will fly back and forth between three beacons, while in our MATLAB simulation the airplane
will not visit a beacon unless we need to improve the accuracy of our estimation without
draining too much battery. We did not use MATLAB/ SIMULINK simulation for our path
planning since the simulation was not ready in time.
4.5
Beacon Estimation
For our MATLAB simulation, the beacon estimation method is to discretize the space, and
slowly chip away at it as new measurements are taken. Since every time we do not see the
beacon in our field of view, we know that there are no beacons in a given area, we can then
mark those spaces as visited with no beacon. Every time a new measurement is taken which
contains the beacon we can mark a set of points as potential places for the beacon to be and
average those locations in the end. It turns out that this method is hard to implement in
arduino. Thus, we implement Kalman filter for our beacon estimation in arduino.
For arduino, we use a Kalman Filter with stationary dynamics to get an accurate estimate of
the beacon location. This requires small amount of computation and memory consumption.
However, it is no longer taking advantage of the strict boundaries given to use through the
measurements. These hard bounds could be vary useful for our estimation, and discarding
them would result in estimates outside of the allowable region.
20
4.6
MATLAB-based Simulation of Mission Plan (any updates after PS2 was done by Devina)
From our MATLAB simulation, we created our static path planning algorithm that the
aircraft will follow once it gets to 100 ft altitude until it sees all three beacons, and our
dynamic path planning algorithm that the aircraft will follow once it sees all three beacons.
The simulation is performed for our second-iteration aircraft.
4.6.1
Assumptions
This simulation assumes that the aircraft is already at 100 ft, the climb rate is 8.57 m/s,
and the velocity is constant at 8 m/s. The simulation does not take into account airplane’s
turning radius, and does not have a model of dynamics and control of the airplane. Thus,
the airplane is treated as a point mass that moves around in the x,y,z plane. The time and
percent energy used calculated from this simulation excludes the time for pre-flight checks,
take off, and landing. Time of sight is set to zero when the airplane crosses 50 ft.
To make this simulation more realistic, we set the constraint in flight time to be no more
than 7 minutes and the percent energy used to be no more than 40%, and we multiply the
approximated time and energy used by a factor of 1.5. This factor should let us compensate for the time and energy used when we actually take into account dynamics and control
of the aircraft, and thus, we can get more accurate approximation in the time and energy
consumption. We set the maximum percent energy used for flight to be 40% since from
experimental data, we found that the electronics on board drained lots of battery, and we
did not take these energy in our energy calculation.
The simulation generates 2 figures for each case: x vs. y (showing our path, true location
of the beacons, target point estimation circles, and our estimation of beacon location) and
altitude vs. time. The energy consumption is printed to the screen as the simulation running.
4.6.2
Energy Consumption Estimation
Our path planning algorithm takes in some performance analysis data, such as CD , ρ, Sref ,
V , and ηoverall , to simulate our energy consumption. The energy consumed (excluding preflight checks, take off, landing, and battery consumed by the electronics) is computed using
equation 6.
1 2
(6)
Econsumed = maircraf t gh + ρV Sref CD (1 + ηoverall )
2
where maircraf t is the mass of the aircraft in kg, g is the gravitational acceleration (= 9.81
m/s2 ), h is altitude in m, ρ is air density (= 1.2008 kg/m3 ), V is aircraft velocity, Sref
is reference area of the aircraft, CD is drag coefficient, and ηoverall is the overall efficiency.
We also know that we will be using 600 mAhr, 7.4V battery. This means that the energy
21
available (Eavailable ) is 1.5984 × 104 J. Thus, we can compute the precent energy consumed
using equation 7. Excluding the energy used for take off, we find that we use about 14% of
our available energy if the aircraft follows our complete static path plan.
%Econsumed =
Econsumed
× 100
Eavailable
(7)
As mentioned previously, we multiply our energy estimation by a factor of 1.5 since we do
not take into account any dynamics and control of the aircraft.
4.6.3
Static and Dynamic Path Planning Algorithm
For static path planning, we have a predetermined path for the aircraft to follow. We calculated the time to complete the entire static path planning to be 105 seconds. At the end
of the static path planning, our simulation will print out the estimated beacon location,
estimated error, estimated percent energy used, and our time of sight.
Entering the dynamic path planning, the aircraft will remain flying at the same altitude,
and start taking more measurement as necessary or until it reaches the limitation in energy
available. For dynamic path planning, we create a cost function based on the estimated
error and energy used to improve the accuracy of our estimation. If the energy used to go
to each beacon is less than 1%, then our simulation will tell the aircraft to take additional
measurement from the beacon with highest estimated error. If the energy used to go to each
beacon is more than 1%, then our simulation will calculate the decrease in error and the
energy used to visit each beacon, and if the percent decrease in the error is 40 times larger
than the percent energy used, then the aircraft will take an additional measurement at that
beacon. The aircraft will stay in the dynamic path planning until the estimated error is
about 3 m, or if there is no more energy.
4.6.4
Expected Simulated Score
To compute the statistics of our expected score, we ran 30 test cases with different locations
of the beacons. The raw data from each test case are included in Appendix. Figures 14
and 15 shows sample figures generated from our simulation. Figure 14 shows our path, true
location of the beacons (symbol: black x with circle around it), target point estimation
circles, and our estimation of beacon location (symbol: yellow circle). The red, green, and
blue circles correspond to first, second, and third beacon, respectively. The percent energy
used is printed to screen. Note that our simulation will tell the aircraft not to visit the
beacon if our estimation from static path is accurate or the energy used to go to the beacon
is too high.
22
150
100
100
50
50
y (m)
y (m)
150
0
0
−50
−50
−100
−100
−150
−150
−200
−150
−100
−50
0
x (m)
50
100
150
200
−200
(a) Case 1: score = 55.5803
−150
−100
−50
0
x (m)
50
100
150
200
(b) Case 2: score = 72.6261
150
150
100
100
50
y (m)
y (m)
50
0
0
Student Version of MATLAB
Student Version of MATLAB
−50
−50
−100
−100
−150
−150
−200
−150
−100
−50
0
x (m)
50
100
150
200
−200
−100
−50
0
x (m)
50
100
150
200
(d) Case 4: score = 55.5803
150
150
100
100
50
50
y (m)
y (m)
(c) Case 3: score = 49.2956
−150
0
0
Student Version of MATLAB
Student Version of MATLAB
−50
−50
−100
−100
−150
−150
−200
−150
−100
−50
0
x (m)
50
100
150
200
−200
(e) Case 5: score = 54.1884
−150
−100
−50
0
x (m)
50
100
150
200
(f) Case 6: score = 107.6828
Figure 14: Sample flight paths
23
Student Version of MATLAB
Student Version of MATLAB
400
350
altitude (ft)
300
250
200
150
100
0
0.5
1
1.5
2
2.5
time (minutes)
3
3.5
4
4.5
Figure 15: Sample altitude vs. time plot
The statistics of our simulated score is tabulated in table 6. Here, we can see that our mean
score improves by about 25% by implementing the dynamic path planning.
Paramaters
Minimum
Maximum
Mean
Variance
Median
Score (static only)
31.86
88.41
45.82 ± 11.32
128.21
42.71
Score (static and dynamic)
44.38
107.68
Student Version of MATLAB
59.37 ± 13.34
177.83
55.10
Table 6: Statistical result from 30 simulation cases
4.7
MATLAB/ SIMULINK-based Simulation of Flight Path (Manu
and Guilherme)
Our MATLAB/ SIMULINK simulation takes into account the dynamics and control of our
airplane, and combines it with our mission path planning algorithm. This simulation has
a sophisticated, 6-degree-of-freedom dynamic model of our airplane. With the high-fidelity,
computationally intensive approach used in this effort, we are able to predict the behavior
of the InfinityEye system given a variety of beacon location setups.
The approach selected to build this simulation consists of an integrated MATLAB/ SIMULINK
system. All of the relevant stability and control derivatives, as well as aircraft parameters,
are inputs in run infEye.m. The simulation then pulls beacon locations and path planning
24
logic from openlooppath.m, and sends the relevant signals to a SIMULINK model that mimics the dynamics of the real life aircraft.
At a high level, the model logos can be represented by figure 16.
Figure 16: Simulating environment overview
The dynamics block, which takes into account the forces and moments that act upon our
aircraft, is quite sophisticated, and was built based on Manu Sharma’s Navion model, and
much of the surrounding infrastructure has been altered to reflect changes needed to this
model. These are reflected in figure 17.
25
Figure 17: Simulating environment Dynamics block
With a strong focus on the reliability of the model, a PID-based control scheme was implemented. Waypoints were taken from the team’s path planning algorithm, and the controller
was tuned to minimize bearing error. As can be shown in figure 18, the aircraft demonstrates stable operation. The average of the scores obtained for the purposes of the AA241X
competition was 52.2545, which would have placed us in a satisfactory position relative to
the other teams’ efforts, most of which used a control strategy similar to the one chosen for
these simulation runs.
26
(a) Flight 1. Score: 51.2477
(b) Flight 2. Score: 49.4624
(c) Flight 3. Score: 56.6060
(d) Flight 4. Score: 51.6820
Figure 18: Sample flight paths
Due to our time constraints and operational priorities that arose in the last few weeks of
the quarter, we were unable to implement the desired state-space controllers in the dynamic
model created. This could have provided a better testing ground for developing and tuning
the controller. In any event, the groundwork is now laid for additional efforts in this arena
for future projects or continued work on Infinity Eye.
27
5
Final control system design (Robert, helped: Devina, Hakki, and Harrison, written part revised by
Devina)
In this section we detail our final control system design and the process of reaching this
design.
5.1
Longitudinal and Lateral Aircraft Dynamics
We have modified our aircraft dynamics by using Automatic Control of Aircraft and Missiles
by John H. Blakelock. The A and B matrices now use stability derivatives defined using
the new text. The longitudinal and lateral equations have been modified to include different
states. The longitudinal state vector is:
• u
• α
• θ
• θ̇
• height
The longitudinal inputs are:
• Elevator
• Throttle
The lateral state vector is:
• β
• φ
• φ̇
• psi
• ψ̇
The later inputs are:
• Aileron
• Rudder
28
The matrices for longitudinal aircraft dynamics for our new design:


−0.1097 0.7843 −9.81 −0.0344 0
−2.1841 −9.8475
0
0.8622 0



0
0
0
1
0
A=

 1.3882 −103.284
0
−2.5945 0
0
−8
8
0
0


−0.1572 2.943
 8.1932
0 


0
0 
B=


 −147.9
0 
0
0
The matrices for lateral aircraft dynamics for our design:


−0.0005 0.0012
0
0 −1.4893


0
0
0.001 0
0



0
−0.0358 0 0.0105 
A = 1000 −0.0068


0
0
0
0 0.001 
0.0284
0
−0.0029 0 −0.0019


0
0.2478
 0

0



B=
270.524 −4.1064 
 0

0
−15.87 −15.5235
The goal of the matrices to solve the following equations.
ẋ = Ax + Bu
y = Cx + Du
5.2
Control Law and Strategy
Our control law and strategy is based on modern controls rather than classical controls. A
PID controller maps one input to one output, while a modern control couples multiple states
and determines the input based on the specified weighting on each state. State space control
uses all available sensor information on the aircraft.
For our case, our state is our output and thus we want the error in the state to be zero. We
do so by using matrices in section 5.1. By driving the error in the state to zero, the airplane
was able to hold similar flight characteristics to what was achieved before the autopilot was
engaged, and even fly more stable than in the manual mode. Figure 19 shows the block
diagram of our control strategy.
29
Nu
Xu
R
+
u
A/C
Y
-K
Nx
X
Xc
-
Figure 19: Control Block Diagram
Here, R is the reference input. In the best care scenario, we are inputing steady-state values,
but instead we set our reference input to be the states we want. These reference inputs are
then scaled by the N matrices (Nu and Nx ), and thus, the commanded inputs are transformed to steady-state states (Xu and Xc ). The steady-state states are then subtracted from
current state vectors. This means that we calculate the difference between Xu and u, and
calculate the difference between Xc and X. This results in the error, and our goal is to
drive this error to zero. The error is then multiplied by the gain matrix K through a gain
matrix to produce the error adjustment commands. The error adjustment commands are
then added to the steady state inputs to produce the control input for the next time step.
The control inputs are scaled to be between 0 and 100. This control design was to stabilize
the aircraft and do altitude holding.
For developing a control scheme, we used a linear quadratic regulator (LQR) to find a gain
matrix (K) by solving algebraic Riccati equation, which minimizes the state optimally for
our given dynamics. The mareix K is then multiplied by the state vector to produce the
control input. Dimensional analysis was done to determine the weighting matrices Q and R.
The gains were calculated with a weighting that minimizes the change in radians since slight
variations in velocity or pitch can be problematic to the autopilot. A yaw wrap around was
implemented to prevent the aircraft to fly in circles due to the change in yaw.
Optimally we would be able to write a sophisticated filtering algorithm for the data, which
smoothed the data, however, due to constraints in time and computational power it was
decided that filtering would not be necessary for a basic autopilot.
For waypoint navigation, we tried to use as much of the state information as possible. We
30
command heading, Ψ, to the controller, and the plane will adjust its heading until has the
required heading to reach the waypoint. Once the plane has reached an area around the
waypoint (we set the radius to be about 7 m), the plane will adjust its heading to go to the
next waypoint. For altitude holding, we specified the altitude to be 100 m, and the controller
allows a variation of 5 m. If the altitude deviates from the specified altitude, the elevator
and throttle will be adjusted to bring the aircraft back to the specified height.
5.3
Advantanges and Disadvantages of Using Modern Control
There are many strengths and weaknesses of using the modern controls design approach.
A major strength is that it quantifies the trade-offs in performance and control usage to
minimize the cost function. Using modern controls also allows us to use all information
provided by the sensors on the airplane. Furthermore, modern controls allows for quickly
recreating new control laws since we only need to change certain parts, and allows for easy
transition between Bixler 2 and our own airplane. A major weakness is that to tune the
gains, new weighting matrices, Q and R, need to be recalculated, and this requires us to
rerun LQR to obtain the new gains, while in PID controller, we can simply change the gains.
5.4
Choice of Dynamics Model and Debugging Process
For modern control to work well, we need a good model that represents the dynamics of
our airplane. We tried two different set of equations: one from Nelson and the other from
Blakelock. The states were different in each textbook. To be able to altitude holding, we
appended added altitude (h) to our state. Later, we found out that we could not use the
dynamics model from Nelson to do altitude holding easily. Thus, we continued on by using
a dynamics model from Blakelock.
Before doing flight testing, we first tested our control law by manually moving the airplane
and seeing its respond. Once we found that the control responds as intended, we ran some
test flights. For a while, we could not get the autopilot to work well. Later, we narrowed
down the problem to the possibility that the APM was broken and the dynamics model was
incorrect. Using new APM and recreating new dynamics model, we started to get a working
autopilot. Then, we created some simple waypoints that form a square, and once it worked
well, we created waypoints that form a spiral. From these flights, we went through a process
of adjusting the gain matrix, and throtlle input. We also calculated the mapping from RPM
to thorrtle input so that we could ask the autopilot to adjust the throttle during flight.
Debugging the C code for the Stanford Arduplane took a very long time. Most of the time
developing the control law was spent on debugging the C code. The estimated total number
of flight test hours to develop and validate the control law was 100 hours. During this
process, we experienced multiple crash. We once crashed into the tree due to lost in radio
contact to the airplane. We crashed into Lake Lagunita multiple times. However, the worst
is even we crashed our own airplane and lost GPS and broke the airspeed sensor.
31
For waypoint navigation, we command heading and to mark that the airplane reached the
waypoint, we created a circle around the waypoint. As long as the airplane went around
the circle surrounding the waypoint, the autopilot will tell the airplane to go to the next
waypoint. Once we got the airplane to follow the waypoints that form a spiral path, we
created simple dynamic waypoints that tell the airplane to visit all three beacons so we can
increase the accuracy of our estimation.
5.5
Attempt to Implement Line Tracking (written by DongHyun)
We observed that the waypoint tracking was not working very well when there was moderate
wind, and our airplane was side-slipping. Thus, we tried to implement line tracking to resist
side-slip and stay on the line connecting the two waypoints. Using current position read
from GPS, we computed side-slip distnace and adjusted our next waypoint and heading as
shown in the figure 20
Figure 20: Line tracking algorithm
5.6
Lessons Learned
We learned a lot about the design and implementation of the control law. Working through
different sets of aircraft dynamics allowed us to choose the specific states that we want to
control. The time spent to setup the modern control was quite a long time, but once the
setup was done properly, we could easily implement any changes to the control law. We also
found that dimensional analysis was very important in creating the weighting matrices to
have robust autopilot. Besides all the hard part of making the autopilot worked, we found
that it was really easy to transition between Bixler 2 and our own airplane. We only needed
to change the stability derivatives, and did not change any gains. Using autopilot, we could
32
also fly the airplane during high wind, and the airplane would fly well, even better than
when we manually fly the airplane. With Bixler 2, we could also use our autopilot for take
off.
6
Experimental result and observation from all autonomous flights in the competition (Robert)
Figure 21 shows the experimental result from the autonomous flight with Bixler 2 on Monday,
June 10, 2013. Figure 22 shows the commands for aileron, elevator, rudder, and throttle
throughout the autonomous flight of Bixler 2. Figures 23 and 24 show similar plot for our
own airplane.
33
(a) Mission path, red = beacon, black = waypoints, green = auto, blue = manual
(b) Altitude vs. time
(c) Pitch, rool, yaw vs. time
(d) Pitch, rool, yaw rates vs. time
(e) Speed vs. time
(f) Climb rate vs. time
Figure 21: Experimental result from a full mission with Bixler 2
34
Figure 22: Aileron, elevator, rudder, and throttle commands vs. time for Bixler 2
35
(a) Mission path, red = beacon, black = waypoints, green = auto, blue = manual
(b) Altitude vs. time
(c) Pitch, rool, yaw vs. time
(d) Pitch, rool, yaw rates vs. time
(e) Speed vs. time
(f) Climb rate vs. time
Figure 23: Experimental result from a mission with our own airplane
36
Figure 24: Aileron, elevator, rudder, and throttle commands vs. time for our own airplane
37
Throughout our test flights performed with the Bixler, our control law performed flawlessly.
It operated with very little jitter, and tracked the commanded inputs with high precision.
The control law was able to successfully stabilize the plane even under wind conditions of
10 m/s far from linearization point. Due to our choice of LQR weightings, the plane did not
track the commanded airspeed, or commanded beta very well. However, this was a design
choice as the measurements for each of these readings was quite noisy, due to the estimation
algorithms employed in order to give us these measurements.
Just by changing the stability derivatives, we were able to get a similar level of performance
using the control law with our home built plane. This proved our control law was robust
enough to be implemented on a variety of small UAV’s. While it is likely we could have
gotten more accurate tracking by tweaking the LQR weightings even more, our priority was
on the path planning architecture.
For our final flight, our plane did not fly as well as we would have hopped. It exhibited a
control mode similar to a dutch roll. We had not seen this in our previous flight tests, and
most likely arose due to the fact that the servo moving our rudder had broken since then.
This meant that the control law which was trying to damp this mode using control inputs to
the rudder, was unable to do so. After a full spiral was complete, we were lucky that some
external disturbance, likely the wind, damped the mode for us.
The biggest problem which our final control law had was in path planning. We were tracking
to waypoints by controlling heading, however, due to the side-slip the plane was experiencing
in the wind, we would frequently miss the waypoint, and have to circle around until we were
flying with a headwind or tailwind to compensate for this fact. In order to remove this extra
circulation, the size of each waypoint was increased to a 20 meter radius so that even with
the side-slip, the plane would hit each waypoint.
This in turn, led to us not being able to cover every part of the field since our initial set of
waypoints assumed we could hit them quite accurately. In order to fix this we were in the
process of implementing a line tracking algorithm, which would help keep us on the intended
path, however, we were unable to test the algorithm which we implemented in time.
7
Experimental and Simulated Score (Devina)
Due to high wind on Monday, we were only able to fly one complete mission with Bixler 2,
and part of a mission with our own airplane. We obtained a score of 55.8 for the mission
that we completed with Bixler 2. In this section, we will compare our experimental score
to the simulated score using MATLAB-based simulation for mission path and calculate our
simulated score for the mission that we did not complete.
38
7.1
Complete Mission with Bixler 2
The true location of the beacon was shown in table 7.
Beacon
1
2
3
x
5.0447
85.7678
23.3357
y
-5.8698
46.9062
-33.4352
Table 7: True beacon location for a complete mission with Bixler 2
Setting the true beacon location on our MATLAB-based simulation for mission path to be
the same as specified in table 7, we obtained our simulated time of sight, estimation error,
and total score (see table 8). Here, we can see that our simulated score is about 3% lower
than our experimental score. This tells us that our simulation gives us reasonable result even
without incorporating an accurate dynamics and aerodynamics model. Also, note that we
did not use exactly the same path planning algorithm for the mission as the one we have for
the simulation, and the simulation was built for our airplane, not Bixler 2. Thus, the higher
experimental score might be due to the fact that we obtained lower time of sight since Bixler
2 fly faster than our airplane.
Time of Sight
(seconds)
95.9
Error Beacon 1
(m)
2.3452
Error Beacon 2
(m)
1.2741
Error Beacon 3 Score
(m)
1.2041
54.1884
Table 8: Simulation result for a complete mission with Bixer 2
39
The simulated path is shown in figure 25. From this figure, we can see that according to
our mission path algorithm, we only need to visit two beacons to improve our estimation.
However, in the mission, we set the waypoints such that Bixler 2 will visit all three beacons
once it see all three beacons during the static path.
150
100
y (m)
50
0
−50
−100
−150
−200
−150
−100
−50
0
x (m)
50
100
150
200
Figure 25: Simulated path for a complete mission with Bixler 2
7.2
Attempt to Complete a Mission with our own Airplane
The true location of the beacon was shown in table 9.
Beacon
1
2
3
x
12.2292
-125.7200
-76.6759
y
-4.9984
-100.2242
Student Version of MATLAB
138.1325
Table 9: True beacon location for a mission with our own airplane
Setting the true beacon location on our MATLAB-based simulation for mission path to be
the same as specified in table 9, we obtained our simulated time of sight, estimation error,
and total score (see table 10). Since we didn’t complete the mission, we could not compare
the simulated score with the experimental score. However, this simulation gives us an idea
about what score we would get if we completed the mission.
40
Time of Sight
(seconds)
95.9
Error Beacon 1
(m)
2.1973
Error Beacon 2
(m)
0.8929
Error Beacon 3 Score
(m)
2.1712
54.1884
Table 10: Simulation result for a mission with our airplane
The simulated path is shown in figure 26. From this figure, we can see that according to our
mission path algorithm, we only need to visit two beacons to improve our estimation.
150
100
y (m)
50
0
−50
−100
−150
−200
−150
−100
−50
0
x (m)
50
100
150
200
Figure 26: Simulated path for a mission with our airplane
8
Website and archived files (Devina, Hakki, Harrison,
Manu, and Robert)
Our website is infinity-eye.com, and the website is maintained and updated by Devina.
The archive of our files is available on our website.
Student Version of MATLAB
41
Appendix: Results from MATLAB Simulation of Mission Plan (Devina)
Table 11 shows our test data from our simulation. From the data, we can see that using
our path planning algorithm, we have our tsight ranging from 25 to 105 seconds, and in
average, we use 17.02% (excluding pre-flight checks, take off, landing, and battery to power
electronics), and our flight time is 9.48 minutes. Recall that we set our percent energy used
for the flights to be 40% to offset the energy consumption for other aspects that we did not
take into account in the simulation, and from experimental data, our endurance is about 7
minutes.
42
Case
Score (static)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
53.2963
56.8586
42.6760
43.6042
32.0229
42.0974
50.9002
41.4574
41.3438
47.0766
55.7015
42.7449
36.7707
43.2578
88.4082
38.1825
41.0687
38.9115
31.8574
36.8543
43.6566
39.6961
46.5748
61.4303
50.6970
47.4766
34.0440
64.2498
41.3274
40.3363
Score (static
and dynamic)
72.6261
75.0870
54.1884
58.0552
45.9433
52.9604
54.1884
55.5803
49.2956
55.5803
75.0870
60.7444
52.3991
49.8344
107.6828
53.5558
57.1712
54.5998
44.3784
52.8044
51.4089
54.5299
59.9481
79.9489
61.3417
58.5231
51.1095
81.0660
44.7433
56.6375
tsight
% Econsumed
(minutes)
0.85
14.18
0.80
17.08
1.60
13.82
1.35
15.00
1.60
17.95
1.70
17.80
1.60
15.25
1.25
17.82
1.40
18.16
1.45
17.64
0.80
17.32
1.20
17.21
1.75
17.32
1.35
18.22
0.43
15.63
1.65
17.91
1.40
17.30
1.50
17.31
1.75
17.31
1.45
18.21
1.05
17.94
1.50
13.47
1.25
17.68
0.70
17.29
0.95
17.78
1.15
17.31
1.75
17.36
0.70
17.28
1.15
18.01
1.20
17.96
Table 11: Data from path planning simulation
43
tf light
(minutes)
4.36
5.94
4.16
4.81
6.41
6.33
4.94
6.34
6.53
6.24
6.07
6.01
6.07
6.56
5.15
6.39
6.06
6.06
6.07
6.56
6.41
3.97
6.27
6.05
6.32
6.06
6.09
6.05
6.45
6.42