rc plane so vertikalno poletuvanje

��

��

�

�

��

��

��

��

��

��

��!��

��

�

�

"#$�%!��

��

��

��

��

�

�#��!��%!�

��

�

��%&�%!�

�� !��"#��

�

�

�

��

�

Executive Summary

This project is a continuation of the 2004 University of Adelaide Mechanical Engineering

final year VTOL project, which aimed to develop a controlled and stable VTOL model

aircraft based on the F-35 Joint Strike Fighter. Last year’s project group was unable to

complete the project for several reasons, primarily because of the poor performance of the

internal combustion engines. Due to advances in electric motor and battery technology,

the use of electric motors in now a feasible option and has been chosen for this year’s

project. An investigation was performed to re-evaluate the most suitable aircraft upon

which to base this year’s design. This research identified that the V-22 Osprey was the

most suitable platform. The primary advantage in using the V-22 Osprey as opposed to

the F-35 was the higher thrust to weight ratio achievable using propellers.

Several designs were considered during the concept evolution, with each concept compared

with the design requirements. The final concept which met all requirements was then

modelled in SolidEdge where further details were considered. The design consists of an

Aluminium chassis with rotating wing arms controlled by servo motors allowing for tilt-

rotor operation. Control simplifications use this wing arm rotation along with a rear

tail-fan to directly control all three rotational degrees of freedom.

Thrust providing components were selected to best satisfy the constraints of cost, weight

and power. Ultimately two-blade fixed-pitch propellers were chosen to be mounted radially

to brushless motors via a planetary gearbox. These motors are controlled using an

electronic speed controller and powered by on-board Lithium Polymer batteries. Using

software based propeller theory these components were shown to produce adequate thrust.

To facilitate the creation of an appropriate control system using the physical

characteristics of the model aircraft, a mathematical representation of the system

was obtained by following several closely related examples. Using this mathematical

representation a state space controller was developed using a Reduced-Order Observer

and tuned using LQR Optimal Control. Another control technique, Proportional Integral

Derivative (PID) control, was also used as a controller for the aircraft. While the PID

iii

controller was less capable than the state space controller, it was much easier to implement

and tune.

The controllers were initially built in Matlab Simulink, which creates C code that is

cross-compiled and downloaded to a dSPACE DS-1104 rapid prototyping control platform.

This allowed for the easy implementation and tuning of these control systems. However

this control platform is an undesirable final solution to control the aircraft due to its

size and cost, so the control system was migrated to the on-board MiniDRAGON+

microcontroller. This microcontroller was specifically programmed to interface with all of

the control peripherals, including a standard remote control and receiver which was used

to control the model.

The model aircraft was attached to a gimble to allow the tuning of the control systems

while in a tethered and safe configuration. However due to problems associated with

this gimble the tuning was not successfully completed. The model was then moved to a

semi-tethered configuration, where it was removed from the gimble but still tethered via

the wiring loom which allowed relatively free movement within a fixed range. During this

semi-tethered stage of controller tuning a gearbox shaft failed which prevented progress

towards the project goals of controlled and stable hover.

The project was set back due to the late procurement of vital components and several

mechanical failures. While this contributed to the project goals of controlled and stable

hover being incomplete, the design was shown to be able to provide enough thrust to

achieve hover and sufficiently controllable to achieve these goals. Furthermore due to the

significant work undertaken in integration and control embedding the model is a solid

control platform for future work.

iv

Acknowledgements

The VTOL group would like to thank everybody who has assisted with the project.

Our project supervisor Dr. Ben Cazzolato has provided valuable assistance in this project.

Both his technical advice and general experience have been very useful for us. We thank

Ben for continuously allocating us into his exceedingly demanding schedule and appreciate

his time spent with us.

The Sir Ross and Sir Keith Smith Fund for providing the financial support which has

made this project possible.

Mr. Tim Newman, our industrial associate has provided us with advice and product

sourcing based on practical knowledge and experience with aeronautical engineering and

model aircraft.

Within the School of Mechanical Engineering Mr. Richard Pateman and Mr. Steven

Kloeden from the workshop and Mr. Silvio De Ieso from Electronics and Instrumentation

have been extremely helpful throughout the project, providing advice and assisting us

despite our constant pestering. Dr. Frank Wornle has also provided valuable help

with the microcontrollers and provided advice regarding the use of his real-time target

for embedded control. Postgraduate student Mr. Rohin Woods also helped in the

development of a Virtual Reality model.

Finally the group would also like to thank our family and friends for supporting us

throughout the project.

v

Disclaimer

We, the authors, state that the material contained within is entirely our work unless

otherwise stated.

Zebb Prime Allan Stabile

Michael Smith Jesse Sherwood

vii

Contents

Executive Summary iii

Acknowledgements v

Disclaimer vii

List of Figures xv

List of Tables xviii

1 Introduction 1

1.1 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Literature Review 4

2.1 Key Findings of the 2004 Report . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Existing VTOL Aircraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 F-35B Joint Strike Fighter . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 V-22 Osprey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.3 Experimental Craft . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Previous Tilt-Rotor VTOL RC Aircraft . . . . . . . . . . . . . . . . . . . . 9

2.4 Control Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

ix

Contents Contents

3 Concept Evaluation 13

3.1 F-35 Joint Strike Fighter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Ducted Fans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2 Basic Feasibility Calculation . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Osprey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 RC Propellers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.2 Basic Feasibility Calculations . . . . . . . . . . . . . . . . . . . . . 17

3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Mechanical Design 19

4.1 Control Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Yaw Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.2 Pitch Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.3 Roll Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.4 Translation Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Frame Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.1 Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.2 Tilt Rotor Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.3 Final Tilt-Rotor Design . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.4 Frame Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.5 Final Frame Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Propulsion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.1 Propeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.2 Propeller Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.3 Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

x

Contents Contents

4.3.4 Batteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.5 Propulsion Component Summary . . . . . . . . . . . . . . . . . . . 34

4.3.6 Tail Thrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.1 Inertial Measurement Unit (IMU) . . . . . . . . . . . . . . . . . . . 37

4.4.2 Rate Gyroscopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5.1 Servo Motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Mathematical System Model 39

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 State Equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2.1 Linearisation Methods Used . . . . . . . . . . . . . . . . . . . . . . 39

5.2.2 Propeller Angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.3 Left and Right Propeller State Equations . . . . . . . . . . . . . . 41

5.2.4 Rear Impeller Equation . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.5 Pitch Axis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.6 Roll Axis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.7 Yaw Axis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.8 Vertical Translation . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.9 Lateral and Longitudinal Translation . . . . . . . . . . . . . . . . . 46

5.3 Virtual Reality Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

xi

Contents Contents

6 Control System 51

6.1 Classical Control (PID Controller) . . . . . . . . . . . . . . . . . . . . . . . 51

6.1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.1.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1.3 Controller Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2 State Space Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.2.2 Controller Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.2.3 Observer Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.2.4 Simulink Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2.5 Microcontroller Implementation . . . . . . . . . . . . . . . . . . . . 59

7 Implementation of Control 61

7.1 Signals, Hardware and Software . . . . . . . . . . . . . . . . . . . . . . . . 61

7.1.1 Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.1.2 Control Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.1.3 Control Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.2 Development Stage (Tethered) . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.2.1 Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . 66

7.2.2 Software Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.3 Semi-Tethered Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.4 Fully Embedded Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.4.1 Embedded Hardware Design . . . . . . . . . . . . . . . . . . . . . . 74

7.4.2 Embedded Software Design . . . . . . . . . . . . . . . . . . . . . . 75

xii

Contents Contents

8 Testing and Tuning 78

8.1 Initial Open Loop Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.2 Closed Loop Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.3 Untethered Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

9 Constraint Analysis 83

9.1 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

9.2 Weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

9.3 Power Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10 Issues 87

10.1 IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

10.2 Sourcing of Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

10.3 Mechanical Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

10.3.1 Wing Arm Motor Mount . . . . . . . . . . . . . . . . . . . . . . . . 88

10.3.2 Gearbox Shaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

10.4 Wing Arm Bearings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

10.5 Electrical Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

10.6 Unmodelled Gimble Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . 90

10.7 Weight of Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

11 Discussion and Future Work 92

11.1 Summary of achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

11.1.1 Choice of platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

11.1.2 Mechanical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

11.1.3 Component Selection and Procurement . . . . . . . . . . . . . . . . 93

xiii

Contents Contents

11.1.4 Mechanical Construction . . . . . . . . . . . . . . . . . . . . . . . . 93

11.1.5 Mathematical Modelling . . . . . . . . . . . . . . . . . . . . . . . . 93

11.1.6 Controller Design and Tuning . . . . . . . . . . . . . . . . . . . . . 93

11.1.7 Control Implementation . . . . . . . . . . . . . . . . . . . . . . . . 93

11.2 Future Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

11.2.1 Stable Hover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

11.2.2 Real-Time Embedded Gain Updating . . . . . . . . . . . . . . . . . 94

11.2.3 System Identification . . . . . . . . . . . . . . . . . . . . . . . . . . 95

11.2.4 Reduced Precision Sensors . . . . . . . . . . . . . . . . . . . . . . . 95

11.2.5 Model Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

11.2.6 Conventional Flight . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

References 97

A CAD Drawings 99

B Simulink Code 100

C Embedded Controller Code 101

xiv

List of Figures

2.1 F-35B JSF STOVL Aircraft (JSF, 2005). . . . . . . . . . . . . . . . . . . . 6

2.2 F125-PW-600 Power Plant for the F-35B JSF STOVL (JSF, 2005). . . . . 6

2.3 F-35B JSF STOVL Landing (JSF, 2005). . . . . . . . . . . . . . . . . . . . 7

2.4 V-22 Osprey in its Hover Configuration (Boeing, 2005). . . . . . . . . . . . 8

2.5 Cut-away View of the V-22 Osprey (Rogers, 1989, p. 242). . . . . . . . . . 8

2.6 Larry’s V-22 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Wind Tunnel Testing of DS-51-DIA + Hacker 50XL Motor (Schubeler, 2005) 15

3.2 Wind Tunnel Testing of DS-51-DIA + HP 220-40-A3 Motor (Schubeler,

2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Yaw Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Rotating Mount Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3 Internal Motor Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 Final Motor Rotation Configuration . . . . . . . . . . . . . . . . . . . . . . 23

4.5 Motor and Motor Mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.6 First Frame Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.7 Redesigned Frame Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.8 Final Frame Concept Sketch . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.9 Final Frame Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

xv

List of Figures List of Figures

4.10 Frame As Built . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.11 Selected Motor, Propeller and ESC. . . . . . . . . . . . . . . . . . . . . . . 35

4.12 Moment About CoM from Primary Thrust . . . . . . . . . . . . . . . . . . 35

4.13 Net Moment of Zero About CoM . . . . . . . . . . . . . . . . . . . . . . . 36

4.14 Rear Thrust Unit - Brushless Motor, Ducted Mini-Fan, ESC . . . . . . . . 37

4.15 Servo Mounted on Wing Arm . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1 Basic Diagram of Model Layout . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Propeller Angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Basic Virtual Reality Model . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.4 V-22 Osprey Model in V-Realm Builder . . . . . . . . . . . . . . . . . . . . 49

5.5 Final V-22 Osprey VR Model . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.6 Simulink Model Driving the VR Block . . . . . . . . . . . . . . . . . . . . 50

6.1 Generalised PID Controller (Cazzolato, 2005b) . . . . . . . . . . . . . . . . 52

6.2 Decoupled PID Control System . . . . . . . . . . . . . . . . . . . . . . . . 53

6.3 Full State Space Controller (Cazzolato, 2005c) . . . . . . . . . . . . . . . . 54

6.4 Reduced Order Observer Implementation Cazzolato (2005c) . . . . . . . . 58

6.5 Simulink State Space Model . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.6 Simulink Model with Observer and Connections from IMU and to dSPACE 60

7.1 Example PWM Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.2 RC PWM and Servo Motor Example . . . . . . . . . . . . . . . . . . . . . 62

7.3 RS-232 Connectors and Pinouts used in this Project . . . . . . . . . . . . . 63

7.4 dSPACE Breakout Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.5 MiniDRAGON+ Development Board. . . . . . . . . . . . . . . . . . . . . . 65

xvi

List of Figures List of Figures

7.6 PicoPic Servo Motor Controller.(Picobytes inc., 2003) . . . . . . . . . . . . 65

7.7 Tethered Configuration Hardware Layout . . . . . . . . . . . . . . . . . . . 67

7.8 Tethered Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.9 Tethered Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.10 Breakout Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.11 Modified Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.12 PicoPic Mounted to the Aircraft Frame . . . . . . . . . . . . . . . . . . . 70

7.13 Abstracted Simulink Model . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.14 VTOL Control Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.15 ControlDesk Layout for the PID Controller . . . . . . . . . . . . . . . . . . 72

7.16 free2move Bluetooth RS-232 Transmitter / Receiver . . . . . . . . . . . . . 73

7.17 Untethered Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . 74

7.18 RC Transmitter and Receiver . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.19 Embedded Code Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.1 Emeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.2 Untethered Testing Outside the Holden Lab . . . . . . . . . . . . . . . . . 80

8.3 Untethered Testing on Grass . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8.4 Mechanical Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

10.1 Failure of shaft at Wing/Motor Mount junction . . . . . . . . . . . . . . . 89

xvii

List of Tables

3.1 Ducted Fan Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Propeller Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Mechanical Properties of Common Model Aircraft Materials . . . . . . . . 21

4.2 Comparison of Battery Types . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.1 Component Expenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

9.2 Estimated Student Labour Costs . . . . . . . . . . . . . . . . . . . . . . . 84

9.3 Weight Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

9.4 Control Circuit Power Budget . . . . . . . . . . . . . . . . . . . . . . . . . 86

9.5 Motor Power Budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

xviii

Notation

Acronyms and Abbreviations

CoM Centre of Mass

CoG Centre of Gravity

CRO Cathode Ray Oscilloscope

CTOL Conventional Take-Off and Landing

ECT Enhanced Capture Timer

GUI Graphical User Interface

IMU Inertial Measurement Unit

LiPo Lithium Polymer

LQR Linear Quadratic Regulator

MIMO Multiple Input Multiple Output

PWM Pulse Width Modulation

RC Remote Control

RPM Revolutions Per Minute

SISO Single Input Single Output

SLA Sealed Lead Acid

USB Universal Serial Bus

VR Virtual Reality

VTOL Vertical Take-Off and Landing

xix

List of Tables List of Tables

Nomenclature

Attitude The position of an aircraft relative to a frame of reference, typically

the horizon or direction of motion.

Authority The amount of control the aircraft provides over its degrees of

freedom.

Nacelle A streamlined enclosure to protect something, such an an engine.

In the context of this report it refers to the engine covers located

at the wing tips of the V-22 Osprey.

Pitch The up or down movement of the nose of an aircraft.

Propeller Pitch The distance a propeller will move forward in a perfect fluid

Roll The rotation of an aircraft about its longitudinal axis, that is the

axis which runs along the length of the aircraft.

Yaw The left or right movement of the nose of the aircraft

xx

List of Tables List of Tables

Roman Symbols

a Acceleration (ms−2)

A Area (m2)

E Young’s Modulus of Elasticity (GPa)

f Frequency (Hz)

F Force (N)

J Moment of Inertia (kg.m2)

J Advance Ratio

p Pitch Angle (radians)

r Roll Angle (radians)

T Thrust (N)

T Period (s)

v Velocity (ms−1)

y Yaw Angle (radians)

Greek Symbols

τ Moment (N.m)

φ Propeller Pitch Angle (radians)

ω Angular Velocity (radians.s−1)

ρ Density (kg.m3)

σ Tensile Stress (MPa)

θ Propeller Angular Position (radians)

Note: x indicates the temporal derivative dxdt

of x.

xxi

Chapter 1

Introduction

Vertical Take-Off and Landing (VTOL) aircraft are able to take-off with the agility of

a helicopter while retaining the efficiency and speed of an airplane during conventional

flight. The applications of such an aircraft are vast, ranging from civilian transport

to aeromedical evacuation and troop deployment (Bell Agusta, 2005; Wilkins, 2001).

Currently such aircraft have been limited to military and research applications. The

long range and efficiency associated with conventional aircraft means they can cover large

distances and the can land where conventional aircraft often cannot. In these locations

supplies can be deployed or surveillance obtained without the need for a sizeable landing

area.

Similar benefits exist for scaled model Remote Controlled (RC) VTOL vehicles. Model

aircraft enthusiasts are more often than not forced to fly their fixed wing aircraft in

areas containing open and appropriate ground space necessary for take off and landing.

However, a model RC VTOL aircraft would allow for launching from a roof top or an

inadequate surface for conventional take off such as the beach. These needs and potential

applications provide the motivation for this design project, in the anticipation of designing

and building a model VTOL aircraft that is able to be controlled remotely and affordable

to the everyday enthusiast.

1.1 Aim

The aim of this project is to develop a remote control model VTOL aircraft that is a scale

model of a real life aircraft. It should feature a control system which allows the aircraft to

remain in stable hover without user intervention. By definition, this aircraft must be able

to take off vertically and transition into conventional flight and be able to return to hover

1

Chapter 1. Introduction 1.2. Scope

mode for landing. It is envisaged that a significant market would exist if a VTOL aircraft

could be purchased for a price affordable to the average RC enthusiast. It is desired to

make such an aircraft available for under $2000. During development the aircraft will be

controlled via a PC, however the final version must be controllable using a standard RC

receiver.

It is desirable for the model to be intuitive to fly for someone who is used to flying

conventional model aircraft. As such when the model is hovering, the control system

should be capable of keeping the model stable with minimal user intervention.

1.2 Scope

As outlined in Section 1.1, this project is an ambitious one and not able to be completed in

a one year timeframe. The primary goal of this year’s project was to develop a mechanical

and control system design which would allow a model aircraft to attain stable hover. This

stable hover would be initally attained whilst tethered to a gimble before free flight was

attempted. This report details the design and construction of a prototype VTOL aircraft

based on the V-22 Osprey. It highlights the achievements of the authors and identifies

possible future work. Real life VTOL aircraft and previous attempts of replicating these

are discussed in the literature review as are some of the control methods for the model.

This report describes the design and construction of a RC VTOL model aircraft based on

the V-22 Osprey, the control system developed for stabilising the plane whilst in hover,

results from testing and possible future work.

A thorough review of previous literature and VTOL designs was undertaken with

the intention of selecting the most suitable platform upon which to base the design.

Full documentation is given for the electrical and mechanical design of the aircraft

including control requirements, frame design, propulsion methods, and sensor and

actuator selection. A comprehensive section is devoted to the mathematical model of the

system. This section describes the fundamental equations and also the approximations

and linearisations made to facilitate the design of a state space control system. A detailed

account of control system design and implementation is provided. This describes the

development of various control systems in software form and their implementation onto

the associated electrical hardware. Results and conclusions from testing are discuissed

along with analysis of constraints and issues. Possible improvements to the design are

discussed along with a list of future work deemed beneficial to the projects success.

2

1.3. Significance Chapter 1. Introduction

1.3 Significance

There are currently no commercially available model VTOL aircraft (apart from rotary

winged) for the average enthusiast. The development of a VTOL capable aircraft sold in

kit form would be an impressive innovation in this field. Individuals have attempted to

build their own VTOL capable aircraft with some degree of success at hovering. However,

a RC VTOL aircraft with the capability to transition to conventional flight still eludes

the global RC aircraft community. The construction of a model that is able to transition

from a hover to conventional flight would be an achievement in itself, furthermore the

ability to VTOL would significantly increase available locations that the model can be

flown and enjoyed in, without the sacrifice of traditional aircraft manoeuvrability often

lost with VTOL aircraft such as model helicopters (Bell Agusta, 2005).

3

Chapter 2

Literature Review

Since this project is a continuation of an existing project, it is important to undertake a

critical analysis of the work already done and the theory involved. Other recent advances

in relevant areas must also be considered, along with well accepted traditional theory and

principles associated with the proposed design.

2.1 Key Findings of the 2004 Report

The most relevant document to the current project was the honours report of Jarrett

et al. (2004) titled “Design and Build of a Remote Control VTOL Aircraft” of which the

current project is an extension. The authors’ aim was to design and build a commercially

viable model VTOL aircraft based upon the F-35 Joint Strike Fighter (JSF), focusing on

the mechanical design of the model and the control system to enable it to hover.

With the help of several industry professionals they successfully built the model. However

they were unable to maintain a prolonged hover due to inadequacies of the internal

combustion engines. These inadequacies were namely:

• Large levels of vibration interfering with the inertial measurement unit and causing

frame fatigue.

• Their unpredictable performance due to tuning sensitivities, such as small changes

in air moisture producing a significant change in power output.

• The time delay between the throttling of the motors and their actual response.

• The time-varying nature of the engines, which stressed the control system.

4

2.2. Existing VTOL Aircraft Chapter 2. Literature Review

Despite these issues, hover was sustained for short periods proving the control system able

to successfully control the aircraft. With time-invariant motors, such as electric motors, it

was thought that a sustained hover would be achievable. The progress in the technology of

batteries, specifically Lithium Polymer (LiPO) batteries, during the course of the project

made it theoretically possible to use electric motors with enough thrust to lift the aircraft

while maintaining an economically viable production cost.

An analysis of the power losses from several different thrust vectoring techniques was

performed. These included a swivelling duct, gimballed motor, fluidic vectoring and thrust

deflection. It was found that the gimballed motor, where the whole motor and impeller

rotate, had the least power loss, at the expense of complexity and model aesthetics. The

final model made use of the swivelling duct so it reflected the true form of the F-35 JSF

better.

2.2 Existing VTOL Aircraft

Model aircraft are typically based on existing full-size aircraft. In this section a critical

analysis of existing VTOL aircraft is presented.

2.2.1 F-35B Joint Strike Fighter

The Joint Strike Fighter program is the focal point of the US Department of Defence for

creating advanced and affordable next-generation strike aircraft for all four branches of

the U.S. armed forces and their allies (JSF, 2005). It attempts to do this by creating

three variants; each suited to a particular niche in the armed forces with up to 80% parts

commonality between models (Jarrett et al., 2004). The variant of particular interest to

this project is the F-35B Short Take-Off and Vertical Landing (STOVL), shown in Figure

2.1.

The F-35B is powered by the Pratt & Whitney F135-PW-600 turbojet engine which is

coupled to a lift fan fore of the main turbine, as shown in Figure 2.2. Vertical thrust at

the rear of the aircraft is generated by vectoring the turbine exhaust through a specially

developed three bearing swivel nozzle. A landing F-35B with its nozzle in the vertical

position is shown in Figure 2.3. Differential thrust from the exhaust and the lift fan allows

for pitch control of the aircraft. The airducts protruding from the sides of the turbine

(Figure 2.2) direct jets of air out to the wings, controlling roll. The nozzle at the rear of

the turbine can swivel either side of straight down, vectoring thrust either side to control

yaw.

5

Chapter 2. Literature Review 2.2. Existing VTOL Aircraft

Figure 2.1: F-35B JSF STOVL Aircraft (JSF, 2005).

Figure 2.2: F125-PW-600 Power Plant for the F-35B JSF STOVL (JSF, 2005).

6

2.2. Existing VTOL Aircraft Chapter 2. Literature Review

Figure 2.3: F-35B JSF STOVL Landing (JSF, 2005).

2.2.2 V-22 Osprey

According to Boeing (2005) the V-22 Osprey is the first aircraft designed from the ground

up to accommodate the needs of all four branches of the U.S. armed forces. Winning the

Naval Air System Command contract in April 1983 the project that was to be known as

the Osprey was a collaboration between Bell, known for their experience with tilt wing

rotorcraft, and Boeing Vertol, known for their experience with heavy lifting helicopters

(Rogers, 1989). The V-22 is designed for both Vertical Take-Off and Landing (VTOL) and

Short Take-Off and Landing (STOL), with the former used for larger payloads. Capable

of 510 km/h (Boeing, 2005) in conventional flight the V-22 combines the advantages of

helicopters and fixed wing aircraft. A V-22 Osprey in its hover configuration is shown in

Figure 2.4.

Powered by two Allison T406-AD-400 turboprop engines, each developing 4,586 kW of

power, the V-22 drives each of its tri-blade 11.58 m diameter proprotors to achieve the

large amount of thrust required for vertical take-off (Boeing, 2005). Utilising both cyclic

and collective propeller pitch control, the V-22 can control all six of its degrees of freedom

when in hover while the nacelles remain stationary and in their upright position (Rogers,

1989). A cut away of the port nacelle to show these pitch control mechanisms is shown

in Figure 2.5, as well as a cut away of the starboard nacelle showing the tilt jack.

7

Chapter 2. Literature Review 2.2. Existing VTOL Aircraft

Figure 2.4: V-22 Osprey in its Hover Configuration (Boeing, 2005).

Figure 2.5: Cut-away View of the V-22 Osprey (Rogers, 1989, p. 242).

8

2.3. Previous Tilt-Rotor VTOL RC Aircraft Chapter 2. Literature Review

2.2.3 Experimental Craft

Franklin (2002) provides a brief historical background on some experimental VTOL

aircraft including the X-22A VTOL Research Craft and XC-142 Tilt-Wing Tactical

Transport. The X-22A has four tilting ducted propellers, a pair near the nose and a

pair on the main wings at the rear. The XC-142 follows the common design of tilt rotor

aircraft but with four turbofan powered propellers on the wings and a shaft driven tail

propeller. The tail propeller is used to control pitch while in hover. In both cases the

propellers are driven through a complex interconnected shaft and gearbox system for

redundancy.

2.3 Previous Tilt-Rotor VTOL RC Aircraft

There have been a number of recent attempts by individuals to build RC VTOL tilt-rotor

aircraft. No one has succeeded in building a model capable of performing a successful

transition to conventional flight. There are many threads on discussion boards such as

“rcgroups.com” where individuals have expressed an intense interest in the development

of a commercially available transition capable tilt-rotor RC aircraft. Literature for this

section is restricted due to the fact that the people who have attempted to build an RC

VTOL aircraft are enthusiasts who do not generally publish their designs and ideas in

detail.

Larry Chapman is an enthusiast who has been developing a tilt-rotor RC aircraft based

on the V-22 for over a decade and has actually flown in a USAF V-22 flight simulator

(Chapman, 2005). His most recent model used customised 2 blade propellers with variable

pitch (from a RC helicopter) driven by O.S.46 petrol engines and is shown in Figure 2.6.

Initially Larry used no control augmentation but the latest model uses two rate gyros for

yaw and roll. The generic gyroscope based control system used has been a success even

though no advanced control techniques are employed.

The earliest model built by Larry had the motors mounted within the fuselage of the

plane with gearboxes at the wingtips. This proved highly unstable during hover and

more recent designs have the motors mounted at the wingtips. One of the initial major

problems experienced by Larry was the gyroscopic effects on the fuselage from attempted

rotation of the nacelles. When the propeller nacelles angles were altered the nose would

pitch up. Initially flat symmetrical helicopter blades were used but these were found to

stall when they were tilted to the 60 degrees from standard required for transition. To

prevent this, the model now incorporates timber propellers with a more traditional screw

9

Chapter 2. Literature Review 2.3. Previous Tilt-Rotor VTOL RC Aircraft

Figure 2.6: Larry’s V-22 Model

10

2.4. Control Techniques Chapter 2. Literature Review

shape. Larry has also experienced issues changing the controls from hover to forward

flight and had to rebuild his models several times due to large crashes. The latest model

is able to sustain semi-hover flight with the propellers tilted at 60 degrees but as yet is

unable to transition to conventional flight.

In 2003, an Austrian man by the name of Norbert also built a scale model of the V-22

(TiltRotorMech, 2005). Norbert used a single petrol engine to power a pair of variable

pitch tri-blade propellers. He claimed to be able to sustain a basic hover with some

control of propeller tilt but has not achieved transition to forward flight. Again a generic

gyroscope based control system is able to stabilise the plane during hover.

Brian DiCinti has built a RC V-22 with electric engines (TiltRotorMech, 2005). In 2003 he

was able to maintain hover and helicopter like forward flight without properly functional

tilt control. Again, only a basic gyroscope control system is employed to stabilise the

plane. Brian is currently attempting to develop a more functional wing tilting system.

The above cases demonstrate that sustained hover is possible even with basic control

systems. If a more advanced control system were implemented in designs such as those

above to augment pilot input the controllability should see a major improvement. An

advanced control system may also facilitate the control of the various degrees of freedom

such as yaw and roll whilst in hover.

The transition from hover to forward flight appears to be the underlying barrier to all

previous attempts at RC VTOL tilt-rotor aircraft. An advanced control system similar

to one used in full size tilt-rotor plane would also make transition to forward flight more

feasible, as few RC pilots would have the skill to control the model through transition

without some form of control augmentation. A heavily automated transition system may

allow even less experienced pilots to fly the plane, a beneficial attribute for a commercial

RC aircraft.

2.4 Control Techniques

Classical methodologies based on PID feedback control are still implemented in full-scale

rotorcraft control (Mettler, 2003). The big advantage of such a simple control architecture

is that it can be implemented without a model of the vehicle dynamics; feedback gains can

be tuned experimentally. Franklin (2002) contains detailed analysis of classical control

systems used by various forms of VTOL aircraft when in hover or forward flight. Control

characteristics for various degrees of freedom in hover and flight are presented separately

with analysis of disturbance rejection and pilot controllability where relevant. This will

be further discussed in Chapter 6.

11

Chapter 2. Literature Review 2.4. Control Techniques

There have been a number of papers describing the development of mathematical models

for similar designs of flying or hovering craft. Cazzolato (2005a), Xiaofei-Wu et al. (2002)

and Hamel (2002) all describe the development of mathematical models for applications

similar to that of this project.

12

Chapter 3

Concept Evaluation

3.1 F-35 Joint Strike Fighter

The F-35 Joint Strike Fighter is the more aesthetically pleasing of the two designs

considered. A commercially available VTOL F-35 model would attract many consumers

interested in its advanced yet aggressive appearance. An F-35 balsa wood scale model

is sold by Oakdale Aircraft, reducing the amount of development required on the skin.

The main limitation of the F-35 model design is the generation of thrust within the

confined space of the shell. The feasibility of the F-35 VTOL was heavily dependent on

the existence of a solution to this issue of thrust generation within the constraints of the

project.

Due to the requirement that the thrust must be generated within the shell of F-35, the

possibilities for thrust generation are limited to ducted fans or turbines. Jarrett et al.

(2004) established that turbines are not an option for this project due to their prohibitively

high cost and low relative static thrust . Ducted fans powered by internal combustion

engines were shown to be inadequate for controllable hover as discussed in Section 2.1.

For this reason electric motors with ducted fans were the most seriously considered option

for thrust generation in the F-35 model.

3.1.1 Ducted Fans

The foremost limitation of the electric motor-ducted fan solution was the insufficient

thrust/weight ratios that could be achieved. It has been determined that the F-35 concept

is in theory feasible using high-end RC Aircraft components currently available (Jarrett

et al., 2004). Under laboratory conditions there are combinations of motor and ducted

13

Chapter 3. Concept Evaluation 3.1. F-35 Joint Strike Fighter

fans that produce enough thrust to lift the proposed mass of the model jet. However,

these theoretical concepts assume a design that would sufficiently minimise thrust losses

and weight. If a sufficient thrust solution was attained, other design factors relating to

the controllability would have been investigated in further detail. Table 3.1 shows the

models of ducted fan investigated.

Wennmacher Modell Technik (WeMoTec) is a German company specialising in the design

and manufacture of ducted fans for use with electric motors. The Jarrett et al. (2004)

considered the possibility of using the WeMoTec Midi-fan (90mm) as a source of thrust

but determined it was unable to produce sufficient levels. Some of the more advanced

ducted fans in the WeMoTec range were considered. The WeMoTec HW730 and HW750

are 7-bladed ducted fans with105mm and 124mm rotors respectively. The rotors are

constructed from carbon fibre with other parts made of Nylon, ABS and Aluminium.

WeMoTec claim that the HW750 fan can provide 35N of static thrust when used a high

power brushless motor powered by 32 Nickel Cadmium (NiCd) cells (WeMoTec, 2005).

There has been no success in finding any documented evidence to prove these claims true.

Furthermore, the weight of a battery to supply the required power for each motor would

be prohibitive (even for LiPo batteries) for a model which is required to perform vertical

take-off.

Schubeler Jets is a German company also specialising in the design and manufacture

of ducted fans for use with electric motors, and model jets that incorporate these fans.

The Schubeler DS-51-DIA ducted fan is regarded by some members of the RC Aircraft

community as the premier ducted fan currently available. The DS-51-DIA is a 4-blade,

90mm impeller designed to withstand the most powerful motors currently available to the

RC market. The DS-51 is constructed from carbon fibre and is built using CAD-CAM

techniques to maximise quality. Schubeler claims that the current design has very low

vibration at high speeds and a static efficiency of 78%. Schubeler performs laboratory

tests of the DS-51-DIA complying to the mass flow rate measurement standard VDI 2041.

Table 3.1: Ducted Fan Options

Characteristic WeMoTec Schubeler

Impeller Model HW730 HW750 DS-51-DIARotor Diameter 105mm 124mm 90mm

Blades 7 7 4Weight 148g 185g 48g

Max Static Thrust 25N (20 cells) 35N (32 cells) 33N (30 cells)Cost (RRP approx $AUD) $215 $250 $380

14

3.1. F-35 Joint Strike Fighter Chapter 3. Concept Evaluation

3.1.2 Basic Feasibility Calculation

The combination that Schubeler found produced the greatest thrust from testing was

the DS-51-DIA ducted fan with a Hacker 50XL (12 winding) motor and Beat 50-8-30

Electronic Speed Controller (ESC). This combination required the equivalent power as

would be supplied from 26-30 cells. Figure 3.1 shows that for an input of 29V (38000 rpm)

the static thrust output was approximately 28N . These results were almost matched by

the slightly smaller Plettenberg 220-40-A3 motor (27N at 27V) with the same battery

and ESC as can be seen in Figure3.2.

Figure 3.1: Wind Tunnel Testing of DS-51-DIA + Hacker 50XL Motor (Schubeler, 2005)

The lightest LiPo batteries able to supply the current required for these motors weighs

at least 650g (eg. Thunder Power TP4000-8S-2P). The total mass of components (not

including wiring) for a potential output thrust of 28 N would be 1200g (50g Ducted

Fan, 350g motor, 50g ESC, 650g LiPo). Assuming that two of these ducted fans in

the F-35 frame were able to replicate the tested thrust with no loss of flow there would

be 56N of thrust for 2400g. For the desired thrust to weight ratio of 1.5:1 this would

leave approximately 1300g for the remaining components or the model. In practice it

would be impossible to replicate the tested thrust efficiencies in the F-35 frame as both

fans will experience losses relating to flow distortions both up and downstream of the

fan. According to Jarrett et al. (2004) approximate thrust losses are 20% at the front

ducted fan with a higher loss for the rear fan. Assuming losses at both fans of 20% the

total theoretical thrust available is reduced to 45N and the allowable mass of the rest

15

Chapter 3. Concept Evaluation 3.2. Osprey

Figure 3.2: Wind Tunnel Testing of DS-51-DIA + HP 220-40-A3 Motor (Schubeler, 2005)

of the model reduced to 600g (for a Thrust/Weight ratio of 1.5:1). Lowering the desired

Thrust/Weight ratio may make this option more feasible. However, other factors such

as the ground effect during take-off, the diverting of thrust during transition and the

possibility of higher thrust losses (up to 50%) at the rear fan reduce the feasibility of this

design further.

The lack of a suitable thrust solution was the determining factor against the F-35 concept.

3.2 Osprey

The alternative VTOL design considered was that of the V-22 Osprey. This design

acquires thrust by means of two proprotors (which act as both a rotor and a propeller)

mounted in wing tip nacelles along with their engines and gearboxes. These nacelles

are able to rotate a vertical to a horizontal position. The high degree of rotation and

aerodynamic design that these proprotors are designed with allow for efficient operation

as both a rotor and a propeller, thus facilitating both VTOL and conventional flight.

The main advantage of the design based on the V-22 Osprey is the relaxed constraints

placed on the size of the propeller/rotor diameters. The propellers were able to be powered

by several types of motors, however as noted in Section 3.1 electric motors were the most

suitable choice for the control of hover on a small scale model.

16

3.2. Osprey Chapter 3. Concept Evaluation

3.2.1 RC Propellers

Propellers choice for model aircraft are chosen based on material, size, blade number and

variable or fixed pitch. The chosen propellers need to provide adequate thrust to allow

sustained hover and have sufficiently low rotational inertia to allow for fine speed, and

thus thrust, control (Airfield Models, 2005). The availability of motor, propeller and

battery combinations is diverse. However, several combinations were considered in Table

3.2 in order to determine the availability of propellers capable of providing adequate thrust

(ICARE, 2005).

The two-blade APC propellers are made from glass-filled nylon, while CAM propellers

are generally made from a carbon fibre composite material and Menz S propellers are

commonly made from wood. These are all fixed pitch propellers and are specified by

diameter and pitch, usually quoted in inches. All of the propellers compared below are

powered using electric motors and can be seen to easily achieve a high level of static

thrust compared with the initial model mass estimate of 2.5kg. Larger diameter and

pitch propellers are also available from both APC and Menz S, however these propellers

have higher rotational inertia.

Table 3.2: Propeller Options

Characteristic APC CAM Menz S

Diameter 16” 17” 20” 13” 14” 20” 18” 20”Pitch 10” 13” 10” 7” 9.5” 12” 10” 10”

Max Static Thrust 38N 44.1N 54N 28N 30N 31N 44.1N 47.1NVoltage at Max Thrust 29.8V 25.6V 27.4V 10.4V 11.5V 11.5V 26.2V 23.7V

3.2.2 Basic Feasibility Calculations

Initial feasibility calculations were performed using the electric flight performance

predictive software package MotoCalc. This allowed for a comparative analysis of

different motor, propeller and battery combinations. The Plettenberg 220 range, along

with the Hacker B40 and B50 range combined with an 11.1 V LiPo battery allowed

for sufficient thrust attainment (at least 25 N per motor/propeller combination) with

propeller diameters greater than 15”. The mass of the LiPo batteries required to provide

the desired thrust is estimated at 0.32kg, with the motor mass approximately 0.25 kg

each. The collective thrust attainable through the use of two electric motors driving

propellers of diameter greater than 15” is therefore estimated to be at least 50 N and thus

17

Chapter 3. Concept Evaluation 3.3. Conclusion

comfortably exceeds the expected mass of the frame, motors and batteries estimated to

be approximately 2.5 kg.

Thus is would appear that the use of electric motors and propellers, powered by LiPo

batteries, provide sufficient levels of thrust to warrant further investigation into their use

as a thrust unit in the VTOL design.

3.3 Conclusion

The deciding factor in choosing to base the project aircraft on the V-22 Osprey was

its ability to generate more static thrust at a lower weight than the F-35. The F-35

has considerable size constraints on the impeller, hence putting an upper limit on the

attainable static thrust. When using propellers with the V-22 model these constraints

were relaxed and thus adequate thrust levels required for VTOL were attainable.

18

Chapter 4

Mechanical Design

4.1 Control Requirements

In order to properly design a frame its functional requirements must be defined. In this

case it must provide sufficient actuation for control of the degrees of freedom of interest.

4.1.1 Yaw Control

In the real V-22 Osprey yaw is controlled by differential longitudinal cyclic pitch, this

offsets the thrust angle resulting in a yaw moment about the centre of mass while

maintaining a net vertical thrust. The model V-22 simplifies this method by counter-

rotating the wing-arm (and motors) as shown in Figure 4.1. For conventional flight the

motors must also be able to tilt all of the way forward. As a result the motors were

designed to be able to rotate slightly more than 90◦.

Figure 4.1: Yaw Control

19

Chapter 4. Mechanical Design 4.2. Frame Design

4.1.2 Pitch Control

Pitch is controlled by using several complex techniques such as pendulum balancing and

longitudinal cyclic pitch control in the real V-22 Osprey. The model V-22 controls pitch

by the addition of a tail fan unit. This provides a much simpler and decoupled control

method than that employed by the real V-22 Osprey at the expense of model aesthetics.

The frame therefore provides facilities to mount a small ducted fan at the rear.

Given the helicopter nature of the V-22 Osprey, when in hover pitch is highly coupled

with forward translation. Thus if the aircraft pitches forward it will move forward as well

due to the thrust being slightly non-vertical.

4.1.3 Roll Control

Roll in the real V-22 Osprey is produced by creating a differential thrust at each proprotor.

This differential thrust creates a moment about the centre of mass and causes rotation

about its longitudinal axis. The real V-22 Osprey creates this thrust differential by

adjusting the collective pitch of each proprotor since speed control is too slow due to

the large rotational inertia of the propellers. To simplify this, the model V-22 uses two

separate motors and creates the differential thrust simply by differential motor speeds.

4.1.4 Translation Control

The real V-22 Osprey controls vertical translation by collectively changing the thrust at

each proprotor. This is achieved in the model V-22 by collectively changing the motor

speeds.

The actual V-22 Osprey can strafe in the horizontal axis by laterally adjusting the angle

of the proprotors. This feature is neglected on the model V-22 due to the associated

complexities in both the mechanical and control system designs. Thus control of horizontal

translation is achieved through the natural coupling with pitch and roll.

4.2 Frame Design

A general aircraft frame must be as light as possible while still being sufficiently strong

to carry all components and not fail. Furthermore for a VTOL platform the frame must

20

4.2. Frame Design Chapter 4. Mechanical Design

provide sufficient actuation, as just discussed, to enable a sustained, stable hover. The

frame must also be sufficiently configurable to accommodate any design changes.

The frame was designed using the Computer Aided Design (CAD) package SolidEdge.

SolidEdge models parts as solids, with associated physical properties such as density.

This allows the monitoring of the total system mass, the centre of mass and the rotational

moments of inertia about the centre of mass. All of these properties are important when

designing a control system.

4.2.1 Materials

According to Newman (2005), materials commonly used in the construction of model

aircraft are Aluminium, Balsa Wood, Birch Wood, Carbon Fibre Tube, Cellfoam 88

and Depron. The relevant mechanical properties are shown in Table 4.1. Due to the

similar properties of Cellfoam 88 and Depron they have both been included as the Foamed

Polymer entry.

Table 4.1: Mechanical Properties of Common Model Aircraft Materials

Material Density ρ(kg/m3)

Young’sModulusE(GPa)

Ultimate TensileStrength σut(MPa)

6060 T4 Aluminium 2710 70 160Balsa Wood 110 - 150 2.6 - 3.5 10 - 12Birch Wood 500 - 700 4.5 - 10.3 27 - 40

Carbon Fibre Tube 1500 - 1600 60 - 160 300 - 800Foamed Polymer 50 - 77 0.0034 - 0.032 0.01 - 0.9

Aluminium was chosen as the base frame material due to its low cost and easy fabrication

properties, despite Carbon Fibre Tubing having a significant strength to weight advantage.

4.2.2 Tilt Rotor Concepts

As previously discussed the nacelle of our proposed model design must be able to rotate

over 90◦ to meet the control requirements. Several concepts to allow this were considered,

before the current solution was chosen.

The concept of a rotating motor mount directly coupled to a servo motor is shown in

Figure 4.2. This concept is mechanically sound, providing the required rotation with the

21


forces supported by the bearings. The directly coupled servo motor provides a direct,

linear link between the servo motor angles and the angle of the propulsion system. The

main disadvantage of this concept is the considerable mass and size associated with the

large wing-arm section. The servo motor and bearing required would also be quite large,

necessitating a larger scale model to accommodate it all.

Figure 4.2: Rotating Mount Concept

An alternative solution of placing the motors inside the frame, driving the propellers

through 90◦ gearboxes, is shown in Figure 4.3. This concept removes the weight of the

bulky components from the end of the wing, allowing for a lighter wing section. There

are several disadvantages to this concept. Firstly, having the weight close to the centre of

mass reduces the rotational moment of inertia, making the platform less stable as it will

rotate more quickly. Secondly, the centre of nacelle rotation must be based at the same

point as the motor shaft passes through. A consequence of this is that when the nacelle

rotates the propeller speed will change due to relative speed differences. Additionally long

shaft sections rotating at high speeds are prone to vibration.

4.2.3 Final Tilt-Rotor Design

Combining several of the advantages of the concept solution, the final solution is shown

in Figure 4.4. It features a servo motor directly coupled to the aluminium tube which

supports the motor. The bearing and servo motor are located on the fuselage, removing all

bulky components except the motor and gearbox from the wing itself. An interchangeable

mount is used at the end of the tube to provide versatility should a different motor be

required. The motor and motor mount at the outer end of the tube are shown in Figure

4.5. For the details of the wing arm parts and assembly refer to Appendix A.

22


Figure 4.3: Internal Motor Concept

Figure 4.4: Final Motor Rotation Configuration

23


Figure 4.5: Motor and Motor Mount

4.2.4 Frame Concepts

Referring to Section 4.2.1, Aluminium was chosen as the base frame material. To simplify

fabrication it was decided that standard Aluminium sections would be used. Originally

using 12 × 20 × 1.5 mm unequal angle sections and 10 × 1.2 mm tube, the first frame

concept shown in Figure 4.6 was constructed in SolidEdge. This frame had several strong

features, including rotating wing arms, a rigid central mount for the IMU to locate it at

the model V-22’s centre of mass, and versatile motor mounts. It was scaled to fit inside a

1:15 scale model size of the actual V-22 Osprey. The major drawback of this design was

its weight, approximately 800 g according to SolidEdge. This was considered too heavy

for just a bare frame.

Following this, the frame was redesigned to be lighter by using less Aluminium and better

utilising Balsa wood as a material. The concept is shown in Figure 4.7.

As a further evolution to the weight reduction by making the frame as small as possible,

the concept shown in Figure 4.8 was considered. Although this concept frame has much

less room for components than the previous two, its lighter weight makes it a desirable

solution.

24


Figure 4.6: First Frame Concept

25


Figure 4.7: Redesigned Frame Concept

26


Figure 4.8: Final Frame Concept Sketch

27

Chapter 4. Mechanical Design 4.3. Propulsion

4.2.5 Final Frame Design

The final frame design is an evolution of the concepts, and as such it closely resembles the

concept sketch in Figure 4.8. Upon construction in SolidEdge it was evident this concept

solution may not accommodate all of the components. A Balsa wood subcarriage was

considered to hold some of the bulky components such as batteries, as shown in Figure

4.9, however it was not used as the hardware was attached to both the top and bottom

of the frame, alleviating the need for an undercarriage.

Figure 4.9: Final Frame Design

The frame was constructed without the balsa-wood subcarriage is shown in Figure 4.10.

The frame as-built differs from the previous design slightly due to the recommendations

of the workshop staff. These recommendations included the use of thicker wing-arm and

rear-arm tubing, now 16×2 mm aluminium tube, and the inclusion of a top plate between

the bearing blocks to reduce lateral deflection under load.

The final frame design is estimated to weigh the same as the first concept designed in

SolidEdge, however through the use of larger materials its strength and hence robustness

against damage was greatly increased. For the full details of the frame construction,

please refer to Appendix A.

4.3 Propulsion

The propulsion unit in a VTOL aircraft is of extreme importance, as it is responsible

for generating enough thrust to overcome the mass of the aircraft. Propulsion units are

28

4.3. Propulsion Chapter 4. Mechanical Design

Figure 4.10: Frame As Built

generally comprised of a motor that drives some kind of propeller/impeller and a power

source. The most appropriate motor, propeller and power source combination for this

design were considered for selection.

4.3.1 Propeller

The actual V-22 Osprey operates variable-pitch proprotors to obtain the required thrust

outputs (Boeing, 2005). The proprotor system of the Osprey incorporates a tri-blade hub,

with automatic folding graphite/fibreglass blades. The approximate diameter of the rotor

system is 11.58 m and thus they have significant rotational inertia due to their large size.

For this reason the V-22 Osprey proprotors operate at a constant speed with variable

pitch utilised to adjust thrust.

The propeller choice for this project was primarily dependant on the static thrust required

to achieve stable hover. The actual selection was an iterative process, as the required

maximum thrust was dependant on the final weight of the model. However, the weight

of the model depended significantly on the choice of the motors, propellers and batteries.

Thus the final weight of the model had to be estimated using the weight of known

components, the frame and choosing an appropriate sized motor and battery to suit.

The chosen propeller must be available as a pusher/tractor pair, this is when two propellers

are identical but designed to operate in different rotational directions. By doing this the

drag forces which act on the propeller to create a yawing moment on the frame are

cancelled out by their counter-rotation.

29


4.3.2 Propeller Theory

Basic propeller theory contains several equations that were used as a guide in the selection

of an appropriate propeller (McCormick, 1995). The most important of these equations

is that which determines an appropriate blade diameter D based on required static thrust

T and the induced power at static thrust Pi0 :

T = P23

i0

(1

2ρπD2

) 13

(4.1)

where ρ is the density of air.

Estimating the required static thrust to be 24.5N and using the required induced power to

be 375W from data obtained during Section 3.2.2, the required propeller was estimated

to be 15”. However this was a lower bounds estimate as the in-ground effects caused

by the propeller sucking in its own downwash had not been considered. According to

Newman (2005) an in-ground effect correction factor of 1.3 was needed to be factored into

the thrust and yielded an estimated propeller diameter of 21”.

4.3.2.1 Fixed vs Variable Pitch

For propellers with a large rotational inertia, variable thrust is accomplished by varying

the pitch of the propeller, whilst maintaining a constant rotational speed. This type

of thrust control significantly adds to the complexity of the mechanical design. The

alternative method consists of using a fixed pitch propeller and varying the rotational

velocity to vary the thrust response. This type of thrust control is limited by the torquing

capabilities of the motor providing the power and is heavily dependant on the rotational

inertia of the chosen propeller. Due to the reduction in both mechanical and control

system design and the low inertia associated with the use of fixed pitch model aircraft

propellers, they were selected over variable-pitch propellers as the method for thrust

variation in the design.

4.3.2.2 Number of Blades

It was decided to use two-blade propellers as compared to the three-bladed system used by

the real V-22 Osprey. This is due to the increased efficiency of the two-bladed propellers

over the three-bladed propellers (HazelProp, 2005).

30


4.3.2.3 Material

The material of the propeller needed to be light weight, rigid and extremely durable, as

the model would be subject to potential failures where the propeller could experience

possible impacts. According to Airfield Models (2005) the five commonly used materials

for model aircraft propellers are wood, nylon, fibreglass-reinforced nylon, fibreglass and

carbon fibre. Wood propellers were not considered as they lacked sufficient strength,

particularly in the larger designs. Nylon propellers were also not a practical choice of

material, although they are highly resilient to impact they are exceedingly flexible and

thus cause a continual change to pitch in addition to high levels of vibration. Both carbon

fibre and fibreglass propellers were viable options, however, due to the expensiveness of

carbon fibre and the non-durable nature of fibreglass they were not considered as suitable

propeller choices. Glass-filled nylon or fibreglass-reinforced nylon were chosen as the most

desirable propeller materials as they are highly durable, rigid and reasonably inexpensive,

though less efficient than carbon fibre propellers.

4.3.2.4 Size

The size of the propeller is specified by the tip to tip diameter and the associated pitch.

In this case MotoCalc was used to determine the most suitable propeller size based on the

required static thrust and induced power of the electric motor. The result of MotoCalc

was that a diameter of at least 18” and a pitch no less than 10” was required for 25 N of

thrust at maximum efficiency. The motor/propeller combination must have a steep speed

gradient at their hover point in order to give adequate authority for the control system,

so a small pitch had to be used as this gives finer speed control.

4.3.2.5 Final Selection

The final choice of propeller consisted of a 20” × 10” APC glass-filled nylon two-blade

fixed-pitch propeller, which is available as a pusher/tractor pair. The size constraints

were confirmed by basic propeller theory, which estimated the propeller diameter to be

approximately 15”. This is a lower estimate because it does not consider in-ground effects,

which will occur during initial stages of hover. When such effects are factored into the

calculations, a resultant propeller diameter of approximately 21” is found, which agrees

with the estimation made by MotoCalc.

31


4.3.3 Motor

Consideration was given to the use of several types of motors, ranging from small jet

engines through to internal combustion engines. However, following the recommendations

of Jarrett et al. (2004) and the selection criteria of cost, efficiency, reliability, size, weight

and ease of operation it was decided to use electric motors to drive the propellers. Two

possible types of electric motors were considered for selection, brushed and brushless.

4.3.3.1 Brushed Motors

Brushed electric motors are the simplest form of direct current (DC) motor to use. They

operate with permanent magnets attached to the case and windings attached to their

rotor, using brushes to produce mechanical commutation. Whilst they are easy to use

they typically operate at a lower efficiency than the equivalent brushless motor and are

not commonly used in remote control motors of the power rating required for the project.

Due to the wear on the brushes, from the nature of mechanical commutation, the motor

performance will vary with long-term operation. Hence any motor constants used in the

construction of the control system will change over time as the motor wears.

4.3.3.2 Brushless Motors

The brushless DC electric motor uses an electronically controlled commutation system,

instead of a mechanically controlled commutation system (Wikipedia, 2005). The benefits

of using a brushless motor over a conventional brushed motor include higher reliability,

longer lifetime (no brush erosion), elimination of ionizing sparks from the commutator,

and overall reduction of electromagnetic interference. Brushless motors generally operate

at efficiencies between 80% and 90% while brushed motors of the same capacity typically

operate at 60-70% (RS Automation, 2005). Furthermore, brushless motors are able to

operate consistently at higher RPM and with higher cogging-torque, they are ideal for

use in this application because of both the large size and expected high speeds of the

propellers.

There are two types of DC brushless motor used in RC equipment, the standard brushless

motor (also known as the ‘inrunner’) and the ‘outrunner’. Both types of motor contain

fixed windings with rotating permanent magnets, the difference being the standard

brushless motor has the permanent magnets attached to the rotor, while on an outrunner

they are attached to a section of the outer casing which rotates, driving the rotor through

32


gears. The outrunner has a higher start-up torque than a standard brushless motor, but

it was decided against using these due to their increased mounting complexities, smaller

product range and relative infancy.

Given their windings are fixed, brushless DC motors require a three-phase power supply in

order to operate. This is provided by an Electronic Speed Controller (ESC) which chops

the DC supply voltage into a three-phase signal for powering the motor and controlling

its speed.

4.3.3.3 Final Selection

Brushless motors were chosen over conventional brushed motors to drive the propellers

based on their high RPM and torque capabilities in conjunction with the minimal

associated wear, resulting in constant motor characteristics over the life of operation.

As with the propeller selection, the choice of motor was determined through the

‘comparative’ ability of the MotoCalc software (Newman, 2005) These calculations

compensate for motor heating effects, which is important as motor efficiency changes with

temperature. The primary consideration in the selection of the motor was the required

static thrust. Although the static thrust was dependant on the weight of the motor itself,

an estimation was used and a motor selected which would attain the required static thrust

to maintain hover at as close to maximum efficiency as possible. The associated thrust

value estimated to be needed at maximum efficiency was 25 N .

An iterative process of determining the ideal motor based on the desired thrust and known

constraints led to the selection of the Plettenberg 220/30/A3 P4 brushless motor, with a

planetary gearbox at a ratio of 5:1. This motor and propeller combination, although not

the optimum solution for maximum efficiency at hover, was the best combination that

could be found without undertaking a substantial optimisation analysis. To drive the

Plettenberg motors, an 80 A Hyperion ESC was selected.

4.3.4 Batteries

A number of requirements were placed about the selection of battery. Firstly, the battery

needed to be rechargeable, with a large number of charge cycles (¿100) possible. Secondly,

the battery was required to output a minimum of 20A at a minimum of 10V, in order to

effectively drive the above motor and propeller combination (ICARE, 2005). Finally, the

selection of battery type was heavily dependant on energy density, as the weight budget

of the model is a crucial factor for a model VTOL aircraft. Three commonly used battery

33


types were considered to drive the brushless electric motors. These were Nickel-Cadmium

(NiCd), Nickel-Metal Hydride (NiMH) and Lithium Polymer (LiPo) and the comparative

analysis can be seen in Table 4.2, where the gravimetric energy density is the value of

average power discharge multiplied by the number of service hours divided by the mass

of the battery.

Table 4.2: Comparison of Battery Types

Battery Type

Characteristic NiCd NiMH LiPoVoltage (V ) 9.6 12 8.4 12 12 7.4 11.1 11.1

Capacity (mAh) 2400 2400 3000 1000 3000 1700 2250 3600Weight (g) 495 670 442 205 600 82 150 302

Gravimetric EnergyDensity (Wh/kg)

45-80 60-120 100-130

From this table, the decision was made to use Lithium Polymer batteries because of their

higher gravimetric energy density. The Plettenberg 220/30/A3 P4 brushless motors were

easily powered from 11.1V, however commonly attainable LiPo packs of 2450mAh were

unable to provide the continuously required current. Thus two 11.1V (3S1P) LiPo battery

packs were chosen to be used in parallel to effectively power the propulsion unit. This

configuration also increases the flight time. The batteries selected were the Tanic 11.1V,

2450mAh LiPo packs. These each weighed 165g, resulting in a net battery weight of 660g

for the main motors.

4.3.5 Propulsion Component Summary

Thus the final selection for the propulsion unit of the model consisted of two Plettenberg

220/30/A3 P4 brushless motors geared 5:1, each connected to a 20”×10” APC glass-filled

nylon two-blade fixed pitch propeller. Each motor is controlled using an 80 Amp Hyperion

Brushless ESC, and is to be powered by two Tanic 11.1V 2450mAh LiPo battery packs

in parallel.

The theoretical thrust levels attained by each motor and propeller combination were

estimated by MotoCalc to be 27 N using a 20”×10” propeller. The actual thrust attained

during testing was approximately 25N. This discrepancy was likely due to significant in-

ground effects in the confined area of testing and motor losses.

34


Figure 4.11: Selected Motor, Propeller and ESC.

4.3.6 Tail Thrust

As discussed in Section 4.1 it was decided to use a thrust unit at the tail of the plane to

control pitch. The thrust (T ) generated by the primary motors creates a moment (M)

about the aircraft’s centre of mass, defined by:

M = T × d (4.2)

where d is the perpendicular distance between the vertical thrust line and the centre of

mass, as shown in Figure 4.12.

Figure 4.12: Moment About CoM from Primary Thrust

By the addition of an tail fan at the rear of the aircraft generating a thrust (Tt) at a

distance (dt) from the centre of mass of the aircraft another moment (Mt) is created as

35

Chapter 4. Mechanical Design 4.4. Sensors

shown in Figure 4.13. By balancing these moments the minimum required static thrust

at the tail was calculated using:

Tt = T × d

dt

(4.3)

The ratio of distances, ddt

, is relatively small, estimated using SolidEdge at being

approximately 45750

= 0.06, thus the required thrust at the tail is relatively small. Given

an estimated primary thrust of 25N during standard hover, the required thrust at the tail

would be a minimum of 1.5N . It is desired that the tail thrust unit produce at least twice

this value to ensure sufficient controllability. Pitch control in both directions is achieved

by either increasing or decreasing the thrust provided by the tail fan about the point

where it cancels the moment generated by the primary propellers.

Figure 4.13: Net Moment of Zero About CoM

The tail thrust is attained through the use of a WeMoTec 5-blade ducted micro-fan,

driven by a brushless Himax 2015 4100 electric motor. The motor is powered using a 20A

Hyperion ESC. The components of the tail unit can be seen in Figure 4.14. The thrust

levels attained by this unit were estimated to be 3.0 N , which provides adequate pitch

authority.

4.4 Sensors

Sensors are required to return data of the planes position and orientation to the controller.

Sensors constitute a large proportion of the cost of the plane and the controller system.

36

4.4. Sensors Chapter 4. Mechanical Design

Figure 4.14: Rear Thrust Unit - Brushless Motor, Ducted Mini-Fan, ESC

4.4.1 Inertial Measurement Unit (IMU)

The Inertial Measurement Unit (IMU) is a device used to obtain information about the

current state of the aircraft, specifically the accelerations, Euler angles and angular rates.

The MicroStrain 3DM-GX1 was chosen as the IMU for this aircraft due to its gyro-

stabilised output which eliminates accelerometer drift and hence the need for an external

Kalman filter. The 3DM-GX1 combines three angular rate gyros with three orthogonal DC

accelerometers, three orthogonal magnetometers, multiplexer, 12 bit A/D converter, and

embedded microcontroller. This enables it to measure the three orientation angles (pitch,

roll and yaw), the three angular rates (pitch rate, roll rate and yaw rate) and acceleration

in the three linear axes (X, Y and Z) in both dynamic and static environments.

The IMU communicates using an RS-232 serial connection with a maximum data rate of

115.2 kbaud. With a maximum data output rate of 100Hz the 3DM-GX1 easily provides

sufficient feedback to the control system to achieve a stable hover.

Due to the high cost (approximately half the expected commercial cost of the aircraft),

the use of the 3DM-GX1 is a short term solution. In the long term, an affordable IMU

incorporating a Kalman filter may be developed as a level four Mechanical Engineering

project.

4.4.2 Rate Gyroscopes

In order to make the aircraft more affordable to the ‘every-day’ enthusiast it is envisioned

that the expensive IMU will be replaced with cheaper rate gyroscopes. This will result in

a loss of precision and an increase in computational effort by the embedded controller in

order to maintain the aircraft in a stable hover.

37

Chapter 4. Mechanical Design 4.5. Actuators

This year the project did not progress to a stage where rate gyroscopes had to be

considered, hence they were not thoroughly investigated. Reference to rate gyroscopes is

made in Section 11.2.4.

4.5 Actuators

4.5.1 Servo Motors

Servo motors allow accurate open-loop command following of their shaft angle thanks

to their on-board controller circuit. They are controlled by a Pulse-Width-Modulated

(PWM) signal where the desired servo motor angle is proportional to the pulse width,

as discussed further in Section 7.1.1.1. RC servo motors generally run between 4 and 8

Volts and may oscillate if they are supplied with a voltage that is too high. Servo motors

typically draw 130mA under normal operation, but they can draw over 1A when under

full load.

To rotate the wing arms the JR 577 standard servo motor were initially chosen. However

these proved inadequate as discussed later in Section 10.4. Following this the JR 579

servo motors, which feature metal gears, a ball-race and can provide 0.824 N.m torque

when run at 4.8V (Modelflight, 2005) were chosen. The JR 579 servo motor mounted to

the wing arm is shown in Figure 4.15.

Figure 4.15: Servo Mounted on Wing Arm

38

Chapter 5

Mathematical System Model

5.1 Introduction

To be able to design a state space controller for the model aircraft a set of state space

equations are required. These must be formulated from physical laws and simplified to

allow for the development of a working linear controller.

A diagram of the axes system used to derive the equations is presented in Figure 5.1. It

is important to note that this system does not share the complexities of more common

aircraft axes systems. Moments about axes and angular velocities are not given separate

labels. The system originates at the centre of mass of the plane with the longitudinal axis

(X) running through the fuselage in the direction of the nose of the plane. The lateral axis

(Y) is positive out of the left (port) wing of the plane. The vertical axis (Z) is positive in

the upward direction. All forces, displacements and velocities along each of these three

body reference axes are positive in the directions indicated. Pitch moments, angles and

angular velocities of the aircraft are positive in a nose-up direction. Yaw moments, angles

and angular velocities are positive in the nose-left direction. Roll moments, angles and

angular velocities are positive for left wing down rotations.

5.2 State Equations

5.2.1 Linearisation Methods Used

To allow for the implementation of a state space controller a linearised state model is

required. This model is derived from the state equations through the linearisation of non-

39

Chapter 5. Mathematical System Model 5.2. State Equations

Figure 5.1: Basic Diagram of Model Layout

linear terms in the equations. The following simplifications are applied in the derivation

of the model.

Where φ is small, we assume sin φ = φ and cos φ = 1. The lift generated by the propellers

is proportional to angular velocity squared (θi2). We assume that lift can be approximated

as a linear function of angular velocity when near the angular velocity required for hover.

Hence:

θ2i ≈ θ0θi (5.1)

where:

θ0 is the angular velocity of the propellers at hover.

θi is the angular velocity of the propellers.

5.2.2 Propeller Angles

In order to affect control in various degrees of freedom the propellers are required to rotate

independently relative to the XY axis of the plane as in Section 5.2. These angles are φL

and φR (for left and right propeller angles respectively). For transition to normal flight

the propellers must both rotate around to the position of a standard plane. However, for

the purposes of the state model for hover the rotation angles will be restricted to small

values. Gyroscopic effects either directly or indirectly caused by the servo motors or the

dynamic movement of angle φ of the propeller are assumed negligible. The servo motors

are controlled by Pulse Width Modulation (PWM), so for simplicity it will be assumed

that φ is the input to the equations. In practice the values of φ will be related to the

servo motors as PWM outputs from the microcontroller.

40

5.2. State Equations Chapter 5. Mathematical System Model

Figure 5.2: Propeller Angles

5.2.3 Left and Right Propeller State Equations

The torque balance and electrical motor equation derivations are directly from the analysis

of the Quanser 3DOF Hover platform (Cazzolato, 2005a).

If we start with the torque balance from the motor then we have the following non-linear

equation:

Jmθm + bmθm + kD(θMm)2 = kT ia (5.2)

where:

Jm is the moment of inertia of the propeller and motor rotor.

bm is the viscous friction in the motor rotor.

kD(θm)2 is the reactive torque, in free air, by the propeller due aerodynamic drag.

kD > 0 is the drag constant of the propellers, which is a factor of the air density, the

propeller dimensions and other factors.

kT is the torque constant of the motor.

ia is the armature current.

θm is the angular position of the rotor.

Another system of equations that governs the dynamics is the electrical equation of the

motor:

41


Laia + Raia = Va − keθm (5.3)

where:

La is the armature inductance.

Ra is the armature resistance.

ka is the back EMF constant and is equal to the torque constant of the motor when in SI

units.

Va is the voltage applied to the motor.

In many cases the relative effect of the inductance is negligible compared to the mechanical

motion and can be neglected in Equation 5.3. This leave us with:

Raia = Va − keθm (5.4)

Combining Equations 5.2 and 5.4 yields:

Jmθm + (bm +kT ke

Ra

+ kDθm,0)θm =kT

Ra

Va (5.5)

Jmθm =kT

Ra

Va − (bm +kT ke

Ra

+ kDθm,0)θm (5.6)

Equation 5.6 can be written for each propeller:

θL =1

Jprop

(kT

Ra

VL −Kmpθm

)(5.7)

θR =1

Jprop

(kT

Ra

VR −Kmpθm

)(5.8)

where Kmp = bm + kT ke

Ra+ kDθm,0

42


5.2.4 Rear Impeller Equation

The rear ducted fan impeller is expected to have a moment of inertia (J) low enough

such that it can be assumed to have negligible effect on the angular acceleration of the

impeller. Removing this term from Equation 5.6 and rearranging yields:

VB =RB

kB

(bB +kBke

RB

+ kD,rearθB,0)θB (5.9)

VB = KB˙θB (5.10)

where:

KB =RB

kB

(bB +kBke

RB

+ kD,rearθB,0) (5.11)

5.2.5 Pitch Axis

Taking the torque balance about the pitch axis, the following expression can be derived:

Jpp ≈ l1(FL + FR)− l2Fb (5.12)

Therefore:

p =l1Jp

(FL cos φL + FR cos φR)− l2Jp

FB (5.13)

Simplifying by applying trigonometric linearisation:

p =l1Jp

(FL + FR)− l2Jp

FB ≈l1Kprop

Jp

(VL + VR)− l2Krear

JP

VB (5.14)

where:

JP is the moment of inertia of the body about the pitch axis.

l1 is the distance from the pitch axis to either front propeller centre.

l2 is the distance from the pitch axis to the back propeller centre.

kl is the coefficient of lift for the two front propellers.

43


kl,rear is the coefficient of lift for the back propeller.

θL, θR and θB are the angular velocity of the left and right propellers and back fan

respectively.

Kprop = klθ0kT

RaKmpis the approximated (linearised) lift supplied by the propellers for a given

input voltage.

Krear =kl,rear θ0,B

KBis the lift supplied by the rear fan for a given input voltage.

It should be noted that the longitudinal distance between the centre of mass and the lift

point of the propellers (l1) is affected by the angle of the motors. The lift point is moved

when the motors are not parallel to the pitch axis. This change in l1 is non-linear and

assumed negligible.

5.2.6 Roll Axis

Taking the torque balance about the roll axis, the following expressions can be derived:

Jrr ≈ l3(Fl − Fr) (5.15)

Therefore:

r =l3Jr

(FL cos φL − FB cos φR) (5.16)

Simplify by applying trigonometric linearisation:

r =l3Jr

(FL − FR) =l3Kprop

Jr

(VL − VR) (5.17)

where:

Jr is the moment of inertia of the body about the roll axis.

l3 is the distance from the roll axis to either propeller centre.

θL and θR are the angular velocity of the left and right propellers respectively.

Kprop = klθ0kT

RaKmpis the approximated (linearised) lift supplied by the propellers for a given

input voltage.

44


5.2.7 Yaw Axis

Taking the torque balance about the yaw axis yields:

Jyy ≈ l3(FL,yaw + FR,yaw) + τL − τR + τB (5.18)

y =l3Jy

(FL sin φL − FR sin φL) +KD,prop

Jy

(VL − VR) +KD,rear

Jy

VB (5.19)


y =1

Jy

(l3(FLφL + FRφR) + KD,prop(VL − VR) + KD,rearVB) (5.20)

This can be approximated by:

y =1

Jy

(l3Kprop(VLφL + VRφR) + KD,prop(VL − VR) + KD,rearVB) (5.21)

This is linearised by removal of the multiplication between the input voltage and propeller

angle.

y =1

Jy

(l3Kprop(VhovφL + VhovφR) + KD,prop(VL − VR) + KD,rearVB) (5.22)

where:

Jy is the moment of inertia of the body about the yaw axis.

l3 is the distance from the roll axis to either propeller centre.

θL and θR are the angular velocity of the left and right propellers respectively.

θB is the angular velocity of the rear impeller.

θ0 is the angular velocity of the front propellers at hover.

θ0,B is the angular velocity of the rear impeller at hover.

Vhov is the voltage supplied to the front propellers for hover.

45


Kprop = klθ0kT

RAKmpis the approximated lift supplied by the propellers (at hover angular

velocity) for a given motor input voltage.

KD,prop = kD θ0kT

RAKmpis the torque constant that relates the torque generated by the propeller

when a voltage is applied to the motor.

KD,rear =kD,rear θ0kT

RAKmpis the torque constant that relates the torque generated by the rear

impeller when a voltage is applied to the motor.

5.2.8 Vertical Translation

For z-axis translation, it is assumed that in-ground effects are negligible and that the

translational velocity is too low to induce significant drag. All translations are expressed

in body reference frame.

Therefore:

MP z =∑

Fz ≈ FL cos φL + FR cos φR + FB −W (5.23)

where W = MP g the total weight of the model.

Linearising the cosine terms and replacing the forces with voltage input relationships

gives:

MP z = KpropVL + KpropVR + KrearVB −W (5.24)

MP z = Kprop(VL + VR) + KrearVB −W (5.25)

5.2.9 Lateral and Longitudinal Translation

For both lateral and longitudinal translation it is assumed that drag is negligible due to

low velocity. Since there are no translation forces acting along the lateral axis the lateral

translation is not considered. Thus:

MP y = 0 (5.26)

In the longitudinal direction the only translational forces are from the tilted propellers.

Thus:

46

5.3. Virtual Reality Model Chapter 5. Mathematical System Model

MP x =∑

Fx ≈ FL sin φL + FR sin φR (5.27)


MP x = FLφL + FRφR = Kprop(VLφL + VRφR) (5.28)

This equation can be simplified further by assuming that the motors will be running at a

voltage near their hover voltage.

MP x = Kprop(VhovφL + VhovφR) (5.29)

5.3 Virtual Reality Model

The virtual reality (VR) model was developed in order to be able to visualise the aircraft’s

expected behaviour during flight. Initially a simple model was created using the VRML

Editor software V-Realm Builder 2.0 editor and the Matlab VR toolkit. This model was

used to learn the basic concepts of using the VR software and can be seen in Figure 5.3.

When these concepts were understood a more advanced model was developed. Accurate

3D models of the V-22 Osprey are available for purchase on a number of dedicated 3D

model websites but are generally more expensive than necessary (approximately US$90).

A model of the Osprey developed using Gmax 1.2 by Travis FitzPatrick as a file for the

MS Flight Simulator computer game was discovered as a freely available download on the

Internet.

This file format is not compatible with the CAD and design software available at university

so the freeware computer game model design program Gmax was downloaded. The

developer of Gmax is Discreet Software (also developers of 3D Studio Max); however

the company has made it extremely difficult to convert files from one format to the other

for commercial reasons. The solution to this was to convert the Gmax file to a Quake

3 model (M3D) using Tempest (also freeware game model design software) and then to

a Raw Object file using 3D Exploration (shareware). The Matlab VRML Editor (V-

Realm 2.0) can be used to convert the Raw object into a VRML file, but the shapes are

scrambled within a single node and cannot be individually manipulated. The solution to

this was to use the university’s educational version of 3DS Max to convert the VRML to

a .max file and reclassify all shapes as individual nodes. From here individual shapes were

grouped into functional parts such as the propellers and motors before being exported

47

Chapter 5. Mathematical System Model 5.3. Virtual Reality Model

Figure 5.3: Basic Virtual Reality Model

as a VRML file. In the Matlab V-realm editor some aspects of the VRML file such as

rotational centres of nodes were redefined to allow for accurate animation as can be seen

in Figure 5.4. To complete the model colour changes were made to some components and

a background was added. The final model can be seen in Figure 5.5.

The Virtual Reality model is manipulated directly through Simulink using the VR Sink

block such as in Figure 5.6. The VR Sink block allows values for orientation and position

of each node to be altered relative to its parent node. The orientation of the whole model

is manipulated by inputting a vector consisting of four values into the VR Sink block

targeted at the V2Grp01 node which represents all nodes of the model. These values

include pitch, yaw and roll weighting as well as a sum of the three angles in radians.

Position in space is affected by a vector input in the three axes of the VR space again

targeted at the V2Grp01 node. The motors of the Osprey are manipulated by altering

the value of the angles of rotation of the two motor group nodes relative to the axis along

the wing. Rotation of the propellers is achieved by continuously increasing the angle

about the vertical axis relative to the motors. Models with a tail fan in place rotate the

blades of the tail fan in the same manner as the propellers. These inputs provide the

model with all of the functionality required for the current scope of the project. However,

features of the model such as the flight surfaces and landing gear have been left on the

model to be used at a later date if required. Furthermore, an advanced virtual world

could be constructed within which the Osprey could fly among fixed objects, complete

with collisions and lighting effects.

48

5.3. Virtual Reality Model Chapter 5. Mathematical System Model

Figure 5.4: V-22 Osprey Model in V-Realm Builder

Figure 5.5: Final V-22 Osprey VR Model

49

Chapter 5. Mathematical System Model 5.3. Virtual Reality Model

Figure 5.6: Simulink Model Driving the VR Block

50

Chapter 6

Control System

The control system for the RC VTOL aircraft forms a large part of the project. The

reason for this is the aircraft itself is inherently unstable in hover and thus would be

difficult to fly without a control system.

6.1 Classical Control (PID Controller)

6.1.1 Background

For Single Input Single Output (SISO) systems, the controller that is most commonly

used in industrial process control is the three-term or PID controller. This controller has

the following transfer function:

Gc(s) = KP +KI

s+ KDs (6.1)

where KP , KI and KD the proportional, integral and derivative gains respectively.

Equation 6.1 is often rewritten in terms of time constants:

Gc(s) = K +K

TIs+ KTDs (6.2)

where K is the overall gain, TI and TD are the integral and derivative time constants

respectively.

51

Chapter 6. Control System 6.1. Classical Control (PID Controller)

This controller is termed a PID controller because Equation 6.1 has a proportional,

integral and derivative term. Although these controllers are simple, they are quite robust,

simple to tune and often provide sufficient control. PID controllers have well known

tuning methods such as the Ziegler-Nichols Step and Ultimate Gain Methods (Dorf and

Bishop, 2001). Whilst these tuning methods are unlikely to produce an optimally tuned

controller, they do provide a good starting point for further optimisation.

The default PID block in Simulink is quite limited and an improved model was used

in this project. The improved model included an integrator anti-windup loop, setpoint

weighting, output saturation and a low-pass filter on the derivative term to reduce the

effect of noise (Cazzolato, 2005b). This model is shown in Figure 6.1.

Figure 6.1: Generalised PID Controller (Cazzolato, 2005b)

6.1.2 Application

It is possible to control a system such our aircraft using decoupled PID loops. Such

loops would view the coupling between axes purely as a disturbance and should be able

to compensate in a robust manner. This is the type of controller used by Jarrett et al.

(2004). A Simulink implementation of such a system is shown in Figure 6.2.

6.1.3 Controller Tuning

The group decided that the PID loops would be tuned one at a time, leaving any untuned

degrees of freedom in an open-loop (when feedback is not applied configuration). However

52

6.2. State Space Control Chapter 6. Control System

Figure 6.2: Decoupled PID Control System

the tuning of the controller while the aircraft was attached on the gimble proved difficult

due to the non-linearities introduced by having a pivot not located at the centre of mass

of the aircraft, as discussed in Section 10.6.

The aircraft was moved to its semi-tethered configuration and it was then attempted to

tune the controller. However due to the mechanical failure discussed in Section 10.3.2 this

was not completed.

6.2 State Space Control

6.2.1 Background

While classical control is quite successful in controlling SISO systems, it is often less

successful in controlling Multiple Input Multiple Output (MIMO) systems. Fortunately

state space or “modern control” techniques often provide adequate control. If the state

vector is defined as x = [x1 x2 . . . xn] then the differential equations governing the system

can be written in matrix form as:

x = Ax + Bu (6.3)

53

Chapter 6. Control System 6.2. State Space Control

y = Cx + Du (6.4)

State space controllers can be designed using pole placement or optimal control using a

Linear Quadratic Regulator (LQR). State space techniques have the potential to produce

a high-performance controller, however they require an accurate model of the plant

(Cazzolato, 2005c). Matlab has extensive optimal controller development tools which

can be used to determine the controller and observer gains. These calculated gains can

be used in Simulink with the dSPACE DS-1104 boards (and with the VR model) until

the controller is working as desired. Dr. Ben Cazzolato kindly provided a template state

space controller Matlab file to assist in the development of the controller.

Figure 6.3: Full State Space Controller (Cazzolato, 2005c)

6.2.2 Controller Design

Initially the mathematical equations derived in Chapter 5 were converted to a set of state

matrices as in Equation 6.5. Using Matlab and the template m-file for a state space

controller provided by Dr. Cazzolato the controller was developed around these state

matrices.

The mathematical equations for the behaviour of the plane were converted to a set of

state matrices. Relationships between states such as angular rates to angular positions

54


were represented by integral relationships. Initially there were 16 states; six for the yaw,

pitch and roll angular rates and positions, six for the translational velocity and positions

and an angular position and velocity state for each of the left and right motors. However,

the Y translation states were not implemented since they always equal zero.

y

y

p

p

r

r

θ

θ

θ

θ

X

X

Y

Y

Z

Z

=

0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 l1Kprop

Jp0 l1Kprop

Jp0 0 0 0 0 0

0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 l3Kprop

Jr0 −l3Kprop

Jr0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 −Kmp

Jprop0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 −Kmp

Jprop0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 Kprop

Mp0 Kprop

Mp0 0 0 0 0 0

y

y

p

p

r

r

θL

θL

θR

θR

X

X

Y

Y

Z

Z

+

0 0 0 0 0

0 0 KD,rearl3KpropVhov

Jy

−l3KpropVhov

Jy

0 0 0 0 0

0 0 −l2Krear

Jp0 0

0 0 0 0 0

0 0 0 0 0

0 0 0 0 0kT

RaJprop0 0 0 0

0 0 0 0 0

0 kT

RaJprop0 0 0

0 0 0 0 0

0 0 0 KpropVhov

Mp

KpropVhov

Mp

0 0 0 0 0

0 0 0 0 0

0 0 0 0 0

0 0 −Krear

Mp0 0

VL

VR

VB

φL

φR

(6.5)

55


During preliminary testing a number of states were removed from the state matrices.

The values of the angular position of the left and right motor/propeller states were

accumulating to very high levels and overloading the simulation. Since the thrust

generated by the propellers is relative to angular velocity, the angular position states

were irrelevant and were also removed. Furthermore, the X translation states were also

removed as the aim of this particular controller was only to facilitate stable hover. The

Z translation state was also removed due to the fact that the IMU can only measure

translational accelerations (double integration of the acceleration to measure position is

prone to large offset errors). The yaw position state was also removed as yaw rate was

deemed a more intuitive set-point input for a pilot. After the removal of these states the

state matrices were rearranged to facilitate the development of the reduced order observer

as discussed in Section 6.2.3. The final set of state matrices are 6.6 with outputs 6.7.

y

p

r

Z

p

r

θL

θR

=

0 0 0 0 0 0 0 0

0 0 0 0 1 0 0 0

0 0 0 0 0 1 0 0

0 0 0 0 0 0 Kprop

Mp

Kprop

Mp

0 0 0 0 0 0 l1Kprop

Jp

l1Kprop

Jp

0 0 0 0 0 0 l3Kprop

Jr

−l3Kprop

Jr

0 0 0 0 0 0 −Kmp

Jpr0

0 0 0 0 0 0 0 −Kmp

Jpr

y

p

r

Z

p

r

θL

θR

+

Kd −Kd Kd,rearl3KpVhov

Jy

−l3KpVhov

Jy

0 0 0 0 0

0 0 0 0 0

0 0 −Kr

Jp0 0

0 0 −l2Kr

Jr0 0

0 0 0 0 0kt

RaJpr0 0 0 0

0 kt

RaJpr0 0 0

VL

VR

VB

φL

φR

(6.6)

56


y

p

r

Z

=

1 0 0 0 0 0 0 0

0 1 0 0 0 0 0 0

0 0 1 0 0 0 0 0

0 0 0 1 0 0 0 0

y

p

r

Z

p

r

θL

θR

+

0 0 0 0 0

0 0 0 0 0

0 0 0 0 0

0 0 0 0 0

VL

VR

VB

φL

φR

(6.7)

The Matlab m-file uses Linear Quadratic Regulator (LQR) theory to determine the gain

matrices for the controller. LQR is a tool used in optimal control which involves the

setting of state weighting and control (effort) weighting matrices. These two matrices are

used in conjunction with the state matrices to develop a function of the physical cost of

controlling the plant with respect to the mathematical model. LQR determines a gain

matrix to minimise this cost function. If the equations model the behaviour of the plant

accurately then the controller can be tuned by altering the state weighting and control

penalty matrices and recalculating the gain matrix.

The mathematical model defines a number of constants required to enable implementation

of the controller. The accuracy of these constants is crucial to the development of

a working state space controller. Sourcing accurate values for some of the required

constants proved difficult, as a result some values had to be measured experimentally.

The torque constant and armature resistance of the motors were available from the

manufacturer. However, other constants considered in the mathematical model such as

the viscous resistance and armature current were unavailable. Data regarding the lift

and drag characteristics of the propellers is not published by the manufacturers, although

generic data is available from various enthusiasts and computer programs. PropCalc and

ThrustHP were used to estimate propeller performance relative to power input. These

programs claim to be within 10% of the true thrust for available RC propellers. The

rotational moment of inertia of the propellers was calculated using a generic equation

for 2-bladed RC propellers. After testing it was discovered that the accuracy of the

programs was within the claimed percentage (26.7 N estimated vs 24.5 N measured) and

almost identical after considering losses in the electric motor. Due to the unavailability

of motor constants for the rear fan this too had to be estimated until it was determined

experimentally. Rotational moments of inertia for the fuselage were calculated on the

SolidEdge model, as was the estimated mass. Whilst the constants used were reasonably

close to the physical values, a system identification as described in Section 11.2.3 would

result in a superior model upon which to design a controller.

57


For preliminary testing the equations of the mathematical model are used as the plant.

For the controller to work the values of all states must be fed back into the controller.

Not all of the states of the model can be measured by the IMU. Hence an observer is

required in the controller to estimate those states that are not measured.

6.2.3 Observer Design

To begin with, an observer with full-rank feedback (to observe all states) gain matrix

was developed to estimate the states. Initially the feedback matrix was determined using

pole placement, however the resulting observer matrix was unable to be calculated by

Matlab. An optimal observer was attempted but similar issues were encountered during

testing in Simulink. A reduced order observer was developed in an attempt to remedy

these problems. To develop a reduced order observer it is necessary to partition the states

into those xm which can be measured and those xu which must be estimated (Hansen and

Snyder, 1996). This resulting state equation is shown in Equation 6.8.

xm

xu

=

Amm Amu

Aum Auu

xm

xu

+

Bm

Bu

u (6.8)

An observer matrix L was created to estimate the states that are not measured. This

is implemented as in Section 6.4. In the final controller the ‘estim’ command is used in

Matlab to create a state space system to represent the whole observer.

Figure 6.4: Reduced Order Observer Implementation Cazzolato (2005c)

58


6.2.4 Simulink Model

A Simulink model of the desired controller complete with estimator was adapted from

the state space controller provided by Dr. Ben Cazzolato for the Quanser 3DOF Hover

Platform. The VR Model Block was added to this Simulink model and a reduced order

observer version was also created. The gain and observer matrices created by the controller

m-file can be implemented in such a Simulink block diagram of a state space controller.

For preliminary testing the equations of the mathematical model were used in a state

space Simulink block as the plant, with a gain block containing the state output matrix,

converting the output of the state space block to the correct vector.

Figure 6.5: Simulink State Space Model

For tethered testing the state space block was replaced with links to the DS-1104 boards

representing the outputs from the controller and the inputs from the IMU. Figure 6.6

shows the layout of the controller for testing, including a block to determine vertical

velocity as the return input for Z velocity.

6.2.5 Microcontroller Implementation

In order to convert the complete controller from a set of gain and observer matrices to

a form able to be implemented on a microcontroller, a state space model of the whole

system was created in Matlab. This was done by creating state space models for each

59


Figure 6.6: Simulink Model with Observer and Connections from IMU and to dSPACE

of the augmented states, estimator, set-point inputs and controller gains. These blocks

were appended into a single state space model. The ‘connect’ command was then used

to connect the various components of the model in the same manner as the Simulink

block model. Separate output states were added for the control signals of the voltages

and motor angles of the model so that they could be monitored. This process results in a

state space model that can be discretised and diagonalised. The resulting set of matrices

can more easily be converted to C-code for use in the microcontroller.

60

Chapter 7

Implementation of Control

7.1 Signals, Hardware and Software

In order to provide some insight into the way the control system was integrated, the

components are discussed briefly.

7.1.1 Control Signals

Control signals are the method by which different components of the control system

transfer information between each other. The two types of control signals used in this

project are Remote Control (RC) Pulse Width Modulation (PWM) and asynchronous

serial communications using the RS-232 standard.

7.1.1.1 RC Pulse Width Modulation

Pulse Width Modulation (PWM) is a technique commonly used to represent an analogue

signal using digital circuitry. It involves the switching on and off of a digital output at a

fixed frequency (switching frequency fs), but with varying times of either on or off. The

ratio of on-time to the total period (T = 1fs

) is called the duty cycle (d). Some examples

of a PWM signal are shown in Figure 7.1.

RC equipment such as servo motors and electronic speed controllers typically use PWM

signals to represent the control input. As opposed to standard PWM signals where the

signal value is dependant upon the duty-cycle, RC equipment use the actual pulse-width

(in seconds) to represent the signal. An RC PWM signal is usually bound between a 750 µs

61

Chapter 7. Implementation of Control 7.1. Signals, Hardware and Software

Figure 7.1: Example PWM Signals

and 2250 µs pulse width, with 1500 µs generally being accepted as the centre-point, as

indicated in Figure 7.2. The RC PWM signals usually operate fairly independently of the

PWM switching frequency, with the accepted range being between 20 Hzand 200 Hz.

Figure 7.2: RC PWM and Servo Motor Example

7.1.1.2 Asynchronous Serial Communications

Many devices communicate using an asynchronous serial communications port, ones in

this project include the IMU (mentioned previously), the PicoPic, dSPACE DS-1104 and

MiniDRAGON+ (all mentioned later). Several standards for this exist, including the

commonly known RS-232 and RS-485 standards. The standard used in this project

62

7.1. Signals, Hardware and Software Chapter 7. Implementation of Control

was RS-232 which will be discussed briefly, but a full description of the standard is

unwarranted.

The RS-232 standard includes many features, such as hardware flow control and

handshaking, but which are not usually used in practice. The connections of interest are

the transmit (Tx), receive (Rx) and ground (GND) lines. The standard also recommends

several connector types, commonly the DB-9 (or D-subminiature 9-pin) type. The

standard pinouts for these connectors, as well as the ones on the MiniDRAGON+ are

shown in Figure 7.3.

Figure 7.3: RS-232 Connectors and Pinouts used in this Project

7.1.2 Control Hardware

The control hardware is the hardware used to run the control system or assist in its

implementation.

7.1.2.1 dSPACE DS-1104

The dSPACE DS-1104 rapid prototyping platform is a real-time control target that is

extensively used in the construction and testing of control systems. The DS-1104 is an

expansion card that sits on the host computer’s PCI bus and contains its own PowerPC

CPU and a Texas Instruments (TI) Digital Signal Processor (DSP). Matlab Simulink

models are compiled using a cross-C compiler and loaded to the DS-1104 platform. Using

63

Chapter 7. Implementation of Control 7.1. Signals, Hardware and Software

the dSPACE software ControlDesk, variables and outputs from the Simulink model are

accessible via a Graphical User Interface (GUI). A dSPACE DS-1104 breakout board is


The DS-1104 hardware has eight Analogue to Digital (A/D) converters, eight Digital

the Analogue (D/A) converters, four PWM outputs, one asynchronous serial port (either

RS-232 or RS-422/485), two encoder readers as well as a host of other inputs and outputs.

Figure 7.4: dSPACE Breakout Board

7.1.2.2 MiniDRAGON+

The microcontroller chosen to run the embedded control system is the Motorola 68HCS12,

operating on a MiniDRAGON+ development board. The HCS12 is very flexible and

powerful when compared to similar microcontrollers, featuring a plethora of inputs and

outputs. Some of these include two asynchronous serial communication ports, two 10-bit

analogue to digital converters (multiplexed to 16 channels), eight 8-bit PWM outputs, an

Enhanced Capture Timer (ECT) and a variety of configurable digital input/output pins.

A MiniDRAGON+ is shown in Figure 7.5.

Dr. Frank Wornle has developed a Real-Time MC9S12 Simulink Target, allowing Simulink

models to be compiled onto the MiniDRAGON+ in a similar fashion to the dSPACE

platform.

7.1.2.3 PicoPic

The PicoPic servo controller is a PIC microcontroller that has been designed and built

by PicoBytes to generate RC PWM signals. It has 20 PWM output channels, each with

a resolution of 1 µs (giving approximately 1500 discrete output levels)(Picobytes inc.,

2003). It receives commands over its RS-232 asynchronous serial communications port

up to a rate of 115.2 kbaud, giving ample output bandwidth. The serial connection is

64

7.1. Signals, Hardware and Software Chapter 7. Implementation of Control

Figure 7.5: MiniDRAGON+ Development Board.

uni-directional, that is the PicoPic does not transmit any information it only receives it.

A PicoPic servo controller is shown in Figure 7.6.

Figure 7.6: PicoPic Servo Motor Controller.(Picobytes inc., 2003)

7.1.3 Control Software

The control software is the software used when designing, constructing and testing the

control system.

7.1.3.1 Matlab/Simulink

MathWorks Matlab (short for Matrix Laboratory) is a powerful mathematical program

that is commonly used not just for engineering, but many applications ranging from

financial modelling to image processing. Due to its powerful and versatile control toolbox

it is commonly used in the design and analysis of control systems.

65

Chapter 7. Implementation of Control 7.2. Development Stage (Tethered)

Simulink is a software package that comes with Matlab and is commonly used in

the construction of control systems, particularly those that contain non-linearities,

discontinuities or complex systems. It also has facilities to compile these models to

a variety of platforms, including the aforementioned dSPACE DS-1104 and HCS12

platforms.

7.1.3.2 dSPACE ControlDesk

ControlDesk is the software that comes with the DS-1104 platform. It interacts with

the Simulink control system running on the DS-1104 hardware to allow the monitoring of

control signals, such as controller outputs, and allows the modification of control variables,

such as controller gains, on the fly. When a USB joystick is attached to the host computer,

ControlDesk acts as an interface, forwarding any joystick commands to the DS-1104

platform.

ControlDesk combines all of these features with an easy to use Graphical User Interface

(GUI).

7.1.3.3 Metrowerks Codewarrior

Metrowerks Codewarrior is an Integrated Development Environment (IDE) for several

platforms including the Motorola HCS12 family of microcontrollers. It allows direct

programming of the MiniDRAGON+ development board in the C programming language.

7.2 Development Stage (Tethered)

The first stage of implementation was to operate the aircraft while tethered to a frame.

This would allow safe operation of the aircraft while tuning the controller.

7.2.1 Hardware Configuration

The basic control hardware configuration of the model is shown in Figure7.7.

66

7.2. Development Stage (Tethered) Chapter 7. Implementation of Control

Figure 7.7: Tethered Configuration Hardware Layout

Figure 7.8: Tethered Configuration

67


7.2.1.1 Control Platform

During tethered testing the control system was initially run on the dSPACE DS-1104

platform. A DS-1104 board is only capable of producing 4 PWM outputs. Since this

project required a minimum of 5 such outputs, one for each motor and one for each wing

arm servo motor, a second DS-1104 board was used in a master-slave configuration to

provide the additional PWM outputs. The two DS-1104 boards communicated with each

other via digital to analogue (D/A) and analogue to digital (A/D) ports. The PWM

signals were run along a BNC cable to the breakout board where they are terminated and

run along the main loom to the platform.

Problems arose with electrical noise from nearby equipment. The large length of the loom

made this problem significant. The group was able to use the serial port of the secondary

DS-1104 board and a PicoPic servo controller to minimise the noise interfering with the

PWM signals.

7.2.1.2 Power Supply

The three motors (two main and single rear) were powered from a 12V deep-cycle sealed

lead acid (SLA) battery as shown in Figure 7.9. For safety reasons, a 100A circuit

breaker/isolator was installed to allow the team to cut the power should anything go

wrong and to help prevent damage in the case of a short circuit. It also allows the

complete isolation of power from the high-power components, allowing the team to work

on the model in safety, without the fear the motors will start up unexpectedly. The servos

and the IMU were powered using a bench power supply which allowed the group to easily

monitor and control the maximum current.

7.2.1.3 Signal Routing and Distribution

The control signals were routed through a breakout board which was developed by Jarrett

et al. (2004). Since the power to the motors came from the battery in the control room,

large gauge wires needed to be added to last year’s loom. The only other addition was

two thermocouple extension cables for monitoring the temperature of the motors as this

was identified as a potential problem. Figure 7.10 shows the breakout board located

at the host end. The five PWM channels are on cables with BNC connectors. This is

convenient as one could easily connect a channel to a Cathode Ray Oscilloscope (CRO) to

troubleshoot the system. The IMU power and data connections are shown on the bottom

left of the picture.

68


Figure 7.9: Tethered Power Supply

Figure 7.10: Breakout Board

69


As mentioned previously, there was the problem of electrical noise. The group were able

to overcome this without modifying the cable loom. For untethered configuration the

group had decided on using the PicoPic serial servo motor controller, as it was expected

the serial connection would be less sensitive to noise. Since the signal is uni-directional,

a pin to BNC cable connecting the transmit and ground pins of the dSPACE serial port

to the breakout board. This is shown in Figure 7.11.

Figure 7.11: Modified Configuration

Figure 7.12 shows the PicoPic mounted on the aircraft. The serial connection is located

on the right of the picture and the five PWM connections are at the top of the device.

Figure 7.12: PicoPic Mounted to the Aircraft Frame

7.2.2 Software Configuration

While in its tethered configuration the model was ran open-loop, with proportional, PID

and State-Space control as described in Chapter 6. The results of this are discussed in

70


detail in Chapter 8.

7.2.2.1 Simulink

When implementing the control system through Simulink several specialized input/output

blocks were constructed to abstract the control system from the underlying hardware. The

abstracted Simulink model is shown in Figure 7.13.

Figure 7.13: Abstracted Simulink Model

The feedback block handles the serial communication protocol to the IMU, sending the

command byte and receiving the raw data from the IMU. This is then converted to

standard units, such as radians, and output from the block.

The output, or ‘VTOL’ block receives the output from the control system as a series of

control outputs as standardised units, for example motor angles in radians. This data is

scaled and offset to correspond with the appropriate raw output and sent to the digital to

analogue converters in order to send it to the slave DS-1104 board. For reasons of safety

a software emergency stop (or Estop) has been programmed into this block that latches

all outputs to zero in the event of an emergency. The workings of the ‘VTOL’ block are


7.2.2.2 ControlDesk

Different ControlDesk layouts were required for each of the controller types being run.

The open-loop layout provided direct access to the output signals, the PID controller

layout had control of the setpoints and access to the controller gains, while the State-

Space controller layout only provided access to the setpoints. Figure 7.15 shows the

71


Figure 7.14: VTOL Control Block

ControlDesk layout used during the tuning of the PID controller. It provides access to

all of the controller gains, the control output values, the input values provided by the

joystick and the IMU feedback.

Figure 7.15: ControlDesk Layout for the PID Controller

72

7.3. Semi-Tethered Configuration Chapter 7. Implementation of Control

7.3 Semi-Tethered Configuration

When the issue regarding the pivot not being located at the centre of mass was identified,

as discussed in Section 10.6, it was decided to test the aircraft while semi-tethered. The

aircraft was removed from the gimble, but still powered by the power sources discussed

in Section 7.2.1. The large power cables acted as an anchor, preventing the model from

lifting too high or travelling too far.

The only significant difference between this configuration and that outlined in Section

7.2 is the replacement of the serial connections with the free2move bluetooth dongles,

shown in Figure 7.16. These dongles act as a wireless serial link and have an approximate

outdoor range of 100m.

Figure 7.16: free2move Bluetooth RS-232 Transmitter / Receiver

In order to replace to two serial connections with a single wireless link the semi-

unidirectional nature of the IMU and the PicoPic were exploited. Information was send

to the PicoPic (located on the aircraft) as before, since this is already a unidirectional

link. The IMU was placed into ‘continuous’ mode, where it sends back information about

the aircraft’s state as quickly as it can, and hence was only used uni-directionally. This

data-stream from the IMU was buffered in the DS-1104 board and required analysis to

identify a packet, compute its checksum and store the previous correct result in the event

a checksum fails. This process was made difficult by the signals-based nature of Simulink.

73

Chapter 7. Implementation of Control 7.4. Fully Embedded Solution

7.4 Fully Embedded Solution

7.4.1 Embedded Hardware Design

The aircraft hardware layout in its fully untethered configuration is shown in Figure 7.17

Figure 7.17: Untethered Hardware Configuration

7.4.1.1 Control Platform

In the untethered configuration the control system was ported to the MiniDRAGON+

development board, as discussed further in Section 7.4.2. It received control setpoints

by measuring the pulse width of the PWM output from the RC transmitter/receiver

pair, shown in Figure 7.18. Feedback is received from the IMU via one of the serial

communications ports of the MiniDRAGON+.

Figure 7.18: RC Transmitter and Receiver

74

7.4. Fully Embedded Solution Chapter 7. Implementation of Control

It was decided to continue using the PicoPic to generate the RC PWM signals even

though the MiniDRAGON+ has the facilities to generate eight 8-bit PWM signals, or

four 16-bit PWM signals. This is because the PicoPic can generate a much higher

resolution output for the five required PWM outputs (expected to be eight when the

aircraft achieves conventional flight). The 8-bit PWMs generated by the MiniDRAGON+

can describe a maximum of 256 discrete levels over the entire period. Given the

usable pulse width is restricted to between 750µs and 2250µs as outlined in Section

7.1.1.1, as a best case scenario with fs = 200Hz, the number of usable outputs is

(2250 − 750) × 10−6 × 200 × 256 = 76.8. This was deemed too low compared with

the approximate 1500 usable output levels available when using the PicoPic (see Section

7.1.2.3).

7.4.1.2 Power Supply

Once fully untethered the main motors and the the control system were powered by

on-board Lithium Polymer (LiPo) batteries, as chosen in Section 4.3.4.

7.4.2 Embedded Software Design

After consultation with Dr. Frank Wornle it was decided that the embedded controller

would be programmed in C, using Metrowerks Codewarrior, as opposed to using Dr.

Wornle’s real-time embedded Simulink target. This decision was made because of the need

to use some of the hardware units on the microcontroller, as discussed later. Programming

in C also tends to be more efficient, flexible and reliable than using Simulink and the real-

time target.

A brief overview of the operation of the embedded code can be seen in Figure 7.19. The

following describes the basic operation of the program. Refer to Appendix C for the

embedded code.

7.4.2.1 Main Program

The main program consists of a loop that does nothing. The function of the main program

is to simply waste time until an interrupt occurs, at which time the program jumps to

one of the interrupt service routines.

75

Chapter 7. Implementation of Control 7.4. Fully Embedded Solution

Figure 7.19: Embedded Code Operation

7.4.2.2 Timed Interrupt

The timed interrupt is an interrupt that occurs at a fixed frequency, in this case exactly

40 Hz. The function of the timed interrupt is to ensure the control system runs at a

fixed rate as is required when running a discrete control system. As soon as the interrupt

occurs the control system is started.

7.4.2.3 Control System

The control system executes outside of the timed interrupt, so that other interrupts

associated with the other modules can still occur. Once the control system begins

execution it reads in the buffered data from the IMU on the first serial port (SCI0)

and requests the next set of data from the IMU. The control system then copies the

setpoint data from the PWM capture block, and for safety reasons tests the state of the

‘landing gear’ switch on the RC radio. If this switch is off or the radio itself is off the

control system is stopped from executing and all outputs set to zero, this is to prevent the

accidental starting up of the motors while someone is working on the aircraft. Before the

actual control system will execute properly this switch needs to be on for two seconds.

The controller has been ported to C from the state-space model. This was done by

collecting all the state-space components together into one large state-space controller

using the ‘connect’ command in Matlab, as discussed in Section 6.2.5. This connected

state-space controller was converted from the continuous ’s-plane’ to the discrete ‘z-

plane’ using Matlab’s ‘c2d’ command. Finally the ‘A’ matrix of the discrete state-space

controller was diagonalized using the ‘canon’ command in Matlab, which diagonalizes

the state space model reducing it to a simpler series of multiplications and additions which

are easily implemented in C.

76

7.4. Fully Embedded Solution Chapter 7. Implementation of Control

Once the control outputs are calculated they are placed in a buffer to be sent to the

PicoPic over the second serial port (SCI1).

7.4.2.4 PWM Capture

The PWM capture code makes use of the microcontroller’s Enhanced Capture Timer

(ECT) hardware unit to accurately measure the PWM signal output from the RC receiver

while using as little processor time as possible. The ECT captures both the time when

the PWM signal goes high and the time when it goes low. It then generates an interrupt

where the two times are compared to calculate the input pulse width. This pulse width

is scales to a value between zero and one representing the control setpoint.

The ECT has a total of eight channels, one (channel 7) is reserved for the timed interrupt

and another (channel 5) is connected to the speaker of the MiniDRAGON+ and thus does

not operate properly, leaving six channels able to capture the PWM signals.

7.4.2.5 IMU Communications

Upon the request of the control system the IMU Communications block sends the one-byte

request for the next set of data to the IMU. When each byte is returned from the IMU an

interrupt occurs and this byte is buffered. Once the entire data packet has been received

the raw data from the IMU is converted and scaled to standard units. The control system

requests this data once it starts executing.

7.4.2.6 PicoPic Communications

Once the control system has buffered the data for sending to the PicoPic, the PicoPic

communications module converts the data to the appropriate format for the PicoPic and

begins transmitting. Given the relatively long time required to send this data compared

with the processor’s speed this process is interrupt driven. When a byte has been sent

an interrupt occurs and the next byte in the buffer is sent. This significantly reduces the

communications overhead as compared to the ’busy-waiting’ method of communication.

77

Chapter 8

Testing and Tuning

8.1 Initial Open Loop Testing

The group initially tested the model connected rigidly to the gimble. This allowed the

group to verify the mechanical and systems design. It revealed the flaw in the integrity

of the wing arm/motor mount junction, discussed in detail in Section 10.3. A new motor

mount was designed and built to withstand greater loading conditions.

After strengthening and rebuilding, a thrust test was performed by placing a set of digital

scales under the whole assembly and measuring the reduction in force applied to the

scales. Using the 12V Sealed Lead Acid (SLA) battery, a 5 kg reduction in mass was

measured which corresponds to 49 N of lift. The maximum current and voltage drop were

measured using the Emeter, a device placed in series with the power supply to one of

the motors which records its voltage, current draw and speed. The Emeter is showed in

Figure 8.1. The maximum current draw of one of the primary motors was 33.3A under

maximum load, with a corresponding voltage of 11.3V. This results in a total power draw

of 375W each motor. This exercise was repeated when powered by the LiPo batteries

which yielded slightly over 30N, however this is dependant of the actual charge status of

the batteries.

If the motors were not adequately cooled there was the potential for damage. A

thermocouple was attached to the exterior of each motor which allowed the group to

monitor the surface temperature, as overheating was a concern. During normal operation

the surface temperature did not exceed 30◦. However, to ensure that the motors did not

heat up too much after running at full load, the motors were allowed to run at a lower

speed for some time before being shut off completely.

78

8.2. Closed Loop Testing Chapter 8. Testing and Tuning

8.2 Closed Loop Testing

It was initially planned to tune the controller while the aircraft was fixed to the gimble.

This would allow testing with a reduced risk of damage to components (particularly the

propellers) from a rough landing, as the consequences of the system going unstable would

be minimal.

The group attempted to tune a PID controller. Initially the gimble was locked so only

movement in yaw was possible. The aircraft was able to be controlled very effectively

in the yaw axis through simple proportional feedback. The gimble was then loosened to

allow the model to attempt a more realistic hover. The roll and pitch axes could not be

easily controlled. This was primarily due to the effect of being tethered to the gimble,

in particular the point of rotation being moved from the model’s centre of mass to the

ball-joint of the gimble. The layout of the fuselage had been designed for a centre of

gravity in front of the lift point of the wings. Moving the pivot point away from this

location rendered pitch uncontrollable, with roll dynamics also made uncontrollable as a

result. Other issues with the gimble are covered in more detail in Section 10.6.

The state space controller was also tested on the gimble. After some modification to the

control weighting matrix the state space controller showed stable behaviour in yaw but

encountered the same problems as the PID controller in pitch and roll. It was decided

not to attempt further control of the roll and pitch of the model whilst connected to the

gimble.

Figure 8.1: Emeter

79

Chapter 8. Testing and Tuning 8.3. Untethered Testing

8.3 Untethered Testing

The model was tested on the concrete outside the Holden Lab of the University of

Adelaide. This site is shown in Figure 8.2. This figure also shows the landing gear

that was assembled in an attempt to keep all moving parts away from the ground. The

power cables constrained the movement of the rig, acting as an anchor. A large mass was

placed on top of the cable to fix is to the ground. This test was short lived as one of the

propellers hit the ground which caused minor damage to one its tip. It was expected that

the pitch PID loop would compensate for the pitching forward motion associated with

the thrust form the front propellers. However, this proved untrue and a small amount

of forwards pitch immediately after takeoff caused the plane to land in such a way that

the propeller into contact with the concrete. Further tests were postponed until a more

suitable testground was found. The damaged propeller was balanced by smoothing the

edge of the damaged tip and reducing the length of the undamaged tip to match. This

resulted in uneven thrust generation between the two propellers. A small amount of gain

(˜2%) was added to the control signal of the motor driving the damaged propeller so as

to match the thrust output between the two motors.

Figure 8.2: Untethered Testing Outside the Holden Lab

The next testing session took place on grass, as shown in Figure 8.3, with the aim of

limiting hardware damage due to unstable landings. The power to the tail fan was made

proportional to the power supplied to the front motors such that the plane would be more

stable in pitch during hover. The maximum power offset was limited to the point required

for stable pitch, in the hope that the pitch PID loop would compensate after this level

is reached. The basic PID controller was tested before attempting the more complicated

80

8.3. Untethered Testing Chapter 8. Testing and Tuning

state space controller. The controller gains for roll and pitch were tuned incrementally

after each test run. While lift-off was achieved a number of times, the aircraft could not

achieve a stable hover. After a few runs the lift-off characteristics were improving with

less severe landings.

Figure 8.3: Untethered Testing on Grass

The group did not have time to adequately tune the controller due to a mechanical failure.

As shown in Figure 8.4, the wing arm rotated 180◦ from its original position and struck the

ground. This failure was caused by the plastic servo motor horns stripping and resulted in

one of the propellers striking the ground whilst still being powered. This impact resulted

in a shear failure of the output shaft of the planetary gearbox. This shaft was repaired

by Steve Kloeden of the mechanical workshop in time to display the aircraft at the Level

IV Project Exhibition, however further testing was not possible due to time constraints.

81

Chapter 8. Testing and Tuning 8.3. Untethered Testing

Figure 8.4: Mechanical Failure

82

Chapter 9

Constraint Analysis

9.1 Cost

Final product price is a major constraint, as a model that is too expensive will have

reduced commercial appeal. A project such as this requires the use of several expensive

components, which are outlined in Table 9.1. Some of these expensive components, such

as the Bluetooth Dongles and the IMU will not be used in the final solution but are

required for prototyping.

The major expense of the project was labour, namely the students and the workshop staff.

Whilst the labour costs for the workshop staff were unavailable, the estimated student

labour throughout the project is shown in Table 9.2. This was estimated using the hours

each student worked with a standard salary and including estimated direct and indirect

costs.

9.2 Weight

As with any aircraft weight is a major constraint. VTOL aircraft are particularly sensitive

to weight as the powerplant must produce enough thrust to overcome this weight. The

weight distribution of the project model are shown in Table 9.3.

The discrepancy between the initial estimate of 2.5 kgand that listed in Table 9.3 of 4.0 kg

is discussed in Section 10.7.

83

Chapter 9. Constraint Analysis 9.2. Weight

Table 9.1: Component Expenses

Item Quantity Item Cost Total

Plettenberg 220/30/A3 P4 5:1 Brushless Motor 2 $444.98 $889.9680 Amp Hyperion Brushless ESC 2 $168.00 $336.00

Tanic-3S2P 2450 mAh 11.1 V LiPo 8 $118.00 $944.007.4V 1800mAh LiPo 1 $40.80 $40.80

LiPo Charger 1 $200.00 $200.00Deep Cycle 12 Volt Lead Acid Battery 1 $100.00 $100.00

Lead-Acid Battery Charger 1 $75.00 $75.00MiniDRAGON+ plus comm upgrade 1 $174.00 $174.00

PicoPic plus upgrades 1 $87.60 $87.60Free2Move RS-232 Bluetooth Dongles 2 $182.50 $365.00

3DM-GX1 IMU 1 $2500.00 $2500.00Wemotec Ducted MicroFan 1 $30.00 $30.00

Hyperion 20Amp ESC 1 $87.40 $87.40Himax 2025 4100 Brushless Motor 1 $69.95 $69.95

Hyperion e-Meter 1 $138.00 $138.00APC 20 x 10” Propeller Pusher Tractor Pair 1 $115.00 $115.00

Frame Materials + Construction 1 $300.00 $300.00Cabling 1 $100.00 $100.00

Total (incl GST) $6552.71

Table 9.2: Estimated Student Labour Costs

Student Hours Salary Direct Costs Indirect Costs Total

Zebb Prime 567.5 $14,551 $4,365 $18,917 $37,833Jesse Sherwood 292 $7,487 $2,246 $9,733 $19,467Michael Smith 407 $10,436 $3,131 $13,567 $27,133Allan Stabile 400.5 $10,269 $3,081 $13,350 $26,700

Total 1667 $42,744 $12,823 $55,567 $111,133

84

9.2. Weight Chapter 9. Constraint Analysis

Table 9.3: Weight Budget

Item Quantity Weight (g) Total (g)

FrameAluminium Frame 1 400 400

Rear Arm 1 110 110Wing Arms 2 110 220

Wing Arm Bearings 2 60 120Motor Mounts 2 100 200

Assorted Screws 20 3 60Sensors

3DM-GX1 IMU 1 75 75Actuators

NES-579 JR Servo with mount 4 48 192E381 Servo with mount 3 29 87

ControllersMiniDRAGON+ 1 50 50

PicoPic 1 14 14Propulsion

Motors - Plettenberg 220/30/A3 P4 5:1 2 225 450Propellers 2 190 380

Propeller Adaptor 2 40 80ESC Hyperion 80 A Brushless 2 45 90

WeMoTec Ducted Fan 1 30 30Himax 2025 4100 Brushless Motor 1 61 61

20 Amp Hyperion ESC 1 21 21Batteries

Tanic-3S2P 2450 mAh 11.1 V LiPo 5 172 8607.4 V 1800mAh LiPo 1 82 82

MiscellaneousCabling∗ 1 300 300

Landing Gear 1 30 30Bluetooth Dongle 1 50 50

Total 3952

∗Estimated

85

Chapter 9. Constraint Analysis 9.3. Power Budget

9.3 Power Budget

The amount of power that the batteries can provide is a constraint. Given the specification

of a minimum of 3 minutes flight time it is important that the batteries are able to provide

full power to the motors for at least this period.

The current prototype contains four separate power circuits. The control circuit contains

all of the control components and is powered by a 7.4V 1800 mAh LiPo, as shown in Table

9.4. Each of the main motors are driven by two Tanic 2400mAh 11.1V LiPo batteries,

while the rear motor runs from its own Tanic TP730-2S. The power budgets for both of

these circuits are shown in Table 9.5.

Table 9.4: Control Circuit Power Budget

Component Current Draw (mA) Quantity Total

Servo Motors 130 6 780PicoPic 14 1 14

MiniDRAGON+ 85 1 853DM-GX1 IMU 65 1 65

Bluetooth RS-232 Dongle 70 1 70TOTAL (mA) 1014

Battery Capacity (mAh) Surge Current (A) Discharge Time (min)7.4 V 1800 mAh LiPo 1800 12 106.5

Table 9.5: Motor Power Budgets

Motor CurrentDraw (A)

Battery BatteryCapacity (mAh)

BatterySurge(A)

DischargeTime (min)

Plettenberg @ 100% 31 2xTanic LiPo 4900 58 8.9Plettenberg @ 75% 25 2xTanic LiPo 4900 58 11.76Himax @ 100% 10 Tanic LiPo 2450 24 14.7

86

Chapter 10

Issues

10.1 IMU

There were a number of issues relating to the IMU. Initially the 3DM-G, an older variant

of the 3DM-GX1 described in Section 4.4.1, was to be used. The communications protocol

provided with this unit was in fact for the newer 3DM-GX1, and hence described several

modes of operation which were not available on the older 3DM-G. It was desired to use

one of these modes of operation for the project, and as such a lot of time was wasted

trying to get these modes to work which were not supported by the 3DM-G. The correct

manual was eventually sourced from the manufacturer, and the 3DM-G exchanged with

a 3DM-GX1 another project group who did not need these advanced modes were using.

One issue relating to the IMU that affected several groups, including Jarrett et al. (2004)

was the poor handling of two’s-complement numbers by Matlab and Simulink. Two’s

complement is the most popular method used in computer science to represent both

positive and negative values. Matlab and Simulink treat the pure binary data, such as

that read back from the IMU, as unsigned integers, with no simple conversion to two’s

complement representation. The conversion had to be manually programmed in order to

obtain the correct values.

10.2 Sourcing of Equipment

The Plettenberg motors together with the two associated ESCs, the Himax motor, LiPo

batteries and charger were originally sourced from a Canadian distributor. The specialised

nature of the Plettenberg motors required purchasing by the distributor from Plettenberg

87

Chapter 10. Issues 10.3. Mechanical Failure

in Germany prior to delivery. However, the deadline specified for delivery was exceeded.

After unsuccessful attempts to contact the distributor, a decision was made to procure

the Plettenberg motors direct from the manufacturer in Germany and the remainder of

the goods from a local distributor. Although this further delayed the acquisition date, it

was a necessary decision based on the lack of communication and unknown arrival date of

goods from the Canadian distributor. As a result of this sourcing issue, the commissioning

of the model was delayed by approximately three weeks.

10.3 Mechanical Failure

10.3.1 Wing Arm Motor Mount

During the initial stages of design testing, a failure occurred at the junction of the motor

mount and the wing arm. This occurred in the course of preliminary motor quantitative

thrust analysis and was believed to be a direct result of inadequate design accelerated by

propeller imbalance.

Initially the motor mount was fixed to the aluminium tubing of the wing by a 3 mm bolt

through the tube, 10mm from the end of the shaft. The size of the tubing was designed to

withstand loading associated with torquing from the servo motors and transverse bending

from lift and the weight of the assembly, in which case the design would have been

sufficient. However, the moment generated by the small distance between the thrust

point and the motor mount was not considered, and coupled with the eccentric force

generated by the propeller imbalance caused the bolt tear-out shown in Figure 10.1.

The slight imbalance in the pusher propeller was rectified through a static balancing

process. The thickness of the aluminium tubing used for the wing arm was also increased

to 2mm. This had the complimentary effect of reducing transverse flex of the wing arms,

a previously noticed concern. Additionally, the distance of the bolt-hole from the shaft

end was increased to 30mm and was reinforced with a solid aluminium plug. The result

of these changes was a more rigid, durable and strengthened junction point between the

wing arm and motor mount, reducing the risk of failure.

10.3.2 Gearbox Shaft

During untethered testing several crashes stripped the plastic gears on the servo motor

horn. This caused the wing arm to slip with the motor at high power, sending the propeller

88

10.4. Wing Arm Bearings Chapter 10. Issues

Figure 10.1: Failure of shaft at Wing/Motor Mount junction

into the ground at full-speed. This resulted in a torsional shear failure of the gearbox

output shaft.

Mr. Steve Kloeden from the workshop managed to repair the broken part in time for

the exhibition, allowing us to demonstrate the propulsion system. However Mr. Kloeden

stressed that this is a short-term solution, and advised a new gearbox or motor/gearbox

assembly be purchased. The motor itself is undamaged and it is envisaged that it will be

used to power a ducted fan for another of Dr. Ben Cazzolato’s final year projects.

10.4 Wing Arm Bearings

The original bearings used to facilitate rotation of the wing arms were teflon coated

dry-rubbing copper bearings embedded into opposite ends of a nylon block. With no

transverse loading these bearings operated at a satisfactory level. However, transverse

forces experienced by shaft during operation resulted in an unsatisfactory level of friction

between the shaft and bearings. Even with additional lubrication, the wing arms were not

able to rotate with desired freedom, eventually resulting in stripping of the servo motor

gears.

The dry rubbing bearings were subsequently replaced with needle roller bearings of the

same inner diameter and similar length. This combined with the purchasing of the more

robust servo motors described in Section 4.5.1 resulted in satisfactory wing-arm operation.

89

Chapter 10. Issues 10.5. Electrical Noise

10.5 Electrical Noise

Originally the PWM signals were generated by the two dSPACE DS-1104 boards and

transmitted to the aircraft through the entire length of the wiring loom. During

transmission the PWM signals were picking up electrical noise which caused erratic

behaviour of the servo motors and electronic speed controllers. This noise problem was

identified by measuring the PWM signal at the aircraft side of the loom using a Cathode

Ray Oscilloscope (CRO).

The PWM signals were replaced with a serial connection to the PicoPic servo controller

which was located on the aircraft. The serial connection proved to be more robust

against noise, eliminating the erratic behaviour of the servo motors and electronic speed

controllers.

10.6 Unmodelled Gimble Dynamics

Tuning of the control system was initially attempted while the model was attached to

the gimble. This had the effect of introducing unmodelled dynamics into the system.

The gimble pivot was located at a distance from the centre of mass of the model. This

introduced dynamics analogous to the ‘inverted pendulum’ problem, in that the aircraft

was easiest to control when in it was approximately horizontal, but became harder to

control as the angle from the horizontal increased. Furthermore the restraint on the

maximum angle of the gimble restricted movement and introduced a spring effect such

that the model could bounce when it hit the extremities of its movement.

To counter this problem, smaller IMU cradle arms where fabricated so the position of

the gimble could be brought closer to the centre of mass of the aircraft. If the centre of

mass is brought to the position of the pivot, or even slightly below it the dynamics of the

aircraft would better represent the true untethered dynamics.

10.7 Weight of Model

During the construction phase various elements of the design were altered. A consequence

of these alterations was the mass of the model to increased significantly over initial

estimates. Increasing the size of the motors and propellers relative to the initial design

subsequently required an increase in battery size and resulted in substantial weight gain.

The redesign of the wing-arms after failure also increased the mass of the model, with

90

10.7. Weight of Model Chapter 10. Issues

thicker aluminium tubing and plate used to strengthen the motor mounts. The mass

of electric cabling was also higher than expected. The final measured mass was 4.4kg

including batteries and training undercarriage. The model was able to attain sufficient

thrust to leave the ground when running on a sealed lead acid battery. However testing

on LiPo batteries has shown that it there may not be enough static thrust generated to

achieve lift-off.

91

Chapter 11

Discussion and Future Work

11.1 Summary of achievements

Whilst a stable hover was not achieved during the course of the project, there were still

a number of significant achievements throughout the project.

11.1.1 Choice of platform

The first major task in this project was the choice of which platform to base our design on.

A number of sources were discussed in the literature review in Chapter 2 and the reasons

against choosing the F-35 Joint Strike Fighter were detailed in Section 3.1. For the reasons

outlined in Section 2.2.2, the V-22 Osprey was noted to have some promising features

and subsequently was analysed in more detail. This change in platform necessitated the

abandoning of much of the work achieved by Jarrett et al. (2004).

11.1.2 Mechanical design

To develop a realistic working model of the system, a full solid model of the frame and

components was constructed in SolidEdge. The detailed frame drawings can be found in

Appendix A. The biggest constraint was keeping the weight down enough to ensure that

the thrust to weight ratio exceeded the chosen minimum of 1.5:1. Although the mechanical

design of the current system did not have the same vibration issues that Jarrett et al.

(2004) had to consider, the frame still needed to be structurally sound.

92

11.1. Summary of achievements Chapter 11. Discussion and Future Work

11.1.3 Component Selection and Procurement

Through the review of the mechanical system requirements as discussed in Section 4.3, the

components required to produce thrust, namely the batteries, motors and propellers, were

chosen and subsequently purchased. These components, whilst expensive, have enormous

potential for producing thrust. Furthermore these components have a high degree of

reuseability due to their quality, and thus will be used in future projects.

11.1.4 Mechanical Construction

The frame design was manufactured in the workshop and was assembled with all the

chosen components. The frame displayed a high degree of robustness and controllability,

provided the control system were sufficiently tuned. As such makes a solid control platform

for future development.

11.1.5 Mathematical Modelling

This project intended to implement a state space controller which required an accurate

model of the system dynamics. In Chapter 5 the mathematical model of the aircraft

whilst in hover was derived using force and moment balancing, motor/propeller response

properties and differential equations of motion. In order to design a controller the non-

linear terms were approximated as linear about their operation points.

11.1.6 Controller Design and Tuning

In Chapter 6 both a PID and a state-space controller were designed. The state-

space controller was constructed using the derived mathematical model. Whilst it was

envisioned the PID controller would be tuned experimentally this did not occur due to

the events discussed in Chapter 8, where mechanical failure hampered controller tuning.

The state-space controller, on the other hand, was tuned using optimal control (LQR).

11.1.7 Control Implementation

Significant achievements were accomplished in the implementation of the control system,

even though the control system itself was not sufficiently tuned.

93

Chapter 11. Discussion and Future Work 11.2. Future Tasks

During the control development, while the controller was run from the dSPACE DS-

1104 platform, several issues relating to the Inertial Measurement Unit (IMU) were

discovered for the first time in a final year project, despite its previous use, as discussed

in Section 10.1. Additionally through the use the PicoPic servo motor controller, a much

less expensive component than a dSPACE DS-1104 platform, and insight into to the

communications protocols used, the control system was implemented on a single DS-

1104 board. This frees an expensive DS-1104 board for use in other projects or teaching

practicals throughout the university year.

Given the requirement of an embedded controller and the use of standard RC equipment

for control, extensive work was undertaken in the integration of these components.

The MiniDRAGON+ development board was programmed and tested for reliable

operation and communication with all peripheral equipment, as discussed in Section 7.4.

Furthermore the state space controller was ported to the MiniDRAGON+ development

board using an efficient method that is quick and easy to reproduce if the controller

changes. It was tested and proven that the MiniDRAGON+ development board had

sufficient processing power to execute this state space controller, including such features

as a reduced-order observer.

11.2 Future Tasks

11.2.1 Stable Hover

Given the large amount of work that has gone into this project it is envisioned that the

completion of all the project goals will only require minimal work. As such all of the

project members have expressed an interest in continuing the project past the official

completion date in order to get the aircraft to hover in a stable manner. Through the

modification of the gimble to eliminate the issue of the unmodelled dynamics discussed

in Section 10.6, it is expected that a suitable controller could be quickly developed. The

aircraft would then be tested untethered, in a similar method to that described in Section

8.3.

11.2.2 Real-Time Embedded Gain Updating

It is proposed to implement communications from the MiniDRAGON+ to the IMU and

PicoPic using a single serial communications port in a similar fashion to that implemented

on the dSPACE DS-1104 control board. This would free up the second port which could

94

11.2. Future Tasks Chapter 11. Discussion and Future Work

then be used to implement a protocol to update the controller gains in real-time, possibly

using the bluetooth dongles, in a similar fashion to that used by ControlDesk.

11.2.3 System Identification

While the mathematical model developed in Chapter 5 is quite detailed, many

approximations were required to linearise the model. Due to these approximations some

states of the model may be uncontrollable in practice. Different methods of linearising

the equations exist but may have similar issues. Should this be the case with the

model presented in Chapter 5, the Matlab System Identification toolkit facilitates the

evaluation of linear models of dynamic systems from input-output data. Designing the

controller using such a numerical system model is potentially more accurate. This will

allow a wider choice of control system as some techniques require an accurate model.

11.2.4 Reduced Precision Sensors

As one of the main objectives is to build a system which is affordable by model aircraft

enthusiasts, using a $2500 IMU is not practical. It is envisioned that more economically

viable rate gyroscopes will be used. Rate gyroscopes are prone to DC offset since they

must be integrated to determine the position. The effect of less precise information can

be simulated on the IMU by not utilising some of its advanced features, which will allow

the tuning of the existing control system to a point where it is suitable for use with rate

gyroscopes and hence more viable for the commercial market.

Rate gyroscopes output the angular velocity of the model, thus for control the signal must

be numerically integrated to obtain a value for angular position. Numerical integration

of discrete signals is prone to offset errors, thus it is likely the model will drift during

hover. These bias errors can be overcome by an operator using trim pots (trimming

potentiometers) to correct the signal, or the addition of a cheap horizon sensor.

11.2.5 Model Body

Eventually a V-22 Osprey body will be constructed around the frame. Using balsa wood

ribbing and depron skin the body can be made very light. The frame has been designed to

fit inside a 1:15 model of the V-22 Osprey with minor modification. At this stage serious

consideration must be put into the size, shape and actuation of the traditional control

surfaces. For the purposes of “realism” a simple body was manufactured from cardboard

95

Chapter 11. Discussion and Future Work 11.2. Future Tasks

and shaped clear plastic. This covering enables a view of the inner model workings, whilst

giving a realistic impression of the final design. The drawback associated with this design

is that it is purely aesthetic and cannot be used for active conditional control surfaces.

11.2.6 Conventional Flight

As a future project the model could be adapted for conventional flight. This will involve

the construction of traditional flight and control surfaces, such as wings, ailerons, rudders

and elevators and the adaption of the control system to allow a successful transition to

conventional flight. This has been the major challenge to enthusiasts who have attempted

to build model VTOL aircraft in the past.

96

References

Airfield Models (2005).

http://www.airfieldmodels.com/information source/model aircraft engines/propellers.html.

Accessed 10/10/05.

Bell Agusta (2005). http://www.bellagusta.com/pdf/ba609 2004.pdf. Accessed 19/5/05.

Boeing (2005). http://www.boeing.com/rotorcraft/military/v22. Accessed 10/5/05.

Cazzolato, B. (2005a). 3 Degree of Freedom Hover Tutorial. The University of Adelaide.

Cazzolato, B. (2005b). Advanced Automatic Control Lecture Notes. The University of

Adelaide, Adelaide.

Cazzolato, B. (2005c). Automatic Control II Lecture Notes. The University of Adelaide,

Adelaide.

Chapman, L. (2005). http://www.geocities.com/v22chap. Accessed 15/3/05.

Dorf, R. and Bishop, R. (2001). Modern Control Systems. Prentice Hall, New Jersey,

9th edition.

Franklin, J. A. (2002). Dynamics, Control and Flying Qualities of V/STOL Aircraft.

AIAA.

Hamel, R. L. R. O. J., Tarek; Mahony (2002). Dynamic modelling and configuration

stabilization for an x4-flyer. IFAC 15th Triennial World Congress, Barcelona, Spain.

Hansen, C. and Snyder, S. D. (1996). Active Control of Noise and Vibration. Spon Press.

HazelProp (2005). http://www.hartzellprop.com/engineering/engineering faqs.htm.

Accessed 19/9/05.

ICARE (2005). Personal correspondence. 28/7/05.

Jarrett, M., Ng, R., and Teske, T. (2004). Radio Controlled Vertical Take-Off and

Landing Aircraft. The University of Adelaide, Adelaide.

97

References References

JSF (2005). http://www.jsf.mil/index.htm. Accessed 19/5/05.

McCormick, B. W. J. (1995). Aerodynamics, Aeronautics and Flight Mechanics.

Academic Press.

Mettler, B. (2003). Identification Modelling and Characteristics of Minature Rotorcraft.

Kluwer Academic Publishers.

Modelflight (2005). http://www.modelflight.com.au/jr propo rc control servos.htm.

Accessed 1/5/05.

Newman, T. (2005). Personal correspondence. 16/5/05.

Picobytes inc. (2003). PicoPIC User and Technical Manual.

Rogers, M. (1989). VTOL Military Aircraft. Haynes.

RS Automation (2005). http://www.rsaustralia.com. Accessed 1/6/05.

Schubeler (2005). http://www.schuebeler-jets.de. Accessed 16/3/05.

TiltRotorMech (2005). http://www.tiltrotormech.com/v22 models.htm. Accessesd

10/5/05.

WeMoTec (2005). http://www.wemotec.com/index e.html. Accessed 1/5/05.

Wikipedia (2005). http://en.wikipedia.org. Accessed 25/9/05.

Wilkins, P. S. (2001). The potential use of military tiltrotor aircraft for aeromedical

evacuation. ADF Health, 1:58 – 63.

Xiaofei-Wu, Ignatov, R., Muenst, G., Imaev, A., and Zhu, J.-J. (2002). A nonlinear

flight controller design for a ufo by trajectory linearization method, part 1, modelling.

Proceedings of the Thirty Fourth Southeastern Symposium on System Theory Cat,

No.02EX540.:97–102.

98

Appendix A

CAD Drawings

Drawing Number Title

VTOL-05-001 VTOL-05 Frame

VTOL-05-002 Main Chassis

VTOL-05-003 Main Chassis Parts

VTOL-05-004 Assembled Wing Arm

VTOL-05-005 Assembled Wing Arm Parts

VTOL-05-006 IMU Cradle

VTOL-05-007 IMU Cradle Parts

VTOL-05-008 Motor Mount and Propeller Adapter

Please note all drawings were intended for printing to A3, hence some detail may be lost

when printed to A4.

99

DRAWN

CHECKEDENG APPRMGR APPR

ALL DIMENSIONS IN MILLIMETERSUNLESS OTHERWISE SPECIFIED

a1078621 27/10/05

TITLE SIZEA3

DWG NO REV

FILE NAME: VTOL-05-001.dft SCALE: WEIGHT: SHEET 1 OF 2

REVISION HISTORY

REV DESCRIPTION DATE APPROVED CONTACT

VTOL-05 Frame

[email protected]

VTOL-05-001 1

ALL TOLERANCES +/- 0.5MM OR +/- 1°UNLESS OTHERWISE SPECIFIED

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


VTOL-05 Frame

[email protected]

VTOL-05-001 1


115426094

6022

030

042

0

945

31

11 2

2

Item Number DocumentNumber

Title Quantity

1 VTOL-05-002 Main Chassis 1

2 VTOL-05-004 Assembled Wing Arm 2

3 VTOL-05-006 IMU Cradle 1

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV

FILE NAME: VTOL-05-002.dft SCALE:� 1:5 WEIGHT: 279g+welds SHEET 1 OF 1

REVISION HISTORY


Main Chassis

[email protected]

VTOL-05-002 1


265

420

106.5

A

DETAIL A

B

DETAIL B

ASSEMBLY NOTE:PLEASE WELD ALL COMPONENTS AS APPROPRIATE

(Left)

7

8

13

1211

10

6

23

5

4

1

9


Title Quantity

1 VTOL-05-003 Rear Servo Mount (for elevatorsand rudder)

1

2 VTOL-05-003 Main Frame Front Strut 1

3 VTOL-05-003 Main Frame Left Strut 1

4 VTOL-05-003 Main Frame - Rear CantileverArm

1

5 VTOL-05-003 Main Frame Right Strut 1

6 VTOL-05-003 Main Frame Back Strut 1

7 VTOL-05-003 Aileron Servo Mount 1

8 VTOL-05-003 Rear Ducted Fan Mount 1

9 VTOL-05-017 Connecting Bracket 1

10 VTOL-05-003 Connecting Bracket 1

11 VTOL-05-003 Arm holder 2

12 VTOL-05-003 Wing Servo Bracket (Right) 1

13 VTOL-05-003 Wing Servo Bracket 1

Flatten tube to accept rear fan mount

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV

FILE NAME: VTOL-05-003.dft SCALE: - WEIGHT: - SHEET 1 OF 5

REVISION HISTORY


Main Chassis Parts

[email protected]

VTOL-05-003 1


Jesse Sherwood

3

47

100

37

7.514

.5

3

REAR SERVO MOUNT (FOR RUDDER AND ELEVATOR CONTROL)QUANTITY: 1SCALE: 1.5:1

MATERIAL: 3MM ALUMINIUM

148.5

4.5

O4.5

O 3.5

O 3.5

36.5

246.5

173.5

420

20MAIN FRAME - LEFT STRUT

QUANTITY: 1 SCALE: 1:2MATERIAL: 20x12x1.5 UNEQUAL ANGLE ALUMINIUM

45°

1213

1.5 THICK

8x M3

13.5

23

O 34x

19.5

2.5

33.5

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


Main Chassis Parts

[email protected]

VTOL-05-003 1


Jesse Sherwood

173.5

383.5

36.5

420

O3.5

O3.5

45°

1320

148.

5

4.512

1.5 THICK

MAIN FRAME - RIGHT STRUTQUANTITY: 1 SCALE: 1:2

MATERIAL: 20x12x1.5 UNEQUAL ANGLE ALUMINIUM

94

45°

20

12

1.5

O4.5

4747

4.5

MAIN FRAME - FRONT STRUTQUANTITY: 1SCALE: 1:1


94 1042

42

20

12

1.5

45°

MAIN FRAME - REAR STRUTQUANTITY: 1SCALE: 1:1


DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


Main Chassis Parts

[email protected]

VTOL-05-003 1


Jesse Sherwood

SERVO ARM HOLDERQUANTITY: 1SCALE: 1:2

MATERIAL: 3MM ALUMINIUMNOTES: TOP ARM BASE SUPPORTED BY BEARINGS AND NOT

ATTACHED TO LOWER PIECES

47

260

30

55

555

PART 3ARM HOLDER BASE

QUANTITY: 2SCALE: 1:2

MATERIAL: 3MM ALUMINIUMNOTES: ONE FOR THE TOP AND ONE

FOR THE BOTTOM AS SHOWN

60405

35

3

10.5

30.5

O 3.54x O 4.52x

PART 1LEFT SERVO BRACKET

QUANTITY: 1SCALE 1:1

MATERIAL: 3MM ALUMINIUMNOTES: RIGHT BRACET DIMENSION SAME

PART 2RIGHT SERVO BRACKET

QUANTITY: 1SCALE 2:1

MATERIAL: 3MM ALUMINIUMNOTES: DIMESIONS THE SAME AS LEFTBRACKET, JUST MIRRORED (SEE LEFT)

1

2

3

7.5

12.5

22.5

10

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


Main Chassis Parts

[email protected]

VTOL-05-003 1


Jesse Sherwood

R 26INTERNAL10

REAR DUCTED FAN MOUNTQUANTITY: 1SCALE: 1:1

MATERIAL: ALUMINIUMNOTES: ROUND CLAMP SECTION TO BE MADE FROM ROLLED 2MM

ALUMINIUM STRIPPING

15

HOLE THROUGH BOTHTO ACT AS A CLAMP

TOP BEARING BASEQUANTITY: 1SCALE: 1:2


3

260

30

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


Main Chassis Parts

[email protected]

VTOL-05-003 1


Jesse Sherwood

460

O10

OD

O7.6

ID

REAR CANTILEVER ARMQUANTITY: 1SCALE: 1:5

MATERIAL: STANDARD OD 10MM ALUMINIUM TUBE

3

47

5 37 5

94

30 38.5

17

5

4xM3

AILERON SERVO MOUNTQUANTITY: 1SCALE: 1:1


7

REAR SERVO CONNECTING BRACKETQUANTITY: 1SCALE 2:1

MATERIAL: ALUMINIUM

25

12

305

520

3.5

R 5

R 6

1

12

REAR ARM CONNECTING BRACKETQUANTITY: 1SCALE 2:1

MATERIAL: ALUMINUM

25

12 3

O3

4X

O 32X

5

10

1

12

R5

R 6

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV

FILE NAME: VTOL-05-004.dft SCALE: 1:2 WEIGHT: 83g+welds SHEET 1 OF 1

REVISION HISTORY


Assembled Wing Arm

[email protected]

VTOL-05-004 1


A

DETAIL A

67

3 4 2

5

1


Title Quantity

1 VTOL-05-005 Wing Arm 1

2 VTOL-05-005 Wing Arm - Motor Mount 1

3 VTOL-05-005 Collar and Servo Hub 1

4 VTOL-05-005 Wing Arm Collar 1

5 VTOL-05-005 Arm Plug 1

6 VTOL-05-005 Acrylic Block 1

7 ------------- ID16x16 Roller Bearing 2

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


Assembled Wing Arm Parts

[email protected]

VTOL-05-005 1


475

O16

OD

O12

ID

WING ARMQUANTITY: 2SCALE: 1:3

MATERIAL: STANDARD OD 16MM ALUMINIUM TUBENOTES: 1 FOR EACH ASSEMBLED WING ARM

O 30

O 20

O 16.25 +0.250

4x M2.5

123

90°

M2 FOR GRUB SCREWNOTE: 45v OFFSET FROM OTHER HOLES

103

ARM COLLAR AND SERVO HUBQUANTITY: 2SCALE: 2:1

MATERIAL: ALUMINIUMNOTES: 1 FOR EACH ASSEMBLED WING ARM

5

O22

O16.25 +0.250

WING ARM WASHERQUANTITY: 2SCALE: 3:1

MATERIAL: ALUMINIUMNOTES: 1 FOR EACH ASSEMBLED WING ARM

5

45°

M2

2.5

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


Assembled Wing Arm Parts

[email protected]

VTOL-05-005 1


ACRYLIC ARM BEARING BLOCKQUANTITY: 2SCALE: 1:1

MATERIAL: ACRYLICNOTES: 1 FOR EACH WING ARM

RECESSES MACHINED TO FIT STANDARDID16x16 ROLLER BEARINGS

35

30

O 20

O 22

5 55

5

16 28 16

60

1010

4xM3

O26

O 16.25

45°

10.5

2.5 4.5

4xM3

10

WING ARM MOTOR MOUNTQUANTITY: 2SCALE: 2:1

MATERIAL: ALUMINIUMNOTES: 1 FOR EACH WING ARM

O12

O26

1030

40

10.5

2.5

4xO3

WING ARM PLUGQUANTITY: 2SCALE: 2:1

MATERIAL: ALUMINIUMNOTES: 1 FOR EACH WING ARM

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV

FILE NAME: VTOL-05-006.dft SCALE: 1:2 WEIGHT: 126g+welds SHEET 1 OF 1

REVISION HISTORY


IMU Cradle

[email protected]

VTOL-05-006 1


BOTTOM ONLY

BOTTOM ONLY

AS APPROPRIATE

AS APPROPRIATE

AS APPROPRIATE

AS APPROPRIATE

240

9476

.5

56.5

NOTES:ALL PARTS EXCEPT GIMBLE EXTENDER TO BE WELDED ON AS APPROPRIATE/SHOWN

5

1

3

2

4


Title Quantity

1 VTOL-05-007 IMU Cradle Strut - Back 1

2 VTOL-05-007 IMU Cradle - Right Strut 1

3 VTOL-05-007 IMU Cradle - Left Strut 1

4 VTOL-05-007 IMU Cradle upright 4

5 VTOL-05-007 Gimble Extender 1

DRAWN



Jesse Sherwood 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


IMU Cradle Parts

[email protected]

VTOL-05-007 1


45°

4794

O6.5

2012

1.5

IMU CRADLE - REAR STRUTQUANTITY: 1SCALE: 1:1


240

45°

3215

6

20

12

1.5

IMU CRADLE - LEFT STRUTQUANTITY: 1SCALE: 1:2


20

12

1.5

240

3215

6

8.25

5.5

45°

8.25

5.5

IMU CRADLE - RIGHT STRUTQUANTITY: 1SCALE: 1:2


DRAWN



Jesse Sherwood 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


IMU Cradle Parts

[email protected]

VTOL-05-007 1


O10

O7.6

75

IMU CRADLE - UPRIGHTQUANTITY: 4SCALE: 2:1

MATERIAL: STANDARD OD 10MM ALUMINIUM TUBE

O10

1050

10

M6

M6

GIMBLE EXTENDERQUANTITY: 1SCALE: 2:1

MATERIAL: STEELNOTES: CONFIRM BOTTOM THREAD SIZE BEFORE

SUMBISSION

GIMBLE-IMU MOUNTQUANTITY: 1SCALE 1:1

MATERIAL: 3mm ALUMINIUMNOTES: DISTANCE BETWEEN HOLES IS IMPORTANT

76

O 4.52x

25

O6.5

94

120°

Approx

25Approx

36Approx 22Approx

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


Motor Mount and Propeller Adapter

[email protected]

VTOL-05-008 1


O 18

4xO3.5

18

50

3

20 2346

32

13

13

4075

10.5

30

40.5

10.5 9.53

33

50

50

PLETTENBERG MOTOR MOUNTQUANTITY: 2SCALE: 1:1

MATERIAL: ALUMINIUMNOTE: TO BE WELDED TOGETHER FROM 3MM ALUMINIUM

APC PROPELLER ADAPTERQUANTITY: 2SCALE: 2:1

MATERIAL: STEELNOTE: PARTS ON THE FOLLOWING PAGE

5

1

2

4

3


Title Quantity

1 VTOL-05-008 Propeller Adapter Shaft 1

2 VTOL-05-008 Propeller Adapter Lower Collar 1

3 ------------ APC 20"x10" Glass Filled NylonPropeller

1

4 VTOL-05-008 Propeller Adapter Upper Collar 1

5 ------------ M8 Fibre Lock Nut 1

DRAWN



a1078621 27/10/05

TITLE SIZEA3

DWG NO REV


REVISION HISTORY


Motor Mount and Propeller Adapter

[email protected]

VTOL-05-008 1


O44

O 28.2

O 17.8

O 8

1.55.3

O25

O 15.9

O 8

1.5

3.4

M8

O14

4M

6O

2363

4017

4M

PROPELLER ADAPTER SHAFTQUANTITY: 2SCALE: 2:1

MATERIAL: STEELNOTE: ONE FOR EACH MOTOR

PROPELLER ADAPTER LOWER COLLARQUANTITY: 2SCALE: 2:1


PROPELLER ADAPTER UPPER COLLARQUANTITY: 2SCALE: 2:1


Appendix B

Simulink Code

100

% This file will build a state model of the 2005 RC VTOL (Osprey).% The file was adapted from Ben Cazzolato's state model template.

clcclose allclear alldisp('Mass of motors and fans')mf = 0.4; % mass of each front motor/prop (kg)mb = 0.1; % mass o rear motor/fan (kg)disp('Total mass')Mp = 4; %Mass of plane (kg)

%disp('Length of fuselage (m)')l1 = .05;l2 = .8;l3 = .5;

% Will need to work these out somehow%disp('Moment of intertia for a single motor/fan')J = mf;Jre = mb;%disp('Moments of inertia about each axis')Jy = 0.25934; %calculated on solid edge Jp = 0.094625; Jr = 0.19712;

% prop weighs 0.0433lbs = 195g.Jpr = 2.55e-3; % moment of inertia of prop, see p31 of allans book

disp('Motor/Fan Force and Torque constants')% some of these constants are not in use currently as they have been% replaced by experimentally determined values

Vhov = 8; % Voltage supplied to front motors for hover

kD = .004; % drag constant of props (assumed from prop calc)kt = .1901; % torque constant of motor (mN.m/A) (published on website)kB = 0; % torque constant of rear motor (Nm/A)keb = kB;Ra = .29; % armature resistance (ohms)CT = 0.0828; %thrust coefficient for propeller 20-10 estimated propcalckl = 0.7; % coefficient of lift for propsklrear = 0.5; % coefficient of lift for rear fanke = kt; %back emf constant = torque const in SI unitsKmp = ((.1901)^2/0.56 + 0.008*3000/60); %(bm + kt*ke/Ra + kD*theta_0_dot);% was 0.06;Kd = 0; % kD*theta_0_dot*kt/(Ra*Kmp); % Nm per volt Front Props (not measured) Kdr = 0; % Nm per volt Rear Prop/Fan (not measured)%Kp = kl*theta_0_dot*kt/(Ra*Kmp);

% From Thrust Testingthr = 2.5*9.81; % from full power thrust test on 12V battery 49N for both props;Kp = thr/10; % N x volt Front Props; Kr = .15/10; % N per volt Rear Prop/Fan;

Pd = l1*Kp/Jp;Rd = l3*Kp/Jr;Zd = Kp/Mp;

%_______________________________________________disp('Define the uncoupled model')disp('States : [y, y_dot, p, p_dot, r, r_dot, theta_L_dot,theta_R_dot, X, X_dot, Z, Z_dot]')% Angles are in radians% p = pitch% r = roll% y = yaw% theta_L = angular position of left prop% theta_R = angular position of right prop% X = translation along X axis% Y = translation along Y axis% Z = translation along Z axis

disp('State Matrix')

Am=[ 0 0 0 0 0 0 0 0 % * y_dot 0 0 0 0 1 0 0 0 % * p 0 0 0 0 0 1 0 0 % * r 0 0 0 0 0 0 Zd Zd % * Z_dot 0 0 0 0 0 0 -Pd -Pd % * p_dot 0 0 0 0 0 0 -Rd Rd % * r_dot 0 0 0 0 0 0 -Kmp/Jpr 0 % * theta_L_dot 0 0 0 0 0 0 0 -Kmp/Jpr ] % * theta_R_dot

disp('State input matrix')disp('Command states are: [Dl, Dr, Db, phi_L, phi_R]')% Vl Vr Vb phi L phi R Bm=[ Kd -Kd Kdr l3*Kp*Vhov/Jy -l3*Kp*Vhov/Jy % = y_ddot 0 0 0 0 0 % = p_dot 0 0 0 0 0 % = r_dot 0 0 -Kr/Mp 0 0 % = Z_ddot 0 0 l2*Kr/Jp 0 0 % = p_ddot 0 0 0 0 0 % = r_ddot kt/(Ra*Jpr) 0 0 0 0 % = theta_L_ddot 0 kt/(Ra*Jpr) 0 0 0 ] % = theta_R_ddot

%State output vector

% y p r X ZCm = [1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 ]; %Feedforward termDm = [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0];

disp(' ');disp(' ');

osprey_model = ss(Am,Bm,Cm,Dm);Statenames = str2mat('y_dot', 'p','r', 'Z_dot', 'p_dot', 'r_dot', 'theta_L_dot', 'theta_R_dot')set(osprey_model,'StateName',Statenames);set(osprey_model,'InputName',{'D_{left}'; 'D_{right}'; 'D_{back}'; 'Phi_{left}';... 'Phi_{right}'},'OutputName',{'yaw'; 'pitch'; 'roll'; 'Z_trans'})

disp(' ');disp(' ');disp('Now add the augmented states');disp('States : [y_dot, p, r, Z_dot , p_dot, r_dot, theta_L_dot,... theta_R_dot, alpha, beta, gamma, zeta, eta]');

% State MatrixA_augmented = [Am, zeros(8,4); Cm, zeros(4,4)];% State input matrixB_augmented = [ Bm; zeros(4,5)];% Also define an alternative input vector to allow us to input the desired% setpointsB_setpoint = zeros(12,4);B_setpoint(9,1)=-1;B_setpoint(10,2)=-1; B_setpoint(11,3)=-1;B_setpoint(12,4)=-1;% Augmented state input vector for 4 augmented states % B_aug = [B,B2]% State output vectorC_augmented = [Cm, zeros(4,4)];% Feedforward termD_augmented = Dm;

osprey_augmented = ss(A_augmented,B_augmented,C_augmented,D_augmented);Statenames = str2mat('y_dot', 'p','r','Z_dot', 'p_dot', 'r_dot', 'theta_L_dot',...

'theta_R_dot', 'alpha', 'beta', 'gamma', 'zeta');;set(osprey_augmented,'StateName',Statenames);set(osprey_augmented,'InputName',{'D_{left}'; 'D_{right}'; 'D_{back}'; 'Phi_{left}';... 'Phi_{right}'},'OutputName',{'yaw'; 'pitch'; 'roll'; 'Z_trans'});osprey_augmented;%%%disp('The open poles are')damp(Am);

step(osprey_model)title('Open Loop Step Response')

% Check controllabilityCo = ctrb(osprey_model);cond(Co);

% Check observabilityOb = obsv(osprey_model);cond(Ob);

unco = length(Am)-rank(Co); % number of uncontrollable statesunob = length(Am)-rank(Ob); % number of unobservable states

%_____________________________________________________________disp('Now design the controller')disp('State weighting matrix') q = diag([100 100 100 100 1 1 1 1 200 200 200 200])disp('Effort penalty matrix')r = diag([2 2 2 50 50])

% The controller gainsK = lqr(A_augmented,B_augmented,q,r);Km = K(:,1:8) % These are the usual feedback gainsKi = K(:,9:12) % These are the feedback gains for the augmented states

% The closed loop system with full state feedback isC_extra = [Cm;-Km]; % Augment the output so we can see the motor drive voltages.osprey_model_full = ss(Am-Bm*Km,Bm,C_extra,0);Statenames = str2mat('y_dot', 'p','r', 'Z_dot', 'p_dot', 'r_dot', 'theta_L_dot', 'theta_R_dot');set(osprey_model_full,'StateName',Statenames);set(osprey_model_full,... 'InputName',{'D_{left}'; 'D_{right}'; 'D_{back}'; 'Phi_{left}'; 'Phi_{right}'}, ... 'OutputName',{'yaw'; 'pitch'; 'roll'; 'Z_trans'; 'D_{left}'; 'D_{right}'; 'D_{back}';... 'Phi_{left}'; 'Phi_{right}'});

% Plot the closed loop step responsefigurestep(osprey_model_full)title('Closed loop step response with full state feedback');

% The closed loop augmented system with full state feedback and command following isC_extra = [C_augmented;-K]; % Augment the output so we can see the motor drive voltages.osprey_augmented_full = ss(A_augmented-B_augmented*K,B_setpoint,C_extra,0);Statenames = str2mat('y_dot','p','r', 'Z_dot', 'p_dot', 'r_dot', 'theta_L_dot',... 'theta_R_dot', 'alpha', 'beta', 'gamma', 'zeta');set(osprey_augmented_full,'StateName',Statenames);set(osprey_augmented_full,... 'InputName',{'Yaw Command'; 'Pitch Command'; 'Roll Command';'Z Trans Command'}, ... 'OutputName',{'yaw'; 'pitch'; 'roll';'Z_trans';'D_{right}';'D_{left}'; 'D_{back}';'Phi_{left}'; 'Phi_{right}'});osprey_augmented_full;

% % Plot the closed loop step responsefigurestep(osprey_augmented_full)title('Augmented system closed loop step response with full state feedback and command following')

%% Reduced Order Observer

% Splits A and B matrices into required form for Reduced Order Observerfor i = 1:4 for j = 1:4 Aaa(i,j) = Am(i,j); Ba(i,j) = Bm(i,j); endend

for i = 5:8 for j = 1:4 Aba(i-4,j) = Am(i,j); Bb(i-4,j) = Bm(i,j); endend

for i = 1:4 for j = 5:8 Aab(i,j-4) = Am(i,j); endend

for i = 5:8 for j = 5:8 Abb(i-4,j-4) = Am(i,j); endend

Qob = diag([1 1 1 1]); % Q matrix for kalman filterRob = diag([1 1 1 1]); % R matrix for Kalman filterG = lqr(Abb',Aab',Qob,Rob); % Determine observer gains

L = transpose(G);L_red = L;

%computes state matrices for reduced order observer to allow for a state%space block to be used in Simulink modelAr = Abb - L*Aab; Br = [(Aba- L*Aaa + Abb*L - L*Aab*L) (Bb - L*Ba)];Cr = eye(4);Dr = [L zeros(4,5)];

%% Full Rank Observer (used in estim command below)

P = pole(ss(Am-Bm*Km,Bm,Cm,Dm));

disp('Place observer poles at 10 times the controller poles')P_ob = 10*P;

disp('Now work out observer gains')L_transpose = place(transpose(Am),transpose(Cm),P_ob);L_full = transpose(L_transpose);

disp('Now build the full estimator (not reduced) using the "estim" command')% EST = ESTIM(SYS,L,SENSORS,KNOWN) % The system is "plant", the estimator gains are "L"% The sensors specify which outputs (y) are known, which in this case% is the first four states% The known refers to which inputs (u) to the plant are known.%% First determine the number of inputs and outputs from the plant[Nstates,Nin] = size(Bm)[Nout,Nstates] = size(Cm)SENSORS = [1:Nout]KNOWN = [1:Nin]system_estim = estim(osprey_model,L,SENSORS,KNOWN)plant_estim = estim(osprey_model,L)Statenames = str2mat( 'y_dot_est', 'p_est', 'r_est',... 'Z_dot_est','p_dot_est','r_dot_est','theta_L_dot_est', 'theta_R_dot_est')set(system_estim,'StateName',Statenames)set(system_estim, 'InputName',{'V_{left}'; 'V_{right}'; 'V_{back}'; 'Phi_{left}'; 'Phi_{right}';... 'Yaw_des'; 'Pitch_des'; 'Roll_des';'Z_des'},... 'OutputName',{'Yaw_est'; 'Pitch_est'; 'Roll_est';'Z_est'; 'y_dot_est';... 'p_est';'r_est';'Z_dot_est';'p_dot_est'; 'r_dot_est';'theta_L_dot_est'; 'theta_R_dot_est'})

%%% disp('*******************')disp('Design a regulator ')disp('*******************')

% Look at the regulated plant - For checking final systemdisp('The regulator is')osprey_model_reg = reg(osprey_model,Km,L)disp('The regulated system is')osprey_model_regulated = feedback(osprey_model,-osprey_model_reg)figurestep(osprey_model_regulated)title('Step response with regulator')%%

% disp('************************************************************************')disp('Now build all the subcomponents to make the model with integral tracking')disp('************************************************************************')

disp('*******************************************')disp('Build a state space model of the controller')disp('*******************************************')system_controller = ss([],[],[],-Km); % This is simply a feed forward termStatenames = str2mat( 'y_dot', 'r', 'p', 'Z_dot','p_dot','r_dot','theta_L_dot','theta_R_dot')set(system_controller,... 'InputName',{ 'y_dot_in','p_in','r_in','Z_dot_in', 'p_dot_in','r_dot_in','theta_L_dot_in','theta_R_dot_in'},... 'OutputName',{'Vcont_{left}'; 'Vcont_{right}'; 'Vcont_{back}'; 'Phi_cont_{left}'; 'Phi_cont_{right}'});system_controller

disp('******************************************************')disp('Build a state space model of only the augmented states')disp('******************************************************')% This is an integrator (on the input) for each state, with input weighting equal to the control gains calculated earliersystem_aug = ss(zeros(5),Ki,eye(5),0); Statenames = str2mat('alpha', 'gamma','beta','epsi','kappa')set(system_aug,'StateName',Statenames)set(system_aug,... 'InputName',{'Yaw Error'; 'Pitch Error';'Roll Error';'Z Error'},... 'OutputName',{'Integral Vl error'; 'Integral Vr error'; 'Integral Vb error';... 'Integral phi L error';'Integral phi R error'})system_aug%%disp('**********************************************')disp('Build a state space model of the command input')disp('**********************************************')% This is the only way to have four inputs into the augmented statessystem_input = ss([],[],[],eye(4));set(system_input,'InputName',{'Yaw SP', 'Pitch SP','Roll SP','Z SP'},'OutputName',{'Pitch SP', 'Yaw SP', 'Roll SP','Z SP'});system_input

system_plant = osprey_model;disp('********************************************************************************************')disp('Append the plant, the estimator, the controller, the augmented states and the command inputs')disp('********************************************************************************************')system_complete_temp = append(system_plant, system_estim, system_aug, system_controller, system_input)

goutput = get(system_complete_temp,'OutputName');ginput = get(system_complete_temp,'InputName');

disp('*********************************************************************************************')disp('Connect the plant, the estimator, the controller, the augmented states and the command inputs')disp('*********************************************************************************************')%% Connect all the appropriate inputs and outputs of the subsystems

% The connection from the plant output into the estimatorcon1 = [11, 1, 0; 12, 2, 0; 13, 3, 0; 14, 4, 0];

% The connection from the control gain and augmented states to the estimatorcon2 = [6, 22, 17; 7, 23, 18; 8, 24, 19 ; 9, 25, 20 ; 10, 26, 21];

% The connection from the control gain and augmented states to the plant inputcon3 = [1, 22, 17; 2, 23, 18; 3, 24, 19 ; 4, 25, 20 ; 5, 26, 21];

% The connection from the ref gain and plant output into the augmented states con4 = [15, 27, -1; 16, 28, -2; 17, 29,-3 ; 18, 30, -4;];

% The connection from the state estimates to the controller con5 = [ 19, 9, 0; 20 , 10, 0; 21, 11, 0; 22, 12, 0; 23, 13, 0; 24 , 14, 0; 25, 15, 0; 26, 16, 0]; CON = [con1;con2;con3;con4;con5]; INPUTS = [27,28,29,30]; % The inputs to the system are the four setpointsOUTPUTS = [1,2,3,4]; % The outputs from the system are

system_complete = connect(system_complete_temp,CON,INPUTS,OUTPUTS);C_extra = [system_complete.c;zeros(5,8), -Km, eye(5)]; % Add some additional outputs to see the motor control voltageD_extra = [0];system_complete = ss(system_complete.a, system_complete.b, C_extra, D_extra);set(system_complete,... 'InputName',{'Yaw SP', 'Pitch SP', 'Roll SP', 'Z SP'}, ... 'OutputName',{'Yaw'; 'Pitch'; 'Roll'; 'Z';'VL control';'VR control';'VB control';'PhiL control';'PhiR control'})Statenames = get(system_complete_temp,'StateName');

set(system_complete,'StateName',Statenames)system_completefigurestep(system_complete)title('Augmented System step response using an estimator with command following')

Appendix C

Embedded Controller Code

101

/* ------ Metrowerks Codewarrior Project: P:\Code\miniDRAGON_SS -------- */

/* ----------------------------------------------------------------------------------------------- File: main.c

----------------------------------------------------------------------------------------------- */

#include <mc9s12dp256.h> /* derivative information */#include "pll.h" /* defines _BUSCLOCK, sets bus frequency to _BUSCLOCK MHz */#include "timer.h"#include "ControlSystem.h"

void main(void) {

/* set system clock frequency to _BUSCLOCK MHz (24 or 4) */ PLL_Init(); /* Initialize the timer unit */ timer_Init(); /* Initialize the control system */ controlSystem_Init(); /* forever - check if the control system is ready for execution */ for(;;){ if( controlSystemFlag == 0x01 ){ controlSystemFlag = 0x00; controlSystem(); } }}

/* ----------------------------------------------------------------------------------------------- File: isr_vectors.c

----------------------------------------------------------------------------------------------- */

extern void near _Startup(void); /* Startup routine */

/* declarations of interrupt service routines *///extern __interrupt void SCI1_RX_isr(void);//extern __interrupt void RTI_isr(void);

#include "timer.h"#include "PicoPicCommInt.h"#include "IMUComms.h"

#pragma CODE_SEG __NEAR_SEG NON_BANKED/* Interrupt section for this module. Placement will be in NON_BANKED area. */

__interrupt void UnimplementedISR(void) {

/* Unimplemented ISRs trap.*/ asm BGND;}

typedef void (*near tIsrFunc)(void);const tIsrFunc _vect[] @0xFF80 = { /* Interrupt table */ UnimplementedISR, /* vector 63 : (reserved) */ UnimplementedISR, /* vector 62 : (reserved) */ UnimplementedISR, /* vector 61 : (reserved) */ UnimplementedISR, /* vector 60 : (reserved) */ UnimplementedISR, /* vector 59 : (reserved) */ UnimplementedISR, /* vector 58 : (reserved) */ UnimplementedISR, /* vector 57 : PWM emergency shutdown */ UnimplementedISR, /* vector 56 : PORT P */ UnimplementedISR, /* vector 55 : MSCAN4 - transmit */ UnimplementedISR, /* vector 54 : MSCAN4 - receive */ UnimplementedISR, /* vector 53 : MSCAN4 - errors */ UnimplementedISR, /* vector 52 : MSCAN4 - wakeup */ UnimplementedISR, /* vector 51 : MSCAN3 - transmit */ UnimplementedISR, /* vector 50 : MSCAN3 - receive */ UnimplementedISR, /* vector 49 : MSCAN3 - errors */ UnimplementedISR, /* vector 48 : MSCAN3 - wakeup */ UnimplementedISR, /* vector 47 : MSCAN2 - transmit */ UnimplementedISR, /* vector 46 : MSCAN2 - receive */ UnimplementedISR, /* vector 45 : MSCAN2 - errors */ UnimplementedISR, /* vector 44 : MSCAN2 - wakeup */ UnimplementedISR, /* vector 43 : MSCAN1 - transmit */

UnimplementedISR, /* vector 42 : MSCAN1 - receive */ UnimplementedISR, /* vector 41 : MSCAN1 - errors */ UnimplementedISR, /* vector 40 : MSCAN1 - wakeup */ UnimplementedISR, /* vector 39 : MSCAN0 - transmit */ UnimplementedISR, /* vector 38 : MSCAN0 - receive */ UnimplementedISR, /* vector 37 : MSCAN0 - errors */ UnimplementedISR, /* vector 36 : MSCAN0 - wakeup */ UnimplementedISR, /* vector 35 : FLASH */ UnimplementedISR, /* vector 34 : EEPROM */ UnimplementedISR, /* vector 33 : SPI2 */ UnimplementedISR, /* vector 32 : SPI1 */ UnimplementedISR, /* vector 31 : IIC bus */ UnimplementedISR, /* vector 30 : DLC */ UnimplementedISR, /* vector 29 : SCME */ UnimplementedISR, /* vector 28 : CRG lock */ UnimplementedISR, /* vector 27 : Pulse accumulator B overflow */ UnimplementedISR, /* vector 26 : Modulus down counter underflow */ UnimplementedISR, /* vector 25 : PORT H */ UnimplementedISR, /* vector 24 : PORT J */ UnimplementedISR, /* vector 23 : ATD1 */ UnimplementedISR, /* vector 22 : ATD0 */ SCI1_TDRE_ISR, /* vector 21 : SCI1 (TIE, TCIE, RIE, ILIE) */ SCI0_RIE_ISR, /* vector 20 : SCI0 (TIE, TCIE, RIE, ILIE) */ UnimplementedISR, /* vector 19 : SPI0 */ UnimplementedISR, /* vector 18 : Pulse accumulator input edge */ UnimplementedISR, /* vector 17 : Pulse accumulator A overflow */ UnimplementedISR, /* vector 16 : Timer Overflow (TOF) */ TOC7_ISR, /* vector 15 : Timer channel 7 */ TIC6_ISR, /* vector 14 : Timer channel 6 */ TIC5_ISR, /* vector 13 : Timer channel 5 */ TIC4_ISR, /* vector 12 : Timer channel 4 */ TIC3_ISR, /* vector 11 : Timer channel 3 */ TIC2_ISR, /* vector 10 : Timer channel 2 */ TIC1_ISR, /* vector 09 : Timer channel 1 */ TIC0_ISR, /* vector 08 : Timer channel 0 */ UnimplementedISR, /* vector 07 : Real-Time Interrupt (RTI) */ UnimplementedISR, /* vector 06 : IRQ */ UnimplementedISR, /* vector 05 : XIRQ */ UnimplementedISR, /* vector 04 : SWI */ UnimplementedISR, /* vector 03 : Unimplemented Instruction trap */ UnimplementedISR, /* vector 02 : COP failure reset*/ UnimplementedISR, /* vector 01 : Clock monitor fail reset */ _Startup /* vector 00 : Reset vector */ };

/* ----------------------------------------------------------------------------------------------- File: pll.h

----------------------------------------------------------------------------------------------- */

/*************************PLL.h***************************** boosts the CPU clock to 48 MHz ** ** Created by Theodore Deden on 20 January 2004. ** Modified by Theodore Deden on 9 February 2004. ** Last Modified by Jonathan Valvano 2/9/04. ** ** Distributed underthe provisions of the GNU GPL ver 2 ** Copying, redistributing, modifying is encouraged. ** ***********************************************************/

// modified to define _BUSCLOCK// PLL now running at 48 MHz to be consistent with HCS12 Serial Monitor// fw-07-04

#ifndef _PPL_H_#define _PLL_H_

/* Define the desired bus clock frequency: no PLL (crystal) -> SYSCLOCK = 4 MHz -> BUSCLOCK = 2 MHz PLL on -> SYSCLOCK = 48 MHz -> BUSCLOCK = 24 MHz This is used by sci0.c and/or sci1.c to determine the baud rate divider */#define _BUSCLOCK 24

//********* PLL_Init ****************

// Set PLL clock to 48 MHz, and switch 9S12 to run at this rate// Inputs: none// Outputs: none// Errors: will hang if PLL does not stabilize void PLL_Init(void);

#endif /* _PLL_H_ */

/* ----------------------------------------------------------------------------------------------- File: pll.c

----------------------------------------------------------------------------------------------- */

/*************************PLL.C**************************** boosts the CPU clock to 48 MHz ** ** Created by Theodore Deden on 20 January 2004. ** Modified by Theodore Deden on 9 February 2004. ** Last Modified by Jonathan Valvano 2/16/04. ** ** Distributed underthe provisions of the GNU GPL ver 2 ** Copying, redistributing, modifying is encouraged. ** **********************************************************/

// modified to make PLL_Init depend on _BUSCLOCK (defined in pll.h)// PLL now running at 48 MHz to be consistent with HCS12 Serial Monitor// fw-07-04

#include <hidef.h> /* common defines and macros */#include <mc9s12dp256.h> /* derivative information */#include "pll.h" /* macro _BUSCLOCK */

//********* PLL_Init ****************// Set PLL clock to 48 MHz, and switch 9S12 to run at this rate// Inputs: none// Outputs: none// Errors: will hang if PLL does not stabilize void PLL_Init(void){

/* ensure we're running the controller at an appropriate clock speed */ #if (_BUSCLOCK != 24 && _BUSCLOCK != 16) #error pll.h: _BUSCLOCK has to be set to 16 (MHz) or 24 (MHz) #endif /* set PLL clock speed */ #if _BUSCLOCK == 24 SYNR = 0x02; // PLLOSC = 48 MHz REFDV = 0x01; #else SYNR = 0x00; // PLLOSC = 32 MHz REFDV = 0x00; #endif /* PLLCLK = 2 * OSCCLK * (SYNR + 1) / (REFDV + 1)Values above give PLLCLK of 48 MHz with 4 MHz crystal.

(OSCCLK is Crystal Clock Frequency) */ CLKSEL = 0x00; /*Meaning for CLKSEL: Bit 7: PLLSEL = 0 Keep using OSCCLK until we are ready to switch to PLLCLK Bit 6: PSTP = 0 Do not need to go to Pseudo-Stop Mode Bit 5: SYSWAI = 0 In wait mode system clocks stop. But 4: ROAWAI = 0 Do not reduce oscillator amplitude in wait mode. Bit 3: PLLWAI = 0 Do not turn off PLL in wait mode Bit 2: CWAI = 0 Do not stop the core during wait mode Bit 1: RTIWAI = 0 Do not stop the RTI in wait mode Bit 0: COPWAI = 0 Do not stop the COP in wait mode */ PLLCTL = 0xD1; /*Meaning for PLLCTL: Bit 7: CME = 1; Clock monitor enable - reset if bad clock when set Bit 6: PLLON = 1; PLL On bit

Bit 5: AUTO = 0; No automatic control of bandwidth, manual through ACQ But 4: ACQ = 1; 1 for high bandwidth filter (acquisition); 0 for low (tracking) Bit 3: (Not Used by 9s12c32) Bit 2: PRE = 0; RTI stops during Pseudo Stop Mode Bit 1: PCE = 0; COP diabled during Pseudo STOP mode Bit 0: SCME = 1; Crystal Clock Failure -> Self Clock mode NOT reset. */ while((CRGFLG&0x08) == 0){ // Wait for PLLCLK to stabilize. } CLKSEL_PLLSEL = 1; // Switch to PLL clock}

/* ----------------------------------------------------------------------------------------------- File: timer.h

----------------------------------------------------------------------------------------------- */

extern char controlSystemFlag; // Flag to indicate start control system

void timer_Init( void ); // Initialize the timer module

extern float PWM_Capture_Ch0; // PWM input variables, range: 0-1extern float PWM_Capture_Ch1;extern float PWM_Capture_Ch2;extern float PWM_Capture_Ch3;extern float PWM_Capture_Ch4;extern float PWM_Capture_Ch5;extern float PWM_Capture_Ch6;

__interrupt void TOC7_ISR( void ); // Interrupt Service Routines for timer channels.__interrupt void TIC6_ISR( void );__interrupt void TIC5_ISR( void );__interrupt void TIC4_ISR( void );__interrupt void TIC3_ISR( void );__interrupt void TIC2_ISR( void );__interrupt void TIC1_ISR( void );__interrupt void TIC0_ISR( void );

/* ----------------------------------------------------------------------------------------------- File: timer.c

----------------------------------------------------------------------------------------------- */

/** * \file * Code to control the ECT timer module. Channel 7 causes * 40Hz Interrupts and Channels 0-6 capture PWM inputs. Channels * 0-3 are pins 9-12 (miniDRAGON+) and Channels 4-6 are pins * 15-17 (miniDRAGON+). * The PWM signal received from the R700 receiver normally varies between * 1.1ms and 1,9ms, hence the PWM is configured for this. * * \bugs Channel 5 doesn't work. This is because the channel is connected * to the speaker and a capaciter. This can be fixed by breaking * the J15 connection on the bottom of the board. * * * \author Zebb Prime * \date 19/7/05 * \version 1.0 beta */

#include <mc9s12dp256.h> // Derivative information

// Constants that define the operation of the PWM and the timed interrupts.#define timerOffset 37500 // Timer offset for 40Hz interupts#define lowCount 1650 // #Clock cycles for 1.1ms#define highCount 2850 // #Clock cycles for 1.9ms#define validCount 3000 // If greater than this ignore the value.#define fullPeriodThreshold 3500 // Threshold for low pwm#define pwmInputScale 1200.0 // Input resolution, highCount - lowCount#define pwmInputPeriod 33000 // Clock cycles per pwm input period

// Flag to begin control system computationchar controlSystemFlag;

// Variables containing the captured PWM signals. Vary from 0 to 1.

float PWM_Capture_Ch0;float PWM_Capture_Ch1;float PWM_Capture_Ch2;float PWM_Capture_Ch3;float PWM_Capture_Ch4;float PWM_Capture_Ch5;float PWM_Capture_Ch6;

// Holding variables for the channels without buffered registers.unsigned short first_Ch4;unsigned short first_Ch5;unsigned short first_Ch6;char PWM_Capture_flags;

// Variable to reduce period to 1s for flashing the LED.char timerDivider;

/** * \brief Initializes the ECT timer module. * * Sets up channel 7 for 40Hz interrupts and channels 0-6 for * PWM capture. The PWM signals saturate at 1.1ms and 1.9ms. * * \author Zebb Prime * \date 19/7/05 */void timer_Init( void ){ asm sei TIOS = 0x80; // Ch7 = OC, Ch0-6 = IC TCTL1 = 0x3F; // Disconnect pin 7 OC7M = 0x00; // Don't affect any linked input pins TCTL3 = 0xFF; // Detect on all edges TCTL4 = 0xFF; // Detect on all edges ICOVW = 0xFF; // Only write to registers when they're empty ICSYS = 0x0A; // TFMOD, BUFEN TSCR2 = 0x0C; // PR = 32, reset on successful OC TC7 = timerOffset; // Offset for 40Hz interrupts TIE = 0xFF; // Enable all interrupts TSCR1 = 0x80; // Enable Timer DDRB = 0xFF; // Port B is output DDRH = 0xFF; // Port H is output PWM_Capture_Ch0 = 0.5; PWM_Capture_Ch1 = 0.5; PWM_Capture_Ch2 = 0.5; PWM_Capture_Ch3 = 0.5; PWM_Capture_Ch4 = 0.5; PWM_Capture_Ch5 = 0.5; PWM_Capture_Ch6 = 0.5; PWM_Capture_flags = 0x00; controlSystemFlag = 0x00; // Initially don't start computation TFLG1 = 0xFF; // Clear all interrupt flags asm cli // Enable interrupts }

/** * \brief 40Hz interrupt routine. * * Toggles bottom LED of 7seg display at 1Hz, also sets flag * to mark the beginning of the control system. * * \author Zebb Prime * \date 19/7/05 */__interrupt void TOC7_ISR( void ){ if( timerDivider < 20 ){ timerDivider ++; }else{ timerDivider = 0; PTH ^= 0x08; // Toggle PortH bit3 }

controlSystemFlag = 0x01; // Set flag TFLG1 = 0x80; // Clear interrupt flag }

/** * \brief Interrupt service routine for Channel 0 PWM capture * * Channel 0 has a buffered holding register. Using this we only need * to interrupt once 2 edges have been caught (catches both rising and * falling edges). Determines if it has caught a rising then falling or * falling then rising edge by testing the time between them. Using this * it offsets and scales the input to between 0 (1.1ms) and 1 (1.9ms). * Can detect a maximum of 1200 discrete PWM input levels. * * \author Zebb Prime * \date 19/7/05 */__interrupt void TIC0_ISR( void ){ unsigned short first; unsigned short last; PTH |= 0x02; // Beginning of paylod first = TC0H; // Read from registers last = TC0; if( last > first ){ // Calculate difference between edges last -= first; }else{ last = (first - last) + timerOffset; } if( last > fullPeriodThreshold ){// Detect if PWM high or low last = pwmInputPeriod - last; } if( last > validCount ){ // If data is greater than the threshold, ignore it. PTH &= 0xFD; // End of payload TFLG1 = 0x01; // Clear interrupt flag return; } if( last < lowCount ){ // Test for lower limit PWM_Capture_Ch0 = 0.0; PTH &= 0xFD; // End of payload TFLG1 = 0x01; // Clear interrupt flag return; } if( last > highCount ){ // Test for upper limit PWM_Capture_Ch0 = 1.0; TFLG1 = 0x01; // Clear interrupt flag PTH &= 0xFD; // End of Payload return; } last = last - lowCount; // Offset PWM_Capture_Ch0 = ((float)last)/pwmInputScale; PTH &= 0xFD; // End of payload TFLG1 = 0x01; // Clear interrupt flag}

/** * \brief Interrupt service routine for Channel 1 PWM capture * * Channel 1 has a buffered holding register. Using this we only need * to interrupt once 2 edges have been caught (catches both rising and * falling edges). Determines if it has caught a rising then falling or * falling then rising edge by testing the time between them. Using this * it offsets and scales the input to between 0 (1.1ms) and 1 (1.9ms). * Can detect a maximum of 1200 discrete PWM input levels. * * \author Zebb Prime * \date 19/7/05 */__interrupt void TIC1_ISR( void ){ unsigned short first;

unsigned short last; PTH |= 0x02; // Beginning of paylod first = TC1H; // Read from registers last = TC1; if( last > first ){ // Calculate difference between edges last -= first; }else{ last = (first - last) + timerOffset; } if( last > fullPeriodThreshold ){ // Detect if PWM high or low last = pwmInputPeriod - last; } if( last > validCount ){ // If data is greater than the threshold, ignore it. PTH &= 0xFD; // End of payload TFLG1 = 0x02; // Clear interrupt flag return; } if( last < lowCount ){ // Test for lower limit PWM_Capture_Ch1 = 0.0; PTH &= 0xFD; // End of payload TFLG1 = 0x02; // Clear interrupt flag return; } if( last > highCount ){ // Test for upper limit PWM_Capture_Ch1 = 1.0; TFLG1 = 0x02; // Clear interrupt flag PTH &= 0xFD; // End of Payload return; } last = last - lowCount; // Offset PWM_Capture_Ch1 = ((float)last)/pwmInputScale; PTH &= 0xFD; // End of payload TFLG1 = 0x02; // Clear interrupt flag}

/** * \brief Interrupt service routine for Channel 2 PWM capture * * Channel 2 has a buffered holding register. Using this we only need * to interrupt once 2 edges have been caught (catches both rising and * falling edges). Determines if it has caught a rising then falling or * falling then rising edge by testing the time between them. Using this * it offsets and scales the input to between 0 (1.1ms) and 1 (1.9ms). * Can detect a maximum of 1200 discrete PWM input levels. * * \author Zebb Prime * \date 19/7/05 */__interrupt void TIC2_ISR( void ){ unsigned short first; unsigned short last; PTH |= 0x02; // Beginning of paylod

first = TC2H; // Read from registers last = TC2; if( last > first ){ // Calculate difference between edges last -= first; }else{ last = (first - last) + timerOffset; } if( last > fullPeriodThreshold ){ // Detect if PWM high or low last = pwmInputPeriod - last; } if( last > validCount ){ // If data is greater than the threshold, ignore it. PTH &= 0xFD; // End of payload TFLG1 = 0x04; // Clear interrupt flag return; }

if( last < lowCount ){ // Test for lower limit PWM_Capture_Ch2 = 0.0; PTH &= 0xFD; // End of payload TFLG1 = 0x04; // Clear interrupt flag return; } if( last > highCount ){ // Test for upper limit PWM_Capture_Ch2 = 1.0; TFLG1 = 0x04; // Clear interrupt flag PTH &= 0xFD; // End of Payload return; } last = last - lowCount; // Offset PWM_Capture_Ch2 = ((float)last)/pwmInputScale; PTH &= 0xFD; // End of payload TFLG1 = 0x04; // Clear interrupt flag}

/** * \brief Interrupt service routine for Channel 3 PWM capture * * Channel 3 has a buffered holding register. Using this we only need * to interrupt once 2 edges have been caught (catches both rising and * falling edges). Determines if it has caught a rising then falling or * falling then rising edge by testing the time between them. Using this * it offsets and scales the input to between 0 (1.1ms) and 1 (1.9ms). * Can detect a maximum of 1200 discrete PWM input levels. * * \author Zebb Prime * \date 19/7/05 */__interrupt void TIC3_ISR( void ){ unsigned short first; unsigned short last; PTH |= 0x02; // Beginning of paylod first = TC3H; // Read from registers last = TC3; if( last > first ){ // Calculate difference between edges last -= first; }else{ last = (first - last) + timerOffset; } if( last > fullPeriodThreshold ){ // Detect if PWM high or low last = pwmInputPeriod - last; } if( last > validCount ){ // If data is greater than the threshold, ignore it. PTH &= 0xFD; // End of payload TFLG1 = 0x08; // Clear interrupt flag return; } if( last < lowCount ){ // Test for lower limit PWM_Capture_Ch3 = 0.0; PTH &= 0xFD; // End of payload TFLG1 = 0x08; // Clear interrupt flag return; } if( last > highCount ){ // Test for upper limit PWM_Capture_Ch3 = 1.0; TFLG1 = 0x08; // Clear interrupt flag PTH &= 0xFD; // End of Payload return; } last = last - lowCount; // Offset PWM_Capture_Ch3 = ((float)last)/pwmInputScale; PTH &= 0xFD; // End of payload TFLG1 = 0x08; // Clear interrupt flag}

/**

* \brief Interrupt service routine for Channel 4 PWM capture * * Channel 4 does not have a buffered holding register like channels 0-3. * Hence we need to interrupt on every edge. On first edge it stores the * interrupt time and sets a flag. On the second edge it computes the PWM * input. Determines if it has caught a rising then falling or * falling then rising edge by testing the time between them. Using this * it offsets and scales the input to between 0 (1.1ms) and 1 (1.9ms). * Can detect a maximum of 1200 discrete PWM input levels. * * \author Zebb Prime * \date 19/7/05 */__interrupt void TIC4_ISR( void ){ unsigned short last; PTH |= 0x02; // Beginning of Payload if((PWM_Capture_flags & 0x10)==0){ // Capture first time first_Ch4 = TC4; PWM_Capture_flags |= 0x10; // Set flag TFLG1 = 0x10; // Clear Interrupt flag PTH &= 0xFD; // End of Payload }else{ // Capture second time last = TC4; PWM_Capture_flags &= 0xEF; // Clear flag if( last > first_Ch4 ){ // Calculate difference between edges last -= first_Ch4; }else{ last = (first_Ch4 - last) + timerOffset; } if( last > fullPeriodThreshold ){ // Detect if PWM high or low last = pwmInputPeriod - last; } if( last > validCount ){ // If data is greater than the threshold, ignore it. PTH &= 0xFD; // End of payload TFLG1 = 0x10; // Clear interrupt flag return; } if( last < lowCount ){ // Test for lower limit PWM_Capture_Ch4 = 0.0; PTH &= 0xFD; // End of payload TFLG1 = 0x10; // Clear interrupt flag return; } if( last > highCount ){ // Test for upper limit PWM_Capture_Ch4 = 1.0; TFLG1 = 0x10; // Clear interrupt flag PTH &= 0xFD; // End of Payload return; } last = last - lowCount; // Offset PWM_Capture_Ch4 = ((float)last)/pwmInputScale; PTH &= 0xFD; // End of payload TFLG1 = 0x10; // Clear interrupt flag }}

/** * \brief Interrupt service routine for Channel 5 PWM capture * * Channel 5 does not have a buffered holding register like channels 0-3. * Hence we need to interrupt on every edge. On first edge it stores the * interrupt time and sets a flag. On the second edge it computes the PWM * input. Determines if it has caught a rising then falling or * falling then rising edge by testing the time between them. Using this * it offsets and scales the input to between 0 (1.1ms) and 1 (1.9ms). * Can detect a maximum of 1200 discrete PWM input levels. * * \bugs Doesn't work due to the issues outlined in bug report at the top of * the file. * * \author Zebb Prime

* \date 19/7/05 */__interrupt void TIC5_ISR( void ){ unsigned short last; PTH |= 0x02; // Beginning of Payload if((PWM_Capture_flags & 0x20)==0){ // Capture first time first_Ch5 = TC5; PWM_Capture_flags |= 0x20; // Set flag TFLG1 = 0x20; // Clear Interrupt flag PTH &= 0xFD; // End of Payload }else{ // Capture second time last = TC5; PWM_Capture_flags &= 0xDF; // Clear flag if( last > first_Ch5 ){ // Calculate difference between edges last -= first_Ch5; }else{ last = (first_Ch5 - last) + timerOffset; } if( last > fullPeriodThreshold ){ // Detect if PWM high or low last = pwmInputPeriod - last; } if( last > validCount ){ // If data is greater than the threshold, ignore it. PTH &= 0xFD; // End of payload TFLG1 = 0x20; // Clear interrupt flag return; } if( last < lowCount ){ // Test for lower limit PWM_Capture_Ch5 = 0.0; PTH &= 0xFD; // End of payload TFLG1 = 0x20; // Clear interrupt flag return; } if( last > highCount ){ // Test for upper limit PWM_Capture_Ch5 = 1.0; TFLG1 = 0x20; // Clear interrupt flag PTH &= 0xFD; // End of Payload return; } last = last - lowCount; // Offset PWM_Capture_Ch5 = ((float)last)/pwmInputScale; PTH &= 0xFD; // End of payload TFLG1 = 0x20; // Clear interrupt flag }}

/** * \brief Interrupt service routine for Channel 6 PWM capture * * Channel 6 does not have a buffered holding register like channels 0-3. * Hence we need to interrupt on every edge. On first edge it stores the * interrupt time and sets a flag. On the second edge it computes the PWM * input. Determines if it has caught a rising then falling or * falling then rising edge by testing the time between them. Using this * it offsets and scales the input to between 0 (1.1ms) and 1 (1.9ms). * Can detect a maximum of 1200 discrete PWM input levels. * * \author Zebb Prime * \date 19/7/05 */__interrupt void TIC6_ISR( void ){ unsigned short last; PTH |= 0x02; // Beginning of Payload if((PWM_Capture_flags & 0x40)==0){ // Capture first time first_Ch6 = TC6; PWM_Capture_flags |= 0x40; // Set flag TFLG1 = 0x40; // Clear Interrupt flag PTH &= 0xFD; // End of Payload }else{ // Capture second time last = TC6;

PWM_Capture_flags &= 0xBF; // Clear flag if( last > first_Ch6 ){ // Calculate difference between edges last -= first_Ch6; }else{ last = (first_Ch6 - last) + timerOffset; } if( last > fullPeriodThreshold ){ // Detect if PWM high or low last = pwmInputPeriod - last; } if( last > validCount ){ // If data is greater than the threshold, ignore it. PTH &= 0xFD; // End of payload TFLG1 = 0x40; // Clear interrupt flag return; } if( last < lowCount ){ // Test for lower limit PWM_Capture_Ch6 = 0.0; PTH &= 0xFD; // End of payload TFLG1 = 0x40; // Clear interrupt flag return; } if( last > highCount ){ // Test for upper limit PWM_Capture_Ch6 = 1.0; TFLG1 = 0x40; // Clear interrupt flag PTH &= 0xFD; // End of Payload return; } last = last - lowCount; // Offset PWM_Capture_Ch6 = ((float)last)/pwmInputScale; PTH &= 0xFD; // End of payload TFLG1 = 0x40; // Clear interrupt flag }}

/* ----------------------------------------------------------------------------------------------- File: SS_Coeff.h (Truncated for printing, please see file for all coefficients)

----------------------------------------------------------------------------------------------- */

/*This is an automatically generated C header containing the state-space coefficients for embedded implementation.Matlab Script: ss_to_C(state_model,filename)Filename: miniDragon_SS/sources/SS_Coeff.h*/

const float A[21][21]= {-9.1569272269e-001, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, -9.1569268446e-001, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, -3.8880428789e-001, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, -3.8880429515e-001, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 8.1703176158e-001...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, -1.5453544113e-001...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000, 0.0000000000e+000...};

#define A_r 21#define A_c 21

const float B[21][4]= {3.6582688568e-013, 2.4467522904e-014, 3.1242486781e-014, -2.1705685760e-014,

1.6712711309e-013, 5.2834063705e-013, -1.2557649859e-013, -8.1983891956e-013,1.9843779054e-012, 5.9900646127e+000, 2.2014237798e-007, -1.3504266527e+000,-2.9010561451e-012, 1.5089742169e-007, 6.1617707053e+000, -3.4017976770e-008,-2.4184664193e-011, -4.7056325828e-012, 1.3492266473e-012, 1.7220433282e-012,-4.4849946680e-011, -1.4073711378e-011, 4.5062648469e-012, 3.1700405834e-012,7.4181812052e-012, -1.8413170676e-012, 1.1911860740e-012, 3.3944339450e-014,3.3737575024e-011, 2.1871351392e-011, -9.4595802845e-012, -5.0029395807e-012,3.7938084548e-011, 2.7250524993e-011, -6.5493908201e-012, -4.8949575126e-012,-4.6764788929e-011, 2.6509138572e-011, 5.2382893392e-011, -1.1272323060e-012,-1.3783742617e-011, 6.1147145472e-011, 7.0997845059e-002, -8.2123923013e-012,3.7013896008e-011, -3.7372361300e-011, -2.7746898269e+001, 3.7811686665e-012,-2.1586936395e+000, 1.7292502007e-012, -5.5748089934e-014, -2.0138870928e-013,-2.3222524122e+000, -1.5280042564e-012, 1.0041674945e-013, 3.4836853354e-014,-2.2717536008e-011, 1.5838285949e-001, 5.6269623357e-012, 2.8203040294e-001,1.3437569820e-011, 2.7135180414e+001, 1.3139954975e-011, -6.8533579834e-001,5.7031990974e-012, 9.2537772449e-011, 2.2784283437e+001, -7.1467867754e-013,-9.1060348650e-013, 1.6393862198e-002, -1.0137053021e-012, 1.0561911880e+001,1.3310443365e-011, -1.3336306705e-001, 1.0280626427e-011, 1.0930577444e+001,-2.3104715970e-012, -2.2614016329e+001, 8.2612501756e-012, 2.9346513625e-001,2.1921292290e-014, -1.8582181118e-015, -6.0355819202e-015, 3.2943424657e-015};

#define B_r 21#define B_c 4

const float C[9][21]= {-1.5135710425e-009, -5.0000998413e-011, 2.8280210190e-020, -1.7387059327e-020, 8.6650829691e-008..1.2538929729e-016, 2.4449164424e-007, -1.8707062049e-005, -5.0650824380e-004, -8.2050340264e-017..8.5468421435e-004, -3.5955196304e-017, -4.3783564211e-016, 4.2501851266e-015, 3.0349521701e-017...-7.9623063711e-005, -1.3054349330e-004, 1.1832256217e-016, 1.7468585945e-004, -1.7021630967e-004..6.8601559232e-005, 1.6517375709e-005, -4.7059613017e-005, -1.7105528226e-006, 3.0658896706e-005...6.8601559232e-005, 1.6517375709e-005, 4.7059613017e-005, -1.7105528223e-006, 3.0658896705e-005...-2.0895429305e-003, 1.6922006100e-004, 7.2704763060e-015, -4.3194157336e-004, 2.2771334703e-002...-4.9376122033e-016, -9.1493967213e-016, 3.7769139042e-017, 4.8777088403e-016, -4.5010575369e-016..1.1450331826e-005, -8.0359465268e-006, 4.9955754429e-006, 4.6401473120e-018, 3.8328293839e-017...};

#define C_r 9#define C_c 21

const float D[9][4]= {5.1054167768e-005, -5.9863029349e-019, -6.1332346957e-019, 1.4606183962e-019,3.0196506168e-024, 1.1141134508e-007, -6.1612654539e-019, 6.2663331226e-009,2.9511260106e-024, -5.0774104049e-018, 5.1120242753e-007, 1.2394756926e-018,-2.9847545536e-022, -6.3630467674e-006, 1.3033869983e-019, 1.3318683848e-006,-1.4440332303e-018, -2.6648620966e-002, -2.7118402241e-002, 6.0801804810e-003,-1.1309289964e-018, -2.6648620966e-002, 2.7118402241e-002, 6.0801804810e-003,-8.2208294403e-018, 2.7308393981e-002, -2.7622221347e-015, 1.2169653467e-001,1.7491888561e-002, 1.7610189069e-018, -2.9154543622e-018, 3.0797889565e-018,-1.7491888561e-002, -1.7610189069e-018, 2.9154543622e-018, -3.0797889565e-018};

#define D_r 9#define D_c 4

#define state_length 21#define input_length 4#define output_length 9

/* ----------------------------------------------------------------------------------------------- File: ControlSystem.h

----------------------------------------------------------------------------------------------- */

void controlSystem_Init( void ); // Initialize the control systemvoid controlSystem( void ); // Run the control system

/* ----------------------------------------------------------------------------------------------- File: ControlSystem.c

----------------------------------------------------------------------------------------------- */

/** * \file * Control system computation. Occurs outside an interrupt as there are a large * number of interrupts that need to occur while the control system computation * is taking place. Note the state-space controller hasn't been tested. It is * recommended that this take place! *

* * \author Zebb Prime * \date 22/7/05 * \version 1.0 alpha */

#include <mc9s12dp256.h> // Derivative information#include <math.h>#include "timer.h"#include "PicoPicCommInt.h"#include "IMUComms.h"#include "SS_Coeff.h"

#define pi 3.141592564

void SSmatrixMult(float *X, float *Y, float *result, int X_r, int X_c);

char active; // Control System active flag.char counter; // count until control system starts

float current_states[ state_length ];float next_states[ state_length ];float inputs[ input_length ];float outputs[ output_length ];float Z_d;

/** * \brief Initialize the control system. * * Initializes the SCI1 module for communications to PicoPic and * the SCI0 module for the IMU. Also clears all of the state variables. * * \author Zebb Prime * \date 22/7/05 */ void controlSystem_Init( void ){ int ii; PicoPicCommInt_Init(); IMUComms_Init(); active = 0; counter = 80; // 2 second delay DDRB = 0xff; // Port B is output for(ii=0; ii<state_length; ii++){ // Clear States current_states[ ii ] = 0.0; next_states[ ii ] = 0.0; Z_d = 0.0; }}

/** * \brief Computes the control system. * * For safety the remote control landing gear switch (PWM Capture Channel 4) must * be on for at least two seconds before the control system will start. * Computes the connected state space model of the controller through matrix * multiplication. * * \author Zebb Prime * \date 5/10/05 */void controlSystem( void ){ int ii; float temp_states[ state_length ]; PTH |= 0x01; // Beginning of payload IMUComms_Update(); // Update the IMU data. // If the switch is off, then stop the control system. if( PWM_Capture_Ch4 < 0.9 ){ counter = 81; active = 0; PORTB &= 0x7F; // Turn off PortB.7 (Pin 31 - LED) }

if( active == 0 ){ // If the control system is off PicoPicCommInt_Send( 0, 1); // All signals to 0 PicoPicCommInt_Send( 0, 2); PicoPicCommInt_Send( 0.709677419, 4); PicoPicCommInt_Send( 0.29032258, 5); PicoPicCommInt_Send( 0, 7); // Decrement count. counter --; if( counter == 0 ){ // If the switch has been on for two active = 1; // seconds, start the controller and reset the states. for(ii=0; ii<state_length; ii++){ current_states[ ii ] = 0.0; next_states[ ii ] = 0.0; Z_d = 0.0; } } }else{ PORTB |= 0x80; // Turn on PortB.7 (Pin 31 - LED) /* State Space Control Implementation */ // update state vectors for(ii=0; ii<state_length; ii++){ current_states[ ii ] = next_states[ ii ]; } Z_d += (scaledOutput[ 6 ] + 9.81)*0.025; // Integrate Z acceleration // Calculate controller inputs (setpoints - feedback) inputs[0] = (PWM_Capture_Ch3+0.5)*pi - scaledOutput[ 2 ]; // Yaw = Yaw_SP - Yaw_FB inputs[1] = (PWM_Capture_Ch2+0.5)*pi/12 - scaledOutput[ 1 ]; // Pitch = Pitch_SP - Pitch_FB inputs[2] = (PWM_Capture_Ch1+0.5)*pi/12 - scaledOutput[ 0 ]; // Roll = Roll_SP - Roll_FB inputs[4] = (PWM_Capture_Ch0+0.5) - Z_d; // Z_d = Z_d_SP - Z_d_FB SSmatrixMult(&A,&current_states,&temp_states,A_r,A_c); // A*x SSmatrixMult(&B,&inputs,&next_states,B_r,B_c); // B*u for(ii=0; ii<state_length; ii++){ // x_n = A*x + B*u next_states[ii] += temp_states[ii]; } SSmatrixMult(&C,&current_states,&temp_states,C_r,C_c); // C*x SSmatrixMult(&D,&inputs,&outputs,D_r,D_c); // D*u for(ii=0; ii<output_length; ii++){ // y = C*x + D*u outputs[ii] += temp_states[ii]; } PicoPicCommInt_Send( outputs[4]/10, 1); // Send the left motor speed PicoPicCommInt_Send( outputs[5]/10, 2); // Send the right motor speed PicoPicCommInt_Send( 0.36965019*outputs[7]+0.709677419, 4); // Send the left servo position PicoPicCommInt_Send( -0.36965019*outputs[8]+0.29032258, 5); // Send the right servo position PicoPicCommInt_Send( outputs[6]/10, 7); // Send the rear motor speed } PTH &= 0xFE; // End of payload}

/*** \brief Performs State-Space matrix multiplication (matrix * vector).** \param X: first matrix for multiplication* \param Y: second matrix for multiplication* \param result: matrix to house the result (please make sure the size is correct)* \param X_r: number of rows of X* \param X_c: number of columns of X** \author Zebb Prime* \date 24/10/05*/void SSmatrixMult(float *X, float *Y, float *result, int X_r, int X_c){ int ii, jj, kk; float temp; // Matrix * Vector multiplication kk=0; for( ii=0; ii<X_r; ii++ ){

temp = 0; for( jj=0; jj<X_c; jj++){ temp += *(X+kk) * *(Y+jj); kk ++; } *(result + ii) = temp; }}

/* ----------------------------------------------------------------------------------------------- File: IMUComms.h

----------------------------------------------------------------------------------------------- */

#define GSEAARV // Defined mode#define BAUD_115200 // Defined baud rate

void IMUComms_Init( void ); // Prototypeschar IMUComms_Update( void );__interrupt void SCI0_RIE_ISR( void );

// Available modes#ifdef RSO #define outputLength 9#endif#ifdef GSV #define outputLength 9#endif#ifdef IV #define outputLength 9#endif#ifdef IQ #define outputLength 4#endif#ifdef GSQ #define outputLength 4#endif#ifdef IOM #define outputLength 9#endif#ifdef GSO #define outputLength 9#endif#ifdef GSQV #define outputLength 13#endif#ifdef IEA #define outputLength 3#endif#ifdef GSEA #define outputLength 3#endif#ifdef GSEARV #define outputLength 6#endif#ifdef GSEAARV #define outputLength 9#endif

extern float scaledOutput[ outputLength ];

/* ----------------------------------------------------------------------------------------------- File: IMUComms.c

----------------------------------------------------------------------------------------------- */

/** * \file * \brief Communications to the 3DM-GX1 IMU using interrupts over SCI0 * * data bits = 8, stop = 1, parity = none, baud - see header * Communicates to the 3DM-GX1 IMU using receiver interrupts. Mode is selectable * by declaring the acronym in the header file IMUComms.h. * * \author Zebb Prime * \date 8/9/05 * \version 1.0 */ #include <mc9s12dp256.h> /* derivative information */

#include <math.h> /* Math libraries */#include "IMUComms.h"

#define pi 3.141592653 #define RDRF 0x20 // Receive Data Register Full Bit#define TDRE 0x80 // Transmit Data Register Empty Bit

#define bufferLength (outputLength*2+5)

char ReadBuffer[ bufferLength ]; // Not a ringbuffer.char bufferIndex;

float scaledOutput[ outputLength ];

// Raw sensor output#ifdef RSO

#define commandByte 0x01 const float scalingValues[ outputLength ] = { 5.0/65536.0, 5.0/65536.0, 5.0/65536.0, 5.0/65536.0, 5.0/65536.0, 5.0/65536.0, 5.0/65536.0, 5.0/65536.0, 5.0/65536.0 };

#endif// Gyro stabilised vectors#ifdef GSV #define commandByte 0x02 #define magGainScale 4000.0 #define accelGainScale 7000.0 #define gyroGainScale 8500.0 const float scalingValues[ outputLength ] = { magGainScale/32768000.0, magGainScale/32768000.0, magGainScale/32768000.0, accelGainScale/32768000.0, accelGainScale/32768000.0, accelGainScale/32768000.0, gyroGainScale/32768000.0, gyroGainScale/32768000.0, gyroGainScale/32768000.0 };#endif// Instantaneous vectors#ifdef IV #define commandByte 0x03 #define magGainScale 2000.0 #define accelGainScale 7000.0 #define gyroGainScale 8500.0 const float scalingValues[ outputLength ] = { magGainScale/32768000.0, magGainScale/32768000.0, magGainScale/32768000.0, accelGainScale/32768000.0, accelGainScale/32768000.0, accelGainScale/32768000.0, gyroGainScale/32768000.0, gyroGainScale/32768000.0, gyroGainScale/32768000.0 };#endif// Instantaneous Quaternion#ifdef IQ #define commandByte 0x04 const float scalingValues[ outputLength ] = { 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0 };#endif// Gyro Stabilised Quaternion#ifdef GSQ #define commandByte 0x05 const float scalingValues[ outputLength ] = { 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0 };#endif// Instantaneous Orientation Matrix#ifdef IOM #define commandByte 0x0A const float scalingValues[ outputLength ] = { 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0 };#endif// Gyro Stabilised Oriantation Matrix#ifdef GSO #define commandByte 0x0B const float scalingValues[ outputLength ] = { 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0 };#endif// Gyro Stabilised Quaternion and Vectors#ifdef GSQV

#define commandByte 0x0C #define magGainScale 2000.0 #define accelGainScale 7000.0 #define gyroGainScale 8500.0 const float scalingValues[ outputLength ] = { 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.0, magGainScale/32768000.0, magGainScale/32768000.0, magGainScale/32768000.0, accelGainScale/32768000.0, accelGainScale/32768000.0, accelGainScale/32768000.0, gyroGainScale/32768000.0, gyroGainScale/32768000.0, gyroGainScale/32768000.0 };#endif// Instantaneous Euler Angles (rad)#ifdef IEA #define commandByte 0x0D const float scalingValues[ outputLength ] = { 2.0*pi/65536.0, 2.0*pi/65536.0, 2.0*pi/65536.0 };#endif// Gyro Stabilised Euler Angles (rad) #ifdef GSEA #define commandByte 0x0E const float scalingValues[ outputLength ] = { 2.0*pi/65536.0, 2.0*pi/65536.0, 2.0*pi/65536.0 };#endif// Gyro Stabilised Euler Angles (rad) and Rate Vector (rad/s)#ifdef GSEARV #define commandByte 0x30 #define gyroGainScale 8500.0 const float scalingValues[ outputLength ] = { 2.0*pi/65536.0, 2.0*pi/65536.0, 2.0*pi/65536.0, gyroGainScale/32768000.0, gyroGainScale/32768000.0, gyroGainScale/32768000.0 }; #endif// Gyro Stabilised Euler Angles (rad) and Acceleration (g) and Rate Vectors (rad/s).#ifdef GSEAARV #define commandByte 0x31 #define accelGainScale 7000.0 #define gyroGainScale 8500.0 const float scalingValues[ outputLength ] = { 2.0*pi/65536.0, 2.0*pi/65536.0, 2.0*pi/65536.0, accelGainScale/32768000.0, accelGainScale/32768000.0, accelGainScale/32768000.0, gyroGainScale/32768000.0, gyroGainScale/32768000.0, gyroGainScale/32768000.0 };#endif /** * \brief Initialize SCI0 for communications to the 3DM-GX1 IMU * * Sets the communication parameters such as baud, data bits and parity. * Communications are two-way so both transmitter and receiver are enabled. * Interrupts are enabled for receive register full, however command packets * are one byte so polling is sufficient for sending. * * \author Zebb Prime * \date 28/7/05 */void IMUComms_Init( void ){ char i; asm sei #ifdef BAUD_115200 // Set up baud rate SCI0BDH=0; SCI0BDL=13; #endif #ifdef BAUD_38400 SCI0BDH=0; SCI0BDL=39; #endif #ifdef BAUD_19200 SCI0BDH=0; SCI0BDL=78 #endif SCI0CR1=0x00; // data = 8, stop = 1, parity = none SCI0CR2=0x2C; // RIE,TE,RE bufferIndex = 0; // Reset Buffer Index

for( i=0; i<outputLength; i++ ){ // Clear output values scaledOutput[i] = 0.0; } asm cli // enable interrupts}

/** * \brief Updates that data in the holding variables, requests the next lot of data from the * IMU * * Calculates the checksum to make sure the packet is valid, if so the results are converted * to floating point values and normalized, then placed in the holding variables. It then * sends a request to the IMU for the next data packet. This implies that the data will * always be Ts behind at worst. * * \return valid: 1 if data in variables is valid, 0 if not. * \author Zebb Prime * \date 28/7/05 */char IMUComms_Update( void ){ char i; short temps; float tempf; if( (SCI0SR1 & RDRF) != 0 ){ temps = SCI0DRL; } for(i=0; i<outputLength; i++){ temps = ReadBuffer[ (i*2+1) ] << 8; // Data MSB temps += ReadBuffer[ (i*2+2) ]; // Data LSB tempf = (float)temps; // convert to floating point tempf *= scalingValues[i]; // scale scaledOutput[i] = tempf; // store } if(bufferIndex == bufferLength) i = 0x01; else i = 0x00; bufferIndex = 0; // reset the buffer index while((SCI0SR1 & TDRE) == 0){}; // When Tx ready SCI0DRL = commandByte; // Send request for next byte return i;}

/** * \brief miniDRAGON+ to 3DM-GX1 over SCI0 received data interrupt service routine * * Adds the received data to the buffer. The buffer must be big enough to hold all of the * input data. If the buffer is full the byte is ignored. * * \author Zebb Prime * \date 28/7/05 */__interrupt void SCI0_RIE_ISR( void ){ char temp; if( bufferIndex == bufferLength ){ // if buffer is full discard the byte while((SCI0SR1 & RDRF) == 0){}; temp = SCI0DRL; return; } while((SCI0SR1 & RDRF) == 0){}; // Test to see if data is present ReadBuffer[ bufferIndex ] = SCI0DRL; // Place the data in the buffer bufferIndex ++;}

/* ----------------------------------------------------------------------------------------------- File: PicoPicCommInt.h

----------------------------------------------------------------------------------------------- */

void PicoPicCommInt_Init( void ); // Initialize SCI1 to PicoPic

void PicoPicCommInt_Send( float position, char port ); // Send a position setpoint to PicoPic

__interrupt void SCI1_TDRE_ISR( void ); // SCI1 TDRE interrupt service routine

/* -----------------------------------------------------------------------------------------------

File: PicoPicCommInt.c----------------------------------------------------------------------------------------------- */

/** * \file * \brief Communications to the PicoPic using SCI1 with interrupts. * * baud = 115200, data bits = 8, parity = none. * Even though the baud is set at the maximum for the PicoPic there * was still significant latency when communicating using polling * (~0.5 ms per channel) which is too much considering there is only * 25ms available per control system cycle (40Hz). Hence using interrupts * the polling overhead is removed freeing MCU time for other computation * while still transferring data to the PicoPic as fast as possible. * * Utilizes a ring-buffer to store data. There is no buffer overflow check * so if the communications starts doing crazy stuff try increasing the * bufferLength parameter. As indicated below the current maximum buffer * length is 255 (using 8-bit indexes), to increase this change SCI1Buffer * and SCI1Sent to unsigned short or unsigned int (16-bit: max length 65535). * * \author Zebb Prime * \data 19/7/05 * \version 1.0 */

#include <mc9s12dp256.h> /* derivative information */

#define TDRE 0x80 // Transmit Data Register Empty

#define bufferLength 100 // Max 255 unless change pointers to short

char SCI1RingBuffer[ bufferLength ]; // Ringbuffer variableschar SCI1Buffer;char SCI1Sent;

/** * \brief Initialize SCI1 for communications to the PicoPic * * Sets the communication parameters such as baud, data bits and parity. * Communications are one way so it only enables the transmitter. Interrupts * aren't enabled until the buffer is non-empty. * * \author Zebb Prime * \date 19/7/05 */void PicoPicCommInt_Init( void ){ char i; SCI1BDH=0; // baud = 115200 SCI1BDL=13; SCI1CR1=0x00; // No parity SCI1CR2=0x08; // TIE,Enable Transmitter

for(i=0; i < bufferLength; i++ ){ // Clear buffer SCI1RingBuffer[i] = 0; } SCI1Buffer = 0; SCI1Sent = 0; asm cli; // Global enable Interrupts}

/** * \brief Sends a position to the PicoPic. * * Scales the input to values recognisable by the PicoPic, then * places the data into the ring-buffer. If the buffer was empty at the * beginning of the call it starts the transmission by enabling the interrupts. * * \param position: float - value between 0 and 1 indicating the desired position * of the servo. If <0 or >1 saturates to 0 or 1. * \param port: char (byte) - servo port to send the position to (1 - 20) * * \author Zebb Prime * \date 19/7/05 */

void PicoPicCommInt_Send( float position, char port ){ short setpoint; char data; char flag; // Flag if buffer is empty if( SCI1Buffer == SCI1Sent ) flag = 1; else flag = 0; setpoint = (short)(1500.0*position); // Scale for PicoPic setpoint += 750; // Offset for PicoPic if(setpoint > 2135){ // Position Saturation setpoint = 2135; }else if( setpoint < 750 ){ setpoint = 750; } SCI1RingBuffer[ SCI1Buffer ] = 120; // Put PicoPic address in buffer SCI1Buffer ++; if( SCI1Buffer == bufferLength ) SCI1Buffer = 0; SCI1RingBuffer[ SCI1Buffer ] = port; // Put servo port in buffer SCI1Buffer ++; if( SCI1Buffer == bufferLength ) SCI1Buffer = 0; data = (char)(setpoint/256); // Put upper position byte in buffer SCI1RingBuffer[ SCI1Buffer ] = data; SCI1Buffer ++; if( SCI1Buffer == bufferLength ) SCI1Buffer = 0; data = (char)(setpoint%256); SCI1RingBuffer[ SCI1Buffer ] = data; // Put lower position byte in buffer SCI1Buffer ++; if( SCI1Buffer == bufferLength ) SCI1Buffer = 0; SCI1RingBuffer[ SCI1Buffer ] = 0; // Put a 0 in the buffer SCI1Buffer ++; if( SCI1Buffer == bufferLength ) SCI1Buffer = 0; if(flag == 1){ // If the buffer is initially empty. SCI1CR2 = 0x88; // Enable the interrupts }}

/** * \brief SCI1 to PicoPic Transmission Data Register Empty (TDRE) interrupt * service routine. * * Tests if the ring-buffer is empty. If it is the interrupts are disabled, * otherwise it places the next byte in the transmission register to send * to the PicoPic. * * \author Zebb Prime * \date 19/7/05 */__interrupt void SCI1_TDRE_ISR( void ){ PTH |= 0x40; // Turn on the Tx LED.

if( SCI1Buffer == SCI1Sent ){ // If nothing to send PTH &= 0xBF; // Turn off Tx LED SCI1CR2 = 0x08; // Turn off the interrupts return; } while((SCI1SR1 & TDRE) == 0){}; // Read SCI1SR1 (needed before transmission) SCI1DRL = SCI1RingBuffer[ SCI1Sent ]; // Place next byte in register SCI1Sent ++; // Update ring-buffer if(SCI1Sent == bufferLength) SCI1Sent = 0; PTH &= 0xBF; // Turn off Tx LED}

rc plane so vertikalno poletuvanje

Documents

control systemswhile

control technique

control simplifications

howeverthis control

appropriate control

standard remote control

lqr optimal control

ofthe control peripherals