Design and Build a Search and Rescue UAV

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 takeoff 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 flaps. The new wings dramatically reduced takeoff 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 flight 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 modified 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 efficient layup techniques. The project team intends to finish 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 Arjomandi’s guidence, experience and engineering knowledge have been invaluable to the group throughout the year. The group greatly appreciates the time and effort Dr Arjomandi has spent in ensuring the success of the project. The project received financial 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 financial 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 staff 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 findings 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 suffers any loss (financial 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 specified. Mark Eldridge

1120791

................................................................

James Harvey

1147525

................................................................

Todd Sandercock

1132146

................................................................

Ashleigh Smith

1147261

................................................................

vii


Contents Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iii

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

v

Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xx

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvi 1 Introduction

1

1.1

Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.4

Scope

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.5

Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.6

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

4

2 Feasibility Study 2.1

Mission Requirements

5 . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.1

Mission Parameters . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.2

Search Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.1.3

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

8

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 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.1.1

Configuration Review . . . . . . . . . . . . . . . . . . . . . . . .

23

3.1.2

Propeller Placement . . . . . . . . . . . . . . . . . . . . . . . .

23

3.1.3

Configuration Selection . . . . . . . . . . . . . . . . . . . . . . .

25

3.2

Aircraft Design Parameters

. . . . . . . . . . . . . . . . . . . . . . . .

25

3.3

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

26

3.3.1

Stall Requirements . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.3.2

Takeoff 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

4.2

59

Airfoil Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.1.1

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 Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

6.2

101

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

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

6.1.2

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

6.1.3

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

6.1.4

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

6.1.5

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

i

B Matching Diagram Verification

v

B.1 Take Off Distance Verification . . . . . . . . . . . . . . . . . . . . . . .

v

B.1.1 Verification point 1 . . . . . . . . . . . . . . . . . . . . . . . . .

v

B.1.2 Verification point 2 . . . . . . . . . . . . . . . . . . . . . . . . .

vi

B.2 Climb Performance Verification . . . . . . . . . . . . . . . . . . . . . .

vii

B.3 Cruise Performance Verification . . . . . . . . . . . . . . . . . . . . . . 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 Verification . . . . . . . . . . . . . . . . . . . . . . . . .

xv

E.2.3 Preliminary communication field tests . . . . . . . . . . . . . . . xvi E.2.4 Communication Long Range Verification . . . . . . . . . . . . . xix E.3 Flight testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.3.1 Proof of aerodynamic and mechanical design E.3.2 Flight performance verification

. . . . . . . . . .

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 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . .

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 . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.2

Search patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3

Creeping line search pattern . . . . . . . . . . . . . . . . . . . . . . . .

8

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 fiew of the final 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 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 configuration . . . . . . . . . . . . . . . .

80

4.18 Communication systems configuration . . . . . . . . . . . . . . . . . . .

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

Takeoff performance for various flap configurations

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 Configuration 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 specifications . . . . . . . . . . . . . . . . . . . . . . . . .

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 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 Specifications . . . . . . . . . . . . . . . . . . . . . . . .

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

Coefficient of Drag of the parachute

CH

Chord length of horizontal stabiliser

cHT

Horizontal tail volume coefficient

CLmax Maximum lift coefficient CLT O Take off configuration coefficient of lift CNC Computer Numerical Control CPU Central Processing Unit Cv

Chord length of vertical stabiliser

cV T

Vertical tail volume coefficient

CW

Average wing chord length

Cx

Parachute opening force coefficient at infinite mass conditions xxiii

D

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

g

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

k

=

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

�n

Change in load factor due to gust load

n

Number of sides in a flat 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 ( 12 ρV 2 )

R

Reefing fraction of parachute

RC

Remote Control

RF

Radio Frequency

RSO Range Safety Officer Sg

Take off 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

T

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 effective or where human life may be endangered. Though not as widely publicised as military related UAVs, significant 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 effective, affordable 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 significant 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 specifically designed for civilian applications, such as fire detection and monitoring, shark spotting, and traffic 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

2

1.2

Aim

The aim of the 2009 project was to design, manufacture and test a fixed-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 flight, 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 specified 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 specified target. • Implement an autopilot system capable of controlling the UAV outside of visible range. The desired level of autonomy includes maintaining straight and level flight, 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. The University of Adelaide

1.4. SCOPE

3

• Reduce the takeoff weight of the UAV to 9 kg or less. • Develop a system capable of determining the GPS coordinates, within 100m accuracy, of a specified 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 different applications in the civil and commercial sphere. The Outback Challenge provides a means of clearly defining the scope of the project while maintaining the fundamental features of a UAV designed for civil and commercial tasks. Though the competition rules define 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

Significance

The use of UAVs offers significant benefits in a variety of civil and commercial applications. The lack of a human pilot is a significant advantage as it eliminates the risk to a pilot’s life, significantly 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 flexibility for adjusting to a customer’s needs (Sarris 2001). Some of the applications for which UAVs can be utilised include search and rescue, coast watch, border patrol, bushfire detection and monitoring, traffic monitoring, mapping Design and Build a Search and Rescue UAV

CHAPTER 1. INTRODUCTION

4

and surveying, surveillance, and media coverage. In each of these applications, replacing a manned aircraft with a UAV has the potential to significantly 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 fly 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 find 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.

The University of Adelaide

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 influenced 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 define the aircraft’s required cruise speed, which in turn had a significant impact on other performance and systems requirements. It was assumed that designing the UAV’s performance specifically for search and rescue missions would not prevent it from performing other surveillance missions, such as coastwatch, border patrol, shark spotting and bushfire monitoring. The optimum strategy was defined as the strategy which would maximise the probability of finding 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 flight corridor, mission boundary and search area predefined in the rules of the competition. The flight corridor is approxiamately 0.2 nautical miles (0.3 km) by 1 nautical miles (1.8km), and the vehicle must stay within this flight 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 defined 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 flying at an altitude between 200ft and 400ft (though permission can be attained from CASA to fly to 1500ft), with the exception of take-off and landing. If at any time the vehicle exits the mission boundary, the vehicle’s mission is terminated by the Range Safety Officer (RSO). Figure 2.1, illustrates the flight corridor, mission boundary and search area.

Figure 2.1: Search and Rescue Area The University of Adelaide

2.1. MISSION REQUIREMENTS

7

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 fluid safely to him. The fluid 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 subject’s whereabouts, as the search pattern can begin and be centred around the area of highest probability. In this way the time taken to find 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, effectively 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 inefficient use of the allowed search time. Furthermore, it is generally Design and Build a Search and Rescue UAV


8

difficult 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 affected 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 subject’s 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 modified 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 spreadsheet’s input parameters included: The University of Adelaide

2.1. MISSION REQUIREMENTS

9

• Cruise altitude: Increasing the cruise altitude increases the sweep width (width of ground seen in camera’s 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 field of view (HFOV): Coupled with cruise altitude, HFOV determines the UAV’s 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 figure 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 spreadsheet’s 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 fixed 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. Design and Build a Search and Rescue UAV


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 profiles. This demonstrated the feasibility of the intended design and the expected level of performance. The surveillance UAV’s analysed included the 2007 iSOAR aircraft, Aerosonde, ScanEagle, Silver Fox and CryoWing. 2007 iSOAR Aircraft The iSOAR UAV, depicted in figure 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 configuration 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-off and landing. Aerosonde The UAV Aersonde, indicated in figure 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-off 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. The University of Adelaide

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-off 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 configuration, and a 1.9hp 2-stroke internal combustion engine. Design and Build a Search and Rescue UAV

12


Figure 2.6: The Insitu/Boeing ScanEagle UAV (CNet 2007). Silver Fox Silver Fox, indicated in figure 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 configuration with a wing span of 2.1 m and a maximum take-off weight of 11.3 kg. It incorporates a modular design, which can be suited for a number of different 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) The University of Adelaide

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 figure 2.8, CryoWing has a wing span of 3.8 m, a maximum take-off 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 UAV’s 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 flight industry and for research applications. Companies involved in the manufacture of these systems include Micropilot, Cloudcap Technology, Procerus Technologies and Design and Build a Search and Rescue UAV


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 significant distance away. Some examples of the use of these autopilot systems are given below. CryoWing Micropilot’s 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 flight 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 flight, with takeoff 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 specified by the project goals. The University of Adelaide

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 different requirements compared to a ground-based system, and the use of image processing tools for automonous identification 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 aircraft’s camera for manual identification 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). Design and Build a Search and Rescue UAV


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 The University of Adelaide

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 flown 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 flown 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 flight, and can also reduce weight (although the need for strengthened wings can reduce this advantage). Design and Build a Search and Rescue UAV

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 flight, 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. The University of Adelaide

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. • Configure 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 vehicle’s 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 Design and Build a Search and Rescue UAV


20

Safety Authority (CASA), the governing body of Australia’s 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-off 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 specified 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. Takeoff and Landing The takeoff and landing distance of the aircraft is limited to the ARCAA Outback Challenge runway length of 1600m. However, smaller takeoff and landing distances are desirable in order for the UAV to be flexible 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 UAV’s minimum endurance will be 1 hour and 15 minutes of continuous flight in accordance with the maximum mission time allowed for the Outback Challenge. The University of Adelaide

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 flight, excluding takeoff 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 fit in a standard station wagon. This would greatly improve its ease of transportation and the flexibility of its operations. In addition, the components of the airframe must be capable of withstanding the stresses imposed on them during all flight 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 sufficient 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 UAV’s flight path mid-flight. 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 flight data at the ground station and asserting manual commands. Onboard batteries are required to power the autopilot and modem. Their capacity should be sufficient 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 Design and Build a Search and Rescue UAV

22


Section 2.1), the camera requires a horizontal field 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 sufficient 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 inflicted 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 Configuration

The choice of aircraft configuration is an important decision, and can drastically affect 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 configration was reasonably restricted.

3.1.1

Configuration Review

A review of possible airframe configurations was performed. Good stability and controllability were desirable characteristics for maximising the reliability of autonomous flight, while high efficiency and low weight were beneficial 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 configuration was the most beneficial 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 significant impact on the performance and maintenance requirements of the aircraft. 23

CHAPTER 3. CONCEPTUAL DESIGN

24

Table 3.1: Airframe Configuration Decision Matrix Criteria Controllability Stability Efficiency 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 configurations are: • ’Tractor’ or ’Puller’ – This configuration is the most common configuration 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 configuration · Ideal weight location for aircraft centre of gravity ∗ Disadvantages · Prevents placement of imaging or communications equipment in the nose of the aircraft • ’Pusher’ – This configuration has the propellor mounted behind the fuselage, ’pushing’ the aircraft through the air. ∗ Advantages · Improved aerodynamic efficiency, as propellor wash does not flow over aircraft wing · Aircraft nose can be used for imaging or communications equipment ∗ Disadvantages · Aircraft take-off 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 effect on aircraft centre of gravity The University of Adelaide

3.2. AIRCRAFT DESIGN PARAMETERS

3.1.3

25

Configuration 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 configuration 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 configuration was deemed the most effective configuration for the redesigned aircraft, due to its inherent stability and manufacturability advantages over most other configurations. For these reasons, a conventional aircraft configuration was chosen for use on the 2009 Search and Rescue UAV, with the propellor placed in the aircraft nose in a tractor configuration.

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 efficiency of the wing at the expense of higher structural weight, while a lower aspect ratio will conserve structural weight but have a lower aerodynamic efficiency (Raymer 2006). It was decided that an aspect ratio of 10 would be an effective balance between aerodynamic and structural efficiency 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. Design and Build a Search and Rescue UAV


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 flow (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. The University of Adelaide

3.3. AIRCRAFT PRELIMINARY SIZING

3.3.1

27

Stall Requirements

Given the desired stall speed and a known maximum lift coefficient for the aircraft, the required maximum wing loading was calculated using the following equation:

W/S

1 2 CLmax = ρVstall 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

Takeoff Distance Requirements

The takeoff distance requirements provide a maximum power loading for the aircraft, given the minimum length of runway the aircraft is designed to take off from. A shorter runway will require a lower power loading (corresponding to a higher power engine). The desired maximum takeoff 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 aircraft’s mission flexibility. This was an important consideration from a marketing perspective, but was also essential to allow adequate flight testing of the aircraft. Obstacle clearance was not considered, as any airfield used for takeoff would likely be several times larger than 50m. To find takeoff length (Sg ) the following equation was used:

Sg =

�

1 2gKA

�

ln

�

2 KT + KA VLOF KT

�

(3.3)

Where:

KA =

2

� ρ � 2 � W � −CD0 − KCLT + µC LT O O S

Design and Build a Search and Rescue UAV

(3.4)


28

KT =

3.3.3

T −µ W

(3.5)

Climb Requirements

The climb requirements for the aircraft are specified by CASA, and must be met if the aircraft is to be certified. 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

� � �2 �� 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. The University of Adelaide

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

1237827 10

0 0

5

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 off requirements. Although the desired stall speed is not a fixed requirement for this aircraft, keeping the stall speed as low as possible aids with low speed flying such as on an approach to land. In this important stage of flight 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 takeoff weight of 11kg, and this value was used as an initial estimate of the final 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 final design point for the aircraft is therefore:

3.4

W/P

= 11

kg/kW

W/S

= 16

kg/m2

Propulsion System

A propeller driven aircraft was selected given the preference for high engine efficiency 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 off 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. The University of Adelaide

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 UAV’s 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 flight industry and in research applications has increased in recent years due to significant improvements in battery technology. The large storage capabilites of lithium polymer (LiPo) batteries have had a significant impact on this increase. Electric motors are noted for their relatively high efficiency 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 beneficial than a brushed DC motor, as they experience less frictional losses and are therefore more efficient 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 efficiency 2 4 Level of maintenance 3 5 Ease of implementation 3 4 Environmental impact 2 5 Total 14 20 Design and Build a Search and Rescue UAV


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 Efficiency 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 significant 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 manufacturer’s recommendations and confirmed 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. The University of Adelaide

3.4. PROPULSION SYSTEM

3.4.5

33

Motor Batteries

There were two battery types, which had sufficient 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 Type of Battery Lithium-Polymer Nickel Metal Hydride

Voltage (V)

Charge (Ahr)

Weight (g)

11.1 10.8

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 manufacturer’s recommendations for the AXI 4130-20 are listed in Table 3.8 (Model Motors 2009). Table 3.8: AXI 4130-20 specifications η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. Design and Build a Search and Rescue UAV


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 film. 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) The University of Adelaide

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 differences 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 finish 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 off of the plug. Design and Build a Search and Rescue UAV


36

3.5.2

Selection

Hollow moulded wings provide the most accurate manufacture and the best surface finish. 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 insignificant. 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 specifications for the control and communications systems were derived from the mission requirements.

3.6.1


A number of different flight regimes were analysed to determine the UAV’s mission requirements including: • Take-off and landing The University of Adelaide


37

• Search • Loiter over target • Payload deployment • Emergency recovery Takeoff and Landing It was desired that takeoff 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 flight. For takeoff, 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 predefined 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 flight data be returned to the ground station. This may include sensor reports, position monitoring, etc. It is also expected that the mission profile be able to be modified during flight. 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 identified, 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 identified 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. Design and Build a Search and Rescue UAV


38 Payload Deployment

After confirmation 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 takeoff, landing, recovery in the event of an emergency and close range flight 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 Specifications A six channel RC system is required such that the pilot has control over throttle, ailerons, flaps, 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: The University of Adelaide


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 different frequencies, creating a redundant radio frequency (RF) path. • The utilisation of dual receivers, each of which are exposed to a different RF environment. System Selection The DX7 Spektrum as shown in Figure 3.4 appeared to offer 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 significantly 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) Design and Build a Search and Rescue UAV


40

3.6.3

Autonomous control

An autopilot system is required to control the UAV throughout all stages of flight excluding takeoff 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 Specifications Based on the mission requirements, the following design specifications were made. • Capable of autonomous control during all stages of flight excluding takeoff and landing. • Minimum of 7 servo control pins for direct control over the throttle, separate ailerons, flaps, elevator, rudder and payload deployment. • GPS waypoint navigation • Manual override • In-flight monitoring capability • In-flight 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 flight and sending flight data back to the groundstation via the modem pair. The autopilot utilises Proportional Integral Derivative (PID) control loops, which need to be tuned during flight 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 configuring the autopilot, generating flight plans and monitoring the UAV during flight. 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 configurable. The University of Adelaide


41

The 2028g and RF modems meet the minimum requirements set out by the design specifications. 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 flexible 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 significant 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 significantly shorter lead time than other commercial autopilots. Therefore, paparazzi was identified as a feasible alternative in case the Micropilot 2028g was to fail during the project. Design and Build a Search and Rescue UAV


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, traffic monitoring, bushfire early warning - all of these tasks require the aircraft to be able to see it’s surroundings and transmit this information to a ground station.

3.7.1

Requirements

As a specific primary goal, the newly designed imaging system was required to be capable of autonomously detecting and tracking the lost bushwalker specified 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 confirmation of the state of the aircraft, as well as a visual guide for landing and performing manoeuvres. The inclusion of autonomous target detection is beneficial 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 identification of a target simply due to the long period of intense concentration required (Kruegle 1996). Automated identification of objects of interest significantly reduces this fatigue level, only requiring operator attention in order to confirm a potential target. The field 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). The University of Adelaide

3.7. IMAGING SYSTEM

3.7.2

43

Problem Description

Target Characteristics As specified 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 fixed 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 simplifies the detection of the bushwalker, as a camera configured 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” filters 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 fire detection). Design and Build a Search and Rescue UAV


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 sufficient resolution to allow identification 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 modified, although too small a viewing angle could potentially require the aircraft to fly 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 specifications 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 specified 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 sufficient 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 identification of unusually coloured objects or objects which are easily distinguishable from natural formations, and is also beneficial for final confirmation 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 The University of Adelaide

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 firefronts 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 effective method of detecting the ARCAA Outback Challenge target. Purchase of an inexpensive monochrome security camera, combined with an IR-Pass filter 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 confirmation 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 Design and Build a Search and Rescue UAV


46

directional receiver dish for the ground station. Use of this system would save sigificant 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 suffer 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 effective 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 effectively 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. The University of Adelaide

3.7. IMAGING SYSTEM

47

Matlab Matlab is a system in use throughout the engineering and scientific 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 files) familiar to most scientific 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 significant 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 final imaging system for the 2009 aircraft will consist of an infrared-capable security camera with an IR-pass filter, 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. Design and Build a Search and Rescue UAV


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 affecting 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 takeoff, 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 flying 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, significantly 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 fixed, ground-based system would not be suitable for recovery of the aircraft in the event of communication being lost during flight. 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 The University of Adelaide

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 sacrificing aircraft performance) would not be found. In addition, it would be unlikely that any selected system could be effectively 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 suffer 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 affect 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 effectively select a suitable solution.

3.8.2

Comparison of Parachute Types

Three main types of parachute were considered for use in the 2009 aircraft: Design and Build a Search and Rescue UAV


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 coefficient, 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 coefficient, 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 differently from simple drag-generating designs such as hemispherical and spherical parachutes. Technically, a parafoil is classed as a semi-rigid airfoil, using airflow 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 The University of Adelaide

3.8. RECOVERY SYSTEM

51

volume on the aircraft. Therefore, a high efficiency (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, sacrificing 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 coefficient 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:;@ &'(&)(! (%*+#,," -*"+#,," !#2( #,,"1A(! .%/(00+12'("$30(+0,(&343(! !3-(%031%0+#"(+3%+-3//3-(2("0 #%*/(0+56768 9+,/+56766+:+,/+567666

-;F;C -;BC+"=D@E= 232/(

!?MN+!=OMBDK?>KHMB The bottle holder is pivoted inside the aircraft fuselage to release the payload, with a! 03F( !$*+%1 "(< "# .#


H.1. AIRFRAME FILE

xxxv


APPENDIX H. PAPARAZZI CODE

xxxvi


H.1. AIRFRAME FILE

xxxvii

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 Design and Build a Search and Rescue UAV


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

H.2

Flightplan File
#include "datalink.h" #include "bomb.h" #include "OSAMNav.h" The University of Adelaide

H.2. FLIGHTPLAN FILE

xli



xlii


H.2. FLIGHTPLAN FILE Design and Build a Search and Rescue UAV

xliii


xliv


H.2. FLIGHTPLAN FILE

xlv



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 PROCESSING CODE 28/10/09 11:45 AM

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(); mis[0] = new MemoryImageSource(camWidth, camHeight, cv.pixels(), 0, camWidth); viewPanel.setImage(createImage(mis[0])); break; case VIEW_MODE_THRESHOLD: // Perform processing cv.convert(OpenCV.GRAY); cv.invert(); cv.threshold(threshold); mis[0] = new MemoryImageSource(camWidth, camHeight, cv.pixels(), 0, camWidth); viewPanel.setImage(createImage(mis[0])); break; case VIEW_MODE_FINAL: // Pull image out before we mangle it mis[0] = new MemoryImageSource(camWidth, camHeight, cv.pixels(), 0, camWidth); // Perform processing cv.convert(OpenCV.GRAY); cv.invert(); cv.threshold(threshold); blobs = cv.blobs(minBlobSize, maxBlobSize, maxBlobsToFind, true, OpenCV.MAX_VERTICES*4); viewPanel.setImage(createImage(mis[0])); viewPanel.setBlobs(blobs); break; case VIEW_MODE_4VIEW: // First panel - show feed unchanged mis[0] = new MemoryImageSource(camWidth, camHeight, cv.pixels(), 0, camWidth); images[0] = createImage(mis[0]); // Second panel - show greyscale/inverted feed cv.convert(OpenCV.GRAY); cv.invert(); mis[1] = new MemoryImageSource(camWidth, camHeight, cv.pixels(), 0, camWidth); images[1] = createImage(mis[1]); // Third panel - show greyscale, inverted, thresholded cv.threshold(threshold); mis[2] = new MemoryImageSource(camWidth, camHeight, cv.pixels(), 0, camWidth); images[2] = createImage(mis[2]); // Fourth panel - show original feed with blobs highlighted images[3] = createImage(mis[0]); blobs = cv.blobs(minBlobSize, maxBlobSize, maxBlobsToFind, true, OpenCV.MAX_VERTICES*4); viewPanel.setFourViewImages(images); viewPanel.setBlobs(blobs); 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

l

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) new IvyMessageListener() { bus.bindMsg("(NAVIGATION( .*|$))", // dist to home (m^2) public void receive(IvyClient client, String[] args) { // circle count st = new StringTokenizer(args[1], " "); StringTokenizer // oval block = count 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

}

public void receive(IvyClient navigationMessage = true; client, String[] args) { StringTokenizer st = new StringTokenizer(args[1], " "); } 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 = Float.valueOf(st.nextToken())/10; (decideg) bus.bindMsg("(GPS( .*|$))", new IvyMessageListener()//course { alt = (Float.valueOf(st.nextToken()).floatValue())/100; //Altitude (m) st.nextToken();// speed (cm/s) public void receive(IvyClient client, String[] args) { st.nextToken();// (cm/s) StringTokenizer stclimb = newrate StringTokenizer(args[1], " "); 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 utm_zone utm_north= =(Integer.valueOf(st.nextToken()).intValue());// 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 public void receive(IvyClient client, String[] args) { GPSMessage = true; } StringTokenizer st = new StringTokenizer(args[1], " "); }); phi = Float.valueOf(st.nextToken()); // phi (rad) = roll (rad) psi = Float.valueOf(st.nextToken()); // psi (rad) = heading (rad) // Attitude messages theta = Float.valueOf(st.nextToken()); // theta (rad) = pitch (rad) bus.bindMsg("(ATTITUDE( .*|$))", new IvyMessageListener() { } }); public void receive(IvyClient client, String[] args) {

bus.start(port); StringTokenizer st = new StringTokenizer(args[1], " "); 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 sendTarget(int target_no) { tryvoid { int send_x = (int) (targetX * 100); bus.sendMsg("ME JUMP_TO_BLOCK 2 " + block); int send_y = (int) (targetY } catch (IvyException e) { * 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 send_x = send_x (int) (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); } catch (IvyException e) { // 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 double finalX; dx; double double finalY; dy;

double = heading; double headingDegrees finalX; double double headingRadians; finalY; double double double double double

theta; headingDegrees = heading; alpha; headingRadians; r;

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

theta = Math.atan2(dx, dy); px, h, hfov); dx = PixelToDistance(width, 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 -= Math.PI; alpha = theta + headingRadians; } 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 || block == 10) { finalX = r== * 9 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 System.out.println("Block out ofpaparazzi range"); communication yet"); } }

} 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 = double h * Math.tan(Math.toRadians(fov)/2); public PixelToDistance(double width, double p, double h, double fov){ d = (p*w/width)-(w/2); double w; return double d; 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 configuration procedures and the developed flight plans. Although it was not implemented in the final 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 firmware (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 Configuration

Autopilot Configuration 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 configured using the configuration 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 artificial horizon. 6. No AGL is installed therefore adjust the autopilot accordingly. 7. Select “separate flaperons” for the servo configuration. A normal tail configuration 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 different 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 configuration 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. The University of Adelaide

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 off.

J.3

Micropilot Flight Plans

//Primary flight path Imperial //Use imperial units takeoff climb 300 //climb to 300 feet waitClimb 200 //commence next step once reached 200 feet flyTo ( 1000, 1000) //follow a square path (1000=38.1m) as search path not yet developed flyTo ( 1000,-1000) flyTo (-1000,-1000) flyTo (-1000, 1000) repeat -4 //repeat path indefinitely //Pattern 0 – Loiter above target Design and Build a Search and Rescue UAV

lvi


definePattern 0 [rotatePattern]=[currentHeading] //rotate relative waypoints to coincide with current heading flyTo (500,500) //follow figure 8 flight pattern (500=19.05m) flyTo (0,0) flyTo (-500,-500) flyTo ( 500,-500) flyTo (0,0) flyTo (-500,500) repeat -6 //repeat pattern indefinitely // Pattern 1 – Payload deployment definePattern 1 [fServo7]=32000 //Deployment servo at full position return //Pattern 2 – Return to home definePattern 2 flyTo(26.59949S,151.84306E) //Initially fly to throat of flight corridor fromTo[home] //Return to home repeat -1 //Pattern3 – Flight termination definePattern 3 [stopEngine]=1 //Engine off [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 flap down [fServo5]=32000 //left flap down wait 99999 // RC failure pattern definePattern rcFailed flyTo [home] //Attempt to fly home The University of Adelaide

J.3. MICROPILOT FLIGHT PLANS repeat -1 //Horizon communication link failure pattern definePattern gcsFailed wait 10 //wait 2 seconds flyTo[home] //Attempt to return to base wait 15 //wait 3 seconds [stopEngine]=1 //Engine off [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 flap down [fServo5]=32000 //left flap down wait 99999 //GPS failure pattern definePattern 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 definePattern engineFailed [elDrivesAlt]=0 //elevator controls airspeed climb 0 //set-up to descend to the ground turn [runwayDirection] //turn into wind wait 99999 Design and Build a Search and Rescue UAV

lvii

lviii


//Low battery voltage definePattern batVFailed climb 0 //set-up to descend to the ground turn [runwayDirection] //turn into wind [elDrivesAlt]=0 //elevator controls airspeed [stopEngine]=1 //turn off 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 offthem • Get in touch with Michael Williams • Contact school office 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 coefficient is dependent on the airfoil 2. Manufacturing (Todd and James) The University of Adelaide

K.1. TUESDAY 3.2.09

lxi

• Look at procedure • Different types of materials 3. Autopilot communication problem (James) • Interference- autopilot and payload, autopilot and carbon fibre 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 definition) 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 definition • 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 office 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 – Identified likely causes and required modifications. Currently generating test procedure. • Contact Michael Williams – Waiting on contact details from Ben and Brad. • Email school office regarding software – Waiting till after speaking with Ben, Brad and Michael. • Project Definition – Completed. o Wing materials and manufacture research – In progress. The University of Adelaide

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 office 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 • Don’t make them so specific 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. The University of Adelaide

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 first • 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 fibe • Engine on test engine off test • Range test we test along runway, don’t 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. Design and Build a Search and Rescue UAV


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 flight tests! • Structural design for small UAVs for MAA, standard for operation, when they operating last time, they operated from a MAA airfield as long as you never switch on the auto-pilot • Its over 7kg it can be flown by a large aircraft operator. Pilot signed forms to fly aircraft. • Need to find a place to fly the aircraft as a model, need to find a place to fly 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 find a place to fly. 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 The University of Adelaide

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 find a place to legally fly iSOAR • First thing – fixing 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 (don’t need supervisor) • Use clear fonts, such as Arial, Arial Narrow, font we used was also fine, needs to be readable • It is for commercial purposes therefore needs to be attractive, have animations, pictures, videos etc. • Doesn’t need to be as technical • Needs Slide numbers • Pictures need to have captions • Ever slide should have pictures • Different size fonts on different 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 flowchart 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 The University of Adelaide

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 UAV’s, search and rescue applications, examples of that, Importance of UAV’s, shark patrols, for bushfire 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 first to see who is the best to address the letter to • Must email 10-20 companies this week Design and Build a Search and Rescue UAV


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 effects of flaps 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 difference • Happy with the airfoil • Todd has reviewed the other airfoils, cannot find 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 off and landing distance (improve) Student Expectation Form OK! Design and Build a Search and Rescue UAV


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 modification 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 fly 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 field test for the RC communication problem • Try to plan a test in the field, take the aircraft there and try to communicate with the RC and autopilot The University of Adelaide

K.5. MONDAY 16.03.09

lxxiii

• Weekend of 28 and 29, plan a field test, get a feeling for the problems, out of the city SPPA Contract on MyUni Parachute design • Hemispherical Large shock waves in opening • Crucifical • 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 stuff 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 you’re plan • Don’t 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 field related to the motor Richard Pateman for 6m pole! The University of Adelaide

K.6. MONDAY 23.03.09

lxxv

Wing Design • Matching diagram, stall requirements is , wing loading changes cruise speed should decrease • Don’t 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 stuff 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 couldn’t 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 didn’t 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 doesn’t want Design and Build a Search and Rescue UAV


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 • Configure 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 fibres, 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 doesn’t 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 Design and Build a Search and Rescue UAV


lxxviii

Competition is important but for us, we need to finish the project Ashleigh Try to find 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 modification 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

Present: Maziar, Ashleigh, James, Mark and Todd Apologises: None Parachute No recovery systems, designed to fly 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 doesn’t believe that the parachute will work Might look at look at risk to return the aircraft, program the aircraft the to fly the aircraft for 1 min, Last crash was from about 10-20 m high, Try to concentrate more time on flight 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, flaps are not as effective, 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 off 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 profile for different stages of the wing. For the first 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 definition yes, and uses, CFS could be customers of the aircraft One chapter in report about competition and how that affects the design of the aircraft Testing this Thursday, looking effects 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 Design and Build a Search and Rescue UAV

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 significantly changing autopilot signal



lxxxii

K.10

Monday 27/04/09

Present: Maziar, Ashleigh, James, Mark and Todd 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 flaps, must be perpendicular root chord and trailing edge Tongue and Reinforcement • Central Part of wing The University of Adelaide

K.10. MONDAY 27/04/09

lxxxiii

Image Processing • Camera is fine • 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 find 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 • Specification- not such a good topic title, project specification would be better • Only 3 levels and NO MORE!! • Sub-sections have to be at least a page Design and Build a Search and Rescue UAV


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 flight testing if rectified soon • Wing manufacture is technically behind schedule, it has not affected 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 modification Infrared Camera • Signature, processing, ease, cost, we don’t have the money to purchase and infrared camera Manufacturing • Need to considered the way in which the layes of fiberglass are layer (orientation etc) Preliminary Report (Intro, Design Review, Literature Review) • Feasibility study • Specification- where to put it Design and Build a Search and Rescue UAV


lxxxvi • Intro- project definition

• 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 first principles) • Talk about what you’re doing don’t teach • Acknoledgements- Smith Fund, Sponsors, Micropilot • Structure – Use classical approach as before – Balanced- each chapter has the same amount of stuff 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 fixed and working • Hyperterminal thing • Image processing – 850nm IR light – Swap filter for IR filter – Visual mode for camera – Analogue cameras – 3 cameras perhaps ∗ 1 forward view camera for flying ∗ 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) Design and Build a Search and Rescue UAV


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 Todd’s mate’s 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 efficiency of different propellers – Measure current and voltage as well • Peer Assessment for Preliminary Report



xc

K.14

Monday 01/06/09

Present: James, Todd, Mark, Todd and Maziar 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 flight 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

Present: James, Todd, Mark, Todd and Maziar Apologies: None • Preliminary Report Mark – 50% Group Mark for report – 50% Individual mark • Resin Stuff – 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 fibres • 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 deflection 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 Design and Build a Search and Rescue UAV


xcii • Prelim Report

– Panning, view angle , flight 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

Present: James, Todd, Mark, Todd and Maziar Apologies: None • Mark purchasing $60 Camera – Same size ccd and lens • Ring more sponsors • More action photos when manufacturing and testing • Aim to be flying 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 flight – Linear graph of voltage – Performance of different 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 – Don’t lecture eg “defines 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 Design and Build a Search and Rescue UAV


xciv

– Decision matrix could be useful for configuration 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 – Don’t include money for competition in fiances – 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 won’t work – support purchased, should be able to get new software that works and software updates • Wings – Can flight 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 flight testing due to the issues that have arisen with the autopilot – Use Apprentice for Camera Testing – Speak to Reuben about autopilot Design and Build a Search and Rescue UAV


xcvi • New camera – ordered, will hopefully take 1 week

– also no IR pass filter available ( not in stock) so homemade filter 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 flight 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 find a white dot on screen • **Payload Mechanism Drop** – designed to be modular – get onto this asap • QA for wings – make sure flat across chord – middle part of airfoil is thickest – ref points, templates, different wing stations, tolerance, difference between wing tips – angle at each end important The University of Adelaide

K.17. MONDAY 20/07/09

xcvii

∗ ie le and te • Trim Triangle – Center of gravity range – lines find relationship between Cm and alpha, which changes with elevator angle – effectively “elevator effectiveness” – 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 configs) ∗ 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 – Abott’s 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 first 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 The University of Adelaide

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 finished Tues 28/07 • Need a new flight 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 deflection • CG Measurement before first flight • 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 office (Edith) – perhaps get a phone card and call micropilot Design and Build a Search and Rescue UAV


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

Present: James, Todd, Mark, Todd 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 – Abott’s 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 deflection, 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 • Seminar Presentation – year on title slide – outline first, not intro – currently using large font – titles start from the edge ∗ Wing Design · more slides Design and Build a Search and Rescue UAV


cii · matching diagram – No thankyou slide – 2 screens

∗ Ask in Workshop is there is anything wrong with using the 2 screens · 1st official presentation · 2nd additional material such as more pictures etc – FOCUS of PRESENTATION ∗ James - all autopilot stuff 5 mins ∗ Mark - 5 mins for payload – Structure (as Maziar recommended) ∗ intro etc ∗ review 2007 ∗ autopilot ∗ payload ∗ testing · finding cg, structural testing etc • No Presentation stuff 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 • Don’t add anything to the fuselage • Add lead to the nose • Configuration – CG at 25% – NP at 40% – SM at 15%


ciii


civ

K.21

Monday 17/08/09

Present: James, Todd, Mark Ashleigh and Maziar Apologies: None Flight test • Video of flight test • Measure cruise speed, take-off distance • Land as slow as possible • If stall nose down will crash! Seminar Presentation • 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

Present: James, Todd, Mark Ashleigh and Maziar Apologies: None Flight Test • Safe Operating Procedure • Flight test plan – Where to stand – Where we are flying – Permission for flight – Get inspected Camera link - interference with receiver, flareout from lens, need footage to start image processing Autopilot • Set up paparrizi • Uses Linux • Signal strength 100mV to 1V Maziar’s Comments for Todd • Stance • Laser pointer • Eye contact • Stand out in front of audience • Don’t use I when talking about project James • Memorise content of slide • Transition, thank Todd • Work on eye contact Design and Build a Search and Rescue UAV


cvi

K.23

Monday 31/08/09

Present: James, Todd, Mark Ashleigh and Maziar 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

Present: James, Todd, Mark Ashleigh and Maziar 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 flight • Release bottle mechanism • Change waypoint during flight • 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

Present: James, Todd, Mark Ashleigh and Maziar 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-off 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 stuff 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 floorplan 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 find 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 The University of Adelaide

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 configuration 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 final 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

11

REV

DO NOT SCALE



SIZE DWG NO

Ortho Plane View

TITLE

SHEET 2 OF 31


11

REV

TOP

DO NOT SCALE


BOTTOM


SIZE DWG NO

Wing Ortho

TITLE

SHEET 3 OF 31


11

REV

Passage for servo leads and pitot tube

Spar/Wing joining system

1:1

Plywood root rib Wing fixing tab

DO NOT SCALE



SIZE DWG NO

Root

TITLE

SHEET 4 OF 31


Torsional shear pin From pultruded carbon rod

11

REV

20

35

Tip Rib 1:1

159

Root Rib 1:1

150

155,5

13,8

32,5

DO NOT SCALE



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.

11

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



SIZE DWG NO

Spar Assembly

TITLE

SHEET 6 OF 31


11

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



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

11

REV

18

20

30

130

140

DO NOT SCALE



SIZE DWG NO

SHEET 8 OF 31

Tongue Sleeve Detail

TITLE


11

REV

Material: 3 layers of lightweight fibreglass

1187

DO NOT SCALE



SIZE DWG NO

SHEET 9 OF 31

UAV Search and Rescue Shear Web

TITLE

13

30

11

REV

20

6

18

130

55,75

1:1

DO NOT SCALE


Wing joiner to be made of sheet pultruded carbon laminated together


SIZE DWG NO

Wing Joiner

TITLE

SHEET 10 OF 31


11

REV

55

13,5

1:1

2,5

DO NOT SCALE


55

55 2,5 13,5

Flap Servo

Aileron Servo

65


SIZE DWG NO

SHEET 11 OF 31

Servo Installation Detail

TITLE


11

REV

2-56 Rod

2,5

2,5

DATE 25/10/09 27/04/09

DO NOT SCALE

DRAWN CHECKED ENG APPR MGR APPR UNLESS OTHERWISE SPECIFIED DIMENSIONS ARE IN MILLIMETERS

NAME T.S. J.H.

Aileron Pushrod

50

Flap Pushrod

70


SIZE DWG NO

Pushrods

TITLE

SHEET 12 OF 31


2-56 Threaded steel clevis

1

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



SIZE DWG NO

SHEET 13 OF 31

Flap Servo Installation

TITLE


Internal View (hatch removed)

JR 331 mini servo

11

REV

51

Balsa false spar made from 5mm sheet

306 499

DO NOT SCALE



SIZE DWG NO

Aileron

TITLE

SHEET 14 OF 31


61

11

REV

Balsa false spar made from 5mm sheet

320 635

DO NOT SCALE



SIZE DWG NO

Flap

TITLE

SHEET 15 OF 31


11

REV

73

61

Tip Template - Lower 1:1

Tip Template - Upper

Root Template - Lower

Root Template - Upper

DO NOT SCALE



SIZE DWG NO

Core Templates

TITLE

SHEET 16 OF 31


11

REV

Slot for fixing tab through fuselage

7

13

36,75

152

DO NOT SCALE



SIZE DWG NO

Wing Joining

TITLE

SHEET 17 OF 31


Plywood Doubler for trailing pin support

11

REV

Bottom Hatch

Drop Bracket

Standard Servo

Bottle Chute

Drop Module Bracket

DO NOT SCALE



SIZE DWG NO

Drop Module

TITLE

SHEET 18 OF 31


11

REV

Open

Closed

Drop module demonstrating operation

DO NOT SCALE



SIZE DWG NO

SHEET 19 OF 31

Drop Demonstration

TITLE


11

REV

80

100 10

12

150

90

Poly Downpipe

42,5

40

20

Heat treated to shape

85

20

DO NOT SCALE



SIZE DWG NO

Drop chute

TITLE

SHEET 20 OF 31


Blocks made of spruce and glued to pipe

11

REV

Fibreglass bottom hatch 81

252

DO NOT SCALE


Hole cut to fit bottle chute

6

87

42


SIZE DWG NO

Bottom hatch

TITLE

SHEET 21 OF 31


11

REV

R7

3 85

3 mm Sheet Aluminium

DO NOT SCALE


5

47


SIZE DWG NO

SHEET 22 OF 31

UAV Search and Rescue Drop Bracket

TITLE

10

11

REV

Plywood Mounting Plate

70 53 6

DO NOT SCALE


Spruce Servo Mount

8 70

11,6



SIZE DWG NO

SHEET 23 OF 31

Drop Module Bracket

TITLE

7,5

11

REV

Autopilot Battery

Autopilot Battery

Flight Battery Packs

300 500

Modem

GPS

DO NOT SCALE



SIZE DWG NO

SHEET 24 OF 31

Electronics installation

TITLE


IR Sensors

Autopilot

Video Modem Located Below Base Frame

11

REV

Frame:

Front

1

Base Frame

2

DO NOT SCALE


3

4


SIZE DWG NO

SHEET 25 OF 31

UAV Search and Rescue Fuselage Frame

TITLE

Shear Pin Reinforcement

11

REV

Front

6

26

106 40

188

216

8

594

Material: 6mm Plywood

427

6

R3

DO NOT SCALE


6


SIZE DWG NO

Base Frame

TITLE

SHEET 26 OF 31


6

70 10

10

25

74

110

,5

R2

11

REV

Frame 1

150

182

0 R2


110

70

74

R7 7

6

69

R 20

DO NOT SCALE


6


SIZE DWG NO

Frame 1

TITLE

SHEET 27 OF 31


11

REV

Doubler x 2


70

110

90

50 48

70

98 68

Frame 2

118

DO NOT SCALE


6


SIZE DWG NO

Frame 2

TITLE

SHEET 28 OF 31


11

REV

Doubler

R5


110

90

70

73 43

50 23

Frame 3

R5

93

DO NOT SCALE


6


SIZE DWG NO

Frame 3

TITLE

SHEET 29 OF 31


11

REV

Frame 4

R 57 R5


70

70

R7 7

R2 0

20

150

182

0 R2

DO NOT SCALE


6


SIZE DWG NO

Frame 4

TITLE

SHEET 30 OF 31


11

REV

O6

Material: 3mm plywood

70

30

35

20

43

8

DO NOT SCALE


3


SIZE DWG NO

SHEET 31 OF 31

Shear Pin Reinforcement

TITLE


11

REV

Design and Build a Search and Rescue UAV

Design and Build a Search and Rescue UAV

Suggest Documents

Multipurpose UAV for search and rescue operations

Design of an Autonomous Platform for Search and Rescue UAV ...

An Autonomous Multi-UAV System for Search and Rescue [PDF]

HYBRID CONTROL FOR UAV-ASSISTED SEARCH AND RESCUE

Design and Development of Search and Rescue Robot - IJENS

Search and Rescue Plan - ICAO

Design of an Autonomous Quadrotor UAV for Urban Search and ...

A Novel Search Strategy for Autonomous Search and Rescue Robots

Urban Target Search and Tracking Using a UAV and ...

Guidelines for Rescue Services Search and rescue from crashed ...

Rescue Communicators for Global Victim Search and Local Rescue ...

Working with Search and Rescue Helicopters

Unmanned Maritime Systems for Search and Rescue

Search and Rescue - UDSpace - University of Delaware

185 ;Search520- - Horrifying Search and Rescue ... - WordPress.com

Autonomous Systems for Search and Rescue - CiteSeerX

Behavior Differences Between Search-and-Rescue ...

50. Search and Rescue Robotics - Semantic Scholar

Supporting Wilderness Search and Rescue with Integrated ...

Basic Search and Rescue (BSAR) - nkepc

INCIDENT COMMAND SYSTEM URBAN SEARCH AND RESCUE ...

INCIDENT COMMAND SYSTEM URBAN SEARCH AND RESCUE ...

1.2 What is Search and Rescue

informed maritime search and rescue performance evaluation