Search and Rescue UAV Design Report

Design and Build a Search and Rescue
UAV
Mark Eldridge
James Harvey
Todd Sandercock
Ashleigh Smith
Supervisor:
Maziar Arjomandi
The University of Adelaide
School of Mechanical Engineering
October 30, 2009
This Page Intentionally Left Blank
Executive Summary
This report outlines the design and manufacture of an Unmanned Aerial Vehicle (UAV)
intended for civil and commercial surveillance applications. Particular emphasis is
placed on the search and rescue capabilities of the aircraft, for potential entrance
into the 2009 ARCAA Outback Challenge. The Outback Challenge requires that the
aircraft be capable of autonomously searching a remote area for a missing bushwalker,
and then dropping emergency supplies.
In 2007, the iSOAR UAV was developed at the University of Adelaide for a similar
purpose. The knowledge and components accumulated throughout the development of
the iSOAR aircraft provided an extensive resource for the 2009 project. The fuselage,
propulsion system, modems and video downlink were retained from the 2007 project,
allowing the 2009 project team to focus on additional systems such as the integration of the aircraft autopilot, an emergency recovery system and image processing for
autonomous detection of ground targets.
The 2007 iSOAR aircraft demonstrated high takeo and landing speeds, resulting in a
number of crashes. In order to solve this problem, a new pair of wings were designed
and manufactured with an increased wing area, aspect ratio, and the addition of aps.
The new wings dramatically reduced takeo and landing speeds while maintaining good
cruise performance.
The aircraft autopilot was not successfully implemented in the 2007 iSOAR UAV, as
it resulted in a loss of remote control (RC) communication. This issue was solved in
2009, with fully autonomous ight demonstrated in a test aircraft.
The use of a parachute for emergency recovery was deemed infeasible as it would compose too high a proportion of the overall aircraft weight. It was therefore decided that
in the event of component or communications failure, the aircraft would be deliberately
crashed in order to prevent the aircraft drifting into populated areas.
The imaging system was redesigned for autonomous detection of the ARCAA Outback
Challenge target, and consisted of an infrared camera and image processing software.
iii
The completed system was demonstrated to be capable of automatically detecting and

tracking a 3W infrared light source from an altitude of 50m.
Future work for the project includes the integration of an improved camera with the
ability to encompass both visual and infrared imagery, a modied video communications link to reduce interference with the autopilot modem, construction of a new
landing gear to allow for a modular payload system, and re-manufacture of the aircraft fuselage in order to reduce weight through more ecient layup techniques. The
project team intends to nish these tasks and complete full system integration in order
to successfully compete in the 2010 ARCAA Outback Challenge.
iv
Acknowledgements
The authors would like to acknowledge the contributions made by many people throughout the course of this project.
Firstly, the group would like to thank our project supervisor, Dr. Maziar Arjomandi.
Dr Arjomandis guidence, experience and engineering knowledge have been invaluable
to the group throughout the year. The group greatly appreciates the time and eort
Dr Arjomandi has spent in ensuring the success of the project.
The project received nancial support from Codan, which was greatly appreciated.
Without this support, the goals of the project may not have been realised. The group
would like to thank Codan for their support of engineering education in Australia.
The group would also like to acknowledge the nancial support received from The
Sir Ross and Sir Keith Smith Fund, which has contributed greatly to the aerospace
industry within South Australia. Without the assistance of The Sir Ross and Sir Keith
Smith Fund, many aspects of this project would not have been possible.
The assistance of the sta at the School of Mechanical Engineering Workshop is greatly
appreciated. In particular, the assistance provided by Philip Schmidt and Bill Finch
was invaluable, and the group would like to acknowledge their work.
Finally, the authors would like to thank their friends and families for supporting them
throughout the year.
Smith Fund Acknowledgment and Disclaimer

Research undertaken for this report has been assisted with a grant from the Smith
Fund (www.smithfund.org.au). The Smith Fund by providing funding for this project
does not verify the accuracy of any ndings or any representation contained in it. The
Smith Fund does not accept any responsibility or liability from any person, company
or entity that may have relied on any written report or representations contained in
this report if that person, company or entity suers any loss (nancial or otherwise)
as a result.
v
Disclaimer
The authors listed below hereby declare that the contents of this report are their own
original work unless otherwise specied.
Mark Eldridge
1120791
................................................................
James Harvey
1147525
................................................................
Todd Sandercock
1132146
................................................................
Ashleigh Smith
1147261
................................................................
vii
Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xx
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvi
1 Introduction
1.1
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Scope
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Signicance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6
ARCAA UAV Outback Challenge . . . . . . . . . . . . . . . . . . . . .
2 Feasibility Study
2.1
Mission Requirements
5
. . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1
Mission Parameters . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2
Search Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3
Optimisation of search pattern . . . . . . . . . . . . . . . . . . .
2.2
UAV Market Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3
Control and Communication Systems . . . . . . . . . . . . . . . . . . .
13
ix
2.4
Imaging Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5
Recovery Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.6
Technical Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.6.1
Technical Level . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.6.2
Economic Parameters
. . . . . . . . . . . . . . . . . . . . . . .
19
2.6.3
Standard Requirements
. . . . . . . . . . . . . . . . . . . . . .
19
2.6.4
Performance Requirements
. . . . . . . . . . . . . . . . . . . .
20
2.6.5
System Requirements . . . . . . . . . . . . . . . . . . . . . . . .
21
3 Conceptual Design
3.1
23
Aircraft Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.1
Conguration Review . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.2
Propeller Placement . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.3
Conguration Selection . . . . . . . . . . . . . . . . . . . . . . .
25
3.2
Aircraft Design Parameters
. . . . . . . . . . . . . . . . . . . . . . . .
25
3.3
Aircraft Preliminary Sizing . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3.1
Stall Requirements . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3.2
Takeo Distance Requirements . . . . . . . . . . . . . . . . . .
27
3.3.3
Climb Requirements . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3.4
Cruise Requirements . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3.5
Matching Diagram Results . . . . . . . . . . . . . . . . . . . . .
28
3.3.6
Weight Estimation . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.3.7
Final Design Point . . . . . . . . . . . . . . . . . . . . . . . . .
30
Propulsion System . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.4.1
Motor Type Selection . . . . . . . . . . . . . . . . . . . . . . . .
30
3.4.2
Electric Motor Selection . . . . . . . . . . . . . . . . . . . . . .
32
3.4.3
Propeller Selection . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4.4
Electronic Speed Controller (ESC) Selection . . . . . . . . . . .
32
3.4.5
Motor Batteries
33
3.4
. . . . . . . . . . . . . . . . . . . . . . . . . .
x
3.5
Manufacturing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.5.1
Wing Manufacture Methods . . . . . . . . . . . . . . . . . . . .
34
3.5.2
Selection
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Control and Communication Systems . . . . . . . . . . . . . . . . . . .
36
3.6.1
Mission Requirements . . . . . . . . . . . . . . . . . . . . . . .
36
3.6.2
Manual Control . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.6.3
Autonomous control . . . . . . . . . . . . . . . . . . . . . . . .
40
Imaging System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.7.1
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.7.2
Problem Description . . . . . . . . . . . . . . . . . . . . . . . .
43
3.7.3
Camera Selection . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.7.4
Downlink Selection . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.7.5
Image Processing System . . . . . . . . . . . . . . . . . . . . . .
46
3.7.6
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
Recovery System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.8.1
Comparison of Recovery Methods . . . . . . . . . . . . . . . . .
48
3.8.2
Comparison of Parachute Types . . . . . . . . . . . . . . . . . .
49
3.8.3
Parachute Sizing . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.8.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Payload Release Mechanism . . . . . . . . . . . . . . . . . . . . . . . .
55
3.9.1
Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.9.2
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
3.10 Final Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
3.6
3.7
3.8
3.9
4 Detailed Design
4.1
59
59
4.1.1
4.2
Airfoil Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selection Considerations . . . . . . . . . . . . . . . . . . . . . .
59
Tailplane Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.2.1
61
Tailplane sizing . . . . . . . . . . . . . . . . . . . . . . . . . . .
xi
4.2.2
Rudder and Elevator Sizing . . . . . . . . . . . . . . . . . . . .
61
Wing Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.3.1
Design Factors . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.3.2
Aerodynamic Design . . . . . . . . . . . . . . . . . . . . . . . .
62
4.3.3
Control Surface Sizing . . . . . . . . . . . . . . . . . . . . . . .
63
4.3.4
Mechanical Design . . . . . . . . . . . . . . . . . . . . . . . . .
64
Autopilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.4.1
Micropilot 2028g issues . . . . . . . . . . . . . . . . . . . . . . .
68
4.4.2
Paparazzi Hardware . . . . . . . . . . . . . . . . . . . . . . . .
69
4.4.3
Paparazzi Software . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.4.4
Sensor Calibration . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.4.5
Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.4.6
Flight Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
Communication Systems Design . . . . . . . . . . . . . . . . . . . . . .
79
4.5.1
Review of 2007 design . . . . . . . . . . . . . . . . . . . . . . .
79
4.5.2
Investigation of possible causes . . . . . . . . . . . . . . . . . .
81
4.5.3
Preliminary Testing . . . . . . . . . . . . . . . . . . . . . . . . .
83
4.5.4
Solution generation . . . . . . . . . . . . . . . . . . . . . . . . .
84
4.5.5
Video Downlink . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.5.6
Summary of Design . . . . . . . . . . . . . . . . . . . . . . . . .
85
Imaging System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.6.1
Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.6.2
Image Processing . . . . . . . . . . . . . . . . . . . . . . . . . .
87
4.6.3
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
Ground Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
4.7.1
Aircraft Remote Control Transmitter . . . . . . . . . . . . . . .
89
4.7.2
Paparazzi Ground Control Station . . . . . . . . . . . . . . . . .
90
4.7.3
Imaging System . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.7.4
Personnel Requirements . . . . . . . . . . . . . . . . . . . . . .
90
4.8
91
4.9
Final Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
4.3
4.4
4.5
4.6
4.7
xii
5 Manufacturing
5.1
93
Wing Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
5.1.1
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
5.1.2
Manufacturing Issues . . . . . . . . . . . . . . . . . . . . . . . .
96
Fuselage Modication . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.2.1
Wing Attachment . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.2.2
Battery Location . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.3
98
5.4
Electronic System Installation . . . . . . . . . . . . . . . . . . . . . . .
98
5.5
Quality Assurance
99
5.6
Completed Airframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Testing
6.1
101
Component Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

6.1.1
6.1.2
Static Propulsion Test . . . . . . . . . . . . . . . . . . . . . . . 103
6.1.3
Communication Range Test . . . . . . . . . . . . . . . . . . . . 104
6.1.4
Imaging System Test . . . . . . . . . . . . . . . . . . . . . . . . 105
6.1.5
6.2
Wing Structural Test . . . . . . . . . . . . . . . . . . . . . . . . 101
Payload Release Mechanism . . . . . . . . . . . . . . . . . . . . 107
Flight Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.2.1
Airframe Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.2.2
Autopilot Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.2.3
Imaging System Test . . . . . . . . . . . . . . . . . . . . . . . . 112
6.2.4
Payload Deployment Test . . . . . . . . . . . . . . . . . . . . . 114
7 Management and Finances
115
7.1
Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.2
Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.2.1
Management Delegation . . . . . . . . . . . . . . . . . . . . . . 115
7.2.2
Communication
. . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.3
Financial Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.4
Time Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

xiii
8 Conclusion
119
8.1
Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.2
Future Work and Recommendations . . . . . . . . . . . . . . . . . . . . 122
Bibliography
125
A Airfoil Comparison
B Matching Diagram Verication
B.1 Take O Distance Verication . . . . . . . . . . . . . . . . . . . . . . .
B.1.1 Verication point 1 . . . . . . . . . . . . . . . . . . . . . . . . .
B.1.2 Verication point 2 . . . . . . . . . . . . . . . . . . . . . . . . .
vi
B.2 Climb Performance Verication . . . . . . . . . . . . . . . . . . . . . .
vii
B.3 Cruise Performance Verication . . . . . . . . . . . . . . . . . . . . . . viii

C Tailplane Sizing Calculations
ix
D Spar Stress Calculations
xi
E Test Procedures
xiii
E.1 Test aircraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

E.2 Component Testing
. . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
E.2.1 Static Wing Loading . . . . . . . . . . . . . . . . . . . . . . . . xiv

E.2.2 Motor Verication . . . . . . . . . . . . . . . . . . . . . . . . .
xv
E.2.3 Preliminary communication eld tests . . . . . . . . . . . . . . . xvi

E.2.4 Communication Long Range Verication . . . . . . . . . . . . . xix
E.3 Flight testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.3.1 Proof of aerodynamic and mechanical design
E.3.2 Flight performance verication
. . . . . . . . . .
xx
xx
. . . . . . . . . . . . . . . . . . xxii
E.3.3 Autopilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

E.3.4 Imaging System
. . . . . . . . . . . . . . . . . . . . . . . . . . xxiv
E.3.5 Payload Deployment . . . . . . . . . . . . . . . . . . . . . . . . xxv

xiv
F Project Scheduling
xxvii
G Bill of Materials
xxix
H Paparazzi Code
xxxiii
H.1 Airframe File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii

H.2 Flightplan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I
Image Processing Code
xl
xlvii
I.1
Initial Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xlvii
I.2
Blob Quality Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . xlix
I.3
Ivy Bus Communication . . . . . . . . . . . . . . . . . . . . . . . . . .
J Micropilot 2028g Development
l
liii
J.1 Solution to Micropilot issues . . . . . . . . . . . . . . . . . . . . . . . .
liii
J.2 Micropilot Conguration . . . . . . . . . . . . . . . . . . . . . . . . . .
liii
J.3 Micropilot Flight Plans . . . . . . . . . . . . . . . . . . . . . . . . . . .
lv
K Meeting Minutes
lix
K.1 Tuesday 3.2.09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lix
K.2 Tuesday 10.2.09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxii

K.3 Thursday 19.02.09
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxiv
K.4 Monday 02.03.09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxviii

K.5 Monday 16.03.09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxxi
K.6 Monday 23.03.09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxxiv
K.7 Monday 30.03.09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxxvii
K.8 Monday 06/04/09
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxxix
K.9 Monday 20/04/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxxxi

K.10 Monday 27/04/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxxxii
K.11 Monday 04/05/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxxxv
K.12 Monday 11/04/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxxxvii
xv
K.13 Monday 25/05/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lxxxix

K.14 Monday 01/06/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xc
K.15 Monday 15/06/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xci
K.16 Monday 13/07/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xciii

K.17 Monday 20/07/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xcv
K.18 Monday 03/08/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xcviii
K.19 Monday 03/08/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ci
K.20 Monday 10/08/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ciii
K.21 Monday 17/08/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
civ
K.22 Monday 24/08/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cv
K.23 Monday 31/08/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cvi
K.24 Monday 07/09/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cvii

K.25 Monday 07/09/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cviii
K.26 Monday 28/09/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cix
K.27 Monday 12/10/09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cx
L CAD Drawings
cxiii
xvi
List of Figures
2.1
Search and Rescue Area . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Search patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Creeping line search pattern . . . . . . . . . . . . . . . . . . . . . . . .
2.4
The iSOAR UAV (Avalakki et al. 2007) . . . . . . . . . . . . . . . . . .
11
2.5
Aerosonde (Corporation 2009)
. . . . . . . . . . . . . . . . . . . . . .
11
2.6
The Insitu/Boeing ScanEagle UAV (CNet 2007). . . . . . . . . . . . . .
12
2.7
Silver Fox (Sadaghiani 2007) . . . . . . . . . . . . . . . . . . . . . . .
12
2.8
CryoWing (Norut 2008) . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.9
The Boeing/Insitu ScanEagle UAV, showing the imaging compartment

(CNet 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.10 The IAI I-View MK50 UAV, with para-foil recovery system deployed
(IAI 2002) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.11 The SkyHook capture system used for the Boeing ScanEagle (Insitu
2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.1
Matching Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.2
Built up wing construction (Johnson 2007) . . . . . . . . . . . . . . . .
34
3.3
Composite covered foam core construction (Decker 2002) . . . . . . . .
35
3.4
DX7 Spektrum RC system including dual receivers and servos (Model

ModelFlight 2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.5
Micropilot 2028g (MicroPilot 2009) . . . . . . . . . . . . . . . . . . . .
42
3.6
Steady-state descent rate versus nominal parachute diameter . . . . . .
52
3.7
Final concept 3-View of the aircraft . . . . . . . . . . . . . . . . . . . .
57
3.8
A side ew of the nal concept aircraft, showing all major subsystems.
57
xvii
4.1
The performance of the SD7032 airfoil at various Reynolds numbers . .
60
4.2
V-N Diagram including gust loading
. . . . . . . . . . . . . . . . . . .
63
4.3
Local Lift Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.5
Wing tongue joiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.4
Bending Moment Distribution . . . . . . . . . . . . . . . . . . . . . . .
66
4.6
Spar design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.7
TWOG v1.00 architecture (Paparazzi 2009) . . . . . . . . . . . . . . .
70
4.8
Two IR sensors used to measure aircraft roll (Paparazzi 2009) . . . . .
71
4.9
Autopilot conguration . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.10 Arrangement of autopilot components within the UAV . . . . . . . . .
72
4.11 Paparazzi Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.12 Paparazzi GCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.13 Search Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.14 Figure 8 loiter pattern . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.15 Payload drop routine . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.16 Return to home pattern . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.17 2007 Communication systems conguration . . . . . . . . . . . . . . . .
80
4.18 Communication systems conguration . . . . . . . . . . . . . . . . . . .
86
4.19 Layout of communication systems within UAV . . . . . . . . . . . . . .
86
4.20 The Image Processing software
. . . . . . . . . . . . . . . . . . . . . .
87
4.21 The payload release mechanism design . . . . . . . . . . . . . . . . . .
91
4.22 Final aircraft design, showing all major systems . . . . . . . . . . . . .
92
5.1
Core Cutting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.2
Wingbox Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.3
Spar Cap Layup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.4
Fibreglass Layup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.5
Completed wing with control surfaces removed . . . . . . . . . . . . . .
96
5.6
Wing attachment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
xviii
5.7
Battery installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
5.8
Removable payload release mechanism . . . . . . . . . . . . . . . . . .
99
5.9
Installed Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
5.10 Completed airframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.1
Wing Load Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2
Motor Test Stand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.3
Thrust vs Battery Power . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.4
Autopilot signal strength . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.5
Initial Testing of the Image Processing Software . . . . . . . . . . . . . 106
6.6
Takeo performance for various ap congurations
6.7
Increasing proportional gain on navigation loop . . . . . . . . . . . . . 111
6.8
Figure 8 path performed autonomously . . . . . . . . . . . . . . . . . . 112
6.9
System testing of the Image Processing software, showing detection of a

3W infrared lamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.1
Management Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.2
Number of work hours per month . . . . . . . . . . . . . . . . . . . . . 118
. . . . . . . . . . . 108
A.1 Polar plot comparison of airfoils for Re = 100,000 . . . . . . . . . . . .
ii
ii
iii
iii
iv
iv
D.1 Spar Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xii
E.1 Test Aircraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

E.2 RC range test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
E.3 UAV supported by stand . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
E.4 Accomodation Hill . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xix
xx
F.1 Gantt Chart of Internal and External Deadlines . . . . . . . . . . . . . xxvii

F.2 Gantt Chart of Project Tasks . . . . . . . . . . . . . . . . . . . . . . . xxviii
xx
List of Tables
2.1
Parameters of mission strategy . . . . . . . . . . . . . . . . . . . . . . .
10
3.1
Airframe Conguration Decision Matrix . . . . . . . . . . . . . . . . .
24
3.2
Wing Dihedral
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3
Decision matrix for propulsion system selection . . . . . . . . . . . . .
31
3.4
Current Available Brushless Motors . . . . . . . . . . . . . . . . . . . .
32
3.6
Li-Po and Ni-MH Battery Comparison . . . . . . . . . . . . . . . . . .
33
3.8
AXI 4130-20 specications . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.9
Decision matrix for wing manufacture selection
36
. . . . . . . . . . . . .
3.10 Comparison of 2028g with other autopilot systems
. . . . . . . . . . .
41
3.11 Decision matrix for payload release system selection . . . . . . . . . . .
56
3.12 Design Specications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.1
The airfoils analysed for use on the redesigned wing . . . . . . . . . . .
60
4.2
Tailplane sizing requirements
. . . . . . . . . . . . . . . . . . . . . . .
61
4.3
2024-T3 Aluminium Material Properies (Typical) . . . . . . . . . . . .
66
4.4
Pultruded carbon-reinforced epoxy strip (Chen & Lui 2005) . . . . . .
66
4.5
Final Camera Specications . . . . . . . . . . . . . . . . . . . . . . . .
86
6.1
Aircraft Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.2
Flight path error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.1
Breakdown of Finances . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2
Major Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

xxi
Nomenclature
2( W )
S
gcCl
Ground roll friction
Air density
ARCAA Australian Research Centre for Aerospace Automation

CASA Civil Aviation Safety Authority
CASRs Civil Aviation Safety Regulations
CCD Charge-Coupled Device
CCTV Closed-Circuit Television
Cdp
Coecient of Drag of the parachute
CH
Chord length of horizontal stabiliser
cHT
Horizontal tail volume coecient
CLmax Maximum lift coecient

CLT O Take o conguration coecient of lift
CNC Computer Numerical Control
CPU Central Processing Unit
Cv
Chord length of vertical stabiliser
cV T
Vertical tail volume coecient
CW
Average wing chord length
Cx
Parachute opening force coecient at innite mass conditions

xxiii
Drag
Do
Distance between opposite sides of a polygonal parachute, assuming the number

of sides is even
Dp
Drag generated by the parachute in steady-state descent
DSM2 Second generation spread spectrum modulation

DSSS Direct-Sequence Spread Spectrum
FHSS Frequency Hopping Spread Spectrum
Fo
Parachute opening force
Acceleration due to gravity at sea level
GCS Ground Control Station

GPS Global Positioning System
GUI
Graphical User Interface
HFOV Horizontal Field of View

IC
Internal Combustion
iSOAR intelligent Surveillance for Outback Aerial Rescue

JVM Java Virtual Machine
K
1
Ae
0.88
5.3+
KA
2( W )
S
KT
T
W
2
(CD0 KCLT O + CLT O )
LED Light Emitting Diode

LHT
Horizontal tail moment arm
LiPo Lithium-Polymer
Ls
Length of each side of a polygonal parachute
LV T
Vertical tail moment arm

xxiv
ma
Mass of the iSOAR aircraft
Change in load factor due to gust load
Number of sides in a at polygonal parachute
Ni-MH Nickel Metal Hydride

OSS
Open-Source Software
PFD Primary Flight Display

PID
Proportional Integral Derivative
PN
Pseudonoise
PWM Pulse Width Modulation

q
Dynamic viscosity ( 1 V 2 )
2
Reeng fraction of parachute
RC
Remote Control
RF
Radio Frequency
RSO Range Safety Ocer

Sg
Take o ground roll
SHT
Horizontal tailplane area
SOP Safe Operating Procedure

Sp
Parachute surface area
SRTM Shuttle Radar Topography Mission

SV T
Vertical tailplane area
SW
Wing planform area
Thrust
TWOG Tiny Without GPS

U
= kUde
xxv
UAV Unmanned Aerial Vehicle

Vclimb Climb Velocity
Vd
Steady-state descent rate of the aircraft
Vi
Speed of the aircraft at the point of parachute deployment
Vstall Stall velocity

Wa
Weight of the aircraft
W/P
Power Loading
W/S
Wing Loading
Xi
Parachute opening force reduction factor
xxvi
Chapter 1
Introduction
1.1
Background
Unmanned Aerial Vehicles (UAVs) are a rapidly advancing area of technology, with
military UAVs having been in use for many years. Unmanned aircraft also have great
potential for civilian and commercial applications, particularly in situations where a
manned aircraft would not be cost eective or where human life may be endangered.
Though not as widely publicised as military related UAVs, signicant developments
have been made in the civil domain.
The civil and commercial potential of these systems has resulted in a large amount
of research and development towards eective, aordable unmanned aircraft for civil
use. The Aerosonde is one such example - a UAV developed in Australia by Aerosonde
Pty Ltd and used by the Bureau of Meteorology and Sencon Environmental Systems.
The Aerosonde aircraft is used for meteorological and environmental surveillance over
oceanic, remote, and hazardous areas. In addition, many universities across Australia
(including the University of Adelaide) have had signicant involvement in the research
and development of unmanned aircraft.
In 2007 a team of 8 students from the University of Adelaide School of Mechanical
Engineering designed and manufactured a UAV named iSOAR, for intelligent Surveillance for Outback Aerial Rescue. The iSOAR aircraft was specically designed for
civilian applications, such as re detection and monitoring, shark spotting, and trac
surveillance. It was also intended to enter the aircraft in the 2007 ARCAA Outback
UAV Challenge (described in greater detail in Section 1.6) , a competition focused on
the use of unmanned aircraft for search and rescue.
1
CHAPTER 1. INTRODUCTION
1.2
Aim
The aim of the 2009 project was to design, manufacture and test a xed-wing UAV
capable of performing a variety of civil or commercial tasks which might normally rely
on manned aircraft. Using the experience obtained from the 2007 project, the 2009
team aims to improve on the design of the iSOAR aircraft with regard to aerodynamic
and functional performance during all stages of ight, payload deployment, level of
autonomy, and through the successful implementation of emergency recovery and image
processing systems. In addition, the team intends to compete successfully in the 2009
ARCAA 2009 UAV Challenge - Outback Rescue.
1.3
Project Goals
A number of goals were specied at the commencement of the project. The goals
maintain the direction of the project as well as providing a measure of success at
its conclusion. The primary goals were essential for the successful completion of the
project, while the extended goals are to be completed if time and resources allow.
Primary Goals
Design and manufacture a new pair of wings with improved performance over the
2007 iSOAR aircraft.
Design and implement a reliable payload deployment device capable of delivering
a 500mL bottle of water to within 100 m of a specied target.
Implement an autopilot system capable of controlling the UAV outside of visible
range. The desired level of autonomy includes maintaining straight and level
ight, negotiating turns, and allowing changes in altitude.
Develop software capable of detecting and tracking an object (representing a
person) from the aircraft camera feed and communicating its location with the
aircraft. The aircraft should use this location to drop the payload previously
described.
Extension Goals
Meet the minimum requirements for participation in the ARCAA 2009 UAV
Challenge Outback Rescue.
1.4. SCOPE
Reduce the takeo weight of the UAV to 9 kg or less.

Develop a system capable of determining the GPS coordinates, within 100m
accuracy, of a specied target on the video footage streamed from the UAV.
Improve the quality of the video system, such that it is possible to identify a
human from cruise altitude.
Design and implement an emergency recovery system, with the primary goal of
ensuring safety to people on the ground and secondary goal of minimising damage
to the UAV.
1.4
Scope
As a general purpose surveillance UAV, the design has the capacity for a number
of dierent applications in the civil and commercial sphere. The Outback Challenge
provides a means of clearly dening the scope of the project while maintaining the
fundamental features of a UAV designed for civil and commercial tasks. Though the
competition rules dene much of the scope of the project, actually competing in the
competition was not essential to the success of the design.
Success in the Outback Challenge requires the design to be capable of a reasonable
degree of autonomy, in addition to possessing imaging systems capable of identifying
a human target from cruise altitude. Such abilities are also required for many civil
and commercial tasks where UAVs might be required to play a role, and so successfully meeting these requirements would make the aircraft useful for many applications
outside of the competition itself.
1.5
Signicance
The use of UAVs oers signicant benets in a variety of civil and commercial applications. The lack of a human pilot is a signicant advantage as it eliminates the risk
to a pilots life, signicantly increases endurance time, and allows a greater load factor
to be sustained. In addition, UAVs have relatively low manufacturing and operational
costs, and a high exibility for adjusting to a customers needs (Sarris 2001).
Some of the applications for which UAVs can be utilised include search and rescue, coast
watch, border patrol, bushre detection and monitoring, trac monitoring, mapping
Design and Build a Search and Rescue UAV
CHAPTER 1. INTRODUCTION
and surveying, surveillance, and media coverage. In each of these applications, replacing a manned aircraft with a UAV has the potential to signicantly reduce costs. For
the same expense as a single manned aircraft (generally including a pilot and copilot),
multiple UAV platforms could be used to achieve a greater level of coverage.
1.6
ARCAA UAV Outback Challenge
The UAV Outback Challenge is a joint initiative between the Australian Research
Centre for Aerospace Automation (ARCAA), the Queensland Government, and Boeing
Australia Limited. The competition is designed to promote the development of UAVs
for civil purposes in Australia, and is one of the largest competitions of its kind in the
world (ARCAA 2009).
The scoring system for the competition allocates points based on whether aircraft can
successfully complete competition tasks, as well as for safety and design. The 2009
competition incorporates three separate challenges:
An Airborne Delivery Challenge, which is restricted to secondary school students.
This challenge requires competitors to design, build and y a remotely controlled
aircraft a short distance and then release a payload.
A Robot Airborne Delivery Challenge, which is similar to the Airborne Delivery
Challenge, but requires the aircraft to be autonomous. This challenge is also
restricted to secondary school students.
A Search and Rescue Challenge, where competitors must design, build and deploy
a UAV to nd a lost bushwalker within a set search area. Once the bushwalker
has been found the UAV is required to deliver emergency supplies. This challenge
has no restriction on entrants.
The aim of the 2009 project is to design and build a UAV suitable for entrance in the
Search and Rescue Challenge.
Chapter 2
Feasibility Study
Although the vehicle was designed with the intention of being suitable for various civil
and commercial applications, the design was heavily inuenced by the requirements of
the 2009 ARCAA Outback Challenge. It was believed that the competition provided a
realistic scenario to which the UAV could be applied, and required capabilities which
would be applicable in a variety of other applications. A number of existing UAV
systems were investigated prior to beginning the design. This analysis was used to
ascertain the feasibility of the intended design and reveal existing technologies. The
results of the feasibility study were used to generate the technical task for the project.
2.1
Initially it was neccessary to determine the optimum search strategy for the mission.
This was used to dene the aircrafts required cruise speed, which in turn had a signicant impact on other performance and systems requirements. It was assumed that
designing the UAVs performance specically for search and rescue missions would not
prevent it from performing other surveillance missions, such as coastwatch, border patrol, shark spotting and bushre monitoring. The optimum strategy was dened as the
strategy which would maximise the probability of nding the subject, while minimising
the time taken to do so.
2.1.1
Mission Parameters
The primary objective of the Outback Challenge is to search a remote area for a
missing bushwalker and deliver an emergency package. This task must be performed
with minimal human input.
5
CHAPTER 2. FEASIBILITY STUDY
6
Mission Boundary Constraints
The Outback Challenge is held at Kingaroy airport in South East Queensland, Australia. Kingaroy airport is at an elevation of 1472 ft (450m) above sea level and has
a runway of length 5249 ft (1600m). The competition has a ight corridor, mission
boundary and search area predened in the rules of the competition. The ight corridor is approxiamately 0.2 nautical miles (0.3 km) by 1 nautical miles (1.8km), and
the vehicle must stay within this ight corridor on transition from the airport to the
mission area, and vice versa.
The mission boundary has an approximately rectangular geometry of dimensions 2 nm
(3.6km) by 3 nm (5.4km). The target is located in the search area which is dened as
being 0.5 nm within the mission boundary and hence has a rectangular geometry of
1 nm (1.8km) by 2 nm (3.6 km). The vehicle is also limited to ying at an altitude
between 200ft and 400ft (though permission can be attained from CASA to y to
1500ft), with the exception of take-o and landing. If at any time the vehicle exits
the mission boundary, the vehicles mission is terminated by the Range Safety Ocer
(RSO). Figure 2.1, illustrates the ight corridor, mission boundary and search area.
Figure 2.1: Search and Rescue Area

2.1. MISSION REQUIREMENTS
Rescue
The target of the search is Outback Joe, a human dummy wearing light khaki clothes
and an Akubra hat. There is a simulated heat signature for the dummy in the form
of a 12 volt Videotec IR50 infrared lamp, which emits light at a wavelength of 850nm.
The dummy will not be moving and will be positioned in a typical resting pose for a
tired and lost bushwalker as would be viewed from the air.
Once Outback Joe has been located, GPS coordinates of his detected position must be
provided to the judges. Once the judges deem the UAV to be within close proximity
to Outback Joe, the vehicle must deploy a minimum of 500 mL of uid safely to him.
The uid must be in an unopened vessel, suitable for human consumption, and it must
be possible to open the vessel so that the contents can be measured by the judges. The
package must be dropped within 100m of Outback Joe, without contacting him.
2.1.2
Search Pattern
Possible searh patterns considered most relevant to this mission included creeping line,
expanding square, and sector search patterns as shown in Figure 2.2 .
Figure 2.2: Search patterns

The expanding square and sector patterns are advantageous in missions where there
is some prior knowledge of the subjects whereabouts, as the search pattern can begin
and be centred around the area of highest probability. In this way the time taken
to nd the subject is minimised. For the Outback Challenge however, there was no
data provided to indicate where Outback Joe was more likely to be situated, eectively
removing the advantage of both patterns. Considering this, the sector search was no
longer feasible as it would cover the central area of the pattern multiple times, which
would be an inecient use of the allowed search time. Furthermore, it is generally
dicult to maintain navigational accuracy for the expanding square approach (Wollan
2004), paticularly within the central region of the pattern where there are many turns
within a small area. This is especially relevant for aircraft, which have a limited turn
radius and are aected by cross winds.
The creeping line approach is generally considered advantageous in large search areas
(Wollan 2004) where there is no prior knowledge of the subjects position. This is
because it covers the entire area with consistent detail and can be implemented with
reasonably high navigational accuracy due to the low path complexity. Therefore, the
use of a creeping line pattern was considered the most feasible option for this mission.
2.1.3
Optimisation of search pattern
The creeping line pattern was modied such that the path doubles back over the search
area. This was done such that the required turn radius of the UAV was increased and
therefore the UAV could perform the turns at a greater speed. Figure 2.3 shows the
aircraft part way through the creeping line search pattern.
Figure 2.3: Creeping line search pattern

Optimisation of the search pattern involved reducing the total search distance to a
minimum, while ensuring the entire area was covered. This was performed using a
spreadsheet.
The spreadsheets input parameters included:
2.1. MISSION REQUIREMENTS
Cruise altitude: Increasing the cruise altitude increases the sweep width (width
of ground seen in cameras HFOV) and therefore reduces the total search distance
and time taken to cover the entire area. However, increasing altitude also reduces
image detail. Therefore, a cruise altitude of 300 ft (midpoint of allowed range)
was selected as it was believed that it provided a balance between image detail
and sweep width.
Camera horizontal eld of view (HFOV): Coupled with cruise altitude,
HFOV determines the UAVs sweep width. At this stage the camera that would
eventually be used was not known. Therefore, a standard 3.6 mm, 1/3 CCTV
camera was assumed with a HFOV of 67.4.
Track width: Is the distance between the midpoint of each sweep as indicated
in gure 2.2. Therefore, increasing the track width decreases sweep overlap and
the total search distance. Some sweep overlap is required however to avoid gaps
in the search area.
Search time: The time allocated for the search phase of the mission was 50
minutes, which allowed 10 minutes for setup.
The spreadsheets output parameters included:
Total distance: The optimisation process required the total search distance to
be minimised.
Sweep width: For a cruise altitude of 300 ft (91.4 m) and a HFOV of 67.4,
the sweep width was 122 m.
Sweep overlap: It was believed that a sweep overlap of at least 5% (corresponding to 6m of overlap on either side of a sweep) was reasonable to account
for navigational inaccuracies.
Cruise speed: Was calculated from the total search distance and the search
time of 50 minutes.
While keeping the cruise altitude, camera HFOV and search time xed as above, the
track width was increased until the sweep overlap was reduced to approximately 5%.
The results of this optimisation are indicated in table 2.1.
It was therefore decided that the design cruise speed would be 25 m/s (90 km/h). It
should be noted that the above parameters were merely estimates to base the design
work on as futher optimisation would be made through testing.
10
Table 2.1: Parameters of mission strategy

Parameter
Cruise altitude
Camera HFOV
Track width
Search time
Total distance
Sweep width
Sweep overlap
Cruise speed
2.2
300 ft
67.4
115 m
50 mins
70643 m
122 m
5.71%
23.55 m/s
UAV Market Survey
Before commencing design work, it was necessary to benchmark a number of existing

UAV platforms with similar mission proles. This demonstrated the feasibility of
the intended design and the expected level of performance. The surveillance UAVs
analysed included the 2007 iSOAR aircraft, Aerosonde, ScanEagle, Silver Fox and
CryoWing.
2007 iSOAR Aircraft
The iSOAR UAV, depicted in gure 2.4, was designed and manufactured at the University of Adelaide for a variety of surveillance applications, including search and rescue.
iSOAR utilises a conventional conguration with a wing span of 1.9 m and a weight of
approximately 11 kg, and uses an AXI Gold Line electric motor for propulsion.
The iSOAR aircraft is capable of cruising at 25 m/s for over 1 hour and 15 minutes
and has a communication range of 10 km. As the autopilot was not successfully implemented, the maximum mission range was never realised. In addition, iSOAR required
a runway for take-o and landing.
Aerosonde
The UAV Aersonde, indicated in gure 2.5, was designed by an Australian company of
the same name, and has been successful around the world. Aerosonde is capable of performing a variety of missions including surveillance and meteorological investigations,
and has a relatively long endurance of up to 24 hours. It has a wingspan of 3.45 m, a
maximum gross take-o weight of 16.8 kg and a cruise speed of 26 m/s (Corporation
2009). Propulsion is obtained through the use of a 4-stroke, 24cc single cylinder engine.
2.2. UAV MARKET SURVEY
11
Figure 2.4: The iSOAR UAV (Avalakki et al. 2007)
Figure 2.5: Aerosonde (Corporation 2009)
ScanEagle
ScanEagle is a small UAV with a wing span of 3.1 m and a maximum take-o weight
of 18 kg, developed by Insitu and Boeing for military surveillance. The aircraft itself
does not incorporate landing gear, with launching being performed using a catapault,
and landings accomplished using the SkyHook retrieval system. SkyHook involves
using a cable to catch the aircraft via hooks mounted on the wingtips. ScanEagle has
an endurance of over 20 hours, a range of over 100 km, and a cruise speed of 25 m/s
(Insitu 2009). The aircraft is powered by a propellor in a pusher conguration, and a
1.9hp 2-stroke internal combustion engine.
12
Figure 2.6: The Insitu/Boeing ScanEagle UAV (CNet 2007).

Silver Fox
Silver Fox, indicated in gure 2.7, is a medium range reconnaissance, surveillance
and intelligence UAV, which has been used extensively by the Canadian Army and
American Army (Sadaghiani 2007). Silver Fox is launched via a bungee catapult,
which allows its use in a variety of terrains. The UAV has a conventional conguration
with a wing span of 2.1 m and a maximum take-o weight of 11.3 kg. It incorporates
a modular design, which can be suited for a number of dierent payloads, and has an
endurance of 10 hours, a range of 40 km and a cruise speed of 25 m/s (ONR 2004). A
2-stroke engine using a mixture of petrol and oil is used for propulsion.
Figure 2.7: Silver Fox (Sadaghiani 2007)

2.3. CONTROL AND COMMUNICATION SYSTEMS
13
CryoWing
The UAV CryoWing was developed by the Northern Research Institute of Norway and
has been used for a variety of environmental monitoring tasks in the Arctic, including
mapping and meteorological measurements. As depicted in gure 2.8, CryoWing has a
wing span of 3.8 m, a maximum take-o weight of 30 kg and incorporates a V-tail and
push propeller. In addition, its use in snow conditions requires a catapult launcher and
belly landing. CryoWing has an endurance of 5 hours, range of 500 km and a cruise
speed of 28 to 33 m/s (Norut 2008). The aircraft is powered by a 25cc or 35cc internal
combustion engine, running on standard automotive petrol.
Figure 2.8: CryoWing (Norut 2008)
Summary
The above UAVs demonstrated that the capabilites required of the 2009 UAV were
indeed feasible. This was particularly evident from their endurance and range, which
in general was far superior to that required for the ARCAA Outback Challenge. In
addition, all the above UAVs had a cruise speed of 25 to 33 m/s, which was similar to
that of the intended design.
2.3
Control and Communication Systems
There are a variety of commercially available autopilot systems designed for the model
ight industry and for research applications. Companies involved in the manufacture
of these systems include Micropilot, Cloudcap Technology, Procerus Technologies and
14
UAV Navigation. In addition to these, an open-source software (OSS) autopilot system

called Paparazzi is available, with the hardware either custom built or purchased from
a supplier.
The majority of these autopilot systems are capable of controlling a UAV from launch to
recovery whilst maintaining communication with a ground station a signicant distance
away. Some examples of the use of these autopilot systems are given below.
CryoWing
Micropilots 2028g autopilot is utilised in the CryoWing UAV, discussed in further
detail in Section 2.2. This aircraft can operate autonomously from launch to recovery,
and utilises a satellite link which allows a communication range of up to 500 km (Norut
2008). Flight plans are pre-programmed in the autopilot, and the UAV navigates via
GPS waypoints.
Silver Fox
A Piccolo autopilot system, developed by Cloudcap Technology, was used in the Silver
Fox UAV (discussed in Section 2.2). Silver Fox is also capable of fully autonomous ight
from launch to recovery, whilst maintaining communication with the ground station
up to its full range of 40km (Deagel 2003).
Funjet
A paparazzi autopilot system was successfully implemented in a Multiplex Funjet, for
the purpose of gathering meteorological data in the Arctic for the Geophysical Institute
of the University of Bergen/Norway. The UAV autonomously climbs to 1500m, where
it performs a loiter pattern and then glides back to base. Communication is maintained
with the ground station throughout the entire ight, with takeo and landing performed
under manual control (Paparazzi 2009).
Summary
The above UAVs represent a few of many examples where commercially purchased
and open source autopilot systems have been successfully implemented for missions
similar to that of the 2009 Search and Rescue UAV. It therefore appears feasible that
an aircraft can be developed to successfully demonstrate all the capabilities specied
by the project goals.
2.4. IMAGING SYSTEMS
2.4
15
Imaging Systems
Many modern UAVs have extremely sophisticated imagery systems, capable of recording high-resolution footage in both the visible and infrared wavelengths. Due to the
complexity and cost of these systems they are often made as modular systems, with a
single imaging module used for many UAVs in the same family.
An imaging system for use on an unmanned aircraft has quite dierent requirements
compared to a ground-based system, and the use of image processing tools for automonous identication of objects can restrict the type of imaging systems which can
be used.
2007 iSOAR Aircraft

The 2007 iSOAR aircraft incorporated a lone visual-spectrum analogue camera placed
in the belly of the aircraft, angled forwards in order to be useful for aircraft control as
well as ground surveillance.
The project team performed a detailed analysis of all available imaging options when
designing the iSOAR UAV. As automatic image processing was not considered feasible
in the time given, the group required live video footage from the aircrafts camera for
manual identication through the ground station (Avalakki et al. 2007).
The selected imaging system consisted of a high-resolution analogue camera supplied
by WirelessVideoCameras, as part of a package including a transmitter and ground
station receiver. The camera incorporated a colour CCD with a resolution of 450TVL
and weighed 70g, while the downlink transmitted in the 2.4 GHz frequency band with
an output power of 1W.
Boeing ScanEagle
ScanEagle is a small, long endurance UAV built by Insitu and Boeing. ScanEagle
utilises an imaging system consisting of a stabilised camera turret located below the
aircraft, which can contain either an electro-optical visual spectrum camera, or an
infrared camera. The turret is designed to track targets for extended periods, and
can resolve objects the size of small vehicles from a range of at least 5 standard miles
(Insitu 2009).
16
Figure 2.9: The Boeing/Insitu ScanEagle UAV, showing the imaging compartment
(CNet 2007).
Aerosonde
The Aerosonde UAV has been used for meteorological missions in the Arctic where it
successfully carried and operated a Histrionics KTII infrared pyrometer for measuring
ground temperature and a variety of still and video cameras for surface imaging. These
instruments have recorded imagery up to an altitude of 1500m. Integrating an infrared
camera into Aerosonde for search and rescue missions in the Arctic has also been
proposed (Curry et al. 2004).
Summary
Based on the analysis of other UAV systems currently on the market, it was deemed
quite feasible that an imaging system could be incorporated into the aircraft, but that
further analysis would be required in order to determine the type of imaging method
which should be used, as well as the form of image processing for autonomous detection
of ground targets. Additionally, selection of a suitable downlink for providing imagery
to ground station controllers was an important consideration which would be conducted
during conceptual design for the overall imaging system.
2.5
Recovery Systems
A large number of modern UAVs employ recovery systems as an alternative or replacement to a standard runway landing. These systems vary from simple hemispherical
or cruciform parachute systems, to parafoil systems with complex rigging and steering
2.5. RECOVERY SYSTEMS
17
ability. Some systems do not employ parachutes at all, and instead rely on groundbased systems by which the aircraft is simply own into a net or cable and caught.
The purpose of such recovery systems can vary. Some systems are simply designed to
reduce damage to the UAV in the event of an emergency, while others are intended as
replacements to standard runway landings, even to the point where the aircraft may
not include a landing gear.
IAI I-View
The Israel Aerospace Industries I-View series of UAVs all incorporate a parachute
recovery system for precise landings. The parachute is a parafoil type, with steering
ability to allow the pilot to land on a set location. The system is claimed to have an
accuracy of 50m x 50m, with no limitation on crosswinds (IAI 2002).
Figure 2.10: The IAI I-View MK50 UAV, with para-foil recovery system deployed (IAI
2002)
Boeing ScanEagle
The ScanEagle UAV implements a novel recovery system which completely replaces
a standard landing gear. The aircraft is own into a vertical wire on the ground,
and captured through use of hooks on the aircraft wings (Insitu 2009). This has the
advantage of negating the need for a landing gear to be attached to the aircraft, which
reduces the drag experienced by the aircraft in ight, and can also reduce weight
(although the need for strengthened wings can reduce this advantage).
18
Figure 2.11: The SkyHook capture system used for the Boeing ScanEagle (Insitu
2009)
2007 iSOAR Aircraft

The 2007 iSOAR Aircraft incorporated a parachute recovery system consisting of an
octagonal parachute deployed using a spring-loaded drogue parachute (Avalakki et al.
2007). The deployment method of the 2007 parachute relied on a series of actuators
which would release the top hatch of the aircraft during ight, followed by the release
of a spring-loaded mechanism which would propel the drogue chute out of the top of
the aircraft. The force generated by the drogue parachute would then pull the main
parachute from the aircraft. The 2007 recovery system was designed as a complete
replacement to standard runway landings, and was also intended for use when the
aircraft was being launched from a moving car (without the landing gear attached).
The main parachute had an equivalent surface area of 3.65 m2 , which corresponded to
a descent rate of 8.02 m/s or an equivalent drop height of 3.28 m. The parachute was
attached to the aircraft at four locations on the wing tongue using 200lbs kite line,
however no swivel was incorporated in the design, potentially resulting in problems
with a rotating parachute or aircraft upon descent. Ripstop nylon was home-stitched
into the required octagon shape, resulting in a total parachute weight, including lines,
of 600g.
Summary
From analysis of the systems listed above, it appears feasible that a recovery system
can be developed in order to improve safety and reduce damage to the aircraft in an
emergency situation. However, further analysis is needed to ensure that such a system
does not compromise the performance of the aircraft due to the extra weight involved.
2.6. TECHNICAL TASK
2.6
19
Technical Task
The technical task, including the technical level, economic parameters, standard requirements and performance requirements, was generated from the results of the feasiblity study.
2.6.1
Technical Level
The intent of the project is to consider all aspects of a general purpose surveillance
UAV, from concept to implementation. However, as the overall design goals of the
project are similar to those of the 2007 iSOAR aircraft, many of the resources (both
material and academic) left from the 2007 project will be utilised where appropriate.
The technical level to be achieved is as below:
Extended design and development of the existing UAV platform manufactured
using existing techniques and readily available materials.
Integration of existing avionics and improved image analysis equipment.
Congure avionics and image analysis equipment with relatively simple programming techniques such that the vehicle can perform missions autonomously.
Flight testing of new structures, avionics and image analysis equipment to demonstrate the vehicles ability to complete autonomous missions successfully.
The vehicle is to have good structural integrity, reliability and appeal for commercial sale and use.
2.6.2
Economic Parameters
The aim of the project is to produce a relatively inexpensive UAV. Therefore, where
appropriate, components utilised in the 2007 design will be reused in the 2009 design.
The preliminary budget of this project, considering the intended design changes only,
is restricted to $5,000. The details of the budget are presented in the Management and
Finances section.
2.6.3
Standard Requirements
The vehicle is to be operated within Australia, and therefore it will be required to

meet the Civil Aviation Safety Regulations (CASRs) set out by the Civil Aviation
20
Safety Authority (CASA), the governing body of Australias Aviation Industry. In

particular, the design of the aircraft must adhere to UA25 of CASR which is entitled
Design Standards: Unmanned Aerial Vehicles - Aeroplanes. The operation of this
vehicle must be in accordance with Part101 of CASR which is entitled Unmanned
rocket and aircraft operation.
2.6.4
Performance Requirements
Altitude
The operational altitude is to be between 200 ft and 400 ft, excluding take-o and
landing. The cruise altitude will be 300 ft as it provides a reasonable balance between
image clarity and the sweep width of the UAV.
Cruise Speed
In order to cover the entire search area (total search distance of 70643 m) in 50 minutes,
the aircraft requires a cruise speed of 25 m/s.
Operational Range
While remaining within the mission boundary specied in section 2.1.1, the maximum
distance from the ground station is 8.8 km. With the inclusion of a 1.2km safety
margin, the mission range was therefore limited to 10 km.
Takeo and Landing
The takeo and landing distance of the aircraft is limited to the ARCAA Outback
Challenge runway length of 1600m. However, smaller takeo and landing distances are
desirable in order for the UAV to be exible in a variety of locations. A distance in
the order of 50m appeared reasonable for most applications and the intended size of
the UAV.
Endurance
The UAVs minimum endurance will be 1 hour and 15 minutes of continuous ight in
accordance with the maximum mission time allowed for the Outback Challenge.
2.6. TECHNICAL TASK
21
Level of Autonomy
In accordance with the Outback Challenge rules, the UAV must be capable of some
form of autonomous control. For the purposes of the project it was desired that the
aircraft would be capable of fully autonomous ight, excluding takeo and landing.
2.6.5
System Requirements
Airframe
The airframe should be of an appropriate size such that it can safely house all subsystems and t in a standard station wagon. This would greatly improve its ease of
transportation and the exibility of its operations. In addition, the components of the
airframe must be capable of withstanding the stresses imposed on them during all ight
regimes. The control surfaces must be capable of providing adequate control in pitch,
roll and yaw directions.
Propulsion System
The UAV is to be propeller driven and employ a brushless DC motor. The batteries should have sucient capacity for at least 1 hour and 15 minutes of continuous
operation.
Control System
A control system capable of both autonomous and manual control is required. The
autopilot should be capable of autonomous navigation in 3 dimensions based on GPS
waypoints, and it should be possible to modify the UAVs ight path mid-ight.
A reliable communication link should be maintained between the UAV and ground
station up to the maximum range of 10 km, and should provide a means of receiving
ight data at the ground station and asserting manual commands. Onboard batteries
are required to power the autopilot and modem. Their capacity should be sucient
for 1 hour and 15 minutes of continuous operation.
Imaging System
The camera should be able to distinguish a person from an altitude of 300 ft. In
order to ensure the entire search area is covered (using the search strategy outlined in
22
Section 2.1), the camera requires a horizontal eld of view (HFOV) of at least 67.3.
A downlink is required to stream video footage from the UAV to the ground station,
with a minimum range of 10km. The onboard batteries for the camera and downlink
should be sucient for 1 hour and 15 minutes of continuous operation.
Payload Deployment
The payload is a container capable of holding 500ml of water. The deployment mechanism should be capable of jettisoning the rescue package on command, and be reliable
up to the maximum operational range of 10 km. The payload is to land within 100
m of the target, and no water should be lost from the container on impact with the
ground.
Emergency Recovery
It must be possible to deploy the recovery system by manual command, where the
command can be applied up to the maximum operational range, and will be applied
automatically onboard the aircraft if communication is lost for greater than 5 seconds.
The primary requirement of the recovery system is to ensure safety of people on the
ground. Minimising the damage inicted on the UAV is a secondary consideration.
Chapter 3
Conceptual Design
The conceptual design of the aircraft and associated systems involved the analysis of
how each mission requirement would be met, and selection of components and manufacturing techniques used to create each system.
3.1
Aircraft Conguration
The choice of aircraft conguration is an important decision, and can drastically aect
the performance of the aircraft in a given application. Due to the desire to make use
of as many resources from the 2007 iSOAR aircraft as possible, the decision of aircraft
congration was reasonably restricted.
3.1.1
Conguration Review
A review of possible airframe congurations was performed. Good stability and controllability were desirable characteristics for maximising the reliability of autonomous
ight, while high eciency and low weight were benecial for high endurance missions.
Furthermore, the manufacture time and cost was also a limiting factor. A decision
matrix is depicted in Table 3.1, which shows that a conventional conguration was the
most benecial in terms of the chosen criteria.
3.1.2
Propeller Placement
The placement of the aircraft propeller is also an important consideration, and can
have a signicant impact on the performance and maintenance requirements of the
aircraft.
23
CHAPTER 3. CONCEPTUAL DESIGN
24
Table 3.1: Airframe Conguration Decision Matrix

Criteria
Controllability
Stability
Eciency
Weight
Manufacture time
Total
Conventional
5
5
3
3
5
21
Pod & Boom

5
5
3
3
2
18
Twin Tail
4
5
2
2
1
14
Flying Wing
2
2
4
5
3
16
Canard
3
1
3
4
2
13
The two main propellor congurations are:

Tractor or Puller
This conguration is the most common conguration for single-engine aircraft, and has the propellor mounted at the nose of the aircraft.
Advantages
Easy to locate propellor on the aircraft without clearance issues
Well-known conguration
Ideal weight location for aircraft centre of gravity
Disadvantages
Prevents placement of imaging or communications equipment in the
nose of the aircraft
Pusher
This conguration has the propellor mounted behind the fuselage, pushing
the aircraft through the air.
Advantages
Improved aerodynamic eciency, as propellor wash does not ow
over aircraft wing
Aircraft nose can be used for imaging or communications equipment
Disadvantages
Aircraft take-o can result in propellor impacting the runway unless
clearances are correctly calculated
Aircraft landing gear may pick up rocks or other debris, possibly
damaging the propellor
Large mass at rear of aircraft can have a negative eect on aircraft
centre of gravity
3.2. AIRCRAFT DESIGN PARAMETERS
3.1.3
25
Conguration Selection
One of the major aims of the project was that as many resources possible would be
used from the 2007 iSOAR aircraft, in order to minimise project expenses. Changing
the aircraft conguration would preclude the use of many of these components - particularly the aircraft fuselage and empennage, which could not be feasibly redesigned and
manufactured with the resources available to the project group. In addition, a conventional conguration was deemed the most eective conguration for the redesigned
aircraft, due to its inherent stability and manufacturability advantages over most other
congurations.
For these reasons, a conventional aircraft conguration was chosen for use on the 2009
Search and Rescue UAV, with the propellor placed in the aircraft nose in a tractor
conguration.
3.2
Aircraft Design Parameters
In order to accurately generate a preliminary design for the aircraft, several aircraft
parameters were determined by considering the class of aircraft being designed, as well
as its likely performance parameters and mode of operation. These parameters, along
with the decisions made and the reasoning for those decisions, are listed below.
Aspect Ratio
The aspect ratio of the wing is an important consideration, as it determines the lift
distribution of the wing. A high aspect ratio increases the aerodynamic eciency of
the wing at the expense of higher structural weight, while a lower aspect ratio will
conserve structural weight but have a lower aerodynamic eciency (Raymer 2006).
It was decided that an aspect ratio of 10 would be an eective balance between aerodynamic and structural eciency for the 2009 aircraft. This is an increased aspect ratio
over the wing used for the 2007 iSOAR aircraft, which used an aspect ratio of 8.
Twist
A wing twist angle of -2 degrees is recommended for general aviation aircraft (2 degrees
washout) (Raymer 2006), and this value was chosen for use on the redesigned aircraft
wings.
26
Sweep Angle
Swept wings are generally used for aircraft travelling at supersonic or high transonic
speeds, where portions of the wing may experience supersonic air ow (Raymer 2006).
As the project requirements call for an aircraft with a cruise speed far below the speed
of sound, it was decided that it was not necessary to implement a swept wing.
Taper Ratio
For an aircraft with a sweep angle of zero a taper ratio of 0.45 is ideal as stated by
Raymer (2006).
Wing Dihedral
From the results of a market survey on UAV wing dihedral (presented in Table 3.2) it
can be seen that the broad range of modern UAVs have a low dihedral angle. Larger
dihedral angles are seen on many passenger aircraft in order to increase stability and
reduce pilot workload (Raymer 2006), a problem which is less important in the case of
an unmanned aircraft.
Table 3.2: Wing Dihedral
Aircraft
Global Hawk
ScanEagle
Cryo Wing
Silver Fox
Knat 750
IAI Heron
Predator
MQ-9 Reaper
3.3
Dihedral
0o
0o
1o
0o
0o
0o
0o
0o
Aircraft Preliminary Sizing
In order to determine the engine power and wing area required by the aircraft, a matching diagram was created. The matching diagram relates the power loading (W/P ) and
wing loading (W/S ) of the aircraft, and contains a line representing each performance
requirement of the aircraft.
3.3. AIRCRAFT PRELIMINARY SIZING
3.3.1
27
Stall Requirements
Given the desired stall speed and a known maximum lift coecient for the aircraft, the
required maximum wing loading was calculated using the following equation:
W/S
1 2
= Vstall CLmax
2
(3.1)
The stall speed of the aircraft was chosen to be a maximum of 15m/s at an altitude of
1500ft. This is the maximum altitude allowed under the rules of the ARCAA Outback
UAV Challenge, and is also an appropriate altitude for most applications the aircraft
is likely to be used. This resulted in a wing loading of:
W/S
3.3.2
(3.2)
= 16.0 kg/m2
Takeo Distance Requirements
The takeo distance requirements provide a maximum power loading for the aircraft,
given the minimum length of runway the aircraft is designed to take o from. A shorter
runway will require a lower power loading (corresponding to a higher power engine).
The desired maximum takeo distance for the 2009 iSOAR aircraft was chosen to be
50m, as this is a common distance for model aircraft runways, and a longer distance
would reduce the aircrafts mission exibility. This was an important consideration
from a marketing perspective, but was also essential to allow adequate ight testing of
the aircraft.
Obstacle clearance was not considered, as any aireld used for takeo would likely be
several times larger than 50m.
To nd takeo length (Sg ) the following equation was used:
Sg =
1
2gKA
ln
2
KT + KA VLOF
KT
(3.3)
Where:
KA =

2
W CD0 KCLT O + CLT O
S
(3.4)
28
KT =
3.3.3
(3.5)
Climb Requirements
The climb requirements for the aircraft are specied by CASA, and must be met if the
aircraft is to be certied. The required climb gradient is 8.33%, with a safety factor of
1.4 (resulting in a desired climb gradient of 11.67%).
The equation for climb requirements with respect to power loading and wing loading
was derived from fundamental equations for steady climb:
(3.6)
T D W sin() = 0
P
W
V
=
sin() +
S
W
W cos()
q CD0 + K
S
q
(3.7)
For safety Vclimb = 1.3Vstall
V = 1.3
3.3.4

2 W
S
CLmax
(3.8)
Cruise Requirements
The cruise speed was calculated to be 25 m/s in Section 2.1.3.

Cruise speed requirements were calculated using the following equation:
V
P
=
W
3.3.5
qCD0
W +
S
W
S
K
q
(3.9)
Matching Diagram Results
The matching diagram in Figure (3.1) shows the results of the preliminary sizing of the
aircraft. The curves on the graph represent the limitations of wing loading and power
loading in order for the aircraft to meet all performance and regulatory requirements.
3.3. AIRCRAFT PRELIMINARY SIZING
29
The Met Area (area where the power loading and wing loading will both meet all
requirements) is shown. Smaller values on the y-axis correspond to a higher required
engine power, and smaller values on the x-axis correspond to a higher required wing
planform area.
!"#$%&'( )&"(*"+
60
'
')./0 ()*+,-% !&' #$%&$!
(
!"
50
40
Stall Requirements
Cruise Requirements
Climb Requirements
50m Takeoff
2007 iSOAR Aircraft
30
20
123 '4563
9::; 7,0<0*=>
123 7827
10
0
0
10
15
!,-% ()*+,-% !&?
20
25
30
#$%&@9"
Figure 3.1: Matching Diagram

It can be seen from the matching diagram that the aircraft is mainly limited by the
desired stall speed and take o requirements. Although the desired stall speed is not a
xed requirement for this aircraft, keeping the stall speed as low as possible aids with
low speed ying such as on an approach to land. In this important stage of ight it is
necessary to slow the aircraft as much as possible to reduce the landing distance while
keeping full control of the aircraft and minimising the risk of stalling or spinning.
The preliminary design point for the aircraft, chosen from the matching diagram (Figure 3.1) was chosen as:
W/P
= 18
kg/kW
W/S
= 16
kg/m2
30
3.3.6
Weight Estimation
The 2007 iSOAR aircraft had a total takeo weight of 11kg, and this value was used
as an initial estimate of the nal weight of the 2009 aircraft. By omitting the weight
of the aircraft parachute, rigging and deployment system (further discussed in Section
3.8), as well as making the assumption that the redesigned wings would be equivalent
or less weight than their 2007 counterparts, it was decided to use a weight estimate of
10kg for the 2009 aircraft.
3.3.7
Final Design Point
As explained in further detail in Section 2.6.4, it was decided that the 2009 design
would make use of the AXI 4130-20 electric motor used for the 2007 aircraft. This
motor has a rated power of 900 watts.
Using the aircraft weight estimate of 10kg from Section 3.3.6, the shifted power loading
for the aircraft then becomes 11 kg/kw with addition of the 900 watt AXI GoldLine
motor. A 10kg aircraft weight also results in a required wing area of 0.625m2 .
The nal design point for the aircraft is therefore:
W/P
kg/kW
W/S
3.4
= 11
= 16
kg/m2
Propulsion System
A propeller driven aircraft was selected given the preference for high engine eciency
over high thrust. This preference was based on the need for high endurance and it
was expected that the aircraft would perform the majority of its missions at cruise.
Furthermore, it was decided at the commencement of the project that an o the shelf
propulsion system would be sourced to reduce development time and ensure reliability.
3.4.1
Motor Type Selection
A survey of similar UAVs on the market indicated that the majority use either internal
combustion (IC) or electric power plants.
3.4. PROPULSION SYSTEM
31
IC Engines
Hydrocarbon internal combustion engines, such as glow-plug engines, were common in
the model aircraft industry and in research applications. The glow-plug engine works
similiar to an automobile engine, however a catalytic reaction between the glow-plug
and the fuel (rather than a spark plug) ignites the fuel/air mixture. It was evident that
the fuel used by these UAVs were common and therefore would be easily accessible. In
addition, the fuel used by IC engines has a relatively high energy density. IC engines
require regular maintenance however, such as the application of lubricants, and are
known to emit pollutants into the atmosphere.
Electric Motors
The popularity of electric motors in the model ight industry and in research applications has increased in recent years due to signicant improvements in battery
technology. The large storage capabilites of lithium polymer (LiPo) batteries have had
a signicant impact on this increase. Electric motors are noted for their relatively high
eciency and low level of maintenance, however the batteries they use have a relatively
low energy density in comparison to fossil fuels.
The use of a brushless DC motor appeared more benecial than a brushed DC motor,
as they experience less frictional losses and are therefore more ecient and have a
longer service life (Model ModelFlight 2009).
Summary
A decision matrix was created in order to determine which propulsion system would
best meet the project requirements. The selection criteria is outlined in table 3.3 and
each system was given a score out of 5 for each criteria. From this, the decision was
made to use a brushless DC electric motor.
Table 3.3: Decision matrix for propulsion system selection
System
IC engine Electric motor
Energy density
4
2
Engine eciency
2
4
Level of maintenance
3
5
Ease of implementation
3
4
Environmental impact
2
5
Total
14
20
32
3.4.2
Electric Motor Selection
A power of 560 W was required from the motor. Therefore, a market survery was
conducted of electric motors with the capability to provide this as shown in Table 3.4.
Table 3.4: Current Available Brushless Motors
Motor
Kv (RPM/V)
Weight (g)
Maximum
Eciency
Current
(A)
AXI
4130-20
305
409
40
1000
AXI
4130-16
385
409
40
1000
Power 46
670
209
40
925
Power 60
400
380
40
1425
Pmax (W )
Reference
Model
Motors
(2009)
Model
Motors
(2009)
E-Flite
(2009)
E-Flite
(2009)
Purchasing a Power 60 motor would improve the power to weight ratio in comparison
to the AXI 4130-20, which was purchased in 2007. However, the small improvement
in weight was not signicant enough to justify the incurred expense, therefore the AXI
4130-20 was maintained in the design.
3.4.3
Propeller Selection
Overloading electric motors by using an unsuitable propeller can quickly lead to damage
of the motor, hence a propeller size of 16x8 was chosen based on the manufacturers
recommendations and conrmed through testing.
3.4.4
Electronic Speed Controller (ESC) Selection
The Electronic Speed Controller used in the 2007 design was chosen based on its weight,
cost and its current handling capabilities (Avalakki et al. 2007). The selected ESC was
the MasterSpin 750 OPTO and at the time was the best option. However, given the
budget and time constraints of the project it was not deemed necessary to select another
ESC.
3.4. PROPULSION SYSTEM
3.4.5
33
Motor Batteries
There were two battery types, which had sucient capacity for the mission, they were
Lithium-Polymer and Nickel Metal Hydride (Ni-MH) batteries. A market survey was
conducted to determine which of these batteries would be most feasible. Below is a
comparison of the two battery types.
Table 3.6: Li-Po and Ni-MH Battery Comparison
Voltage
(V)
Charge
(Ahr)
Weight (g)
11.1
10.8
Type of
Battery
Lithium-Polymer
Nickel Metal Hydride
1.0
1.0
85
175
As shown in Table 3.6 Li-Po batteries are lighter than Ni-MH batteries for the same
amount of charge and similiar voltage. Therefore given that weight was a primary
factor for selection of the batteries, Li-Po batteries were selected.
The manufacturers recommendations for the AXI 4130-20 are listed in Table 3.8
(Model Motors 2009).
Table 3.8: AXI 4130-20 specications
motor (%) No. LiPo Cells Vmotor (V)
85
8
29.6
An endurance of 75 min was required where it was assumed that the aircraft would
cruise at 160 W for 72 min and utilise maximum power of 560 W for 3min. The required
battery capacity was therefore calculated to be 8.7Ahr using the equation below.
Cbattery =
tPshaf t
Imotor t =
motor Vmotor
tPshaf t
+
motor Vmotor
max
cruise
Flight Power EVO20-33004S battery packs were recommended by Model Flight (2009).
These had a voltage of 14.8 V and a capacity of 3300 mAhr each. Two packs were
connected in series to produce a twin pack with the voltage required for the motor,
and 3 of these twin packs were connected in parallel to provide the desired capacity.
Therefore, 6 battery packs were required in total.
34
3.5
Manufacturing Concepts
The manufacturing methods selected for all parts of this aircraft are based on cost,
required tooling and material availability. Techniques considered are primarily based on
methods used in the model aircraft industry where weight, strength, cost and material
availability are of upmost importance. The manufacturing methods considered include
built up structures, foam core and hollow moulded.
3.5.1
Wing Manufacture Methods
Built up
A built up manufacture method involves the use of materials such as aluminium or
wood in order to manufacture spars and ribs for the internal structure of the aircraft
wing (see Figure 3.2). Aluminium becomes impractical to use for smaller aircraft,
and so materials such as balsawood and plywood are commonly used. The completed
structure is then covered with a skin, consisting of thin plywood or plastic lm.
Built up structures can be made to be very lightweight, but require time consuming
construction and can be easily damaged during ground handling.
Figure 3.2: Built up wing construction (Johnson 2007)

3.5. MANUFACTURING CONCEPTS
35
Foam core
Using a foam core to make the ultimate shape of the wing is a very common technique
because of the low cost, low weight and the added strength of the semi-rigid part. The
core is generally hotwired or CNC machined to shape, then is skinned with composites
or in some cases thin balsa or ply (Figure 3.3) . This method is very simple, durable
and does not require expensive equipment or tooling, so is a very good option for
small wings. With careless cutting of the foam and poor techniques for skinning, large
dierences between desired and actual shape can be encountered therefore reducing
the performance of the wing.
This method is adequate, however care must be taken to ensure the desired shape is
produced.
Figure 3.3: Composite covered foam core construction (Decker 2002)
Hollow Moulded
When combined with accurate tooling, mollow moulded composite stuctures provide
the most accurate nish of all the methods mentioned. Accurate tooling is expensive
and time consuming, usually requiring a plug to be machined from a suitable material
and the a mould pulled o of the plug.
36
3.5.2
Selection
Hollow moulded wings provide the most accurate manufacture and the best surface
nish. However, due to time constraints and budget limitations, the method was considered infeasible. Foam core wings covered in a composite skin provide an acceptable
compromise between strength, ease of manufacture and added durability. Even though
this manufacturing method is less accurate than hollow moulded techniques, the diffence in performance is likely to be insignicant. The decision matrix is depicted in
Table 3.9.
Table 3.9: Decision matrix for wing manufacture selection
System
Weight
Complexity
Cost
Strength
Manufacture time
Total
Built Up
4
3
4
3
2
16
Hollow Molded
5
2
2
4
2
15
Foam Core
3
5
5
4
3
20
For these reasons, it was decided to use a foam core manufacturing method for construction of the 2009 aircraft wings.
3.6
Control and Communication Systems
The functionality and reliability of the aircraft control systems are crucial for achieving
mission goals and maintaining appropriate levels of safety. In the case of a UAV, control
systems generally consist of two critical components; the controller itself, whether it be
a hand controller for manual control or a CPU for autonomous control, and a communication link between the UAV and the ground station. The design specications for
the control and communications systems were derived from the mission requirements.
3.6.1
A number of dierent ight regimes were analysed to determine the UAVs mission
requirements including:
Take-o and landing
37
Search
Loiter over target
Payload deployment
Emergency recovery
Takeo and Landing
It was desired that takeo and landing be manually controlled to reduce the risk of damaging the UAV, and so the system should be capable of switching between autonomous
and manual control during ight. For takeo, manual control will be utilised until
the UAV reaches the desired altitude, at which point the UAV will be switched to
autonomous mode. For landing, the UAV will autonomously maneouvre within close
proximity of the controller, where it will be converted to manual control for landing.
Search
In the majority of surveillance missions, the UAV will be required to negotiate a predened search pattern with the intent of maximising the area covered. This search
pattern will be pre-programmed and performed autonomously based on GPS waypoint
navigation. To ensure the aircraft is operating as required, it is essential that ight
data be returned to the ground station. This may include sensor reports, position
monitoring, etc. It is also expected that the mission prole be able to be modied
during ight. This may include instructions to return to base, loiter over a target,
deploy a payload, etc. Therefore, communication between the groundstation and UAV
should be maintained at all times. For entrance in the Outback Challenge, the communication range is required to be 10km. This appeared realistic for most surveillance
applications.
Loiter
Once the target has been identied, the UAV is required to loiter above it and wait
for further instructions. This is particularly relevant for search and rescue, as the
target should be identied before deploying the emergency payload. Loitering will be
an autonomous procedure, which follows some repetitive pattern above the target. At
this stage, loitering will be initiated by a manual command from the ground station.
38
Payload Deployment
After conrmation that the target has been found, the payload will be deployed. Deployment will be manually asserted from the ground station.
Emergency Recovery
In the event of component failure it is essential that the UAV responds appropriately.
Minimising risk to people on the ground holds the highest priority while minimising
UAV damage is a secondary consideration. It is essential that this system can be
deployed by a manual command from the ground station and autonomously if communication is lost for greater than 5 seconds. This is in accordance with the Outback
Challenge rules (ARCAA 2009), although the aircraft would more likely be instructed
to return home if such an event occurred under non-competition situations.
3.6.2
Manual Control
An RC (Remote Control) system was required, such that a pilot could manually control
the UAV from the ground. The primary tasks to be performed by this system include
takeo, landing, recovery in the event of an emergency and close range ight when the
autopilot is not required. RC systems are widely used in the model aircraft industry and
therefore provide a readily available and reliable means of providing manual control.
The primary components of the RC system include the controller/transmitter and the
receiver, which is placed on board the UAV.
System Specications
A six channel RC system is required such that the pilot has control over throttle,
ailerons, aps, rudder and elevator, as well as switching between manual and autonomous control. In addition, full range capability is desirable such that the UAV
can be controlled up to the edge of visual recognition.
Market Review
A number of RC systems were investigated. Two systems, which were already available to the project group, met the minimum requirements and were therefore further
analysed in order to identify, which was more suitable for the design. These systems
included:
39
JR X2610
DX7 Spektrum
The JR X2610 is a six channel system, which utilises a 36 MHz transmitter, while
the DX7 Spektrum is a seven channel system, which utilises a 2.4 GHz transmitter.
The DX7 Spektrum was found to include additional features designed to improve the
integrity of the RC signal. These additionl features included:
The utilisation of second generation digital spread spectrum modulation (DSM2),
which reduces the probability of narrow band interference.
The system transmits simultaneously on two dierent frequencies, creating a
redundant radio frequency (RF) path.
The utilisation of dual receivers, each of which are exposed to a dierent RF
environment.
System Selection
The DX7 Spektrum as shown in Figure 3.4 appeared to oer superior signal integrity
and an additional channel, which could possibly be used for future developments. In
addition, testing of the 2007 design demonstrated that the DX7 Spektrum performed
signicantly better than the JR X2610 when implemented with the autopilot system.
Therefore, the DX7 Spektrum was selected for the design.
Figure 3.4: DX7 Spektrum RC system including dual receivers and servos (Model
ModelFlight 2009)
40
3.6.3
Autonomous control
An autopilot system is required to control the UAV throughout all stages of ight
excluding takeo and landing. It was decided that a commercially available autopilot
system would be utilised, as it was likely to be more reliable than a custom system and
could be implemented in a shorter period of time.
System Specications
Based on the mission requirements, the following design specications were made.
Capable of autonomous control during all stages of ight excluding takeo and
landing.
Minimum of 7 servo control pins for direct control over the throttle, separate
ailerons, aps, elevator, rudder and payload deployment.
GPS waypoint navigation
Manual override
In-ight monitoring capability
In-ight command capability
Minimum of 10 km communication range
Market Review
The project group has access to the Micropilot 2028g autopilot and corresponding Microhard MHX-2400 RF modems, which were utilised in the 2007 iSOAR UAV. The
2028g is relatively light and compact, and is capable of complete autonomous operation from launch to recovery, utilising GPS waypoint navigation. The autopilot is
also capable of receiving commands during ight and sending ight data back to the
groundstation via the modem pair. The autopilot utilises Proportional Integral Derivative (PID) control loops, which need to be tuned during ight in order to optimise the
performance of the UAV. The Ground Control Station (GCS) software Horizon, was
provided with the 2028g for the purposes of conguring the autopilot, generating ight
plans and monitoring the UAV during ight. The RF modems operate in the 2.4 GHz
frequency band and are capable of transmitting up to 10 km. The default transmission
power is 1 W, though this setting is user congurable.
41
The 2028g and RF modems meet the minimum requirements set out by the design
specications. However, as the Micropilot 2028g was never successfully implemented
in the 2007 design, the capabilities of other autopilot systems were investigated to determine whether any improvements could be made. Table 3.10 indicates the advantages
and disadvantages of other autopilot systems in comparison to the Micropilot 2028g.
Table 3.10: Comparison of 2028g with other autopilot systems

Autopilot
Manufacturer
2128g
Micropilot
Piccolo
LT, plus &
II
Cloudcap
Technology
Advantages
2 x input/output pins
20 x CPU power
Integrated RF link
Electronically
shielded
More robust
Kestrel
2.23
Procerus
Technologies
Lighter and smaller
AP04
UAV Navigation
Paparazzi
Hardware:
PPZUAV
Software:
Open Source
Integrated RF link
Processor redundancy
More robust
More exible
Better after sale
support
Disadvantages
Cost: $6875 AUD
Lead time: 4 weeks
Cost: $10000 AUD
Lead time: 6 months
Larger and heavier
Cost: $6250 AUD
Lead time: 6 months
GCS purchased
separately
Cost: $12250 AUD
Lead time: Unknown
Heavier
Cost: $640 AUD
Lead time: 3-8 days
System Selection
The advantages and disadvantages of purchasing a new autopilot system were analysed. With the exception of cost and lead time, the disadvantages of the alternative
autopilot systems appeared tolerable. It was decided however, that although improvements could be made over the Micropilot 2028g, the improvements were not signicant
enough to justify the expense and lead time associated with purchasing a new autopilot. Therefore, the Micropilot 2028g as shown in Figure 3.5, including the Microhard
MHX-2400 modem pair, were retained in the design. Paparazzi however, met the autonomy requirements of the project and was recognised as being relatively cheap and
having a signicantly shorter lead time than other commercial autopilots. Therefore,
paparazzi was identied as a feasible alternative in case the Micropilot 2028g was to
fail during the project.
42
Figure 3.5: Micropilot 2028g (MicroPilot 2009)
3.7
Imaging System
The imaging system was broadly required to serve as the eyes of the UAV, an essential
task for the vast majority of applications the iSOAR aircraft is designed to suit. Search
and rescue, shark spotting, trac monitoring, bushre early warning - all of these tasks
require the aircraft to be able to see its surroundings and transmit this information to
a ground station.
3.7.1
Requirements
As a specic primary goal, the newly designed imaging system was required to be
capable of autonomously detecting and tracking the lost bushwalker specied in the
ARCAA Outback Challenge. This is a rather narrow requirement considering the
areas the aircraft is intended to be used, but was deemed a suitable proof of concept
and starting point for more advanced imaging systems. The imaging system was also
required to serve as a visual conrmation of the state of the aircraft, as well as a visual
guide for landing and performing manoeuvres.
The inclusion of autonomous target detection is benecial for a number of reasons,
most notably the greatly reduced workload imposed on ground operators who would
otherwise be forced to monitor a video feed for extended periods (Peer et al. 2002).
Such work can be expensive, fatiguing and error prone, and it is not uncommon for
remote camera operators to miss identication of a target simply due to the long period
of intense concentration required (Kruegle 1996). Automated identication of objects
of interest signicantly reduces this fatigue level, only requiring operator attention in
order to conrm a potential target.
The eld of image processing has progressed greatly in recent years, with open-source
image processing libraries such as OpenCV making advanced image processing tasks
achievable without requiring several years of development (Bradski 2008).
3.7. IMAGING SYSTEM
3.7.2
43
Problem Description
Target Characteristics
As specied in the competition description, the lost bushwalker is dressed in khaki and
wearing an Akubra hat. These colours are less than ideal for image processing, as they
appear often in nature. Colours such as red can be useful for object detection, as they
occur infrequently in nature but reasonably often in man-made objects (Hazeldene &
Price 2005). However, most other colours are less than useful as distinguishing features,
necessitating additional information for detection of the desired object.
Due to the cruise altitude of the aircraft, it was unlikely that a person could be easily
distinguished by a human observer given the cruise speed of the aircraft, let alone an
image processing program. Analysis of footage taken by the 2007 aircraft also showed
a reasonable amount of static, due to interference with the camera downlink. Although
interference issues were intended to be xed for the 2009 aircraft, it was unlikely that
they would be removed entirely. Therefore, any successful image processing algorithm
would have to account for this static, while still being able to pick out a human wearing
khaki clothing, on a similar coloured background, from an altitude of at least 300ft.
IR Emitter
As well as specifying the clothing and pose of the bushwalker requiring rescue, the
ARCAA competition rules specify that an infrared source will be placed with the
bushwalker in order to assist in detection. The infrared source is a 50 watt, 12 volt
Videotec IR50, which emits light at a wavelength of 850nm. This source is placed with
the lost bushwalker and points upwards throughout the competition day.
The addition of a source of infrared light simplies the detection of the bushwalker,
as a camera congured to detect 850nm light would simply see a white dot on a grey
background when passing over the location of the bushwalker. Many common cameras
are capable of detecting 850nm light, although the majority incorporate IR-cut lters
which block out infrared radiation. The ability to detect the infrared source would
drastically increase the likelihood of the aircraft detecting the stranded bushwalker,
and an infrared camera would be an extremely useful addition to the aircraft for each
of the other functions it is expected to perform (although a much more advanced
camera would be needed for the majority of these tasks, such as human heat signature
detection or re detection).
44
Camera Requirements
For the purposes of the 2009 Search and Rescue aircraft, any camera integrated in the
airframe would need to be as lightweight as possible, while still providing a sucient
resolution to allow identication of a ground target from the aircraft cruise altitude.
The search path outlined in section 2.1.3 was created with the assumption of a standard
3.6 mm, 1/3 camera sensor, with a HFOV of 67.4. These values could be modied,
although too small a viewing angle could potentially require the aircraft to y above the
maximum altitude for the competition, and too wide a viewing angle would introduce
distortion into the video image. Therefore, these values were a good starting point for
the specications of cameras to be considered for use.
The resolution of any selected camera would be limited by the capabilities of the
downlink used, but the camera would need to be capable of identifying a human shape
from the minimum altitude specied in the ARCAA challenge rules (200ft). The camera
would also need to have a frame rate capable of holding the target within frame for a
sucient number of frames when passing directly over the target at cruise altitude.
3.7.3
Camera Selection
There were a number of potential camera types which could be used to meet the mission
requirements:
Visual
A visual camera provides imagery in visible light wavelengths, and is the form of
camera used in the 2007 iSOAR aircraft. This type of camera is ideal for identication
of unusually coloured objects or objects which are easily distinguishable from natural
formations, and is also benecial for nal conrmation of a target once a suspected
detection has occured.
Near-Infrared
The majority of modern camera charge-coupled devices (CCDs) are capable of seeing
in the near-infrared spectrum (between 750nm and 1400nm) and just beyond the capabilities of the human eye. This characteristic is widely used for night vision security
cameras, which make use of infrared Light Emitting Diodes (LEDs) to illuminate a
scene which is otherwise dark in the visual spectrum. A camera capable of vision in
3.7. IMAGING SYSTEM
45
near-infrared wavelengths would be ideal for detection of the infrared emitter placed
with the target of the ARCAA outback challenge, as detection would be the equivalent
of looking for a spotlight in the visible spectrum.
Long-Wavelength Infrared (Thermal)
Thermal imaging cameras have many forms, and have been in use for military applications for many years. These cameras have the advantage of being capable of vision
in low-light environments, without requiring active illumination. Such cameras are
ideal for detection of human objects on comparatively cold backgrounds, or for monitoring refronts through smoke. However, thermal imaging cameras are prohibitively
expensive, with lightweight versions (capable of use on a small aircraft) even more so.
Selection
Use of a near-infrared camera was determined to be the most eective method of detecting the ARCAA Outback Challenge target. Purchase of an inexpensive monochrome
security camera, combined with an IR-Pass lter to block visible light from the camera CCD, would allow for the target to be seen as a clear white dot on an otherwise
grey background. This would simplify detection of the target using image processing
techniques.
If permitted by time and budget constraints, a second visual camera could be included
in the aircraft for visual conrmation of the target after initial detection.
3.7.4
Downlink Selection
Transmitting the live video feed from the aircraft to the ground station is a major
bottleneck in the imaging system, as bandwidth requirements for the camera downlink
increase dramatically as the resolution of the onboard camera is increased.
Analogue Downlink
The 2007 iSOAR aircraft made use of a commercial analogue transmitter capable of
being connected to a camera via a standard composite video link. This made the
system quite modular, as the camera used could be changed without issue provided it
could be connected to a composite video plug. The 2009 group inherited this system
from the 2007 iSOAR project, consisting of an analogue video transmitter as well as a
46
directional receiver dish for the ground station. Use of this system would save sigicant
resources for other aspects of the project, due to the cost of purchasing a new system.
The disadvantage of this system, or any other analogue video transmission system, is
that the resultant signal is susceptible to losses and transmission interference, whereas
correction of these errors is relatively trivial with a digital signal (Barry et al. 2003).
This can pose a problem when using autonomous detection methods via image processing, as static in the video feed can be a major source of false positives.
Digital Downlink
Use of a digital downlink for transmitting a live video feed has many potential advantages; the incoming video feed does not need to be converted before processing
(as it is already a digital image), the downlink is much less susceptible to interference and will simply drop frames rather than suer static, and the link can be relayed
several times without requiring signal boosters and the corresponding problems with
amplifying signal noise (Barry et al. 2003).
A major disadvantage of digital links is that they have a much lower bandwith than
a comparable analogue link, and so transmission of live video generally requires the
video to be compressed before it can be sent. This requires a microprocesser to be
present on the aircraft, at additional cost, complexity, and weight.
Selection
Despite the advantages of digital transmission, and due to the budget limitations of
the 2009 project, it was decided that retaining the camera and datalink system purchased by the 2007 iSOAR team was the most eective solution for the 2009 aircraft.
Obtaining a digital solution would also require purchase of a digital transmitter and
ground station, the cost of which would be too great for the team to eectively manage. However, use of a digital downlink still has many advantages, such as allowing
autopilot communications to be carried over the same link. Such a solution will be
explored as possible future work for the project.
3.7.5
Image Processing System
Computer vision is an active area of computer science research, with many software
libraries available for image processing purposes. The two main options for the 2009
imaging system are discussed below.
3.7. IMAGING SYSTEM
47
Matlab
Matlab is a system in use throughout the engineering and scientic industries, and is
used extensively within the University of Adelaide. Matlab contains numerous modules
for image processing tasks, and is presented in a language and format (Matlab .m les)
familiar to most scientic and engineering students. Matlab has also been used for
several projects at the University of Adelaide which make use of image processing. The
primary disadvantage of Matlab is the propriatory nature of the software, requiring a
Matlab licence in order to make use of the image processing libraries.
OpenCV
OpenCV is a computer vision library developed by Intel, and is an open-source library
free for commercial and research use. The library is written in C, is multi-platform,
and can perform the vast majority of image processing tasks including edge detection,
facial recognition, and image stitching (Bradski 2008). The open source nature of
the OpenCV library gives it a signicant advantage over Matlab in terms of usability,
as there are far less restrictions on how the library can be used. In addition to this
usability advantage, the 2009 project group posessed prior experience using OpenCV
for basic image processing tasks.
Selection
Due to the advantages present in using an open source system and the experience of
certain 2009 project team members, OpenCV was chosen as the platform to be used
for creating the image processing software to be run on the aircraft ground station.
3.7.6
Summary
The nal imaging system for the 2009 aircraft will consist of an infrared-capable security
camera with an IR-pass lter, connected with the aircraft ground station through the
analogue downlink inherited from the 2007 iSOAR project. The ground station will
posess image processing software for processing the incoming video feed, written using
the Intel OpenCV library and capable of autonomously detecting the infrared emitter
placed with the target of the ARCAA Outback Challenge.
48
3.8
Recovery System
The main requirement for the redesigned recovery system was that the aircraft should
not pose a risk to safety in the event of an emergency situation such as radio contact
being lost. A secondary consideration was that the aircraft would ideally be recoverable
in an emergency situation, with no major or irreparable damage. Any implemented
recovery system would also have the restriction of not unduly aecting the performance
of the aircraft itself.
A maximum descent rate of 5 m/s (equivalent to dropping the aircraft from 1.27m)
was demanded of the redesigned recovery system, in order to minimise aircraft damage
upon landing.
3.8.1
Comparison of Recovery Methods
The following recovery methods were investigated for inclusion in the 2009 aircraft:
Ground-Based Capture Systems
Several commercial and military UAVs do not use a conventional landing gear, instead
relying on a catapault or other assisted-launch mechanism for takeo, and netting or
wires to catch the UAV as it comes in for landing. The Boeing ScanEagle is one notable
example of this form of recovery. Recovery of the ScanEagle is achieved by simply ying
the aircraft into a ground-based net, which hooks on to the aircraft wingtips, catching
and holding the UAV in place (Insitu 2009).
This form of system has several advantages, as the UAV itself requires no landing gear,
signicantly reducing the weight of the aircraft. However, such a system would not be
suitable for use on the 2009 design, as the recovery system is intended for emergency
situations rather than everyday landings. Additionally, a xed, ground-based system
would not be suitable for recovery of the aircraft in the event of communication being
lost during ight.
Parachute
A parachute based system is the most widely use recovery method for unmanned aircraft, and also for heavier amateur rocketry recovery systems. Given the weight of
the 2009 aircraft this method was immediately deemed the most feasible solution for
3.8. RECOVERY SYSTEM
49
meeting all the recovery requirements of the aircraft, although further analysis was
required in order to determine the weight penalty involved.
No Recovery System
An early concern during the analysis of possible recovery systems for the 2009 aircraft was that a feasible method (i.e. able to meet both the primary and secondary
requirements without unduly sacricing aircraft performance) would not be found. In
addition, it would be unlikely that any selected system could be eectively tested.
Any test failure would almost certainly mean destruction of the aircraft, as it was not
possible to construct additional prototype aircraft purely for testing.
Because of these concerns, there was the possibility of abandoning the secondary requirement - that the aircraft should suer a minimum damage in an emergency situation
- and instead focus on the use of a controlled crash to prevent the aircraft endangering the public. A disadvantage of this approach was that the aircraft would be less
attractive from a marketing perspective, and would be less appealing for missions over
populated areas when the connection between the aircraft and the ground station is
not guaranteed.
Recovery Method Selection

From analysis of the above recovery methods, it was decided that only two possibilities
could meet the requirements. The weight of the aircraft made a parachute-based recovery method the best possibility for minimising damage to the aircraft in an emergency
situation. However, such a system may pose a weight penalty which would unduly
aect the performance of the aircraft in regular use. A second possibility was to omit
a recovery system for the aircraft, and instead implement a controlled crash method
for situations where contact is lost with the aircraft.
Further analysis was undertaken in order to quantify the weight needed for an appropriate parachute system, in order to more eectively select a suitable solution.
3.8.2
Comparison of Parachute Types
Three main types of parachute were considered for use in the 2009 aircraft:
50
Hemispherical
Hemispherical parachutes have the advantage of being simple and relatively easy to
manufacture (especially if an approximation of a hemispherical parachute is used, such
as a hexagonal or octagonal parachute). They are also easy to pack and have a high
drag coecient, meaning less parachute is needed for the same descent speed (Huckins
III 1970).
The disadvantages of hemispherical parachutes include the large opening loads generated, which typically necessitates rigging to force a gradual opening of the parachute.
In addition, without a bypass hole in the parachute, they have a tendency to oscillate,
and are not steerable (Knacke 1992).
Cruciform
Cruciform parachutes are even simpler to manufacture than hemispherical parachutes,
but can be complex to pack properly. They also have a smaller drag coecient, requiring more surface area (and hence material) than a hemispherical parachute of equivalent drag. The advantages of cruciform parachutes are that they experience much
lower opening shock forces and are quite stable, a reason they are commonly used as
braking aids for aircraft and dragsters (Knacke 1992).
Parafoil
A parafoil operates very dierently from simple drag-generating designs such as hemispherical and spherical parachutes. Technically, a parafoil is classed as a semi-rigid
airfoil, using airow through the parachute to create a wing shape and generate lift.
Because of this characteristic, parafoils are far more steerable than hemispherical or
cruciform parachutes.
The primary disadvantage of parafoils is their complexity and cost, and their inherent
tendency to open very rapidly, leading to high opening shocks - higher than both
cruciform or hemispherical parachutes. It is this characteristic which necessitates a
slider on the parachute lines to slow the opening speed of the parachute (Knacke 1992).
Parachute Selection
It was decided that a hemispherical parachute posed the best option for the 2009
aircraft, as the limiting factor for the parachute would be the available weight and
51
volume on the aircraft. Therefore, a high eciency (drag per unit surface area) was
essential.
Although parafoils are found on several modern UAV designs incorporating parachute
recovery systems, the complexity and cost of such systems was out of reach of this
project. In addition, as the recovery system was an emergency system, the ability
to control and steer the aircraft during its descent was not seen as a large enough
advantage to outweigh the complexity and cost associated with using a parafoil system.
The manufacture advantage of a cruciform parachute was appealing, particularly given
the inexpert nature of the project group and the likelihood that the parachute would
have to be constructed without outside assistance. Therefore it was decided to compromise by selecting an octagonal parachute instead of a true hemispherical parachute.
Octagonal parachutes are created from a simple two-dimensional template, as opposed
to the relatively complicated three-dimensional construction of a true hemispherical
parachute. The resulting behaviours of the parachute would be very similar to that of
a hemispherical parachute, sacricing a small amount of drag for simpler construction.
3.8.3
Parachute Sizing
Sizing to Desired Descent Rate

By assuming the aircraft is in steady-state descent with no upwards or downwards
wind gusts present, the required surface area (Sp ) for the parachute can be calculated
as follows:
Sp =
2ma g
Vd2 Cdp
(3.10)
For initial analysis of parachute size a descent rate of 5 m/s was used, along with
a drag coecient of 0.75, standard for hemispherical/octagonal parachutes (Knacke
1992). Using these values along with an aircraft mass of 12kg, the known values
of gravitational acceleration (9.81 m/s2 ) and air density (1.225 kg/m3 ) resulted in a
required parachute surface area of 9.4 m2 .
Using the equation linking parachute surface area with diameter, an expression can be
found for required parachute nominal diameter given the desired descent rate:
Do =
4Sp
(3.11)
52
Do =
8ma g
Vd2 Cdp
(3.12)
Where Do is the nominal diameter of the parachute. Using this equation, it was
determined that a parachute with a diameter of 3.46 m would be required in order to
obtain a descent rate of 5 m/s. Figure 3.6 shows a plot of descent rate against required
parachute diameter, marking the desired value of 5 m/s as well as the descent rate
achieved by the 2007 parachute system.
()&*)+,-./,)-#!"' 0&-1/2/*34,)-(5/$),)2-#(6'
&$"$$
%!"#$
!" #$%&'
%#"$$
%&"#$
%$"$$
7889-5:;<.-<52*2/=,
!"#$
788>-()&5?+
#"$$
&"#$
$"$$
$"$$
%"$$
&"$$
'"$$
("$$
#"$$
)"$$
!"$$
(6 #$'
Figure 3.6: Steady-state descent rate versus nominal parachute diameter
Equivalent Octagonal Parachute Dimensions
The nal parachute selection called for a two-dimensional octagonal shape, designed
to approximate the performance of a true hemispherical parachute but without the
associated complexity in manufacture. Brohm (2004), explains that the dimensions of
a polygonal parachute can be calculated from the equivalent hemispherical parachute
area using the following relations, where n is the number of sides to be used (8 in this
case):
53
Ls =
4Sp tan( 180 )

n
n
(3.13)
and
Do =
4Sp
n tan( 180 )
n
(3.14)
As the required parachute surface are is known to be 9.4 m2 , this results in an octagonal
parachute with sides of length 1.4 m.
Parachute Opening Force
The shock load exerted on the airframe during initial parachute opening is an important
consideration, as excessive loading can necessitate the use of reeng mechanisms to slow
the opening speed of the main parachute.
From Knacke (1992), the maximum opening force created by a parachute can be calculated using the following relation:
Fo = 1/2Vi2 Cdp Sp Xi Cx R
(3.15)
Parachute Eciency and Weight Calculation

The eciency of the parachute was dened using the amount of parachute surface area
which could be obtained per unit volume, as well as the density of the parachute in
weight per unit volume. Ideally the parachute would meet the required surface area
while taking up a minimum of space and weight when fully folded. This would be
limited by the type and weight of the fabric used (assuming it could withstand the
necessary loads), and the type and length of lines used to connect the parachute to the
aircraft frame.
As an initial estimate the parachute used for the 2007 aircraft was measured and
weighed, and used as a baseline for the redesigned system. The packed volume of the
parachute was calculated as 0.003 m3 , and the weight of the parachute including all
54
lines was 0.6 kg. This resulted in a packing coecient (parachute surface area divided
by packed volume) of 1216.7, and a parachute density of 200 kg/m3 .
Given that the required parachute area for a descent rate of 5 m/s was determined as
9.4 m2 , and assuming that the same eciencies will apply to the redesigned system,
the redesigned parachute packed volume can be calculated:
Vp = 9.4/1216.7
Vp = 0.0077 m3
And the resulting weight of the parachute including lines and rigging:
mp = 200 0.0077
mp = 1.54 kg
This estimate of the weight of the redesigned parachute assumes the same eciencies
in packing, materials and manufacture as the 2007 system, which had a very short
development time and so could be expected to contain some compromises with regard to
weight. However, even as a rough estimate this value shows that a parachute designed
to slow the descent of the 2009 aircraft to 5 m/s will be in the order of 15% of the total
weight of the aircraft.
3.8.4
Summary
The nal estimated parachute weight was deemed an unacceptably high proportion of
the total aircraft weight. In addition, it was decided that a fully designed parachute
system could never be fully tested (that is, during ight testing of the aircraft), as failure
during a test would most likely result in total destruction of the aircraft, and the time
restrictions associated with the project preclude the manufacture of a replacement or
separate prototype aircraft.
For these reasons, the group decided to discontinue development of the parachute
system, and therefore ignored the secondary requirement of the recovery system in
favour of the primary requirement: that the aircraft should not pose a danger to the
public in the event of an emergency.
3.9. PAYLOAD RELEASE MECHANISM
55
To this end, it was decided that the No Recovery System option would be chosen,
with the aircraft simply intentionally crashing into the ground in the event of a communication loss or other emergency. This would prevent the aircraft drifting out of
any safe areas and into a populated area, and prevent potential injury at the expense
of sacricing the aircraft itself.
3.9
Payload Release Mechanism
The requirements of the ARCAA Outback Challenge specify that the aircraft must be
able to drop a 500ml bottle of liquid within a 100m radius of the lost bushwalker. This
requires a mechanism that can be reliably actuated by the onboard autopilot system.
Another consideration of the system is that it must be low drag so that it minimises
the reduction in performance and does not interfere with aerodynamic control of the
aircraft.
3.9.1
Concepts
Strap
The strap design involves an elastic strap that holds the bottle into a cradle underneith
the aircraft. This concept is very simple but basic tests showed that large tension
needed to be placed on the elastic strap to ensure the bottle would not move during
ight. This tension places high load on the actuation servo which can cause a high
current drain from the servo batteries and potential problems during release..
Clip
A clip concept involves the bottle being held into the fuselage by a small pin, which
is removed by a servo. This design is not particularly complex, although may require
reasonably precise tolerances in the pin mechanism. The disadvantage of this system
is that the bottle (or casing) must be modied to incorporate the pin, and that the
friction force on the pin may cause a high load on the actuation servo.
Chute
A pivoting chute design was investigated and found to be possible to incorperate into
the unused bay under the aircraft. A cylidrical chute is attached to a pivoting arrangement which is actuated by a standard servo, with gravity causing the bottle to slide out
56
once the chute has been opened. This design reduces the frontal area of the payload
deployment mechanism, reducing drag on the aircraft.
The main disadvantages of this system is that it is heavier than others considered and
there is no reduction in drag once the payload has been deployed.
3.9.2
Summary
A decision matrix was created to determine which payload release system would be the
most eective at meeting all design requirements. The selection criteria is outlined in
Table 3.11 where each system was given a score out of 5 for each criteria. Although
the chute design is seen to be the heaviest, the reduction in aerodynamic drag and
actuation force outweighs the disadvantages and therefore was chosen for the payload
release mechanism.
Table 3.11: Decision matrix for payload release system selection
System
Weight
Aerodynamic Drag
Reliability
Actuation Force
Manufacture time
Total
3.10
Strap
5
3
3
3
4
18
Clip
5
2
4
2
2
15
Chute
3
5
5
5
3
21
Final Concept
The nal concept design for the aircraft can be seen in Figures 3.7 and 3.8, with the
major aircraft specications shown in Table 3.12.
Table 3.12: Design Specications
Parameter
Length
Span
Root Chord
Tip Chord
Wing Area
Specications
1600 mm
2490 mm
340 mm
160 mm
0.6225 m2
Parameter
Motor Power
Aircraft Weight
Wing Loading
Power Loading
Specications
900 W
10 kg
16 kg/m2
11 kg/kW
3.10. FINAL CONCEPT
57
Figure 3.7: Final concept 3-View of the aircraft

"(A3031%+'3021"H
!(0&"3,231%
"(A
%#-(
!#2(
!"#$%
2;<<
=>?9@?>@
&'(&)(!
(%*+#,,"
-*"+#,,"
!#2(
#,,"1A(!
.%/(00+12'("$30(+0,(&343(!
!3-(%031%0+#"(+3%+-3//3-(2("0
#%*/(0+56768
9+,/+56766+:+,/+567666
-;F;C
-;<JP
#LF;MNO;F
IDFFJCK
IDFFJCK
IDFFJCK
0MJJ<+&;QFC;OOJC
Figure 3.8: A side ew of the nal concept aircraft, showing all major subsystems.
%#-(
!#2(
!"#$%
2;<<
=>?=>?=>
&'(&)(!
(%*+#,,"
-*"+#,,"
.%/(00+12'("$30(+0,(&343(!
!3-(%031%0+#"(+3%+-3//3-(2("0
#%*/(0+56768
9+,/+56766+:+,/+567666
SOLID EDGE
UGS - The PLM Company
232/(
03@( !$*+%1
!"
43/(+%#-(B+!CDEFG
0&#/(B
$(3*'2B
"(A
0'((2+>+14+>
!"#$%&'%(
!"#$%$&'($)*+$,-.
232/(
03A( !$*+%1
!"
43/(+%#-(C+,DEFGH7<IJ
0&#/(C
$(3*'2C
0'((
Chapter 4
Detailed Design
4.1
4.1.1
Airfoil Selection
Selection Considerations
The airfoil for the redesigned aircraft wing was selected based on the following requirements:
A maximum lift coecient, Clmax greater than or equal to 1.2, as this was the
value assumed for the aircraft sizing calculations.
Eectiveness at low Reynolds numbers (1 105 < Re < 6 105 ), due to the
relatively low speed of the aircraft.
A high lift to drag ratio, L/D
Good ap performance
Minimal airfoil complexity for ease of manufacture
The SD7032 airfoil was determined to be the most ideal airfoil for the 2007 iSOAR
aircraft (Avalakki et al. 2007). Therefore, other airfoils (shown in Table 4.1) were
benchmarked against the SD7032 in order to determine the ideal airfoil for the 2009
wing.
59
CHAPTER 4. DETAILED DESIGN
60
Table 4.1: The airfoils analysed for use on the redesigned wing
Airfoil
HQ 3.0/13
HQ 3.0/15
HQ 3.5/13
NACA 23012
SD7032
SD7037
Presented in Appendix A are the polar plot comparison of six airfoils commonly used
on model aircraft, including the SD7032 and SD7037. The plots show that at low
Reynolds numbers, only the SD series airfoils have good performance through the full
Cl range. At higher values of Re the other airfoils provide good values of Cd , but the
SD series airfoils still perform better over the full Cl range.
For this reason, it was decided to retain the SD7032 airfoil for the redesigned wing.
Figure 4.1 shows the plot of Cl versus CD for the SD7032 at various Reynolds numbers.
SD7032 Polar Plot

1.60
1.40
1.20
1.00
Cl
0.80
Re 100 000
0.60
Re 200 000
Re 300 000
0.40
Re 400 000
0.20
Re 500 000
Re 600 000
0.00
-0.20
-0.40
0.00
0.01
0.02
0.03
0.04
0.05
0.06
CD
Figure 4.1: The performance of the SD7032 airfoil at various Reynolds numbers
4.2. TAILPLANE DESIGN
4.2
4.2.1
61
Tailplane Design
Tailplane sizing
With the conventional design of the fuselage, a simple analysis of tailplane areas was
completed by performing a statistical analysis of real world aircraft. This was presented
in the form recommended by Raymer (2006). Tail volume coecients were used to
calculate a suitable tailplane area and moment as presented in Appendix C.
Table 4.2 depicts the results of the analysis in comparison to the 2007 iSOAR tailplane
sizing. As shown the current size of the tailplanes were greater than the required size
and therefore met the tailplane sizing requirements.
Table 4.2: Tailplane sizing requirements
Horizontal Stabiliser
Vertical Stabiliser
4.2.2
2007 iSOAR Size

0.0863m2
0.0345m2
Required Size
0.0798m2
0.0318m2
Rudder and Elevator Sizing
The requirements for the tailplane control surface sizing were:

Chord length of the rudder to be between 20% and 30% of vertical stabiliser
chord (Simons 2002).
Chord length of the elevators to be between 20% and 30% of horizontal stabiliser
chord (Simons 2002).
Control surface span to be maximised within the constraints of the tailplane.
The tips of the stabilisers are to be left intact however, to prevent damage to the
control surfaces if the tail were to impact with the ground.
The 2007 aircraft utilised a rectangular rudder and rectangular elevators with chord
lengths of 0.30 CV and 0.30 CH respectively. In addition, a small clearance was allowed
between the control surfaces and the stabiliser tips. This met the requirements for the
2009 design and therefore these control surface sizes were maintained in the design.
62
4.3
Wing Design
The wing design was based on the aircraft preliminary sizing, which required a wing
loading of 16 kg/m2 . Therefore, given the estimated aircraft weight of 10 kg, a wing
planform area of 0.625 m2 was required.
It was necessary to determine the aerodynamic loads on the aircraft in order to calculate
the internal stresses produced by the redesigned wings. In addition, it was desired that
the new wing tongue design be compatible with the 2007 wings, in case the new wings
were damaged during testing.
4.3.1
Design Factors
The aircraft wings and airframe were designed to meet the following requirements:
A load factor of 3.8 in accordance with FAR23 for normal category airplanes
A safety factor of 1.5 for composites in accordance with FAR 23.303
CASR 101 rules were considered, however as the aircraft is categorised as a small UAV
(<150kg) and not used for commercial purposes, certication rules did not apply.
4.3.2
Aerodynamic Design
Gust Loading
The gust loading for the wing was calculated using the methods presented in Raymer
(2006). The base equation used is noted below:
n =
U V Cl

2 W
S
(4.1)
It was noted that the wing loading and average chord of the aircraft have a signicant
eect on the gust loading of the aircraft. As the wing loading increases, the mass ratio
also increases and reduces the eect of the gust. In addition, as the average chord is
decreased (aspect ratio increased) the mass ratio increases.
4.3. WING DESIGN
63
V-N Diagram
The ight envelope of the aircraft was limited by several factors including stall, structural strength and gust loadings.
V-N Diagram
5
+%)!,$ %&'()*!
Load Factor
!"#$ %&'()*!
%)*++ %'&&(
!"#$%& %'&&(
-1
-2
0
10
20
30
40
V (m/s)
Figure 4.2: V-N Diagram including gust loading

In the VN diagram of Figure 4.2 it was evident that at a cruise speed of 90km/h the
aircraft could not aerodynamically reach the maximum load factor of 3.8, as the wing
would stall. However, if the aircraft was accelerated to approximately 105km/h the
aircraft could possibly be damaged by violent manouvering.
4.3.3
Control Surface Sizing
Ailerons
The sizing of the ailerons was undertaken using an estimate provided by Simons (2002),
which suggested an aileron width of between 20 and 30 percent of the wing chord. This
was similar to the aileron sizing used by the 2007 project group, and as no issues were
reported with the controllability of the aircraft, this length was deemed sucient.
64
The ailerons of the 2007 aircraft lie between 55 and 95 percent of the half span of the
wing, and a similar conguration was chosen for the new wings. The 5% clearance
between the aileron and the wingtip was chosen to minimise the damage inicted on
the ailerons if a wing was to impact with the ground.
Flaps
The width of the wing aps was chosen to be the same as that of the ailerons for
simplicity. The length of the aps was chosen to extend from the aileron to the root
of the wing, with a slight clearance either side to allow for free movement. This length
was chosen in order to maximise the benet provided by the aircraft aps.
4.3.4
Mechanical Design
Aerodynamic Loading
Shrenks approximation (Raymer 2006), represented by equations 4.2 and 4.3, was
used to approximate the load distribution over the wing as an average between the
trapezoidal and elliptical chord distribution. The calculated distribution is depicted in
Figure 4.3.
C (y) = Cr
2y
(1 )
1
b
(4.2)
and
C (y) =
C (1 + )
2 r
b
2y
b
(4.3)
The distribution, including the load factor of 3.8, was applied to the wing. The lift
generated by the fuselage was considered to be zero and the approximate wing weight
was subtracted from the load distribution. The resulting bending moment diagram is
depicted in Figure 4.4.
It was evident from Figure 4.4 that the maximum bending moment for the standard
load factor of 3.8 was 86 Nm, occuring at the wing root (x = 55 mm). The maximum
bending moment was relatively large, as the majority of the aircraft weight consisted
of non-lifting parts.
4.3. WING DESIGN
65
Local Lift Distribution

1.4
1.2
Local Lift
0.8
0.6
0.4
0.2
0
0
200
400
600
800
1000
1200
Position (mm)
Figure 4.3: Local Lift Distribution

Wing Joining
A rectangular beam was used to transfer the loads betweed each wing and to the
fuselage as shown in Figure 4.5 below. This design was chosen in order to simplify
manufacture.
Figure 4.5: Wing tongue joiner

The maximum bending stress of the joiner was calculated using simple beam theory:
=
My
I
(4.4)
Using the maximum bending moment of 86 Nm, the maximum bending stress was
calculated to be 217 M P a. In 2007, an aluminium wing joiner was used with the mechanical properties indicated in Table 4.3. Aluminium was not an acceptable material
66
Bending Moment Diagram

100
90
80
Moment (Nm)
70
60
50
40
30
20
10
0
0
200
400
600
800
1000
1200
Position (mm)
Figure 4.4: Bending Moment Distribution

for the 2009 wings however, as it provided a reserve factor of only 1.05, which was
under the desired reserve factor of 1.5. Therefore, the use of an alternative material
was investigated.
Table 4.3: 2024-T3 Aluminium Material Properies (Typical)
Mechanical Properties
Tensile Strength (Yield)
Tensile Strength (Ultimate)
Value
345
483
Units
MPa
MPa
The most promising candidate was pultruded carbon strip, whose mechanical properties
are indicated in Table 4.4. It was found that for the same dimensions, this material
could provide a reserve factor in the order of 8. Furthermore, the pultruded carbon
strip would provide sucient reserve factor for an increased wing span and aspect ratio,
thus allowing possible design iterations in the future.
Table 4.4: Pultruded carbon-reinforced epoxy strip (Chen & Lui 2005)
Mechanical Properties
Tensile Strength
Fibre Volume
Value
2799
65
Units
MPa
%
4.4. AUTOPILOT
67
Spar Design
A breglass shear web with carbon bre spar caps was designed to take the majority
of the wing bending loads. This design was produced with the intention of simplifying
manufacture.
The spar cap was designed in a V shape as shown in Figure 4.6 in order to provide a
reasonable bonding area between the shear web and spar caps.
Figure 4.6: Spar design

The stress in the spar was calculated using a composite beam approach as simplied
in Appendix D:
x =
M E1 y
E1 I1 + E2 I2
(4.5)
Bending stress was plotted along the wings and the maximum stress was calculated to
be 299 M P a at the very root of the wing. This provided a reserve factor of 3, which
allowed for errors in manufacture and imperfections in the carbon material used in the
spar.
4.4
Autopilot
The Micropilot 2028g autopilot was initially selected for the UAV, however the discovery of a number of problems with this system led to the purchase of the Paparazzi
68
autopilot system. Paparazzi was succesfully congured and implemented in the UAV
and proved to be an eective and reliable control system.
4.4.1
Micropilot 2028g issues
The Micropilot 2028g was inherited from the 2007 project and attempts were made to
implement it in the 2009 design. Unfortunately, after a signicant amount of time had
been spent familiarising the group with operation of the system, several problems were
encountered.
Firstly Horizon, the Micropilot GCS, was observed to cause recent laptop models to
crash unexpectedly. Micropilot acknowledged that this occurred due to conicts between the drivers used by newer laptops and those of the Horizon license system. They
recommended that a Horizon software update be purchased to solve the problem.
Secondly, upon attempting to initiate the autopilot within the UAV, an Unknown
Fatal Error was displayed, which prevented the autopilot from being operational. It
was believed that this was caused by an incompatibility between the autopilot software
and Horizon, thus it was believed that the Horizon update would solve this issue also.
Finally, it was discovered that Micropilot support had expired. Therefore, it would no
longer be possible to attain advice regarding problems experienced with the autopilot
or its GCS.
There were three options as indicated below.
1. An additional 6 months of support could be purchased for $500 and therefore the
Horizon update could be downloaded from the Micropilot support page for $50.
The total purchase price would be $550 US and Micropilot predicted a lead time
of more than 3 weeks.
2. A Micropilot starter kit containing the Horizon update could be purchased for
$300 US, however no after sales support would be provided. This also had a lead
time of more than 3 weeks.
3. The group could discard Micropilot altogether and purchase the Paparazzi hardware for $535 US from PPZUAV and download the software for free from the
Internet. The lead time for this system was only 3-8 days.
Purchasing the Micropilot starter kit without support was not a feasible option, as
from previous experience it was predicted that signicant support would be required
4.4. AUTOPILOT
69
to eectively operate the software. Therefore, the two remaining options were to either
purchase 6 months of support from Micropilot or purchase Paparazzi. Discarding
Micropilot altogether was undesirable as a signicant amount of money had already
been invested in it. However, it could not be guaranteed that the Horizon update
would be delivered in time or solve all the problems. Therefore, the decision was made
to purchase 6 months of support from Micropilot and additional project funding was
sought to purchase Paparazzi as a backup option.
This proved to be the correct decision as Micropilot support was not delivered on time,
and Paparazzi became the principle control system for the UAV. Further information
regarding the development of the Micropilot autopilot is presented in Appendix J.
4.4.2
Paparazzi Hardware
Paparazzi uses a TWOG (Tiny Without GPS) v1.00 Control Board, which features a
LPC2148 MCU microcontroller. It contains 8 analogue input channels and 8 PWM
outputs. The architecture for the TWOG v1.00 is shown in Figure 4.7. The entire
autopilot system was powered by a 2500 mAh, 7.4V LiPo battery. It was demonstrated
through testing that the capacity of this battery was well above that required for 1
hour and 15 minutes of ight.
A u-blox LEA-5H GPS module with a Sarantel GeoHelix-P2 antenna was used to
determine the UAVs position, altitude and ground speed. This device was an external
module, which was serially connected to the control board.
Four infrared thermopiles were used for primary attitude sensing based on the temperature dierence between the sky and the ground. Two sensors were used to measure
pitch and the remaining two were used to measure roll. An example of two IR sensors
measuring roll is shown in Figure 4.8. These sensors were connected to the control
board via a single analogue input channel. As the output of the thermopiles is aected
by weather and terrain, two additional vertical sensors were implemented to provide
calibration and were connected to the control board by another analogue input channel.
The Microhard MHX-2400 modem pair were salvaged from the Micropilot autopilot
system and were used for bidirectional communication between the Paparazzi autopilot
and the GCS. These modems operate in the 2.4 GHz frequency band and transmit at
1W in order to meet the maximum range requirement of 10km.
As previously discussed, the 2.4 GHz DX7 Spektrum RC system was retained in the
design. The DX7 RC receiver was connected to the autopilot via an external encoder
70
Figure 4.7: TWOG v1.00 architecture (Paparazzi 2009)

board, which converts the PWM (Pulse Width Modulation) output from the receiver
into a PPM signal that can be decoded by the control board.
The conguration of the autopilot and its components is indicated in Figure 4.9 and
the arrangement of these components within the UAV is indicated in Figure 4.10.
4.4.3
Paparazzi Software
As Paparazzi is an open source autopilot system, it was possible to acquire the Paparazzi Centre software for free from the Internet. The Paparazzi Centre provides a
graphical user interface (GUI) for the autopilot, and requires a Linux operating system.
It is used for conguring and writing ight plans for the autopilot as well as running
the Paparazzi Ground Control Station (GCS) for monitoring and controlling the UAV
during ight.
Paparazzi Center
The Paparazzi Center screen is shown in Figure 4.11. The left most panel is used for
editing the XML conguration les while the panels to the right of the screen are used
for building and executing these les for ight or for a simulation.
4.4. AUTOPILOT
71
Figure 4.8: Two IR sensors used to measure aircraft roll (Paparazzi 2009)
Figure 4.9: Autopilot conguration

The conguration les, which hold the greatest signicance, include the airframe and
ight plan les. The airfame conguration le contains all the hardware and software
settings for the UAV including all trims, gains and behaviour settings. This will be
further discussed in Sections 4.4.4 and 4.4.5. The ight plan le contains the instructions and GPS waypoints which dictate the UAVs ight path and payload operations.
This will be further discussed in Section 4.4.6.
GCS
The Paparazzi GCS was the primary means of interaction with the UAV during both
autonomous and manual ight. It provided the GUI for sending commands to the UAV
and viewing sensor data. The GCS screen consists of three primary panels including
72
Figure 4.10: Arrangement of autopilot components within the UAV
Figure 4.11: Paparazzi Center

the Map, Strips and Notebook as shown in Figure 4.12.
The map panel displays the UAVs actual track in red and its intended trajectory
in green. The waypoints dened in the ight plan are displayed as red diamonds.
The Paparazzi GCS can automatically ll the background with satellite imagery from
Google Earth, or display user dened maps. Using satellite imagery was deemed more
suitable in this case as the UAV would be operating in remote regions where there
are minimal landmarks which would be useful on a map. The WGS84 coordinates of
the mouse cursor are displayed at the top right hand corner of the screen as well as
the ground altitude based on SRTM (Shuttle Radar Topography Mission) data les.
Existing waypoints can be modied during ight, however new waypoints cannot be
added.
The strips display the UAVs sensor data, which includes ground speed, throttle, battery
4.4. AUTOPILOT
73
Figure 4.12: Paparazzi GCS

power, altitude, etc. It also provides buttons for initiating a number of pre-congured
ight patterns including take-o, landing, altitude shift and lateral shift. Additional
buttons were created such that ight patterns, designed specically for search and
rescue missions, could be initiated when required. The additional patterns included
the search routine, loiter, payload drop and return to home. The details of these
patterns are discussed in Section 4.4.6.
The notebook consists of a number of pages including Flight Plan, Settings and PFD
(Primary Flight Display). The settings page is particularly important as it allows the
operator to modify the airframe conguration le during ight, which is necessary for
tuning as will be discussed in Section 4.4.5.
4.4.4
Sensor Calibration
Prior to performing autonomous ight it was necessary to calibrate the IR sensors

to ensure that the measured pitch and roll angles were accurate. The calibration
coecients were modied through the settings page in the GCS notebook and saved
in the airframe conguration le (Appendix H.1).
Firstly it was necessary to calibrate the neutral state of the IR sensors. This was
performed by encasing the sensors in a foam enclosure, with no temperature dierence
across each sensor pair. The neutral values were adjusted such that the reading was
zero as required.
The roll and pitch neutrals, which are required for the UAV to perform straight and
level ight, were congured by positioning the aircraft outside on a at surface where
74
the primary attitude IR sensors had line of sight with the horizon. The UAV was
banked at a known angle and the longitudinal and lateral correction coecients were
adjusted such that the measured and actual angle were the same. The neutrals were
further adjusted if asymmetry was observed.
4.4.5
Tuning
Paparazzi uses PID control for stability and navigation. The P term acts directly
on the error between the control signal and the system output, the D term provides
damping to reduce oscillations and the I term acts to eliminate steady state error.
Although PID controllers are used on all loops, many of the I and D terms were not
implemented as they were unnecessary. For example, aircraft pitch is generally well
damped (Paparazzi 2009), therefore the D term was not required in the pitch control
loop. In contrast, navigation is often underdamped, therefore the D term was included
in the navigation control loop. The I term was not included in the navigation loop, as
accurate and reliable wind data could not be provided to the autopilot.
In-ight tuning was deemed to be a more feasible option than developing a mathematical model, due to the relatively short project time frame. The initial gains, prior to
tuning, were based on those of a similar aircraft. It was therefore deemed unlikely that
the aircraft would become unstable.
The controller gains were modied during ight through the settings page in the GCS
notebook and saved in the airframe conguration le (Appendix H.1). Based on the
recommendations of MicroPilot (2007), the gains were adjusted in 25% intervals to
prevent a dramatic increase, which would drive the aircraft unstable. The gains were
increased to the point just before the UAV began to oscillate in order to achieve the
quickest response while maintaining stability.
The inner stability loops were tuned in AUTO1 mode, where the autopilot would
act to maintain the aircrafts stability, however the operator still had control of the
throttle and navigation. After tuning the inner loops, the navigation loops were tuned
in AUTO2 mode. In this mode the autopilot had full control over the aircraft. Details
of the in-ight tuning procedure are outlined in Section 6.2.2.
4.4.6
Flight Plan
A ight plan was written in XML and saved in the ight plan conguration le (Appendix H.2). It contained the instructions and GPS waypoints, which dictated the
4.4. AUTOPILOT
75
UAVs ight path throughout the autonomous stages of the mission. The ight plan
was simulated in software prior to ight as proof of functionality.
Takeo
Takeo is to be performed under manual control. Once level ight is maintained at
approximately the correct altitude and heading, autonomous control is initiated via
the RC transmitter.
Search Pattern
Once autonomous ight is initiated the UAV will y directly to the search area and
begin the creeping line search pattern as described in Section 2.6.4. The search pattern
is depicted in 4.13.
Figure 4.13: Search Pattern
Loiter Pattern
Once the target is spotted, the UAV is manually commanded to loiter above it from the
ground station. During this time conrmation will be made from the ground station
that the object spotted is in fact the desired target.
A number of alternative loiter patterns were considered, including circle, square and
gure 8 patterns. A circle was considered infeasible as it would require the aircraft
to maintain a banked orientation, and therefore the camera would never be directed
76
at the target. A gure 8 was eventually chosen over a square pattern, as the aircraft
would pass over the target twice per run, as shown in Figure 4.14.
The gure 8 pattern was designed with a 100 m turn radius and a distance of 200
m between the centre of the pattern and the start of a turn. These dimensions were
designed such that the aircraft had sucient time to straighten itself before passing
over the target. It was believed that this design could be further modied based on
the results of ight tests.
Figure 4.14: Figure 8 loiter pattern
Payload Deployment
Once the target has been veried by the ground station operator, a payload deployment
routine is manually initiated. The payload is to land within a 100 m radius of the target
in accordance with the Outback Challenge rules (ARCAA 2009).
As shown in Figure 4.15 the UAV performs the gure 8 loiter pattern relative to the
target waypoint. When the payload drop routine is initiated, the aircraft leaves the
loiter pattern and begins an approach. The autopilot calculates the optimum release
position, taking into account aircraft speed, wind, and air resistance. The UAV climbs
from the release point in order to aid the release mechanism. The code for this routine
is included in the paparazzi software.
4.4. AUTOPILOT
77
Figure 4.15: Payload drop routine

Return to Home
The UAV has the ability to autonomously return to home on command from the ground
station, or autonomously in the case of an emergency. The home position in majority
of missions would be where the UAV took o from, though this can be modied to suit
the operators needs.
Generally the UAV will return directly home. However, in the case of the Outback
Challenge where the aircraft must remain within the mission boundary, the UAV is
instructed to return home via a waypoint positioned at the throat of the ight corridor.
This will reduce the risk of the UAV leaving the mission area, and is depicted in Figure
4.16. This type of path is also relevant for other missions where the UAV would be
required to avoid sensitive areas such as densely populated towns.
Landing
When the UAV enters RC range the operator converts to manual control using the RC
transmitter. The UAV is then manually landed.
Flight Termination
A ight termination pattern was required in order to provide for emergency situations
where contact was lost with the aircraft. This mode would deliberately crash the
UAV, preventing it from drifting into populated areas. Termination could be initiated
78
Figure 4.16: Return to home pattern

manually, or autonomously as part of an emergency failsafe. A termination button
was created on the strip, allowing the pattern to be initiated immediately. For obvious
reasons this pattern was never tested during ight, however on ground tests suggested
that it would successfully bring the plane to ground.
In accordance with the Outback Challenge rules (ARCAA 2009) the following termination process is to occur: engine o, full up elevator, full right rudder, full up left
aileron, full down right aileron, both aps down.
Failure Modes
The software was designed such that when an on board component fails, a software
exception was generated. Depending on the situation, 3 dierent actions can then be
taken. The aircraft can either attempt to recover from the failure, alter its ight path
to reduce the damage inicted on it, or execute the ight termination pattern. Failure
patterns were created for a number of failure modes including loss of GPS signal, loss
of engine power, low battery voltage, RC link failure and GCS communication failure.
In the event of GPS signal loss, the UAV will follow a circle pattern and wait for the
GPS lock to be re-established. This would prevent the UAV from leaving the area. If
after a period of 5 seconds a GPS lock is not attained, the termination pattern will be
executed automatically.
If the engine loses power or a low battery voltage is detected, the UAV will cut the
engine and turn into the wind in an attempt to reduce its ground speed. The elevator
4.5. COMMUNICATION SYSTEMS DESIGN
79
will be used to further control the airspeed until the aircraft reaches the ground. The
termination pattern is not required to be automatically initiated in this case, as the
ground station operators would be aware of the UAVs position and therefore could
manually execute the termination pattern if required.
In the case of a loss of RC communication during manual ight, the autopilot will take
control and execute the return to home pattern. The operator can then attempt to
regain control over the aircraft and land it safely.
If the autopilot was to lose communication with the ground station for greater than 5
sseconds, the ight termination sequence will be implemented as per the rules of the
Outback Challenge.
4.5
Communication Systems Design
Three separate communication links exist between the aircraft and the ground station.
These include the manual RC link, autopilot commands/data, and video footage.
In 2007, it was found that the reliability of the RC communication link was signicantly
reduced after installation of the autopilot system. On two occasions when the UAV was
operating under manual control, the RC link was lost. On one occasion this resulted
in a crash and on another an emergency landing. As a result, the autopilot was never
successfully implemented.
Analysis of the 2007 iSOAR aircraft communication systems was neccessary due to the
similarity with those of the 2009 aircraft. Only after this analysis would attempts be
made to implement the communication systems for ight.
4.5.1
Review of 2007 design
The communication systems for the 2007 aircraft consisted of three separate links, as
shown in Figure 4.17. A 36 MHz JR X2610 RC system was used for manual control of
the aircraft (later changed to a 2.4 GHz system), an FM, 2.4 GHz, 1 W video downlink
streamed live video footage to the ground station laptop, and a pair of bi-directional,
2.4 GHz, 1W modems provided the communication link between the autopilot and the
ground station.
The test ights performed in 2007 were examined in order to determine the performance
of its communication systems. The communication systems were introduced in stages
as discussed below.
80
Figure 4.17: 2007 Communication systems conguration

Remote Control (RC)
For the intial ight test, the aircraft was simply own as a model, thus only the RC
communication link was present. At no stage throughout the ight was interference
experienced.
RC and Imaging
An imaging system test was performed where live video footage was streamed from
the UAV to the ground station. For this test both the RC and video signals were
established. The RC signal suered no interference throughout the ight and the video
footage only experienced minor breakouts, believed to have been caused by the highly
directional nature of the receiving antenna.
RC and Autopilot
The initial autopilot test included only the RC system and the autopilot. During
this ight test the RC signal was lost and as a result the UAV crashed. The UAV
was repaired and the same test was performed again, this time with a 2.4 GHz DX7
81
Spektrum RC system. The RC signal was lost momentarily during this ight and an
emergency landing was performed. It should be noted that for both autopilot test
ights, a carbon bre hatch was installed as a ground plane for the GPS antenna.
Summary of Findings
After analysing the 2007 ight tests, it was evident that the reliability of the RC
communication link was signicantly reduced when the autopilot and carbon bre hatch
were installed in the UAV. Therefore, it appeared that either the autopilot signal or
its circuitry was interfering with the RC signal or the carbon bre hatch was causing
some form of attenuation or multiple path eects.
4.5.2
Investigation of possible causes
After a review of various literature, a list of possible causes was generated. The characteristics of each potential cause was examined, thus making it possible to investigate
their eect on the RC system.
Noise (Internal Sources)
The electronic devices and leads on board the UAV generate noise, capable of masking
the RC signal and making it unintelligible to the receiver (Kennedy 1984). When
the autopilot was installed in the UAV, this signicantly increased the quanitity of on
board electronics and with it the potential for interference.
Noise (External Sources)
Noise could also have been introduced to the system from external sources. Potential sources include mobile phones and other communication devices, communication
towers, and high voltage power lines, and are spread over the entire radio spectrum
(Kennedy 1984) . However, as the UAV was operated in relatively remote areas, this
issue appeared to be of little concern.
Narrow Band Interference
It was proposed that narrow band interference could have been caused by devices transmitting in the RC frequency band or by devices with harmonics in the RC frequency
82
band. Narrowband interference results in a reduction in signal to noise ratio (Gerdan

et al. 1995) and could potentially cause the RC signal to become unintelligible to the
receiver. This was initially of concern as the 2.4 GHz RC system and auopilot modems
utilise the same frequency band.
The DX7 Spektrum RC system however, incorporates direct-sequence spread spectrum
(DSSS) modulation (Model Flight, 2009). According to Maxim (2003) and Andren
(1997), DSSS modulated transmission involves the multiplication of the transmitted
signal by a pseudo noise (PN) sequence known to both the transmitter and receiver.
As a result, the energy of the original signal is spread over a much wider band. At the
receiving end, the signal is multiplied by the same PN sequence, which reconstructs
the signal. Undesired signals, with a dierent or no PN sequence, experience no processing gain during de-spreading. Therefore, although the DX7 Spektrum RC system
is susceptible to wide band interference, such as that caused by noise, it should not be
susceptible to narrow band interference. In addition, the 36 MHz RC system encountered the same communication issue despite operating in a dierent frequency band to
the autopilot modem. Therefore, it was decided that narrow band interference was of
little concern.
Receiver Inundation
Placing the RC receiver in close proximity to a transmitting source of relatively high
power, can signicantly reduce signal strength. This is due to inundation of the receiver and is independent of frequency (Gerdan et al. 1995). As receiver inundation is
independent of frequency, the DSSS modulation utilised by the RC receiver would not
be eective. This was a signicant concern as the modem transmits at a much higher
power than the RC transmitter.
Shadowing
Relatively dense or conductive materials, such as copper, steel, aluminium and carbon
bre, eectively shield electromagnetic waves (Chiou et al. 1989). Therefore, if such a
material was located between the RC transmitter and receiver, a signicant reduction
in signal strength would be experienced. As the communication problem arose when a
carbon bre hatch was implemented in the design, the eects of signal shadowing were
considered a signicant issue.
83
Multiple Path Eects

Physical features, particularly smooth and conductive surfaces, eectively reect electromagnetic waves. The reection of an RC signal results in multiple signal paths
whereby the RC signal could eectively interfere with itself (Kennedy 1984). As the
RC system utilises dual receivers, it is expected that the eects of multiple signal paths
would be signicantly reduced. In addition, DSSS modulation decorrelates the delayed
signal, also reducing multiple path eects (Andren 1997).
Summary
From the above analysis, it appeared that the more likely causes of the problem included
noise from internal devices, receiver inundation and signal shadowing. Preliminary
testing was therefore required to distinguish which was the dominant factor.
4.5.3
Preliminary Testing
RC signal strength tests were performed for a number of dierent aircraft congurations. This made it possible to identify which of the on board components reduced the
signal strength. The orientation of the UAV was also varied with respect to the RC
transmitter. The procedures for these tests are outlined in Appendix E.
The results attained from these tests are indicated below.
The noise generated by the on board circuitry appeared to have minimal aect
on the RC signal in comparison to the factors listed below.
Signicant reductions in RC signal strength were experienced across all orientations when the autopilot modem was on. Minimal reductions were experienced
when the autopilot modem was o. This suggested that receiver inundation may
be the primary cause of interference.
Regardless of whether the modem was on or not, a consistent signal loss was
experienced when the tail of the UAV was directed toward the transmitter. This
suggested that signal shadowing was a signicant factor. However, moving the
secondary RC receiver to the tail of the UAV, as shown in gure 4.19, signicantly
reduced these eects.
84
4.5.4
Solution generation
A number of possible solutions were proposed to solve the issue of receiver inundation.
These are listed below:
Utilisation of an RC amplier
Operating RC through the autopilot modem
Reduction of the modem power
Switch modem on during autonomous ight only
The use of an RC amplier was deemed infeasible given that the output power would be
limited to 100mW by the Radiocommunications (Low Interference Potential Devices)
Class Licence 2000. It should be noted that although it is illegal for the RC system to
operate at 1 W, it is not illegal for the autopilot modems to do so, because they are
frequency hopping modems. Furthermore, the video downlink is allowed to operate at
1 W because it is classed as telemetry.
Operating RC through the autopilot modems appeared to be the ultimate solution as
it eliminates the issue altogether. However, although the Micropilot 2028g autopilot is
capable of this, Paparazzi at this stage is not. Code is in the process of being developed
for this task, however at this stage reliability could not be guaranteed.
Reducing the modem power to 100 mW provided a temporary and eective solution,
which allowed the autopilot to be tuned and tested within close range. This however
was not the ultimate solution, as the UAV was no longer able to meet its full range
requirements.
The most feasible solution appeared to be the use of an electronic switch, which would
be used to turn the autopilot modem on only during autonomous ight when manual
control was not required. An electronic switch was included as part of the paparazzi
autopilot as shown in Figure 4.7 and therefore it could be turned on via the RC
transmitter and turned o via the GCS.
There were initial concerns that in the case of an emergency, the operator would not be
able to revert to manual control quickly enough to save the aircraft. It was therefore
decided that prior to implementing the switch, the autopilot would undergo stringent
testing at close range, with a reduced modem power, to ensure its reliability. It should
be noted that the risk to the safety of people on the ground was not a concern, as ights
would only be performed in remote areas. In addition, the ight termination pattern
could be initiated at any time to prevent the aircraft from entering a populated area.
4.6. IMAGING SYSTEM
4.5.5
85
Video Downlink
Given that the higher powered autopilot signal was interfering with the RC signal, it
was expected that the video downlink would cause a similar issue. This however was
not observed during ight testing in the 2007 project, which lead to the belief that
either the 2007 team was extremely fortunate, or that the interference problem was
not entirely understood.
An additional concern was the possibility of interference between the video and autopilot signals. As both systems were never implemented in the 2007 aircraft at the same
time, there was no evidence to suggest that interference would not occur between the
two signals. The decision was made to maintain a similiar conguration to the 2007
imaging communication system. However, these concerns demonstrated the need for
communication range tests, which would be performed prior to ight to ensure signal
integrity.
4.5.6
Summary of Design
A summary of the entire communication systems design is depicted in Figure 4.18.

Note that despite some diering components, the conguration is similar to the 2007
design, except for the electronic switch used to turn the autopilot modem o and on,
and the Ivy Bus, which is discussed in Section 4.7.2. The layout of these systems within
the UAV is indicated in Figure 4.19.
4.6
4.6.1
Imaging System
Camera
The camera selected for use on the 2009 aircraft was a monochrome security camera
designed for use with infrared illuminators to enable night-time vision. Combined with
an IR-Pass lter, to lter out wavelengths shorter than 750nm, the camera was capable
of detecting the 50W, 850nm infrared emitter used in the ARCAA Outback Challenge.
The nal camera specications are listed in Table 4.5.
86
Figure 4.18: Communication systems conguration
Figure 4.19: Layout of communication systems within UAV
Table 4.5: Final Camera Specications

Resolution
512 (H) x 582 (V)
1/3 Samsung
CCD
Lens
3.6mm
Spectral Sensitivity
~400nm to ~1000nm
Power Requirements
12v DC, ~100 mA
Diameter
31mm
Length
100mm (~125mm including cable entry)
4.6. IMAGING SYSTEM
4.6.2
87
Image Processing
As discussed in Section 3.7, the image processing software was required to autonomously
detect and track the infrared emitter placed with the target of the ARCAA Outback
Challenge. Due to the use of an infrared-capable camera with an IR-Pass lter, the
target would appear as a white dot/blob on a grey background.
Software Overview
The Image Processing software was developed using the Java programming language.
Java is an object-oriented language which is executed on the Java Virtual Machine
(JVM), and so Java programs are multi-platform by default without requiring large
amounts of work. The various operating systems in use by the group (including Windows, Linux, and Mac OS X) made a multi platform system essential, and the project
group has extensive experience writing Java software. Important functions from the
software can be found in Appendix I.
Figure 4.20: The Image Processing software
The nal software consists of a graphical user interface (GUI) with a main frame
containing two primary panels. The left panel is a view panel containing the current
video feed, and can be swapped between one of four views depending on the preference
of the user. The right panel contains controls for modifying the behaviour of the
target detection algorithms used for the image processing, and also contains controls
for communicating with the Paparazzi autopilot Ground Control Station (GCS).
88
Target Detection Process
1. Obtaining Video Feed
The analogue video signal collected by the receiver antenna is converted into a
digital video feed through the use of an inexpensive USB video capture card.
Frames from the video stream are then fed into the Image Processing software
for analysis.
2. Initial Processing
Each frame is rst converted into a greyscale image, and then inverted so that
white objects appear black, and vice versa. A pixel threshold is then applied
to every pixel in the frame, culling (locking to white) any which are not dark
enough. The remaining pixels are set to black. The threshold is an integer
between 0 (white) and 255 (black), and can be modied by the user.
3. Blob Detection and Sorting
The remaining groups of pixels, or blobs, are obtained through the use of a
simple OpenCV blob detection function, and placed in an array in size order.
Each blob is then given a quality measurement based on parameters set by the
user, and the blobs are sorted by quality. There are three quality measurements:
Size How close the size of the blob is to a user-dened size
Aspect Ratio How close the aspect ratio of the blob is to a user-dened value
Circular Quality How closely the blob approximates a circle. More accurately,
how close the area of the blob is to the area of a perfectly circular blob of
the same diameter (taken as the average of width and height if the aspect
ratio is greater than 1)
Each of these quality measurements can be given a weighting value if the user
wishes to apply greater emphasis on one type of detection method over another.
If a weighting value is set to zero, that measurement is ignored.
4. Final Target Detection
The blob with the greatest quality value is set as the primary target, and highlighted with a red crosshair for the user. This only occurs after a predetermined
frame count, in order to ensure the target is not caused by signal noise.
A notication noise is also played when the blob is rst detected, and a message is
sent over the Ivy Bus (described in greater detail in Section 4.7.2) to the Paparazzi
4.7. GROUND STATION
89
GCS. This message is used by Paparazzi to update the waypoint containing the
target position. The user may then instruct the aircraft to loiter over this position
or begin a payload drop, through controls in the Image Processing software.
4.6.3
Summary
The completed Image Processing software is capable of autonomously detecting and

tracking white objects of various sizes and shapes, with parameters able to be set by
the user at runtime. The software is modular and can be modied to detect various
types of objects based on their pixel size, aspect ratio, and circular shape, and can
perform these tasks without modication provided the objects can be distinguished
based on being whiter than their surroundings.
The software successfully provides an autonomous target detection system for the ARCAA Outback Challenge, and could also be paired with a thermal imaging (long infrared) camera in order to autonomously detect human heat signatures or other warm
objects.
4.7
Ground Station
The ground station for the iSOAR aircraft is required to maintain a connection with
the aircraft for both manual and automatic ight modes, as well as receive the video
feed from the aircraft camera.
The ground station is also required to process the incoming video feed in order to allow
for autonomous target detection and tracking, and communicate detected targets to
the aircraft. This is performed via the Image Processing software, which is integrated
with the Paparazzi Ground Control Station (GCS) using a communcation interface
called the Ivy Bus.
4.7.1
Aircraft Remote Control Transmitter
Manual control of the UAV is achieved through use of a Spektrum DX-7 remote control
(RC) transmitter. This transmitter is used purely for the takeo and landing stages of
ight, with the remaining ight modes controlled by the Paparazzi autopilot.
90
4.7.2
Paparazzi Ground Control Station
The Paparazzi software maintans a continual broadcast over a communication interface

called the Ivy Bus, which can exist over a network (if the two programs are running
on separate computers) or on common hardware. The Ivy Bus allows other programs,
such as the Image Processing software and video antenna tracking system, to obtain
information about the aircraft position, and control certain aspects of the Paparazzi
GCS. The Image Processing software makes use of this link to inform the Paparazzi
GCS when a potential target has been detected.
4.7.3
Imaging System
Video Datalink Receiver

The video receiver is a directional antenna which obtains the aircraft video feed and
passes it into the Image Processing software for analysis. The highly directional nature of the antenna resulted in the development of an automatic tracking system that
allowed the antenna to track the aircraft based on position information provided by
the Paparazzi GCS.
A software program is used to calculate the antenna placement needed for optimum
video reception based on the aircraft position, and then move the video antenna mount
using servos.
Image Processing System
The Image Processing software obtains a digital video feed from the video receiver
through use of a USB converter, which converts the composite video feed into a series
of digital frames for analysis.
A connection is maintained to the Paparazzi GCS over the Ivy Bus, which is used to
communicate detected targets to the GCS software. The pixel position on the video
feed is converted into GPS coordinates in order to update a target waypoint within
the Paparazzi GCS. The aircraft can then be instructed to loiter over or begin a payload
drop on this waypoint from within the Image Processing software.
4.7.4
Personnel Requirements
The minimum recommended personnel for operating the aircraft ground station consists of one operator for the Image Processing/Targeting system, and one operator
4.8. PAYLOAD RELEASE MECHANISM
91
for both the Paparazzi GCS and the takeo/landing modes of ight (which must be
performed under manual control).
Further development of the Image Processing software could feasibly integrate the
Paparazzi GCS functionality into a single interface, potentially allowing the aircraft
to be controlled with a single operator - although a backup pilot may be required for
safety purposes.
4.8
As outlined in Section 4.8, a chute mechanism was decided upon as the best method
of meeting the requirements of the payload release system.
The nal system (shown in Figure 4.21) consists of a holder for the 600mL bottle
required as part of the ARCAA Outback Challenge, which is bolted onto the base of
the aircraft. A plywood bracket holds the servo for the mechanism, and is connected
to the main bulkhead inside the aircraft fuselage.
&TMD=C
1N=B
%#-(
Figure 4.21: The payload release mechanism design
!#2(
!"#$%
2505
6789:8:;
&'(&)(!
Q5'5
6R8:S8:;
(%*+#,,"
-*"+#,,"
.%/(00+12'("$30(+0,(&343(!
!3-(%031%0+#"(+3%+-3//3-(2("0
.#<+0=>?@A+>BC+"=D@E=
232/(
!?MN+!=OMBDK?>KHMB
The bottle holder is pivoted inside the aircraft fuselage to release the payload,!$*+%1
with a!
03F(
"(<
"# .#<0#"9P9;
!
$
9
minimal operating force required by the servo. The system is also designed 43/(+%#-(Greduce
to +$HBI5CJK
!1+%12+0&#/(
0'((2+9;+14+L6
impact on the aerodynamics of the aircraft, with a streamlined casing used for the
portion of the system in the airstream.
92
The system has a minimal impact on the payload capacity of the fuselage itself, with
only a small amount of the total payload volume housed inside the aircraft.
The servo for the release mechanism can be controlled either manually from the remote
control transmitter, or via the aircraft autopilot. The autopilot can be triggered to release the payload either directly from the Paparazzi GCS, or from the Image Processing
software.
4.9
Final Design
The nal design for the UAV can be seen in Figure 4.22. Highlighted in green is the
connection for the aircraft autopilot antenna, and purple is used for the remote control
receivers.
Additionally, the batteries for the aircraft motor can be seen at the front of the fuselage,
with the battery straps coloured in blue.
Figure 4.22: Final aircraft design, showing all major systems
Chapter 5
Manufacturing
5.1
Wing Construction
By their nature wings involve curves and critical structural components which make
their manufacture relatively complex. To reduce this complexity the wing structure
was designed with manufacture in mind, and construction was divided into sections in
order to work within the curing time of the resin chosen.
The majority of methods used for manufacture of the aircraft wings were experimental
techniques, with the supervision of an experienced composite aircraft manufacturer
and repairer. All methods were optimised as much as possible through the use of dry
manufacturing runs to ensure that no detail would be missed or made overly complex.
CIBA 3600 resin was chosen, as the low viscosity allows for easy wet out of the carbon
and glass bres used for construction, and the working time of the resin is approximately
90 minutes at the low temperatures experienced during manufacturing. This allowed
relatively unskilled project members enough time to complete each manufacturing part
without risk of the resin going o early and ruining the part.
5.1.1
Procedure
Foam Core Cutting

The polystyrene core was cut using a hotwire passed over CNC cut wing templates. A
weighted jig was used to pull the wire through the foam, creating a smooth surface for
the skin to bond to (Figure 5.1). A bandsaw was used to cut the core down the middle
so that the shear web could be located. Finally, a V shape was sanded into the core
ready for the wing tongue box and spar to be attached.
93
CHAPTER 5. MANUFACTURING
94
Figure 5.1: Core Cutting

Wing Box and Shear Web
The wing box was constructed by rst making a box from thin plywood to t the
carbon bre wing tongue (Figure 5.2), then wrapping it in carbon bre rovings. The
shear web was constructed by laying up a sandwich of peelply-breglass-peelply onto
a at sheet of glass. Once cured the sandwich was peeled o and cut to shape.
Figure 5.2: Wingbox Core

After removing the peel ply, the shearweb and wing box was bogged into the foam core
with a mixture of resin, micro balloons and cotton ock. The wing tongue was used as
a jig to ensure that the dihedral and and alignment was correct.
Spar Caps
The excess bog left over from gluing the shear web and wing box was removed from
the wing, and the surfaces were prepared with sandpaper. Resin was painted into
the previously created V-shaped groove in the foam core, and then wetted out carbon
rovings were laid in until the groove was lled. Emphasis was placed on ensuring the
spar was suciently attached to the wing box by fanning out the rovings over the top
of the box (Figure 5.3).
5.1. WING CONSTRUCTION
95
Figure 5.3: Spar Cap Layup
Skin
Mylar sheet was prepared by marking out the wing size for the layup. Resin was
drizzled over the mylar and bre glass worked into the resin (Figure 5.4). As the layers
of glass were built up more resin was added such that the bre glass was suciently
wetted out. The mylar and bre glass was then pressed onto the wing cores using
the negatives from the core cut and then loaded up with weights to ensure adequate
bonding.
Figure 5.4: Fibreglass Layup
Control Surfaces
After curing the wings in a heated room for 48 hours, the control surfaces were cut out
of the wing (Figure 5.5) and prepared for a false spar which allowed the attachment of
hinges. The false spar was bogged in using a similar method to the wing box and shear
96
web and left to cure. Hinges were then attached to the false spar, and servos installed
for ailerons and aps.
Figure 5.5: Completed wing with control surfaces removed
Details
Finally the wing was sanded to prole and lightly painted. White sign writing vinyl
was then stuck to the wing to produce a smooth gloss white surface.
5.1.2
Manufacturing Issues
During manufacture it was discovered that the breglass skin on the wings was not
adequately bonded to the foam core in certain areas towards the tip. A repair scheme
was carried out whereby a mixture of resin and micro balloons were injected into the
wing surface, and then pressed to bond the skin back to the foam.
The manufacturing fault appeared to be due to inadequate pressure being applied
during the curing phase, and not enough resin being used for bonding. For future
manufacture more resin would be wetted out onto the glass before wrapping, and a
vacuum bagging system would be employed to increase pressure.
5.2
5.2.1
Fuselage Modication
Wing Attachment
Due to the change in method for wing attachment, the fuselage from the 2007 iSOAR
aircraft required modication. The original wing attachment was via an aluminium
5.2. FUSELAGE MODIFICATION
97
frame that was attached to the fuselage sub frame with 4 bolts. This required simple
modication in order for the fuselage to be suitable for the new tongue system.
A plywood box was constructed to tightly t the new tongue in the fuselage. This
was glued to the main lifting bulkhead and breglass rovings were wrapped around to
securely x it as shown in gure 5.6. Initially carbon bre was considered but was then
decided against for fear of interrupting the radio signal of the remote control link.
Figure 5.6: Wing attachment
Reinforcing in the form of a plywood bulkhead was glued to the sides of the fuselage in
order to transfer the wing torsional loads from the shear pins to the fuselage sub frame
5.2.2
Battery Location
To achieve the correct centre of gravity of the aircraft the batteries were relocated
entirely to the front of the aircraft. To easily install and remove the batteries slots
were cut into the main sub-frame and Velcro straps installed as seen in gure 5.7.
The connector harness for the batteries was also xed into the sub-frame to allow the
batteries to be easily connected.
98
Figure 5.7: Battery installation
5.3
For testing purposes the payload release mechanism was manufactured as a removable
module, attached to the bottom of the aircraft. This was because a new set of landing
gear, which would have allowed the integration of the payload into the fuselage, was
not manufactured in time. To reduce the time and cost of manufacture, simple and
easily available materials were used for construction.
The test payload release mechanism consisted of a plywood and spruce main frame
and a poly down-pipe bottle cradle. This is attached to the undercarriage dolly using
screws so that it was easily removable and is depicted in Figure 5.8. The mechanism
was actuated with a standard servo with particular attention to the actuation geometry
so that minimum load is placed on the servo when the cradle is in the neutral position.
5.4
Electronic System Installation
The electronic systems are vital for ensuring a reliable UAV system. With the large
quantity of dierent electronics inside the aircraft from servos to the autopilot, an
attempt to manage the wiring inside the aircraft was made. As shown in gure 5.9
below, wiring was secured to the sides of the aircraft to allow access to the autopilot and
modem. All servos are plugged into a wiring block on the starboard side of the aicraft.
When the wings are attached, the secured wiring block simplies the connection of the
5.5. QUALITY ASSURANCE
99
Figure 5.8: Removable payload release mechanism

wing servos to the correct output channels of the autopilot and prevents damage of the
fragile autopilot wiring and connectors.
Figure 5.9: Installed Electronics
5.5
Quality Assurance
An important aspect of the manufacturing process was quality control. Each component was measured post-manufacture in order to ensure it matched all design drawings,
and modications were made if necessary.
Wing Manufacture
The inverse templates for each wing section were used in order to ensure the nished
wing prole was accurate to the nal design. Basic design specications, such as the
wing span, were measured to ensure they conformed to design values. Each wing was
also weighed to ensure they were the same weight within an acceptable tolerance.
100
The completed wings were also subjected to stress testing in order to ensure no manufacturing defects had aected their ability to cope with design loads. The wings were
loaded up to their maximum designed wing loading, and various tests were used to
ensure no cracks were present in the carbon bre spar of the wing. The results of these
tests can be found in Section 6.1.1.
5.6
Completed Airframe
The completed airframe is depicted in Figure 5.10. The aircraft was nished with the
logos of The Sir Ross & Sir Keith Smith Fund and Codan, as recognition for their
nancial support.
Figure 5.10: Completed airframe
Chapter 6
Testing
Testing of the 2009 iSOAR aircraft consisted of three major stages, each of which
needed to be completed successfully before the next could begin. A large amount of
testing involved the use of a test aircraft, a model plane which could be used to test
individual components without risking the iSOAR airframe. Individual components
were rst tested on the ground in order to verify their design and manufacture, before
being placed into the test aircraft for system testing. Once their performance had
been proven in ight, components were integrated into the completed iSOAR airframe.
(Note that additional details regarding the test procedures are provided in Appendix
E).
6.1
Component Testing
Key components were subjected to ground testing before integration into the test
aircraft. The major components and their associated ground tests are described below,
along with the results obtained from testing and any design modications made as a
result.
6.1.1
Wing Structural Test
A wing static load test provided a method of simulating the aerodynamic loads exerted
on the aircrafts wings during ight. The test allows for the structural integrity of the
wings to be checked before integration onto the aircraft, and is also used to ensure that
the wing control surfaces are fully operational under maximum aerodynamic load.
Method
101
CHAPTER 6. TESTING
102
The aerodynamic load distrubution across each wing was calculated using Andersons
method, as found in Abbot & Von-Doenho (1959). This curve was converted into a
piecewise distribution, with the wing divided into sections and loads applied through
the use of sandbags. The theoretical and piecewise distributions can be seen in Figure
6.1.
The wing was loaded to varying degrees of the maximum load, including 20%, 50%
and 80% of maximum load, for a period of 30 seconds. The wing was then loaded to
the maximum load factor of 3.8, equivalent to a total mass of 38 kilograms over the
surface of the wing. This load was applied for a period of 5 seconds.
As the wing was being loaded, a tapping test was performed over the surface of each
wing in order to determine if any cracks had formed, with a hollow noise indicating a
potential crack in the wing spar.
!"#$%)*+,-*./,*"0
%"
$"
1*2324*+2
!"#$%&'(
#"
562"-2,*3#7
!"
'"
&"
"
"
'""
#""
%""
(""
&"""
&'""
8*09%:;#0%&<<(
Figure 6.1: Wing Load Distribution

Results
Under the maximum load, a deection of 70 mm was measured
No cracks, hollow spaces or creaking noises were detected.
Discussion
Given that the wings suered no damage during the test, their structural integrity was
veried. Therefore, the wings were deemed safe for ight.
6.1. COMPONENT TESTING
6.1.2
103
Static Propulsion Test
A static propulsion test was conducted to conrm that the selected motor and propeller
could produce the desired power and thrust for ight. From the matching diagram, it
was determined that the required maximum power was 560 W.
Method
The motor test stand was set-up as shown in Figure 6.2. Multimeters were used to
measure the battery voltage and current, while a load cell was used to measure the
thrust produced by the propeller. A number of propellers were tested to conrm that
the selected 16x8 propeller produced the optimum results.
Figure 6.2: Motor Test Stand

Results
It was determined that a 16x8 nylon propeller produced the most thrust for the same
amount of power, which conrmed the propellers selection. It was noticed however
that this propeller cavitated severely at lower speeds.
The maximum thrust was measured by the load cell to be 36 N, which required a shaft
power of 638 W. This was calculated using the following equation from McCormick
(1994) and exceeded the required shaft power of 560 W.
Tstatic
3
2
2 = 3 2A
= 2Adisc (propeller Pshaf t )
disc Pthrust
Furthermore, a linear correlation was observed between the battery power and thrust as
shown in Figure 6.3. This satised the theoretical predictions and the manufacturers
data for the motor. Therefore, it was concluded that the motors performance was
suitable for use in the 2009 aircraft.
Discussion
CHAPTER 6. TESTING
104
Figure 6.3: Thrust vs Battery Power

Cavitation prevented the motor from meeting its maximum potential. This was overcome using a propeller with the same dimensions but thicker blades, which eectively
reduced the cavitation. The test results satised the theoretical predictions and the
manufacturers data for the motor. Therefore, it was concluded that the motors performance was suitable for use in the 2009 aircraft.
6.1.3
Communication Range Test
A communication range test was completed in order to verify the range of the autopilot
and to determine the eects of the video signal on the autopilot signal.
Method
A large open space was required to test the full range capabilites of the communication devices. Therefore, Accomodation Hill was selected as an ideal location as the
transmitters could be placed at the top of the hill and the receivers could be placed a
large distance away on the plains leading to the Riverland. This type of terrain was
chosen so there were no objects, such as trees or buildings, that would interfere with
the signals.
Firstly, the signal strength of the autopilot was measured at 1 km intervals up to a
maximum range of 10 km. This was determined for when the video downlink was o
and then when it was on.
Results
6.1. COMPONENT TESTING
105
The results of the test are depicted in Figure 6.4.
Figure 6.4: Autopilot signal strength

Discussion
When the video downlink was o, the autopilot signal strength reduced by 108 dBm
at 10 km. The signal however was suciently strong for communication, therefore
the minimum required range of 10 km was met. However, when the video downlink
and autopilot modems were transmitting simultaneously, the autopilot signal was lost
completely at 6 km. Furthermore, momentary breakouts were observed at distances
less than 6 km. This was a signicant concern as the reliability of the autopilot link
could not be guaranteed while streaming live video footage to the ground station.
This was a serious issue that was not solved in 2009 due limitations on time. However,
a number of possible solutions were proposed for future developments of the aircraft.
These are given in Section 8.2.
6.1.4
Imaging System Test
Once a nal working version of the Image Processing software had been completed, it
was necessary to perform several on ground tests to ensure the software was working
as required. In addition, it was neccessary to determine whether the aircraft camera
could detect IR light and eectively lter out visible light.
Method
1. Initial testing was performed using a laptop webcam, where a white, circular
piece of paper simulated the target for detection.
CHAPTER 6. TESTING
106
2. A second test was performed in order to test that the video feed from the aircraft
camera was correctly fed into the Image Processing system and that the camera
could detect IR light. The camera (with IR-Pass lter installed) was connected
to the Image Processing software via the composite-USB adapter. A small board
containing 750nm infrared LEDs was then used to simulate the ARCAA Outback
Challenge target, and moved at varying distances from the aircraft camera to
ensure dectection was still possible.
Results
As shown in Figure 6.5, the software successfully detected the paper target despite
the presence of many other white objects in the background. This conrmed the
eectiveness of the blob quality sorting algorithms.
The IR camera and processing software eectively detected and tracked the
LEDs.
Figure 6.5: Initial Testing of the Image Processing Software

Discussion
The imaging tests conrmed that the IR camera was capable of detecting IR light
and the image processsing could eectively detect and track user dened targets. The
imaging system was therefore ready for use in ight.
6.2. FLIGHT TESTING
6.1.5
107
The payload release mechanism is an integral part of the complete UAV system therefore it was necessary to test the payload release mechanism on the test aircraft before
the mechanism was attached to the UAV. Intially, a simple release mechanism composed of an elastic cord and servo was used in ight to determine its eectiveness. It
was also required to determine whether signicant damage was inicted on the bottle
upon impact with the ground. (Details of the test aircraft are given in Appendix E.)
Method
The aircraft was own to an altitude of approximately 50 m and the payload was
manually released. This test was performed twice.
Results
The payload successfully released on both occasions, though some binding of the
elastic cord was observed..
No damage inicted on bottle
Discussion
The bottle remained intact, which was promising for future tests. However, binding of
the release mechanism called for a more complex design, which is outlined in Section
4.8. The new release mechanism was tested on the actual UAV as outlined in Section
6.2.4.
6.2
Flight Testing
System tests were conducted once successful component tests were completed. It was
neccessary to independently test each system to validate its functionality, before integration with other systems.
6.2.1
Airframe Tests
Design Validation
A collection of simple ight tests were performed in order to observe the ight characteristics of the new wings and to verify their aerodynamic and mechanical design.
CHAPTER 6. TESTING
108
This test was also conducted in order to quantitatively determine the performance of
the new wings in terms of takeo distance and landing performance.
Method
1. Initial takeo was performed with no aps. The aircraft climbed to a safe altitude
where a number of circuits, including banks and turns, were performed. The
aircraft was then landed with no aps.
2. A number of takeos and landings were performed with the aps asserted to 25%,
60% and 100%.
Results
The aircraft demonstrated good cruise performance.
Relatively low take-o distances, which are depicted in 6.6.
Relatively low landing speeds resulted in very smooth landings.
!"#$%&&'()*+",-$'.*'/0"1'2%,&)345"+)%,'
,""# $%&'()
!"# $%&'()
*+#)$%&'(
"#)$%&'()
"
#!
#"
$!
$"
!"#$%&&'()*+",-$'678'
Figure 6.6: Takeo performance for various ap congurations

Discussion
Of particular signicance was the improvement in take-o distance over the 2007 aircraft, which achieved a take-o distance of 50 m. This was attributed to the reduced
weight of the aircraft and the decreased wing loading of the new wings. Furthermore,
although the landing speed was not recorded in 2007, a comparison of the 2007 and
2009 ight videos clearly indicated that the 2009 landing speed was signicantly less.
6.2. FLIGHT TESTING
109
Performance Tests
Performance testing was performed on the aircraft in order to obtain a quantitative
measure of the aircrafts ight characteristics, and compare the nished aircraft behaviour with design values.
The parameters of interest included:
Cruise, Takeo and Maximum speed
Motor Power
Roll rate
Minimum turn radius
Method
While a data logger was used to measure the aircrafts speed and motor power at
dierent stages of ight, alternative methods were required to measure the aircrafts
roll rate and minimum turn radius.
The maximum roll rate at cruise was determined by rolling the aircraft from 45 to
-45 and back again three times. The period of time taken to do this was recorded and
hence the roll rate could be calculated.
The minimum turn radius was determined by performing several circular paths at cruise
speed and measuring the time taken to perform the loops. Assuming constant airspeed
and a perfectly circular ight path, the circumference of the path was determined and
from this the turn radius.
Results
The results of the performance tests are shown in Table 6.1. It was intended that the
motor power be recorded at a number of dierent speeds. However, the data recorded
by the data logger was too noisy to be eectively interpreted.
Discussion
It was discovered that the aircrafts cruise and maximum speeds were less than the
desired speeds of 90 km/hr and 120 km/hr respectively. This appeared to be due
to drag induced by the landing gear, which was not accurately estimated during the
design. It was believed that the excessive drag could be reduced by implementing a
new landing gear, which would be integrated into the fuselage. This is further discussed
in Section 8.2.
CHAPTER 6. TESTING
110
Table 6.1: Aircraft Performance

Performance Parameter
Take-o speed
Cruise speed
Maximum speed
Maximum roll rate
Minimum turn radius
Measured Value
40 km/hr
70 km/hr
112 km/hr
81/s
36 m
The minimum turn radius required for search and rescue missions was approximately
100 m, which would be performed during the loiter pattern. The ight performance
tests demonstrated that the aircraft could achieve this with relative ease.
6.2.2
Autopilot Test
The autopilot was initially implemented in the test aircraft, which provided a platform
for proving the autopilots reliability without risking the actual UAV. Upon the successful completion of the test it was intended that the autopilot would be implemented
in the UAV. The aim was to tune the autopilots controller gains and acquire experience with the autopilots functionality in ight. The test was performed over an open
eld near Roseworthy.
Method
1. The autopilot output power was reduced to 100 mW, to prevent the autopilot
signal from inundating the RC receivers.
2. An on ground RC range test was performed with the autopilot modems on to
ensure the aircraft was safe to y.
3. Manual take-o was performed and upon reaching a safe altitude the autopilot
was switched to AUTO1 mode, such that the inner stability loops could be tuned.
4. Flying at cruise throttle, the proportional gains on the inner roll and pitch loops
were increased up to the point just before the aircraft began to oscillate. Only
modifying the proportional gains appeared adequate, therefore no modications
were made to the derivative gains. A number of throttle settings were asserted
and it was observed that this had little aect on the aircrafts stability. Therefore,
no further adjustments were made to the inner loop gains.
6.2. FLIGHT TESTING
111
5. Once the inner stability loops had been tuned, the autopilot was commanded
to perform a circular path in AUTO2 mode. Observation of the aircrafts ight
path indicated that there was signicant error between the aircrafts desired and
actual paths. As shown in gure 6.7, as the proportional gain was increased in
the navigation loop the steady state error was reduced. The actual ight path is
indicated in blue and the desired is indicated in green.
6. Once the autopilot was successfully tuned, the aircraft was commanded to perform a gure 8 pattern to demonstrate its autonomous capabilities.
Figure 6.7: Increasing proportional gain on navigation loop

Results
The autopilot successfully maintained the aircrafts stability, despite signicant wind
gusts. The aircraft was observed to respond quickly to disturbances and exhibited
minimal overshoot. The entire ight path of the aircraft during the test was plotted
in Google Earth as shown in gure 6.8. The actual path is indicated in red and the
desired path is indicated in green. (Note that for a large proportion of the ight, the
aircraft was performing patterns other than an gure 8, hence the existance of other
patterns in Figure 6.8.)
The error between the actual and desired paths was measured for both the clockwise
(Top loop) and counter clockwise loops (Bottom loop) as shown in table 6.2.
Table 6.2: Flight path error
Loop direction
Clockwise
Counter clockwise
Absolute Error (m)

+ 20
- 20
CHAPTER 6. TESTING
112
Figure 6.8: Figure 8 path performed autonomously

Discussion
Given the desired turn diameter was 200 m and that wind was present, an error of 20
m was considered to be reasonably accurate. It was noted however, that the aircrafts
actual turn radius was greater than the desired turn radius for clockwise loops and
the actual turn radius was less than the desired turn radius for counter clockwise
loops. This suggested that the aircrafts roll was not trimmed correctly and therefore
adjustments were made prior to the next ight.
Due to the successful completion of this test it was decided that the autopilot was
safe for use in the UAV. However, poor weather conditions and a number of faulty
components prevented the autopilot from being implmented in the UAV. It was believed
however, that given the work already completed on the autopilot, integration into the
UAV would be relatively simple. This is further discussed in Section 8.2.
6.2.3
Imaging System Test
Following successful ground testing of the Image Processing software, it was necessary
to ensure that the complete imaging system would perform as required in a ight
scenario.
Method
1. An RC range test was performed and it was found that the RC range was significantly reduced due to interference by the video signal. This prevented live video
footage from being sent to the ground station.
2. The aircraft camera was placed into the test aircraft and connected to a handheld
camcorder for recording the footage.
6.2. FLIGHT TESTING
113
3. The test aircraft was own at an altitude of 50m over a 3 watt infrared illuminator
placed on the ground
4. Several passes were performed over the emitter, and the aircraft was then landed
5. The video footage was retrieved from the aircraft, and input into the Image
Processing software
Results
The software was successfully able to detect and track the infrared emitter, with minimal adjustment needed to the detection and quality parameters. This proved that
the imaging system was capable of performing the requirements of the project. The
detected infrared emitter can be seen in Figure 6.9.
Figure 6.9: System testing of the Image Processing software, showing detection of a
3W infrared lamp
Discussion
Although the IR lamp was successfully detected, the test was performed at dask to
reduce the amount of sunlight reected o the ground (particularly from vegetated
surfaces). It was found that despite the use of a visible light cut lter, extreme lighting
conditions still over exposed the lens of the camera. This problem could be solved by
reducing the camera gains, however this setting is not available on the current camera.
This issue is further discussed in Section 8.2.
CHAPTER 6. TESTING
114
Another concern was the interference caused by the video downlink on the RC signal.
This was inconsistent with the results from the 2007 ight tests where no interference
was observed between the two signals. Restrictions on time prevented this problem
from being solved, however a number of possible solutions are proposed in Section 8.2.
6.2.4
Payload Deployment Test
The aim of this test was to test the eectiveness of the payload release mechanism
on the actual UAV. A manual release was performed as the autopilot was yet to be
successfully installed in the UAV.
Method
1. The aircraft was manually own to an altitude of approximately 50 m.
2. As the aircraft passed over the ground target the payload was released.
Results
The payload was instantly released and landed within 20 m of the target.
No evidence of binding
Payload undamaged on impact with ground
Release mechanism appeared to have detrimental eects on the aircrafts aerodynamics.
Discussion
The release mechanism itself was deemed a success, despite the detrimental eects on
the aircrafts aerodynamic performace. It was believed that this was due to the device
being located external to the fuselage and that when the payload release mechanism is
implemented into the fuselage as desired (see Section 8.2), this would no longer be an
issue.
Chapter 7
Management and Finances
7.1
Risk Management
Risk Management is an important aspect of any project, allowing for contingency

planning in the event of problems which may eect the outcome of the project. The
2009 iSOAR project was no exception, and a detailed risk assessment was undertaken
to identify the greatest areas of risk to the project, their likelihood, and what risk
controls could be put in place.
In addition to risks which aected the project outcomes, it was also necessary to identify
safety risks associated with the testing conducted during the project. Testing a 10kg
aircraft under remote control poses unique safety challenges, and so the project risk
assessment needed to take into account any risks to project members, private property,
and other persons. A Safe Operating Procedure (SOP) was created for each test, with
operators required to follow these safety procedures at all times.
7.2
7.2.1
Project Management
Management Delegation
The project group consisted of four students, each of whom was given a managementrelated role outside of their individual project tasks. These roles are outlined below:
Technical Manager Primarily responsible for solving design, manufacturing, and
system integration issues, the technical manager was at the top of the management
115
CHAPTER 7. MANAGEMENT AND FINANCES
116
heirachy and was responsible for having the nal word on decisions relating to the
design of the aircraft systems.
Business Manager The business manager was responsible for administrative tasks
associated with the project. These included obtaining sponsorship funding, keeping
nancial records and maintaining the project budget, and updating the project schedule. The business manager was also responsible for external communications and for
the keeping of meeting minutes.
Testing Manager The testing manager was responsible for all aspects of testing,
including the writing of test procedures for each test, ensuring correct appropriate
experimental process was followed, and recording all results.
Safety Manager Flight testing of a UAV can post signicant safety risks, and the
safety manager was responsible for ensuring all Safe Operating Procedures were followed during testing. The Safety Manager was also required to compile the risk assessment documentation associated with each test.
The schematic of the management hierachy can be seen in 7.1.
"#$%&'$()!
*(&(+#,
-./'&#//!
*(&(+#,
"#/0'&+!
*(&(+#,
1(2#03!
*(&(+#,
Figure 7.1: Management Structure
7.2.2
Communication
Eective communication between team members is essential to the success of any

project. Group meetings with the project supervisor were held weekly, and the project
group worked together as much as possible, aiding in internal communication.
Many dierent technologies were used in order to aid communication throughout the
project. In addition to standard email, SMS and online chat services, the group made
use of an online program called Dropbox, an automatic backup and syncing software.
A shared folder was created to host les used by the project, with any les modied by
7.3. FINANCIAL MANAGEMENT
117
group members instantly updated online, and the changes pushed to other members
in the group.
7.3
Financial Management
At the beginning of the project, a Bill of Materials was written to list the value of all
current materials, estimate the cost of project objectives, and to create the required
budget. This inluded the costs of raw materials, labour, tooling, testing, and travel to
the ARCAA 2009 Outback Challenge. A copy of the Bill of Materials can be seen in
Appendix G.
The primary method of funding was through sponsorship, obtained from various businesses whom were willing to help with monetary assistance or in-kind support. Due
to the current economic climate, it was envisaged that not a great deal of sponsorship
money would be gained. As a result the budget of the project was minimal, and it was
intended that the vehicle would be manufactured as economically as possible. Table
7.1 gives a breakdown of the funds spent throughout the project.
Table 7.1: Breakdown of Finances
Item
Cost from Budget In-kind Support
Airframe modications
$700
Imaging System
$150
Autopilot Hardware
$800
-
7.4
Time Management
In order to dene acceptable time constraints for each task associated with the project,
internal and external deadlines were imposed and milestones were specied. These were
then broken down into smaller tasks which made their completion more manageable.
This allowed for a clear analysis and breakdown of the project time line and was
important in ensuring that adequate time was assigned to each task. Some of the
major project milestones are listed in Table 7.2.
There were several deadlines specied externally by the School of Mechanical Engineering. Within these milestones and deadlines, internal milestones were also made
to ensure progress of the project. These were set at weekly meetings and managed
through Gantt charts. Progress was also monitored using these Gantt charts, which
can be viewed in Figures F.1 and F.2.
CHAPTER 7. MANAGEMENT AND FINANCES
118
Table 7.2: Major Milestones

Milestone
Project Denition, Specication and Contract
Preliminary Report
Seminar Presentation
Draft Final Report
Project Exhibition
Final Report
Deadline
20/03/09
22/05/09
22/09/09
09/10/09
22/10/09
30/10/09
Each member of the group recorded the number of hours spent on the project each
month. A bar chart showing the hours spent for each month of the project can be seen
in Figure 7.2.
&'"()*$+,"'-+."/'0+12+!"#$%
0'1%
(),./%
*+,-#
!"#$%
()$%
!"&'%
!"#$%
*">"?:%
<'+:'=1',%
9.:;1',%
2
322
422
522
622
3"$45+."/'0
Figure 7.2: Number of work hours per month
722
822
Chapter 8
Conclusion
The aim of the 2009 project was to design, manufacture and test a xed-wing UAV
capable of performing a variety of civil or commercial tasks. Particular emphasis was
placed on the search and rescue capabilites of the aircraft for potential entrance into the
2009 ARCAA UAV Outback Challenge. Using the experience obtained from the 2007
project, the 2009 team made signicant improvements to the aircrafts aerodynamic
performance, payload deployment and level of autonomy. In addition, autonomous
target detection via image processing was integrated into the design.
8.1
Project Goals
The original project goals were analysed to determine, which had been achieved and
to what extent. This provided a measure of the projects success as a whole.
Primary Goals
1. Design and manufacture a new pair of wings with improved performance over the 2007 iSOAR aircraft.
A new pair of wings were designed and manufactured with an increased wing area
and aspect ratio (increases of 43% and 25% respectively). Furthermore, aps were
introduced into the design in an eort to improve landing performance. Although
neither the landing speed nor distance were recorded in 2007, from comparison
of the 2007 and 2009 ight videos, the 2009 landing speed was signicantly less.
The take-o distance was reduced from 50 m to 10 m and the aircraft was also
observed to have good cruise performance. This goal was successfully met.
119
CHAPTER 8. CONCLUSION
120
2. Design and implement a reliable payload deployment device capable of

delivering a 500 mL bottle of water to within 100 m of a specied
target.
A payload deployment device was designed, manufactured and tted to the aircraft. A 500 mL bottle of water was successfully deployed from the aircraft and
landed within 100 m of the target. No damage was experienced by the bottle
upon landing. This goal was successfully met.
3. Implement an autopilot system capable of controlling the UAV outside
of visible range. The desired level of autonomy includes maintaining
straight and level ight, negotiating turns, and changes in altitude.
The Paparazzi autopilot system was installed in the test aircraft. The aircraft
performed a number of altitude changes, circular paths and gure 8 paths under complete autonomous control. It was observed to provide good disturbance
rejection and accurate path following. On ground range tests were performed
on the autopilot modems, which demonstrated that they would be capable of
maintaining communication between the UAV and the ground station for over
10 km; well outside visible range. This goal was therefore achieved.
4. Develop software capable of detecting and tracking an object (representing a person) from the aircraft camera feed and communicating
its location with the aircraft. The aircraft should use this location to
drop the payload previously described.
Image processing software was implemented at the ground station and successfully detected and tracked a 3W infrared lamp (simulating a persons heat signature) from an altitude of 50m. The software also determined the GPS coordinates
of the detected target, which could be used to drop the payload with reasonable
accuracy. This goal was successfully met.
Extension Goals
1. Meet the minimum requirements for participation in the ARCAA 2009
UAV Challenge Outback Rescue.
The aircraft was developed to meet the minimum requirements for entrance into
the Outback Challenge. However, these capabilities were not realised until after
the 2009 competition. It is the intention of the team to enter the aircraft in the
2010 Outback Challenge. This goal was not entirely met.
8.1. PROJECT GOALS
121
2. Reduce the takeo weight of the UAV to 9 kg or less.

It was realised in the early stages of the project that for such a goal to be met, a
new fuselage would have to be manufactured. Limitations on time and available
resources prevented this from happening in 2009. The weight was reduced from
10.8 kg to 9.1 kg however, through a reduction in wing weight and the number
of on board batteries. This extended goal was not entirely met.
3. Develop a system capable of determining the GPS coordinates within
100 m of a specied target, from the video footage streamed from the
UAV.
As previously described, the image processing software was capable of determining the GPS coordinates of the target present in the imagery. This system was
simulated in software and it was found that the accuracy was well within 100 m.
This extended goal was met.
4. Improve the quality of the video system, such that it is possible to
identify a human from cruise altitude.
The target of the ARCAA Outback Challenge consisted of a dummy and a 50
W, 850 nm IR lamp. A standard security camera, incorporating a visible light
cut lter, was installed in the aircraft in an eort to detect the IR lamp. Given
that the camera was demonstrated to be capable of detecting a 3 W IR lamp
from an altitude of 50 m (164 ft), it was assumed that a 50 W IR lamp could be
detected from the cruise altitude of 300 ft. The IR camera provided a signicant
advantage over the visual camera used in the 2007 iSOAR aircraft. Therefore,
this extended goal was successfully met.
5. Design and implement an emergency recovery system, with the primary goal of ensuring safety to people on the ground and secondary
goal of minimising damage to the UAV.
It was determined that a parachute diameter of 3.46 m was required for a landing
speed of 5 m/s and that the estimated weight of the parachute (1.54 kg) would be
too heavy for the aircraft. Instead, a ight termination system was implemented
such that in the event of component failure, the UAV would be sent into a nose
dive and deliberately crashed. The intention was to prevent it from drifting into
a populated area, where it could cause possible injury to people on the ground.
This extended goal was partially met.
122
8.2
Future Work and Recommendations
A number of recommendations were made for the future development of the aircraft,
in order to address issues which were not resolved in 2009 due to resource and time
constraints. It is believed that successful implentation of these reccomendations would
signicantly improve the overall design of the aircraft.
Autopilot
Although the Paparazzi autopilot was successfully implemented in the test aircraft,
technical diculties with the GPS and undesirable weather conditions prevented testing
in the completed UAV. It is expected that transferring the working autopilot from the
test aircraft to the UAV will not pose signicant problems, and that the UAV would
exhibit similar performace to the test aircraft.
Landing Gear
The integration of a new landing gear into the fuselage was proposed during the early
stages of the project. This never eventuated, due to the prioritisation of other essential
tasks. A redesigned landing gear system would allow the 500 mL bottle of water to
be contained within the aircrafts fuselage, signicantly reducing drag, and would also
allow for a modular payload system, whereby the bottle could be easily exchanged
for other types of payloads. This would further develop the aircrafts multi-purpose
capabilities.
Fuselage
Manufacturing a new fuselage would signicantly reduce the overall weight of the UAV.
The 2007 team indicated that re-manufacture of the aircraft fuselage would take approximately a week of full time work, given that the fuselage moulds have already been
manufactured. The fuselage weight was signicantly increased in 2007 after repairs
were made following a crash. Therefore, it was believed that the fuselage weight could
be reduced from its current weight of 2.9 kg to less than 2 kg, through more ecient
manufacturing techniques and removal of repair sections.
8.2. FUTURE WORK AND RECOMMENDATIONS
123
Video Downlink
It was discovered during the 2009 project that the video downlink for the aircraft
camera signicantly reduced the range of both the manual RC and autopilot communication links. This posed a signicant issue, as the project team did not wish to risk
a crash due to viewing live video on the ground station.
A number of potential solutions were proposed and are indicated below.
The purchase of a single digital datalink with sucient bandwidth to accomodate
both the video and autopilot data/command streams. This could consist of a
satellite-based internet system, or a point-to-point microwave link. Devices such
as these are generally used by the military and would be relatively expensive.
Transmit the video footage in a dierent frequency band (currently, the autopilot,
RC transmitter and video use the 2.4 GHz band). This was proposed by Micropilot as a possible solution, however the 2009 project group recommend that prior
to purchasing a new downlink, further investigations be made to conrm whether
frequency is actually the issue. This is because the autopilot and RC systems
use FHSS and DSSS modulation respectively, which are supposed to reduce the
eects of narrowband interference.
Perform on board image processing. Thus, when the target is detected a still
image is sent to the ground station for verication. Such a system would require
signicant software and hardware development, though it is believed to be within
the capabilities of the project group. However, this would preclude use of the
aircraft for any purpose requiring a live video feed, such as surveillance, trac
monitoring, or shark spotting.
Use of a directional video link in order to reduce interferance between the video
transmitter and the autopilot modem. This method could be combined with use
of a dierent video datalink frequency in order to maximise eectiveness.
The communication issues prevented all the systems from being integrated in the UAV
at once. Therefore, it is recommended that once this problem is solved a full system
integration test be performed. The reliability of the system should be ensured prior to
ight, as a crash could result in a total loss of the aircraft and on board components.
124
Imaging Systems
The budget constraints of the project necessitated a relatively inexpensive camera be

purchased, which had the potential to impact on the goals of the imaging system. It was
discovered that the camera worked well and without any signicant reliability issues.
However, even with the IR-Pass lter placed over the camera CCD sensor, imagery
obtained during daylight hours had a tendency to be overexposed - particularly over
grassed areas. This overexposure made it impossible to detect any white objects placed
in grassed areas, and would be a signicant issue at the ARCAA Outback Challenge.
In order to solve the problem it was necessary to reduce the gains on the camera
sensor, however the inexpensive nature of the purchased camera did not allow sucient
resolution in manual gain control, preventing the issue from being solved completely.
A higher quality camera would allow this problem to be xed.
Additionally, more expensive security cameras incorporate mechanically movable IRCut lters in order to allow for better colour resolution during daylight hours (by
ltering out infrared light) while still allowing for night-time vision (by moving the
lter to allow infrared light into the camera). Purchase of a similar camera, and
replacement of the IR-Cut lter with an IR-Pass lter, would allow for the camera to
be used for both visual and infrared imagery, with switching controlled by the aircraft
autopilot.
ARCAA Outback Challenge
The 2009 team intend to enter the aircraft into the 2010 Outback Challenge. Given
the challenging nature of the competition, the majority of competitor aircrafts crashed
in 2009. This is believed to be due to minimal testing on their part. It is therefore
recommended that the aircraft be tested in a similar scenario prior to entrance into
the 2010 competition. It is believed that this will provide a signicant advantage over
other teams.
Bibliography
Abbot I & Von-Doenho A, 1959. Theory of Wing Sections
Andren C, 1997. A Comparison of Frequency Hopping and Direct Sequence Spread
Spectrum Modulation for IEEE 802.11 Applications at 2.4 GHz
URL http://www.odessaoffice.com/wireless/fh_vs_ds.pdf
ARCAA, 2009. UAV Challenge Outback Rescue
URL http://www.uavoutbackchallenge.com.au/uavoutbackchallenge/
Avalakki N, Bannister J, Chartier B, Downie T, Gibson B, Gottwald C, Moncrie P &
Williams M, 2007. Design, Development and Manufacture of a Search and Rescue
Unmanned Aerial Vehicle. Technical report, The University of Adelaide School of
Mechanical Engineering
Barry J, Messerchmitt D & Lee E, 2003. Digital Communication
URL http://cnx.org/content/m0074/latest/
Bradski G, 2008. Learning OpenCV: Computer Vision with the OpenCV Library
Brohm J, 2004. The Mathematics of Flat Parachutes
Chen W & Lui E M, 2005. Handbook of Structural Engineering
Chiou J, Zheng Q & Chung D, 1989. Electromagnetic Interference Shielding by Carbon
Fibre Reinforced Concrete. 20:379
CNet, 2007. Where ScanEagle Drones Dare
URL http://news.cnet.com/2300-11397_3-6194563-1.html
Corporation A, 2009. Aerosonde Mark 4.4 Series: Strength and Flexibility. Technical
report
Curry J, Maslanik J, Holland G & Pinto J, 2004. Applications of Aerosondes in the
Arctic. American Meteorlogical Society, pages 18551861
URL http://curry.eas.gatech.edu/currydoc/Curry_BAMS85A.pdf
125
BIBLIOGRAPHY
126
Deagel, 2003. Silver Fox
URL http://www.deagel.com/Tactical-Unmanned-Air-Vehicles/Silver-Fox_
a000171001.aspx
Decker J, 2002. Monkeytumble.com
URL www.monkeytumble.com
Gerdan G, Coombe L & Takac F, 1995. The Eects of RF Interference, Multipath
and Signal Obstruction on the GPS Observables. Technical report, Department of
Land Information RMIT, Melbourne
Hazeldene A & Price A, 2005. Real Time Unnatural Object Detection for Real Time
Unnatural Object Detection for an In-Flight UAV. In AIAC-11 Eleventh Australian
International Aerospace Congress,
Huckins III E, 1970. Techniques for Selection and Analysis of Parachute Deployment
Systems. Technical report, Langley Research Center
IAI, 2002. IAI - Unmanned Air Vechicles
URL http://www.iai.co.il/18892-en/default.aspx
Insitu, 2009. ScanEagle Unmanned Aircraft System
URL http://www.insitu.com/scaneagle
Johnson P, 2007. Aireld Models
URL www.airfieldmodels.com
Kennedy G, 1984. Electronic Communication Systems. 3
Knacke T, 1992. Parachute Recovery Systems Design Manual
Kruegle H, 1996. CCTV Surveillance: Video Practices and Technology
Maxim, 2003. An Introduction to Direct-Sequence Spread Spectrum Communications
URL http://infocom.uniroma1.it/alef/com_el/DSSS.pdf
McCormick B, 1994. Aerodynamics, Aeronautics and Flight Mechanics
MicroPilot, 2007. MicroPilot Autopilot Installation and Operation
Model Motors, 2009. Model Motors Product Specications
URL http://www.modelmotors.cz/index.php
ModelFlight, 2009. 2.4 GHz DSM Receivers
URL http://www.modelflight.com.au/radio_control_dsm_receivers.htm
BIBLIOGRAPHY
127
Norut, 2008. CryoWing Applications

URL http://uas.norut.no/UAV_Remote_Sensing/Applications.html
ONR, 2004. Silver Fox
URL http://www.onr.navy.mil/media/extra/fact_sheets/silver_fox.pdf
Paparazzi, 2009. Paparazzi
URL http://paparazzi.enac.fr/wiki/Main_Page
Peer P, Batagelj B & Solina F, 2002. Using Computer Vision in Security Applications.
Masters thesis, University of Ljubljana, Faculty of Computer and Information Science
Raymer D, 2006. Aircraft Design: A Conceptual Approach Fourth Edition
Sadaghiani K, 2007. Piccolo Equipped Silver Fox UAV Flies in the Philippines for the
31st MEU
URL http://www.cloudcaptech.com/whatsnew.shtm#manta
Sarris Z, 2001. Survey of UAV Applications in Civil Markets. Technical report,
Technical University of Crete, Crete
Simons M, 2002. Model Aircraft Aerodynamics Fourth Edition
Wollan H, 2004. Incorporating Heuristically Generated Search Patterns in Search and
Rescue. Technical report, The University of Edinburgh, United Kingdom
Appendix A
Airfoil Comparison
Presented in this section is airfoil data produced by XFLR5 which is based on the
popular X-Foil. Plots of Cl on CD were produced for a range of Renolds numbers
between 100000 and 600000 which is greater than the scope of the ight envelope of
the aircraft. The best performance criteria for choosing an airfoil is based on having
the lowest CD while spanning the Cl over the full Renolds number range.
The polar plots in Figures A.1 to A.6 below show that at low Renolds numbers the
only airfoils which have good performance throughout the full range of Cl are the SD
series. At higher values of Re the other airfoils provide low values of CD , but the SD
series of aerfoils still perform better over the full Cl range.
For these reasons, it was decided that the SD7032 airfoil was the best candidate for
use on the 2009 aircraft.
i
APPENDIX A. AIRFOIL COMPARISON
ii
!"#$%&!#"'&(")*$%+,"-&. /0&1&2334333
!"$#
!"##
(#
%&'("#)!(
%&'("#)!$
#"$#
%&'("$)!(
./0/'+(#!+
123#(+
#"##
123#(3
*#"$#
#"##
#"#!
#"#+
#"#(
#"#,
#"#$
#"#-
(5
Figure A.1: Polar plot comparison of airfoils for Re = 100,000
!"#$%&!#"'&(")*$%+,"-&. /0&1&2334333
!"$#
!"##
(#
%&'("#)!(
%&'("#)!$
#"$#
%&'("$)!(
./0/'+(#!+
123#(+
#"##
123#(3
*#"$#
#"##
#"#!
#"#+
#"#(
#"#,
#"#$
#"#-
(5
iii
!"#$%&!#"'&(")*$%+,"-&. /0&1&2334333
!"$#
!"##
(#
%&'("#)!(
%&'("#)!$
#"$#
%&'("$)!(
./0/'+(#!+
123#(+
#"##
123#(3
*#"$#
#"##
#"#!
#"#+
#"#(
#"#,
#"#$
#"#-
(5
!"#$%&!#"'&(")*$%+,"-&&. /0&1&2334333
!"$#
!"##
(#
%&'("#)!(
%&'("#)!$
#"$#
%&'("$)!(
./0/'+(#!+
123#(+
#"##
123#(3
*#"$#
#"##
#"#!
#"#+
#"#(
#"#,
#"#$
#"#-
(5
APPENDIX A. AIRFOIL COMPARISON
iv
!"#$%&!#"'&(")*$%+,"-&. /0&1&2334333
!"$#
!"##
(#
%&'("#)!(
%&'("#)!$
#"$#
%&'("$)!(
./0/'+(#!+
123#(+
#"##
123#(3
*#"$#
#"##
#"#!
#"#+
#"#(
#"#,
#"#$
#"#-
(5
!"#$%&!#"'&(")*$%+,"-&. /0&1&2334333
!"$#
!"##
(#
%&'("#)!(
%&'("#)!$
#"$#
%&'("$)!(
./0/'+(#!+
123#(+
#"##
123#(3
*#"$#
#"##
#"#!
#"#+
#"#(
#"#,
#"#$
#"#-
(5
Appendix B
Matching Diagram Verication
Included in this Appendix are hand-calculated verications of all performance requirements used for the aircraft preliminary sizing. These requirements were then used to
construct a matching diagram for the aircraft, allowing a design point to be selected.
B.1
Take O Distance Verication
kg
= 1.1673 m3 , e = 0.73, A = 11, = 0.7, = 0.055, CLmax = 1.2, CD0 = 0.22,
CLT 0 =
1.2
= 0.99
1.21
1
11 0.73
= 0.03964
k=
B.1.1
Verication point 1
From interpolated data for 50m Takeo:

W
S
kg
N
= 10 m2 = 98 m2 ,
W
P
kg
N
= 33.5 kW = 0.3286 W
W
P
= 3.04
W
N
v
(B.1)
APPENDIX B. MATCHING DIAGRAM VERIFICATION
vi
2 98
1.1673 0.99
= 13.02ms1
VLOF =
2P
kT =
V W
0.7 2
=
3.04 0.055
13.02
= 0.17614
kA =

2
W CD0 KCL + CL
2 S
1.1673
=
0.22 0.03964 0.992 + 0.055 0.99
2 98
= 3.8123 105
Sg =
1
2 9.81 (3.8123 105
ln
0.17614 + (3.8123 105 ) 13.022

0.17615
= 50.05m
Which is very close to 50m therefore veried
B.1.2
Verication point 2
kg
= 1.1673 m3 , e = 0.73, A = 11, = 0.7, = 0.055, CLmax = 1.2, CD0 = 0.22
From interpolated data for 50m Takeo:

W
S
kg
N
= 15 m2 = 147 m2 ,
W
P
kg
N
= 19.5 kW = 0.1913 W
W
P
= 5.23
W
N
(B.2)
B.2. CLIMB PERFORMANCE VERIFICATION
vii
2 147
1.1673 0.99
= 15.94ms1
VLOF =
2P
kT =
V W
0.7 2
=
5.23 0.055
15.94
= 0.2698
kA =

2
W CD0 KCL + CL
2 S
1.1673
=
0.22 0.03964 0.992 + 0.055 0.99
2 147
= 2.5415 105
Sg =
1
2 9.81 (2.5415 105
ln
0.2698 + (2.5415 105 ) 15.942

0.17615
= 48.6m
Which is very close to 50m therefore veried
B.2
Climb Performance Verication
for Vs = 15ms1 V = 19.5ms1
1
1.1673 19.52
2
= 221.9
q=
APPENDIX B. MATCHING DIAGRAM VERIFICATION
viii
1
W
= 1.1673 152 1.2
S
2
N
= 157.6 2
m
cos(0.12)
1
221.9 0.022 + 0.03959 157.6
157.6
221.9
19.5
1
=
sin (1.2) +
221.9 0.0417019
0.7
157.6
W
= 4.8964
N
kg
= 20.96
kW
P
19.5
=
W
0.7
B.3
for
W
S
sin (1.2) +
Cruise Performance Verication

kg
kg
N
= 16 m2 = 156.96 m2 and V = 90 km where = 1.1117 m3 (h=1.0km)
h
1
q = 1.11178
2
90
3.6
= 347.4
90
347.4 0.022 156.96 0.03959

P
36
=
+
W
0.7
156.95
347.4
W
= 2.3778
N
W
kg
= 42.87 2
P
m
Appendix C
Tailplane Sizing Calculations
The following analysis was undertaken in order to conrm that the existing empenage
(taken from the 2007 iSOAR aircraft) would be suitable for the larger wings of the new
aircraft. A simple analysis was completed by comparing real world aircraft in the form
presented by Raymer (2006).
CV T bSW
LV T
(C.1)
CHT C W SW
LHT
(C.2)
SV T =
SHT =
SV T is the vertical tailplane area,

SHT is the horizontal tailplane area,
CHT is the horizonal tail volume coecient,
CV T is the vertical tail volume coecient,
C W is the average wing chord length,
LV T is the vertical tail moment arm,
LHT is the Horizontal tail moment arm,
SW is the wing planform area,
From Current Design Fuselage and surfaces:
ix
APPENDIX C. TAILPLANE SIZING CALCULATIONS
LHT = LV T = 0.975m
From new design with 2.49m wing span (Vs = 15.5m/s):
b = 2.49m
C W = 0.250m
SW = 0.6225m2
From Table 6.4 in raymer for a sailplane (high aspect ratio, High eciency):
CV T = 0.02
CHT = 0.5
Substituting values into equation (C.1) for the vertical tail:
SV T =
0.02 2.49 0.6225

0.975
SV T = 0.0318m2
Now Substituting values into equation (C.2) for the horizontal tail:
SHT =
0.5 0.25 0.6225

0.975
SHT = .0798m2
(C.3)
Appendix D
Spar Stress Calculations
The spar was modelled as a composite beam
Normal strains due to bending
y
x = = y
(D.1)
neautral axis calculations

k=n
Ek
k=1
=0
(D.2)
ydy = 0
(D.3)
yk dAk
for beam made of rectangular sections:

k=n
k=1
Ek bk
y
k
yk1
Moment curvature relationship
M=
k=n
Ek Ik
k1
(D.4)
Normal stress due to bending

M Ek (y)k
(x )k = k=n
Ek Ik
k=1
xi
(D.5)
APPENDIX D. SPAR STRESS CALCULATIONS
xii
Figure D.1: Spar Dimensions

Due to symmetry around the neutral axis as shown in gure D.1 above, the carbon
spar caps are calculated together.
Ic = 4
1
(b2 ) (h2 )
(b2 ) (h2 )3 +
36
2
Is =
2h2
3
+ h1
2
(D.6)
1
(b1 ) (h1 )3
12
(D.7)
Inserting the above into equation (D.5) gives:

x =
4Ec
1
36
(b2 ) (h2 ) +
M Ec (y)
2h
(b2 )(h2 )
2
2 +h
(D.8)
+
1
E
12 s
(b1 ) (h1 )
Appendix E
Test Procedures
This appendix provides additional details regarding the test aircraft, component testing
and ight test procedures used in this project.
E.1
Test aircraft
A test aircraft was used for an number of ight tests and is depicted in Figure E.1.
Figure E.1: Test Aircraft

The specications for this aircraft are listed below:
Wing Span:58 in (1475mm)
Overall Length:37 in (940mm)
xiii
APPENDIX E. TEST PROCEDURES
xiv
Wing Area:525 sq in (33.7 sq dm)
Flying Weight:40 - 45 oz (1135 - 1275 g)

Motor Size:15-size brushless outrunner (installed)
Wing Loading:12 oz/sq ft
Prop Size:11 x 8 electric (included)
Speed Control :30A Brushless Pro SB Brushless ESC (EFLA1030)(included)
E.2
Component Testing
E.2.1
Static Wing Loading
Description
The aim of this test is to determine whether the wings are able to withstand the loads
induced during ight and to determine if the control surfaces are fully operational at
maximum aerodynamic load.
Test Procedure
1. Weigh UAV minus wings and calculate maximum load using a load factor of 3.8.
2. Test to 30% of max load for 30s. 1 person load left wing, 1 person load right
wing, 1 person observe any signs of failure and 1 person record deection at wing
tips.
3. Divide wings into 5 sections ensuring that the tip section is not included as no
load is to be placed here.
4. Load wings from root to last section, and distribute evenly across chord as per
the calculated distribution.
5. Check the movement of the control surfaces and check for full range of motion.
6. Listen for noises, there should be none.
7. Remove load in the opposite order to which it was loaded.
8. Once load has been removed observe surface for any sign of failure.
9. Test to 50% and 80% for 30s and 100% of max load for at most 5 seconds only.
E.2. COMPONENT TESTING
E.2.2
xv
Motor Verication
Description
This test was conducted in order to determine the suitability of the existing motor
to this project. In order to verify the current motor, a series of small, static motor
test was performed. These motor tests accessed the performance of the motor, as
to see if the motor performed as to the manufacturers specications and that the
motors performance had not been aected by fatigue. The motor was also testing
using dierent propellers types, these had dierent pitch, diameters and material.
Test Procedure
1. Install all devices as per the motor installation table.
2. Make sure the lab door is completely shut, and you place yourself in the control
room of the lab room.
3. Release the emergency stop button and turn on the power pack.
4. Make sure readings can be read from the multimeters.
5. Turn on the transmitter, and check that the signal is received by the transmitter.
6. Slowly increase the throttle to half of one increment on the transmitter. Ensure
that the appropriate multimeter reads the correct voltage. Record all values.
Increase the throttle to the rst increment and record all values. Repeat this
process for each half increment up to full throttle.
7. Decrease the throttle to minimum, press the emergency stop switch and turn o
the power pack.
8. Change the propeller and repeat the process above, ensure that the installation
checklist is followed again.
9. Finally repeat the process again with the remaining propeller.
xvi
E.2.3
Preliminary communication eld tests
Preliminary Communication Field Test I

Description
The rst preliminary test was performed at the Adelaide Soaring Club, due to its large
open space and minimal external noise. During the test, all devices were installed
in the UAV, except the imaging system, as this was not installed in 2007 when the
communication issue arose. Of primary concern was the eect of the carbon bre
hatch and autopilot modem, therefore a number of congurations were proposed with
respect to these devices including:
1. Fibreglass hatch on, autopilot and modem o.
2. Carbon bre hatch on, autopilot and modem o.
3. Fibreglass hatch on, autopilot and modem on.
4. Carbon bre hatch on, autopilot and modem on.
For each of these congurations and at dierent orientations, the RC signal strength
was determined. Note that the DX7 Spektrum RC system was used and this system
utilises dual receivers. The primary RC receiver was positioned vertically and the
satellite RC receiver horizontally.
Method
1. RC range tests were performed, with and without the attenuator on as shown
in Figure E.2. This was to ensure the transmitter was functioning correctly,
therefore all other devices were o.
2. All devices were installed in the UAV in accordance with conguration 1.
3. The transmitter was placed in a vertical position approximately 1 m above ground
level, 550 m away from the UAV.
4. The orientation of the UAV was varied at 45 intervals in roll and yaw and
the RC signal strength was determined at each orientation. Signal strength was
determined by the status of the LEDs on the receivers.
5. The above procedure was repeated for the remaining congurations.
xvii
Figure E.2: RC range test

Results
The following results were attained:
The RC signal was maintained beyond 70 paces with the attenuator on. This
exceeded 30 paces, the required distance for full range use.
The RC signal was maintained up to 610 m without the attenuator on. This was
beyond visual recognition, which appeared sucient.
RC signal strength was consistently reduced when the tail was directed toward
the transmitter. Most likely due to the fact that at this orientation, the signal
has to penetrate through a greater quantity of materials.
Signicant reductions in RC signal strength were more common across all orientations, when the autopilot and modem were on. It was not distinguished however
whether this was due to noise from the autopilot circuitry or inundation of the
reciever by the modem.
The carbon bre hatch appeared to have no signicant eect.
Recommendations
Further testing was required to:
Distinguish whether the RC signal loss was the result of noise from the autopilot
circuitry or inundation by the autopilot modem.
xviii
Attempt to optimise the receiver positioning to reduce the risk of signal shadowing.
Preliminary communication eld test II
Description
A second preliminary eld test was performed in Adelaide and was designed in accordance with the recommendations of the previous test. The RC signal strength was
determined for the following congurations.
1. Autopilot on, autopilot modem on
2. Autopilot on, autopilot modem o
3. Same as conguration 2, however the secondary RC receiver was placed on the
tail of the UAV as indicated in Figure 4.19.
During the second prelimiary test the UAV was supported by a stand, which could be
modied to suit a number of dierent orietations, as shown in Figure E.3.
Figure E.3: UAV supported by stand

Method
1. A range test was performed with the attenuator on. This was to ensure the
transmitter was functioning correctly and to determine if external noise was an
issue considering the new location.
xix
2. The signal strength tests were performed using the same method as that in the
rst preliminary test, however in this case the new congurations were utilised.
Results
The following results were attained:
The RC signal was maintained beyond the minimum required distance of 30 paces
with the attenuator on.
Signicant reductions in RC signal strength were experienced across all orientations when the modem was on. Minimal reductions were experienced when the
modem was o. This suggested that receiver inundation was the primary cause
of interference.
Regardless of whether the modem was on or not a consistent signal loss was
experienced when the tail of the UAV was directed toward the transmitter. This
however did not occur when the secondary receiver position was altered.
Recommendations
The issue of signal shadowing appeared to have been solved, however the issue of
receiver inundation still required a solution.
E.2.4
Communication Long Range Verication
Description
The video downlink and autopilot are required to transmit over a distance of at least
10km in order to be eective throughout the entire mission. The aim of this test is to
determine whether the video downlink and autopilot modems can transmit up to 10km
and to determine whether interference occurs between the two signals. It is important
to conduct this test at a place where the terrain is at and a road can be followed for at
least 15 kilometers without signicant inteference from objects such as large buildings
and groups of trees. The location chosen was Accomodation Hill as shown in Figure
E.4.
Test Procedure
1. Place camera and downlink, and autopilot and modem at top of hill.
xx
Figure E.4: Accomodation Hill

2. Set-up imaging and autopilot ground station 1 km away on the at stretch of
land.
3. Turn on autopilot modem.
4. Record AP modem signal strength from LEDs (RSSI 1,2&3) on modem.
5. Turn on video downlink, record AP modem signal strength again.
6. Steps 4 and 5 are to be repeated at 1 km intervals up to 10 km.
E.3
E.3.1
Flight testing
Proof of aerodynamic and mechanical design
Description
The aim of this test is to demonstrate the eectiveness of the newly designed and manufactured wings. The UAVs stability, control and manoeuvrability will be observed
during take-o, climb, level ight, bank, descent and landing. In addition, the eectiveness of the aps and the ability of the elevator to counteract the resulting moment
E.3. FLIGHT TESTING
xxi
will be determined. Note: Use timer to measure length of time engine and electronics
operational. Use four batteries, though other four batteries to remain in aircraft for
stability. If uncertain use model aircraft rst to determine whether the wind is suitable
for ight.
Pre-flight checklist
The following was ensured prior to ight.
The correct batteries are used for all devices with regard to voltage, current,
capacity and type.
The batteries are connected to same device and have the same ratings.
The batteries are connected with correct polarity.
All servo leads are connected to the correct output of the receiver.
All devices within UAV securely mounted inside the fuselage.
Wings are securely tted to aircraft and securely mounted to fuselage.
The landing gear is correctly attached to the fuselage of the aircraft.
The wheels turn freely on the landing gear xture.
The motor is securely mounted in the nose of the aircraft.
The propeller securely mounted to the motor shaft.
Ensure RC range is sucient
Test motor and all control surfaces to see if operating correctly.
Test Procedure
1. Increase throttle for initial ground roll and observe aircraft dynamics.
2. Perform a taxi test over a short distance to ensure the motor is functioning
correctly.
3. Flight 1 - Take-o, bank right and complete one full circuit, then land.
4. Flight 2 Assert aps at 5%, 10% & 15% and determine if elevator can compensate to maintain level ight.
5. Flight 3 - Assert aps to 20%, 60% and 100% to determine if elevator can compensate to maintain level ight.
xxii
E.3.2
Flight performance verication
Description
The aim of this test is to determine takeo speed, engine throttle and power during
cruise, acceleration and deceleration at constant altitude, maximum roll rate at cruise,
minimum turn radius, landing speed and landing distance. For each of these aspects
of the test, a dierent test procedure was used.
The pre-ight checks are to be made as described in the previous test.
Test Procedures
Take-o speed
1. Perform a manual takeo.
2. Retrieve speed at takeo from data logger.
3. Determine for none, 20%, 60% and 100% aps.
Engine throttle/power at cruise

1. Record at cruise speed from data logger.
Maximum speed
1. In straight and level ight attempt to reach maximum speed from cruise speed.
2. Retrieve from logger.
Maximum roll rate at cruise

1. Roll 90 degrees with full ailerons and measure time taken to do so.
2. Perform 3 times.
3. Determine average.
E.3. FLIGHT TESTING
xxiii
Minimum safe turn radius at cruise

1. Do not attempt to push aircraft to limit.
2. Perform circular path (may require a number of practice runs).
3. Measure time taken to perform 3 laps.
4. Retrieve speed from data logger.
5. Determine radius of circle.
E.3.3
Autopilot
Description
The autopilot was initially implemented in the test aircraft, which provided a platform
for proving the autopilots reliability without risking the actual UAV. Upon the successful completion of the test it was intended that the autopilot would be implemented
in the UAV. The aim of this test was to tune the autopilots controller gains and acquire
experience with the autopilots functionality in ight. The test was performed using
the test aircraft. It is important to keep the autopilot in visible range due to safety
issues.
The pre-ight checks are to be made as described in the previous test. Additional
checks however include:
Roll and Pitch the UAV to determine if the control surfaces move in the correct
directions. Also check that the articial horizon in the GCS moves as expected.
Verify that GPS position is correct and has a suciently strong lock.
Ensure aircraft is communicating with ground station.
Test Procedure
1. Follow the checklists related to setting up the test aircraft ready for ight.
2. Redude the autopilot output power to 100 mW from 1W. This prevents the
autopilot inundating the RC receivers.
xxiv
3. Perform an on-ground range test for the autopilot modem to ensure the autopilot
modem is functional over the given range.
4. Perform a manual take-o.
5. Once a safe altitude is reached, switch the autopilot to AUTO1 mode. This
allows the inner stability loops to be tuned.
6. Fly at cruise throttle, and tune the inner roll and pitch loops up to the point just
before the aircraft begins to oscillate. Change the throttle setting, and observe
eects on the test aircrafts stability.
7. Comand the test aircraft to perform a circular path in AUTO2 mode. Observe
the aircrafts desired and actual ight paths. The actual and ight path should
be recorded for later use.
8. Once the autopilot was successfully tuned, the aircraft was commanded to perform a gure 8 pattern to demonstrate its autonomous capabilities.
E.3.4
Imaging System
Description
Following successful ground testing of the imaging system and the image processing
software, it was necessary to ensure that the complete imaging system would perform as
required, with the camera placed in an aircraft and video footage input into the image
processing software. Therefore a imaging system test was performed using the test
aircraft. A aim of this test was to ensure that the camera provided adequate footage
and that image processing software was able detect and track the desired object (an
infrared emitter in this case) that was placed on the ground.
The pre-ight checks are to be made as described in the initial ight test. Additional
Ensure camera tightly fastened to aircraft.
Ensure camera equipment securely fastened within the aircraft
Test Procedure
E.3. FLIGHT TESTING
xxv
1. Set-up the test aircraft ready for ight. Ensure that the test aircraft checklist
has been followed.
2. Perform a test ight without the camera in the aircraft.
3. Place the camera into the aircraft making sure that the camera is placed in a
position whereby its eld of view is not obstructed.
4. Connect a handheld camcorder to the output leads of the camera, so that the
camcorder is able to record the video footage from the camera.
5. Place a 3 Watt infrared emitter at a known location on the ground.
6. Perform a ight with the test aircraft ying at an altitude of 50m. In this ight,
several passes should be made over the emitter.
7. Retrieve the video footage from the camcorder and input into this footage into
the image processing software.
8. Run the image processing software.
E.3.5
Payload Deployment
Description
The deployment of the payload is an integral part of the UAV system. It was important to test the accuracy of the payload deployment test as accuracy was crucial to a
successful payload drop. Given that the payload deployment mechanism has already
proven its functionality in component testing, it was now neccessary to test the payload
deployment test. The aim of this test is to determine the eectiveness and accuracy of
the payload deployment device on the UAV.
The pre-ight checks are to be made as described in the previous test. Additional
Ensure payload securely fastened to aircraft.
Ensure latch mechanism securely locked
xxvi
Test Procedure
1. Follow procedures for a ight test to ensure the aircraft is ready to y.

2. Perform a standard ight, incorporating a payload drop into the ight path.
3. Record the GPS coordinates for the desired payload drop.
4. Measure the actual drop position of the payload after it has been jettonised.
Record this GPS coordinate and calculate the dierence between the two drop
positions.
5. Determine if any damage was caused to the payload.
Appendix F
Project Scheduling
As discussed in the Management and Finances section, gantt charts were used to monitor the progress of the project. A gantt chart of external and internal deadlines was
created. This gantt chart can be seen below in gure F.2.
Figure F.1: Gantt Chart of Internal and External Deadlines

Internal tasks were set in order to break the above internal and external deadlines into
smaller, more managable tasks. The gantt chart used to aid this process is seen below
in gure F.2.
xxvii
xxviii
APPENDIX F. PROJECT SCHEDULING
Figure F.2: Gantt Chart of Project Tasks
Appendix G
Bill of Materials
This appendix presents the materials used in the project
xxix
A4+'*"='$
<)0=+$
B"C/4($
A4+'*"='$%"04>"-&4('$
<)0=$%"04>"-&4('$7?0@$+'&9
<)0=$%"04>"-&4('$
!"#$%"&'()"*+$
&'()*
&;('<
&4A)(**
&4I()*
&4')(**
&)*(**
&'**(**
&IR(**
,'+-().&)/0
!""#$#%
S1:#2F%/8""E?/$#%
:D'*'/I;)63+/6#:33
.:98C=/NCO2=63
-C#@/9"#":3"
D"(&
7C:+/.C9"/
0P2=
Q2=6/NCCF/Z"+$#:F"/
Q2=6/Z2$/Z"+$#:F"/
713"#:6"/X:%Y1$
&'()*
&A*(**
&4I()*
&'**(**
&4)(**
,'+-().&)/0
1/+&$
!""#$#%
45)/63+/728"96#:33
.28:/'<**/9"32=/>/?:9@="9
:D'*'/I;)63+/6#:33
4**LIA**L4I**/?/69:@"/DC:+
-%#:9/+2=2+1+/C9@"9/&)*
.:98C=/NCO2=63
Q:H/N"#":3"
D(/-'++$
TCF/M29"/7C:+/
728"96#:33/X:%Y1$
.U./NC1F2=6/
.U./NC1F2=6/
728"96#:33/X:%Y1$
1/+&$
&'()*
&;('<
&4A)(**
&4I()*
&4')(**
&)*(**
&'**(**
&IR(**
,'+-().&)/0
1/+&$
!""#$#%
45)/63+/728"96#:33
.28:/'<**/9"32=/>/?:9@="9
:D'*'/I;)63+/6#:33
4**LIA**L4I**/?/69:@"/DC:+
-%#:9/+2=2+1+/C9@"9/&)*
.:98C=/NCO2=63
Q:H/N"#":3"
'
4
'
*(4
4
*
*
*
)
*
*
*(4
*
*
*
4
)
4
4
*(4
4
6/&"*$1/+&$
6/&"*$1/+&$789
6/&"*$1/+&$789
6/&"*$1/+&$789
UV,
UV,
&)*
&)*
UV,
6/&"*$1/+&$
34"0&)&5
6/&"*$1/+&$
34"0&)&5$
6/&"*$1/+&$
34"0&)&5$
&4**
B"C/4($-/+&EF/4($ /$F/4(+$
:
UV,
'
UV,/
'
&)*
4
&)*
4
UV,
4*
,)2'0+)/0+$
+
3?""F
+
P6
P6
F2=
,)2'0+)/0+
+
+
A#
+
3?""F
P6
F2=
,)2'0+)/0+
+
+
A#
+
3?""F
6/&"*$-/+&$
&4''(**
&4*()*
&A*(**
&'R()*
&'*(**
&4)(**
&5I()*
&*(**
&*(**
&*(**
&<I()*
&*(**
&*(**
&'*(**
&*(**
&AA5()*
&*(**
&*(**
&4A)(**
&<I()*
&4')(**
&)*(**
&'*(**
&IR(**
;4..*)'($
,-./01$$#2"3/
,-./01$$#2"3/
,@"#:2@"/G$CH%/01$$#2"3
7JK
7C:+D:3F
;4..*)'($
,-./01$$#2"3/
,-./01$$#2"3/
,@"#:2@"/G$CH%/01$$#2"3
7JK
7C:+D:3F
W=2O"932F%/QC9P3?C$/[UC/EC3F/2=E199"@\/
%"04>"-&4('($
W3/
W3/
QC9P3?C$
QC9P3?C$
W3/
:/&'+
B="/CDD/EC3F
G=C16?/DC9/+1#F2$#"/M2=63
B="/CDD/EC3F
B="/CDD/EC3F
:/&'+
xxx
APPENDIX G. BILL OF MATERIALS
()*+'
)!%C-22,14,+%
)#2;04";2%
=-.,1-%Q%<1-9+.422,1%-9L%:,5,4R,1%
U6=%SU",521;945%60,,L%=;921;"",1T%
K4++4;9%!1;0,"",1%
K;L,.%
K;2;1%
K;2;1%C-22,14,+%
'Z";9%!1;0,"",1%[;1%2,+249$%
:=%:,5,4R,1%
6,1R;%C;-1L%C-22,14,+%
=-.,1-%C-22,14,+%
6,1R;+%
()*+.'
(-+*"#'
!-.+$%&'
3$%&.'
0"1#2.'
!""#$%&'
@/A
61)%+$+7'
!"+)#'/".+'
='=%:;#2,1
='=%:;#2,1%
>;2%?4149$%
(*",-..'
&
&
&

@/AA
@BOAAAFAA
@BAOABEFM
@VOEJEFM
!"+)#'/".+'"9'0"2-*)+-'A)B)&!"+)#'/".+'"9'C#-,+*$,)#'D1*%"1+
!"#$%&'(#)*+&,-.(%-,/
!01$%&'(#)*+&,-.(%-,/
/".+41%$+':;<=> !"+)#'/".+':;<=>8155#$-*'
@EGFIJ
@EGFIJ K;L,"%*"4$D2%
@NO/NA
@NO/NA /AAE%46P):%1,0;12%
@BOGAEFMA
@BOGAEFMA 841,",++%34L,;%=-.,1-+%S/AAET
@/JA
@/JA !,12D%:=%K;L,"+%-9L%>;774,+%
@BBVFJJ
@BBVFJJ K;L,"%*"4$D2%
@/OBAA
@/OBAA
@BNI
@BNI K;L,"%*"4$D2%
@/BNFGG
@BOEV/ K;L,"%*"4$D2%
@BG
@G/ K;L,"%*"4$D2%
@BNIFAA
@BNIFAA K;L,"%*"4$D2%
@/J
@/J K;L,"%*"4$D2%
@NIFIJ
@NIFIJ K;L,"%*"4$D2%
@VMFJA
@BJGFAA K;L,"%*"4$D2%
!"+)#'/".+
'()
'()%
'()%
'()
'()
'()
'()
@BOI/EFJ/
@B/OJNNFEE
B
B
B
B
B
B
B
M
V
B
B
B
G
BA
/".+'
!"+)#'/".+'"9'?-@1$*-2'()*+.'
!"+)#'/".+'"9'?-5#),$%&'<##'()*+.'
85-,9$,)+$"%'
61)+$+7'
*"4$D2%!;?,1%EFG3%H4!;
K451;04";2%/A/M$%
841,",++%34L,;%=-.,1-+%
K-+2,16049%EJ%P!<P
),1;9-#2%=)K%=-17;9%
K451;D-1L%K>W&/GAA%:*%K;L,.
X#-"%6YZ%
*!U3P/A&VVAAG6
SL4-.,2,1\24.,+%0425DT
60,521#.%):EAAA
*"4$D2%!;?,1%GFM%'4K>%
*!U3P/J&BJAAV6
]:%'U6%VVB%K494%6,1R;%
/".+45-*."%
849$%:;;2%<,.0"-2,%
849$%<40%<,.0"-2,%
849$%*;-.%=;1,%
()*+'
!"#$%
*#+,"-$,%*,.-",%
/&0-12%3,1245-"%62-74"4+,1
xxxi
001234
,
844244
,
544
815?235
5G84244
30G?245
!"#$%&'"(#&
'"(#&
!"#$%"&'()"*+$,$-)./
!"#$%"&'()"*+$,$67+'*"/'
:";<7($
=<<*)./$
='+&)./$
>"(&+$
A!BAA$5441$C7&;"DE$BF"**'./'$
!"#$%&'"(#(&
'"(#&)*"+(#&'$(,-&
83@4525?
15234
899244
,
,
,
853@@2??
5G84244
xxxii
APPENDIX G. BILL OF MATERIALS
Appendix H
Paparazzi Code
Presented in this appendix is the airframe le and ightplan to be used with paparazzi.
The airframe le was used in the test aircraft and is tuned to provide satisfactory fully
autonomous ight. The ightplan le is the proposed ight plan to be used for the
ARCAA Outback UAV Challenge and has been successfully simulated to complete the
mission.
H.1
Airframe File
<!DOCTYPE airframe SYSTEM "airframe.dtd">
<airframe name="iSOAR">

<modules>
<load name="movewpm.xml"/>
</modules>

<servos>
<servo name="THROTTLE" no="1" min="1100" neutral="1100"
max="2000"/>
<servo name="AILERON_LEFT" no="0" max="950"
neutral="1400" min="1850"/>
<servo name="AILERON_RIGHT" no="2" max="950"
neutral="1400" min="1850"/>
<servo name="ELEVATOR" no="6" max="950" neutral="1400"
xxxiii
APPENDIX H. PAPARAZZI CODE
xxxiv
min="1850"/>
<servo name="RUDDER" no="7" min="950" neutral="1430"

max="1910"/>
<servo name="FLAPS" no="3" max="1000" neutral="1500"
min="2000"/>
<servo name="HATCH" no="4" max="1000" neutral="1500"
min="2000"/>
</servos>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
<axis name="YAW" failsafe_value="0"/>
<axis name="FLAP" failsafe_value="0"/>
<axis name="HATCH" failsafe_value="0"/>
</commands>
<rc_commands>
<set
<set
<set
<set
<set
<set
command="THROTTLE" value="@THROTTLE"/>
command="ROLL" value="@ROLL"/>
command="PITCH" value="@PITCH"/>
command="YAW" value="@YAW"/>
command="FLAP" value="@FLAP"/>
command="HATCH" value="@HATCH"/>
</rc_commands>
<section name="MIXER">
<define name="AILERON_DIFF" value="0.66"/>
</section>
<command_laws>
<let
<let
<set
<set
<set
<set
<set
<set
<set
var="aileron" value="@ROLL"/>
var="elevator" value="@PITCH"/>
servo="THROTTLE" value="@THROTTLE"/>
servo="AILERON_LEFT" value="$aileron"/>
servo="AILERON_RIGHT" value="$aileron"/>
servo="ELEVATOR" value="$elevator"/>
servo="RUDDER" value="@YAW"/>
servo="FLAPS" value="@FLAP"/>
servo="HATCH" value="@HATCH"/>
H.1. AIRFRAME FILE
xxxv
</command_laws>
<section name="AUTO1" prefix="AUTO1_">
<define name="MAX_ROLL" value="0.6"/>
<define name="MAX_PITCH" value="0.6"/>
</section>
<section name="adc" prefix="ADC_CHANNEL_">
<define name="IR1" value="ADC_2"/>
<define name="IR2" value="ADC_1"/>
<define name="IR_TOP" value="ADC_0"/>
<define name="IR_NB_SAMPLES" value="16"/>
</section>
<section name="INFRARED" prefix="IR_">
<define name="ROLL_NEUTRAL_DEFAULT"
value="-4.4116601944" unit="deg"/>
<define name="PITCH_NEUTRAL_DEFAULT"
value="-6.18794441223" unit="deg"/>
<linear name="RollOfIrs" arity="2" coeff1="-0.7"
coeff2="0.7"/>
<linear name="PitchOfIrs" arity="2" coeff1="-0.7"
coeff2="-0.7"/>
<linear
<define
<define
<define
<define
<define
name="TopOfIr" arity="1" coeff1="1"/>

name="RAD_OF_IR_MAX_VALUE" value="0.0045"/>
name="RAD_OF_IR_MIN_VALUE" value="0.00075"/>
name="ADC_IR1_NEUTRAL" value="512"/>
name="ADC_IR2_NEUTRAL" value="512"/>
name="ADC_TOP_NEUTRAL" value="512"/>
</section>
<section name="BAT">
<define name="MILLIAMP_AT_FULL_THROTTLE" value="11000"
unit="mA"/>
<define name="CATASTROPHIC_BAT_LEVEL" value="9.3"
unit="V"/>
</section>
<section name="MISC">
<define name="NOMINAL_AIRSPEED" value="20." unit="m/s"/>
xxxvi
<define name="CARROT" value="5." unit="s"/>

<define name="KILL_MODE_DISTANCE"
value="(1.5*MAX_DIST_FROM_HOME)"/>
<define name="CONTROL_RATE" value="60" unit="Hz"/>
<define name="TRIGGER_DELAY" value="1.5"/>
</section>
<section name="PID">
<define name="ROLL_PGAIN" value="6000."/>
<define name="PITCH_OF_ROLL" value="0.25"/>
<define name="PITCH_PGAIN" value="10000."/>
<define name="MAX_ROLL" value="0.35"/>
<define name="MAX_PITCH" value="0.35"/>
<define name="MIN_PITCH" value="-0.35"/>
<define name="AILERON_OF_THROTTLE" value="0.0"/>
<define name="CRUISE_THROTTLE" value="0.35"/>
</section>
<section name="ALT" prefix="CLIMB_">
<define name="PITCH_PGAIN" value="-0.05"/>
<define name="PITCH_IGAIN" value="0.075"/>
<define
<define
<define
<define
name="PGAIN" value="-0.01"/>
name="IGAIN" value="0.1"/>
name="MAX" value="1."/>
name="PITCH_OF_VZ_PGAIN" value="0.05"/>
<define name="THROTTLE_OF_CLIMB" value="0.15"

unit="%/(m/s)"/>
</section>
<section name="HORIZONTAL CONTROL" prefix="H_CTL_">
<define name="COURSE_PGAIN" value="-0.4"/>
<define name="ROLL_MAX_SETPOINT" value="0.6"
unit="radians"/>
<define name="PITCH_MAX_SETPOINT" value="0.5"
unit="radians"/>
<define name="PITCH_MIN_SETPOINT" value="-0.5"
unit="radians"/>
<define name="ROLL_PGAIN" value="6077."/>
<define name="AILERON_OF_THROTTLE" value="0.0"/>
<define name="PITCH_PGAIN" value="-9000."/>
H.1. AIRFRAME FILE
xxxvii
<define name="PITCH_DGAIN" value="1.5"/>

<define name="ELEVATOR_OF_ROLL" value="1250"/>

<define name="ROLL_RATE_MODE_DEFAULT" value="1"/>
<define name="ROLL_RATE_SETPOINT_PGAIN" value="-5."
unit="rad/s/rad"/>
<define name="ROLL_RATE_MAX_SETPOINT" value="10"/>
<define name="LO_THROTTLE_ROLL_RATE_PGAIN"
value="1000."/>
<define name="HI_THROTTLE_ROLL_RATE_PGAIN"
value="1000."/>
<define name="ROLL_RATE_IGAIN" value="0."/>
<define name="ROLL_RATE_DGAIN" value="0."/>
<define name="ROLL_RATE_SUM_NB_SAMPLES" value="64"/>
</section>
<section name="VERTICAL CONTROL" prefix="V_CTL_">
<define name="POWER_CTL_BAT_NOMINAL" value="11.1"
unit="volt"/>

<define name="ALTITUDE_PGAIN" value="-0.03"/>

<define name="ALTITUDE_MAX_CLIMB" value="2."/>

<define name="AUTO_THROTTLE_NOMINAL_CRUISE_THROTTLE"
value="0.35"/>
<define name="AUTO_THROTTLE_MIN_CRUISE_THROTTLE"
value="0.30"/>
<define name="AUTO_THROTTLE_MAX_CRUISE_THROTTLE"
value="0.80"/>
<define name="AUTO_THROTTLE_LOITER_TRIM" value="1500"/>
<define name="AUTO_THROTTLE_DASH_TRIM" value="-1000"/>
<define name="AUTO_THROTTLE_CLIMB_THROTTLE_INCREMENT"
value="0.15" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_PGAIN" value="-0.01"/>
<define name="AUTO_THROTTLE_IGAIN" value="0.1"/>
<define name="AUTO_THROTTLE_PITCH_OF_VZ_PGAIN"
xxxviii
value="0.05"/>


<define name="AUTO_PITCH_PGAIN" value="-0.05"/>
<define name="AUTO_PITCH_IGAIN" value="0.075"/>
<define name="AUTO_PITCH_MAX_PITCH" value="0.35"/>
<define name="AUTO_PITCH_MIN_PITCH" value="-0.35"/>
<define name="THROTTLE_SLEW" value="0.1"/>
</section>
<section name="Takeoff" prefix="Takeoff_">
<define name="Height" value="30" unit="m"/>
<define name="Speed" value="15" unit="m/s"/>
<define name="Distance" value="3" unit="m"/>
<define name="MinSpeed" value="5" unit="m/s"/>
</section>
<section name="NAV">
<define name="NAV_PITCH" value="0."/>
<define name="NAV_GLIDE_PITCH_TRIM" value="0"/>
<define name="DEFAULT_CIRCLE_RADIUS" value="100"
unit="m"/>
</section>
<section name="AGGRESSIVE" prefix="AGR_">
<define name="CLIMB_THROTTLE" value="0.95"/>

<define name="DESCENT_THROTTLE" value="0.1"/>

<define name="CLIMB_PITCH" value="0.3"/>

<define name="DESCENT_PITCH" value="-0.25"/>

<define name="BLEND_START" value="20"/>

<define name="BLEND_END" value="10"/>

<define name="CLIMB_NAV_RATIO" value="0.8"/>


<define name="DESCENT_NAV_RATIO" value="1.0"/>
</section>
<section name="FAILSAFE" prefix="FAILSAFE_">
<define name="DELAY_WITHOUT_GPS" value="1" unit="s"/>
<define name="DEFAULT_THROTTLE" value="0.3" unit="%"/>
<define name="DEFAULT_ROLL" value="0.3" unit="rad"/>
<define name="DEFAULT_PITCH" value="0.5" unit="rad"/>
<define name="HOME_RADIUS" value="100" unit="m"/>
</section>
<makefile>
CONFIG = \"tiny_2_1_1.h\"
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
FLASH_MODE=IAP
ap.CFLAGS += -DFBW -DAP -DBOARD_CONFIG=$(CONFIG) -DLED
-DTIME_LED=1 ap.srcs = sys_time.c
$(SRC_ARCH)/sys_time_hw.c $(SRC_ARCH)/armVIC.c
main_fbw.c main_ap.c main.c
ap.srcs += commands.c
ap.CFLAGS += -DACTUATORS=\"servos_4017_hw.h\"
-DSERVOS_4017 ap.srcs += $(SRC_ARCH)/servos_4017_hw.c
actuators.c
ap.CFLAGS += -DRADIO_CONTROL
-DRADIO_CONROL_TYPE=RC_FUTABA #-DRADIO_CONTROL_AUTO1
ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c
#XBEE #ap.CFLAGS += -DDOWNLINK -DUSE_UART1
-DDOWNLINK_TRANSPORT=XBeeTransport -DXBEE_UART=Uart1
-DDATALINK=XBEE -DUART1_BAUD=B57600 #ap.srcs +=
downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c
#TRANSPARENT ap.CFLAGS += -DDOWNLINK -DUSE_UART1
-DDOWNLINK_TRANSPORT=PprzTransport
-DDOWNLINK_FBW_DEVICE=Uart1 -DDOWNLINK_AP_DEVICE=Uart1
-DPPRZ_UART=Uart1 -DDATALINK=PPRZ -DUART1_BAUD=B9600
ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c
pprz_transport.c
ap.CFLAGS += -DINTER_MCU ap.srcs += inter_mcu.c
xl
ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2

ap.srcs += $(SRC_ARCH)/adc_hw.c
ap.CFLAGS += -DGPS -DUBX -DUSE_UART0 -DGPS_LINK=Uart0
-DUART0_BAUD=B38400 -DGPS_USE_LATLONG ap.srcs +=
gps_ubx.c gps.c latlong.c
ap.CFLAGS += -DINFRARED -DALT_KALMAN -DWIND_INFO
-DWIND_INFO_RET ap.srcs += infrared.c estimator.c
ap.CFLAGS += -DNAV -DAGR_CLIMB -DLOITER_TRIM ap.srcs +=
nav.c fw_h_ctl.c fw_v_ctl.c
ap.srcs += nav_line.c ap.srcs += nav_survey_rectangle.c
ap.srcs += OSAMNav.c
ap.srcs += bomb.c
ap.srcs += snav.c
# Harware In The Loop
#ap.CFLAGS += -DHITL
ap.CFLAGS += -DUSE_MODULES sim.CFLAGS += -DUSE_MODULES
# Config for SITL simulation include
$(PAPARAZZI_SRC)/conf/autopilot/sitl.makefile sim.CFLAGS
+= -DBOARD_CONFIG=\"tiny.h\" -DAGR_CLIMB -DLOITER_TRIM
-DALT_KALMAN -DTRAFFIC_INFO sim.srcs +=
nav_survey_rectangle.c traffic_info.c nav_line.c
OSAMNav.c
sim.srcs += bomb.c
</makefile>
</airframe>
H.2
Flightplan File
<!DOCTYPE flight_plan SYSTEM "flight_plan.dtd">
<flight_plan alt="660" ground_alt="468" lat0="-26.579370"
lon0="151.839481" max_dist_from_home="15000" name="Kingaroy"
qfu="270" security_height="25">
<header>
#include "datalink.h"
#include "bomb.h"
#include "OSAMNav.h"
H.2. FLIGHTPLAN FILE
xli
</header>
<waypoints>
<waypoint alt="600" name="TARGET" x="85.1922610838"
y="8.50236448925"/>
<waypoint name="HOME" x="0" y="0"/>
<waypoint name="STDBY" x="88.7" y="-475.7"/>
<waypoint name="MOB" x="133.2" y="-208.3"/>
<waypoint name="CLIMB" x="35.7" y="-203.6"/>
<waypoint name="H1" x="113.5" y="-590.8"/>
<waypoint name="H2" x="917.1" y="-3309.3"/>
<waypoint name="T1" x="31.1" y="-3845.5"/>
<waypoint
<waypoint
<waypoint
<waypoint
name="S1"
name="S2"
name="S3"
name="S4"
x="392.0" y="-4035.8"/>
x="2722.3" y="-4192.0"/>
x="3200.3" y="-6343.4"/>
x="223.5" y="-6206.0"/>
<waypoint name="MB_1" x="-260.9" y="198.4"/>

<waypoint name="MB_2" x="82.7" y="201.5"/>
<waypoint name="MB_3" x="247.0" y="-234.9"/>
<waypoint name="MB_4" x="791.8" y="105.1"/>
<waypoint name="MB_8" x="-846.3" y="-7119.8"/>
<waypoint name="EX1" x="392.0" y="-3500.0"/>
<waypoint name="BOVAL" x="-100" y="0"/>
<waypoint alt="660" name="START" x="73.0" y="-344.0"/>
<waypoint name="RELEASE" x="149.970542131"
y="126.560028979"/>
<waypoint name="BASELEG" x="-2.87161011167"
y="-163.418097454"/>
</waypoints>
<sectors>
<sector name="Search">
xlii
<corner name="S1"/>
<corner name="S2"/>
<corner name="S3"/>
<corner name="S4"/>
</sector>
<sector name="Mission">
<corner name="MB_1"/>
</sector>
</sectors>
<exceptions/>
<blocks>
<block name="Wait GPS">
<set value="1" var="kill_throttle"/>

</block>
<block name="Geo init">
<while cond="LessThan(NavBlockTime(), 10)"/>
<call fun="NavSetGroundReferenceHere()"/>
</block>
<block name="Holding point">
<attitude roll="0" throttle="0" vmode="throttle"/>
</block>
<block name="Takeoff" strip_button="Takeoff (wp CLIMB)"
strip_icon="takeoff.png">
<exception cond="estimator_z > ground_alt+25" deroute="Flymission"/>
<go wp="CLIMB"/>

</block>
<block name="Flymission" strip_button="Fly Mission">
<go from="H1" hmode="route" wp="T1"/>
<deroute block="Poly Survey"/>
</block>
<block name="bloiter2">
<set value="WaypointX(WP_TARGET) + 200"
var="WaypointX(WP_BOVAL)"/>
<set value="WaypointY(WP_TARGET)"
var="WaypointY(WP_BOVAL)"/>
<eight center="TARGET" radius="nav_radius"
turn_around="BOVAL"/>
</block>
<block name="Standby" strip_button="Standby"
strip_icon="home.png">
<circle radius="nav_radius" wp="HOME"/>
</block>
<block name="flyhome" strip_button="Home">
<go from="H2" hmode="route" wp="H1"/>
<deroute block="Standby"/>
</block>
<block name="MOB" strip_button="Turn around here"
strip_icon="mob.png">
<call fun="NavSetWaypointHere(WP_MOB)"/>
<circle radius="100" wp="MOB"/>
</block>
<block name="Poly Survey" strip_button="Survey"
strip_icon="survey.png">
<call fun="InitializePolygonSurvey(WP_S1, 4, 200,
90)"/>
<call fun="PolygonSurvey()"/>
</block>
<block name="Return to Survey" strip_icon="survey.png">
xliii
xliv
<call fun="PolygonSurvey()"/>
</block>
<block name="bloiter" strip_button="B Loiter">
<call fun="NavSetWaypointHere(WP_TARGET)"/>
<set value="WaypointX(WP_TARGET) + 200"
var="WaypointX(WP_BOVAL)"/>
<set value="WaypointY(WP_TARGET)"
var="WaypointY(WP_BOVAL)"/>
<eight center="TARGET" radius="nav_radius"
turn_around="BOVAL"/>
</block>
<block name="bombhere" strip_button="Bomb Here">
<call fun="NavSetWaypointHere(WP_TARGET)"/>
<deroute block="bomb"/>
</block>
<block name="bomb" strip_button="Bomb">
<set value="WaypointX(WP_TARGET)"
var="WaypointX(WP_START)"/>
<set value="WaypointY(WP_TARGET) - 200"
var="WaypointY(WP_START)"/>
<set value="WaypointX(WP_TARGET)"
var="WaypointX(WP_CLIMB)"/>
<set value="WaypointY(WP_TARGET) + 200"
var="WaypointY(WP_CLIMB)"/>
<set value="BombComputeApproach(WP_TARGET, WP_START,
nav_radius)" var="unit"/>
<circle radius="nav_radius"
until="NavQdrCloseTo(DegOfRad(bomb_start_qdr)-10)"
wp="BASELEG"/>
</block>
<block name="align">
<exception cond="BombUpdateRelease(WP_TARGET)"
deroute="flyhome"/>
xlv
<go approaching_time="bomb_trigger_delay" from="START"

hmode="route" wp="RELEASE"/>
</block>
<block name="shoot">
<set value="BombShoot()" var="unit"/>
<go from="RELEASE" hmode="route" wp="CLIMB"/>
<set value="BombCloseHatch()" var="unit"/>
<deroute block="Return to Survey"/>
</block>
<block name="close">
<set value="BombCloseHatch()" var="unit"/>
<deroute block="Return to Survey"/>
</block>
</blocks>
</flight_plan>
ImageProcessing.java
28/10/09 11:45 AM
Appendix I
private void initialiseCamera(int index){

if(mac){
// OpenCV setup
cv = new OpenCV();
// Camera capture
cv.capture(camWidth, camHeight, index);
}else{
// OpenCV setup
cv = new OpenCV();
Image Processing Code

// JMyron setup
myron = new JMyron();
myron.start(camWidth, camHeight);
}
}
I.1
/**
* Gui listeners
*/
private KeyListener createKeyboardListener()
{
return new KeyAdapter() {
public void keyPressed(KeyEvent e) {
// Nothing here yet
}
};
}
Initial Processing
/**
* Timer listener - performs OpenCV retrieval and processing
*/
public void actionPerformed(ActionEvent e)
{
if(cv==null)
return;
if(pause)
return;
maxBlobsToFind = 50;
// Cap blob search number so we don't bust our array
if(maxBlobs > maxBlobsToFind)
maxBlobs = maxBlobsToFind;
blobs = null;
viewPanel.setBlobs(blobs);
// Grab image from video stream
int[] img;
if(mac){
cv.read();
img = cv.pixels();
}else{
myron.update();
img = myron.image();
}
// Add white border to aid in blob detection at edges
// Force two lines of pixels at top and bottom to white
for(int i = 0; i < camWidth*2; i++){
img[i] = BLACK;
img[(img.length-1) - i] = BLACK;
}
// Force two lines of pixels at left and right to white
for(int i = 0; i < camHeight; i++){
img[camWidth*i] = BLACK;
img[camWidth*i + 1] = BLACK;
img[(camWidth - 1) + i*camWidth] = BLACK;
img[(camWidth - 2) + i*camWidth] = BLACK;
}
// Allocate memory for image, and copy into OpenCV object
cv.allocate(camWidth, camHeight);
cv.copy(img, camWidth, 0, 0, camWidth, camHeight, 0, 0, camWidth, camHeight);
Page 6 of 16
xlvii
APPENDIX I. IMAGE PROCESSING11:45 AM

28/10/09 CODE
xlviii
ImageProcessing.java
// Apply brightness and contrast
cv.brightness(brightness);
cv.contrast(contrast);
// Change display depending on what mode we are in

switch(mode){
case VIEW_MODE_NORMAL:
// No processing needed, just show the image
mis[0] = new MemoryImageSource(camWidth, camHeight, cv.pixels(), 0, camWidth);
viewPanel.setImage(createImage(mis[0]));
break;
case VIEW_MODE_GREYSCALE:
// Perform processing
cv.convert(OpenCV.GRAY);
cv.invert();
break;
case VIEW_MODE_THRESHOLD:
cv.invert();
cv.threshold(threshold);
break;
case VIEW_MODE_FINAL:
// Pull image out before we mangle it
cv.invert();
blobs = cv.blobs(minBlobSize, maxBlobSize, maxBlobsToFind, true, OpenCV.MAX_VERTICES*4);
break;
case VIEW_MODE_4VIEW:
// First panel - show feed unchanged
images[0] = createImage(mis[0]);
// Second panel - show greyscale/inverted feed
cv.invert();
// Third panel - show greyscale, inverted, thresholded
// Fourth panel - show original feed with blobs highlighted
blobs = cv.blobs(minBlobSize, maxBlobSize, maxBlobsToFind, true, OpenCV.MAX_VERTICES*4);
viewPanel.setFourViewImages(images);
break;
}
repaint();
}
/***
Tabbed Pane Creation Method and Listener
*/
private JTabbedPane createTabbedPane()
{
JTabbedPane pane = new JTabbedPane();
//pane.setPreferredSize(new Dimension(200, 200));
Page 7 of 16
I.2. BLOB QUALITY ANALYSIS
I.2
Blob Quality Analysis
BlobWrapper.java
xlix
28/10/09 12:03 PM
/*
* A wrapper which holds a blob as well as
* information about it's quality and state
*/
class BlobWrapper implements Comparable
{
private ImageProcessing ip;
private DecimalFormat formatter = new DecimalFormat("#.##");
public Blob blob;
double ARQuality;
double sizeQuality;
double circleQuality;
private double quality;
private double size;
private
private
private
private
double
double
double
double
x;
y;
width;
height;
public Area rectangle;

public Area area;
public BlobWrapper(Blob blob, ImageProcessing ip)
{
this.ip = ip;
this.blob = blob;
quality = 0;
x = (double) blob.rectangle.x;
y = (double) blob.rectangle.y;
width = (double) blob.rectangle.width;
height = (double) blob.rectangle.height;
size = (double) blob.area;
// Get the geometry of the blob
rectangle = new Area(new Rectangle2D.Double(x, y, width, height));
Polygon poly = new Polygon();
for(Point p : blob.points){
poly.addPoint(p.x, p.y);
}
area = new Area(poly);
double ARWeight = ip.getARWeighting();
BlobWrapper.java
double sizeWeight = ip.getBlobSizeWeighting();
28/10/09 12:03 PM
double circleWeight = ip.getCircularAreaWeighting();

ARQuality = calculateARQuality();
sizeQuality = calculateSizeQuality();
circleQuality = calculateCircleQuality();
// Final quality value is between 0 and 1
quality = (ARWeight*ARQuality + sizeWeight*sizeQuality + circleWeight*circleQuality)/(ARWeight +
sizeWeight + circleWeight);
}
/*
* Determines quality of blob for sorting
*/
private double calculateARQuality(){
// Determine the aspect ratio of the blob
// Use the largest value (>= 1.0)
double AR = width > height ? width/height : height/width;
double desiredAR = ip.getDesiredBlobAR();
return 1.0 - (Math.abs(desiredAR - AR)/(desiredAR + AR));
}
private double calculateSizeQuality(){
double desiredSize = (double) ip.getDesiredBlobSize();
return 1.0 - (Math.abs(desiredSize - size)/(desiredSize + size));
}
private double calculateCircleQuality(){
// Average width and height to get equivalent circle diameter
double d = (width + height)/2.0;
double circleArea = Math.PI*Math.pow(d/2.0, 2);
return 1.0 - (Math.abs(circleArea - size)/(circleArea + size));
}
public double getQuality(){
return quality;
}
public double getARQuality(){
return ARQuality;
}
public double getSizeQuality(){

return sizeQuality;
}
public double getCircleQuality(){
return circleQuality;
Page 1 of 3
APPENDIX I. IMAGE PROCESSING CODE
I.3
Ivy Bus Communication
PaparazziIn.java
28/10/09 12:09 PM
PaparazziIn(String port) throws IvyException

{
// create new ivy bus
bus = new Ivy("PaparazziIn", "PaparazziIn Ready", null);
PaparazziIn.java
28/10/09 12:09 PM
// Navigation messages
bus.bindMsg("(NAVIGATION( .*|$))", new IvyMessageListener() {
public void receive(IvyClient client, String[] args) {
PaparazziIn(String port) throws IvyException
StringTokenizer st = new StringTokenizer(args[1], " ");
{
block = Integer.valueOf(st.nextToken()); // Current Block
// create new ivy bus
st.nextToken(); // Current Stage
bus = new Ivy("PaparazziIn", "PaparazziIn Ready", null);
x = Float.valueOf(st.nextToken()).floatValue(); // pos_x
y = Float.valueOf(st.nextToken()).floatValue(); // pos_y
// Navigation messages
// dist to waypoint (m^2)
bus.bindMsg("(NAVIGATION( .*|$))", new IvyMessageListener() {
// void receive(IvyClient client, String[] args) {
public dist to home (m^2)
// circle count st = new StringTokenizer(args[1], " ");
StringTokenizer
// oval count
block = Integer.valueOf(st.nextToken()); // Current Block
st.nextToken(); // Current Stage
navigationMessage = true;
x = Float.valueOf(st.nextToken()).floatValue(); // pos_x
y = Float.valueOf(st.nextToken()).floatValue(); // pos_y
});
// dist to waypoint (m^2)
// dist to home (m^2)
// GPS messages
// circle count
bus.bindMsg("(GPS( .*|$))", new IvyMessageListener() {
// oval count

navigationMessage = true;
}
mode = Float.valueOf(st.nextToken()); // Mode: manual=1, AUTO1=2, AUTO2=3
});
utm_east = Double.valueOf(st.nextToken())/100; // UTM east (m)
utm_north = Double.valueOf(st.nextToken())/100; // UTM north (m)
// GPS messages
heading = .*|$))", new IvyMessageListener() {
bus.bindMsg("(GPS(Float.valueOf(st.nextToken())/10; //course (decideg)
alt = (Float.valueOf(st.nextToken()).floatValue())/100; //Altitude (m)
st.nextToken();// speed (cm/s)
st.nextToken();// climb rate (cm/s)
st.nextToken();// week (weeks) ??
mode = Float.valueOf(st.nextToken()); // Mode: manual=1, AUTO1=2, AUTO2=3
st.nextToken();// itow (ms) ??
utm_east = Double.valueOf(st.nextToken())/100; // UTM east (m)
utm_zone = =(Integer.valueOf(st.nextToken()).intValue());// utm_zone
utm_north
Double.valueOf(st.nextToken())/100; // UTM north (m)
// gps_nb_err
heading = Float.valueOf(st.nextToken())/10; //course (decideg)
GPSMessage = true;
alt = (Float.valueOf(st.nextToken()).floatValue())/100; //Altitude (m)
}
st.nextToken();// speed (cm/s)
});
st.nextToken();// climb rate (cm/s)
st.nextToken();// week (weeks) ??
// Attitude messages
st.nextToken();// itow (ms) ??
bus.bindMsg("(ATTITUDE( .*|$))", new IvyMessageListener() {
utm_zone = (Integer.valueOf(st.nextToken()).intValue());// utm_zone
// gps_nb_err
GPSMessage = true;
}
});
phi = Float.valueOf(st.nextToken()); // phi (rad) = roll (rad)
psi messages
// Attitude = Float.valueOf(st.nextToken()); // psi (rad) = heading (rad)
theta = Float.valueOf(st.nextToken()); // theta (rad) = pitch (rad)
bus.bindMsg("(ATTITUDE( .*|$))", new IvyMessageListener() {
}
}); public void receive(IvyClient client, String[] args) {
bus.start(port);
phi = Float.valueOf(st.nextToken()); // phi (rad) = roll (rad)
psi = Float.valueOf(st.nextToken()); // psi (rad) = heading (rad)
public static void =sendBlock(int block){
theta
Float.valueOf(st.nextToken()); // theta (rad) = pitch (rad)
try {
}
bus.sendMsg("ME JUMP_TO_BLOCK 2 " + block);
});
} catch (IvyException e) {
//Doesn't care
bus.start(port);
}
}
}
}
public static void sendBlock(int block){

public void sendTarget(int target_no) {
try {
int send_x = (int) (targetX * 100); " + block);
bus.sendMsg("ME JUMP_TO_BLOCK 2
int send_y = (int) (targetY * 100);
int send_h = (int) (alt * 100);
//Doesn't care
try {
}
bus.sendMsg("ME RAW_DATALINK 2 MOVE_WPM;" + target_no + ";2;" + send_x
}
+ ";" + send_y + ";" + send_h);
System.out.println("x = " + x {
public void sendTarget(int target_no) + " y = " + y + "ME RAW_DATALINK 2 MOVE_WPM;" + target_no + ";2
;" = (int)
int send_x + send_x (targetX * 100);
+ ";"
send_y + ";" + send_h);
int send_y = (int) (targetY *+ 100);
} catch (IvyException e) *{ 100);
int send_h = (int) (alt
try // Doesn't care
{
}
bus.sendMsg("ME RAW_DATALINK 2 MOVE_WPM;" + target_no + ";2;" + send_x
}
+ ";" + send_y + ";" + send_h);
System.out.println("x = " + x + " y = " + y + "ME RAW_DATALINK 2 MOVE_WPM;" + target_no + ";2

;" + send_x
+ ";" + send_y + ";" + send_h);
// Doesn't care
}
Page 1 of 2
Page 1 of 2
PaparazziIn.java
28/10/09 12:09 PM
PaparazziIn.java
28/10/09 12:09 PM
I.3. IVY BUS COMMUNICATION

public void Target(int width, int height, int px, int py, double hfov, double vfov, double
groundElevation) {
if (navigationMessage && GPSMessage) {
double dx;
public void Target(int width, int height, int px, int py, double hfov, double vfov, double
double dy;
groundElevation) {
if (navigationMessage && GPSMessage) {
double finalX;
double dx;
double finalY;
double dy;
double headingDegrees = heading;

double finalX;
double headingRadians;
double finalY;
double
double
double
double
double
theta;
headingDegrees = heading;
alpha;
headingRadians;
r;
double theta;
double h = alt - groundElevation;
double alpha;
double r;
dx = PixelToDistance(width, px, h, hfov);
dy = PixelToDistance(height, py, h, vfov);
double h = alt - groundElevation;
theta PixelToDistance(width, px, h, hfov);

dx = = Math.atan2(dx, dy);
dy = PixelToDistance(height, py, h, vfov);
headingRadians = Math.toRadians(headingDegrees);
theta = Math.atan2(dx, dy);
alpha = theta + headingRadians;
headingRadians = Math.toRadians(headingDegrees);
if (alpha >= Math.PI) {
alpha -= + headingRadians;
alpha = thetaMath.PI;
}
if (alpha >= Math.PI) {
r = Math.sqrt((dx*dx)+(dy*dy));
alpha -= Math.PI;
finalX = r * Math.sin(alpha);
}
finalY = r * Math.cos(alpha);
r = Math.sqrt((dx*dx)+(dy*dy));
if (block r== 9 || block == 10) {
finalX =
* Math.sin(alpha);
targetX
x + finalX;
finalY = r *= Math.cos(alpha);
targetY = y + finalY;
sendTarget(1);
if (block == 9 || block == 10) {
} else {
targetX = x + finalX;
System.out.println("Block out of range");
targetY = y + finalY;
}
sendTarget(1);
} else else {
} {
System.out.println("Haven't had and paparazzi communication yet");
System.out.println("Block out of range");
}
}
} else {
System.out.println("Haven't had and paparazzi communication yet");
public double PixelToDistance(double width, double p, double h, double fov){
}
double w;
}
double d;
w
h * Math.tan(Math.toRadians(fov)/2);
public= double PixelToDistance(double width, double p, double h, double fov){
d = (p*w/width)-(w/2);
double w;
return d;
double d;
}
w = h * Math.tan(Math.toRadians(fov)/2);
d = (p*w/width)-(w/2);
return d;
}
Page 2 of 2
Page 2 of 2
li
Appendix J
Micropilot 2028g Development
This section outlines the work completed so far on the Micropilot 2028g autopilot
system including the solution to the problems experienced, the autopilot and sensor
conguration procedures and the developed ight plans. Although it was not implemented in the nal design, it is a complete and powerful system that could potentially
be used for projects in the future.
J.1
Solution to Micropilot issues
Late in the project year, the Horizon software update (Horizon 3.4) arrived from Micropilot. The software was initially tested on a Laptop and it was noticed that it
no longer caused the system to crash. The Horizon update also provided the latest
rmware (mp2028-3.4.325), which was loaded onto the autopilot. After this update
was performed, the autopilot no longer displayed the Unkown Fatal Error as it previously had. Therefore, it appeared that the Micropilot issues had been solved.
J.2
Micropilot Conguration
Autopilot Conguration
1. Install all devices in the UAV.
2. Connect the autopilot to the PC using the serial to 2028g cord.
3. The autopilot can be congured using the conguration wizard software. Firstly
select COM1 for serial communication.
liii
APPENDIX J. MICROPILOT 2028G DEVELOPMENT
liv
4. Choose all data to be presented as metric units.

5. Perform an orientation check by pitching the UAV up and down and comparing
this with the pitch on the articial horizon.
6. No AGL is installed therefore adjust the autopilot accordingly.
7. Select separate aperons for the servo conguration. A normal tail conguration will be utilised.
8. Test the ailerons, elevator and rudder servos, using the zero, maximum and minimum tests. Trim the control services using software such that they perform as
expected. If a control surface is greater than one third dierent to the expected
value, then it should be trimmed mechanically. Also check the throttle control
using the zero, maximum and minimum tests and adjust as required. Record the
trim values.
9. Check RC input. Firstly attempt to convert from CIC to PIC mode. If this does
not operate correctly, reduce the travel on the corresponding transmitter channel.
Move the control sticks and trim to the maximum position, the pulse width of
the servos should be between 0.7 and 2.3 ms. If this is not the case, reduce the
travel on the corresponding transmitter channel.
10. Maintain the default settings for the Speed, Altitude, Throttle, Altitude and
Battery settings, as they are not relevant to this test.
11. Save the conguration for later use.
Sensor Test
1. Run the Hyper Terminal software.
2. Check if the gyros have stabilised and type FFFF to produce a fake GPS lock.
3. Enter SSSS to provide a sensor report.
4. Pitch the UAV 45 degrees and record the x accelerometer and pitch giro values.
Compare these to the expected values.
5. Return the UAV and allow the sensors to stabilise.
6. Roll the UAV 45 degrees so the right wing is pointing down and record the y
accelerometer and roll giro values. Compare these to the expected values.
J.3. MICROPILOT FLIGHT PLANS
lv
7. Return the UAV and allow the sensors to stabilise.

8. Yaw the nose of UAV 90 degrees to the right and record the yaw giro value.
Compare this to the expected value.
9. Blow into the airspeed sensor and record whether the airspeed increased or decreased.
10. Blow and suck on the altitude sensor and record if the altitude increased or
decreased.
Control Test
1. Pitch, Roll and Yaw the UAV. Observe and record how the elevator, ailerons and
rudder react.
2. Switch to PIC and check if all surfaces respond correctly to the controller. If a
servo appears to get stuck, change the travel of the corresponding transmitter
channel.
3. Check if the autopilot diverts to CIC when the transmitter is turned o.
J.3
Micropilot Flight Plans
//Primary ight path

Imperial //Use imperial units
takeo climb 300 //climb to 300 feet
waitClimb 200 //commence next step once reached 200 feet
yTo ( 1000, 1000) //follow a square path (1000=38.1m) as search path not yet developed
yTo ( 1000,-1000)
yTo (-1000,-1000)
yTo (-1000, 1000)
repeat -4 //repeat path indenitely
//Pattern 0 Loiter above target
lvi
denePattern 0 [rotatePattern]=[currentHeading] //rotate relative waypoints to coincide with current heading

yTo (500,500) //follow gure 8 ight pattern (500=19.05m)
yTo (0,0)
yTo (-500,-500)
yTo ( 500,-500)
yTo (0,0)
yTo (-500,500)
repeat -6 //repeat pattern indenitely
// Pattern 1 Payload deployment
denePattern 1 [fServo7]=32000 //Deployment servo at full position return
//Pattern 2 Return to home
denePattern 2
yTo(26.59949S,151.84306E) //Initially y to throat of ight corridor
fromTo[home] //Return to home repeat -1
//Pattern3 Flight termination
denePattern 3 [stopEngine]=1 //Engine o
[Elevator]=-32000 //full up elevator
[Rudder]=-32000 //full right rudder
[fServo1]=-32000 //full up on the left aileron
[fServo6]=32000 //full down on the right aileron
[fServo7]=32000 //right ap down
[fServo5]=32000 //left ap down
wait 99999
// RC failure pattern
denePattern rcFailed
yTo [home] //Attempt to y home
J.3. MICROPILOT FLIGHT PLANS

repeat -1
//Horizon communication link failure pattern
denePattern gcsFailed
wait 10 //wait 2 seconds
yTo[home] //Attempt to return to base
wait 15 //wait 3 seconds
[stopEngine]=1 //Engine o
[Elevator]=-32000 //full up elevator
[Rudder]=-32000 //full right rudder
[fServo1]=-32000 //full up on the left aileron
[fServo6]=32000 //full down on the right aileron
[fServo7]=32000 //right ap down
[fServo5]=32000 //left ap down
wait 99999
//GPS failure pattern
denePattern gpsFailed
setControl rollFixed //angle of bank is held at 0
wait 50 //wait 10s for GPS to re-acquire lock
[elDrivesAlt]=0 //elevator controls airspeed
setControl thFixed,0 //cut the throttle and start a descent
wait 99999
//Loss of engine power failure pattern
denePattern engineFailed
climb 0 //set-up to descend to the ground
turn [runwayDirection] //turn into wind
wait 99999
lvii
lviii
//Low battery voltage

denePattern batVFailed
climb 0 //set-up to descend to the ground
turn [runwayDirection] //turn into wind
[stopEngine]=1 //turn o engine
wait 99999
Appendix K
Meeting Minutes
K.1
Tuesday 3.2.09
Attending: Todd, James, Ashleigh and Maziar

Apologies: None
Housekeeping
Technical Manager- Todd
1 more student- not necessarily needed
Get in the habit of documenting everything!
Each of us need a LOGBOOK - Best in the form of a large folder, that way can keep
written notes and pieces of paper
Scope of project and objectives
Need to contact Ben and Brad, get everything othem
Get in touch with Michael Williams
Contact school oce to get access to S237
Download Fuel cell and Pulse jet UAV reports from last year
Have a look at competition website
Is it running?
Do we need to register?
lix
APPENDIX K. MEETING MINUTES
lx
If not running, we will solve problem for ourselves

Write a short report about competition
Level 4 Project Webpage/Myuni
For project forms
Expectations
Minutes
Agenda with time limits for each item and whole meeting
Keep internal minutes
Things to do for Project (1 and 2 in the next 2-3 weeks)
1. New Wing design (Ash and Todd)
Existing wings are broken
Understand theory of aircraft design
Wing loading
Airfoil
Increase/decrease wing area?
Justify everything
Method- classical approach such as in Raymer and Roskam
Weight calculations
Matching diagram (Hy-Five UAV report good for this)
Wing area
Design is heavily dependent on airfoil, lift coecient is dependent on the airfoil
2. Manufacturing (Todd and James)
K.1. TUESDAY 3.2.09
lxi
Look at procedure
Dierent types of materials
3. Autopilot communication problem (James)
Interference- autopilot and payload, autopilot and carbon bre hatch
Main problem is communication
James to come up with a way of tackling the problem
4. Parachute Design (Todd?)
Using parachute generates a high load factor
Ben designed last parachute
Another design test for parachute is needed, Maziar is not happy with the existing
test
Payload- bottle is ok
For meeting after next meeting
Summary of project (project denition) to go on website
Power point presentation (10-15 mins long) about the project
For the next meeting with Maziar (in 2 weeks 17.2.09)
Project denition 1,2,3 and 4 as stated before
Contact Ben, Brad and Michael Williams
Email school about access to room
Email school about computer to install autopilot software
Ash to make Gantt Chart of Project Schedule
Our next internal meeting is Tuesday 10.2.09 at 6pm.
lxii
K.2
Tuesday 10.2.09
Present - Ashleigh, Todd, James and Maziar

Apologies - None
Progress
Ashleigh
Wing design (Classical approach) In progress. o
Email Ben and Brad Waiting for reply.
Email school oce regarding room availability Room available in a few days.
Gant Chart In progress.
Todd
UAV outback report Completed introduction and 2008 results.
Wing design (Computational approach) Requires material properties.
Structural design of wings Waiting on wing design.
Parachute design research Currently looking into.
Wing materials and manufacture research In progress.
James
UAV outback report Completed competition rules.
Strategy for dealing with interference Identied likely causes and required modications. Currently generating test procedure.
Contact Michael Williams Waiting on contact details from Ben and Brad.
Email school oce regarding software Waiting till after speaking with Ben,
Brad and Michael.
Project Denition Completed. o Wing materials and manufacture research
In progress.
K.2. TUESDAY 10.2.09

Continuing Work
Ashleigh
Wing design (classical approach).
Gantt chart.
UAV Outback report Deliverables and Dates.
Todd
Wing Design (Computational approach).
Structural design of wings.
Parachute design research.
Wing materials and manufacture research.
James
Strategy for dealing with interference.
Contact Michael Williams.
Email school oce regarding software.
Project objectives.
Wing materials and manufacture research.
Our next meeting is Thursday 19.2.09 at 5pm with Maziar.
lxiii
lxiv
K.3
Thursday 19.02.09
Present: Maziar, Ashleigh, James, Mark and Todd

Apologises: None
Housekeeping
Get Logbooks! Something that logs whatever happens in the project, this includes internal meeting minutes, calculations, notes etc
All documents need to be peer reviewed by someone else in the group
Next meeting all documents presented in soft copy to put onto the screen, do not
print them out, therefore they need to be emailed to Ashleigh or be presented on
USB before the meeting!
We need to make decisions between ourselves
Sponsorship
Contact Nova Aerospace to get Sponsorship from them
Prepare a presentation with scope etc, prepare a letter for sponsorship, and possibly present the presentation to the potential sponsors
Prepare a list of sponsors, sponsors A and B - DSTO might be good, Talas?
Aeronautical Engineers
In-kind Sponsorship, discount on materials, services etc
Project Objectives
Dont make them so specic as they need to be investigated, hence leave them
general
Technical Task (as found in Aircraft Design Notes Lecture 3 Slide 4)
This is basically how you communicate with your customers
Need to know why we are designing the aircraft - Can be very long in industry,
sometimes 300 pages.
K.3. THURSDAY 19.02.09
lxv
Ours only needs to be at least 4-5 pages

We are the client, need to make sure the client agrees with the designers
Justify everything, as it is likely everything will be questioned by the client
Todd
Wing Design
Manufacturing of airfoil, better tolerances, so that the performance is increased,
use something like airfoil, use Javafoil
Changing the leading edge with dramatically change its aerodynamic properties.
First thing is not to select airfoil, need to determine design parameters rst
This comes from the preliminary design work, etc and the matching diagram
REMEMBER: the Aim of the project is to LEARN!!
James plan of attach for solving interference problem

Range setting on antenna
Need to know technical parameters with autopilot
Test away from the city without signals
Antenna on board is sensitive to direction of carbon be
Engine on test engine o test
Range test we test along runway, dont test it in a circle Solve problem through
trial and error
Maziar thinks the interference causes by propeller hatch was put on at the same
time as the autopilot was intergrated.
lxvi
Testing
When we want to prepare something for test, ie test concept

Prepare a test procedure - Two Forms
First one what needs to be prepared for that test, theoretical understanding
Second test procedure, like a prac report, table what you want to measure etc,
column for expected values, what you expect to achieve, 2nd column is experimental value and third is tolerance, can even a range of values
Regulations of UAVs (Todd)
CASR 101, FAR 23, 1.5 safety factor, FAR23 3.5 light aircraft category
CASR 101 is only regulation in the world for UAVs
Safety factor mainly used for metals - Calculate everything based on the standards
Safety factor has kept the aircraft from crashing in previous ight tests!
Structural design for small UAVs for MAA, standard for operation, when they
operating last time, they operated from a MAA aireld as long as you never
switch on the auto-pilot
Its over 7kg it can be own by a large aircraft operator. Pilot signed forms to y
aircraft.
Need to nd a place to y the aircraft as a model, need to nd a place to y
legally, payload antenna is the unexceptable, ie camera 2.4 GHz, power is a bit
higher than what we can use, how can we sort these problems legally. Need to
nd a place to y.
Other
In iSOAR copper around electrical devices, most aircraft have thin Al, copper
foil under the intenna as a ground plate to improve the quality
Something we might add to the project is the payload and image processing
Current camera in iSOAR is an analogue camera
K.3. THURSDAY 19.02.09
lxvii
For next meeting,

Presentation - This includes the preliminary project objectives and scope etc
Matching Diagram and complete wing design!
James - Tests for the iSOAR - Prepare test plan
Determine point system for ARCAA
One of us should be in contact with ARCAA, download timetable for ARCAA
2 Gantt charts one for uni report and one for ARCAA Ongoing
Wing design Todd
James interference problems
Need to nd a place to legally y iSOAR
First thing xing the wing to the fuselage ie wing tongue, sourcing some free
material
For the autopilot needs to be tuned for the aircraft, gps waypoints need to be programmed.
Next meeting is Monday 2nd March at 4pm (this is our usual meeting time with Maziar)
in S238
lxviii
K.4
Monday 02.03.09
Present: Mark, James, Todd, Ashleigh and Maziar

Apologies: None
Sponsor Presentation
No project number needed
Make students bigger
Make Supervisor smaller (dont need supervisor)
Use clear fonts, such as Arial, Arial Narrow, font we used was also ne, needs to
be readable
It is for commercial purposes therefore needs to be attractive, have animations,
pictures, videos etc.
Doesnt need to be as technical
Needs Slide numbers
Pictures need to have captions
Ever slide should have pictures
Dierent size fonts on dierent slides ok
Try to keep a list on the one page ie project objectives
No extended project objectives for sponsors
Outback Challenge 2009 needs more pictures
Make slides simpler, fewer words on the slides, say the rest
Perhaps a owchart for the components of iSOAR would be good
1. Breakdown of all major components such as wings, fuselage
2. Green components for what we already have
3. Yellow for components we want
4. Red for the components we will get if we have time
K.4. MONDAY 02.03.09
lxix
Mention that previous year, students did an excellent/fantastic/great job but had
some issues
Keep branding on all slides
No conclusion
No prices at presentation
2 people should present presentation
1. For management questions 2. For technical questions Uni Presentation
4 parts First part talk about UAVs, search and rescue applications, examples
of that, Importance of UAVs, shark patrols, for bushre watch Second part,
what you want to do, project objectives Third part, who you are, introduce
yourselfs, link to the university, link to Mechanical School Fourth part, what
we can promise them, what they can get,
Advertisement
Contribution to the education of young engineers
It is a tax deduction
Invite to exhibition
However they do not get the IP
Need a come up with a name for the project
Ie an identity
iSOAR is a product not an identity
University Slides 2 types
First type has text and pictures
Second type (technical slides) has text, pictures and equations
Sponsorship Letter
Call companies rst to see who is the best to address the letter to
Must email 10-20 companies this week
lxx
Bill of Materials
Excel Spreadsheet
Gives some idea of amount of money we will need

How to divide it up 1. Raw materials 2. Money for Labour 3. Everything related
to tooling 4. Testing
There is no meeting this Monday (9th March) as it is a Public Holiday.
Next Meeting will be Tuesday 10th March at 9am, S237
Action Items:
Mark
Bill of materials
New presentation for Sponsors
James
Continue RC work
Ashleigh
Wing design (with Todd)
Research about eects of aps on design
Wing Design Prelim Report
Prelim Report
Todd
Wing Design
K.5. MONDAY 16.03.09
K.5
lxxi
Monday 16.03.09
Start: 4pm
Finish: 5pm
Present: All
Apologises: None
Airfoil
Thickness ratio is constant
Trailing edge angle same
Put into Javafoil, perhaps not possible
But not big dierence
Happy with the airfoil
Todd has reviewed the other airfoils, cannot nd any faults
SD7032 is the airfoil
Measure airfoil and the one on the wing
Should be a bit thicker towards the trailing edge
Increase the aspect ratio to increase performance
Trailing edge will get quick thick with the layup
Project Def, Spec and Contract

Need to discuss
Think about worst case scenarios
Do not say improve performance
Perhaps mention take o and landing distance (improve) Student Expectation Form
OK!
lxxii
Gantt Charts
Put up a Gantt Chart for
Put all task under heading
Weekly updates on Gantt Charts and progress

Within the next 2 months should Gantt Charts and tasks should be in days and
weeks
Critical Path Method
Sponsorship
Call again in a week For next meeting Todd needs to bring
Numbers etc for Maziar to look at
Load, load distribution
Discuss in internal meetings the calculations, so that we all understand and agree
Look at fuel cell report for tongue
Pulse jet used carbon and no problems
Possible modication get rid of carbon plate on landing gear
Test manager
Need to have a plan for each test
Need to know when each test is going to be
Need to have a big picture of all testing
Who is going to y aircraft
All tests in agenda
By the end of march all the documents related to test should be ready
Begin tests in APRIL!!!
Safety operation procedure, risk assessment and supervise tests
Plan a eld test for the RC communication problem
Try to plan a test in the eld, take the aircraft there and try to communicate with
the RC and autopilot
K.5. MONDAY 16.03.09
lxxiii
Weekend of 28 and 29, plan a eld test, get a feeling for the problems, out of the city
SPPA Contract on MyUni
Parachute design
Hemispherical
Large shock waves in opening
Crucical
Other one which you can use for steering
Drop tests for the parachute
Action Items for next meeting:
Todd
Wing design
Discuss calculations with group in internal meeting
Discuss calculations with Maziar James
Field test for RC?
RC and Autopilot stu Mark
Further investigation into parachute design
Prelim report template for Lyx Ashleigh
Follow up with sponsors
Gantt Charts for the next 2 months which are daily and weekly
Technical Task
BOM
Budget
Put sponsors into excel spreadsheet
lxxiv
K.6
Monday 23.03.09
Weekly Gantt Charts

Update gantt chart according to progress
Always update the main gantt chart CPM of Project Management Sponsorship
Money is better, as a pose of going through the school
Money for exhibition on posters etc
Invoice let Maziar know, so an tax invoice can be sent
Flight power batteries
Need to hire pilot, will there be any charge incurred here?
Show that you are passionate
Remember dates of deliverables
One should observe presentation for quality, auditing, take notes and not involved in
presentation, one involved in technical things, one in management, internal auditor
Show them youre plan
Dont ask for less than $5000!
Fuel cell got $5000 last year
Testing
What we are we going to do
Get a carbon plate and put it near the aircraft, largish
Maziar has a carbon plate which is usually used for shield
Talk to Bill in the workshop, works on CNC machines, he might have something
Name each test
General conditions, ie windy, raining, measure temperature, perhaps call test conditions
Maximum temperature limitations of components
Classify tests, 4 or 5 tables with general test conditions
Prepare separate forms for day of test, general conditions, test name, expected values,
equipment list Ask Phil for motor batteries, should be some magnetic eld related to
the motor Richard Pateman for 6m pole!
K.6. MONDAY 23.03.09
lxxv
Wing Design
Matching diagram, stall requirements is , wing loading changes cruise speed should
decrease
Dont think aspect ratio of 11 is too high, Maziar believes it is too high to manufacture
as foam is delicate
Give your matching diagram, check it
Make sure we are happy
Performance calculations with new stu ie cruise speed
Verify results from software
Finalise wind loading etc by next week
Diagrams with previous year
Stability of aircraft, need to keep in range of tail volume
Wing Structural Calculations
Safety factor- always in aerospace structures is 1.5
Reserve Factor- 1.1
Load factor 3.8, designed aircraft for 38kg, then manufacture, then calculate reserve
factor
Shear web- Banshi, it has layer of carbon and foam injected inside
Finalise shear web and wing structure, produce a few options
Generate a whole picture, including the connections to the fuselage, will change the
wing tongue design, pulse jet had similar thing, carbon rods, we tried to have such a
tongue to put in the wing and carry the load, shear web with bolts can transfer the
load, structure will be rigid for the parachute
Parachute we couldnt source a good one, parachute was designed for rockets, and need
to be deployed at zero velocity, was never tested on the aircraft as believed it didnt
work, this is needed for the competition and prove it works PARACHUTE needs to
be changed, parachute of the UAVs, have a parachute which lowers landing speed but
has a high shock loading, usually two parachutes in a UAV Mark is thinking of having
a hatch which ejects with the parachute, but might hit the tail Maziar doesnt want
lxxvi
the parachute on board, for the competition need a safety regime, UAV is too small
for parachute, solve the problem of emergency, keep the parachute as last result, look
at other options
Next Meeting is Monday 30th March
K.7. MONDAY 30.03.09
K.7
lxxvii
Monday 30.03.09
Attending: All
Apologies: None
Testing
RC has range of 600m from our testing
Test close to ground
Where to next
Congure the autopilot
Need to get computer in Project Room to do this
Problem with autopilot and motor
Carbon pieces in aircraft, ie hatch , landing gear and tail, replace these with glass
bres,
o Autopilot o James to contact Micropilot about autopilot and to contact Michael
Williams (2008 work)
Send Ben an email and organise a meeting with him fortnightly
o Have discussed all these things
o Consult with him on testing/RC Communication/Autopilot issues Critical Issues
Autopilot/RC Communication problem, ie to get this working Gantt Chart to be
handed up, but Maziar really sees this as a tool for us to use. Add rc communication
to the chart because this is a critical issue
Parachute Design Nylon bolts to sheer when the parachute needs to be deployed
Have landing gear bend out, landing gear to be disrupptable 5m/s drop speed Testing
regime needs to be determined, Theoretical Design done Wants to make comparisons
with results found in tests and calculations Sensor for measuring the shock loading?
Not easy, drop test usually for large aircraft, g measurement device, static and dynamic,
drop test need a dynamic sensor, expensive and uni doesnt have one.
Small UAV like pointer for other ideas and UAV which travel around cities Somehow
try to solve this problem without using a parachute Mark to benchmark UAVs for
emergency responses
lxxviii
Competition is important but for us, we need to nish the project

Ashleigh Try to nd smaller sponsors and get smaller amounts of money, but approach
more companies
Testing Prepare safety documents, SOP (safe operation procedure (nearly test procedure)) and RA (risk assessment) Contact and get template
Risk assessment Mac Naer in workshop
All horizontal tail is carbon !
Wing Design DO not use to use blue foam, want to use H-grade polystyrene Present
drawings for wing manufacture as we want to submit it Need to know all the calculations (safety factor of 1.5 and add a reserve factor of 2-3), bring the result of the
calculation, for wing tongue, spars, aerofoil selected, pressure distribution Critical documents should be reviewed by 3 people (inclusive of the author of the report) Not
critical then 2 to review documents Discuss all modication relating to the structure
with Ben and Brad all this week Tailplane needs to be remanufactured as it is made
of carbon,laminated with carbon
Next week talk about drawing Solid carbon 3 or 4 layers, laminated probably 1 layer
K.8. MONDAY 06/04/09
K.8
lxxix
Monday 06/04/09

Apologises: None
Parachute No recovery systems, designed to y back and will crash if communication is
lost, Competition requirements do not specify a parachute, nose dive Parachute design
Large project, cant really rely on it,
Testing will try to keep the aircraft for the competition, maziar doesnt believe that
the parachute will work Might look at look at risk to return the aircraft, program the
aircraft the to y the aircraft for 1 min, Last crash was from about 10-20 m high, Try to
concentrate more time on ight termination regime that does not include a parachute
Include in the preliminary design, put parachute
Change aspect ratio but keep area the same, however there may be some problems
with the root chord, want to change aspect ratio from 8 to 11, horizontal tail is large
enough to support larger wings, DO all the calculations again and make sure they are
correct, need to be critical of the contents of the report Limit the aspect ratio of 9.2
or 9.5, 11 is too high Wing loading increase will make the wing more sensitive to wing
gusts, keep wing loading high, more aspect ratio, aps are not as eective, because
of the small chord length, keep root chord, increase the span to help for aspect ratio,
increase area by, change wing loading to 18, and increase tip length Increase the area
better take o and landing, no drop on cruise speed, wing loading decreased should be
counteracted by increase in aspect ratio CNC templates, prepare one or two templates.
Someone needs to be responsible for quality, must test the sections and have a the
other templates to check the templates, make negative of the wing prole for dierent
stages of the wing. For the rst foam cut use cheap foam to practice, second time use
the actual foam,
Yes a design review, a few pages, in introduction, talk about project denition yes, and
uses, CFS could be customers of the aircraft
One chapter in report about competition and how that aects the design of the aircraft
Testing this Thursday, looking eects of electromagnetic radiation Missiles have 10mm
AL around autopilot, look at shielding again, change position of autopilot and receiver,
so that the wires are neater as well Usually have antenna for radio control, one antenna
and one link is not reliable! Perhaps we need 2 antennas, Professor Coleman, have chat
to him about these communication issues Mark image system, look into, two students
worked in image systems in 2007, 1 mainly worked on data link, the other worked on
lxxx
selecting a camera, keep the camera we have existing , look at camera type and antenna
1. Look at ground station, what do we need? When operating one screen, 1 navigation,
1 UAV, had screen divided into 4 parts, one related to malfunction (batteries etc), one
realted to camera and the image received, one screen related to GPS coordinates,
see how to integrate these 2. Write small code for imaging processing, perhaps using
matlab image processing, look at IR cameras, image processing about a third of points,
is it hard to write a code to identify a circle
K.9. MONDAY 20/04/09
K.9
lxxxi
Monday 20/04/09
Template, 3 templates, perhaps 2 is enough as a d-nose may be too sharp to cut

Vacuum bagging makes sure there is an even distribution of resin and excess resin comes
out, need bags for vacuuming We need to understand the principles and properties of
composites and the process Water tanks in WA for vacuuming bagging
Manufacturing process for wings, sample of manufacturing process, 2 pages, Rc is
signicantly changing autopilot signal
lxxxii
K.10
Monday 27/04/09

Apologises: None
Housekeeping
Sponsorship $2000
Analogue to digital converter
Agendas- be more descriptive, should not ask anymore questions
Todd is away for a week
Carbon Rovings
Harder to use strips
Manufacturing Process
Why use method?
Why use material?
Put manufacturing process report in appendix
Can use light for post curring
Use a bit of resin to set rovings in place
2 columns, 1 for quality control for each step
Drawing Nos
Cut aps, must be perpendicular root chord and trailing edge
Tongue and Reinforcement
Central Part of wing
K.10. MONDAY 27/04/09
lxxxiii
Image Processing
Camera is ne
Digital to analogue converter not working
Colour detection and camera demonstration
Training camera to recognise someone in khaki clothes
No infrared camera
Round object - unnatural, human detection in loop
1st Stage
What we want to do limitations etc
Perhaps we need to nd something like a circle, of red colour
Contact competition and ask more information about parameters of the hat ie
what can be relied upon to be used as a parameter for the hat, colour shape
Edge detection will not be possible
Colour
Range of facial recognition has very short range
Need to add this task to the Gantt Chart
Modem Problem
Send email about this
Project Prelim
Literature Review- project description
Specication- not such a good topic title, project specication would be better
Only 3 levels and NO MORE!!
Sub-sections have to be at least a page
lxxxiv
Next week to go through prelim by chapter

For prelim 20(n+1) pages
Future Work
Todd
CAD wing joiner
Mark
Image Processing
James
Follow up modem hardboard problem
Ashleigh
Sponsorship
Prelim Report
Structural Calcs
K.11. MONDAY 04/05/09
K.11
lxxxv
Monday 04/05/09
Present: All
Apologies: None
Gantt Chart Progress
Up to date with preliminary report
Testing is being delayed by modem hardboard problem, this will not hinder the
progress of ight testing if rectied soon
Wing manufacture is technically behind schedule, it has not aected the critical
path yet. It is invisaged that the wings will be manufactured soon.
Future Work
Immediated- Wing Manufacture
Payload and release mechanism once the prelim is done
Autopilot tuning
Landing gear modication
Infrared Camera
Signature, processing, ease, cost, we dont have the money to purchase and infrared camera
Manufacturing
Need to considered the way in which the layes of berglass are layer (orientation
etc)
Preliminary Report (Intro, Design Review, Literature Review)
Feasibility study
Specication- where to put it
lxxxvi
Intro- project denition
Combine literature review and design review into Feasibility Study

Discuss matching diagram, trade study, talk about it
Do not want to say that we are just solving the problem for the project, we are
starting the project from scratch
No testing in Conceptual Design Phase
Detailed Design
Derived equations do not need refernces (ie the ones that come from rst principles)
Talk about what youre doing dont teach
Acknoledgements- Smith Fund, Sponsors, Micropilot
Structure
Use classical approach as before
Balanced- each chapter has the same amount of stu in it
K.12. MONDAY 11/04/09
K.12
lxxxvii
Monday 11/04/09
Present: James, Todd, Mark and Maziar

Apologies: Todd
Progress
Modem board xed and working
Hyperterminal thing
Image processing
850nm IR light
Swap lter for IR lter
Visual mode for camera
Analogue cameras
3 cameras perhaps
1 forward view camera for ying
Better zoom camera
(3rd) IR camera
Perhaps make these switch between the two via and electronic switch
Conceptual- make all decisions
Proof reading
Look at information management
Bar chart of hours
Internal Meeting
Balance workloads
Peer Assessment
Testing Plans
Management and Finances Section (ASH)
lxxxviii
3 Subchapters
Finances
Estimate for project
Table of money spent
Sponsorship
Management Stratergy
Method for Management
Task Distribution
Communication Methods
Meetings
Timetables
Time Management
K.13. MONDAY 25/05/09
K.13
lxxxix
Monday 25/05/09
Present: James, Todd, Mark, Todd and Maziar

Apologies: None
Wing Manufacture
Workshop at Todds mates house
Gantt Chart of Manufacturing
per day for holidays
Risk Assessment for Testing
Communication problem
Turned down signal strength
Autopilot signal to computer so that processing can be done on ground with
our eyes
Cannot boost signal to transmitter as it is already at maximum power output
Control is through data-link
James - how can we amplify signal of the remote control?
Try to amplify the signal?
Perhaps using 3 ground antennas
1 payload antenna
2 linked antennas - amplifying antenna 1
Try to test Motor and Propeller
Measure thrust
Compare eciency of dierent propellers
Measure current and voltage as well
Peer Assessment for Preliminary Report
xc
K.14
Monday 01/06/09

Apologies: None
Subchapters do not need into or place on new page
When wings are ready
Structural test
Rig for structural testing
Think about making a new fuselage in the holidays
Todd landing gear installation
Exisitng wheels are small
Currently programming ight path for autopilot
Start looking at
Pre
Flight
Post
Flight Assessments
SOP and Risk Assessment
Test camera
Need to decide whether or not we 2 cameras or which type of camera would
be good
No meeting week 13, meeting in SWOTVAC
K.15. MONDAY 15/06/09
K.15
xci
Monday 15/06/09

Apologies: None
Preliminary Report Mark
50% Group Mark for report
50% Individual mark
Resin Stu
Explain about resin, temperature and resin system
5 min presentation about the resin system and how it works
Volume fraction should be about 40-60% to bres
Manufacturing should be included in the report as the report needs to be balanced
Re-design fuselage, second fuselage minimises risk
Structural Testing
Increase weight gradually (30%, 40%, 50%, 60%, 70%, 80%)
Consider the distribution of chordwise and spanwise loadings
Listen for noise as there should be no noise
Test to 80% of max load for 30 secs
Inspect the surface after loadings
100% of max load for 5 secs
Use a camera to measure the deection caused by the load from root to tip
QA Manager
Needs spreadsheet handy with weights of everything during manufacture
Tools for manufacture and a separate way of measuring each component and
process
Need to do an engine test asap
xcii
Prelim Report
Panning, view angle , ight altitude are all related

Safety Procedures
Test Procedures
SOP for Testing
Risk Assessment for Testing
Finalise camera selection by the end of the week
Stability Scissors
Larger phugoid number for larger tail
Larger tail larger SM
Next meeting Prelim Report Run through
Next meeting
K.16. MONDAY 13/07/09
K.16
xciii
Monday 13/07/09

Apologies: None
Mark purchasing $60 Camera
Same size ccd and lens
Ring more sponsors
More action photos when manufacturing and testing
Aim to be ying by Sunday 26th July
Can do ground tests if there is no wind
Motor Testing
endurance test - use the same number of cells that are to be used in ight
Linear graph of voltage
Performance of dierent types of propellers
Need to plan for the new fuselage
Prelim Report Corrections
No uni logo on the front cover, needs to be on there
Smith Fund logo needs to be on there too
Vague sentences are underlined
Dont lecture eg denes the fundamental objectives
NW - Needs work
No intro needed for sub chapters
Subchapters can be placed on the same page
Need to provide 3 options when making a decision
Benchmarking
Component types and purposes, need to write more and use other experiences
xciv
Decision matrix could be useful for conguration design

Stat review and stat analysis needed
According to Raymer NO
Trim triangle
Appendices should be named as they are introduced in the main body
refer to CASA 101 not FAR23, refer to FAR23 if it is not stated in CASA101
Safety factor is a standard and cannot be changed, hence reserve factor is
the amount over the safety factor
Technical manager is one level above the rest of the group
Dont include money for competition in ances
Merge gantt charts
Need to look at making task distribution more even
formatting of the bar graphs
Need to type calculations cannot scan them
More explanation needed in the appendices and intros also needed
Minutes
Summary of discussion and actions
Summary at end of minutes
Next meeting
K.17. MONDAY 20/07/09
K.17
xcv
Monday 20/07/09
Present: James, Todd, Mark, Ashleigh and Maziar

Apologies: None
Open Day
Paul Grimshaw
Plasma Screen from School
Carlee organising exhibition
Fuel cell, pulsejet, morphing wing and iSOAR to be displayed
payment around $400
Engine Test
Which propeller are we going to use?
Need to conside diameter of fuselage also
Need to discuss this in a few paragraphs
Check endurance
Micropilot Autopilot
error, autopilot wont work
support purchased, should be able to get new software that works and software updates
Wings
Can ight test them without painting them
Structural test - test with ailerons in, load wings and make sure ailerons
have a full range of motion
Bring forward testing of payload, camera and ight testing due to the issues that
have arisen with the autopilot
Use Apprentice for Camera Testing
Speak to Reuben about autopilot
xcvi
New camera
ordered, will hopefully take 1 week
also no IR pass lter available ( not in stock) so homemade lter made from
developed negative to be used
Issues
We have 2 weeks before we will solve autopilot issue
One camera on board
visual image
needs to be tested in ight and with transmitter
test out of the city
also want to see if we can use camera with RC
stream video, continuous streaming? changing angle loss of signal?
Switch b/t 2 cameras
Talk to electronics workshop about this switch
Image Processing
currently working on software
not processing anything at the moment
need to check range and downlink
Mark intends to nd a white dot on screen
**Payload Mechanism Drop**
designed to be modular
get onto this asap
QA for wings
make sure at across chord
middle part of airfoil is thickest
ref points, templates, dierent wing stations, tolerance, dierence between
wing tips
angle at each end important
K.17. MONDAY 20/07/09
xcvii
ie le and te
Trim Triangle
Center of gravity range
lines nd relationship between Cm and alpha, which changes with elevator
angle
eectively elevator eectiveness
need to show that most forward and most aft cg positions, that the elevator
input is enough , +- 10 degrees to balance aircraft, enough for manoeuvring
CG envelope is combination of payloads (4 congs)
bottle
camera
autopilot
Meeting after next - seminar pres practice
slide titles
number of slides
background
xcviii
K.18
Monday 03/08/09
Present: James, Todd, Mark, Ashleigh and Maziar

Apologies: None
Structural Testing
load distribution
theoretical calculation
should measure all results
need wing stations (6 appropriate)
transfer to stepwise distribution for these wings stations from the lift
distribution
tip load 0
new sand bags, re-weigh the existing ones and re-bag them
Abotts Method needs to be done for the lift distribution
Double check the calcs and the load distribution
Put weight at quarter-chord line
Camera Testing
Downlink, antenna etc
Worked rst time
2 km down road ok
need more powerful computer
Directionality of camera is sensitive
Should have range of 10 km
If far from area of interest, antenna should not be so directional
Tracking is hard, perhaps use a compass for antenna orientation
Blanchetown perhaps
Further Development
K.18. MONDAY 03/08/09
xcix
Need to make sure everything is working and doing what we want!

Wings
Servos cut out, ailerons marked out
To be nished Tues 28/07
Need a new ight date
Wed Wk 2 this is
Monday for structural testing
Need sandbags
rig
lead
need 3 people to load wing together, one for each side and one to read
the deection
CG Measurement before rst ight
Next Meeting
Test plans
CG Measurement
Wing Test
Seminar Pres
Paparazzi
need 2 IR sensors $125 (1-2 weeks shipping time)
also need ppm encoder $25
Micropilot
NU sent
Export permit waiting on
talk to school oce (Edith)
perhaps get a phone card and call micropilot
c
Next meeting- seminar pres practice
slide titles
number of slides
background
K.19. MONDAY 03/08/09
K.19
ci
Monday 03/08/09

Apologies: None
Structural Testing
load distribution
theoretical calculation
should measure all results
need wing stations (6 appropriate)
transfer to stepwise distribution for these wings stations from the lift
distribution
tip load 0
new sand bags, re-weigh the existing ones and re-bag them
Abotts Method needs to be done for the lift distribution
Double check the calcs and the load distribution
Put weight at quarter-chord line
need to be careful of 85 mm deection, should be about 50 mm
natural frequency is low, resonance may occur
Test Plan for First Flight Test
After ground roll test stop aircraft and then check bolts etc
Appendix in Final Report with Testing Template and summarises results
year on title slide
outline rst, not intro
currently using large font
titles start from the edge
Wing Design
more slides
cii
matching diagram
No thankyou slide
2 screens
Ask in Workshop is there is anything wrong with using the 2 screens

1st ocial presentation
2nd additional material such as more pictures etc
FOCUS of PRESENTATION
James - all autopilot stu 5 mins
Mark - 5 mins for payload
Structure (as Maziar recommended)
intro etc
review 2007
autopilot
payload
testing
nding cg, structural testing etc
No Presentation stu next week
wk 4 want to see content so a Draft Presentation
no of slides
pictures
K.20. MONDAY 10/08/09
K.20
Monday 10/08/09
Present: James, Todd, Mark Ashleigh and Maziar

Apologies: None
Flight tesing
CG envelope
Dont add anything to the fuselage
Add lead to the nose
Conguration
CG at 25%
NP at 40%
SM at 15%
ciii
civ
K.21
Monday 17/08/09

Apologies: None
Flight test
Video of ight test
Measure cruise speed, take-o distance
Land as slow as possible
If stall nose down will crash!
Next week will cover next two speakers
Put on agenda 10 mins to present and 30 mins to talk about slides
K.22. MONDAY 24/08/09
K.22
cv
Monday 24/08/09

Apologies: None
Flight Test
Safe Operating Procedure
Flight test plan
Where to stand
Where we are ying
Permission for ight
Get inspected
Camera link - interference with receiver, areout from lens, need footage to start image
processing
Autopilot
Set up paparrizi
Uses Linux
Signal strength 100mV to 1V
Maziars Comments for Todd
Stance
Laser pointer
Eye contact
Stand out in front of audience
Dont use I when talking about project
James
Memorise content of slide
Transition, thank Todd
Work on eye contact
cvi
K.23
Monday 31/08/09

Apologies: None
Ashleigh and Mark Seminar Presentation
13th September for Seminar Presentation to Maziar and Brad
K.24. MONDAY 07/09/09
K.24
cvii
Monday 07/09/09

Apologies: None
No seminar presentation today
Sticker - get them
Take photos - high resolution photos for posters
Image processing
Finding objects
Get proper thermal images
Interface between software and payload mechanism - systems works with thermal camera
Flight gear - link to Paparazzi
Exhibition
Photos of aircraft including us and inside the aircraft
Flight test
Simulate target
Change mode of ight
Release bottle mechanism
Change waypoint during ight
Secondary mode - 2nd pilot just watching aircraft
Bind 2 controllers
Book S111 or S112 for seminar practice
Next meeting 14/09/09 Full Seminar Run through
cviii
K.25
Monday 07/09/09

Apologies: None
Full seminar run through
Practice needed for all of us and as a group
K.26. MONDAY 28/09/09
K.26
Monday 28/09/09
Present: James, Todd, Ashleigh and Maziar

Apologies: Mark
Must paint aircraft before any more testing is performed
Testing (to be completed before end of project)
Measure performance - airspeed
Take-o and landing performance - speed and distance
Measure climb rate
Pitch, roll, yaw rates - need to work out the procedure for this
Payload drop test
15th October no more technical work to be completed
Exhibition stu to be completed by 12th October
Video presentation to be played on the day
include everything
story, outcomes, components
run in loop all day
2 oorplan sketches
Poster
1st draft of poster
Poster
Go around and look at other posters
Use photoshop
Structure, layout, contrast, colour, pictures are all important
cix
cx
K.27
Monday 12/10/09
Present: James, Todd, Ashleigh, Mark and Maziar

Apologies: Mark
Files to give to Maziar at the end of the year
Soft copy of Final report (very important)
Soft copy of presentations
Seminar
Exhibition documentary
Exhibition poster
Competiting in the competition next year
Get the contacts
Make times for meetings
Payload drop from iSOAR
Need video
Testing for this week
Drop payload, put camera in the aircraft, then play with the autopilot
Make sure footage of the all of this is taken
Need to nd cause of inteference
Exhibition documentary
Need to change
Make 20 second video that can be watched by someone going past and still know
what the project is about
Split screens into two to show the short video and the documentary, dynamically
K.27. MONDAY 12/10/09
cxi
Draft Final report corrections

Executive summary - too long, should be 1 page and 1 paragraph at maximum
Technical task - include as last subchapter of feasibility study
Aspect ratio section needs work - statisitical analysis
Get rid of conguration table - summarise to a paragraph
Stress calcs for wing need to be included
Get rid of conclusion at end of each subchapter
Manufacturing needs quality control written into it
Also need to talk about nal assembly and other parts of the aircraft ie the
fuselage, tail
Testing - why, how, what, quantative/qualitative results, discussion of results,
make this section more formal
Gantt chart in appendix - make a table of major milestones instead
Completed tasks - change to achievements, cross reference to goals
Appendix L
CAD Drawings
cxiii
250
332
Top View
1:5
1190
870
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
UNLESS OTHERWISE SPECIFIED
DIMENSIONS ARE IN MILLIMETERS
500
356
60
A3 UAVSAR1_1
FILE NAME: Wing.dft
SIZE DWG NO
Wing Plan View

SHEET 1 OF 31
UAV Search and Rescue
38
TITLE
52
160
90
1
1
REV
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_2
FILE NAME: Wing.dft
SIZE DWG NO
Ortho Plane View
TITLE
SHEET 2 OF 31
1
1
REV
TOP
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
BOTTOM
A3 UAVSAR1_3
FILE NAME: Wing.dft
SIZE DWG NO
Wing Ortho
TITLE
SHEET 3 OF 31
1
1
REV
Passage for servo leads and pitot tube
Spar/Wing joining system
1:1
Plywood root rib

Wing fixing tab
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_4
FILE NAME: Wing.dft
SIZE DWG NO
Root
TITLE
SHEET 4 OF 31
Torsional shear pin

From pultruded carbon rod
1
1
REV
20
35
Tip Rib
1:1
159
Root Rib
1:1
150
155,5
13,8
32,5
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_5
FILE NAME: Wing.dft
SIZE DWG NO
Ribs
TITLE
SHEET 5 OF 31
Note: Tip and root ribs are to be cut out of

3mm beech plywood using acurate print outs
as a template.
1
1
REV
Wing joining sleeve fills in area

between spar caps and shear web
Carbon roving spar caps
Fibreglass Shear Web
1:2
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_6
FILE NAME: Wing.dft
SIZE DWG NO
Spar Assembly
TITLE
SHEET 6 OF 31
1
1
REV
Carbon spar cap
Fibreglass shear web
3mm deep V-shaped spar

- Use sanding block to cut
V-shapeinto core
0,5
10
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_7
FILE NAME: Wing.dft
SIZE DWG NO
Spar Root Detail
TITLE
SHEET 7 OF 31
Tongue joiner constructed using the wing joiner as a plug and wrapping
carbon fiber around it. Excess space between spar caps and
tongue sleeve is filled with cotton flock/micro balloons/epoxy
1
1
REV
18
20
30
130
140
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_8
FILE NAME: Wing.dft
SIZE DWG NO
SHEET 8 OF 31
Tongue Sleeve Detail
TITLE
1
1
REV
Material: 3 layers of lightweight fibreglass
1187
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_9
FILE NAME: Wing.dft
SIZE DWG NO
SHEET 9 OF 31

Shear Web
TITLE
13
30
1
1
REV
20
18
130
55,75
1:1
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
Wing joiner to be made of sheet pultruded carbon laminated together
A3 UAVSAR1_10
FILE NAME: Wing.dft
SIZE DWG NO
Wing Joiner
TITLE
SHEET 10 OF 31
1
1
REV
55
13,5
1:1
2,5
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
55
55
2,5
13,5
Flap Servo
Aileron Servo
65
A3 UAVSAR1_11
FILE NAME: Wing.dft
SIZE DWG NO
SHEET 11 OF 31
Servo Installation Detail
TITLE
1
1
REV
2-56 Rod
2,5
2,5
DATE
25/10/09
27/04/09
DO NOT SCALE
DRAWN
CHECKED
ENG APPR
MGR APPR
NAME
T.S.
J.H.
Aileron Pushrod
50
Flap Pushrod
70
A4 UAVSAR1_12
FILE NAME: Wing.dft
SIZE DWG NO
Pushrods
TITLE
SHEET 12 OF 31
2-56 Threaded steel clevis
REV
Servo arm protrudes through hatch
Cutout to allow for servo movement
External view
Servo mounted to hatch for easy removal
Hollow for servo wires and pitot tube
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_13
FILE NAME: Wing.dft
SIZE DWG NO
SHEET 13 OF 31
Flap Servo Installation
TITLE
Internal View (hatch removed)
JR 331 mini servo
1
1
REV
51
Balsa false spar made from 5mm sheet
306
499
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_14
FILE NAME: Wing.dft
SIZE DWG NO
Aileron
TITLE
SHEET 14 OF 31
61
1
1
REV
Balsa false spar made from 5mm sheet
320
635
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_15
FILE NAME: Wing.dft
SIZE DWG NO
Flap
TITLE
SHEET 15 OF 31
1
1
REV
73
61
Tip Template - Lower

1:1
Tip Template - Upper
Root Template - Lower
Root Template - Upper
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_16
FILE NAME: Wing.dft
SIZE DWG NO
Core Templates
TITLE
SHEET 16 OF 31
1
1
REV
Slot for fixing tab through fuselage
13
36,75
152
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_17
FILE NAME: Wing.dft
SIZE DWG NO
Wing Joining
TITLE
SHEET 17 OF 31
Plywood Doubler for trailing pin support
1
1
REV
Bottom Hatch
Drop Bracket
Standard Servo
Bottle Chute
Drop Module Bracket
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_18
FILE NAME: Wing.dft
SIZE DWG NO
Drop Module
TITLE
SHEET 18 OF 31
1
1
REV
Open
Closed
Drop module demonstrating operation
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_19
FILE NAME: Wing.dft
SIZE DWG NO
SHEET 19 OF 31
Drop Demonstration
TITLE
1
1
REV
80
100
10
12
150
90
Poly Downpipe
42,5
40
20
Heat treated to shape
85
20
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_20
FILE NAME: Wing.dft
SIZE DWG NO
Drop chute
TITLE
SHEET 20 OF 31
Blocks made of spruce and glued to pipe
1
1
REV
Fibreglass bottom hatch

81
252
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
Hole cut to fit bottle chute
87
42
A3 UAVSAR1_21
FILE NAME: Wing.dft
SIZE DWG NO
Bottom hatch
TITLE
SHEET 21 OF 31
1
1
REV
R7
3
85
3 mm Sheet Aluminium
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
47
A3 UAVSAR1_22
FILE NAME: Wing.dft
SIZE DWG NO
SHEET 22 OF 31

Drop Bracket
TITLE
10
1
1
REV
Plywood Mounting Plate
70
53
6
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
Spruce Servo Mount
8
70
11,6
A3 UAVSAR1_23
FILE NAME: Wing.dft
SIZE DWG NO
SHEET 23 OF 31
Drop Module Bracket
TITLE
7,5
1
1
REV
Autopilot Battery
Autopilot Battery
Flight Battery Packs
300
500
Modem
GPS
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_24
FILE NAME: Wing.dft
SIZE DWG NO
SHEET 24 OF 31
Electronics installation
TITLE
IR Sensors
Autopilot
Video Modem Located Below Base Frame
1
1
REV
Frame:
Front
Base Frame
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_25
FILE NAME: Wing.dft
SIZE DWG NO
SHEET 25 OF 31

Fuselage Frame
TITLE
Shear Pin Reinforcement
1
1
REV
Front
26
106
40
188
216
594
Material: 6mm Plywood
427
R3
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_26
FILE NAME: Wing.dft
SIZE DWG NO
Base Frame
TITLE
SHEET 26 OF 31
70
10
10
25
74
110
,5
R2
1
1
REV
Frame 1
150
182
0
R2
110
70
74
R7
7
69
R 20
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_27
FILE NAME: Wing.dft
SIZE DWG NO
Frame 1
TITLE
SHEET 27 OF 31
1
1
REV
Doubler x 2
70
110
90
50
48
70
98
68
Frame 2
118
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_28
FILE NAME: Wing.dft
SIZE DWG NO
Frame 2
TITLE
SHEET 28 OF 31
1
1
REV
Doubler
R5
110
90
70
73
43
50
23
Frame 3
R5
93
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_29
FILE NAME: Wing.dft
SIZE DWG NO
Frame 3
TITLE
SHEET 29 OF 31
1
1
REV
Frame 4
R 57
R5
70
70
R7
7
R2
0
20
150
182
0
R2
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_30
FILE NAME: Wing.dft
SIZE DWG NO
Frame 4
TITLE
SHEET 30 OF 31
1
1
REV
O6
Material: 3mm plywood
70
30
35
20
43
DO NOT SCALE
NAME
DATE
DRAWN
T.S.
25/10/09
CHECKED
J.H.
27/04/09
ENG APPR
MGR APPR
A3 UAVSAR1_31
FILE NAME: Wing.dft
SIZE DWG NO
SHEET 31 OF 31
Shear Pin Reinforcement
TITLE
1
1
REV

Search and Rescue UAV Design Report

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Search and Rescue UAV Design Report

Uploaded by

Copyright:

Available Formats

Design and Build a Search and Rescue

October 30, 2009

This Page Intentionally Left Blank

The completed system was demonstrated to be capable of automatically detecting and

Smith Fund Acknowledgment and Disclaimer

This Page Intentionally Left Blank

This Page Intentionally Left Blank

Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

ARCAA UAV Outback Challenge . . . . . . . . . . . . . . . . . . . . .

Optimisation of search pattern . . . . . . . . . . . . . . . . . . .

UAV Market Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Control and Communication Systems . . . . . . . . . . . . . . . . . . .

Aircraft Design Parameters

Aircraft Preliminary Sizing . . . . . . . . . . . . . . . . . . . . . . . . .

Takeo Distance Requirements . . . . . . . . . . . . . . . . . .

Matching Diagram Results . . . . . . . . . . . . . . . . . . . . .

Final Design Point . . . . . . . . . . . . . . . . . . . . . . . . .

Motor Type Selection . . . . . . . . . . . . . . . . . . . . . . . .

Electric Motor Selection . . . . . . . . . . . . . . . . . . . . . .

Electronic Speed Controller (ESC) Selection . . . . . . . . . . .

Wing Manufacture Methods . . . . . . . . . . . . . . . . . . . .

Control and Communication Systems . . . . . . . . . . . . . . . . . . .

Image Processing System . . . . . . . . . . . . . . . . . . . . . .

Comparison of Recovery Methods . . . . . . . . . . . . . . . . .

Comparison of Parachute Types . . . . . . . . . . . . . . . . . .

Payload Release Mechanism . . . . . . . . . . . . . . . . . . . . . . . .

3.10 Final Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Rudder and Elevator Sizing . . . . . . . . . . . . . . . . . . . .

Control Surface Sizing . . . . . . . . . . . . . . . . . . . . . . .

Micropilot 2028g issues . . . . . . . . . . . . . . . . . . . . . . .

Communication Systems Design . . . . . . . . . . . . . . . . . . . . . .

Review of 2007 design . . . . . . . . . . . . . . . . . . . . . . .

Investigation of possible causes . . . . . . . . . . . . . . . . . .

Aircraft Remote Control Transmitter . . . . . . . . . . . . . . .

Paparazzi Ground Control Station . . . . . . . . . . . . . . . . .

Payload Release Mechanism . . . . . . . . . . . . . . . . . . . . . . . .

Payload Release Mechanism . . . . . . . . . . . . . . . . . . . . . . . .

Electronic System Installation . . . . . . . . . . . . . . . . . . . . . . .

Completed Airframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Component Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Static Propulsion Test . . . . . . . . . . . . . . . . . . . . . . . 103

Communication Range Test . . . . . . . . . . . . . . . . . . . . 104

Imaging System Test . . . . . . . . . . . . . . . . . . . . . . . . 105

Wing Structural Test . . . . . . . . . . . . . . . . . . . . . . . . 101

Payload Release Mechanism . . . . . . . . . . . . . . . . . . . . 107

Flight Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Airframe Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Autopilot Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Imaging System Test . . . . . . . . . . . . . . . . . . . . . . . . 112

Payload Deployment Test . . . . . . . . . . . . . . . . . . . . . 114

7 Management and Finances

Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Management Delegation . . . . . . . . . . . . . . . . . . . . . . 115

Financial Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Time Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Future Work and Recommendations . . . . . . . . . . . . . . . . . . . . 122

B Matching Diagram Verication

B.1 Take O Distance Verication . . . . . . . . . . . . . . . . . . . . . . .

B.1.1 Verication point 1 . . . . . . . . . . . . . . . . . . . . . . . . .