Design and Build of a Remote Control (RC) Verical Take

Transcription

!
"#$ %!
#
!
%!
%& %!
!
"#
ii
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 tiltrotor 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
vi
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
viii
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
3.1
3.2
3.3
13
F-35 Joint Strike Fighter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1
Ducted Fans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2
Basic Feasibility Calculation . . . . . . . . . . . . . . . . . . . . . . 15
Osprey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1
RC Propellers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2
Basic Feasibility Calculations . . . . . . . . . . . . . . . . . . . . . 17
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Mechanical Design
4.1
4.2
4.3
19
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
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
Propulsion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1
Propeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2
Propeller Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.3
Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
x
Contents
4.4
4.5
Contents
4.3.4
Batteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.5
Propulsion Component Summary . . . . . . . . . . . . . . . . . . . 34
4.3.6
Tail Thrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1
Inertial Measurement Unit (IMU) . . . . . . . . . . . . . . . . . . . 37
4.4.2
Rate Gyroscopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5.1
Servo Motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Mathematical System Model
39
5.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2
State Equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3
5.2.1
Linearisation Methods Used . . . . . . . . . . . . . . . . . . . . . . 39
5.2.2
Propeller Angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.3
Left and Right Propeller State Equations
5.2.4
Rear Impeller Equation . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.5
Pitch Axis
5.2.6
Roll Axis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.7
Yaw Axis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.8
Vertical Translation
5.2.9
Lateral and Longitudinal Translation . . . . . . . . . . . . . . . . . 46
. . . . . . . . . . . . . . 41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
. . . . . . . . . . . . . . . . . . . . . . . . . . 46
Virtual Reality Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
xi
Contents
Contents
6 Control System
6.1
6.2
51
Classical Control (PID Controller) . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.1
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.2
Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.3
Controller Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
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
7.1
7.2
61
Signals, Hardware and Software . . . . . . . . . . . . . . . . . . . . . . . . 61
7.1.1
Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.1.2
Control Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1.3
Control Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
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
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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
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
CoG
CRO
CTOL
ECT
GUI
IMU
LiPo
LQR
MIMO
PWM
RC
RPM
SISO
SLA
USB
VR
VTOL
Centre of Mass
Centre of Gravity
Cathode Ray Oscilloscope
Conventional Take-Off and Landing
Enhanced Capture Timer
Graphical User Interface
Inertial Measurement Unit
Lithium Polymer
Linear Quadratic Regulator
Multiple Input Multiple Output
Pulse Width Modulation
Remote Control
Revolutions Per Minute
Single Input Single Output
Sealed Lead Acid
Universal Serial Bus
Virtual Reality
Vertical Take-Off and Landing
xix
List of Tables
List of Tables
Nomenclature
Attitude
Authority
Nacelle
Pitch
Propeller Pitch
Roll
Yaw
The position of an aircraft relative to a frame of reference, typically
the horizon or direction of motion.
The amount of control the aircraft provides over its degrees of
freedom.
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.
The up or down movement of the nose of an aircraft.
The distance a propeller will move forward in a perfect fluid
The rotation of an aircraft about its longitudinal axis, that is the
axis which runs along the length of the aircraft.
The left or right movement of the nose of the aircraft
xx
List of Tables
List of Tables
Roman Symbols
a
A
E
f
F
J
J
p
r
T
T
v
y
Acceleration (ms−2 )
Area (m2 )
Young’s Modulus of Elasticity (GP a)
Frequency (Hz)
Force (N )
Moment of Inertia (kg.m2 )
Advance Ratio
Pitch Angle (radians)
Roll Angle (radians)
Thrust (N )
Period (s)
Velocity (ms−1 )
Yaw Angle (radians)
Greek Symbols
τ
φ
ω
ρ
σ
θ
Moment (N.m)
Propeller Pitch Angle (radians)
Angular Velocity (radians.s−1 )
Density (kg.m3 )
Tensile Stress (M P a)
Propeller Angular Position (radians)
Note: ẋ indicates the temporal derivative
dx
dt
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
1.3
Chapter 1. Introduction
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
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
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
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
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
2.3. Previous Tilt-Rotor VTOL RC Aircraft
Figure 2.6: Larry’s V-22 Model
10
2.4. Control Techniques
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
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
Impeller Model
Rotor Diameter
Blades
Weight
Max Static Thrust
Cost (RRP approx $AUD)
WeMoTec
HW730
HW750
105mm
124mm
7
7
148g
185g
25N (20 cells) 35N (32 cells)
$215
$250
14
Schubeler
DS-51-DIA
90mm
4
48g
33N (30 cells)
$380
3.1. F-35 Joint Strike Fighter
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
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
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
Diameter
Pitch
Max Static Thrust
Voltage at Max Thrust
3.2.2
16”
10”
38N
29.8V
APC
17”
13”
44.1N
25.6V
20”
10”
54N
27.4V
CAM
13”
14”
20”
7”
9.5”
12”
28N
30N
31N
10.4V 11.5V 11.5V
Menz S
18”
20”
10”
10”
44.1N 47.1N
26.2V 23.7V
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
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 counterrotating 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.1.2
4.2. Frame Design
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
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
6060 T4 Aluminium
Balsa Wood
Birch Wood
Carbon Fibre Tube
Foamed Polymer
Density
(kg/m3 )
2710
110 - 150
500 - 700
1500 - 1600
50 - 77
ρ
Young’s
Modulus
E(GP a)
70
2.6 - 3.5
4.5 - 10.3
60 - 160
0.0034 - 0.032
Ultimate Tensile
Strength σut (M P a)
160
10 - 12
27 - 40
300 - 800
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
4.2. Frame Design
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
4.2. Frame Design
Figure 4.3: Internal Motor Concept
Figure 4.4: Final Motor Rotation Configuration
23
4.2. Frame Design
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
4.2. Frame Design
Figure 4.6: First Frame Concept
25
4.2. Frame Design
Figure 4.7: Redesigned Frame Concept
26
4.2. Frame Design
Figure 4.8: Final Frame Concept Sketch
27
4.2.5
4.3. Propulsion
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
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
4.3. Propulsion
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 =P
2
3
i0
1
ρπD2
2
1
3
(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. Propulsion
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
4.3. Propulsion
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
4.3. Propulsion
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
4.3. Propulsion
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
Characteristic
Voltage (V )
Capacity (mAh)
Weight (g)
Gravimetric Energy
Density (W h/kg)
NiCd
9.6
12
2400 2400
495
670
Battery Type
NiMH
8.4
12
12
7.4
3000 1000 3000 1700
442
205
600
82
45-80
60-120
LiPo
11.1
2250
150
11.1
3600
302
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 inground effects in the confined area of testing and motor losses.
34
4.3. Propulsion
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
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
45
approximately 750
= 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
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 gyrostabilised 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
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
4.5.1
Actuators
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
5.2.1
State Equations
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 non39
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
2
is proportional to angular velocity squared (θ˙i ). We assume that lift can be approximated
as a linear function of angular velocity when near the angular velocity required for hover.
Hence:
θ̇i2 ≈ θ̇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
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 (θ̇M m )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
La ia + Ra ia = 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:
Ra ia = Va − ke θ̇m
(5.4)
Combining Equations 5.2 and 5.4 yields:
kT ke
kT
+ kD θ̇m,0 )θ̇m =
Va
Ra
Ra
(5.5)
kT ke
kT
Va − (bm +
+ kD θ̇m,0 )θ̇m
Ra
Ra
(5.6)
Jm θ̈m + (bm +
Jm θ̈m =
Equation 5.6 can be written for each propeller:
θ̈L =
θ̈R =
where Kmp = bm +
kT ke
Ra
1
Jprop
1
Jprop
kT
VL − Kmp θ̇m
Ra
!
kT
VR − Kmp θ̇m
Ra
+ kD θ̇m,0
42
(5.7)
!
(5.8)
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 ke
(bB +
+ kD,rear θ̇B,0 )θ̇B
kB
RB
VB = KB θ˙B
where:
KB =
5.2.5
kB ke
RB
(bB +
+ kD,rear θ̇B,0 )
kB
RB
(5.9)
(5.10)
(5.11)
Pitch Axis
Taking the torque balance about the pitch axis, the following expression can be derived:
Jp p̈ ≈ l1 (FL + FR ) − l2 Fb
(5.12)
Therefore:
p̈ =
l1
l2
(FL cos φL + FR cos φR ) − FB
Jp
Jp
(5.13)
Simplifying by applying trigonometric linearisation:
p̈ =
l1
l2
l1 Kprop
l2 Krear
(FL + FR ) − FB ≈
(VL + VR ) −
VB
Jp
Jp
Jp
JP
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
(5.14)
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.
T
Kprop = Rklaθ̇K0 kmp
is the approximated (linearised) lift supplied by the propellers for a given
input voltage.
Krear =
kl,rear θ̇0,B
KB
is 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:
Jr r̈ ≈ l3 (Fl − Fr )
(5.15)
Therefore:
r̈ =
l3
(FL cos φL − FB cos φR )
Jr
(5.16)
Simplify by applying trigonometric linearisation:
r̈ =
l3
l3 Kprop
(FL − FR ) =
(VL − VR )
Jr
Jr
(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.
T
Kprop = Rklaθ̇K0 kmp
is 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:
Jy ÿ ≈ l3 (FL,yaw + FR,yaw ) + τL − τR + τB
ÿ =
l3
KD,prop
KD,rear
(FL sin φL − FR sin φL ) +
(VL − VR ) +
VB
Jy
Jy
Jy
(5.18)
(5.19)
ÿ =
1
(l3 (FL φL + FR φR ) + KD,prop (VL − VR ) + KD,rear VB )
Jy
(5.20)
This can be approximated by:
ÿ =
1
(l3 Kprop (VL φL + VR φR ) + KD,prop (VL − VR ) + KD,rear VB )
Jy
(5.21)
This is linearised by removal of the multiplication between the input voltage and propeller
angle.
ÿ =
1
(l3 Kprop (Vhov φL + Vhov φR ) + KD,prop (VL − VR ) + KD,rear VB )
Jy
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
(5.22)
T
Kprop = RkAl θ̇K0 kmp
is the approximated lift supplied by the propellers (at hover angular
velocity) for a given motor input voltage.
kT
KD,prop = RkDAθ̇K0 mp
is the torque constant that relates the torque generated by the propeller
when a voltage is applied to the motor.
k
θ̇ k
0 T
KD,rear = D,rear
is the torque constant that relates the torque generated by the rear
RA Kmp
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̈ =
X
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̈ = Kprop VL + Kprop VR + Krear VB − W
(5.24)
MP z̈ = Kprop (VL + VR ) + Krear VB − W
5.2.9
(5.25)
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
MP ẍ =
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.3
(5.29)
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 (VRealm 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
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
Figure 5.4: V-22 Osprey Model in V-Realm Builder
Figure 5.5: Final V-22 Osprey VR Model
49
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
6.1.1
Classical Control (PID Controller)
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
+ KD s
s
(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
+ KTD s
TI s
(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
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
6.2.1
State Space Control
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
53
(6.3)
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
0
0
0
1
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
1
0
0
0
0
0
0
0
0
0
0
l1 Kprop
Jp
−Kmp
Jprop
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


k
T

 Ra Jprop


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
l3 Kprop
Jr
0
0
0
0
0
0
0
Kprop
Mp
0
0
0
l1 Kprop
Jp
0
−l3 Kprop
Jr
0
0
0
−Kmp
Jprop
0
0
0
0
0
Kprop
Mp
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
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
KD,rear
l3 Kprop Vhov
Jy
−l3 Kprop Vhov
Jy
0
0
0
−l2 Krear
Jp
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
kT
Ra Jprop
0
0
0
0
0
0
0
0
0
0
0
0
Kprop Vhov
Mp
Kprop Vhov
Mp
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
−Krear
Mp
55
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0












































y
ẏ
p
ṗ
r
ṙ
θL
θ˙L
θR
θ˙R
X
Ẋ
Y
Ẏ
Z
Ż






















+


































































VL
VR
VB
φL
φR











(6.5)
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









































Kd
=


0



0



0




0



0

 kt
 R J
 a pr
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
1
0
0
0
0
0
0
0
Kprop
Mp
l1 Kprop
Jp
l3 Kprop
Jr
−Kmp
Jpr
Kprop
Mp
l1 Kprop
Jp
−l3 Kprop
Jr
0
−Kmp
Jpr
l3 Kp Vhov
Jy
−l3 Kp Vhov
Jy
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
−Kd Kd,rear
0
0
0
0
0
0
kt
Ra Jpr
0
0
−Kr
Jp
−l2 Kr
Jr
56
0




















ẏ
p
r
Ż
ṗ
ṙ
θ̇L
θ˙R

VL
VR
VB
φL
φR










+







































(6.6)









ẏ
p
r
Ż
















=
1
0
0
0
0
1
0
0
0
0
1
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
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.







ẋ
A
Amu   xm   Bm 
 m  =  mm
+
u
xu
ẋu
Aum Auu
Bu
(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 = f1s ) 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
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
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
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
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
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 StateSpace 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
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 semiunidirectional 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
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
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 realtime 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
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 ‘zplane’ 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
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
8.2
Chapter 8. Testing and Tuning
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
8.3
8.3. Untethered Testing
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
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
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
Plettenberg 220/30/A3 P4 5:1 Brushless Motor
80 Amp Hyperion Brushless ESC
Tanic-3S2P 2450 mAh 11.1 V LiPo
7.4V 1800mAh LiPo
LiPo Charger
Deep Cycle 12 Volt Lead Acid Battery
Lead-Acid Battery Charger
MiniDRAGON+ plus comm upgrade
PicoPic plus upgrades
Free2Move RS-232 Bluetooth Dongles
3DM-GX1 IMU
Wemotec Ducted MicroFan
Hyperion 20Amp ESC
Himax 2025 4100 Brushless Motor
Hyperion e-Meter
APC 20 x 10” Propeller Pusher Tractor Pair
Frame Materials + Construction
Cabling
Total (incl GST)
Quantity
2
2
8
1
1
1
1
1
1
2
1
1
1
1
1
1
1
1
Item Cost
$444.98
$168.00
$118.00
$40.80
$200.00
$100.00
$75.00
$174.00
$87.60
$182.50
$2500.00
$30.00
$87.40
$69.95
$138.00
$115.00
$300.00
$100.00
Total
$889.96
$336.00
$944.00
$40.80
$200.00
$100.00
$75.00
$174.00
$87.60
$365.00
$2500.00
$30.00
$87.40
$69.95
$138.00
$115.00
$300.00
$100.00
$6552.71
Table 9.2: Estimated Student Labour Costs
Student
Zebb Prime
Jesse Sherwood
Michael Smith
Allan Stabile
Total
Hours
567.5
292
407
400.5
1667
Salary
$14,551
$7,487
$10,436
$10,269
$42,744
Direct Costs
$4,365
$2,246
$3,131
$3,081
$12,823
84
Indirect Costs
$18,917
$9,733
$13,567
$13,350
$55,567
Total
$37,833
$19,467
$27,133
$26,700
$111,133
9.2. Weight
Table 9.3: Weight Budget
Item
Frame
Aluminium Frame
Rear Arm
Wing Arms
Wing Arm Bearings
Motor Mounts
Assorted Screws
Sensors
3DM-GX1 IMU
Actuators
NES-579 JR Servo with mount
E381 Servo with mount
Controllers
MiniDRAGON+
PicoPic
Propulsion
Motors - Plettenberg 220/30/A3 P4 5:1
Propellers
Propeller Adaptor
ESC Hyperion 80 A Brushless
WeMoTec Ducted Fan
Himax 2025 4100 Brushless Motor
20 Amp Hyperion ESC
Batteries
Tanic-3S2P 2450 mAh 11.1 V LiPo
7.4 V 1800mAh LiPo
Miscellaneous
Cabling∗
Landing Gear
Bluetooth Dongle
Total
∗Estimated
85
Quantity
Weight (g)
Total (g)
1
1
2
2
2
20
400
110
110
60
100
3
400
110
220
120
200
60
1
75
75
4
3
48
29
192
87
1
1
50
14
50
14
2
2
2
2
1
1
1
225
190
40
45
30
61
21
450
380
80
90
30
61
21
5
1
172
82
860
82
1
1
1
300
30
50
300
30
50
3952
9.3
9.3. Power Budget
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
Servo Motors
PicoPic
MiniDRAGON+
3DM-GX1 IMU
Bluetooth RS-232 Dongle
TOTAL (mA)
Battery
7.4 V 1800 mAh LiPo
Current Draw (mA)
130
14
85
65
70
Quantity
6
1
1
1
1
Capacity (mAh)
1800
Surge Current (A)
12
Total
780
14
85
65
70
1014
Discharge Time (min)
106.5
Table 9.5: Motor Power Budgets
Motor
Plettenberg @ 100%
Plettenberg @ 75%
Himax @ 100%
Current
Draw (A)
31
25
10
Battery
Battery
Capacity (mAh)
2xTanic LiPo
2xTanic LiPo
Tanic LiPo
4900
4900
2450
86
Battery
Surge
(A)
58
58
24
Discharge
Time (min)
8.9
11.76
14.7
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
10.5. Electrical Noise
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
11.1.3
Chapter 11. Discussion and Future Work
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 nonlinear 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 statespace 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
11.2. Future Tasks
During the control development, while the controller was run from the dSPACE DS1104 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 DS1104 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
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
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-002
VTOL-05-003
VTOL-05-004
VTOL-05-005
VTOL-05-006
VTOL-05-007
VTOL-05-008
VTOL-05 Frame
Main Chassis
Main Chassis Parts
Assembled Wing Arm
Assembled Wing Arm Parts
IMU Cradle
IMU Cradle Parts
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
REV
REVISION HISTORY
DESCRIPTION
DATE
ALL TOLERANCES +/- 0.5MM OR +/- 1°
UNLESS OTHERWISE SPECIFIED
ALL DIMENSIONS IN MILLIMETERS
APPROVED
TITLE
VTOL-05 Frame
FILE NAME: VTOL-05-001.dft
SIZE
A3
SCALE:
DWG NO
VTOL-05-001
WEIGHT:
DRAWN a1078621
27/10/05
CONTACT zebb.prime@student.adelaide.edu.au
REV CHECKED
1 ENG APPR
MGR APPR
SHEET 1 OF 2
945
420
300
220
3
1
2
2
60
1
1
94
260
1154
REV
REVISION HISTORY
DESCRIPTION
DATE
Item Number
TITLE
VTOL-05 Frame
SIZE
A3
SCALE:
DWG NO
Quantity
VTOL-05-002
Main Chassis
1
2
VTOL-05-004
Assembled Wing Arm
2
3
VTOL-05-006
IMU Cradle
1
VTOL-05-001
WEIGHT:
Title
1
APPROVED
Document
Number
DRAWN a1078621
27/10/05
REV CHECKED
1 ENG APPR
MGR APPR
SHEET 2 OF 2
4
12
8
1
7
9
11
6
10
5
2
13
3
Item Number
REV
ASSEMBLY NOTE:
PLEASE WELD ALL COMPONENTS AS APPROPRIATE
Document
Number
Title
Quantity
1
VTOL-05-003
Rear Servo Mount (for elevators
and 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 Cantilever
Arm
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 (Left)
1
REVISION HISTORY
DESCRIPTION
DATE
DETAIL A
Flatten tube to
accept rear fan mount
DETAIL B
B
A
106.5
265
420
APPROVED
TITLE
Main Chassis
SIZE
DWG NO
A3
SCALE:
1:5
DRAWN a1078621
27/10/05
REV CHECKED
VTOL-05-002
1 ENG APPR
MGR APPR
WEIGHT: 279g+welds SHEET 1 OF 1
36.5
3
O 3.5
33.5
13.5
246.5
23
8x M3
100
420
1.5 THICK
O 3.5
O
4. 5
45 °
37
47
REAR SERVO MOUNT (FOR RUDDER AND ELEVATOR CONTROL)
QUANTITY: 1
SCALE: 1.5:1
MATERIAL: 3MM ALUMINIUM
REV
DATE
148.5
19.5
2.5
14.5
7.5
3
REVISION HISTORY
DESCRIPTION
173.5
4x O 3
APPROVED
TITLE
Main Chassis Parts
4.5
13
12
20
MAIN FRAME - LEFT STRUT
QUANTITY: 1
SCALE: 1:2
MATERIAL: 20x12x1.5 UNEQUAL ANGLE ALUMINIUM
DRAWN a1078621
27/10/05
REV CHECKED Jesse Sherwood
SIZE DWG NO
VTOL-05-003
A3
1 ENG APPR
SCALE: -
WEIGHT: -
SHEET 1 OF 5
MGR APPR
36.5
20
12
12
O
20
3.5
1.5
1.5
47
4.5
10
3.5
42
47
O
94
383.5
94
420
O
42
1.5 THICK
148.5
173.5
45 °
MAIN FRAME - FRONT STRUT
QUANTITY: 1
SCALE: 1:1
4.5
13
12
20
MAIN FRAME - RIGHT STRUT
QUANTITY: 1
SCALE: 1:2
REV
REVISION HISTORY
DESCRIPTION
45 °
4 5°
4.5
DATE
APPROVED
TITLE
Main Chassis Parts
MAIN FRAME - REAR STRUT
QUANTITY: 1
SCALE: 1:1
SIZE
A3
SCALE: -
DWG NO
VTOL-05-003
WEIGHT: -
DRAWN a1078621
27/10/05
1 ENG APPR
MGR APPR
SHEET 2 OF 5
4x O 3.5
2x O 4.5
10.5
3
30.5
1
260
40
60
2
5
10
7.5
3
12.5
47
22.5
5
55
35
5
5
30
SERVO ARM HOLDER
QUANTITY: 1
SCALE: 1:2
NOTES: TOP ARM BASE SUPPORTED BY BEARINGS AND NOT
ATTACHED TO LOWER PIECES
REV
REVISION HISTORY
DESCRIPTION
DATE
PART 2
PART 1
LEFT SERVO BRACKET
QUANTITY: 1
SCALE 1:1
NOTES: RIGHT BRACET DIMENSION SAME
APPROVED
TITLE
Main Chassis Parts
RIGHT SERVO BRACKET
QUANTITY: 1
SCALE 2:1
NOTES: DIMESIONS THE SAME AS LEFT
BRACKET, JUST MIRRORED (SEE LEFT)
SIZE
A3
SCALE: -
DWG NO
VTOL-05-003
WEIGHT: -
PART 3
ARM HOLDER BASE
QUANTITY: 2
SCALE: 1:2
NOTES: ONE FOR THE TOP AND ONE
FOR THE BOTTOM AS SHOWN
DRAWN a1078621
27/10/05
1 ENG APPR
MGR APPR
SHEET 3 OF 5
INTERNAL R 26
260
10
15
HOLE THROUGH BOTH
TO ACT AS A CLAMP
3
30
REAR DUCTED FAN MOUNT
QUANTITY: 1
SCALE: 1:1
MATERIAL: ALUMINIUM
NOTES: ROUND CLAMP SECTION TO BE MADE FROM ROLLED 2MM
ALUMINIUM STRIPPING
REV
REVISION HISTORY
DESCRIPTION
DATE
TOP BEARING BASE
QUANTITY: 1
SCALE: 1:2
APPROVED
TITLE
Main Chassis Parts
SIZE
A3
SCALE: -
DWG NO
VTOL-05-003
WEIGHT: -
DRAWN a1078621
27/10/05
1 ENG APPR
MGR APPR
SHEET 4 OF 5
2X
5
4X
5
10
7.6
O3
O
30
3
3
12
25
5
4xM3
460
R5
30
38.5
12
1
37
R6
R6
12
5
R5
12
25
5
7
17
94
3.5
5
1
O
20
ID
3
O
OD
10
47
REAR CANTILEVER ARM
QUANTITY: 1
SCALE: 1:5
MATERIAL: STANDARD OD 10MM ALUMINIUM TUBE
REV
REVISION HISTORY
DESCRIPTION
DATE
AILERON SERVO MOUNT
QUANTITY: 1
SCALE: 1:1
APPROVED
TITLE
Main Chassis Parts
REAR ARM CONNECTING BRACKET
QUANTITY: 1
SCALE 2:1
MATERIAL: ALUMINUM
REAR SERVO CONNECTING BRACKET
QUANTITY: 1
SCALE 2:1
MATERIAL: ALUMINIUM
SIZE
A3
SCALE: -
DWG NO
VTOL-05-003
WEIGHT: -
DRAWN a1078621
27/10/05
1 ENG APPR
MGR APPR
SHEET 5 OF 5
3
2
4
5
A
7
6
1
Item Number
DETAIL A
REV
REVISION HISTORY
DESCRIPTION
DATE
TITLE
Assembled Wing Arm
SIZE
DWG NO
A3
SCALE: 1:2
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
APPROVED
Document
Number
2
DRAWN a1078621
27/10/05
REV CHECKED
VTOL-05-004
1 ENG APPR
MGR APPR
O
ID
12
O
16
5
10
2.5
5
3
OD
M2
M2 FOR GRUB SCREW
NOTE: 45v OFFSET FROM OTHER HOLES
475
O 16.25
O
+0.25
0
22
45°
O 30
4x M2.5
12
O 20
3
90
°
O
25
+0.
0
5
16.2
WING ARM
QUANTITY: 2
SCALE: 1:3
NOTES: 1 FOR EACH ASSEMBLED WING ARM
REV
REVISION HISTORY
DESCRIPTION
ARM COLLAR AND SERVO HUB
QUANTITY: 2
SCALE: 2:1
MATERIAL: ALUMINIUM
DATE
WING ARM WASHER
QUANTITY: 2
SCALE: 3:1
MATERIAL: ALUMINIUM
APPROVED
TITLE
SIZE
A3
SCALE: -
DWG NO
VTOL-05-005
WEIGHT: -
DRAWN a1078621
27/10/05
REV CHECKED
1 ENG APPR
MGR APPR
SHEET 1 OF 2
10
45 °
O
26
40
O2
0
30
4xM3
5
O 22
30
5
4xM3
5
10.5
35
O 16
.25
10
4.5
2.5
5
2.5
26
10
10.5
10
O
16
28
60
16
O
12
4xO3
ACRYLIC ARM BEARING BLOCK
QUANTITY: 2
SCALE: 1:1
MATERIAL: ACRYLIC
NOTES: 1 FOR EACH WING ARM
RECESSES MACHINED TO FIT STANDARD
ID16x16 ROLLER BEARINGS
REV
REVISION HISTORY
DESCRIPTION
DATE
WING ARM MOTOR MOUNT
QUANTITY: 2
SCALE: 2:1
MATERIAL: ALUMINIUM
APPROVED
TITLE
WING ARM PLUG
QUANTITY: 2
SCALE: 2:1
MATERIAL: ALUMINIUM
SIZE
A3
SCALE: -
DWG NO
VTOL-05-005
WEIGHT: -
DRAWN a1078621
27/10/05
REV CHECKED
1 ENG APPR
MGR APPR
SHEET 2 OF 2
AS APPROPRIATE
BOTTOM ONLY
94
AS APPROPRIATE
AS APPROPRIATE
BOTTOM ONLY
1
AS APPROPRIATE
2
240
5
3
76.5
4
NOTES:
ALL PARTS EXCEPT GIMBLE EXTENDER TO BE WELDED ON AS APPROPRIATE/SHOWN
Item Number
REV
Document
Number
Title
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
REVISION HISTORY
DESCRIPTION
DATE
6.5
Quantity
5
APPROVED
TITLE
DWG NO
IMU Cradle
SIZE
SCALE: 1:2
A3
DRAWN a1078621
27/10/05
REV CHECKED
VTOL-05-006
1 ENG APPR
MGR APPR
12
20
1.5
12
1.5
12
20
20
32
32
1.5
240
156
156
47
94
240
O
6 .5
45 °
45 °
45 °
8.25
8.25
5.5
5.5
IMU CRADLE - LEFT STRUT
QUANTITY: 1
SCALE: 1:2
IMU CRADLE - REAR STRUT
QUANTITY: 1
SCALE: 1:1
REV
REVISION HISTORY
DESCRIPTION
DATE
IMU CRADLE - RIGHT STRUT
QUANTITY: 1
SCALE: 1:2
APPROVED
TITLE
IMU Cradle Parts
SIZE
A3
SCALE: -
DWG NO
VTOL-05-007
WEIGHT: -
DRAWN Jesse Sherwood
27/10/05
CONTACT jesse.sherwood@student.adelaide.edu.au
REV CHECKED
1 ENG APPR
MGR APPR
SHEET 1 OF 2
O
O
10
6 .5
7.6
O
O
10
2x O
4.5
10
25
M6
50
75
76
20°
1
rox
App
Approx 25
Approx 36
Approx 22
10
94
M6
IMU CRADLE - UPRIGHT
QUANTITY: 4
SCALE: 2:1
REV
REVISION HISTORY
DESCRIPTION
GIMBLE-IMU MOUNT
QUANTITY: 1
SCALE 1:1
MATERIAL: 3mm ALUMINIUM
NOTES: DISTANCE BETWEEN HOLES IS IMPORTANT
GIMBLE EXTENDER
QUANTITY: 1
SCALE: 2:1
MATERIAL: STEEL
NOTES: CONFIRM BOTTOM THREAD SIZE BEFORE
SUMBISSION
DATE
APPROVED
TITLE
IMU Cradle Parts
SIZE
A3
SCALE: -
DWG NO
VTOL-05-007
WEIGHT: -
DRAWN Jesse Sherwood
27/10/05
CONTACT jesse.sherwood@student.adelaide.edu.au
REV CHECKED
1 ENG APPR
MGR APPR
SHEET 2 OF 2
Item Number
4xO3.5
18
13
50
32
8
O1
Document
Number
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 Nylon
Propeller
1
4
VTOL-05-008
Propeller Adapter Upper Collar
1
5
------------
M8 Fibre Lock Nut
1
1
3
13
20
23
5
46
4
3
50
75
10.5
50
3
30
40.5
2
3
10.5 9.5
3
40
APC PROPELLER ADAPTER
QUANTITY: 2
SCALE: 2:1
MATERIAL: STEEL
NOTE: PARTS ON THE FOLLOWING PAGE
PLETTENBERG MOTOR MOUNT
QUANTITY: 2
SCALE: 1:1
MATERIAL: ALUMINIUM
NOTE: TO BE WELDED TOGETHER FROM 3MM ALUMINIUM
REV
REVISION HISTORY
DESCRIPTION
DATE
APPROVED
TITLE
SIZE
A3
SCALE:
DWG NO
VTOL-05-008
WEIGHT:
DRAWN a1078621
27/10/05
REV CHECKED
1 ENG APPR
MGR APPR
SHEET 1 OF 2
O
44
M 4
M8
O
14
O
25
8.2
2
O
5.9
O1
O 17.8
O8
PROPELLER ADAPTER SHAFT
QUANTITY: 2
SCALE: 2:1
MATERIAL: STEEL
NOTE: ONE FOR EACH MOTOR
REV
1.5
1.5
O 6
REVISION HISTORY
DESCRIPTION
3.4
5.3
17
23
M 4
63
40
O8
PROPELLER ADAPTER UPPER COLLAR
QUANTITY: 2
SCALE: 2:1
MATERIAL: STEEL
PROPELLER ADAPTER LOWER COLLAR
QUANTITY: 2
SCALE: 2:1
MATERIAL: STEEL
DATE
APPROVED
TITLE
SIZE
A3
SCALE:
DWG NO
VTOL-05-008
WEIGHT:
DRAWN a1078621
27/10/05
REV CHECKED
1 ENG APPR
MGR APPR
SHEET 2 OF 2
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.
clc
close all
clear all
disp('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 propcalc
kl = 0.7;
% coefficient of lift for props
klrear = 0.5;
% coefficient of lift for rear fan
ke = kt;
%back emf constant = torque const in SI units
Kmp = ((.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 Testing
thr = 2.5*9.81;
Kp = thr/10;
Kr = .15/10;
% from full power thrust test on 12V battery 49N for both props;
% N x volt Front Props;
% 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
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
1
0
0
0
0
0
0
0
0
0
0
0
Zd
Zd
-Pd
-Pd
-Rd
Rd
-Kmp/Jpr 0
0 -Kmp/Jpr ]
disp('State input matrix')
disp('Command states are: [Dl, Dr, Db, phi_L, phi_R]')
%
Vl
Vr
Vb
phi L
Bm=[
Kd
-Kd
Kdr
l3*Kp*Vhov/Jy
0
0
0
0
0
0
0
0
0
0
-Kr/Mp
0
0
0
l2*Kr/Jp
0
0
0
0
0
kt/(Ra*Jpr)
0
0
0
0
kt/(Ra*Jpr)
0
0
%
%
%
%
%
%
%
%
*
*
*
*
*
*
*
*
y_dot
p
r
Z_dot
p_dot
r_dot
theta_L_dot
theta_R_dot
phi R
-l3*Kp*Vhov/Jy
0
0
0
0
0
0
0
]
%
%
%
%
%
%
%
%
=
=
=
=
=
=
=
=
y_ddot
p_dot
r_dot
Z_ddot
p_ddot
r_ddot
theta_L_ddot
theta_R_ddot
%State output vector
% y
Cm = [1
0
0
0
p
0
1
0
0
r
0
0
1
0
X
0
0
0
1
Z
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
];
%Feedforward term
Dm = [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 Matrix
A_augmented = [Am, zeros(8,4); Cm, zeros(4,4)];
% State input matrix
B_augmented = [ Bm; zeros(4,5)];
% Also define an alternative input vector to allow us to input the desired
% setpoints
B_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 vector
C_augmented = [Cm, zeros(4,4)];
% Feedforward term
D_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 controllability
Co = ctrb(osprey_model);
cond(Co);
% Check observability
Ob = obsv(osprey_model);
cond(Ob);
unco = length(Am)-rank(Co);
unob = length(Am)-rank(Ob);
% number of uncontrollable states
% 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 gains
K = lqr(A_augmented,B_augmented,q,r);
Km = K(:,1:8)
% These are the usual feedback gains
Ki = K(:,9:12)
% These are the feedback gains for the augmented states
% The closed loop system with full state feedback is
C_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 response
figure
step(osprey_model_full)
title('Closed loop step response with full state feedback');
% The closed loop augmented system with full state feedback and command following is
C_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 response
figure
step(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 Observer
for i = 1:4
for j = 1:4
Aaa(i,j) = Am(i,j);
Ba(i,j) = Bm(i,j);
end
end
for i = 5:8
for j = 1:4
Aba(i-4,j) = Am(i,j);
Bb(i-4,j) = Bm(i,j);
end
end
for i = 1:4
for j = 5:8
Aab(i,j-4) = Am(i,j);
end
end
for i = 5:8
for j = 5:8
Abb(i-4,j-4) = Am(i,j);
end
end
Qob = diag([1 1 1 1]); % Q matrix for kalman filter
Rob = diag([1 1 1 1]); % R matrix for Kalman filter
G = 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 model
Ar = 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 system
disp('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)
figure
step(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 term
Statenames = 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 earlier
system_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 states
system_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 estimator
con1 = [11, 1, 0; 12, 2, 0; 13, 3, 0; 14, 4, 0];
% The connection from the control gain and augmented states to the estimator
con2 = [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 input
con3 = [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];
OUTPUTS = [1,2,3,4];
% The inputs to the system are the four setpoints
% 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 voltage
D_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_complete
figure
step(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
#include
#include
#include
<mc9s12dp256.h>
"pll.h"
"timer.h"
"ControlSystem.h"
/* derivative information */
/* defines _BUSCLOCK, sets bus frequency to _BUSCLOCK
MHz */
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 = {
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
/* Interrupt
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
/* vector
table */
63 : (reserved) */
62 : (reserved) */
61 : (reserved) */
60 : (reserved) */
59 : (reserved) */
58 : (reserved) */
57 : PWM emergency shutdown */
56 : PORT P */
55 : MSCAN4 - transmit */
54 : MSCAN4 - receive */
53 : MSCAN4 - errors */
52 : MSCAN4 - wakeup */
};
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
SCI1_TDRE_ISR,
SCI0_RIE_ISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
TOC7_ISR,
TIC6_ISR,
TIC5_ISR,
TIC4_ISR,
TIC3_ISR,
TIC2_ISR,
TIC1_ISR,
TIC0_ISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
UnimplementedISR,
_Startup
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
vector
42
41
40
39
38
37
36
35
34
33
32
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
09
08
07
06
05
04
03
02
01
00
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
MSCAN1 - receive */
MSCAN1 - errors */
MSCAN1 - wakeup */
MSCAN0 - transmit */
MSCAN0 - receive */
MSCAN0 - errors */
MSCAN0 - wakeup */
FLASH */
EEPROM */
SPI2 */
SPI1 */
IIC bus */
DLC */
SCME */
CRG lock */
Pulse accumulator B overflow */
Modulus down counter underflow */
PORT H */
PORT J */
ATD1 */
ATD0 */
SCI1 (TIE, TCIE, RIE, ILIE) */
SCI0 (TIE, TCIE, RIE, ILIE) */
SPI0 */
Pulse accumulator input edge */
Pulse accumulator A overflow */
Timer Overflow (TOF) */
Timer channel 7 */
Timer channel 6 */
Timer channel 5 */
Timer channel 4 */
Timer channel 3 */
Timer channel 2 */
Timer channel 1 */
Timer channel 0 */
Real-Time Interrupt (RTI) */
IRQ */
XIRQ */
SWI */
Unimplemented Instruction trap */
COP failure reset*/
Clock monitor fail reset */
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>
#include <mc9s12dp256.h>
#include "pll.h"
/* common defines and macros */
/* 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;
REFDV = 0x01;
#else
SYNR = 0x00;
REFDV = 0x00;
#endif
// PLLOSC = 48 MHz
// PLLOSC = 32 MHz
/* 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
Bit 7: PLLSEL
Bit 6: PSTP
Bit 5: SYSWAI
But 4: ROAWAI
Bit 3: PLLWAI
Bit 2: CWAI
Bit 1: RTIWAI
Bit 0: COPWAI
*/
CLKSEL:
= 0 Keep using OSCCLK until we are ready to switch to PLLCLK
= 0 Do not need to go to Pseudo-Stop Mode
= 0 In wait mode system clocks stop.
= 0 Do not reduce oscillator amplitude in wait mode.
= 0 Do not turn off PLL in wait mode
= 0 Do not stop the core during wait mode
= 0 Do not stop the RTI in wait mode
= 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
But
Bit
Bit
Bit
Bit
5:
4:
3:
2:
1:
0:
AUTO
ACQ
PRE
PCE
SCME
= 0; No automatic control of bandwidth, manual through ACQ
= 1; 1 for high bandwidth filter (acquisition); 0 for low (tracking)
(Not Used by 9s12c32)
= 0; RTI stops during Pseudo Stop Mode
= 0; COP diabled during Pseudo STOP mode
= 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
extern
extern
extern
extern
extern
extern
// PWM input variables, range: 0-1
float
float
float
float
float
float
float
__interrupt
__interrupt
__interrupt
__interrupt
__interrupt
__interrupt
__interrupt
__interrupt
PWM_Capture_Ch0;
PWM_Capture_Ch1;
PWM_Capture_Ch2;
PWM_Capture_Ch3;
PWM_Capture_Ch4;
PWM_Capture_Ch5;
PWM_Capture_Ch6;
void
void
void
void
void
void
void
void
TOC7_ISR(
TIC6_ISR(
TIC5_ISR(
TIC4_ISR(
TIC3_ISR(
TIC2_ISR(
TIC1_ISR(
TIC0_ISR(
void
void
void
void
void
void
void
void
);
);
);
);
);
);
);
);
// Interrupt Service Routines for timer channels.
/* ----------------------------------------------------------------------------------------------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
*/
// Derivative information
// Constants that define the operation
#define timerOffset 37500
//
#define lowCount 1650
//
#define highCount 2850
//
#define validCount 3000
//
#define fullPeriodThreshold 3500
//
#define pwmInputScale 1200.0
//
#define pwmInputPeriod 33000
//
of the PWM and the timed interrupts.
Timer offset for 40Hz interupts
#Clock cycles for 1.1ms
#Clock cycles for 1.9ms
If greater than this ignore the value.
Threshold for low pwm
Input resolution, highCount - lowCount
Clock cycles per pwm input period
// Flag to begin control system computation
char controlSystemFlag;
// Variables containing the captured PWM signals. Vary from 0 to 1.
float
float
float
float
float
float
float
PWM_Capture_Ch0;
PWM_Capture_Ch1;
PWM_Capture_Ch2;
PWM_Capture_Ch3;
PWM_Capture_Ch4;
PWM_Capture_Ch5;
PWM_Capture_Ch6;
// Holding variables for the channels without buffered registers.
unsigned short first_Ch4;
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.
*
* \date 19/7/05
*/
void timer_Init( void ){
asm sei
TIOS = 0x80;
TCTL1 = 0x3F;
OC7M = 0x00;
TCTL3 = 0xFF;
TCTL4 = 0xFF;
ICOVW = 0xFF;
ICSYS = 0x0A;
//
//
//
//
//
//
//
TSCR2
TC7 =
TIE =
TSCR1
// PR = 32, reset on successful OC
// Offset for 40Hz interrupts
// Enable all interrupts
// Enable Timer
= 0x0C;
timerOffset;
0xFF;
= 0x80;
DDRB = 0xFF;
DDRH = 0xFF;
PWM_Capture_Ch0 =
PWM_Capture_Ch1 =
PWM_Capture_Ch2 =
PWM_Capture_Ch3 =
PWM_Capture_Ch4 =
PWM_Capture_Ch5 =
PWM_Capture_Ch6 =
PWM_Capture_flags
}
Ch7 = OC, Ch0-6 = IC
Disconnect pin 7
Don't affect any linked input pins
Detect on all edges
Detect on all edges
Only write to registers when they're empty
TFMOD, BUFEN
// Port B is output
// Port H is output
0.5;
0.5;
0.5;
0.5;
0.5;
0.5;
0.5;
= 0x00;
TFLG1 = 0xFF;
// Initially don't start computation
// 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.
*
* \date 19/7/05
*/
__interrupt void TOC7_ISR( void ){
if( timerDivider < 20 ){
timerDivider ++;
}else{
timerDivider = 0;
PTH ^= 0x08;
}
// Toggle PortH bit3
}
// 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.
*
* \date 19/7/05
*/
__interrupt void TIC0_ISR( void ){
unsigned short first;
unsigned short last;
PTH |= 0x02;
// Beginning of paylod
first = TC0H;
last = TC0;
// Read from registers
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;
return;
}
if( last < lowCount ){
// Test for lower limit
PWM_Capture_Ch0 = 0.0;
PTH &= 0xFD;
// End of payload
TFLG1 = 0x01;
return;
}
if( last > highCount ){
// Test for upper limit
TFLG1 = 0x01;
PTH &= 0xFD;
// End of Payload
return;
}
last = last - lowCount;
// Offset
PWM_Capture_Ch0 = ((float)last)/pwmInputScale;
}
PTH &= 0xFD;
TFLG1 = 0x01;
// End of payload
/**
*
*
* \date 19/7/05
*/
PTH |= 0x02;
first = TC1H;
last = TC1;
if( last > first ){
last -= first;
}else{
}
if( last > fullPeriodThreshold ){
}
PTH &= 0xFD;
TFLG1 = 0x02;
return;
}
PTH &= 0xFD;
TFLG1 = 0x02;
return;
}
TFLG1 = 0x02;
PTH &= 0xFD;
return;
}
// Detect if PWM high or low
// End of payload
// End of payload
// End of Payload
// Offset
}
PTH &= 0xFD;
TFLG1 = 0x02;
// End of payload
/**
*
*
* \date 19/7/05
*/
PTH |= 0x02;
first = TC2H;
last = TC2;
if( last > first ){
last -= first;
}else{
}
}
PTH &= 0xFD;
TFLG1 = 0x04;
return;
}
// End of payload
PTH &= 0xFD;
TFLG1 = 0x04;
return;
}
TFLG1 = 0x04;
PTH &= 0xFD;
return;
}
// End of payload
// End of Payload
// Offset
}
PTH &= 0xFD;
TFLG1 = 0x04;
// End of payload
/**
*
*
* \date 19/7/05
*/
PTH |= 0x02;
first = TC3H;
last = TC3;
if( last > first ){
last -= first;
}else{
}
}
PTH &= 0xFD;
TFLG1 = 0x08;
return;
}
PTH &= 0xFD;
TFLG1 = 0x08;
return;
}
TFLG1 = 0x08;
PTH &= 0xFD;
return;
}
// End of payload
// End of payload
// End of Payload
// Offset
}
PTH &= 0xFD;
TFLG1 = 0x08;
/**
// End of payload
*
* 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
*
* \date 19/7/05
*/
PTH |= 0x02;
// Beginning of Payload
if((PWM_Capture_flags & 0x10)==0){
first_Ch4 = TC4;
PWM_Capture_flags |= 0x10;
TFLG1 = 0x10;
PTH &= 0xFD;
// Capture first time
}else{
last = TC4;
PWM_Capture_flags &= 0xEF;
// Capture second time
// Set flag
// Clear Interrupt flag
// End of Payload
// Clear flag
if( last > first_Ch4 ){
last -= first_Ch4;
}else{
last = (first_Ch4 - last) + timerOffset;
}
if( last > fullPeriodThreshold ){ // Detect if PWM high or low
}
PTH &= 0xFD;
// End of payload
TFLG1 = 0x10;
return;
}
PTH &= 0xFD;
// End of payload
TFLG1 = 0x10;
return;
}
TFLG1 = 0x10;
PTH &= 0xFD;
// End of Payload
return;
}
// Offset
}
}
PTH &= 0xFD;
TFLG1 = 0x10;
// End of payload
/**
*
*
* \bugs Doesn't work due to the issues outlined in bug report at the top of
*
the file.
*
* \date 19/7/05
*/
PTH |= 0x02;
first_Ch5 = TC5;
TFLG1 = 0x20;
PTH &= 0xFD;
}else{
last = TC5;
PWM_Capture_flags &= 0xDF;
// Set flag
// End of Payload
// Clear flag
last -= first_Ch5;
}else{
}
}
PTH &= 0xFD;
TFLG1 = 0x20;
return;
}
PTH &= 0xFD;
TFLG1 = 0x20;
return;
}
TFLG1 = 0x20;
PTH &= 0xFD;
return;
}
// End of payload
// End of payload
// End of Payload
// Offset
}
}
PTH &= 0xFD;
TFLG1 = 0x20;
// End of payload
/**
*
*
* \date 19/7/05
*/
PTH |= 0x02;
first_Ch6 = TC6;
TFLG1 = 0x40;
PTH &= 0xFD;
}else{
last = TC6;
// Set flag
// End of Payload
PWM_Capture_flags &= 0xBF;
// Clear flag
last -= first_Ch6;
}else{
}
}
PTH &= 0xFD;
TFLG1 = 0x40;
return;
}
PTH &= 0xFD;
TFLG1 = 0x40;
return;
}
TFLG1 = 0x40;
PTH &= 0xFD;
return;
}
// End of payload
// End of payload
// End of Payload
// Offset
}
}
PTH &= 0xFD;
TFLG1 = 0x40;
// End of payload
/* ----------------------------------------------------------------------------------------------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
#define A_c
21
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 );
void controlSystem( void );
// Initialize the control system
// 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!
*
*
* \date 22/7/05
* \version 1.0 alpha
*/
#include
#include
#include
#include
#include
#include
<mc9s12dp256.h>
<math.h>
"timer.h"
"PicoPicCommInt.h"
"IMUComms.h"
"SS_Coeff.h"
// Derivative information
#define pi 3.141592564
void SSmatrixMult(float *X, float *Y, float *result, int X_r, int X_c);
char active;
char counter;
float
float
float
float
float
// Control System active flag.
// count until control system starts
current_states[ state_length ];
next_states[ state_length ];
inputs[ input_length ];
outputs[ output_length ];
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.
*
* \date 22/7/05
*/
void controlSystem_Init( void ){
int ii;
PicoPicCommInt_Init();
IMUComms_Init();
active = 0;
counter = 80;
DDRB = 0xff;
}
for(ii=0; ii<state_length; ii++){
current_states[ ii ] = 0.0;
next_states[ ii ] = 0.0;
Z_d = 0.0;
}
// 2 second delay
// Port B is output
// Clear States
/**
* \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.
*
* \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 ){
PicoPicCommInt_Send(
// If the control system is off
0, 1);
// All signals to 0
0, 2);
0.709677419, 4);
0.29032258, 5);
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.
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
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 ];
inputs[1] = (PWM_Capture_Ch2+0.5)*pi/12 - scaledOutput[ 1 ];
inputs[2] = (PWM_Capture_Ch1+0.5)*pi/12 - scaledOutput[ 0 ];
inputs[4] = (PWM_Capture_Ch0+0.5) - Z_d;
//
//
//
//
SSmatrixMult(&A,&current_states,&temp_states,A_r,A_c);
SSmatrixMult(&B,&inputs,&next_states,B_r,B_c);
// A*x
// B*u
next_states[ii] += temp_states[ii];
}
// x_n = A*x + B*u
SSmatrixMult(&C,&current_states,&temp_states,C_r,C_c);
SSmatrixMult(&D,&inputs,&outputs,D_r,D_c);
// C*x
// D*u
for(ii=0; ii<output_length; ii++){
outputs[ii] += temp_states[ii];
}
// y = C*x + D*u
outputs[4]/10, 1);
outputs[5]/10, 2);
0.36965019*outputs[7]+0.709677419, 4);
-0.36965019*outputs[8]+0.29032258, 5);
outputs[6]/10, 7);
PTH &= 0xFE;
Yaw = Yaw_SP - Yaw_FB
Pitch = Pitch_SP - Pitch_FB
Roll = Roll_SP - Roll_FB
Z_d = Z_d_SP - Z_d_FB
// Send the left motor speed
// Send the right motor speed
// Send the left servo position
// Send the right servo position
// Send the rear motor speed
// 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
*
* \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
#define BAUD_115200
// Defined mode
// Defined baud rate
void IMUComms_Init( void );
char IMUComms_Update( void );
__interrupt void SCI0_RIE_ISR( void );
// Prototypes
#ifdef RSO
#define outputLength
#endif
#ifdef GSV
#endif
#ifdef IV
#endif
#ifdef IQ
#endif
#ifdef GSQ
#endif
#ifdef IOM
#endif
#ifdef GSO
#endif
#ifdef GSQV
#endif
#ifdef IEA
#endif
#ifdef GSEA
#endif
#ifdef GSEARV
#endif
#ifdef GSEAARV
#endif
// Available modes
9
9
9
4
4
9
9
13
3
3
6
9
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.
*
* \date 8/9/05
* \version 1.0
*/
#include <math.h>
#include "IMUComms.h"
#define pi 3.141592653
#define RDRF 0x20
#define TDRE 0x80
/* Math libraries */
// Receive Data Register Full Bit
// Transmit Data Register Empty Bit
#define bufferLength (outputLength*2+5)
char ReadBuffer[ bufferLength ];
char bufferIndex;
// Not a ringbuffer.
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 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
};
#endif
// Instantaneous Quaternion
#ifdef IQ
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
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
1.0/8192.0, 1.0/8192.0, 1.0/8192.0, 1.0/8192.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
2.0*pi/65536.0, 2.0*pi/65536.0, 2.0*pi/65536.0,
};
#endif
// Gyro Stabilised Euler Angles (rad) and Acceleration (g) and Rate Vectors (rad/s).
#ifdef GSEAARV
2.0*pi/65536.0, 2.0*pi/65536.0, 2.0*pi/65536.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.
*
* \date 28/7/05
*/
void IMUComms_Init( void ){
char i;
asm sei
#ifdef BAUD_115200
SCI0BDH=0;
SCI0BDL=13;
#endif
#ifdef BAUD_38400
SCI0BDH=0;
SCI0BDL=39;
#endif
#ifdef BAUD_19200
SCI0BDH=0;
SCI0BDL=78
#endif
// Set up baud rate
SCI0CR1=0x00;
SCI0CR2=0x2C;
// data = 8, stop = 1, parity = none
// RIE,TE,RE
bufferIndex = 0;
// Reset Buffer Index
}
for( i=0; i<outputLength; i++ ){
scaledOutput[i] = 0.0;
}
// Clear output values
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.
* \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;
temps += ReadBuffer[ (i*2+2) ];
tempf = (float)temps;
tempf *= scalingValues[i];
scaledOutput[i] = tempf;
}
}
if(bufferIndex == bufferLength) i = 0x01;
else i = 0x00;
bufferIndex = 0;
while((SCI0SR1 & TDRE) == 0){};
SCI0DRL = commandByte;
return i;
//
//
//
//
//
Data MSB
Data LSB
convert to floating point
scale
store
// reset the buffer index
// When Tx ready
// Send request for next byte
/**
* \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.
*
* \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).
*
* \data 19/7/05
* \version 1.0
*/
#define TDRE 0x80
// Transmit Data Register Empty
#define bufferLength 100
// Max 255 unless change pointers to short
char SCI1RingBuffer[ bufferLength ];
char SCI1Buffer;
char SCI1Sent;
// Ringbuffer variables
/**
* \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.
*
* \date 19/7/05
*/
void PicoPicCommInt_Init( void ){
char i;
}
SCI1BDH=0;
SCI1BDL=13;
SCI1CR1=0x00;
SCI1CR2=0x08;
// baud = 115200
for(i=0; i < bufferLength; i++ ){
SCI1RingBuffer[i] = 0;
}
SCI1Buffer = 0;
SCI1Sent = 0;
// Clear buffer
asm cli;
// Global enable Interrupts
// No parity
// TIE,Enable Transmitter
/**
* \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)
*
* \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);
setpoint += 750;
// Scale for PicoPic
// Offset for PicoPic
if(setpoint > 2135){
setpoint = 2135;
}else if( setpoint < 750 ){
setpoint = 750;
}
// Position Saturation
SCI1RingBuffer[ SCI1Buffer ] = 120;
// Put PicoPic address in buffer
SCI1Buffer ++;
if( SCI1Buffer == bufferLength ) SCI1Buffer = 0;
SCI1RingBuffer[ SCI1Buffer ] = port;
// Put servo port in buffer
SCI1Buffer ++;
data = (char)(setpoint/256);
// Put upper position byte in buffer
SCI1RingBuffer[ SCI1Buffer ] = data;
SCI1Buffer ++;
data = (char)(setpoint%256);
SCI1RingBuffer[ SCI1Buffer ] = data;
// Put lower position byte in buffer
SCI1Buffer ++;
SCI1RingBuffer[ SCI1Buffer ] = 0;
// Put a 0 in the buffer
SCI1Buffer ++;
}
if(flag == 1){
SCI1CR2 = 0x88;
}
// If the buffer is initially empty.
// 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.
*
* \date 19/7/05
*/
__interrupt void SCI1_TDRE_ISR( void ){
PTH |= 0x40;
// Turn on the Tx LED.
if( SCI1Buffer == SCI1Sent ){
PTH &= 0xBF;
SCI1CR2 = 0x08;
return;
}
}
// If nothing to send
// Turn off Tx LED
// Turn off the interrupts
while((SCI1SR1 & TDRE) == 0){};
//
SCI1DRL = SCI1RingBuffer[ SCI1Sent ];
//
SCI1Sent ++;
//
if(SCI1Sent == bufferLength) SCI1Sent = 0;
PTH &= 0xBF;
//
Read SCI1SR1 (needed before transmission)
Place next byte in register
Update ring-buffer
Turn off Tx LED

Design and Build of a Remote Control (RC) Verical Take

Transcription

Similar documents

December 2012 - Blaine Airport Promotion Group

T-REX Manual - RC Helitechnics

TECHNICAL SPECS

Wherever you are. Whenever you need it.

AB Master Back - Sensenich Propellers

BREGUET Br.XIX-2A/B

COMMERCIAL BOOTHS

PSU Zephyrus

handheld controller