Embed Size (px)
Citation preview
UNIVERSITY OF SOUTHAMPTON
An Unmanned Aerial Vehicle for
Oceanographic Applications
By Ed Waugh
A transfer thesis submitted for Engineering Doctorate progression
FACULTY OF ENGINEERING, SCIENCE AND MATHEMATICS
SCHOOL OF ENGINEERING SCIENCES
21st September 2007
ii
Abstract Progress is reported on the development of an Unmanned Aerial Vehicle (UAV) at the
National Oceanography Centre, Southampton. Literature on the use of remote sensing
in ocean science is examined and a gap identified between the high‐resolution,
infrequent measurements made by ships and the wide area low‐resolution
measurements made by satellites. The commercial UAV market is summarised and
internal development has been selected as offering lower‐cost and more flexibility in a
potentially higher performance vehicle. Requirements are identified and a low‐cost‐
robust design philosophy has been adopted for all aspects of the development.
A new revision of the vehicle was designed, manufactured and manually test flown with
some success but a lack of engine power means the propulsion system will need to be re‐
examined. A highly integrated Flight Control System based on Micro Electro Mechanical
Systems sensors and an ARM 7 processor has been developed. The prototype Flight
Control System was flown in the vehicle and flight data was recorded. This data was used
to assess the performance of the vehicle. Future work is identified in developing the
launch system, proving software robustness and developing improved actuation for
control surfaces.
iii
Contents Abstract ................................................................................................................................................... ii
Contents ................................................................................................................................................. iii
List of figures ....................................................................................................................................... vii
List of acronyms .................................................................................................................................. ix
Chapter 1 ................................................................................................................................................. 1
Introduction........................................................................................................................................... 1
1.1 Research Context ............................................................................................................................... 1
1.2 Summary ............................................................................................................................................... 2
1.3 Novel contributions .......................................................................................................................... 2
1.4 Report structure ................................................................................................................................ 3
1.5 Project structure ................................................................................................................................ 3
Chapter 2 ................................................................................................................................................. 7
Literature review ................................................................................................................................. 7
2.1 Introduction ......................................................................................................................................... 7
2.2 Application ........................................................................................................................................... 7
2.3 Existing Unmanned Aerial Vehicles ........................................................................................ 10
2.3.1 Military ...................................................................................................................................... 10
2.3.2 Commercial ............................................................................................................................. 11
2.3.3 Academic .................................................................................................................................. 13
2.3.4 Conclusions ............................................................................................................................. 13
iv
2.4 Flight Control Systems ................................................................................................................. 14
2.4.1 Commercial Systems ........................................................................................................... 14
2.4.2 Hardware Component ........................................................................................................ 16
2.4.3 Software Component ........................................................................................................... 19
2.4.4 Payload Management .......................................................................................................... 20
2.4.5 Conclusions ............................................................................................................................. 21
2.5 Safety ................................................................................................................................................... 22
2.6 Conclusions ....................................................................................................................................... 25
Chapter 3 ............................................................................................................................................... 26
System Design ..................................................................................................................................... 26
3.1 Introduction ...................................................................................................................................... 26
3.2 Approach ............................................................................................................................................ 26
3.3 Modes of operation ........................................................................................................................ 26
3.3.1 Mode 1 – Short range .......................................................................................................... 27
3.3.2 Mode 2 – Deep Sea ............................................................................................................... 27
3.3.3 Mode 3 – Traffic ..................................................................................................................... 27
3.4 Flight conditions ............................................................................................................................. 28
3.4.1 Cruise condition .................................................................................................................... 28
3.4.2 Landing condition ................................................................................................................. 28
3.4.3 Launch condition .................................................................................................................. 28
3.4.4 Climb condition ..................................................................................................................... 28
3.5 Conclusions ....................................................................................................................................... 29
Chapter 4 ............................................................................................................................................... 30
Airframe ................................................................................................................................................ 30
4.1 Introduction ...................................................................................................................................... 30
4.2 Aerodynamic development ........................................................................................................ 30
4.3 Wind tunnel work .......................................................................................................................... 33
v
4.4 Engine development ..................................................................................................................... 35
4.5 Manufacture ..................................................................................................................................... 37
4.6 Systems integration ....................................................................................................................... 38
4.6.1 Electrical system ................................................................................................................... 38
4.6.2 Battery specification ............................................................................................................ 39
Chapter 5 ............................................................................................................................................... 40
Flight Control System ....................................................................................................................... 40
5.1 Introduction ...................................................................................................................................... 40
5.2 Approach ............................................................................................................................................ 41
5.3 Design .................................................................................................................................................. 45
5.3.1 Pressure sensing ................................................................................................................... 46
5.3.2 Layout ........................................................................................................................................ 47
5.4 Results ................................................................................................................................................. 48
5.5 Conclusions ....................................................................................................................................... 50
Chapter 6 ............................................................................................................................................... 52
Instrumented Flight Test ................................................................................................................ 52
6.1 Introduction ...................................................................................................................................... 52
6.2 Performance analysis ................................................................................................................... 52
6.3 Conclusions ....................................................................................................................................... 54
Chapter 7 ............................................................................................................................................... 56
Payload Management ....................................................................................................................... 56
7.1 Introduction ...................................................................................................................................... 56
7.2 Detailed requirements definition ............................................................................................ 56
7.3 Design .................................................................................................................................................. 58
7.3.1 Physical size ............................................................................................................................ 58
7.3.2 Voltage support and low power consumption ......................................................... 59
7.3.3 Analogue measurement ..................................................................................................... 60
vi
7.3.4 Serial interfaces ..................................................................................................................... 60
7.3.5 Driving high power devices .............................................................................................. 60
7.3.6 High pressure survivability .............................................................................................. 60
7.4 Results ................................................................................................................................................. 61
7.4.1 Analogue performance ....................................................................................................... 61
7.4.2 Power consumption ............................................................................................................. 63
7.4.3 High pressure survival ....................................................................................................... 63
7.5 Conclusions ....................................................................................................................................... 63
Chapter 8 ............................................................................................................................................... 65
Conclusions and Future work ....................................................................................................... 65
8.1 Introduction ...................................................................................................................................... 65
8.2 Conclusions ....................................................................................................................................... 65
8.3 Vehicle ................................................................................................................................................. 66
8.4 Flight Control System ................................................................................................................... 66
8.5 Robustness and redundancy in surfaces .............................................................................. 67
8.6 Planning ............................................................................................................................................. 68
References ............................................................................................................................................ 70
Appendix 1 ............................................................................................................................................... i
Appendix 2 ............................................................................................................................................. ii
Appendix 3 ............................................................................................................................................ iii
Appendix 4 ............................................................................................................................................ iv
Appendix 5 .............................................................................................................................................. v
vii
List of figures
Figure 1.1 ‐ NERC research vessel James Cook berthed outside the NOC ............................. 1
Figure 1.2 ‐ Project responsibilities and relationships ........................................................... 5
Figure 1.3 ‐ Overview of project timeline ................................................................................ 6
Figure 2.1 ‐ Seascan UAV being recovered (left) and ready for launch (right) ................... 12
Figure 2.2 ‐ UAV Navigation AP04 (left) Cloud Cap Piccolo II (right) ................................ 15
Figure 2.3 ‐ Diagram of FCS main components .................................................................... 17
Figure 4.1 ‐ NOC UAV mark 1 ................................................................................................. 31
Figure 4.2 ‐ Artists rendering of NOC UAV mark 2 design ................................................. 32
Figure 4.3 ‐ Design differences between mark 1 and mark 2 .............................................. 33
Figure 4.4 ‐ Wind tunnel results L/D .................................................................................... 33
Figure 4.5 ‐ Wind tunnel results, flaps .................................................................................. 34
Figure 4.6 ‐ Honda GX25 specifications................................................................................ 36
Figure 4.7 ‐ Honda GX25, power v.s. fuel consumption ...................................................... 37
Figure 5.1 ‐ FCS interfaces to the UAV and ground station ................................................. 40
Figure 5.2 ‐ Comparison of FCS options ............................................................................... 44
Figure 5.3 ‐ Component selections for FCS .......................................................................... 46
Figure 5.4 ‐ Absolute pressure sensing converter design .................................................... 47
Figure 5.5 ‐ FCS layout ........................................................................................................... 48
Figure 5.6 ‐ Flight Control System ........................................................................................ 49
Figure 5.7 ‐ Results of FCS sensor testing ............................................................................. 49
Figure 5.8 ‐ FCS feature list ..................................................................................................... 51
Figure 6.1 ‐ Speed (red) and RPM (blue) ............................................................................... 53
Figure 6.2 ‐ Speed (red) and Altitude (blue) ........................................................................ 54
Figure 7.1 ‐ Sensors Group Data Logger v1.1 specificatons ................................................... 57
Figure 7.2 ‐ UAV sensors and interconnections ................................................................... 58
viii
Figure 7.3 ‐ Technical drawing of SGDL v1.2 ........................................................................ 59
Figure 7.4 ‐ Voltage reference measurement at 4.6 kHz ..................................................... 62
Figure 7.5 ‐ Voltage reference measurement at 1.7 kHz ...................................................... 63
Figure 8.1 ‐ Actuator failure diagram .................................................................................... 68
Figure 8.2 ‐ Steering group members .................................................................................... 69
ix
List of acronyms
ADS/B Automatic Dependent Surveillance/Broadcast
CAA Civil Aviation Authority
CPU Central Processing Unit
CTAS Converging Traffic Alert System
DC Direct Current
DCDC Direct Current to Direct Current
FCS Flight Control System
FPU Floating Point Unit
GPS Global Positioning System
INS Inertial Navigation System
NERC Natural Environment Research Council
NOC National Oceanography Centre, Southampton
PID Proportional, Integral, Differential
PDF Proportional, Derivative, Feedback
RADAR RAdio Detection and Ranging
RAM Random Access Memory
ROM Read Only Memory
RTOS Real Time Operating System
SGDL Sensors Group Data Logger
TCAS Traffic Collision Alert System
UAV Unmanned Aerial Vehicle
1
Chapter 1
Introduction
1.1 Research Context
The National Oceanography Centre, Southampton (NOC) is the focus for the UK’s
oceanographic activity, performing research into chemical, geological and biological
processes in the world’s oceans. This research involves simulation, sampling and indirect
measurement using satellites. Sampling and in situ analysis of the deep ocean is usually
done onboard the Natural Environment Research Councils (NERC) research ships
(Figure 1.1) or using automated buoys, underwater vehicles or floats.
Figure 1.1 ‐ NERC research vessel James Cook berthed outside the NOC
2
The scientists working at the NOC want to measure the ocean for more parameters, at
greater spatial and temporal resolution in the most time efficient manner possible. One
of the most expensive aspects of ocean research is the use of research ships. Ship
operations can be made more effective by using satellite data to direct the vessel to areas
of interest. Although, as will be shown in section 2.2 this is not always ideal. This project
aims to characterise an established need for an Unmanned Aerial Vehicle (UAV) to
enhance research ship operations (Chapter 2) and then develop an appropriate system.
1.2 Summary
A vehicle has been designed to suit the requirements of ocean research. This design has
a range of > 1000 km and a prototype has been manufactured for flight‐testing (Chapter
4). Initial flights have shown the design to be underpowered when climbing although
otherwise operating well. A new hardware autopilot has been designed and a prototype
manufactured (Chapter 5), this has been used to record a large amount of data during
flight‐testing. A new revision of the Sensors Group Data Logger has been designed to
support UAV payload control and improve performance for chemical sensor control
(Chapter 7). This will satisfy the requirements of the primary (oceanographic)
application and provide a useful platform for wider UAV research currently in progress
at the University of Southampton.
Remaining work includes developing the vehicle for ship operations, completing the
low‐level software for the flight control system and performing robustness proving. It is
also hoped to develop a custom smart actuator for the flap system (Chapter 8).
1.3 Novel contributions
This multidisciplinary project is application focused and is concerned primarily with the
development and construction of high performance functioning prototypes that together
constitute a novel system (no comparable research or commercial UAV system exists
(see sections 2.3 and 2.4). System and component‐level novel contributions include:
1. The design, construction, and test of a long‐range, low‐cost, UAV airframe for
ship based oceanographic applications (Chapter 4)
3
2. The design, construction and test of a low‐cost, robust and potentially certifiable
autopilot with health monitoring functionality and black box recording system
(Chapter 5)
3. The design, construction and test of a generic low‐cost, high performance
logging and control electronics suitable for UAV and in situ deep sea operation
(i.e. at high (<60MPa) ambient pressure) (Chapter 7)
1.4 Report structure
This report is split into sections relating to the areas of work undertaken. Much of the
work was carried out in parallel. Chapter 1 provides an overview of the work completed
to date and describes the long‐term timeline and the relationship of this project to the
others associated with the NOC UAV project.
Chapter 2 is a review of the literature related to the application of a UAV to
oceanography, existing vehicles, control systems and the safety aspects of operating
unmanned vehicles. Chapter 3 uses the conclusions from the literature review to define
the requirements for the whole vehicle. Chapter 4 describes the development of the
airframe and propulsion system including aerodynamic and structural work. The
development of the Flight Control System (FCS) is described in Chapter 5. Chapter 6
describes instrumented flight tests of the airframe (under manual control) using the FCS
as a black box recorder. Chapter 7 describes the modifications made to the Sensors
Group Data Logger to make it appropriate for use in the UAV. Chapter 8 draws
conclusions on the progress made so far and identifies the direction of the future
research.
1.5 Project structure
The project has two main streams both led by engineering doctorate students, the
hardware development stream including vehicle structure, aerodynamics and electronics
and the software development stream including simulation and algorithm optimisation.
These are supplemented by undergraduate projects in aerospace, materials and
electronics. The undergraduate projects are targeted at work not in the critical path for
the project, these independent units allow the students to pursue their own ideas and
4
develop their own solutions. This work is then evaluated by the doctorate students and
the supervisory team for inclusion in the project. The distribution of work between
streams is shown in Figure 1.2.
The long‐term aim of the project is to begin flight trials from a research vessel in the
autumn of 2009. The timeline for the project is shown in Figure 1.3.
5
Figure 1.2 ‐ Project responsibilities and relationships
Flight Testing
Project planning
Propulsion
Ed WaughEngD
Development of a UAV for oceanographic
applications
Matt Bennett EngD
Development of software algorithms for
a low-cost UAV
Hardware
Software
Aerodynamics
Structures
Fourth yearGDP
Aerospace, mechanical and electronics
undergraduate students
Flight Control System - Requirements definition - Component selection - Physical board designPayload Management - As flight control system
Flight Control System - Modification and repair of ONavi autopilot - Integration of cameraPayload Management - Supervision of GDP group
Payload Management - Integrate with sensors and vehicle
Flight Control System - Structural design - Low-level codePayload Management - Library development
Flight Control System - State estimation - Control - Navigation
Payload Management - Develop preliminary code
- Requirements definition - Supervision of fourth year students - Experiment design
- Computational fluid dynamics - Aerodynamic optimisation - Operation of wind tunnel
- Requirements definition - Fuselage and non-aerodynamic design - Supervision of fourth year students - CAD modelling - Design tracking - Mould design and manufacture
- Modelling for simulation
- Strength modelling (FEA) - Manufacture of components - Integration of tail surfaces
- Requirements definition - Supervision of fourth and third year students - Characterisation experiment design and setup - Fuel system design
- Modelling for simulation - Engine characterisation experiments
- Long term, whole project planning - Planning own work - Assisting in proposal writing - Creating project specifications for student groups
- Planning own work - Developing a schedule based on the project specification
- Scheduling - Preparation of all aspects - Experimental design - Aircraft setup - Organisation on site
- Flying test vehicle
6
Figure 1.3 ‐ Overview of project timeline
2004 2009
Ele
ctro
nics
GD
PM
att B
enne
ttE
ngD
Four
th Y
ear
GD
PTh
ird Y
ear
Indi
vidu
alE
d W
augh
Eng
D
Development of manufacturing
techniques
Aerodynamic testing of new
designTail redesign
Payload management
system
Flight control hardware
development
Test hardware development State estimation Control
algorithms
Advanced control and flight planning
Design of new hardware system
Implementation of new hardware
system
Vehicle integration and actuator development
Development for use at sea Flight trials at sea
Engine characterisation
Wing manufacture and
structure
Note: Year boundaries are academic years starting October 1st
2005 2006 2007 2008
7
Chapter 2
Literature review
2.1 Introduction
Literature is examined to inform design decisions and generate the requirements for the
project. The current application of Unmanned Aerial Vehicles (UAVs) to ocean sensing
is investigated and new areas are identified. This information is used to generate an
outline specification for the vehicle and then a market survey is performed to find a
suitable commercial system.
2.2 Application
As part of the continuing programme to enhance measurement techniques, the National
Oceanography Centre, Southampton (NOC), commissioned a of study into the use of
UAVs in oceanography [1]. There have also been studies by Lomax [2] and Peterson [3].
These indicate a gap between high‐resolution direct measurements at sea and wide‐area
but low‐resolution satellite measurements. They suggest this gap could best be filled
with an airborne platform.
The most common ocean parameters measured by satellites are; surface temperature,
using infrared and microwave radiometers [4, 5] and colour using panchromatic cameras
[6]. It is also possible to measure wind speed and surface roughness by adding a
scatterometer [2]. Imaging resolution from new satellites has improved to 3metres
resolution for colour images; however, the sensing equipment available to
8
oceanographic research is more normally around 15‐90 metre resolution. Using an
airborne vehicle allows much higher resolutions (0.2 m and less [2]) due to the proximity
of the sensor to the ocean. There is also a great deal more flexibility, the sensor can be
upgraded or filters applied to improve performance, which is not possible with a satellite
[3].
The most useful satellite systems for oceanographic sensing are in a low polar orbit as
this allows the whole surface of the earth to be scanned as it rotates under the satellites
path [3]. These satellites pass over the same area approximately four times each day
allowing the tracking of changing systems. However, the onboard infrared radiometers
and panchromatic cameras are unable to penetrate cloud, leading to very poor
performance in conditions other than clear skies. New microwave radiometry techniques
can measure sea surface temperature in all weather conditions except rain [7]. An
airborne vehicle is able to fly under the cloud base and stay on station in the area of
interest to take frequently repeated measurements. This offers significant advantages
when monitoring a rapidly changing system.
Manned aircraft have a number of serious limitations for oceanographic applications.
They are too large to launch from a research ship and would have to fly from a land‐base
close to the area of interest. This would reduce time on station and would create
significant cost and logistics issues. There would also be a long start‐up time for each
mission. In addition, mission length is determined by the crew who can only work for
eight‐hour periods, operation in shifts is at the penalty of reduced range or payload, or
increased mission cost. Lomax and Pluck et al both conclude that UAVs offer the best
solution due to their flexibility, potentially smaller size and lower cost [1, 2].
Several medium‐scale applications such as plankton bloom monitoring where the area of
interest is hundreds to thousands of kilometres in size, could be enhanced by the
improved temporal and spatial resolution offered by a UAV. Features this large would
require an aircraft with a range in excess of 1000 km and the ability to travel fast enough
to view large areas.
In some cases, existing sensor technology can be directly applied to oceanographic UAV
operations without modification. Sea colour could be measured with panchromatic
cameras (e.g. Nikon D200 [8] (£800)) with a suitable vibration‐reducing mount. A
9
gimballed mounting may offer advantages. Alternatively recording the aircraft’s
orientation would allow the image location data to be corrected with post‐processing.
Infrared imaging packages suitable for small UAVs are commercially available. The
Photon from Indigo Systems [9] measures less than 10 cm in its longest dimension and
weighs under 300 grams. Fitted with a 14.5 mm lens it has a pixel size of one square
metre from a 200‐metre altitude. The camera captures 7 to 13.5 µm wavelengths and
translates them to an analogue video signal that would require calibration before using
to measure absolute temperature.
White capping and wave height data is of interest when investigating the chemical
exchange of the ocean and the atmosphere. Measuring white capping could be done
with the panchromatic imagery and wave height data could be measured using a
miniaturised RADAR system or by deploying small buoys [10, 11]. The micro‐sized wave
buoy from Planning Systems Inc [11] can be deployed at altitude and at only 5 cm long
could easily be carried by a small UAV. The system has been test deployed by a manned
aircraft [10] and the average wave period measured showed a good correlation with the
baseline system used.
Even with a relatively small set of parameters that can be measured with commercially
available sensors; a suitably equipped UAV would provide useful data on a range of
oceanographic variables. As well as providing data in its own right, one of the most
useful modes of operation of a UAV could be in supplementing the work of a research
vessel. This would involve tracking ahead of the vessel to allow its research to be more
accurately directed to areas of interest.
Such a UAV could also be applied to disaster monitoring as well as research. Tracking of
oil spills, harmful algae blooms [12] or other contaminant would allow protective
measures to be applied more effectively and swiftly by recovery crews. The ability to
deploy the vehicles rapidly would allow imagery to be taken in advance of the
contaminant reaching coastal areas. This could then be used after the incident to direct
clean‐up crew activities.
To be most effective an oceanographic UAV would need to be launched and recoverable
from a typical ocean research vessel. This limits the size of the vehicle to something that
could be dismantled to fit inside a standard shipping container (6.5 m x 2.5 m x 2.5 m).
To be considered cost effective any vehicle would need to be of a value equivalent to the
10
research it is able to perform. A NERC research vessel costs around £15,000 to run per
day, a UAV operating to enhance this research would need to cost less than this taking
into account the potential for losing the vehicle during recovery.
The application of a UAV to oceanographic research can supplement and enhance
existing programs of ocean research as well as providing support to disaster recovery
operations. Such a UAV would need to be able to carry a scientific payload of small
instruments that could be varied depending on the mission to be flown. To carry the
infrared and panchromatic cameras described would require a volume of 3 litres and a
mass of 500 g.
It would also need to be operated from a typical research vessel. This will involve
handling the vehicle on deck and transporting it to and from the ship as well as launch
and recovery. To be cost effective such a UAV would need to be under £15,000 per
vehicle and per day including staff costs and the possibility of loss during recovery. This
means the capital cost of each UAV should be no more than £5,000.
2.3 Existing Unmanned Aerial Vehicles
2.3.1 Military
The most well known UAV is arguably General Atomics Predator B [13], which has been
used (and filmed in operation) extensively in military applications for reconnaissance
and weapons deployment [14]. A 20m wingspan and one and a half tonnes of payload
make this one of the largest UAVs available and therefore too large to operate from
research vessels. However, the long endurance of 30+ hours, high level of autonomy and
robustness would otherwise make this a good choice for a research vehicle, allowing the
largest instruments to be carried, along with possibly hundreds of deployable buoys. The
Predator is available in an unarmed version called Altair; estimates of cost are around
£4,000,000 per vehicle.
The Pioneer UAV has been used extensively by both the US army and navy for
reconnaissance. It is a relatively short‐range vehicle (180 km) with an endurance of just 5
hours although it does carry a large payload of moveable cameras. The vehicle can be
ship launched using rocket or catapult but it is very large (205 kg) with a wingspan of 5
metres making it difficult to accommodate on a small vessel. There have also been some
11
problems reported with pioneer [15], its inability to operate in rain would severely limit
its use as a research vehicle and the lack of automated take‐off and recovery has led to a
high accident rate.
The Insitu group ScanEagle [16] is the military variant of the SeaScan described in detail
section 2.3.2.
One of the smallest UAVs in regular use by the US military is the AeroVironment Raven
[17]. This is a hand launched, electric powered UAV weighing just 2 kg. Its small size
would make launch and recovery at sea relatively easy as the whole vehicle can be
handled by one person. However, it is limited to a range of just 10 km and cannot carry a
payload beyond the fitted cameras. The cost per vehicle is around £17,000.
Military UAVs are designed to perform a specific task regardless of cost. This generally
makes them unsuitable for use in a commercial environment. Some make the transition
from commercial to military, like the SeaScan (described in section 2.3.2); however, most
will never be a viable proposition. The Predator and Pioneer are both to large and
expensive to be suitable, the Raven is too small and limited in range. The small seaplanes
that have been demonstrated [18] are unable to operate in the heavy conditions
anticipated.
2.3.2 Commercial
There are several UAVs now for sale aimed at a variety of markets from advanced hobby
aircraft pilots through to off the shelf systems including crew to perform specific
missions. The Micropilot MP‐UAV [19] is based on a trainer aircraft for hobby pilots and
includes a basic flight control system. It is a very low‐cost system at £6,000 including a
ground station and radio link. However, its flight endurance is only 20 minutes and due
to its balsa construction, would be unlikely to survive in adverse weather conditions, it
would also be very difficult to make waterproof.
The most well known commercial UAV is the Aerosonde; it is a 3‐metre wingspan, 14 kg
pusher configuration designed primarily for the barometric measurement. It has been
successful in operations in the Arctic as well as flying across the Atlantic and has an
endurance of over 50 hours. If required it is possible to purchase operational time rather
than your own aircraft. This includes all the personnel and equipment necessary at £300
‐> £600 per flight hour for a four‐week mission. To purchase a complete system
including four aircraft is £410,000.
12
The Insitu group SeaScan is a UAV designed specifically for operation at sea [16]. It
includes a catapult launch and a wire recovery system (Figure 2.1). The vehicle has very
long endurance at over 22 hours and only a 3‐metre wingspan. It can carry payloads of
up to 6 kg and includes an inertial stabilised camera turret. Three vehicles, a control
centre, launcher, capture system and training is around £650,000.
Figure 2.1 ‐ Seascan UAV being recovered (left) and ready for launch (right)
Launching a UAV from a ship, as in the case of the SeaScan, is usually done with a
catapult or other system that allows it to be accelerated quickly to flight speed. However,
the ability to launch from the sea could offer big advantages to oceanographic study.
Launch and recovery are simplified along with gaining the ability to land at a distant
point, collect a sample and then launch and return to the ship. NASA have conducted
experiments with a seaplane [20] intended for use as an unmanned cargo carrier. The
vehicle operated successfully but only in very calm conditions. The Gull UAV from
Centaur Systems [21] has also demonstrated launching from the sea surface, also in calm
conditions. It is likely that a research vessel operating in the open ocean would rarely
encounter the sea states in which these vehicles can operate.
Advanced Ceramics Research in the US have developed the Manta B UAV [22], this is a
pusher configuration with an all‐up‐mass of 23 kg and 6‐hour endurance at 30 ms‐1
giving a range of approximately 600 km. The package includes three vehicles with
autonomous operation, a pneumatic launcher, spares and training for £200,000.
The MLB Bat UAV [23] features 6‐hour endurance, 180‐mile range, with a 2 Kg payload
and only a 2‐metre wingspan. The avionics package also includes the ability to track and
follow road convoys as well as autonomous bungee powered launch. At only £25,000 for
13
the basic package including launcher, ground station and training this would make a
suitable platform from which to develop a waterproof version capable of the water
landings required.
Commercial UAVs are now of a quality that makes them appropriate for adaptation to
suit the specific requirements of oceanographic missions. However, many are still far
from economically viable for operation from a research vessel (see section 2.1). Despite
its relatively short range, the closest is the MLB Bat UAV. If the advanced package was
selected (£50,000) and a couple of vehicles were included, it would be necessary for each
vehicle to survive five flights with only minor repairs. It is unlikely that the engines
would survive landing in seawater although spares could be sourced independently. The
main disadvantages of a bought in system is the high replacement cost and the lack of
configurability. This could become limiting as more complex and unusual missions are
required.
2.3.3 Academic
Many academic institutions are now running UAV projects. Most of these are focussed
on the development of advanced flight control algorithms including cooperative flight
[24] and distributed control [25]. The majority of the vehicles used are off‐the‐shelf
hobby aircraft that serve only as a taxi for the electronics payload. This type of vehicle is
unsuitable for use in oceanographic research as they are usually too small, too flimsy and
have short flight durations. No academic institutions are currently attempting to
develop what is essentially a commercial vehicle targeted to a specific application and as
such, are not a good model for this project.
2.3.4 Conclusions
The high cost of military grade vehicles makes them inappropriate for oceanographic
research due to the low vehicle cost necessary (see section 2.1). Academic vehicles are
usually too simple and perform too poorly to be useful at sea and for the long duration
missions that will be required. Of the commercial vehicles, the Bat UAV is the closest fit
with the requirements especially if several vehicles were supplied for the £50,000 initial
cost, although, it would still require a large amount of customisation to suit the
environment.
Developing the vehicle internally not only allows tight control of our vehicle (our
primary objective) but also allows the design to be tailored to the application from the
14
start. Access to wind tunnel and computer cluster facilities allow a highly optimised
design to be developed that can compete on range and endurance with the best
commercially available vehicles. The experience gained while developing the vehicle will
also be invaluable when it comes to deployment and predicting performance in
challenging weather conditions.
2.4 Flight Control Systems
2.4.1 Commercial Systems
Flight Control Systems (FCSs) are supplied with all of the commercial UAVs described in
section 2.3. These all offer the basic functions required to stabilise a fixed wing UAV and
perform waypoint based navigation using GPS waypoints. They can be purchased
separately so if a custom airframe were developed it would still be possible to make use
of an off‐the‐shelf control system, substantially reducing development time.
The most common FCS amongst the commercial UAVs is Cloud Caps Piccolo range, now
at version 2 (shown in Figure 2.2). The system includes high frequency (4 Hz) GPS, an
Inertial Measurement System (IMS) with external magnetometer option, autonomous
launch and landing, a wide range of interfaces and weighs only 233 grams. The Piccolo
FCSs have flown many hours in the Aerosonde UAV and there are links between the
companies as the two systems were originally developed together[26]. It has also been
used by a number of university projects, successfully piloting a range of different
airframes [24, 27] and in cooperative flying [28]. The Piccolo is reported to be reliable
and easy to configure in all cases. A single Piccolo II is £4,000 with an additional £4,700
for the ground station and £500 for the developer kit. The cost of each Piccolo is very
high when compared to the required total vehicle cost of £5,000 established in section
2.1, there would need to be a high confidence of safe recovery if a system this expensive
was used.
Blue Bear Systems [29] have recently developed a miniaturised FCS that includes
stabilisation functions and has considerable processing power available to the end user.
It is designed to fit into very small UAVs and has an open architecture allowing access to
the software. It is likely that this system would require some additional development to
make it appropriate for use in oceanographic research, as it is not supplied in any
enclosure. The system is supplied at £1000 per unit where the base station is an
ad
of
ha
us
ex
Th
te
re
fo
re
re
Th
N
pr
fa
sh
ha
is
Cr
w
fa
sy
dditional co
f its use are
ardware, wi
se of a Real
xpensive to
he Micropil
echnical spe
eport proble
or the basic
eported poo
eliability.
he AP04 fl
avigation [3
rocessors an
ailures and
hockproof h
as not been
expect that
rossbow Ine
ith an autop
amily is the
ystem that o
ost. It is diffi
from Blue
ith a large p
Time Oper
develop (se
lot MP2028
ecification i
ems configu
board inclu
r performan
Figure 2.2 ‐
light contro
31]. In addi
nd softwar
single fail
housing mak
possible to
t it would be
ertial System
pilot family
e NAV420 t
outputs ine
icult to rate
Bear, this is
processor fed
rating System
e section 5.2
8 is widely
s similar to
uring it and
uding no ra
nce, make it
UAV Naviga
ol system s
ition to flig
e algorithm
lure of any
kes it a suit
obtain a qu
e similar in
ms [32] sup
y that uses t
that incorpo
ertial data. T
e the perform
s probably b
d with sens
m (RTOS).
2).
used by ac
o the other
in its flight
adio link or
t a risky cho
ation AP04 (le
shown in F
ght control
ms that allo
y sensor. T
table choice
uote for the
price to the
pplement th
their sensor
orates sens
This can th
mance of th
because it i
sor data by a
This makes
ademic pro
products d
t performan
compass. T
oice for a pr
eft) Cloud Ca
Figure 2.2
and naviga
ow (in som
This comb
e for operati
AP04 altho
e Piccolo II.
heir range
rs. The most
ing and ine
hen be custo
his system as
s relatively
a microcont
s the system
ojects due t
described he
nce [30]. Th
The age of t
roject aimin
ap Piccolo II
has been d
ation, the A
me cases) f
ined with
ion in hosti
ugh one ha
of inertial m
t appropriat
ertial algori
om program
s the only e
new. The d
troller, requ
m more diffi
to its low‐co
ere but som
he MP2028 i
this product
ng for a high
(right)
developed b
AP04 featur
for multiple
a waterpro
ile environm
s been requ
measureme
te system fr
ithms to pr
mmed altho
15
xamples
design of
uires the
cult and
ost. The
me users
is £2,700
t and its
h level of
by UAV
res dual
e sensor
oof and
ments. It
uested. It
nt units
rom this
rovide a
ough the
16
inertial algorithms are not retained and would need to be rewritten. An open source
project does exist although this is far from complete. At £4,500, the NAV420 is the
majority of the budget for the whole UAV and does not include any flight control
software.
Using an off‐the‐shelf FCS would significantly reduce the development time of the UAV.
The Crossbow and UAV Navigation systems are designed to survive in harsh
environments and the Cloud Cap systems have extensive flight time. The cost of these
systems, however, is prohibitive when compared to the £5,000 vehicle cost required,
especially when the hardware they contain is itself quite low‐cost. They are also
inflexible compared to a fully custom system as no hardware changes could be made to
accommodate new features. These considerations combined with the electronics
experience in the group make it advantageous to develop a system internally.
2.4.2 Hardware Component
All the FCSs examined use the same type of measurements to control the aircraft. They
sense rotation with gyroscopes and acceleration with accelerometers each in three axes.
This is supplemented by dynamic pressure for airspeed, static pressure for altitude and a
GPS to provide positional drift correction. In some systems, magnetic sensing is also
included, which can give redundancy for speed and heading measurement (if there is no
wind) or provides true heading (as opposed to ground track) and allows the estimation
of wind speed and direction if winds are present. Figure 2.3 shows the main components
of a FCS.
17
Figure 2.3 ‐ Diagram of FCS main components
The development of low‐cost Micro‐Electro‐Mechanical Systems (MEMS) inertial
sensors has been the enabling technology for small UAV systems. Traditional Fibre
Optic Gyroscope (FOG) based IMUs offer exceptional performance. The KVH TG6000
IMU [33] has an angular rate range of 750 °/s and a resolution of 3×10‐2 °/s. It is also very
low drift (±1 °/hr), has low non‐linearity (1000 ppm) and is highly insensitive to off axis
rotations. It can also measure accelerations of ±70 g with a resolution of 3×10‐4 g. This
military grade system costs around £20,000.
MEMS inertial sensors do not provide the raw performance of conventional devices with
typical gyroscopes [34] limited to ±300 °/s at a resolution of 2.4×10‐2 °/s and
accelerometers with a range of ±2 g and a resolution of 1.2×10‐3 g. The problem when
comparing these values is that the MEMS sensors can exhibit worse characteristics in
areas like drift, which are not presented by the manufacturer. However, these sensors
are several orders of magnitude cheaper than their conventional counterparts at around
£50 for the six required. Due to their relatively low‐cost nature, all the FCSs examined in
section 2.4.1 use almost identical sensor suites based on MEMS sensors.
18
An advantage of MEMS sensors is better robustness over traditional sensors. The KVH
TG6000 is rated to a maximum non‐operating shock of 200 g while MEMS sensors are
typically rated at 2000 g while operating [34]. This has led to their use in munitions
applications [35].
The main difference between commercial FCSs is the amount and type of processing
power used to execute the inertial and control algorithms. The Piccolo system uses a
Motorola MPC555 processor running at 40 MHz that can achieve 50 Million Instructions
per Second (MIPS) and has a hardware Floating Point Unit (FPU). The addition of the
FPU is significant as it makes processing large matrices of floating point numbers
possible in real time. This can be important for some algorithms as described in section
2.4.3. The disadvantage of a fast CPU is an increase in power consumption; this can be
significant over a long duration mission. Cloud Cap do not run an Operating System
(OS) on the Piccolo and program directly for the processor, there is no indication of any
software quality‐assurance method, which may be critical in gaining aviation authority
approval to operate (section 2.5).
Blue Bear take a different direction with their system and have a high‐speed integer
processor, a 400 MHz XScale that can do 480 MIPS. This does not include a FPU but due
to its high clock speed, can perform these calculations very effectively in software. Blue
Bear run a Linux based operating system that allows very easy code development and
porting directly from Matlab routines. This combination of software makes it very
difficult to prove reliable operation but is very convenient for rapid prototyping. Despite
its high clock speed, the XScale draws very little power in operation.
The Micropilot and AP04 both use low‐cost microcontrollers (the AP04 uses two) to
perform data collection and all calculations. This makes them simple to program and
cheap to build but does mean they have limited processing ability. They are
programmed directly and do not use an OS. Micropilot uses a 33 MHz Motorola M‐Core
that can do around 40 MIPS but has no FPU; this processor also lacks any additional
hardware to reduce the burden of data collection, further reducing the available
processing time. Both these systems have demonstrated successful flights including the
use of Kalman filters (described in section 2.4.3) for inertial positioning which, suggests
it is feasible with this amount of processing.
19
In addition to the fully integrated systems, it is possible to purchase an inertial
measurement system that could then be interfaced to a processing board to create a
complete system. These include polished algorithms for state estimation that would
significantly reduce development time. High performance systems from Crossbow [32]
cost from £2,500 and can easily exceed the cost of the NAV420 at £4,500 (see section
2.4.2). Other systems like the Sparkfun 6DOF IMU [36] are essentially just the same
inertial sensors as the FCSs offer but pre‐mounted and easy to use. The Crossbow
systems are too expensive for the same reason as the FCSs (see section 2.4.1), the other
systems like those from Sparkfun do not offer the advantages of a real IMU, as they
include no processing, just raw data outputs.
There is no consensus on the optimum processing solution amongst the FCSs available
on the market today. Different systems take completely different approaches, often to
tailor themselves to a specific market. Low‐cost inertial sensing is performed in the same
way by all the systems examined. MEMS sensors (usually from the same manufacturer)
are used and their outputs filtered to give an acceptable estimate of aircraft state. The
hardware used in all these systems is in itself, quite cheap. The cost of the systems
usually comes from the integration and software. A custom‐built FCS should offer the
same features as the best available commercial systems but provide the reduction in cost
of having been developed internally.
2.4.3 Software Component
The commercial FCSs examined in section 2.4.1 all use very similar software schemes.
The Kalman filter is preferred for state estimation due to its ability to compensate for the
strengths and weaknesses of the low‐cost MEMS inertial sensors [37]. The filter can also
incorporate data from GPS [38] and provide estimates of unmeasured parameters like
gyroscope bias [39]. Gyroscope bias is especially important as the low‐cost MEMS
sensors can drift dramatically within a matter of minutes. An extended Kalman filter is
typically used in UAV applications due to the non‐linear nature of aircraft dynamics.
Most UAV control systems use Proportional‐Integral‐Differential (PID) controllers as
these are well understood and methods exist for tuning the gains. Some more
sophisticated systems use state‐space or adaptive models but these are generally only
found in large and military UAVs. An alternative to the PID controller is the Pseudo
Derivative Feedback (PDF) controller. This differs from the PID because the
proportional and derivative terms are in the feedback rather than forward stage [40].
20
This offers a performance improvement over PID but they are more difficult to tune and
there are less examples in the literature [41].
The computational requirements of the software will determine the processing
requirements of the system. The computational requirements of an Extended Kalman
Filter can be very high especially when done in floating point on an integer only
processor. An example of this is the floating point Kalman filter implemented on the test
hardware by Bennett [41]. The filter requires approximately 260,000 instructions per
execution when GPS data is updated in addition to inertial data. This is 58% of the
instructions available on a 50 MHz ARM core every 100 Hz. Some developers have used
processors with a hardware FPU to get round this problem, although it is possible to
write a Kalman filter that uses fixed point [42]. Integer calculations require 20 ‐> 35
instructions less than emulated floating‐point instructions (very mixture dependent).
This allows a smaller processor to be used, resulting in power savings or a more
sophisticated algorithm to be executed.
Another major factor in determining the processing requirements is the rate at which
the aircraft surfaces need updating. The Crossbow [32] inertial measurement and
autopilot systems operate at a rate of 100 Hz. It is difficult to find information on the
rates used by commercial systems but due to the maximum 100 Hz bandwidth
limitations of the MEMS gyroscopes (values are similar for the other devices) there is no
benefit going faster.
The FCS software component will necessarily include Kalman filtering for state
estimation and either PID or PDF controllers for stabilisation. It should also be
considered that more advanced controllers might be used in the future. These would
likely be the same order of processing as the Kalman filter so the ability to process up to
500,000 instructions at 100 Hz would be desirable if everything was implemented in
floating point. In addition, there may be several higher layers of control to provide
advanced functions including navigation. The software in commercial FCSs is the
expensive part of the system. It is mathematically sophisticated and requires a high level
of reliability making it difficult and time consuming to develop.
2.4.4 Payload Management
Any UAV for oceanographic research will need to carry a mixture of scientific equipment
as payload. This will require data from the FCS about position and will need data storage
21
and possibly transmission to the research vessel. Some commercial FCSs like the Piccolo
[43] include some of this functionality (2 serial interfaces and 4 analogue inputs).
Although convenient, this places an extra load on the FCS as well as potentially requiring
rewriting of the FCS software for different payload combinations.
Separating the payload management from the flight control reduces the complexity of
the FCS making it more reliable and leaving more processing time for advanced
algorithms. Commercial data logging systems like the DT50 [44] have flexible inputs and
can record 16‐bit analogue data at rates up to 100 kHz. One of the disadvantages of this
kind of system is the inability to transmit selected data on demand to the research
vessel, which may be in only intermittent contact with the UAV. It is also unable to
perform even basic analysis on the data; perhaps to flag an important change that the
scientists might want to examine in more detail.
Separating the data logging from the FCS creates a far more flexible and maintainable
system. The level of sophistication required in such a system is such that an off‐the‐shelf
data logger would not have the flexibility required. The NOC have already developed a
low‐power data logger that should fulfil the immediate requirements of the project [45]
and provide the processing power to perform more advanced operations as these
become necessary.
2.4.5 Conclusions
The use of MEMS sensors has become the standard method of measuring inertial
variables in all the commercial FCSs examined. This hardware is relatively cheap to
develop and manufacture compared to the cost of the final product. The value in the
commercial systems is in the software algorithms for state estimation and flight control.
Purchasing a commercial system would mean that the both the software and hardware
are paid for each time. An internally developed system would only face the cost of
replacement hardware as the software could be programmed into the new board. As the
requirements are for the lowest possible vehicle cost, it makes sense to develop the
system internally. This allows the maximum amount of flexibility as well as making the
vehicle a development platform for more advanced control techniques and flight system
research.
Kalman filtering is essential for accurate state estimation and the requirements of
implementing an Extended Kalman Filter (possibly a fixed‐point version) must be
22
considered when determining hardware requirements. The processing requirements for
PID and PDF controllers are very similar although it would be worth ensuring that more
advanced controllers could run on any hardware to future‐proof the design.
2.5 Safety
The most important issue when considering the operation or certification of any
unmanned vehicle is the safety of the operators and those who may be affected by the
operation. In the case of UAVs, this includes any people or property flown over by the
aircraft. Papers are examined that discuss safety issues relating both to UAVs and to full
size aircraft due to the small body of working directly related to UAVs. The implications
for a low‐cost UAV and the practicality of implementing the recommendations, is
considered.
Presently there is only limited documentation available on the future certification
requirements for UAVs. The governing body for the UK, the Civil Aviation Authority
(CAA), is involved in a continuing process of refining its position and released the
second edition of its UAV guidelines [46] at the end of 2004. These guidelines will form
the basis of any future legislation that is considered necessary.
The fundamental principle laid down in the CAA guidelines is that any UAV must meet
or exceed the safety standards for manned vehicles if it is to operate in controlled
airspace. This creates a significant problem for small UAV projects that wish to fly over
land or around the coast of the UK. To meet these requirements the aircraft must be
able to sense other aircraft with the same (or better) ability as a human pilot and take
avoiding action. They must also have all the communication systems to be “seen” from
air traffic control as if they are a conventional vehicle.
Casarosa [47] evaluates the impact of safety requirements on UAVs by considering all
the components required to achieve manned aircraft levels of safety (10‐9 failures per
flight hour). They identify the fundamental aircraft components and additional
equipment to provide the required safety level such as, a visual flight reckoning system,
a transponder and a traffic collision‐avoidance system (RADAR). Summing the masses of
these gives an overall minimum weight of 150 kg for the onboard systems and a take‐off
weight of 450 kg. This leads Casarosa to conclude that a fully certifiable UAV must have
a wingspan of around 7.7 metres. The size and complexity of a vehicle with these kinds
23
of features makes it unlikely that it could fit into the low‐cost gap identified in section
2.1.
In assessing methods of certification for civil UAVs, Haddon and Whittaker [48]
compare the operation of UAVs in the military environment with potential operations
undertaken by civil UAVs. They conclude that it would not be possible to operate civil
UAVs simply with a code of requirements. This is because the CAA would have no direct
control or even information about the kinds of missions being flown. Their solution is
that a set of airworthiness standards should be derived from the existing set for manned
aircraft. This also retains the scope for individual criteria that are dependent on mission
type. So for example, a mission in an environment where there is little risk may incur a
more relaxed approach.
Haddon and Whittaker then examine both unpremeditated descent and loss of control
scenarios. An unpremeditated descent is a failure that results in the inability to maintain
a safe altitude above the surface. This is dominated by the reliability of the propulsion
system. A loss of control scenario uses the terminal velocity of the aircraft to calculate
kinetic energy and it is dominated by control system reliability. Their conclusion is that
aircraft, which on failure simply ditch at the location of the failure, are far less likely to
gain approval than those that can maintain some control and return to a known safe
area for recovery. To achieve this level of performance on failure it may be necessary to
include multiple independent control systems or a system that can detect and adapt to
failures if they occur.
When UAVs are operating in the same airspace as regular air traffic there is potentially a
danger to other aircraft. UAVs are often small, fast and hard to see so they need to be
able to identify themselves to other aircraft and air traffic control in the same way as a
conventional aircraft. It is also generally agreed that they should operate under the same
Visual Flight Rules (VFR) as light manned aircraft. Le Tallec [49] examines how this may
be possible. Light aircraft usually rely on the “see and avoid” principle although this can
fail when there is a high closing speed or through lack of pilot vigilance. In UAV terms,
this would need to be translated to “sense and avoid”. This has traditionally meant active
systems like RADAR however; even modern man‐transportable systems are much too
heavy, delicate and expensive to be carried on a small UAV.
24
Le Tallec then goes on to examine the use of a Converging Traffic Alert System (CTAS)
developed and tested in France. This system includes the ability to measure the aircrafts
position, transmit this data to other aircraft and to inform the pilot of danger. A system
of this kind would be more suitable for small UAVs than existing Automatic Dependent
Surveillance‐Broadcast (ADS/B) systems as they are designed for wide‐body aircraft and
are consequently much too large and heavy. It would also be compatible with the Traffic
Collision Alert System (TCAS) used by ground control although the CTAS messages are
much simpler. Le Tallec concludes that this system would be highly popular with
airspace authorities, and could be made available for less than $1000. This system could
allow small UAVs to operate in controlled airspace but it relies on all air traffic carrying
it as well as support from ground stations. It is expected that it will be more than a
decade before such a system is viable option.
The findings of the presented publications have serious implications for this project. To
fly in any airspace some kind of approval will be necessary from the relevant authority.
By considering the potential requirements they will have at any early stage it is possible
to improve the chances of gaining such approval. The main advantage the project has is
the type of operations undertaken (section 2.1). These will initially be over unpopulated
areas (offshore), with no air traffic under the UAV flight ceiling of 200metres.
Ensuring that a single point failure of the control system does not cause the whole
aircraft to fail will also be critical. Redundant surfaces and actuators, identified by
Casarosa [47] as the most vulnerable point, will be critical in improving robustness.
Quantifying the potential failure rates of many components including actuators will be
important through identification of the most common failure modes and testing to
destruction.
As soon as flights to investigate coastal features or in more areas of greater air traffic are
required, some method of deconfliction will be necessary. In the case of CTAS, this could
possibly be carried by the UAV itself or it could be carried onboard ship and relay UAV
information to other aircraft. Avoidance should be straightforward as the UAV will be
relatively manoeuvrable and able to change altitude rapidly without danger.
There is little information on UAV safety that can be applied directly to the project.
However, extrapolations can be drawn from the publications presented. By following
these outlines, it should be possible to develop a low‐cost aircraft that performs in a
25
manner acceptable to certifying authorities within the scope of its operation. Full
certification can never be expected for a civil UAV of this type because of the extremely
high costs. The CAA also requires the manufacturer to be authorised in advance for this
type of development.
2.6 Conclusions
A gap in oceanographic sensing techniques has been identified and this gap could be
filled by a UAV. This UAV would need the ability to be launched and recovered by a
NERC research vessel. It should carry standard equipment like the cameras [8, 9]
described in section 2.1 (500 grams and 3 litres without batteries) and have room for
additional sensors. This gives a total payload requirement of at least 1.0 kg and 10 litres.
To examine the features of interest it must be able to cover distances > 1000 km within a
working day (8 hours) which gives a cruise speed of around 35 ms‐1. The combination of
these requirements points to a vehicle that is high performance and very specialised.
The commercial UAV market has several solutions that nearly meet the requirements set
out in section 2.1. All of them, however, have a cost of ownership that is higher than the
£5,000 per vehicle necessary. The absence of an appropriate commercial system indicates
the need to develop one internally. The use of a commercial FCS within a custom
airframe was rejected, as this would also increase individual vehicle cost beyond the
£5,000 constraint.
Little formal consideration is given to safety and reliability issues in non‐military UAV
systems. While it is not possible for a UAV developed on this scale to meet the
requirements of the CAA’s certification programme, there are steps that can be taken to
move in that direction, in airframe (Chapter 4) and control system (section 5.2)
development. Improvements in technology and new legislation may make it reasonable
for UAVs to operate using ADS/B or similar system in the future. Any new vehicle design
should consider the impact this would have on payload and power supply should it
become necessary.
26
Chapter 3
System Design
3.1 Introduction
The requirements established in section 2.6 were used to develop an approach to the
design process for the vehicle. This approach (section 3.2), coordinates all aspects of the
work. The original project in 2003 [1] performed a preliminary design for the vehicle
based on similar requirements and some of the elements are retained, including
approximate dimensions for the aircraft. The refinements made to these are discussed in
Chapter 4.
3.2 Approach
The design approach for the complete system is that certification level reliability should
be aimed for where possible whilst keeping development and unit cost as low as
possible. One of the key ideas is to use low‐cost components but to monitor them
closely for signs of failure and to offset poor performance by using sophisticated
software. The application of this approach is described in more detail as it relates to each
stream in the project (Chapter 4, Chapter 5).
3.3 Modes of operation
The CAA is not only concerned with the robustness of the vehicle but also the types of
operation it will perform and in what airspace. It is hoped that the operations planned
for the NOC UAV will allow for some relaxation of the other requirements. The reason
27
for this is that they will not take place in controlled airspace or above any populated
areas. Three modes of operation have been defined with increasing levels of reliability
necessary in the vehicle and will be implemented sequentially and in discussion with the
CAA, as the project develops.
3.3.1 Mode 1 – Short range
Mode 1 is suitable for directing ship operations to areas of interest. The UAV flies a box
pattern ahead of the vessel to detect fronts and upwelling.
Restrictions
• Always within line of sight
• Flight area is monitored visually and by ships RADAR
• Altitude between 100 and 200 metres
• Constant radio communications between ship and UAV for course correction
and status monitoring
• On loss of communications link vehicle holds position by circling until contact
re‐established or auxiliary engine cut off activated
3.3.2 Mode 2 – Deep Sea
Mode 2 is for operations in the deep ocean, well away from other shipping and low flying
aircraft. This can be used for mapping large features or searching for areas of interest.
Restrictions
• Altitude between 100 and 200 metres
• Constant communication between ship and UAV by either radio or satellite for
course correction and status monitoring
• Course planned to avoid shipping areas and heavy weather
• Loss of communication causes UAV to return to last known ship position
3.3.3 Mode 3 – Traffic
Mode 3 is operationally the same as mode 2 except that it takes place in areas where
other traffic may be present. These may be coastal but still unpopulated. The restrictions
are the same as mode 2 but with the addition of those listed below.
Restrictions
28
• Sensing of other aircraft using ADS/B
• Transmission of position and intentions using ADS/B
• Ability to automatically take avoiding action in case of potential collision
3.4 Flight conditions
The design of the vehicles structure, propulsion and control systems need to be based on
a set of common performance parameters. These parameters are not the final values for
the finished system but a set of interim targets. They should represent the most common
case (cruise) as well as the extreme conditions encountered at launch and landing.
3.4.1 Cruise condition
Cruise condition is defined by the need to achieve optimum range and endurance.
• Lift/ drag performance > 10
• Speed of approximately 30 ms‐1 (to cover required distance in one work day)
• Fuel consumption < 300 g/hr (to get required endurance from fuel load)
• Ability to perform well over the weight change due to fuel load
3.4.2 Landing condition
Landing requires the slowest possible approach to reduce the impact with the water.
• Speed of < 17 ms‐1
• Good rudder authority to allow cross wind landing
• Waterproof payload bay
3.4.3 Launch condition
Launch requires that the aircraft can be accelerated rapidly.
• 6 G loading in forward direction
3.4.4 Climb condition
Climb condition is important not only after launch but also to define the performance
required in heavy weather conditions.
• Climb rate of > 1:10 when fully loaded
29
3.5 Conclusions
The design approach, modes of operation and flight conditions combine to give a
complete definition of the system. Using this, the detailed design process can begin. The
airframe and propulsion development are described in Chapter 4 and FCS development
in Chapter 5.
30
Chapter 4
Airframe
4.1 Introduction
The requirements for the vehicle described in sections 2.6 and 3.4, demand an airframe
that is resilient and aerodynamic. These requirements are summarised below:
• Range in excess of 1000 km
• Endurance longer than 8 hours
• Payload mass of up to 2 Kg
• Payload volume of up to 10 litres
• Capable of launch from a ship
• Recoverable after landing and immersion in sea water
• Structural cost of less than £1,500 to meet total cost requirement of £5,000
4.2 Aerodynamic development
The first prototype vehicle developed in 2003 was designed entirely using classical
aerodynamic methods (Figure 4.1). This vehicle was successfully test flown using landing
gear for recovery (not shown in figure). Despite the success of the test flight, the vehicle
did not meet the requirements due to its poor aerodynamic performance, over powered
engine and weak wing construction. The next few years of undergraduate projects
focussed on attempting to improve these areas.
Th
pr
se
Th
pe
At
de
4.
di
th
re
(C
de
Th
he sizing a
roject. A pu
elected so th
he size was
etrol require
t the start o
eveloped fo
5). Howeve
ifferent des
hem. The un
edeveloping
CFD). This r
esign [50].
he recomme
• Use o
• Wing
• 3.2 me
• Use o
• Sink w
• Use o
and configu
usher config
hat sensor p
s determine
ed to run th
of this proj
or the fusela
er, only limi
igns from e
ndergradua
the wing a
resulted in s
endations m
of the Selig 9
g cross sectio
etre wing sp
of a straight
wing into fu
of split flaps
uration of th
guration, w
payloads wo
ed by the pa
he engine fo
Figur
ect, more a
age and win
ited progres
each year o
ate GDP gro
as they had
summer pla
made by End
9037 wing se
on; at root 2
pan
sided fusela
uselage body
as oppose t
he vehicle
where the en
ould be able
ayload volu
r the requir
re 4.1 ‐ NOC
advanced co
ng by a ser
ss had been
of the proje
oup starting
d particular
acement for
dicott were:
ection
204.21 mm, a
age to elimin
y
to simple fla
was determ
ngine is at
e to sample
ume and ma
red enduran
UAV mark 1
omposite co
ries of unde
n made in a
ect and littl
g in summe
skills in C
r one of the
at tip 122.55
nate acceler
aps to impro
mined in th
the back o
clean air ah
ass followed
nce.
onstruction
ergraduate g
aerodynamic
le evidence
er 2005 wer
Computation
students an
5 mm
ration of flo
ove perform
he first yea
of the fusel
head of the
d by the vo
methods h
groups (see
c performan
e to support
re given the
nal Fluid D
nd a report
ow under the
mance
31
r of the
lage was
e engine.
olume of
had been
e section
nce with
t any of
e task of
ynamics
into the
e wing
32
• Design for a more pointed nose
These recommendations were refined and the fuselage redesigned to provide the
minimum cross section to accommodate the engine, fuel and expected payload. Its
length was set by the need to counter balance the tail and engine against the payload
and avionics around the centre of lift of the wing. The result of this design work is shown
in Figure 4.2.
Figure 4.2 ‐ Artists rendering of NOC UAV mark 2 design
The main differences between the two designs are summarised in Figure 4.3. The volume
of the fuselage has been substantially reduced although still meets the requirements set
out in section 2.6. However, the CFD calculated lift to drag ratio at cruise is substantially
improved doubling the effective range of the aircraft.
Mark 1 Mark 2
Wing span 2600 mm 3160 mm
Flaps None Split flaps, 30%, 1000 mm
Overall length 2450 mm 2055 mm
Predicted Lift/Drag 4 10
Payload volume 20 litres 10 litres
33
Fuel tank volume 7 litres 5.8 litres
Engine 2‐stroke, 28 cc 4‐stroke, 25 cc
All Up Mass (AUM) 15 kg 15 kg
Figure 4.3 ‐ Design differences between mark 1 and mark 2
4.3 Wind tunnel work
To confirm the data calculated by CFD a half scale model of the mark 2 design was
manufactured to test in the wind tunnel. The objective was to demonstrate the improved
L/D performance (validating the CFD results) and to test a selection of flap designs, as it
was not possible to model them successfully using CFD.
Figure 4.4 ‐ Wind tunnel results L/D
Figure 4.4 shows the results of the L/D testing. At an angle of attack of 1°, the L/D ratio
hits a peak of 11, slightly better than the CFD result. This difference may be because CFD
tends to overestimate drag.
-5
0
5
10
15
-4 -2 0 2 4 6 8 10
Lift
/ Dra
g
Angle of Attack (degrees)
34
Figure 4.5 ‐ Wind tunnel results, flaps
The target landing speed for the aircraft is <17 ms‐1 and so flap data was calculated just
below this at 15 ms‐1. Figure 4.5 shows the results for different flap designs set to 30°
deployment. The flap designs are measured as a percentage of the wing chord and all
designs run the entire length of the wing before the ailerons (1 metre each side). As
shown in the figure, increasing the flap size increases not just the maximum lift of the
wing but also the lift for a given angle of attack.
The most effective design is the plot marked EXT. This design is an extending flap that
not only deploys to 30° but also extends the chord of the wing by 20%. This is better
performing but more mechanically complex and therefore was not selected for the
vehicle at this time.
The maximum mass of the aircraft is 15 kg so to remain in the air ≈150 N of lift must be
generated by the wing. As shown in the figure none of the designs could reach the
design point of 150 N at 15 ms‐1, in fact they only reach this amount of lift at 17 ms‐1. This
is acceptable as the flaps are only to be deployed during landing where speed will be
reduced gradually to make the aircraft lose lift so it descends while being pitched nose
up. In addition, at landing the fuel weight will be approaching a minimum giving an
40
60
80
100
120
140
160
-5 0 5 10 15 20
Lift
(New
tons
)
Angle of Attack (degrees)
10%20%30%40%EXT
35
aircraft mass of approximately 12 kg. This is accomplished with a small safety margin at
15 ms‐1 with the extended and 30% flap designs.
The flap selected for the vehicle was a 30% flap deployed to 30°. This was the best
compromise between lift performance at lower speeds and the drag created that would
need to be overcome by the engine.
4.4 Engine development
To meet the range performance requirements set out in section 2.6 an extremely
efficient engine is required. Commercial UAV engines like those developed by RCV [51]
perform extremely well and use heavy fuel but are very expensive. At the time of writing
all RCV’s engines are also too large to be suitable for the project but collaboration is
being discussed that may fund the development of smaller, lower cost versions.
The mark 1 vehicle used a 28cc, 2‐stroke petrol engine that generated 1.3 kW peak power.
The 2‐stroke cycle is inherently inefficient due to the unburned fuel passing through the
system and the engine was more powerful than required for the more aerodynamically
efficient mark 2 vehicle. At cruise condition (see section 3.4.1), the wind tunnel data
indicates that 14.6 N of thrust will be required which is 503 W (given an 85% efficient
propeller).
Moving to a 4‐stroke engine would offer an immediate improvement in performance, the
Honda GX25 was identified as the smallest 4‐stroke petrol engine available and its
specifications are shown in Figure 4.6.
Parameter Value Units
Capacity 25 cc
Cycle 4‐stroke
Maximum power 810 watts
Speed at maximum power 7000 rpm
Maximum torque 1.25 Nm
Speed at maximum torque 5000 rpm
Fuel consumption 340 g/kWh
Fuel Unleaded petrol
Carburettor Diaphragm type
36
Ignition Transistorised magneto
Figure 4.6 ‐ Honda GX25 specifications
As the engine would have to operate in very different conditions to those it was designed
for, it was decided to perform a characterisation. This work was performed with the
assistance of a third year engineering student who operated the test system, took the
measurements and produced an analysis of the data.
The test system was rebuilt based on a previously used design and improved and
maintained as part of this project. The system was set up in an open‐ended cargo
container to allow air to flow through and exhaust gases to be vented. The engine was
mounted on a rig measuring reaction torque, RPM, temperature and fuel flow. This data
was captured using LabView and the throttle was controlled with the same system that
operates in the UAV. A set of differently pitched propellers were run at a range of RPMs
and fuel flow recorded for each.
The work on the system included:
• Improvements to the fuel flow measurement to isolate vibration, wind noise and
improve resolution
• Addition of connectors to allow the electronics to be moved indoors for storage
• Control of throttle using a linear actuator and hobby transmitter
• Signal conditioning enhancements
• The LabView system for data acquisition and display
• Site risk assessment
• Training of undergraduate student in equipment use and safety precautions
• Procurement of all equipment including selection of propellers
• Day‐to‐day setup and oversight of work
37
Figure 4.7 ‐ Honda GX25, power v.s. fuel consumption
The results of the testing (Figure 4.7) show that the GX25 met the fuel consumption
figures quoted for it. When generating the 500 W required for cruise it consumes around
275 g/hr (using a least means squared polynomial fitting on the data boundary). The
mark 2 design can carry up to 5.8 litres (4.2 kg) giving an endurance of 15.3 hours and a
range of 1600 km at 30 ms‐1.
4.5 Manufacture
The structural design of a full size aircraft requires a very careful balance of weight and
strength. These structures are certified using simulation and testing to demonstrate that
they have a safety factor of at least 1.3 over the expected maximum strength required. It
is expected that the CAA will require at least the same factor for UAVs.
The loads experienced during handling and transportation are far greater than the flight
loads for a small UAV. As such, these will determine the minimum strength of the
structure, resulting in an in‐flight safety factor that is relatively high. In addition, the
NOC UAV has two unusual phases of flight that require additional strength, the high G
100
150
200
250
300
350
400
450
500
0 100 200 300 400 500 600
Fuel Con
sumption (g/hr)
Power (Watts)
38
loading during launch and a potential impact during landing. These will also be
important in determining the required strength. The minimum strength / weight
achievable with the material available is very high so the numerical structural analysis of
the vehicle is left to the undergraduate student groups, see section 1.5 for more
information on the distribution of tasks.
As part of undergraduate projects over the last four years many composite construction
techniques have been attempted. The requirements for the technique are:
• Good external surface finish
• Light weight part with minimum resin
• Strong, low velocity impact resistant parts
• Manufacture by students / personnel with limited practical skills
• Resulting parts are easily assembled
• Process can be repeated reliably
• Moulds can be modified to experiment with different designs
After much experimentation the current recommended technique is:
• Always female moulding
• CAM cut mould or former to make mould
• Use sandwich structures with Rohacell foam or Balsa cores
• Wet layup
• Cold cure (not autoclave)
• Vacuum pressure using bag
• Use of joggles to help assembly
• Moulds to form all joints so complex joins are not required during assembly
4.6 Systems integration
Integration of the propulsion, structural and electrical systems was performed as part of
this project.
4.6.1 Electrical system
The design philosophy established in Chapter 3 was to make the best use of low‐cost
actuators and sensors. The actuators selected for the control surfaces of the UAV are
39
low‐cost hobby aircraft servos. These are cheap, flexible and fast, however, they are not
very robust and have no protection if they become stuck, causing them to be destroyed
from overheating. To mitigate these factors it is planned to monitor their performance
very closely by measuring position and current draw. To allow this to be done centrally
each servo requires four wires. This is discussed in more detail in section 8.5.
Wiring was selected by designing for the worst‐case loading caused by each servo. As
power consumption is critical, it is important that losses in the wiring be reduced as far
as possible. For the first vehicle, a 7/32 AWG core size was selected so that power loss to
the most distant servos was 0.23 W at 1 A peak load. This gave a total wiring weight of
441 grams for the whole vehicle. Future work to characterise the servos may indicate a
lower current draw allowing a smaller core size to be used. Moving to 7/34 AWG, would
reduce wiring weight by half to 222 grams.
4.6.2 Battery specification
To provide the current necessary to run all the actuators for a possible endurance of over
12 hours requires a high‐performance battery technology. The best energy‐to‐weight
ratio technology available is Lithium‐Ion. However, these packs require careful
monitoring and charging to get best performance and prevent explosions. Nickel‐Metal‐
Hydride (NiMH) was selected as this is a robust technology, is easy to charge and has
good capacity. A 6 volt, 4.5 Amp hour pack weighs 300 grams.
40
Chapter 5
Flight Control System
5.1 Introduction
To meet the low‐cost requirement identified in section 2.1 it was determined that the
Flight Control System (FCS) must be developed internally, as the commercially available
solutions were too expensive or performed poorly. Figure 5.1 shows the position and
connectivity of a bespoke FCS within the aircraft system.
Flight Control SystemData Logger
Satellite Uplink
RF CommunicationsEngine
Control Surfaces
Structural Health
Monitoring
Figure 5.1 ‐ FCS interfaces to the UAV and ground station
41
The FCS needs to be evaluated as part of the complete aircraft system and must achieve
equivalent or better levels of robustness. It will be critical in monitoring the health of the
airframe, control surfaces and engine. The functions required of the system are:
• Measurement of inertial parameters making best use of low‐cost sensors
• GPS reception
• Processing of sensor data to find the state of the aircraft
• Processing of current state and required state to produce inputs to the system
• Control of all surfaces
• Monitoring of control surfaces, engine and eventually airframe
• Communications with the ground station
• Power supply monitoring and control
• Ability to continue navigating in the absence of some sensor data
• Black‐box data recording for post‐flight analysis
5.2 Approach
In section 2.4 the requirements for a suitable FCS were established, these are:
• A unit cost of under £1,000 for the hardware in order to be part of a complete
system at under £5,000
• The hardware must be robust to survive handling in a wet environment, in‐flight
vibration and possible impacts during vehicle assembly
• Software must be robust to deal with sensor and actuator failures
• Hardware and software must be developed to be potentially certifiable (see
section 2.5)
• The system must support health monitoring of the structure and control surfaces
• There should be enough headroom to allow the use of sophisticated flight
control algorithms (section 2.4.3)
To achieve the low hardware cost required the design should make use of widely
available components, particularly MEMS inertial sensors. These are used by all the
commercial autopilots available for small UAVs, they are more noisy and prone to drift
than traditional transducers but they are also more robust (section 2.4.2).
42
By combining all the systems required into a single package it should be possible to
substantially improve hardware robustness simply by reducing the risk of connector
failure and operator error. It will also be easier to protect components from water and
handling damage. The tight integration of vehicle structural and control surface
monitoring will help to combat one of the weakest areas in current small UAVs, the use
of actuators design for hobby aircraft.
A UAV developed to be so low‐cost and by an organisation other than the main
aerospace manufacturers is very unlikely to be CAA certifiable (see section 2.5) due to
the expense of meeting the documentation and formal proof requirements. These are
not just incurred during the main development but also when any software, hardware,
structural or aerodynamic change is made to the vehicle during its life. The CAA is
continuing to evolve its requirements in order to support the new commercial UAVs and
their roles, some of which will be in controlled airspace. It is likely this will result in a set
of graduated requirements that depend on the size of vehicle, the type of work
undertaken and the airspace in which the operation takes place.
The initial operations envisaged for the NOC UAV take place in the deep ocean (section
2.1). If the UAV is to be used to identify interesting features it needs to perform search
patterns which can take place within the line‐of‐sight of the ship, keeping a visual and
RADAR check of the area over flown. Constant communication with the research vessel
allows changes to be made at any time. Even with this very low risk activity, it is
important to consider how to make the vehicle as certifiable as is reasonable. This will
not only ensure its correct and safe operation but that in the future it may be possible to
fly coastal or over‐land missions.
Meeting robustness requirements for the vehicle structure is more possible for a small
UAV than with a large vehicle (discussed in section 4.5). However, for the control system
it is substantially harder. Pre‐certified components (like a standalone IMU) are too
expensive, as is self‐certification, and any software needs to conform to stringent quality
guidelines.
Given that the requirements described could not be met, a study was performed to
examine how easily they could be approximated and what this would offer to the project.
The electronic hardware, particularly in inertial measurement, is largely determined by
the need to meet the budget requirements. These components are not available in a
43
certified form as this only applies to complete devices, normally including software and
an interface either to another device or to the pilot.
Some standards do exist for these kinds of components, including some for the
reliability conscious automotive industry [52]. However, they are not universally
supported, making it difficult to choose all components to conform to a single standard.
Many manufacturers do offer components targeted specifically at automotive use and
these will be considered acceptable unless they are found to perform poorly on an
individual basis (section 5.3).
Software is even more important in a UAV than in a manned aircraft. It is in complete,
independent control of the vehicle and the ground station crew have only a limited
ability to put control into the hands of a human pilot. The software standard used in
developing avionics for the manned aircraft industry is DO178‐B. The level of
compliance required is varied according to the impact a software failure would have on
the flight. In the case of a UAV control system, this is considered ‘catastrophic’. To
develop for DO178‐B from scratch would require a team of developers, skilled not just in
coding but also in generating the necessary documentation.
To reduce the cost of implementing software to this standard it is possible to buy Real‐
Time Operating Systems (RTOSs) that have been previously certified in other
applications. This then provides a base of code that will not need to be examined so
closely during certification. Integrity from GHS [53] can be used in this way although at
£10,000 for a single, non‐commercial license it is still extremely expensive. There would
also be a steep learning curve and any new code written for it would still need to be to
DO178‐B for the system to be certifiable.
Running any kind of Operating System requires additional processing overhead as in
addition to the algorithmic code to control the aircraft it must perform frequent status
checking on different processes. More processing requires a more sophisticated and
faster processor that will draw more current, increasing the power consumption of the
system.
It is possible to develop certifiable software without doing all the work from scratch and
without using a RTOS by using a modelling and code synthesis suite, like SCADE from
Esterel Technologies [54]. This allows control algorithms to be modelled in a graphical
environment and tested to ensure they perform correctly. The code generator then
44
creates DO178‐B certifiable code. This does not certify the entire system as this must
include the hardware certification; however, it does go a long way to create confidence
in the most critical and difficult to test part of the software.
There are also tools available to help with the development of software for use in
automotive applications. These generally ensure that the software conforms to the
MISRA standard [55]. This is a less sophisticated standard than DO178‐B and there is no
formal certification process so software tools tend to implement a variety of levels of
functionality.
It is possible to achieve the combination of low‐cost and some software and hardware
reliability in a number of ways. However, two distinct options can be drawn out and
these are shown in Figure 5.2. The first is use of a third party RTOS built around a large
processor, probably supported by an additional smaller processor to perform data
collection. The second is the use of a smaller processor that is programmed directly and
a system such as SCADE is used to generate the algorithmic code with a MISRA code
checker used to analyse the lower level functions.
RTOS No RTOS
Hardware complexity More Less
Hardware development time More Less
Software complexity More Less
Software development time Equal Equal
Processing requirements More Less
Partly certifiable Yes Yes
Cost of Development tools Equal Equal
Cost per unit More Less
Figure 5.2 ‐ Comparison of FCS options
From Figure 5.2 it is clear that avoiding the use of a RTOS reduces many of the system
requirements while still allowing a high‐level reliability to be achieved. This choice
affects not just software development but also the hardware design described in section
5.3.
45
5.3 Design
Figure 5.3 shows the major components selected for use in the FCS. Each component was
chosen by examining the market for the type of device required and evaluating it on the
following criteria:
• Performance
• Robustness
• Cost in small quantities
• Availability in small quantities
In addition to those listed, numerous other supporting components were chosen in areas
like analogue to digital conversion and power regulation.
Component Device Selected Notes
CPU Freescale, MAC7116 Automotive grade CPU
High performance ARM7 core
Low power consumption
Multiple serial interfaces
GPS Fastrax, iTrax130 Up to 4 Hz operation
WAAS and EGNOS support
Gyroscope (Z axis) Analog Devices, ADRXS300 Low‐cost, easily available
Gyroscope (XY axes) InvenSense, IDG‐300 Two axes in a single device
Simplifies mounting requirements
Accelerometer Freescale, MMA7260Q Three axes in single device
Low cost and easily available
Compass PNI, MicroMag3 Three axes in single device
Simple interfacing requirements
Absolute pressure Freescale, MPX4115A Fully integrated sensor
Low cost due to mass production
Automotive grade
Dynamic pressure Freescale, MPXV5004 Fully integrated sensor
Low cost due to mass production
Automotive grade
Radio modem Aerocomm, AC4868 Low operating frequency gives large range
Black box Multimedia card High speed data recording
Simple interfacing requirements
46
Previous experience with these devices
Enclosure ModICE Automotive grade
Waterproof and robust
Figure 5.3 ‐ Component selections for FCS
It is beyond the scope of this report to detail the design methodology and specification
of the complete autopilot including all components and subsystems. Section 5.3.1 gives
an example of the method used for the pressure‐sensing element of the design.
5.3.1 Pressure sensing
One of the critical areas for the control system that was identified by the algorithm
development EngD project was for accurate pressure sensing (Bennett [41]). Absolute
pressure is used to estimate altitude and dynamic pressure to estimate airspeed; these
supplement the inertial sensors and the GPS providing high‐rate data. The original
sensors on the hardware for this project were interfaced using a 10‐bit analogue to digital
converter across their entire pressure range, giving an altitude resolution of several
metres. Bennett improved on this design by using a 16‐bit analogue to digital converter
and limiting the range to a 200‐metre ceiling. This gave a theoretical maximum
resolution of 3.5 cm.
Bennett [41] considers this enough resolution, and that the resolution is limited by the
fundamental sensor noise, however, the range of 200 metres may be too small for some
applications where imagery of large areas is required. The design also used voltage
dividers to create the voltage references. These are at best around 1% accurate and
output voltage will shift with the temperature difference between the two resistors.
Standard resistors can have a temperature coefficient as much as 5000 ppm/˚C.
To improve on this design a 24‐bit sigma‐delta analogue to digital converter was used,
not to improve resolution (as Bennett has already shown this to be limited by the
fundamental sensor noise) but to increase range. By keeping the Least Significant Bit
(LSB) size the same, the greater number of bits allows a larger voltage range to be
measured at the same resolution.
This greater flexibility in range allowed the use of off‐the‐shelf precision voltage sources
that have much greater accuracy (0.05%), low noise (41 µVRMS) and lower temperature
drift (10 ppm/˚C) than voltage dividers. Although the fundamental device noise in a
voltage source is higher than in a resistor, they reject noise from the power supply,
47
which would propagate through a voltage divider circuit. The laboratory test results of
the design for the absolute pressure sensor converter are shown in Figure 5.4.
Parameter Value Units
Effective number of bits 21.3 bits
Effective resolution 1.7 mm
Noise free bits 18.6 bits
Noise free resolution 11.3 mm
Range 4494 metres
Voltage offset 3.3 volts
Voltage reference 2.048 volts
Converter gain 2 n/a
Figure 5.4 ‐ Absolute pressure sensing converter design
The dynamic pressure sensor and other systems were designed using the same method.
Existing systems were analysed and then the latest components were used to improve
performance. All are sampled at a much higher precision than necessary so, when
combined with careful layout and the use of clean power supplies this should make the
most of the low‐cost sensors used. The results of this work are shown in section 5.4.
5.3.2 Layout
The components were brought together in a single circuit schematic shown in Appendix
1 and the analogue sections were simulated. The final layout of the FCS is shown in
Figure 5.5. The layout required careful consideration to ensure that the analogue
performance requirements were met and that the board fit securely in the enclosure.
The board is four layers, with power and ground planes split to isolate analogue and
digital sections. The power supplies are individually selected for each section to provide
either very low noise for analogue or very high efficiency for digital sections.
The PCB was manufactured and the majority of components placed by Newbury
Electronics Ltd [56].
48
Figure 5.5 ‐ FCS layout
5.4 Results
The completed system is shown in Figure 5.6. A few minor errata were corrected and the
software was developed to read the sensors and perform other low‐level tasks. This has
not yet undergone any robustness analysis or testing so is not suitable to control the
UAV. However, it is possible to measure parameters on the bench and to assess the
performance of some devices statically.
To
pr
sa
co
th
Se
Ab
Ab
Gy
Gy
Ac
Th
w
se
gy
ax
o assess the
ressure sen
amples). Th
onverted int
his analysis.
ensor
bsolute pre
bsolute pre
yroscope X
yroscope Y
cceleromet
he pressure
ould appea
ection 5.3.1,
yroscope sh
xis channel
e performa
nsor, gyrosc
his data wa
to the real
essure
essure
X axis
Y axis
ter X axis
e sensor noi
r that using
this has a
hows excelle
making thi
Figure 5
nce of the
copes and a
as then pr
number of
Samp
Figure 5.7 ‐
ise‐floor is
g the 24‐bit
allowed a
ent perform
is well wort
5.6 ‐ Flight C
sensor me
acceleromet
rocessed to
bits being m
ple precisio
24.0
1.7
16.0
16.0
16.0
‐ Results of F
above the r
t converter
much wide
mance with a
th convertin
Control Syste
asurement
ters were s
find the
measured. F
on Measu
FCS sensor te
resolution o
is unnecess
er dynamic
a maximum
ng the signa
m
techniques
sampled for
standard d
Figure 5.7 s
ured precis
15.6
56.0
13.2
15.0
10.8
esting
of a 16‐bit c
sary. Howev
range to
m of 15‐bit re
al at 16‐bit.
used the a
r 10 second
deviation an
shows the re
sion U
converter a
ver, as desc
be measur
esolution on
The accele
49
absolute
ds (1000
nd then
esults of
Units
bits
mm
bits
bits
bits
and so it
cribed in
red. The
n the Y‐
erometer
50
performs relatively poorly offering little advantage over using a 10‐bit converter. It is
possible that an alternative part could be found to replace this in the future.
One of the key requirements established in section 2.6 was for a range of > 1000 km. To
help achieve this, as few battery packs should be carried as possible, so the electronics
should consume as little power as possible. The board consumes around 2 watts when
reading all sensors, processing the data and transmitting over the RF link. Due to an
error in the power supply layout it is currently only around 55% efficient where it should
be 90%. This is easily corrected in future revisions of the board. Using the 4.5 Ampere‐
hour battery packs described in section 4.6.1, the current board could operate for 13
hours.
5.5 Conclusions
The FCS developed for the NOC UAV project has a rich feature set tailored to the
specific needs of the project. All sensors are operational and more than 300,000 integer
operations are available after data collection and filtering for every loop of the control
algorithms. This is enough to execute the floating point Kalman filter and PDF controller
used by Bennett. Using a more sophisticated algorithm for control would require
converting some or all of the algorithms to fixed point. The final specification is shown
in Figure 5.8. The power consumption of <1.8 watts compares very well to that of the
Cloud Cap Piccolo [43] that draws 4.8 watts. Data collected by the FCS during flight is
presented in Chapter 6.
Feature Quantity
Processing > 40 MIPS integer
IMU 3 axis acceleration
3 axis rotation
3 axis magnetic
GPS WAAS/EGNOS enhanced at 4 Hz
Barometric altitude 0 ‐> 1000 metres
Dynamic pressure 0 ‐> 45 ms‐1
RF communications Range > 10 miles
Black box 4 GB at 200 kBps
Actuator control 8 channels
51
Actuator monitoring 8 channels
Pilot override Integrated and independent (all channels)
Power consumption < 1.8 watts (operating)
Figure 5.8 ‐ FCS feature list
The FCS hardware is now ready for integration with the rest of the vehicle. While this is
taking place, the control algorithms developed by Bennett will be adapted to operate on
the new hardware with the aim of flying the trainer aircraft automatically.
52
Chapter 6
Instrumented Flight Test
6.1 Introduction
Flight test 4 on the 11th of September 2007 was unsuccessful in that the vehicle seemed
underpowered. The vehicle was accelerated to approximately 50 mph before release
from a car‐mounted cradle, the aircraft then climbed for around 5 seconds before
stalling and falling. However, the Flight Control System (FCS) was onboard the aircraft
and successfully recorded all parameters, allowing the vehicle’s performance to be
examined in detail.
6.2 Performance analysis
The engine performs as expected given that it should reach 5500 RPM at 30 ms‐1 and
there seems to be no reason to think that a fuel/air flow or throttle problem caused
unusual performance.
Figure 6.1 shows the speed of the vehicle in ms‐1 (red) and the engine RPM (blue) against
time. Speed has been scaled by a factor of 1.5, as the sensor had not been calibrated at
the time of the test. The vertical green line indicates the point of release from the launch
cradle, to the left of the line the speed can be seen increasing as the car accelerates.
Initially the RPM drops as the car starts accelerating as when stationary a large part of
the propeller is stalled, reducing the torque required. After this, the RPM increases with
53
speed. At 11 seconds, the car has reached 50 mph and then holds this speed and this is
shortly followed by the release.
At release, the UAV is travelling at 22 ms‐1. According to the wind tunnel measurements
for an all‐up‐mass of 11 kg, this forward speed is enough to support the aircraft at an
angle of attack of 3 degrees. After release the speed reduces as it is exchanged for
altitude and the engine RPM drops as it becomes more heavily loaded.
The engine performs as expected given that it should reach 5500 RPM at 30 ms‐1 and
there seems to be no reason to think that a fuel/air flow or throttle problem caused
unusual performance.
Figure 6.1 ‐ Speed (red) and RPM (blue)
Figure 6.2 shows speed (red) and altitude (blue) against time. The vertical green line
indicates the point of release from the cradle. After release, the vehicle exchanges
airspeed for altitude climbing to a peak of 25 m. The two vertical cyan lines mark the
period that the vehicle was climbing. In this period, the average airspeed was 13.5 ms‐1
and the climb rate was 5.95 ms‐1 giving a ratio of 1 in 2.2. The expected maximum climb
0 5 10 15 20 250
5
10
15
20
25
Spe
ed (m
s-1)
Time (seconds)0 5 10 15 20 25
4000
4500
5000
5500
RP
M
54
rate that maintains constant airspeed is 1 in 20. After altitude peaks at 25 m, the aircraft
is fully stalled and out of control. Some speed is regained during the descent but never
enough to resume controlled flight.
Figure 6.2 ‐ Speed (red) and Altitude (blue)
6.3 Conclusions
The test flight demonstrated the value of data logging with the high performance FCS
and validated this unit’s performance. This data reveals how and why the vehicle
performed as it did which could not be assessed visually on the day or with video
footage. It also demonstrated that the vehicle was performing as expected but also that
in its current state it will prove difficult to fly manually. It does not perform like a hobby
aircraft but more like a glider, requiring very gentle climbs and good conditions.
Watching the flight video (FlightTest4.avi on accompanying CD) it is impossible to tell
that there is a problem until it is too late. The direction of flight, directly away from the
pilot, means that the loss of airspeed cannot be seen and it appears to be climbing well
0 5 10 15 20 250
5
10
15
20
25
Spe
ed (m
s-1)
Time (seconds)0 5 10 15 20 25
0
5
10
15
20
25
30
Alti
tude
(m)
55
until it stalls. It may have been possible to recover at this time by putting the nose down
and gaining speed but lack of authority in the control surfaces may have made this
impossible.
In the short term, it will be necessary to use a more powerful engine to allow manual
piloting for the assessment of the airframes performance. It may also be necessary to
have more power available to cope with poor weather conditions.
56
Chapter 7
Payload Management
7.1 Introduction
Although this project is focussed on developing a UAV, the most important part of any
mission will be the collection of the oceanographic data. Following the review of existing
data logging systems 2.4.4 it was determined that a custom data recording and relaying
system would be required. This is due to the requirement that the system must not only
accurately record data during the flight but also relay data to the research vessel when
requested. It may also be beneficial to perform some simple analysis on the data to
identify features that may alter the flight plan.
To provide the sophisticated features and flexibility required, it was decided to use an
existing data logger design developed at the NOC for use in chemical and biological
sensing [45]. This design would need to be adapted to suit the specific needs of the
project.
7.2 Detailed requirements definition
Version 1.1 of the Sensors Group Data Logger (SGDL) was designed for use in the Wave
Buoy project where high precision analogue data was time‐stamped and recorded for
deployments of several days at a time. The specifications for the logger are shown in
Figure 7.1.
57
Parameter Value UnitsProcessor frequency 40 MHzAverage processing rate 10 MIPSStorage capacity (maximum) 4 GBStorage data rate (maximum) 100 kBpsFile systems supported FAT32 ‐Analogue to digital resolution (see section 7.3.3) 16 bitAnalogue to digital voltage input swing 0 ‐> 5 VAnalogue to digital resolution 0.76 µVAnalogue to digital sample rate (maximum) 30 kSpsSensor reference 5 VTime–stamp resolution 1 secondTimestamp drift ≈ 5 min/yearExternal serial interfaces RS232 2 ‐USB 0 ‐SPI 1 ‐I2C 0 ‐Supply voltage 8 ‐> 11 VPower consumption (operating) 1 WPower consumption (sleeping) 10 mW
Figure 7.1 ‐ Sensors Group Data Logger v1.1 specificatons
The new revision of the SGDL will not only need to support operations as part of the
UAV payload but also the next generation of chemical sensors. This will add additional
requirements to those of the UAV, these are:
• Smaller physical size
• More flexible voltage support (5 V ‐> 40 V)
• Ultra low power consumptions sleep mode
• Low power solenoid valve drivers
• Stepper and DC motor drivers
• Temperature monitoring
• Constant current sources (temperature independent)
• Ability to survive crushing forces
During UAV operation, the SGDL will sit at the centre of a mixture of sensor types,
distributing information, relaying data and recording information. Figure 7.2 shows an
example of expected sensors and their interconnections.
58
Figure 7.2 ‐ UAV sensors and interconnections
7.3 Design
For discussion purposes, the requirements have been grouped into sections of related
issues. Each of these sections led to specific design decisions that shaped the final
system.
7.3.1 Physical size
Version 1.1 of the SGDL was a single PCB with a footprint of 60 × 70 mm and a maximum
height of 20 mm. The new generation of chemical sensors require the board and all
connections to fit roughly within the area of a credit card 80 × 50 mm. This means that
board itself will need to be even smaller than that, whilst accommodating the new
functionality required. To achieve this small footprint a two‐board system was designed,
a primary processing board with general‐purpose connections and daughterboard with
components and connections specific for each application.
As the high‐power systems and high input voltage support (section 7.3.5) would only be
required by the chemical sensing applications, these systems were placed on the
daughterboard. Stacking the boards means that height was a more important dimension
than in v1.1. Due to this and the increased number of connections to the boards new
miniature headers were selected reducing the maximum height of the boards to 12 mm.
When stacked with 15 mm spacers this gives a total height of 40 mm. Figure 7.3 ‐
59
Technical drawing of SGDL v1.2Figure 7.3 shows a drawing of the stacked system, a more
detailed drawing is in Appendix 3.
Figure 7.3 ‐ Technical drawing of SGDL v1.2
7.3.2 Voltage support and low power consumption
In some of the seaborne sensor applications proposed, only very high DC voltages are
available. To use these to power the small actuators, valves and the data logger, it is
necessary to reduce them to a more useful level. This reduction is achieved in three
stages; first, the conversion of the high‐voltage input to 12 volts is done using a high
efficiency, switching DCDC converter. This is located on the daughterboard, as it will
only be needed in chemical sensing applications. The remaining steps are both
performed by the processing board, a high efficiency switching DCDC step down to 6V
followed by a low noise linear regulator to supply the electronic components. This
cascading approach allows maximum input voltage flexibility (5 volts ‐> 36 volts) whilst
retaining high efficiency (≈ 90% per stage) and good noise performance in the analogue
sections.
To provide a low power consumption mode, the regulators and most onboard devices
can be shut down by the processor. The processor then enters sleep mode, reducing its
60
own power consumption considerably. There is a further mode where supply is taken
from a supplementary battery. This allows all regulation to be switched off, removing the
energy losses from this process. The results of these efforts are described in section 7.4.2.
7.3.3 Analogue measurement
Analogue measurement with the SGDL v1.1 was very successful, giving low noise data
(≈15 bits) very reliably. It was decided to stay with the same analogue to digital converter
family but to use a different version (ADS8345EB) that accepts a 2.5‐volt reference rather
than 5 volt, which simplified the supply requirements as well as allowing a more
advanced reference (LT1790A) to be used. The analogue to digital system’s performance
is characterised in section 7.4.1.
7.3.4 Serial interfaces
To increase the flexibility of the SGDL additional serial interfaces have been added
including I2C and USB2.0 interfaces. The USB2.0 interface allows rapid download of
information stored on the MMC card at around 2.0 Mbps compared to 0.2 Mbps when
using RS232. This will be important in applications where the card cannot be retrieved
(perhaps from inside a pressure housing). The I2C interface is used for communication
between stacked boards due to its flexible addressing technique.
7.3.5 Driving high power devices
A typical chemical sensor would include several valves and pumps to control fluid flow
and occasionally a DC or stepper motor. Optimal control of all these devices is achieved
by controlling the current flowing in their windings. In the case of the motors, a sense
resistor is used to detect peak current and this is controlled by pulse width modulating
the output signal. To reduce the standing current of the valves and pumps they are
actuated using their full rated voltage for only a very short period (≈20 ms). This can
then be reduced to half the rated voltage to hold position.
7.3.6 High pressure survivability
A common failure of electronic devices under pressure is the electrolytic capacitors
crushing, so where possible, these were replaced with ceramic or tantalum capacitors. A
footprint for a cylindrical crystal was included along with the surface mount, as these are
reported to survive better.
61
7.4 Results
7.4.1 Analogue performance
The majority of chemical sensors have an analogue output so making the best possible
measurement of this signal is crucial to getting good performance from the system. The
output signals are typically not very dynamic but require a very precise DC
measurement. Using a Successive‐Approximation‐Register (SAR) type converter allows
the most flexibility in conversion rate and is simple to multiplex so eight channels are
available on a single device.
Figure 7.4 shows a histogram of 50,000 samples of the voltage reference taken at 4.6
kHz. Each bin represents a step of 7.6×10‐7 volts so the signal peak is 0.2 mV away from
ideal. This offset could be due to a number of factors in the design but is small enough
that the error is likely to be dominated by any filtering stage ahead of it. The combined
system error could be removed by calibration. The maximum device performance
quoted by the data sheet is for 96.3% codes occurring within one bin of the peak signal.
The noise performance of the board is measured as 97.7% of codes. This improvement is
probably due to the use of a very high‐performance voltage reference both for
referencing the converter and supplying the voltage to be measured.
62
Figure 7.4 ‐ Voltage reference measurement at 4.6 kHz
A disadvantage of a multiplexed SAR converter is cross talk between channels. The
voltage reference was measured again along with a ground connection on the second
channel. This was performed at a lower sample rate of 1.7 kHz due to communication
limitations. The results of this experiment are shown in Figure 7.5 and the offset in the
converter has increased by 0.15 mV towards ground. The noise performance is still very
good at 92.9% of codes within one code of the peak. This change in performance could
be reduced by ensuring that the analogue input is driven by a low impedance source and
by increasing the acquisition time available to the converter.
0
5000
10000
15000
20000
25000
30000
‐6 ‐5 ‐4 ‐3 ‐2 ‐1
Freq
uency
Bin
63
Figure 7.5 ‐ Voltage reference measurement at 1.7 kHz
7.4.2 Power consumption
In low power sleep mode the SGDL version 1.2 is currently drawing 42 mA (290 mW).
This is low enough for operation as a UAV data logger however not enough for the
chemical sensing application. The previous data logger could be reduced to less than 0.5
mW.
7.4.3 High pressure survival
At the time of writing, it has not been possible to pressure test the new SGDL however, it
has been successfully operated in oil.
7.5 Conclusions
The SGDL version 1.2 has the capability to control complex systems over long periods
and record large quantities of high‐resolution data. Its use in the UAV project can now
continue with an undergraduate project to source, purchase and install suitable sensors
in the fuselage. These will then be integrated with the SGDL to provide control,
reporting and possibly data recording. The system that is developed will then be
evaluated by the doctorate students on the project and some or all of it incorporated
into the final design.
0
5000
10000
15000
20000
25000
30000
‐8 ‐7 ‐6 ‐5 ‐4 ‐3
Freq
uency
Bin
64
To improve the power consumption of the new data logger a new board will be
manufactured with some modifications to the USB interface.
65
Chapter 8
Conclusions and Future work
8.1 Introduction
In the first two years of this project, a great deal of progress has been made. The vehicle
has been almost entirely redesigned and aerodynamic performance has been improved
leading to greater range and endurance. The vehicle meets the criteria set out in section
2.2 and now needs to be further developed for use at sea. Future work will focus on
improving the robustness of the vehicle.
8.2 Conclusions
After four test flights, the mark 2 vehicle design has still spent only a short amount of
time in the air. The final flight included the recording of flight parameters and allowed
analysis of its performance (section 6.2). The data indicates that even though human
pilots have struggled, the vehicle would fly with the current propulsion system.
However, as many initial flights will be performed in some part by a human pilot, it is
necessary to ensure that they can fly it easily and safely. As such, a more powerful engine
will be sourced for testing. In the short flights, the vehicle appeared well balanced and
has good control authority on all surfaces.
The Flight Control System (FCS) performed well on its first test flight and recorded
detailed data for the entire flight. It also survived the impact of the crash without any
damage. This system is now ready for further software development and the addition of
66
the control algorithms as part of the doctorate project by Bennett. The novel use of over‐
sampled, low‐cost sensors has paid off by providing data of a resolution not available
with commercial autopilots.
8.3 Vehicle
The development of the vehicle for use at sea will mostly be focussed around launch and
recovery. A launcher based on an existing system used by ATS [57], one of the companies
involved as part of a commercial steering group for the project (see section 8.6).
Recovery preparation will focus on ensuring the payload bay is waterproof and designing
a system to make grappling for the vehicle simple.
Undergraduate students will design a new tail for the vehicle that can then be evaluated
by the doctorate and supervisor team. More information on this project can be found in
the project specification in Appendix 4.
The method for characterising and assessing the performance of the propulsion system
has been very successful; however, it now appears that criteria used for the design were
not correct. An attempt will be made to analyse the requirements particularly regarding
performance in poor weather conditions. This should lead to a more detailed
specification that can then be compared with commercial engines and discussed with
RCV [51] (see section 8.6).
Manufacturing improvements will continue with the development of new tail moulds
and once the design has more flight time, moving the wing manufacture to a sandwich
construction with a support spar.
8.4 Flight Control System
Development of the existing flight control hardware will continue to ensure that all the
functionality is working as expected and the hardware is robust to vibration, water and
impact. It is possible that the system could fit inside a smaller enclosure and this
possibility will be investigated if time allows.
The critical aspects in FCS development are the addition of robust control algorithms for
the full size aircraft. These will be derived from the work by Bennett on the algorithm
67
development project. Demonstrating the reliability of the software will be essential. This
will be done using MISRA for low‐level code and SCADE for the algorithmic code as
described in section 5.2. Robustness for control surfaces is described in section 8.5.
The new FCS can record detailed flight data and this can be fed back into the simulation
for use in system identification and improvement of control algorithms. This work will
be in collaboration with Bennett. Additional algorithmic development will continue as
part of this project to include the monitoring of actuators and increasing robustness.
8.5 Robustness and redundancy in surfaces
In section 2.5, the most common area of failure in all UAVs is the control surfaces. As
these are so critical, there will be a special focus on making them as robust as possible.
Following the approach determined in Chapter 3, low‐cost actuators will be used but
monitored very carefully to predict failure. Initially this work will involve the testing of
hobby actuators. Figure 8.1 shows the expected paths of failure of the servos and the
predicted method of detection.
It may be possible to apply Failure Mode, Effects and Criticality Analysis (FMECA) to
evaluate the actuator performance and software tools to aide with this will be
investigated.
In addition to the work on the existing actuators, a new type of actuator using a linear
stepper motor has been designed. It is not clear if this will be appropriate for all the
surfaces on the aircraft due to slow operation. However, it should be; more robust, use
less power, be self‐monitoring, report performance data and cost less than £100.
68
Figure 8.1 ‐ Actuator failure diagram
8.6 Planning
The work planned for the next two years of the project will be funded by a proposal
currently under submission to EPSRC. This includes money for launcher development
and time onboard the University research ship Callista to perform testing at sea. If
successful, the funding should be available from the start of 2008.
As part of the proposal, a steering group of commercial companies has been assembled
to assist with identifying and pursuing any commercial technologies that may be
developed. The group members are listed in Figure 8.2. The group will meet twice
annually to discuss progress and help establish new goals.
Company Expertise
QinetiQ Developing and operating military UAVs
Vosper‐Thorneycroft Interested in using UAVs in civilian applications
Response
Fault
Method of detection
Actuator failure
Mechanical failure
Gearbox sticks
Linkage to surfaceSurface sticks Gearbox free Servo
detaches
Electrical failure
InterferenceServo
electronics fail
No signalNo power
No response to commanded position, high current draw
Response to commanded position, low current draw
Position sensor shows
zero
No response to commanded position
Shut off servo to conserve power and transfer control effort to alternate surface
Continue to try and operate servo but transfer control effort to alternate surface
Erratic response
Report condition to base station for controlled termination of flight and add to black box record
Continue to try and operate servo but transfer control effort to alternate surface
69
ATS Group Experts in UAV operation and piloting
RCV Engines Developers of rotating sleeve engines for UAVs
Figure 8.2 ‐ Steering group members
In addition to the existing proposal, it is hoped that a bid for funding may be made in
collaboration with RCV engines to develop their technology to make it more suitable for
small fixed‐wing applications.
70
References
[1] Pluck G, Waugh E, Gilbertson R, Hoen‐Teng L, Roberts S, McKinley M, et al. An
Unmanned Aerial Vehicle for Oceanographic Applications [Masters Thesis].
Southampton: University of Southampton, UK; 2003.
[2] Lomax AS, Corso W, Etro JF. Employing unmanned aerial vehicles (UAVs) as an
element of the Integrated Ocean Observing System. OCEANS, Proceedings of
MTS/IEEE; 2005; 2005. p. 184‐90 Vol. 1.
[3] Peterson DL, Brass JA, Smith WH, Langford G, S. W, Dunagan S, et al. Platform
options for free flying‐satellites, UAVs or the ISS for remote sensing assesment of the
littoral zone. International Journal of Remote Sensing. 2003 10/01/2003;24(13):2785‐804.
[4] Smith WL, Knuteson RO, Revercomb HE, Feltz W, Howell HB, Menzel WP, et al.
Observations of the IR radiative properties of the ocean ‐ Implications for the
measurement of SST via satellite remote sensing. Bulletin of the American Meterological
Society. 1996;77(1):41‐51.
[5] Jena B, Rao MV, Sahu BK. TRMM derived SST in the wake of a cyclonic storm
over the central Bay of Bengal. International Journal of Remote Sensing.
2006;27(14):3065‐72.
[6] Son S, Campbell J, Dowell M, Yoo S, Noh J. Primary production in the Yellow Sea
determined by ocean color remote sensing. Marine Ecology Progress. 2005;303:91‐103.
[7] Wentz FJ, Gentemann C, Smith D, Chelton D. Satellite Measurements of Sea
Surface Temperature Through Clouds. Science. 2000 May 5, 2000;288(5467):847‐50.
[8] Nikon. D200 digital SLR Specifications. 2007 [cited; Available from:
http://www.europe‐nikon.com/product/en_GB/products/broad/1083/overview.html
[9] Indigo Systems. Photon Infrared camera specifications. 2007 [cited; Available
from: http://www.corebyindigo.com/products/core_photon.cfm
71
[10] Miles RT, Melhado JA, Hughes EW, Osiecki D. Air‐launched expendable micro‐
sized wave buoy. Proceedings of MTS/IEEE Oceans. Honolulu, USA 2001.
[11] Smith R. MAXWB ‐ Air‐launched expendable wave buoy. 2007 [cited; Available
from: http://www.neptunesci.com
[12] Stumpf RP. Applications of Satellite Ocean Color Sensors for Monitoring and
Predicting Harmful Algal Blooms. Human and Ecological Risk Assessment. 2001;7(5):1363
‐ 8.
[13] General Atomics, Predator B UAV. 2000 [cited; Available from: http://www.ga‐
asi.com/products/predator_b.php
[14] US Military. About the Predator UAV. 2007 [cited; Available from:
http://usmilitary.about.com/cs/afweapons/a/preditor.htm
[15] Carlson BJ. Past UAV program failures and implications for current UAV
programs: Air command and staff college, Maxwell airforce base, USA; 2001.
[16] Insitugroup. ScanEagle/SeaScan UAV Specifications. 2007 [cited; Available
from: http://www.insitu.com/prod_scaneagle.cfm
[17] AeroVironment. Raven UAV Specification. 2007 [cited; Available from:
http://www.aerovironment.com/UAS.asp
[18] Centaur Seaplanes. Gull UAV Specifications. 2007 [cited; Available from:
http://www.centaurseaplane.com/gull/capabilities.htm
[19] Micropilot. MP‐UAV Autopilot Specifications. 2007 [cited; Available from:
http://www.micropilot.com/prod_uav.htm
[20] Pisanich G, Morris S. Fielding an amphibious UAV: development, results and
lessons learned. Proceedings of the 21st digital avionics system conference; 2002; 2002.
p. 8C4‐1 ‐> 8C4‐9.
[21] Centaur Systems. Gull UAV Capabilities. 2007 [cited; Available from:
http://www.centaurseaplane.com/gull/capabilities.htm
[22] Advanced Ceramics Research. Manta B UAV Specifications. 2007 [cited;
Available from: http://www.acrtucson.com/UAV/manta/index.htm
[23] MLB Company. Bat UAV Specifications. 2007 [cited; Available from:
http://www.spyplanes.com/bat3specs.html
[24] How J, King E, Kuwata Y. Flight demonstrations of cooperative control for UAV
teams. Proceedings of the AIAA 3rd "Unmanned Unlimited" technical conference; 2004;
Chicago, USA; 2004.
72
[25] King ET. Distributed coordination and control experiments on a multi‐uav
testbed; 2002.
[26] Holland GJ. The aerosonde robotic aircraft: A new paradigm for environmental
observations. Bulletin of the American Meterological Society. 2001;82(5):889‐902.
[27] Elston J, Argrow B, Frew E. A distributed avionics package for small UAVs.
Proceedings of Infotech@Aerospace; 2005; Arlington, USA; 2005.
[28] Bayraktar S, Fainekos GE, Pappas GJ. Experimental cooperative control of fixed‐
wing unmanned aerial vehicles. Proceedings of the 43rd IEEE conference on Decision
and Control 2004; Atlantis, Bahamas; 2004.
[29] Blue Bear Systems. 2006 [cited; Available from:
http://www.bluebearsystems.com
[30] Platanitus G, Shkarayev S. Integration of an autopilot for a micro air vehicle.
Proceedings of Infotech@Aerospace; 2005; Arlington, USA; 2005.
[31] UAV Navigation. AP04 Autopilot Specification. 2007 [cited; Available from:
http://www.uavnavigation.com/uavprod/uavprod_01.htm
[32] Crossbow Inertial Systems. NAV420 family, Inertial Measurement Units. 2007
[cited; Available from: http://www.xbow.com/Products/productdetails.aspx?sid=206
[33] KVH Inertial Systems. KVH TG‐6000 FOG based Inertial Measurement Unit.
2007 [cited; Available from: http://www.kvh.com/pdf/TG_6000.Bro_10.03.pdf
[34] Analog Devices. iMEMS Gyroscopes Specifications. 2007 [cited; Available from:
http://www.analog.com/en/subCat/0,2879,764%255F801%255F0%255F%255F0%255F,00.
html
[35] Scaysbrook IW, Cooper SJ, Whitley ET. A miniature, gun‐hard MEMS IMU for
guided projectiles, rockets and missiles. Position Location and Navigation Symposium,
2004 PLANS 2004; 2004; 2004. p. 26‐34.
[36] Spark Fun. 6DOF IMU Specifications. 2007 [cited; Available from:
http://www.sparkfun.com/commerce/product_info.php?products_id=8193
[37] Gebre‐Egziabher D, Hayward RC, Powell JD. Design of multi‐sensor attitude
determination systems. IEEE Transactions on Aerospace and Electronic Systems.
2004;40(2):627‐49.
[38] Kingston DB, Beard RW. Real‐time attitude and position estimation for small
UAVs using low‐cost sensors. Proceedings of AIAA 3rd "Unmanned Unlimited"
Technical Conference; 2004; Chicago, USA; 2004.
73
[39] Niculescu M. Sensor fusion algorithms for unmanned air vehicles. Information,
decision and control conference. Adelaide, Australia 2002.
[40] Phelan RM. Automatic control systems. New York: Cornell University Press 1977.
[41] Bennett M, al e. Development of technologies for low‐cost oceanographic UAVs
[Transfer]: University of Southampton; 2007.
[42] Dhaouadi R, Mohan N, Norum L. Design and implementation of an extended
Kalman filter for the state estimation of a permanent magnet synchronous motor. IEEE
Transactions on power electronics. 1991;6(3):491‐7.
[43] Cloud Cap Technologies. Piccollo 2 Specifications. 2007 [cited; Available from:
http://www.cloudcaptech.com/piccolo_II.shtm
[44] Data Loggers Online. DataTaker DT50 Specifications. 2007 [cited; Available
from: http://www.dataloggersonline.co.uk/datataker/dt50.htm
[45] Waugh E. Data Logger v1.2 User Manual. National Oceanography Centre,
Southampton 2007.
[46] Civil Aviation Authority. CAP 722 ‐ Unmanned Aerial Vehicle Operations in UK
airspace ‐ Guidance. CAA Publications. 2004.
[47] Casarosa C, al e. Impact of safety requirements on the weight of civil UAVs.
Aircraft engineering and aerospace technology. 2004;76(6):600‐6.
[48] Haddon DR, Whittaker CJ. Aircraft airworthiness certification standards for civil
UAVs. Aeronautical Journal. 2003;107(1068):79‐86.
[49] Le Tallec C. Visual flight rules general aviation aircraft and UAV flights
deconfliction. Aerospace Science and Technology. 2005;9(6):495‐503.
[50] Endicott G. CFD wing optimisation for the NOC UAV: University of
Southampton; 2006.
[51] RCV Engines. UAV Engines for JP8 fuel. 2007 [cited; Available from:
http://www.rcvengines.com/corporate/uav_applications.htm
[52] Automotive Electronics Council. AEC Standards Documents. 2007 [cited;
Available from:
[53] Green Hills Software. Integrity RTOS for DO178‐B. 2007 [cited; Available from:
http://www.ghs.com/products/safety_critical/integrity‐do‐178b.html
[54] Esterel Technologies. SCADE Suite Specifications. 2007 [cited; Available from:
http://www.esterel‐technologies.com/products/scade‐suite/
[55] Motor Industry Software Reliability Association. MISRA C Guidelines. 2007
[cited; Available from: http://www.misra‐c2.com/
74
[56] Newbury Electronics. About Newbury Electronics. 2007 [cited; Available from:
http://www.newburyelectronics.co.uk/
[57] ATS Group. 2007 [cited; Available from: http://www.ats‐group.co.uk/
i
Appendix 1 Flight Control System schematic
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
RTCK
RS232D_RXRS232D_TXRS232C_RXRS232C_TX
RS232B_TXRS232B_RX
CANA_TXCANA_RX
RS232A_TXRS232A_RX
I2C_sda
SPIA_misoI2C_scl
SPIA_mosiSPIA_sckSPIA_PCS0SPIA_PCS1SPIA_PCS2
SPIB_ss0
SPIB_miso
SPIB_sckSPIB_mosi
PD1PD2 / CLKOUT
PD0
TDI
TCK
XTAL
EXTAL
XFC
VddPLL
TDO
Reset
VddPLL
SW_flaps
SW_rudderSW_throttle
SW_elevator
Compass_ResetCompass_DRDY
naughty
naughty
max3222_nshdnmax3222_nenZGyro_ST1ZGyro_ST2
LED4
LED6
LED8
LED5
LED7
LED3
LED2
LED0LED1
g_sel1g_sel2
CAN_nen
CANB_TXCANB_RX
SPIA_PCSS
SPIA_PCS1SPIA_ss0SPIA_ss1SPIA_ss2SPIA_ss3SPIA_ss4
Mos1
SPIA_PCSS
A2D4_Busy
A2D2_BusyA2D3_Busy
A2D2_nCONVST
mmc_NOT_presentmmc_switch
PPS
FCS_aileron_sb
PA10
SPIA_PCS0
SPIA_PCS2
GPI_b0
GPI_b2
GPI_b3
RTC_Switch
int_RTC
GPI_b1
SW_aileron_sbMos0
SW_aileron_ptRXin_gearoverride
SD1_nDRDY
nTRSTResetTCK
TDO TDI
TMS
TMS
AC4868_upreset
AC4868_CMDDATAC4868_CTS
SD0_nDRDY
A2D3_nCONVST
A2D4_nCONVST
FCS_rudder
FCS_elevator
FCS_flapsFCS_throttle
FCS_aileron_pt
SS0_nSYNCSS0_nRST
SS1_nRSTSS1_nSYNC
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V+D3.3V
+D3.3V
RS232B_RXRS232B_TXRS232A_RXRS232A_TX
RS232D_RXRS232D_TXRS232C_RXRS232C_TX
CANA_TXCANA_RX
I2C_sdaI2C_scl
SPIA_misoSPIA_mosiSPIA_sck
SPIB_ss0
SPIB_misoSPIB_mosiSPIB_sck
SW_rudderSW_throttle
SW_elevatorSW_flaps
Compass_ResetCompass_DRDY
max3222_nshdnmax3222_nen
ZGyro_ST1ZGyro_ST2
LED4
LED6
LED8
LED5
LED7
LED3
LED2
LED0LED1
g_sel1g_sel2
CAN_nen
CANB_TXCANB_RX
SPIA_ss0SPIA_ss1SPIA_ss2SPIA_ss3SPIA_ss4
Mos1
A2D4_Busy
A2D2_BusyA2D3_Busy
A2D2_nCONVST
mmc_NOT_presentmmc_switch
PPS
FCS_aileron_sb
PA10
GPI_b0
GPI_b2
GPI_b3
RTC_Switch
int_RTC
GPI_b1
SW_aileron_sbMos0
SW_aileron_ptRXin_gearoverride
SD1_nDRDY
AC4868_upreset
AC4868_CMDDATAC4868_CTS
SD0_nDRDY
A2D3_nCONVST
A2D4_nCONVST
FCS_rudder
FCS_elevator
FCS_flapsFCS_throttle
FCS_aileron_pt
SS0_nSYNCSS0_nRST
SS1_nRSTSS1_nSYNC
Title
Size Document Number Rev
Date: Sheet of
<Doc> 1.1
Flight Control System - Core
A3
1 8Friday, November 17, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> 1.1
Flight Control System - Core
A3
1 8Friday, November 17, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> 1.1
Flight Control System - Core
A3
1 8Friday, November 17, 2006
Ideal value is 7600pF but it does not exist, 7600 +-10% (typical cap tolerance) is 6840 -> 8360pF.
D1 RA-LEDD1 RA-LED
C1327pF
C1327pF
R2010KR2010K
R14 10KR14 10K
EXTAL TP1EXTAL TP11
U66
74AHC1G04
U66
74AHC1G04
24
53
1
R16 180RR16 180R
C111nF
C111nF
C21220nF
C21220nF
C20
220nF
C20
220nF
Y1
4 MHz
Y1
4 MHz
R1810KR1810K
C29100nF
C29100nF
D2 RA-LEDD2 RA-LED
R106k8R106k8
TP_PCS1TP_PCS1
1
C18
220nF
C18
220nF
C45
220nF
C45
220nF
C1227pF
C1227pF
J17
JTAG
J17
JTAG
246810
13579
TP_PCS2TP_PCS2
1
IO - 113 pins
U1B
MAC7116VAG50
IO - 113 pins
U1B
MAC7116VAG50
TA_AS79PA0_MCKO138PA1_EVTO137PA2_EVTI136PA3_MDO0135PA4_MDO1134PA5_MSEO133PA6_RDY132PA798PA897PA996PA1095PA1194PA1293PA1367PA1466PA1565
PB0_SDA15PB1_SCL16PB2_SINA17PB3_SOUTA18PB4_SCKA19PB5_PCS0A_SSA20PB6_PCS1A21PB7_PCS2A22PB8_PCS5A_PCSSA23PB9_PCS0B_SSB72PB10_PCS5B_SSB73PB11_PCS2B74PB12_PCS1B75PB13_SCKB76PB14_SOUTB77PB15_SINB78
PC09PC110PC211PC312PC428PC529PC630PC731PC844PC945PC1046PC1147PC1288PC1389PC1490PC1591
PD0_MODB70PD1_MODA71PD2_XCLKS80PD3_XIRQ81PD4_IRQ82PD592PD6119PD7120PD8121PD9122PD10123PD1168PD1269PD1383PD1484PD1585
PE0_ANA0_MCKO' 99PE1_ANA1_EVTO' 100PE2_ANA2_EVTI' 101
PE3_ANA3_MDO0' 102PE4_ANA4_MDO1' 103PE5_ANA5_MSEO' 104
PE6_ANA6_RDY' 105PE7_ANA7 106PE8_ANA8 107PE9_ANA9 108
PE10_ANA10 113PE11_ANA11 114PE12_ANA12 115PE13_ANA13 116PE14_ANA14 117PE15_ANA15 118
PF0_eMIOS0_NEXPS 43PF1_eMIOS1_NEXPR 42
PF2_eMIOS2 41PF3_eMIOS3 40PF4_eMIOS4 39PF5_eMIOS5 38PF6_eMIOS6 37PF7_eMIOS7 36PF8_eMIOS8 35PF9_eMIOS9 34
PF10_eMIOS10 33PF11_eMIOS11 32PF12_eMIOS12 27PF13_eMIOS13 26PF14_eMIOS14 25PF15_eMIOS15 24
PG0_RXDB 141PG1_TXDB 142PG2_RXDA 143PG3_TXDA 144
PG4_CNTXA 1PG5_CNRXA 2PG6_CNTXB 7PG7_CNRXB 8PG8_CNTXC 3PG9_CNRXC 4
PG10_CNTXD 5PG11_CNRXD 6
PG12_RXDD 51PG13_TXDD 52PG14_RXDC 139PG15_TXDC 140
R11
10K
R11
10K
C19
220nF
C19
220nF
R13 10KR13 10K
C16 220nFC16 220nF
Power and clocks - 31pins
U1A
MAC7116VAG50
Power and clocks - 31pins
U1A
MAC7116VAG50
EXTAL60XTAL61XFC58RESET48TDI128TDO129TCK130TMS131
VssX 13VddX 14VddX 50
VssX 49
Vdd2.5 53Vss2.5 54
VssR55VddR56
VddPLL 57VssPLL 59
VssX 63
VddX 64
VssX 86
VddX 87VddA109VRH110VRL111VssA112
VddX 124
VssX 125
Vss2.5 126
Vdd2.5 127
Test62
R15 180RR15 180R
C108200pFC108200pF
C17
220nF
C17
220nF
C15 220nFC15 220nFC14 220nFC14 220nF
R12 10KR12 10K
R1710KR1710K
U50
74HC137
U50
74HC137
A0 1A1 2A2 3LE 4
E1 5E2 6
Y77GND 8
Y69 Y510 Y411 Y312 Y213 Y114 Y015
Vcc 16
R1910KR1910K
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A AVbat
RTC_scl
RTC_sda
int_RTC
I2C_scl
I2C_sdaI2C_scl
I2C_sdaI2C_scl
A2D2_BusyA2D2_nCONVST
A2D3_BusyA2D3_nCONVST
throttle_I_f
elevator_sb_I_felevator_pt_I_f
rudder_sb_I_frudder_pt_I_f
aileron_sb_I_faileron_pt_I_f
I2C_sdaRTC_sclRTC_sda
A2D4_BusyA2D4_nCONVST
I2C_sdaI2C_scl
flap_sbob_I_f
flap_sbib_I_f
flap_ptob_I_fCurrent_Sense_f
flap_ptib_I_f
aileron_sb_pos_f
rudder_sb_pos_f
rudder_pt_pos_f
elevator_pt_pos_f
flap_ptob_pos_f
rudder_pt_pos_f
elevator_pt_pos_f
flap_ptob_pos_f
Vin_meas
flap_sbob_I_f
flap_ptob_I_fflap_ptib_I_f
Current_Sense_f
flap_ptob_pos_f
rudder_sb_I_faileron_pt_I_f
throttle_I_f
rudder_pt_I_f
rudder_pt_pos_f
flap_sbib_I_f
elevator_pt_I_faileron_sb_I_f
elevator_sb_I_f
elevator_pt_pos_f
aileron_sb_pos_frudder_sb_pos_felevator_sb_pos_f
throttle_pos_faileron_pt_pos_f
flap_ptib_pos_fflap_sbob_pos_fflap_sbib_pos_f
throttle_pos_f
elevator_sb_pos_f
aileron_pt_pos_faileron_pt_pos_f
flap_sbib_pos_f
flap_sbob_pos_f
flap_ptib_pos_f
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+A3.3V2
+A3.3V2
+A3.3V2
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+A3.3V2
+A3.3V2
+A3.3V2
+A3.3V2+A3.3V2 +A3.3V2
+A3.3V2+A3.3V2
+A3.3V2
+A3.3V2
+A3.3V2
+A3.3V2
+A3.3V2
+A3.3V2
+A3.3V2
+A3.3V2
I2C_sda
I2C_scl
int_RTC
A2D2_BusyA2D2_nCONVST
A2D3_BusyA2D3_nCONVST
throttle_I
elevator_pt_I elevator_sb_I
rudder_pt_I rudder_sb_I
aileron_pt_I aileron_sb_I
aileron_sb_pos
elevator_pt_pos
Vbat
RTC_Switch
A2D4_BusyA2D4_nCONVST
flap_ptob_pos
flap_sbob_I
flap_ptob_I
flap_sbib_I
Current_Sense
flap_ptib_I
rudder_sb_pos
rudder_pt_pos
Vin_meas
throttle_pos
elevator_sb_pos
aileron_pt_pos
flap_sbib_pos
flap_sbob_pos
flap_ptib_pos
Title
Size Document Number Rev
Date: Sheet of
<Doc> 1.0
Autopilot - I2C Bus
A2
2 8Thursday, December 14, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> 1.0
Autopilot - I2C Bus
A2
2 8Thursday, December 14, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> 1.0
Autopilot - I2C Bus
A2
2 8Thursday, December 14, 2006
Address = 1101000x
Address = 101000xx
Address = 0100011x
Address = 0100100x
Address = 0100000x
Current sense inputs
Position sense inputs
R28
820R
R28
820R
C43
4u7F
C43
4u7F
R155DP
R155DP
R7
820R
R7
820R
-
+
U77A
LMV324-
+
U77A
LMV324
12
3
411
C1601uFC1601uF
C3
4u7F
C3
4u7F
C34
4u7F
C34
4u7F
R392k2R392k2
C35
4u7F
C35
4u7F
C30
4u7F
C30
4u7F
R25
820R
R25
820R
C38
4u7F
C38
4u7F
C40
100nF
C40
100nF
R168 820RR168 820R
C8
4u7F
C8
4u7F
R166 820RR166 820R
C2
4u7F
C2
4u7F
C46 100nFC46 100nF
R152 820RR152 820R
U43
MAX323
U43
MAX323
GND 4VCC8
NO1 1NO2 5COM12
COM26
IN17IN23
R26
820R
R26
820R
C36
100nF
C36
100nF
R163DP
R163DP
C6
4u7F
C6
4u7F
-
+
U77B
LMV324
-
+
U77B
LMV324
76
5
411
R154 820RR154 820R
-
+
U80D
LMV324
-
+
U80D
LMV324
1413
12
411
C26
100nF
C26
100nF
R157DP
R157DP
C33
4u7F
C33
4u7F
R147DP
R147DP
R159DP
R159DP
R71
100R
R71
100R
R23
100R
R23
100R
C27
4u7F
C27
4u7F
R150 820RR150 820R
R149DP
R149DP
C23
4u7F
C23
4u7F
C39
4u7F
C39
4u7F
-
+
U78A
LMV324
-
+
U78A
LMV324
12
3
411
R12510kR12510k
R8
820R
R8
820R
C44
4u7F
C44
4u7F
R6
820R
R6
820R
R161DP
R161DP
C51
100nF
C51
100nF
U6
FM24CL64
U6
FM24CL64
NC1A12A23Vss4
Vdd 8
SDA 5SCL 6WP 7
C1581uFC1581uF
-
+
U77C
LMV324
-
+
U77C
LMV324
89
10
411
R29
820R
R29
820R
R4010kR40
10k
R24
820R
R24
820R
C42
4u7F
C42
4u7F
R32
100R
R32
100R
R165DP
R165DP
R22
820R
R22
820R
C4
4u7F
C4
4u7F
R148 820RR148 820R
C31
4u7F
C31
4u7F
-
+
U78D
LMV324
-
+
U78D
LMV324
1413
12
411
R156 820RR156 820R
R158 820RR158 820R
U7Battery
U7Battery
+2
-1
-
+
U80B
LMV324
-
+
U80B
LMV324
76
5
411
R9
820R
R9
820R
-
+
U80C
LMV324
-
+
U80C
LMV324
89
10
411R153
DPR153
DP
C47 100nFC47 100nF
R164 820RR164 820R
U4
AD7998BRUZ-1
U4
AD7998BRUZ-1
AGND 1
Vdd 2
AGND 3AGND 4
Vdd 5
REFin 6
Vin17
Vin214
Vin38
Vin413
Vin59
Vin612
Vin710
Vin811 AS 15
CONVST16 Alert_Busy17
SDA18SCL19 AGND 20
R151DP
R151DP
U5
DS1339C_16P
U5
DS1339C_16P
NC4 4NC5 5
VBACKUP14 GND 15
SDA16
SCL 1
SQW/INT2
VCC3
NC6 6NC7 7NC8 8NC9 9
NC10 10NC11 11NC12 12NC13 13
C5
4u7F
C5
4u7F
R27
820R
R27
820R
-
+
U77D
LMV324
-
+
U77D
LMV324
1413
12
411
C7
4u7F
C7
4u7F
C122
100nF
C122
100nF
-
+
U78B
LMV324
-
+
U78B
LMV324
76
5
411
C37 100nFC37 100nF
C9
4u7F
C9
4u7F
R162 820RR162 820R
C1591uFC1591uF
C123
100nF
C123
100nF
C32
4u7F
C32
4u7F
U3
AD7998BRUZ-1
U3
AD7998BRUZ-1
AGND 1
Vdd 2
AGND 3AGND 4
Vdd 5
REFin 6
Vin17
Vin214
Vin38
Vin413
Vin59
Vin612
Vin710
Vin811 AS 15
CONVST16 Alert_Busy17
SDA18SCL19 AGND 20
R167DP
R167DP
C28
4u7F
C28
4u7F
R160 820RR160 820R
R382k2R382k2
R5
820R
R5
820R
-
+
U78C
LMV324
-
+
U78C
LMV324
89
10
411
R9210kR9210k
U8
AD7998BRUZ-1
U8
AD7998BRUZ-1
AGND 1
Vdd 2
AGND 3AGND 4
Vdd 5
REFin 6
Vin17
Vin214
Vin38
Vin413
Vin59
Vin612
Vin710
Vin811 AS 15
CONVST16 Alert_Busy17
SDA18SCL19 AGND 20
-
+
U80A
LMV324
-
+
U80A
LMV324
12
3
411
C24
100nF
C24
100nF
R9310kR9310k
C53
100nF
C53
100nF
C1
4u7F
C1
4u7F
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
RXin_flaps
RXin_throttle
RXin_aileron_pt
RXin_elevator
RXin_rudder
RXin_aileron_sb
FCS_aileron_pt
FCS_rudder
FCS_throttle
FCS_elevator
FCS_aileron_sb
FCS_flaps
aileron_ptaileron_sbelevator
rudder
throttleflaps
OP_aileron_ptOP_aileron_sbOP_elevator_ptOP_elevator_sb
OP_rudder_sb
OP_throttleOP_flap_sbibOP_flap_sbob
OP_flap_ptobOP_flap_ptib
OP_PA10
rudder
throttle
aileron_pt
aileron_sb
elevator
flaps
PA10
RXin_elevator
RXin_flapsRXin_rudder RXin_gear
RXin_throttleRXin_aileron_sb
RXin_aileron_pt
OP_rudder_pt
SW_rudder
SW_throttle
SW_flaps
SW_aileron_pt
SW_aileron_sb
SW_elevator
override
override
override
override
override
override
RXin_gear
override
+D3.3V
+D3.3V
+D5V +D5V
+D5V
+D5V
+D5V
+D5V
+D5V
+D5V
+D3.3V
+D3.3V
+D5V
+D5V
+D3.3V+D3.3V
+D3.3V
+D3.3V
FCS_aileron_pt
FCS_aileron_sb
FCS_rudder
FCS_throttle
FCS_elevator
FCS_flaps
PA10
RXin_gear
SW_rudder
SW_throttle
SW_flaps
SW_aileron_pt
SW_aileron_sb
SW_elevator
override
OP_aileron_ptOP_aileron_sbOP_elevator_ptOP_elevator_sbOP_rudder_ptOP_rudder_sb
OP_throttleOP_flap_sbibOP_flap_sbobOP_flap_ptibOP_flap_ptobOP_PA10
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCod
Servos
A3
3 8Thursday, December 14, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCod
Servos
A3
3 8Thursday, December 14, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCod
Servos
A3
3 8Thursday, December 14, 2006
D6
TS4148
D6
TS4148
R136
2k
R136
2k
D9
TS4148
D9
TS4148
U71
74LVC08
U71
74LVC08
1A11B2
1Y 32A42B5 2Y 6
GND7
3Y 8
3A93B10
4Y 11
4A124B13
VCC 14
C114
100nF
C114
100nF
+C12510uF
+C12510uF
R9510kR9510k
R96
10k
R96
10k
C117
100nF
C117
100nF
-
+
U75A
MC33202-
+
U75A
MC33202
12
3
48
R139 51kR139 51k
R9810kR9810k
C163
100nF
C163
100nF
D10
TS4148
D10
TS4148
U37
74HC4053_16SO
U37
74HC4053_16SO
B1 1B0 2
C13COM OUT/IN CN4
IN/OUT C05 E6VEE 7GND 8
VCC16
BN 15
AN 14A1 13A0 12
S011S110S29
-
+
U75B
MC33202-
+
U75B
MC33202
76
5
48
C1651uFC1651uF
D5
TS4148
D5
TS4148
R1372kR1372k
U36
74HC4053_16SO
U36
74HC4053_16SO
B1 1B0 2
C13COM OUT/IN CN4
IN/OUT C05 E6VEE 7GND 8
VCC16
BN 15
AN 14A1 13A0 12
S011S110S29
D4
TS4148
D4
TS4148
R10010k
R10010k
D7
TS4148
D7
TS4148
R1406.2k
R1406.2k
R14112kR14112k
R99
10k
R99
10k
R13812kR13812k
J14
Hobby RX
J14
Hobby RX
2468
10
13579
ABCD
U39
74HC4050
U39
74HC4050
VCC 1
IY 2
1A3
2Y 4
2A5
3Y 6
3A7
GND8
4A9
4Y 105A11
5Y 12
NC113
6A14
6Y 15
NC216
C164
100nF
C164
100nF
U72
74LVC08
U72
74LVC08
1A11B2
1Y 32A42B5 2Y 6
GND7
3Y 8
3A93B10
4Y 11
4A124B13
VCC 14
D8
TS4148
D8
TS4148
C166
100nF
C166
100nF
-
++
-
U73
LMC7211
-
++
-
U73
LMC7211
1
2
3
4
5
C115
100nF
C115
100nF
C124100nFC124
100nF
U38
74HC4050
U38
74HC4050
VCC 1
IY 2
1A3
2Y 4
2A5
3Y 6
3A7
GND8
4A9
4Y 105A11
5Y 12
NC113
6A14
6Y 15
NC216
R9410kR9410k
C116
100nF
C116
100nF
R9710kR9710k
R134
330k
R134
330k
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
Supply_Gnd
GPI0
GPI1
LED5
LED8
LED3LED1 LED0
LED7LED6 LED4
LED2
Power_In
Mos1
Mos0
OP_PA10
GPI3GPI2
Mos1_S
RS232A_TX_ext
Compass_DRDY
Compass_Reset
SPIA_misoSPIA_mosi
SPIA_ss4SPIA_sck
Mos1_SCANL_BCANH_B
CANL_ACANH_A
OP_flap_ptob
rudder_sb_pos
aileron_pt_pos
OP_flap_sbib
OP_throttle
OP_rudder_pt
GPI0
GPI3
GPI1GPI2 GPI_b0
GPI_b1GPI_b2GPI_b3
OP_elevator_ptOP_aileron_sb
OP_elevator_sbOP_flap_sbobOP_flap_ptib
OP_aileron_pt
OP_rudder_sb
RS232B_TX_ext
RS232A_RX_ext
RS232B_RX_ext
flap_ptib_I flap_sbob_posflap_sbib_pos
flap_ptob_I
flap_sbob_I
throttle_I
rudder_sb_Iaileron_pt_Irudder_pt_I
elevator_sb_I
elevator_pt_I
flap_sbib_Iaileron_sb_I
aileron_sb_pos
elevator_sb_pos
flap_ptib_pos
throttle_posflap_ptob_pos
rudder_pt_pos
elevator_pt_pos
+D3.3V
+D3.3V
Supply_Gnd
LED5
LED8
LED3LED1 LED0
LED7LED6 LED4
LED2
Power_In
Mos1
Mos0
RS232A_TX_ext
Compass_DRDY
Compass_ResetSPIA_mosiSPIA_miso
SPIA_ss4SPIA_sck
CANL_BCANH_B
CANL_ACANH_A
rudder_sb_pos
aileron_pt_pos
GPI_b0GPI_b1GPI_b2GPI_b3
OP_rudder_pt
OP_PA10OP_flap_sbib
OP_flap_ptobOP_throttle
OP_elevator_ptOP_aileron_sb
OP_elevator_sbOP_flap_sbobOP_flap_ptib
OP_aileron_pt
OP_rudder_sb
RS232B_TX_ext
RS232A_RX_ext
RS232B_RX_ext
flap_ptib_I flap_sbob_posflap_sbib_pos
flap_ptob_I
flap_sbob_I
throttle_I
rudder_sb_Iaileron_pt_Irudder_pt_I
elevator_sb_I
elevator_pt_I
flap_sbib_Iaileron_sb_I
aileron_sb_pos
elevator_sb_pos
flap_ptib_pos
throttle_posflap_ptob_pos
rudder_pt_pos
elevator_pt_pos
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCod
Off board connections
A3
3 8Thursday, November 16, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCod
Off board connections
A3
3 8Thursday, November 16, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCod
Off board connections
A3
3 8Thursday, November 16, 2006
R86 180RR86 180R
R84 180RR84 180R
J7SPIA_ss4 J7SPIA_ss412
R83180R R83180R
R91 180RR91 180R
U41
74HC4050
U41
74HC4050
VCC 1
IY 2
1A3
2Y 4
2A5
3Y 6
3A7
GND8
4A9
4Y 105A11
5Y 12
NC113
6A14
6Y 15
NC216
R89180R R89180R
J15
Led Header
J15
Led Header
2468101214
13579
1113
R85180R R85180R
C128
100nF
C128
100nF
R87180R R87180R
J6SPIA_sck J6SPIA_sck12
U56
ZXMN3B04N8TA
U56
ZXMN3B04N8TA
S1 S2 S3 G4 D 5D 6D 7D 8
J9 SPIA_mosiJ9 SPIA_mosi1 2
U70
ModICE
U70
ModICE
A1A1A2A2A3A3
B1B1B2B2B3B3
C1C1C2C2C3C3
D1D1D2D2D3D3
E1E1E2E2E3E3
F1 F1F2 F2F3 F3
G1 G1G2 G2G3 G3
H1 H1H2 H2H3 H3
J1 J1J2 J2J3 J3
K1 K1K2 K2K3 K3
J8 SPIA_misoJ8 SPIA_miso1 2
R88180R R88180R
U69
ModICE
U69
ModICE
A1A1A2A2A3A3
B1B1B2B2B3B3
C1C1C2C2C3C3
D1D1D2D2D3D3
E1E1E2E2E3E3
F1 F1F2 F2F3 F3
G1 G1G2 G2G3 G3
H1 H1H2 H2H3 H3
J1 J1J2 J2J3 J3
K1 K1K2 K2K3 K3
R82180R R82180R
R90 180RR90 180R
U55
ZXMN3B04N8TA
U55
ZXMN3B04N8TA
S1 S2 S3 G4 D 5D 6D 7D 8
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
Power_In
Current_Sense
Vin_meas
+U6V +A3.3V
+A5V
+D3.3V
+D5V
+A3.3V2Supply_Gnd
Power_In
Current_Sense
Vin_meas
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCode>
<Title>
A3
4 8Monday, December 04, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCode>
<Title>
A3
4 8Monday, December 04, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCode>
<Title>
A3
4 8Monday, December 04, 2006
Title
Size Document Number
Date: Sheet of
<Doc>
<Title>
A3
4Monday, December 04, 2006
Title
Size Document Number
Date: Sheet of
<Doc>
<Title>
A3
4Monday, December 04, 2006
Title
Size Document Number
Date: Sheet of
<Doc>
<Title>
A3
4Monday, December 04, 2006
U51
REG102-3.3
U51
REG102-3.3
Vout 1Vout 2
NR 3Enable5 Gnd 4
Vin7 Vin8
NC6
CL322uF
CL322uF
+22uF
+22uF
+D3.3V+D3.3V
1
J18Gnd ConnectJ18Gnd Connect
12
L1
6.2uH
L1
6.2uH
R143
2k
R143
2k
+ CT168uF
+ CT168uF
U57
REG102-3.3
U57
REG102-3.3
Vout 1Vout 2
NR 3Enable5 Gnd 4
Vin7 Vin8
NC6
R1421k8R1421k8
C15010nFC15010nF
TP4TP41
R441MR441M
TP1TP11
U53
TPS62046 - 3.3V DCDC 1.2A
U53
TPS62046 - 3.3V DCDC 1.2A
Enable1
Vin2Vin3
Gnd4
FB 5
Mode6
SW (Vout) 7SW (Vout) 8
PGnd 9PGnd 10
+22uF
+22uF
J12 3.3V OutJ12 3.3V Out1 2
LD1085 OutLD1085 Out
1
CL122uF
CL122uF
R4133kRR4133kR
L2
6.2uH
L2
6.2uH
R47Zero OhmR47Zero Ohm
TP3TP31
J16 5V OutJ16 5V Out1 2
R130Don't PlaceR130Don't Place
C16110nFC16110nF
INA139NA
U12
INA139NA
U12
OUT 1
GND 2
VIN+3
VIN-4
V+5
C148470pFC148470pF
C153100nFC153100nF
TP2TP21
R42
0.02 Ohm - 1206 - 0.5W
R42
0.02 Ohm - 1206 - 0.5W
R13236KR13236K
Q1IRLML5203Q1IRLML5203
C25
4u7F
C25
4u7F
R45300RR45300R
7805 Out7805 Out
1
U68
LD1085V33
U68
LD1085V33
GND
1
IN3 OUT 2
R133Don't PlaceR133Don't Place
+D5V+D5V
1
+ CT322uF
+ CT322uF
R49Zero OhmR49Zero Ohm
D3Pwr_LED
D3Pwr_LED
C15110nFC15110nF
CL222uF
CL222uF
CL422uF
CL422uF
C162100nFC162100nF
U54
TPS62040 - Adj V DCDC 1.2A
U54
TPS62040 - Adj V DCDC 1.2A
Enable1
Vin2Vin3
Gnd4
FB 5
Mode6
SW (Vout) 7SW (Vout) 8
PGnd 9PGnd 10C14747pFC14747pF
U52
REG102-5
U52
REG102-5
Vout 1Vout 2
NR 3Gnd 4Enable5 NC6 Vin7 Vin8
C152100nFC152100nF
R50Zero OhmR50Zero Ohm
R131330KR131330K
U67
MC7805C/TO
U67
MC7805C/TO
IN1 OUT 2GND3
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
sd_clk
sd_clk
SPIA_mosi
SPIA_miso
SPIA_sckSD0_nDRDY
SPIA_ss0
SPIA_sck
SPIA_ss1
SPIA_mosi
SD1_nDRDYSPIA_miso
SS0_nRSTSS0_nSYNC
SS1_nRSTSS1_nSYNC
+A5V
+D3.3V
+A5V
+A5V
+A5V
+A5V
+A5V
+D3.3V+A5V
+A5V
SPIA_mosi
SPIA_miso
SPIA_sckSD0_nDRDY
SPIA_ss0
SPIA_sck
SPIA_ss1
SPIA_mosi
SD1_nDRDYSPIA_miso
SS0_nRSTSS0_nSYNC
SS1_nRSTSS1_nSYNC
Title
Size Document Number Rev
Date: Sheet of
<Doc> 0.9
Pressure Sensing
A3
5 8Friday, November 17, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> 0.9
Pressure Sensing
A3
5 8Friday, November 17, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> 0.9
Pressure Sensing
A3
5 8Friday, November 17, 2006
C140100nFC140100nF
C1431uFC1431uF
R126
100R
R126
100R
U62
LT1790A-1.25
U62
LT1790A-1.25
Gnd 1Gnd 2NC3
NC5
Vin 4Vout6
C1411uF
C1411uFC135
100pFC135
100pF
C1341uF
C1341uF
U58
LT1790A-3.3
U58
LT1790A-3.3
Gnd1Gnd2 NC 3
NC 5
Vin4 Vout 6
C127 100nFC127 100nF
C126100nFC126100nF
C1121uFC1121uF
C1131uFC113
1uF
C130100nFC130100nF
R135100RR135100R
C129100pFC129100pF
C641uFC64
1uF
R144100RR144100R
C144100pFC144100pF
R145100RR145100R
C5418pFC5418pF
C136100nFC136
100nF
C1111uFC111
1uF
C137100nFC137100nF
CL522uF
CL522uF
CL1022uFCL1022uF
CL622uF
CL622uF
CL8
22uF
CL8
22uF
R146100RR146100R
HoleHole
1
C138 100nFC138 100nF
Y27.68 MHz
Y27.68 MHz
C131100pFC131
100pF
C139100pFC139100pF
C4118pFC41
18pF
U44
ADS1255
U44
ADS1255
AGND2
VREFN 3VREFP 4AINCOM5
AIN06AIN17
SYNC/PDWN8 RESET9
SCLK18
DIN17
DOUT 16XTAL1/CLKIN13XTAL212
DGND11
AVDD 1
DVDD 10
D0/CLKOUT 19D1 20
CS14
DRDY 15
U18
MPXV5004G
U18
MPXV5004G
VCC2
GND3 VOUT 4
CL9
22uF
CL9
22uF
U49
ADS1255
U49
ADS1255
AGND2
VREFN 3VREFP 4AINCOM5
AIN06AIN17
SYNC/PDWN8 RESET9
SCLK18
DIN17
DOUT 16XTAL1/CLKIN13XTAL212
DGND11
AVDD 1
DVDD 10
D0/CLKOUT 19D1 20
CS14
DRDY 15
C133100pFC133100pF
U59
LT1790A-2.048
U59
LT1790A-2.048
Gnd 1Gnd 2NC3
NC5
Vin 4Vout6
R58
100R
R58
100R
R127100RR127100R
C1421uFC142
1uF
TP StaTP Sta
1
R61
100R
R61
100R
CL722uFCL722uF
R63
100R
R63
100R
U45
MPXA4115A
U45
MPXA4115A
VCC2
GND3 VOUT 4
R70
100R
R70
100R
U61
LT1790A-1.25
U61
LT1790A-1.25
Gnd1Gnd2 NC 3
NC 5
Vin4 Vout 6
TP DyTP Dy1
C132100nFC132
100nF
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
RF In
max3222_nshdnmax3222_nen
RS232A_TX RS232A_RX
RS232A_TX_ext
RS232A_RX_ext
RS232B_TX RS232B_RX
RS232B_RX_ext
RS232B_TX_ext
CAN_nen
CAN_nen
CANL_ACANH_A
CANB_TX
CANA_RXCANA_TX
RS232D_RXVbat
CANH_BCANB_RX
RS232D_TX
PPS
RS232C_RXRS232C_TX
AC4868_CTS
AC4868_upreset
AC4868_CMDDAT
modem_pwr
CANL_B
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V RS232D_RX
AC4868_upreset
RS232A_TXRS232B_TX
RS232A_RXRS232B_RX
max3222_nshdnmax3222_nen
CANB_TX
CANA_RXCANA_TX
CAN_nen
RS232A_TX_extRS232B_TX_ext
RS232A_RX_extRS232B_RX_ext
CANL_ACANH_A
Vbat
CANH_BCANL_BCANB_RX
RS232D_TX
PPS
RS232C_TXRS232C_RX
AC4868_CTS
AC4868_CMDDAT
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCode>
<Title>
A3
6 8Friday, November 17, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCode>
<Title>
A3
6 8Friday, November 17, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCode>
<Title>
A3
6 8Friday, November 17, 2006
C73 100nFC73 100nF
C69100nF C69100nF
U47
SN65HVD234
U47
SN65HVD234
D/TX1
GND2 Vcc3
R/RX4
EN 5
CANL 6CANH 7
Rs 8
J11
SMC_A
J11
SMC_A
12345
R57100KR57100K
+ C66100uF
+ C66100uF
C71 100nFC71 100nF
R53220RR53220R
R80 220RR80 220R
TPS_1TPS_1 1
Baud_ResetBaud_Reset1
C167100nFC167100nF
U46
SN65HVD234
U46
SN65HVD234
D/TX1
GND2 Vcc3
R/RX4
EN 5
CANL 6CANH 7
Rs 8
R62220RR62220R
U25
MAX3222
U25
MAX3222
EN1
C1+2
V+ 3
C1-4
C2+5C2-6
V-7
T_OUT1 17T_OUT2 8
R_IN116R_IN29
R_OUT1 15R_OUT2 10T_IN113
T_IN212
GND18
VCC 19
SHDN20
NC1111NC1414
C6810nFC68
10nF
C75 100nFC75 100nF
R54
10K
R54
10K
J10
Modem Power
J10
Modem Power
1 2
R59 220RR59 220R
DN6
BAT54C
DN6
BAT54C
C6510nFC6510nF
C74100nF C74100nF
U76
AC4868
U76
AC4868
GO0 1TXD2RXD3 GI0 4
Gnd5Gnd16
Hop 6CTS7 GO1 9RTS8
Vcc 10Vcc 11
9600_Baud12
NC 13GI1 14
UP_RESET15
Cmd/Data17
ADin 18DAout 19
In_Range 20
AA
BB
CC C168
100nFC168100nF
C72 100nFC72 100nF
R55100KR55100K
R5210KR5210K
DN5
BAT54C
DN5
BAT54C
C70 100nFC70 100nF
U23
iTrax130
U23
iTrax130
Eport41Boot12
Gnd5
Eport53Eport74
Eport66Eport37AD08XReset9NC10Gnd11Eport812Eport1213VddB14AD115 TXD1 16
RXD1 19
TXD0 17RXD0 18
Gnd 20ADREFT 21Gnd 22Gnd 23RFin 24Gnd 25Gnd 26Eport9 27Vdd 28Eport1 29PPS 30R56 220RR56 220R
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
X_axis_pfY_axis_pfZ_axis_pf
ZGyro_Tmp
Y-Plane
XYGyro_Vref
Z-Plane
ZGyro_Vref
SPIA_sck
SPIA_miso SPIA_mosi
Z_axis
g_sel1g_sel2
5VrefSPIA_miso
ZGyro_Tmp_f
3.3Vref
X-Plane
SPIA_sckSPIA_misoSPIA_mosi
Compass_ResetCompass_DRDY
ZGyro_Tmp_f
ZGyro_Vref_f
XYGyro_Vref_f
ZGyro_ST1
ZGyro_ST2
SPIA_sckSPIA_mosi
SPIA_ss4
Z-Plane
SPIA_ss2
SPIA_ss3
Z-PlaneZGyro_Vref_f
X-PlaneY-Plane
X_axisY_axisZ_axis
XYGyro_Vref_f
X_axisY_axis
+A3.3V
+A3.3V
+A5V
+A3.3V
+A3.3V
+A5V
+U6V
+A5V
+D3.3V
+A3.3V +A5V
+A5V
+D5V+D3.3V
+D3.3V
SPIA_miso
SPIA_sck
SPIA_mosi
g_sel1g_sel2
SPIA_miso SPIA_sckSPIA_misoSPIA_mosi
Compass_ResetCompass_DRDY
ZGyro_ST1
ZGyro_ST2
SPIA_sckSPIA_mosi
SPIA_ss4SPIA_ss2
SPIA_ss3
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCode>
SPI Bus A
A3
7 8Monday, December 04, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCode>
SPI Bus A
A3
7 8Monday, December 04, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCode>
SPI Bus A
A3
7 8Monday, December 04, 2006
O/P BW
CMID sets BW
A2D0
A2D1
C146100pF
C146100pF
CL14
22uF
CL14
22uF
C93100nF
C93100nF
CL1122uF
CL1122uF
C76100nFC76100nF
R76 750RR76 750R
R72
820R
R72
820R
+C12110uF
+C12110uF
C97100nFC97100nF
C1561uFC1561uF
R66 1kR66 1k
D12TS4148
D12TS4148
C90100nFC90100nF
R12210kR12210k
C77100nFC77100nF
R129
200R
R129
200R
U63
LT1790A-3.3
U63
LT1790A-3.3
Gnd 1Gnd 2NC3
NC5
Vin 4Vout6
D13
TS4148
D13
TS4148
C82 100nFC82 100nF
U34
PNI-MicroMAG3
U34
PNI-MicroMAG3
SCLK1MISO2MOSI3SS4DRDY5Reset6
GND 7GND 14Vdd12
NC 8NC 9NC 10NC 11NC 13
C119
100nF
C119
100nF
TP A2D1TP A2D11
C8122nF
C8122nF
C100
4u7F
C100
4u7F
R12010k
R12010k
R64 1kR64 1k
C8322nF
C8322nF
C80 100nFC80 100nF
C92100nF
C92100nF
C86 22nFC86 22nF
C154100nFC154
100nF
C1571uFC1571uF
C84
4u7F
C84
4u7F
R77
820R
R77
820R
U27
MMA7260Q
U27
MMA7260Q
g-Select1 1g-Select2 2
Vdd3Vss4
NC5NC6NC7NC8NC9NC10NC11
Sleep 12
Xout 15Yout 14Zout 13
NC16
C94100nF
C94100nF
U48
MAX3390
U48
MAX3390
VL1OVL12IVL23IVL34IVL45NC6GND7 Three-State 8NC 9OVcc4 10OVcc3 11OVcc2 12IVcc1 13Vcc 14
C145100nF
C145100nF
C99 22nFC99 22nF
C79 100nFC79 100nF
C105
100nF
C105
100nF
TP A2D2TP A2D21
C85 47nFC85 47nF
R69
820R
R69
820R
C155
1uF
C155
1uF
ADS8344EB
U29
ADS8344EB
U29
CH0 1CH1 2CH2 3CH3 4CH4 5CH5 6CH6 7CH7 8
COM 9SHDN 10
VREF 11
+VCC 12AGND13 AGND14
DOUT15
BUSY16
DIN 17
CS 18
DCLK 19
+VCC 20
R65 1kR65 1k
CL1322uF
CL1322uF
C149100nF
C149100nF
R74 5R1R74 5R1
R78 5R1R78 5R1
R121200RR121200R
C98 22nFC98 22nF
C78100nFC78100nF
U65
ADS8341
U65
ADS8341
+VCC 1
CH0 2CH1 3CH2 4CH3 5
COM6
SHDN 7
VREF 8
+VCC 9GND10 GND11
DOUT12
BUSY13
DIN14
CS15 DCLK16
U64
LT1790A-5.0
U64
LT1790A-5.0
Gnd 1Gnd 2NC3
NC5
Vin 4Vout6
R123200RR123200R
C103100nF
C103100nF
C87
4u7F
C87
4u7F
C101 100nFC101 100nF
U28
ADXRS300
U28
ADXRS300
CP5_1D6CP5_2D7
CP4_1A6CP4_2B7
CP3_1C6CP3_2C7
CP1_1A5CP1_2B5
AVCC A3AVCC B3
RATEOUT1 B1RATEOUT2 A2
CP2_1A4CP2_2B4
CMID_1D1CMID_2D2
2.5V_1 E12.5V_2 E2
AGNDF1AGNDG2
TEMP2 G3TEMP1 F3
ST2_2G4 ST2_1F4 ST1_2G5 ST1_1F5
PGNDG6PGNDF7
PDD E6PDD E7
SUMJ1C1SUMJ2C2
C120100nF
C120100nF
C104100nF
C104100nF
C106100nF
C106100nF
R128
200R
R128
200R
R75 750RR75 750R
U31
IDG-300
U31
IDG-300
GND2GND22GND25GND38GND39GND40
Vdd14Vdd29Vdd34
X-Rate3
Y-Rate28
X-AGC8
Y-AGC23
CPOUT17 Vref32
NC 1
NC 30NC 31
NC 4NC 5NC 6NC 7
NC 33
NC 9NC 10NC 11NC 12NC 13
NC 36
NC 15NC 16
NC 35
NC 18NC 19NC 20NC 21
NC 37
NC 24
NC 27NC 26
TP A2D0TP A2D0
1
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
mmc_switch
SPIB_ss0
SPIB_sck
mmc_NOT_present
SPIB_mosi
mmc_power
SPIB_miso
+D3.3V
+D3.3V
+D3.3V
+D3.3V
+D3.3V
mmc_switch
SPIB_ss0
SPIB_miso
SPIB_sck
SPIB_mosi
mmc_NOT_present
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCo
SPI Bus B
A4
8 8Thursday, November 16, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCo
SPI Bus B
A4
8 8Thursday, November 16, 2006
Title
Size Document Number Rev
Date: Sheet of
<Doc> <RevCo
SPI Bus B
A4
8 8Thursday, November 16, 2006
C109
10nF
C109
10nF
R8110kR8110k
C110100nFC110
100nF
J13
mmc_pwr_jpr
J13
mmc_pwr_jpr
1 2
U40
MMC Header New
U40
MMC Header New
MMC_SS 1MMC_mosi 2MMC_gnd 3MMC_pwr 4MMC_sclk 5MMC_gnd 6
MMC_miso 7Pin9 9
Pin10 10Card Detect 11
SheildC
SheildDCommon 12
R79270kR79270k
Q2ZXM61P02FQ2ZXM61P02F
R12410kR12410k
ii
Appendix 2 Payload Management System schematic
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
rtc_int
max3222_NOT_shdn
ain_1a2d_int
ain_2
pic_rs232A_tx
ain_3
pic_rs232A_rx
ain_4ain_5
prog_dataprog_clk
ain_6ain_7
rs232A_tx
A2D Supply
external_int3
OSC1OSC2
rs232A_rx
i2c_sda
a2d_int
spi2_mosispi2_misospi2_sclkspi2_ss0
spi1_sclk
Vref 2.5
eccp1
spi1_misospi1_mosi
ain_0
spi2_miso
spi2_ss0
spi2_sclk
prog_mclr
eccp2T1_clockin
T0_clockin
external_int2
eccp3
A2D Supply Vref 2.5
Vref 2.5ads8345_NOT_shdn
Vref 2.5
i2c_sclk
temp_int
mmc_switch
A2D Supply
Low Battery
Iconst2-Iconst1-
driver_5V_switch
MOSA MOSB
MOSA_D
MOSA_S MOSB_S
MOSB_D
prog_mclr
prog_clk
pic_USB_tx pic_USB_rx
rs232B_rx
rs232B_tx
JUMP1 JUMP0
driver_12V_switch
spi2_miso
spi2_ss2
ads8345_NOT_shdn
MOSB
ain_3
ain_5
ain_7
ain_6 ain_2
ain_4 ain_0
spi2_mosi
ain_1
prog_data
rs232A_rxrs232A_tx
T1_clockinT0_clockin
pic_rs232A_txpic_rs232A_rx
MOSA_DMOSA_S
USB_DPUSB_DM
Vref 2.5
Vref 2.5
Vref 2.5
Vref 2.5
external_int2eccp2
spi2_ss2external_int3
eccp3Power In
max3222_NOT_shdndriver_12V_switch
spi2_ss3
MOSA
spi2_ss3
spi2_sclk
rs232B_tx
eccp1
spi2_ss1
rs232B_rx
spi2_mosi
Power In
i2c_sda
MOSB_S
i2c_sclk
MOSB_D
USB_CONNECT
USB_PWR
USB_PWR
Power EN PIC_PEN
USB_CTS
spi1_ss0
DS1721_SHConstC Switch
3.3V Enable
driver_5V_switch
JUMP0
mmc_detectFRAM_SH
spi2_ss1
pic_USB_txpic_USB_rx
pic_rs232A_txpic_rs232A_rx
JUMP1
Iconst1+Iconst2+
USB_ENABLE
USB_RTS
+5V
+5V
+5V
+5V
+5V
+5V
+5V
+5V
+5V
+6V
+5V+5V
+5V
+6V +5V
+5V
spi1_sclkspi1_misospi1_mosi
i2c_sdai2c_sclk
temp_int
rtc_int
mmc_switch
Low Battery
Iconst2-Iconst1-
A2D Supply
USB_DPUSB_DM
Power In
Power In
Power EN
USB_CONNECTUSB_CTS
spi1_ss0
ConstC SwitchDS1721_SH
3.3V Enable
mmc_detectFRAM_SH
pic_USB_txpic_USB_rx
Iconst1+Iconst2+
USB_ENABLE
USB_RTS
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
Core
A3
2 6Wednesday, October 03, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
Core
A3
2 6Wednesday, October 03, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
Core
A3
2 6Wednesday, October 03, 2007
20 pins to be for driver and rest for IO
U3
LT1790A-2.5
U3
LT1790A-2.5
Gnd1Gnd2 NC 3
NC 5
Vin4 Vout 6
C10100nFC10100nF
C11100nF
C11100nF
TP2TP2
1
R82k2R82k2
C7100nFC7100nF
J53JPJ53JP
1
2
3
R3
200R
R3
200R
C8100nFC8100nF
TP1TP1
1
C3100pFC3100pF
D2
HSME-C191
D2
HSME-C191
TP3TP3
1
R1010kR1010k
C16 100nFC16 100nF
CL122uFCL122uF
R910kR910k
TP4TP4
1
R72k2R72k2
R11 10kR11 10k
C9100nFC9100nF
Y110Mhz
Y110Mhz
C2100nFC2100nF
Y210Mhz
Y210Mhz
J63JPJ63JP
1
2
3
CL222uF
CL222uF
J7
PWREN
J7
PWREN
1 2
DN1
BAT54C
DN1
BAT54C
J2
Analogue Header
J2
Analogue Header
135791113151719
2468
101214161820
D3
PMEG4010BEA
D3
PMEG4010BEA
R5270R R5270R
C5100pFC5100pF
R6 4R7R6 4R7
C21 470nFC21 470nF
Q8AQ8AU7
MAX3222_20P
U7
MAX3222_20P
EN1
C1+2
V+ 3
C1-4
C2+5C2-6
V-7
T_OUT1 17T_OUT2 8
R_IN116R_IN29
R_OUT1 15R_OUT2 10T_IN113
T_IN212
GND18
VCC 19
SHDN20
NC1111NC1414
Q8BQ8B
C22 470nFC22 470nF
ADS8345
U4
ADS8345
U4
CH01CH12CH23CH34CH45CH56CH67CH78
COM9SHDN10
VREF11
+VCC12AGND 13AGND 14
DOUT 15
BUSY 16
DIN17
CS18
DCLK19
+VCC20
C17 100nFC17 100nF
R4 270RR4 270R
C12 27pfC12 27pf
C4100nFC4100nF
C13 27pfC13 27pf
C15 470nFC15 470nF
Q7
IRLML6402
Q7
IRLML6402
U5
PIC18f6722
U5
PIC18f6722
RE1/WR/P2C1 RE0/RD/P2D2
RG0/ECCP3/P3A3RG1/TX2/CK24RG2/RX2/DT25RG3/CCP4/P3D6
RG5/MCLR/Vpp7 RG4/CCP5/P1D8
Vss 9
Vdd 10
RF7/SS111 RF6/AN1112 RF5/AN10/CVref13 RF4/AN914 RF3/AN815 RF2/AN7/C1OUT16 RF1/AN6/C2OUT17 RF0/AN518
AVdd19AVss20
RA3/AN3/Vref+21 RA2/AN2/Vref-22 RA1/AN123 RA0/AN024
Vss 25
Vdd 26
RA5/AN4/HLVDIN27 RA4/T0CKI28
RC1/T1OSI/ECCP2/P2A 29RC0/T1OSO/T13CKI 30
RC6/TX1/CK1 31RC7/RX1/DT1 32
RC2/ECCP1/P1A 33RC3/SCK1/SCL1 34RC4/SDI1/SDA1 35
RC5/SDO1 36
Vdd 38
RB7/KBI3/PGD 37
OSC1/CLKI/RA739OSC2/CLKO/RA640 Vss 41
RB6/KBI2/PGC 42RB5/KBI/PGM 43RB4/KBI0 44RB3/INT3 45RB2/INT2 46RB1/INT1 47RB0/INT0 48
RD7/PSP7/SS2 49RD6/PSP6/SCK2/SCL2 50RD5/PSP5/SDI2/SDA2 51RD4/PSP4/SDO2 52RD3/PSP3 53RD2/PSP2 54RD1/PSP1 55
Vss 56
Vdd 57
RD0/PSP0 58
RE7/ECCP2/P2A59 RE6/P1B60 RE5/P1C61 RE4/P3B62 RE3/P3C63 RE2/CS/P2B64
D1
HSME-C191
D1
HSME-C191
J3
CONN RCPT 25x2
J3
CONN RCPT 25x2
2468101214161820222426283032343638404244464850
13579
1113151719212325272931333537394143454749
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
Power In DCDC_IN
3.3V Enable
FB
SW
Pwr_protected
Power EN
+3.3V+5V
+6V
+5V
+6V
+5V
Power In
3.3V Enable
Low Battery
Power EN
Title
Size Document Number Rev
Date: Sheet of
Data Logger 1.2a
Power Supply
A
5 6Tuesday, October 02, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger 1.2a
Power Supply
A
5 6Tuesday, October 02, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger 1.2a
Power Supply
A
5 6Tuesday, October 02, 2007
By powering the 3.3V regulator from the 5V line the boardcan accept a 5V supply without modification. - 5V and 6V regulators are automatically disabled - There is no reverse polarity protection in this case - There is little loss of efficiency
Vdiv sets trigger at 6.48V
Tants are used on linear regs as Cout as the ESR helpswith stability at low currents.
Vdiv sets output at 6.05V
Mosfet to stop current return
R34 should be big - 510k
Q10IRLML6402
Q10IRLML6402
+ CT222uF
+ CT222uF
Q4IRLML6402Q4IRLML6402
R2824kR2824k
U16
REG102-5
U16
REG102-5
Vout 1Vout 2
NR 3Gnd 4Enable5 NC6 Vin7 Vin8
R25100kR25100k
U18
TPS62110_ADJ_17P
U18
TPS62110_ADJ_17P
AGND9
GND11GND12
PGND1PGND16
VINA8 SW 14SW 15
LBO 6PG 13
EN4
FB 10
LBI7SYNC5
VIN2VIN3
CL447uF
CL447uF
C34100nFC34100nF
CL310uF
CL310uF
L1
10uH
L1
10uHR27 100kR27 100kR26
1MR261M
Q11IRLML2502Q11IRLML2502
R29510kR29510k
U15
REG102-3.3
U15
REG102-3.3
Vout 1Vout 2
NR 3Enable5 Gnd 4
Vin7 Vin8
NC6+ CT1
22uF+ CT1
22uF
R32100kR32100k
C3122pfC3122pf
C301uF
C301uF
R30120kR30120k
R34DPR34DPC33
10nFC3310nF
C35100nFC35100nFC32
10nFC3210nF
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
Iconst2+
Iconst1-
Iconst1+
ConstC Supply
Iconst2-
A2D Supply ConstC Supply
ConstC Supply
ConstC Switch
Iconst2- Iconst1-
Iconst2+ Iconst1+
A2D Supply
ConstC Switch
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
LED Constant current circuit
A
1 6Monday, October 01, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
LED Constant current circuit
A
1 6Monday, October 01, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
LED Constant current circuit
A
1 6Monday, October 01, 2007
Current = 0.065 * ( 1/Rp1 + 1/Rp2) Current = 0.065/Rp
As long as the equation for the current in the LED contains a resistive term it will have temperature dependence.
Q1
BC859C
Q1
BC859C
RP33RRP33R
Q9IRLML6402
Q9IRLML6402
RP13RRP13R
Q2
BC859C
Q2
BC859C
RP2DPRP2DP
LM234-3
U1
LM234-3
U1
V+ 1
R 2
V- 3
RP4DPRP4DP
LM234-3
U2
LM234-3
U2
V+ 1
R 2
V- 3
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
Vbat
i2c_sclk
i2c_sda
i2c_sda
i2c_sclk
rtc_int
temp_int
i2c_sclki2c_sda
DS1721_SH
FRAM_SH
+5V
+3.3V
+5V
+5V
i2c_sda
i2c_sclk
i2c_sda
i2c_sclk
rtc_int
temp_int
i2c_sclki2c_sda
DS1721_SH
FRAM_SH
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
I2C Bus
A
3 6Monday, October 01, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
I2C Bus
A
3 6Monday, October 01, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
I2C Bus
A
3 6Monday, October 01, 2007
Addr = 1101 000x
Addr = 1001 000x
Addr = 1010 000x
For the FM24C512 the A0 bit is used the address MSB.This means it is worth also leaving the alternate addressunused: Addr = 1010 001x.
R2110kR21
10k
C25 100nFC25 100nF
C24100nFC24100nFC23
100nFC23
100nF
U8
DS1339C_16P
U8
DS1339C_16P
NC4 4NC5 5
VBACKUP14 GND 15
SDA16
SCL 1
SQW/INT2
VCC3
NC6 6NC7 7NC8 8NC9 9
NC10 10NC11 11NC12 12NC13 13
Q15IRLML6402Q15IRLML6402
DS1721S+
U19
DS1721S+
U19
SDA1
SCL 2
TOUT 3
GND 4
A25 A16 A07
VDD8
U11
FM24C256
U11
FM24C256
A01A12A23Vss4 SDA 5SCL 6WP 7Vdd 8
U10Battery
U10Battery
+2
-1
Q14IRLML6402
Q14IRLML6402
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
mmc_sclkmmc_mosimmc_miso
mmc_ssmmc_mosi
mmc_sclk
mmc_miso
spi1_ss0spi1_sclk
spi1_miso
mmc_ssmmc_pwr
spi1_mosi
mmc_switch
mmc_detect
+5V
+3.3V
+3.3V
+3.3V
+5V
spi1_ss0spi1_sclk
spi1_misospi1_mosi
mmc_switch
mmc_detect
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
MMC Interface
A4
4 6Monday, October 01, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
MMC Interface
A4
4 6Monday, October 01, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
MMC Interface
A4
4 6Monday, October 01, 2007
New MMC socket with standoff - Common not connected to case - Detect goes low on card present - Case connected to ground - Write prtoect ignored - Pins 8&9 are for SD mode
U13
MAX3392EEUD
U13
MAX3392EEUD
VL1OVL12OVL23OVL34IVL45NC6GND7 Three-State 8NC 9OVcc4 10IVcc3 11IVcc2 12IVcc1 13Vcc 14 R22
10kR2210k
C29
100nF
C29
100nF
R2310kR2310k
C28
100nF
C28
100nF
R24270kR24270k
U12
SCDA1A1301
U12
SCDA1A1301
MMC_SS 1MMC_mosi 2MMC_gnd 3MMC_pwr 4MMC_sclk 5MMC_gnd 6
MMC_miso 7
Pin9 (SD) 9Card Detect 10
Sheild13
Write Protect12
Common 11
Pin8 (SD) 8
C26
100nf
C26
100nf
Q3
IRLML6402
Q3
IRLML6402
C27100nfC27
100nf
5
5
4
4
3
3
2
2
1
1
D D
C C
B B
A A
USB_DM
USB_DP
pic_USB_tx
pic_USB_rx
USB_RTS
USB_CTS
USB_ENABLE
PWREN#
+5V
USB_DM
USB_DP
pic_USB_tx
pic_USB_rx
USB_RTS
USB_CTS
USB_ENABLE
USB_CONNECT
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
USB2.0 Interface
A
6 6Wednesday, October 03, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
USB2.0 Interface
A
6 6Wednesday, October 03, 2007
Title
Size Document Number Rev
Date: Sheet of
Data Logger v1.2 1.2a
USB2.0 Interface
A
6 6Wednesday, October 03, 2007
Sheild unconnected ascable will be sheildedfrom PC end.
USB power is detected by the PIC and then the FT232RQis enabled
U17
FT232RQ
U17
FT232RQ
VccIO1Vcc19
Data Minus15
Data Plus14
NC5NC12NC13
NC25NC29
NC23
Reset#18OscI27OscO283v3 out16
AGnd24Gnd4Gnd17Gnd20Test26
TXD 30
RXD 2
RTS# 32DTR# 31
CTS# 8DSR# 6
RI# 3DCD# 7
CBus0 22CBus1 21CBus2 10CBus3 11CBus4 9
C39 100nFC39 100nF
Q13IRLML6402
Q13IRLML6402
C38100nFC38100nF
TPS1TPS1
1
C37100nF
C37100nF
iii
Appendix 3 Payload Management System technical drawing
SCALE 1 : 1
DRAWNEd WaughCHECKED
QA
MFG
APPROVED
01/11/2007Sensors Group, NOC, UK
TITLE
Stacked SGDL v1.2
SIZE
A4SCALE
DWG NO
SGDL Stacked together assemblyREV
SHEET 1 OF 1
47.0
0
60.00
40.2
0
15.0
0
10.0
0
26.3
9
36.5
5
46.80
37.7
0
9.50 12
.00
iv
Appendix 4 Project specifications for student groups
ECS Group Project Specification
Previous Unmanned Aerial Vehicle (UAV) research and student projects at the National
Oceanography Centre (NOC) have focussed on developing and demonstrating a flying
vehicle. With these goals now achieved, the next phase of research must develop the
payload that the vehicle will carry. Many of the components in the payload will be off
the shelf and these must be integrated with data logging to create a complete system
that is independent from the rest of the UAV.
Areas of work
• Consultation with oceanographic scientists to determine a useful and achievable
payload
• Selection and acquisition of appropriate sensors
• Use of the NOC sensors group data logger to synchronise and record data
• Integration of sensors with data logging and power supply within the 1.5Kg
weight limit
• Development of data processing software for windows in C# or Matlab
• Testing of sensor package
• Flight test of sensor package
Possible sensors
• Visible light imaging
• Infra‐red and/or ultra‐violet measurement or imaging
• Atmospheric sensors
• Ambient light measurement (for calibration of images)
Deliverables
• Project report detailing design process and justification of decisions
• An integrated sensor payload ready for deployment on the UAV
• An instruction manual detailing the setup and operation of the payload
• Details of all equipment used allowing easy replacement or the manufacture of
additional payloads
• Easy to use software for processing the returned data and creating files that are
useful to the oceanographic scientists and that integrate with packages they
currently use
SES GDP Specification 2007
The Unmanned Aerial Vehicle (UAV) project at the National Oceanography Centre
(NOC) is now in its fifth year of development. The fundamental design decisions for the
vehicle have been taken and the focus is now shifting to refining the aerodynamic
performance. This includes improvements to the lift over drag (L/D) as well as
characterising and improving the dynamic performance of the aircraft during
manoeuvres. The characterisation of the vehicle should also result in a model suitable
for use in flight control system modelling.
Areas of work
• Make a redesign of the tail to an inverted V design for improved aerodynamic
performance and have this manufactured to fit the existing wind tunnel model
• Enhance the existing wind tunnel model to include adjustable ailerons, elevators
and rudders
• Measure the performance of the model in the wind tunnel in a variety of
conditions to determine the control authority available and the effectiveness of
the redundant systems
• Develop a model of the vehicle with both types of tail in Aerosim and compare
this to the model generated by AVL
Deliverables
• Project report detailing design process and the decisions made
• New more efficient tail design
• Half scale model of both designs of tail with adjustable surfaces
• Conclusions about the effectiveness of the current tail, suggestions for
improvement and comparison with the new design
• An Aerosim model of the vehicle based on tunnel data that can be compared
with one generated by AVL
v
Appendix 5 Contents of accompanying CD
Name Description
Transfer Report.pdf A copy of this report
Flight Test Videos Video footage of flight tests, requires XVid codec (supplied)
‐ Flight Test 1 Launch failure due to lack of speed
‐ Flight Test 2 Launch failure due to release mechanism
‐ Flight Test 3 Longest flight
‐ Flight Test 4 Climb too steep (discussed in Chapter 6)
![[Article] Unmanned aerial vehicle remotely sensed datasets, a …geodata.kr/assets/pdf/7/journal-1-1-38.pdf · generated using rotary-wing UAV(unmanned aerial vehicle) system for](https://img.pdfslide.tips/doc/110x75/5e99aef244dfab24c12e8cfc/article-unmanned-aerial-vehicle-remotely-sensed-datasets-a-generated-using-rotary-wing.jpg)
![[8 126-137최종]김학진 Use of Unmanned Aerial Vehicle for Multi](https://img.pdfslide.tips/doc/110x75/621da6510336ac7495452ef5/8-126-137-use-of-unmanned-aerial-vehicle-for-multi-.jpg)
