Final Year Project Report Latest Version

Loughborough University

Department of Aeronautical & Automotive Engineering

10TTD001 – Final Year Project

Main Report

Development of Autonomous Landing System for Fixed Wing Unmanned Aerial Vehicles

By James Dunthorne – A761579

Supervisor: Dr Wen-Hua Chen

January 2011

Development Of Autonomous Landing System for Unmanned Aerial Vehicles

ABSTRACT

This paper aims to develop autonomous landing system capabilities for small, fixed wing, Unmanned Aerial Vehicles (UAV’s) at Loughborough University. Very little work has been conducted on fixed wing aircraft in the department, and outdoor tests have been conducted very infrequently so a lot of work was required before any flight testing could be achieved. Micropilot is an Autopilot system for UAV’s. In order to develop control algorithms for fixed wing landings, Micropilot was thought of as being a useful learning tool, and would provide a good benchmark for the Universities own Autopilot so was investigated further

This report starts by looking at a list of regulations that the CAA have set out for unmanned aerial vehicles (UAV’s) including CAP722 and CAP393. Some of these regulations are compulsory by law and therefore needed observing before any flight testing could be carried out. It was found that a company called EuroUSC has been recently certified by the CAA to regulate UAV operations, but the Universities UAV’s are all under the 20kg threshold for it to apply. However an operational structure was developed in order to close the gap between our operating procedures and EuroUSC’s. An internal regulatory framework was developed and is included in the Appendices in order to start this process and provide an operating site some confidence that the lab was working responsibly. This developed into talks with Derby Airfield who were very enthusiastic about have Loughborough University operating there and granted us permission to fly. Third party insurance could then be purchased from the BMFA in order to reduce the risk of personal liability.

The report then looks into hardware, especially Above Ground Level (AGL) sensors and Autopilots. These were researched and AGL’s were required in order to provide accurate height measurements to the aircraft. The sensors needed to be light weight, low power and compatible with both Micropilot and the Universities autopilot. Two Sharp Infra-Red (IR) sensors were purchased, one with a certified range of 0.1-0.8m and the other 1.0-5.5m. A PIC4520 Microprocessor was programmed with code in order to provide a full 5m range height measurement right down to the floor, but it was found that outputting the data via Serial slowed the speed of the device so much that the filters introduced too much latency.

A Simulink Model is then developed in order to test the switching algorithms and optimise the filters. It is found from this model that using just two sensors introduces noise at the crossover point of the two sensors (0.8-1.0m). This was programmed and tested on the hardware and the same noise was also confirmed. This meant that a third sensor was needed in order to remove this crossover noise. Another Simulink Model was developed and tested again. This time there was very little noise at all and again the algorithms were written to the hardware and tested. With minor adjustment an accurate and full 0.1-5.5m height range data set was achieved. The sensors needed interfacing with Micropilot using Pulse Width Modulation which was coded, interfaced, tested and found to work well.

Micropilot is then setup and installed, along with the Horizon ground control software that comes with the autopilot. Once setup, several flight test days are planned but due to weather constraints they were not flyable. Eventually, the weather improved and a flight test day was conducted, testing out the new operational procedures that had been developed. This involved filling out forms and making sure people were aware of their individual roles as per the Operations Manual that was developed. A data logging flight is performed and the results discussed. All sensors seemed to be working correctly and as expected, and the AGL seemed to perform well. Calibration of pressure height was needed in order to smooth out the transition between that and AGL height.

Further work can involve the continuation of Micropilot setup including tuning of gains and waypoint tracking. Once that has been achieved an autonomous landing can be investigated and some of these techniques could be applied to the Universities autopilot system

2James Dunthorne - A761579


TABLE OF CONTENTS

Abstract.................................................................................................................................................................2

Nomenclature.......................................................................................................................................................4

Acknowledgements...............................................................................................................................................5

1 Introduction..................................................................................................................................................5

Aim....................................................................................................................................................................6

Objectives.........................................................................................................................................................6

2.0 Literature Review & Preparation..............................................................................................................6

2.1 Unmanned Aerial Vehicles...................................................................................................................6

2.2 External Regulation..............................................................................................................................7

2.3 Insurance..............................................................................................................................................9

2.4 Operating Site......................................................................................................................................9

2.5 Internal Regulation.............................................................................................................................11

2.6 Types of Landing................................................................................................................................11

2.7 Test Vehicle........................................................................................................................................15

2.8 Hardware...........................................................................................................................................16

3 Hardware Selection....................................................................................................................................16

3.1 Autopilots...........................................................................................................................................16

3.2 AGL Sensors.......................................................................................................................................19

3.2.1 Ultrasonic Altimeters.................................................................................................................20

3.2.2 Laser Range Finders...................................................................................................................21

3.2.3 Infra-Red Sensors......................................................................................................................22

4 Hardware Development.............................................................................................................................23

4.1 Sensor Verification and Modelling.....................................................................................................23

4.2 AGL Revision 1....................................................................................................................................24

4.3 AGL Revision 2....................................................................................................................................27

4.3.1 Hardware Design.......................................................................................................................27

4.3.2 Simulink Model..........................................................................................................................28

4.3.3 Hardware Programming............................................................................................................35



4.4 AGL Revision 3....................................................................................................................................36

4.4.1 Simulink Model..........................................................................................................................36

4.4.2 Hardware Testing......................................................................................................................37

4.5 Interfacing With Micropilot................................................................................................................38

4.6 Installation Issues...............................................................................................................................39

4.6.1 Sensor Interference...................................................................................................................39

4.6.1 Divergent Dynamic Behaviour Due To Rotation Of Aircraft.......................................................39

5 Micropilot...................................................................................................................................................41

5.1 Hardware Installation.........................................................................................................................41

5.2 Software Installation & Setup............................................................................................................42

5.3 Post Installation Checks......................................................................................................................43

5.4 Administration...................................................................................................................................44

5.5 Flight Test 1........................................................................................................................................44

5.6 Flight Test 2........................................................................................................................................45

5.7 Flight Test Results..............................................................................................................................45

5.7.1 Flight Speed...............................................................................................................................45

5.7.2 GPS Data Plot.............................................................................................................................46

5.7.3 Height Data................................................................................................................................49

5.7.4 3D GPS Plot................................................................................................................................51

5.7.5 Attitude Data.............................................................................................................................51

5.7.6 Further Testing..........................................................................................................................52

6 Conclusion..................................................................................................................................................54

Bibliography........................................................................................................................................................56



NOMENCLATURE

d Distance (m)

h Height (m)

k Gain

R Mean Radius of Earth (6,378,000m)

V Voltage (V)

X Distance from Origin (N-S component) (m)

Y Distance from Origin (E-W component) (m)

φ Bearing (Deg)

Ø Latitude (Deg)

λ Longitude (Deg)

Subscripts:

*S referring to short range sensor

*L referring to long range sensor

*L2 referring to new long range sensors

*1 referring to origin

*2 referring to new point

ACKNOWLEDGEMENTS

This work was undertaken in the SEIC building at Loughborough University with the Autonomous Systems Laboratory.

I would like to thank Jonathan Clarke and Owen McAree for their help with supervising me on this project. Hardware was developed in consultation with Jonathon and Air Law and Regulation was investigated in consultation with Owen.

Finally, I would like to thank Dr W. H. Chen for his continued help and supervision of the project.



1 INTRODUCTION

Loughborough University has been developing an avionics suite and autopilot used to control small Unmanned Aerial Vehicles (UAV’s). Many of the control algorithms are developed and tested indoors for rotary aircraft but outdoor autonomous flights are still yet to be achieved. Fixed wing UAV control strategy has seen very little development in the last few years at Loughborough mainly down to operational constraints, such as:

Needing landowners permission to conduct tests Having poor weather Conforming with CAA regulation and air law Insurance Time taken to setup equipment ready for test

Historically, outdoor testing of fixed wing aircraft systems has always taken a long while in the department and it’s this that has really hindered the universities development in the area.

The CAA has recently certified a company to regulate UAV operations over 20kg. Civil fixed wing UAV technology is therefore going to be developing very quickly within the next 10 years and commercial applications are already starting to be introduced. The motivation for this project is to develop the Universities understanding of fixed wing flight control so that an Autopilot can be developed and further the Universities understanding of this area of research.

AIM

The aim of this report is to develop an understanding of the current strategies that are being used to conduct an autonomous landing of fixed wing UAV’s, in order to develop the universities capabilities in this area.

OBJECTIVES

Develop an operational framework so ease fixed wing operations Find an appropriate testing facility Develop hardware to enable to autonomous landing of UAV’s Install Micropilot, setup the flight control gains and investigate its performance Conduct an autonomous landing and use this to develop algorithms

Chapter 2 begins with the development of the framework used to conduct outdoor flight testing, including regulation, insurance and operating sites. Some background information of the area is also covered. Hardware options are covered in Chapter 3 and the development of the hardware is discussed in Chapter 4. Micropilot is installed and tested in Chapter 5, and then finally all work is concluded



2.0 LITERATURE REVIEW & PREPARATION

2.1 UNMANNED AERIAL VEHICLES

Unmanned Aerial Vehicles (UAVs) are aircraft without any human crew on board. They have seen rapid development over the last few years being used in Iraq and Afghanistan. UAV’s have been used to carry cameras, sensors and communications equipment for use in surveillance and intelligence roles since the 1950s(1). Only within the last 15 years has UAV development really accelerated. The advancement of cheap, highly accurate, Micro- Electrical Mechanical Systems (MEMS) sensors has meant that building a UAV has become accessible to almost anyone. Removing the pilot from the aircraft has many advantages. Here are just a few:

Weight – The aircraft no longer needs a crew onboard and the associated structures in place to capacitate them, saving weight and improving performance

Space– The aircraft no longer has to accommodate large, bulky crew, so a much greater range of geometric shapes, sizes and configurations can be used to improve performance. An example of the complexity of these shapes can be seen in Figure 1.

Greater Endurance – Pilots require feeding and resting which inherently reduces the endurance of many aircraft. Removing them helps to reduce this problem.

Reduced Risk – The RAF say that their pilots are their most valuable assets (2) so removing them from dangerous situations is desirable to both them and their families.

Increases ‘g’ Limitation – Pilots are not very tolerant of high ‘g’ manoeuvring, so removing them from the aircraft removes this limitation on performance.

Cost – Aircraft can be smaller and have lower operating costs. This is probably one of the most influential factors which has caused such a rapid growth in the industry

FIGURE 1 – A PHOTO OF A BOEING PHANTOM RAY TAKEN AT FARNBOROUGH AIR SHOW 2010



UAV’s can be split into two main categories-

Remotely Piloted – These are aircraft that are controlled from the ground by a pilot. In military applications the pilot will have several screens and often there are large teams of engineers monitoring data being streamed back from the UAV to check it is functioning correctly.

Fully Autonomous – These are aircraft which can fly without the aid of any ground pilot. Usually they are programmed with GPS co-ordinates which they follow whilst performing tasks on route such as surveillance. Control systems must be able to mimic the pilots control actions, decision making, and problem solving capabilities. (3) Most of the research being undertaken at the university on UAV’s is within this area.

Sometimes UAV’s fall somewhere in the middle of these groups, being operated autonomously during most of the flight and being manually operated for the remainder. This usually happens when the UAV has to perform complicated tasks which are beyond the capability of the control system. This project focuses on fully autonomous UAV’s and looks to remove the pilot totally from the loop. During testing, some aircraft have the ability to be remotely piloted so that control system failure doesn’t lead to the demise of the aircraft.

2.2 EXTERNAL REGULATION

Previous work by Adam D’Amore on “Autopilot Development for Outdoor Model Helecopters” has looked into legislation set out by the CAA for outdoor operation (4). Some of these regulations have been updated so will require further clarification.

UAV’s used for civil applications are under extremely heavy restrictions, compared with their military counterparts. When flying UAV’s for civilian purposes, such as research, the following applies:

1. Air Navigation Order (ANO) CAP393 (5), especially part 22, articles 166 and 167 (Appendix 1) highlight the following restrictions amongst others for UAV’s below 20kg:

The pilot must remain in direct line of sight at all times during operation Must not fly within 150m of congested areas Aircraft must not be flown more than 400ft above the ground unless you are flying in a

private Air Traffic Zone (ATZ) and have permission from the site It is illegal to fly UAV’s for the purposes of aerial work unless permission is granted by the

CAA. Aerial work is defined as any flights in which profit is made, so to do this, an exemption is needed from the CAA

2. CAP 722 (6) highlights some other relevant restrictions for UAV’s:

Aircraft must not be flown any further than 500m or line of sight from the pilot in command (whichever is smaller)

Within 50m of any person, or vehicle that is not under the control of the pilot Within 30m of a person on take-off or landing If operating below 7kg, insurance is not a requirement, although the operator remains

personally liable for any injury or damages caused.

As soon as any sensors are placed within a vehicle, that vehicle is then classified as a UAV, so all of these restrictions apply. This drastically limits the ease of data acquisition and testing when operating outdoors.



The CAA has recently certified an organisation called EuroUSC to regulate UAV operations. Currently there are no requirements to obtain certification for a UAV pilot’s license, although the CAA has made it quite clear that this is the way regulation is heading in the near future. In order to qualify for EuroUSC’s British National Unmanned Air System Certificate (BNUC-S) (7), many steps are required. The aim of the BNUC certification process is to train potential UAV pilots to operate in the environment they are most likely to encounter. The BNUC-S qualification consists of two parts:

Ground School Examination covering:

1. Regulation of UAV’s including relevant parts of CAP382, CAP393, CAP403 and CAP7222. Air law3. Aircraft General Knowledge Planning4. Human factors, performance and limitations5. Meteorology6. Navigation and map interpretation7. Operational Procedures8. Communications

Flight Test Examination covering:

1. Planning2. Pre-flight preparation & checks3. Flight Test4. Post-flight checks5. Emergency Handling6. Other considerations

This regulatory framework has only come into operation within the last 12 months, so many of the constraints are in development. Although this framework is not immediately needed in order to operate UAV’s for research purposes, it is good practice for the department to start drawing together a set of procedures and best practices, ready for when this legislation comes into force with greater effect. This will require documenting much of what the department does which will take more time, but will reduce the risk of operating and show a level of professionalism.

This project will require some of this framework to be constructed, so that Loughborough University is seen to operate responsibly and to ensure that the risk of personal injury is kept to a minimum. This has the added benefit of reducing the attrition rate of equipment and prepares the department for future frameworks that seem likely to be enforced very soon. If this structure is not developed now, there is a risk that future outdoor operations may be restricted even more than they are already, making outdoor testing almost impossible. The beginning of this framework is covered in Chapter 2.5.

2.3 INSURANCE

Although insurance is not a requirement by law, the British Model Flying Association covers UAV operators against 3rd party loss or damages, as long as the pilot is able to regain manual control of the aircraft at all times during testing and as long as Landowners permission is granted before the flight. If the aircraft were to crash into anything or anyone, causing damage or injury, the university and possibly the operator, would remain



liable. Therefore this insurance was purchased to remove any risk of personal or corporate liability, and to provide reassurance for the land owner, so that they are happy for operations to begin.

2.4 OPERATING SITE

Due to the constraints of the regulations and insurance governing UAV’s, an appropriate flying site is required to conduct any form of outdoor testing with sensors. This site needs to be able to fulfil the following set of criteria:

1. Permission to fly UAV’s on the site must be granted by the landowner2. The site must be large enough in order to conduct a full rectangular circuit of at least 200m by 100m

allowing for clearances of 150m from any built up areas. This requires a space of 500m x 400m3. The site must be suitable for launching and landing UAV’s from – i.e. Flat landing strip, no large

obstructions, no interference from electromagnetic sources.4. The airspace must be unrestricted, ideally within a private ATZ.5. The site must be operable from, for little if not no cost6. Close proximity to the University is desirable in order to reduce damage to vehicles during transit, and

to make flight testing more practical

The University has permission for Holywell pitches, on the University grounds, to be used for flight testing. However the area means the circuit would be very cramped, which will drastically restrict the level of testing that can be carried out. Another site was needed to be able to conduct any meaningful outdoor tests without the same level of risk.

Contact was made with the Chief Flying Instructor, Colin Davey, at Four Counties Gliding Club based at RAF Wittering, and he granted us permission to fly there at weekends for free. During the week the RAF still operates at the base, so this was not an option. In terms of size, there would be no problems as the site is very large and open. However the site is quite a distance from the University, about 1 hour drive, and the weekend only limitation is not very practical. This site was a useful alternative for weekends, and there is even sleeping arrangements if overnight stay was needed. Continuation of this agreement would likely require the operator to be a member of Loughborough Students Union Gliding Club and speak to Colin Davey, as the agreement was a personal one.

A meeting with Martin Jones was then arranged via a friend, at Derby Airfield. Derby airfield operates small fixed wing aircraft, and has three runways as shown in Figure 2. A more detailed map of the airfield is given in Appendix 2. The area is very large, and has its own ATZ. It is only 30 minutes from Loughborough by car and we can operate there any time during the week.

They were keen to form relations with Loughborough University and an operation framework was discussed. It was decided that Loughborough would develop a UAV Operations Manual, in order to satisfy Derby Airfield that we had the necessary procedures to negate risk. Money has not yet been discussed, and they are happy to let us operate free of charge.



FIGURE 2 - DERBY AIRFIELD OVERVIEW

2.5 INTERNAL REGULATION

After plenty of discussion and refinement, an Operation Manual was drafted (Appendix 3) in consultation with Owen McAree. This document goes through how we internally regulate ourselves and how responsibilities are arranged. It discusses what each role requires and also how we internally qualify ourselves for the roles. It also set out the laws and regulations that must be observed when operating UAV’s in a civil environment.

Registration forms for airframes were designed (Appendix 4) so that a modular approach is built up into the manufacturing process. Once complete the work could then be signed off by an internally qualified member of the team who is happy with the work. These internal qualifications are awarded by demonstrating the required skills for that role. For certain roles, external qualification is needed in order to be signed off, such as Radio Telephony licenses.

Flight log sheets and Flight Test Programme forms were also designed (Appendices 5 & 6) in order to ensure that flight times were recorded, all equipment was in attendance and any potential risks could be avoided when conducting outdoor flight tests. All of these forms and procedures were drafted out specifically for this project, but will massively help future student who wish to carry out outdoor testing.

These documents are intended as the basis for all future outdoor UAV operations by Loughborough University, regardless of the location of operation. This will help prepare for future frameworks that are very likely to come into place within the near future. If the university wishes to operate UAV’s above 20kg, this BNUC-S certificate is compulsory, so building this framework now will future proof the departments operations.



The advantages of this internal regulatory framework are:

Statistical data can be generated from logs allowing mitigation of risks Individuals understand their responsibilities and roles, and accidents are avoided So called “Short cuts” are avoided, so modular design approach can be realized reliably To show a level of professionalism to other organisations in the industry To comply with CAA regulations and the law

It has been decided that all future airframes will be dealt with in this new framework, and old airframes will be slowly transferred over to it. Every component shall be labelled and logged, so that at any time the University can verify the age and life expectancy of the parts on any of our aircraft to the UAV regulators EuroUSC. This will be done using a component master sheet, and when components are taken on or off an aircraft, the parts shall be logged on this sheet. This is likely to give the department much more flexibility when the framework becomes compulsory.

2.6 TYPES OF LANDING

There are many different strategies to land UAV’s compared with conventional aircraft. Each strategy relies on different data sets and algorithms in order to function appropriately. Here is a list of current known landing techniques:

1. Constant Decent Rate Landing (Figure 3) – This is when the aircraft descends at its minimum sink rate and the aircraft purely maintains speed. This strategy is often used with flying wing designs where the aircraft is less than 1kg such as the Sensefly Swinglet CAM shown in Figure 4 (8). For these lightweight designs a slight bump on landing is not critical, but for larger aircraft, this is much more of a problem, and this type of landing reduces the number of air-ground cycles before inspection is needed.

FIGURE 3 - MIMIMUM SINK CONSTANT DESCENT RATE LANDING



FIGURE 4 - SENSEFLY SWINGLET CAM

2. Deep Stall landing – This is entered by pitching the aircraft up at low speed and fully stalling both wings. Due to the large drag during this state of flight, the aircraft floats down to the ground quite slowly and remains controllable (9). This is usually used for aircraft 500g or less as otherwise the aircraft can get damaged when it hits the ground, despite. The Skylark by Elbit Systems (10) is a little larger but still uses this method of landing. It achieves this by deploying an airbag underneath the aircraft in order to protect the still quite hard landing as shown in Figure 5. This method is quite effective but it does limit the maximum take-off weight (MTOW) of the aircraft considerably.

FIGURE 5 - DEEP STALL LANDING BY SKYLARK (ELBIT SYSTEMS)

3. Parachute deployment – This is often used for aircraft such as the Brammor by C-Astral (11). Slightly larger aircraft, often with a front mounted propeller or jet engine. When the aircraft is over the landing area, a parachute is deployed and the aircraft floats back down as shown in Figure 6. This requires the parachute to be repacked on each launch and also takes up a reasonable amount of space in the aircraft that could be used for payload.



FIGURE 6 - PARACHUTE LANDING

4. Traditional Landing – This is the most widely used type of landing and requires quite complex control methods. The aircraft descends at a constant speed, but once it gets to an acceptable height, the aircraft flares by applying some elevator so that it levels out just above the ground as shown in Figure7. The attitude of the aircraft is held until the aircraft gently touches down. This is the method that nearly all passenger aircraft employ, as the aircraft is then ready to take-off and conduct another mission assuming enough fuel. This method of landing is usually the preferred choice for larger aircraft that are carrying expensive electronics, but does require complex control algorithms as well as large spaces in which to land the aircraft.

FIGURE 7 - DORNIER 335 FLARING BEFORE TOUCHDOWN



5. Vertical “Prop-Hang” Landing – This is the most demanding of landing techniques and requires an aircraft with Power to Weight ratio greater than 1. The aircraft prepares itself for landing by coming in at high angles of attack, and then the responsibility for lift is transferred from the wings to the propeller. The aircraft stabilizes itself with conventional controls (elevator, ailerons and rudder), and then descends by reducing the throttle input. This requires a stiff tail mount to avoid breakages, and is also very demanding on the control system. Massachusetts Institute of Technology (MIT) has a project running at the moment investigating this feature (12). A picture of their setup is shown in Figure 3. It was thought that this technique would be difficult to implement with the universities current sensor suites as it introduces problems with Euler angles. Quaternions would be needed as otherwise singularities appear in the algorithms when at 90 degree pitch. At the moment all of the universities algorithms are derived from Euler angles thus making this type of landing very difficult. Simon Howroyd at Loughborough University has been doing some work on Quaternion’s, so this type of landing may become possible in the near future.

FIGURE 8 - AUTONOMOUS PROP-HANG AT MIT IN CALIFORNIA

The method of landing was dictated primarily by the size and weight of the UAV, and by the types of mission that the aircraft was intending on doing. The most helpful type of landing for the department to develop is the traditional approach, and most of the work the university has focused on, has been for the type and size of aircraft that requires this. The amount of ground to air cycles was also a major concern, so this method of landing was thought to add the most value to the department as well as being relevant in industry.

2.7 TEST VEHICLE

In order to conduct tests, an aircraft was selected. The university owns three Seagull Pioneer training aircraft, two, Showtime 50’s and an Extra 300. The Pioneer is the most stable out of the three, and also is the lightest and cheapest aircraft. It is powered with an electric motor and is very easy to fly. It has enough internal volume to fit plenty of electronics, and can be modified easily. The Showtime is slightly larger and heavier than the Pioneer but is much more manoeuvrable. Its stall behaviour is poor and it has a much lower thrust to weight ratio. The Extra 300 is even larger with a 3m wingspan and is extremely heavy. This, and the fact that the aircraft has still not flown yet, ruled it out for testing.



The Pioneer was chosen as the test vehicle, as it is cheap, lightweight, is naturally stable and has plenty of internal space. It also requires little certification in order to fly autonomously as it is below the 7kg threshold set by the CAA (13). The aircraft can be seen in Figure 9 below.

FIGURE 9 - SEAGULL PIONEER TRAINING AIRCRAFT USED FOR TESTING

2.8 HARDWARE

In order to fly UAV’s autonomously some items of hardware are needed:

UAV Airframe – Chosen to be the Seagull Pioneer as shown in Figure 9 High Quality Servos – Nose Wheel, Left and Right Ailerons, Rudder & Elevator (5 Total) High Current Speed Controller – To control electric Motor 770Kv Electric Motor – E-flight 32 as in Figure 10 2.4GHz Remote Control Receiver – To ensure that manual control of the vehicle can be taken at any

time without the risk of interference Autopilot – To process data and flight control algorithms Avionics – Attitude Heading Reference System (AHRS), Inertial Navigation System (INS) and Global

Positioning System (GPS) which all tell the aircraft its location and orientation RF Modem & Antenna – To communicate to a ground station Above Ground Level (AGL) Sensor – Gives an accurate reading of height above ground (Used for

landing) Batteries & Voltage Regulators – To control levels of power in the system

FIGURE 10 - E-FLIGHT 32 ELECTRIC MOTOR



3 HARDWARE SELECTION

3.1 AUTOPILOTS

Autopilots have been around for a long time, and are used on the majority of commercial flights nowadays, to fly most, if not all of the journey. They are also being used more frequently in military scenarios due to the benefits mentioned previously.

The first aircraft autopilot was developed by Sperry Corporation in 1912. The autopilot connected a gyroscopic Heading indicator and attitude indicator to hydraulically operated elevators and rudder. It permitted the aircraft to fly straight and level on a compass course without a pilot's attention, greatly reducing the pilot's workload. (14)

3.1.1 UNIVERSITY AUTOPILOT

The university has developed an AHRS and INS, which have been through basic testing, and an Autopilot based on an Overo Fire Gumstix microprocessor as shown in Figure 11 has been developed. Another project “The Development of Micro Avionic Systems for UAV’s” by Patrick Cowling (15) has focused on interfacing these systems together to get a T-Rex 450 flying autonomously indoors. The level of control and data processing needed for rotary aircraft is a magnitude larger than that of fixed wing aircraft. Other work in the department by Tom Fletcher and Matthew Coombes has worked on getting reliable GPS data streaming to I2C, and this area is still in development.

FIGURE 11 - OVERO FIRE GUMSTIX MICROPROCESSOR

Quite early in the project it was felt that the University was not yet in the position to develop its own autopilot for outdoor flights. The universities avionics and hardware had not been fully tested and there was a lot of work needed in getting all the systems working reliably.

However the university owns Micropilot MP2028g a fully functioning autopilot system which would form a good basis to start outdoor operations. It is known to work and Micropilot has customers all over the world. It was felt that to build up a good background and safe operations history, operating with tested hardware was much more desirable. Using Micropilot would also allow the University to learn from their methods and techniques and implement some within the design of the Universities own Autopilot.


http://en.wikipedia.org/wiki/Rudder

http://en.wikipedia.org/wiki/Elevator_(aircraft)

http://en.wikipedia.org/wiki/Attitude_indicator

http://en.wikipedia.org/wiki/Heading_indicator

http://en.wikipedia.org/wiki/Gyroscope

http://en.wikipedia.org/wiki/Sperry_Corporation


3.1.2 MICROPILOT AUTOPILOT

Micropilot is a Canadian company specializing in the design of fully autonomous autopilot systems for UAV’s. Loughborough University has Micropilot’s MP2028g Autopilot system and has not been fully tested.

The autopilot includes:

Microprocessor Board Servo Mux RF Modem GPS Antenna Horizon Ground Station Software

Microprocessor Board

This acts as the central nervous system for the autopilot and has the job of coordinating with hardware, and processing the vast amounts of data that is streaming into it from the sensors to provide accurate control actions to each of the servos. The board also includes memory in which flight data and installation settings are recorded. See Figure 5 for a picture of the main board

Figure 5 – Micropilot MP2028g Main Processor Board

The microprocessor board has the following other noticeable components:

Gyros & Accelerometers – Used to provide roll, pitch and yaw data, and their respective angular rates and accelerations

Total & Static Pressure sensors – Used to calculate altitude and airspeed data Analogue to digital converters – Used to convert analogue signals into a digital format for processing



GPS Module – Processes satellite data taken from the antenna

The microprocessor performs nearly all of the computations that are needed for fully autonomous flight including the landing. It houses many very generic systems that are used to compute data, perform control actions and to ensure stability such as:

Attitude Heading Reference System (AHRS)– with the use of gyro’s, accelerometers and flight data, this monitors the aircraft roll, pitch and yaw data in a global sense

Inertial Navigation System (INS) – Uses same data as AHRS in conjunction with GPS to determine the aircrafts position globally

Stability Augmentation System (SAS) – Used to ensure the aircraft remains in stable modes during all flight conditions

Flight mode algorithms – Used to provide control actions to servos

Servo Mux

This provides a central location for the connection of actuators/servos to the microprocessor. It also provides power and ground lines for them to operate. It is helpful for keeping cables neat, although if the autopilot fails, manual recovery by remote control is not possible. This would become an immediate problem and could cause damage to an aircraft. An alternative may be needed.

RF (Radio Frequency) Modem

This is the device which allows the aircraft to communicate with the ground station. It feeds information back to a ground receiver and has about a 5km range. Using a piece of software called Horizon, it’s possible to communicate with the autopilot and control the aircraft from the ground using a visual map interface

GPS Antenna

This is used to receive signals from the satellites to enable the GPS module to decipher the aircrafts position. Its placement on the aircraft is important, so that it gets a good reception and is not affected by interference. Often it’s best to place it on top of the aircraft when in its cruise position. A metal plate is a good way to increase the antennas effectiveness

AGL

Micropilot doesn’t come with an AGL but you can purchase one from their website. This requires interfacing by Pulse width modulation (PWM). This is when the pulse is held high for a precise time which corresponds with the magnitude of the data being sent. Micropilot uses a system of 1.8ms per foot, so if the pulse is held high for 18ms, the height is 10feet. This means that when measuring data at 5m, the AGL is limited to a 25Hz update rate. Micropilot only requires data to be input to Micropilot at 5-6 Hz, which is sufficient for its application, but could cause limitations in the future.

Horizon Ground Station Software

Allows communication between the vehicle and ground station during flight, and gives a visual representation of the aircrafts flight data on screen. Waypoints can be set up for the aircraft to follow and control gains can be adjusted while in flight.

Micropilot is discussed further in Chapter 5



3.2 AGL SENSORS

In order to provide accurate height information to the aircraft, often an AGL sensor is used. This AGL is required to satisfy the following set of criteria:

Small Size – To be used on small fixed wing aircraft so needs to be able to be located easily on the underside of the aircraft

Low mass – The Pioneer operates at around 3kg Maximum Take-Off Mass (MTOM) so the payload needs to be kept to a minimum so as to increase the operational payload of the aircraft

Low Power Consumption – Due to the power limitation of UAV’s, it is desirable to reduce the power consumption of all hardware on board to extend the aircrafts endurance.

Accurate and repeatable data up to at least 3m on various surfaces– The pioneer flares at around 2-3m from the ground, and accurate height data is needed from this point in order to trigger the flare command. This data must be obtainable on both grass and concrete runways.

Compatibility with Autopilots – Easy integration with Micropilot and the Universities Autopilot is desirable to help eliminate future integration problems. I2C is the most preferred data string, although PWM is needed for interfacing to Micropilot

Other methods of obtaining height data are possible, but introduce flaws which are explored below.

Work by Simon Howroyd has proven that Pressure data can be calibrated accurately to provide height to the aircraft to within 0.1m. This requires the sensors to be calibrated very accurately prior to takeoff at the site in which the aircraft is operating. If the aircraft wishes to land at an alternative site, the QFE (Atmospheric Pressure) of the landing point is needed in order for the aircrafts height to be known accurately. On a climatically active day, air pressure at a site can vary dramatically, meaning the sensors would require calibration prior to landing even if landing at the same site it took off from. This requires external systems other than them which are on the aircraft, in order to implement this technique, and methods or relaying this information back to the aircraft. This method introduces constraints to the aircrafts operational limitations and would require development of a ground station, pressure suite and GPS module. Work by Matthew Coombes and Patrick Cowling has made progress in this area and possible development of Pressure height may be possible in the near future if this ground station is developed. This method of data acquisition though was not explored for the purposes of this project, so as to extend the scope of the Universities operations.

Work by Jonathon Clarke (16), and Derek B. Kingston and Randal W. Beard (17) has proven that GPS data introduces large latency to data. It is also much less accurate and can only provide height data to an accuracy of 3-4m. Due to the accuracy of flight that is needed during an autonomous landing, the integrity of this data is not sufficient to undertake repeatable landings. Therefore this method was also not investigated

The traditional approach to landing UAV’s is to use an AGL sensor to provide this height data more accurately. This method was used as there has been quite a lot of research in this area and it would provide much more reliable data. Several types of AGL were looked at.



3.2.1 ULTRASONIC ALTIMETERS

Ultrasonic Altimeters are a commonly used sensor which emits a pulse of Ultrasonic sound and records the time it takes to hear the echo. This time is proportional to the distance between the sensor and the surface it is measuring.

Wind noise generally operates in the ultrasonic region and this can cause major problems for these kinds of sensors. Micropilot uses a weather resistant sensor (18), the SensComp 600 electrostatic transducer. This sensor overcomes the wind noise problem by sending a very high power pulse and then uses complex filters to reduce the noise. The drawback to this is the unit’s power consumption which is very high drawing around 10 Watts of Power whilst the AGL is emitting.

TABLE 1- SENSCOMP 600 SPECIFICATION (19)

Data Frequency 5-6HzRange & (Accuracy) 0.15-10.7m (+/- 3mm)Compatibility PWM, TTLPower Consumption 10WSize Sensor Diameter - 50mm, Board – 70mm x 50mmMass 8.2g

This AGL has the benefit of being able to interface directly with Micropilot. Micropilot installation requires AGL gains to be tuned in order to reduce the noise from Wind and Engine. This means that interfacing this AGL with other autopilots would require considerable effort.

Other ultrasonic altimeters that are available for purchase do not have the noise compensation hardware or algorithms in order to overcome the problems with wind and engine noise. Therefore this variant is one of very few which does this for you.

In order to be able to keep the project relevant for the department it was felt that the high power consumption and poor compatibility of the Senscomp 600 sensor made it undesirable. The fact the sensor needed noise and temperature compensation also meant that hardware development would be quite difficult. It would only be suitable to fly Micropilot, and then further development would be needed in order to interface the board with our own hardware.

Other ultrasonic altimeters would need development, and the power output would likely be just as high in order to overcome the high power noise. Graham Holland’s work on Airship Flight Control (20) used basic Ultrasonic altimeters in order to control the airships height in an indoor environment. Some preliminary tests were conducted with a MaxSonar EZ4 Ultrasonic Altimeter (21) and it was found that the sensors would also need temperature compensation in order to provide accurate information. With the added complexity of wind noise, it was felt that this was a poor solution to the problem.

BAE systems use laser range finders for most of its larger UAV’s. This was the next type of AGL that was looked into.



3.2.2 LASER RANGE FINDERS

These are similar in operation to ultrasonic altimeters, but instead fire a high power laser and wait for the reflection of light back to the sensor to record the height. They do not suffer from the same noise problems as ultrasonic altimeters as they use light. Many successful UAV’s such as the Watchkeeper by Thales uses this kind of AGL, but much larger than the kind the University would require.

Several Lasers were looked at including but not limited to the following:

AGL-N by Latitude Engineering –

This Laser range finder is one of the current best on the market and is fairly small. It does however require connection via serial which makes interfacing the module fairly difficult. It’s also quite heavy and uses a fair amount of power. A specification can be seen below:

TABLE 2 - AGL-N SENSOR BY LATTITUDE ENGINEERING

Data Frequency 10HzRange & (Accuracy) Up to 50m (Highly Accurate)Compatibility CAN, RS232Power Consumption <1WSize 4.82 x 5.03 x 5.64cmMass 70g

FIGURE 12 - AGL-N BY LATTITUDE ENGINEERING

This sensor is very good and would be perfect for the Universities operations. However interfacing it to Micropilot becomes a major problem and another piece of hardware would be needed to make this possible. It is however a good solution for the requirements. This unit is very expensive so would need to be able to provide multiple uses for it to be purchased and used for future operations



HOKUYO URG-04LX-UG01 Scanning Laser Range Finder for Robotics

This sensor provides a 270˚ scan so as to provide a detailed map of the area beneath the aircraft. This sensor provides far too much information than is needed, and interfacing the sensor is difficult for this reason. It has a large mass and is also quite bulky, so was not thought of as appropriate for this project.

3.2.3 INFRA-RED SENSORS

Infra-Red (IR) sensors work on a similar method by sending out a pulse of Infra-red light and waiting for the echo. They use a lot less power than Lasers and are much smaller in terms of size and mass. The best IR sensors that were found are manufactured by Sharp. These sensors have a lower operating limit (i.e. 1-5m) so multiple sensors would be needed to provide a full data set.

TABLE 3 - SHARP IR SENSORS TECHNICAL DETAILS

Data Frequency Analogue (Infinite)Range 0.1-0.8m, 0.2-1.5m, 1.0-5.5mCompatibility AnaloguePower Consumption 0.165W per sensorSize (10mm x 10mm x 30mm), (15mm x 20mm x 40mm), (20mm x 40mm x 50mm)Mass <5g per sensor

In order to interface this module with an Autopilot, a breakout board is needed. This board requires the following operations:

1. Analogue to Digital converter (ADC) – to convert voltages into a digital format2. Filters- To reduce the noise on the sensors3. Logic Algorithms – To determine which sensors are providing accurate information4. Signal Conversion – To output data in PWM and I2C formats

Other types of sensors would require a board to be made to interface with the relevant autopilots, so hardware development was unavoidable. However using these analogue sensors with a personally developed board gives the best performance in terms of the original AGL specification. It also means that the sensors can be designed to achieve the exact specification that is needed for the Universities operations.

Another benefit from using multiple IR sensors is that the suite could be further developed to provide data relating the slope of the ground, to the aircrafts attitude. This is especially helpful to ensure that at the vehicle touches down accurately, which allows future scope for landing on slopes. This is more applicable for rotary aircraft, but also help fixed wing aircraft to conduct a three-point landing (i.e. on all three wheels).

The laboratory has historically used PIC4520 microprocessors which should provide enough processing power to conduct the operations mentioned above. The next chapter looks into the development of the AGL sensors which are to be used to measure height data for autonomous landings.



4 HARDWARE DEVELOPMENT

4.1 SENSOR VERIFICATION AND MODELLING

The 1.0-5.5m and 0.2-1.5m range Sharp IR sensors were purchased and an experiment was set up so that mathematical models could be developed of the analogue outputs as shown in Figure 13.

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5

3

3.5

A Graph To Show How Output Voltage Of 2 Analogue IR Sensors Varies With Distance

Long Range SensorShort Range Sensor

Distance (cm)

Volta

ge (V

)

FIGURE 13 - MATHEMATICAL MODELLING OF SHARP IR SENSORS

Equations expressing distance in terms of Voltage were then optimised in order to save on computational burden for the microprocessor and the results are as follows:

Short Range (0.1-0.8m):

hS=243.34

V S1.026

EQUATION 1

Long Range (1.0-5.5m):



hL=3097.3

V L1.171

EQUATION 2

It was thought that although the short range sensor was only rated up to 0.8m, it provided enough data sets to be able to overlap with the Long range sensor. This would need further investigation.

4.2 AGL REVISION 1

In order to interface these sensors with an autopilot, some hardware needed development. Earlier work in this project used an existing board, as in Figure 14, that had been developed for other projects. This was programmed with code I generated found, which in the Appendix of my Project Preparation report (21).

The board uses just one Peripheral Interface Controller (PIC), which handles all of the tasks mentioned earlier such as:

Analogue to Digital conversion Filtering Logic Operations Printing data to serial

Analogue to digital conversion was done automatically by the PIC via its input pins.

Time-weighted averaging filters were introduced in the form:

Output=(Output ×k )+( InputData× ( k−1 ))

The value of k is generally in the region of 0.9-0.99 and means that the input data only has a small effect on the output. As time tends to infinity, the output value tends to the input value.

Basic logic operations were coded in order to decide which sensors were reading correctly at each point and found in the Appendix of (21)



FIGURE 14 - AGL BOARD 1ST REVISION

This chip has a Bluetooth wireless connection, and serial can be streamed directly from this chip into Matlab via a wireless receiver using a piece of code that was written with help from Owen McAree.

A step test was conducted by placing sensors on a moveable platform and moving them in fixed 0.65m steps away from the wall. Both filtered and unfiltered data was recorded in Matlab and results are shown in Figure15 & Figure 16.

FIGURE 15 – REVISION 1 UNFILTERED SENSOR DATA



FIGURE 16 – REVISION 1 FILTERED SENSOR DATA

Raw data was found to be extremely noisy, which required large filter gains to reduce noise to an acceptable level. The speed at which the filters were processing data was constrained by the speed at which data could be output to Matlab. This constraint reduced the speed of each processor cycle to drop down to about 50Hz meaning the filters were only working at this speed.

An outdoor flight test was conducted by fixing the AGL to a Pioneer and conducting a manual Remote controlled landing. Data was streamed back to a Laptop and plotted in Matlab as shown in Figure 17.


3850 3900 3950 4000 40500

1

2

3

4

5

6

7

Time (s)

Heig

ht (m

)


At the end of the test, after data was collected the aircrafts speed controller failed causing the rear elevator to deflect downwards at its maximum travel. This caused the aircraft to nose dive into the ground, leading to the

demise of the airframe and sensors. This meant that new sensors had to be purchased.

Due to the high value of filter gains, and the relatively slow cycle speed of the processor a large latency was introduced which can be seen in Figure 17. The time between the aircraft being at 5m height to touchdown took around 10 seconds to fly, yet it can be seen that it takes over 100 seconds for the value to settle back down to ground level. This is purely a filtering speed issue, and by increasing the cycle speeds of the processor, greater filtering gains can be achieved whilst reducing latency.

Therefore it was decided that a further hardware revision was needed in order to improve this issue to an acceptable level.

By conducting hardware tests it was found that about 97% of the processors cycle time was being taken up by streaming data via Serial. A similar problem would be realised when converting to a PWM signal as this will constrain the cycle time to about 25Hz due to reasons mentioned earlier.

The best way of reducing this processing requirement, was to output data via I2C. This form of data communication is extremely fast, and would allow the processor to concentrate on filtering sensor data and applying the logic. This did however mean that another microprocessor was needed in order to convert this I2C into a PWM signal.

4.3 AGL REVISION 2

4.3.1 HARDWARE DESIGN

A board was designed by Jonathon Clarke, and constructed by myself in order to overcome the filtering issue. The board was designed with two PIC4520’s and a level shift to allow data transfer via an I2C port. It was also designed to have the PWM output, to allow direct integration with Micropilot. One microprocessor (Slave) reads in sensor data, converts it to a digital signal, filters it, applies the logic and then feeds it via I2C to the second microprocessor (Master). This master processor then converts the signal to the relevant data type and outputs either via Bluetooth, the PWM connection or I2C. This means that the AGL will be compatible with all current hardware, including Micropilot, and the Slave processor is freed up so as to process sensor data at a much faster rate. The board can be seen in Figure 18


FIGURE 17 - DYNAMIC FLIGHT TEST AGL REVISION 1


FIGURE 18 - AGL BOARD REVISION 2

The board runs off a 5V supply and has up to 8 programmable sensor inputs which will keep the scope open for future projects.

In order to optimise the AGL and to debug any coding problems that may have existed in the original code, a Simulink model was developed. The idea of this model was to simulate the properties of the sensors and then build a logic control algorithm to optimise accuracy and repeatability of the height reading. This output could then be verified against the reference input height. This will allow:

Optimisation of filter gains Optimisation of Logic algorithms Debugging of sensor crossover problems (Between 0.8-1.0m) Optimisation of processor speed by reducing computational burden through simplification of

algorithms Calibration of voltage to height conversion Investigation of the effect of noise power

To compound problems, Sharp discontinued its long range sensor. Due to the crash in previous flight tests this sensor had to be replaced by a new sensor which had a different output. This was modelled in Simulink and the equation is shown below:

hL2=1000

V L2−250+1.2

EQUATION 3

4.3.2 SIMULINK MODEL

First each sensor was mathematically modelled to match the curves as shown in Figure 13. This was done by taking Equation 1 & Equation 2 and converting them to Simulink blocks. To replicate the lower end of the range where the voltage drops off, further block were needed, and this was all calculated mathematically. To ensure the models were accurate, Matlab was used to tune the numbers until the graphs matched as closely as possible to experimental results for the short range sensor. As the datasheets matched the experimental data quite accurately, this information was used to model the Long Range sensor. The models of each of the Long and Short range sensors can be seen below.



4.3.2.1 SENSOR MODEL

Short Range Sensor

FIGURE 19- SHORT RANGE SENSOR MODEL

Below is the output from both experimental and model data.

FIGURE 20 - VERIFICATION OF SHORT RANGE SENSOR MODEL

It can be seen that the model accurately represents the sensor behaviour and more importantly accurately models the short range end of the curve. This is very important to replicate as it will determine the constraints that are needed in the code in order for the logic to work effectively

Long Range Sensor



FIGURE 21 - LONG RANGE SENSOR MODEL

Below is verification to show that the long range sensor model is accurate

FIGURE 22 - VERIFICATION OF LONG RANGE SENSOR MODEL

This sensor was much harder to replicate due to the quite shallow curve towards the sensors lower range. The model however was accurate enough to show the effect of the drop off point and would allow investigation of the algorithms.

4.3.2.2 NOISE

In order to replicate the noise power on the sensors raw data was analysed from each of the sensors by placing the sensors on a T-Rex 450 Helicopter. The aircraft was then flown up to around 6 m and then back to the ground on a grass surface. Raw data from the short range sensor is shown in Figure 23



FIGURE 23 - NOISE POWER INVESTIGATION

The noise power seemed quite extreme, sometimes up to 1.5m at various points. However when analysing the data, the sensor behaviour could be seen clearly despite the noise. This was promising as it proves that the sensors operate on other types of surface other than flat ground. Grass disperses light considerably, so they should have no problems on other surfaces such as concrete and soil.

This noise power needed to be replicated on the Simulink Model. This was done by adding a white noise block onto the output of each of the sensors. A value of the noise power was chosen within the block to try and replicate the amount of noise that the sensors were experiencing. Data was only recorded at 5Hz so the frequency of the noise on this data is lower than that experienced by the sensors. Therefore the frequency of the noise was set at 2 kHz which was an estimate of the processor cycle time of the slave microprocessor which is processing the data. The block layout was pretty simple and shown below:

FIGURE 24 - WHITE NOISE BLOCK

The model was ran again in Simulink and the noise adjusted long range sensor output is shown in Figure 25



FIGURE 25 - LONG RANGE SENSOR MODEL WITH WHITE NOISE ADDED

More noise was added than was realistically expected on the sensors to ensure that the data quality is optimised in the design. The next stage was to optimise the time weighted averaging filters

4.3.2.3 FILTERING

In order to replicate the filters in the algorithms, filters were introduced to try to replicate the voltage signal prior to adding the noise. The time weighted averaging filters as described earlier were applied to each sensor and whilst comparing the output and reference signals, the filter gains were tuned to ensure that the filters were working optimally. The code for each of the filters can be found in Appendix 7. It was found that to optimise the filters, larger gains were needed towards the upper end of the ranges. This meant that the gains needed to increase as the voltage reduced. This filter was applied to the model by using an embedded Matlab function.

After optimisation the short range sensor gain was tuned to 0.989, but this increased to 0.993 when the voltage of the sensor falls below 0.8V (0.35m). The long range sensor was also tuned and resulted in a gain of 0.98, which switches to 0.993 when the voltage drops to below 1.8V (1.9m) and then increases further to 0.998 when the voltage drops below 1.5V (3.6m).

Time Period

Both of these were tuned with the height increasing from 0-5.0m over a 5 second period. This was considered the minimum time an aircraft conducting a traditional style of landing would take to descend from 5m. Therefore if the gains were suitable for this period, they would improve as the time taken increases.



Matlab was set up to run at 2000 Hz which mimicked the estimated speed of the microprocessor allowing for accurate gains to be achieved.

Simulation Results

FIGURE 26 - FILTER TUNING FOR SHORT RANGE SENSOR

It can be seen that the data fits quite well and the error hits a maximum of 50mm at 300mm height which is acceptable. This is caused by the latency introduced by the filtering, which equates to around a 0.1 second delay. This should not cause any problem for the control system as the height change has been applied linearly rather than exponentially like a traditional landing. This means that the time taken to cover the final metre before touchdown will be greater than the time to drop from 5-4m. This allows the filters to catch up with the dynamic behaviour of the aircraft.

FIGURE 27 - FILTER TUNING FOR LONG RANGE SENSOR



The long range sensor behaviour was better than that of the short range sensor as the long range sensors voltage change is lower. The short range sensor peaks very quickly compared with the long range, so therefore introduces more latency. The lower range of long range sensor does not follow the reference as well as the short range sensor, but this part of the curve doesn’t provide accurate information so is not important.

This voltage is then converted to a height by using Equation 1 & Equation 3. The expressions were adjusted so that the outputs matched the input reference height in the simulation as best as possible during the sensors operating limits.

4.3.2.4 SENSOR SWITCHING LOGIC

Each of the previous blocks link together and algorithms used to control the switching are required. This is done in an embedded Matlab function. The block diagram is shown below in

FIGURE 28 - FULL AGL SENSOR MODEL

The embedded Matlab function controlling sensor selection has the following logic applied:

Short range sensor has priority unless any of the following rules apply IF short range sensor reads greater than 0.8m and less than 1.2m output a mixture of Short and Long

Range sensors, on a sliding gain system. i.e. KS = 1-((hS-0.8)/0.4) and KL = (hL-0.8)/0.4 IF short range sensor reads greater than 1.2m, output Long Range sensor reading

Once the logic is applied, the rate of the signal is reduced to a more realistic output speed of 10 Hz. A sine wave was introduced to the height input and the results from the model given in Figure 29



4.3.2.5 SIMULATION RESULTS

FIGURE 29 - MODEL RESULTS USING 2 SENSORS

It was found in the simulation that during the transition between the short and long range sensors, there was some noise introduced. This could cause problems with the real sensors so another sensor may be required in order to eliminate this problem.

4.3.3 HARDWARE PROGRAMMING

This simulation code needed converting into code for the hardware which involved using CCS Compiler. The language the software uses is C and the logic was translated into this format. Both sets of code were written to the Master and Slave PIC’s. The master code was purely listening to data from the slave PIC and then converting the signal to serial to enable output via Bluetooth. A copy of the final AGL code is included in Appendix 8 and shows both the header files needed to set up the microprocessors and the simulation code that was translated into C. Once the code was programmed, the sensors were pointed towards a wall while moving towards them at a fairly constant rate, similar to that what would be experienced during a landing. Results of this experiment are given in



FIGURE 30 - EXPERIMENTAL AGL DATA USING 2 SENSORS

The data was of a good quality but there was a definite problem with the switching point between the two sensors. As the height reduces the switching point introduces a rise in measured height. If this were to happen in a flight the aircraft control systems would pitch the aircraft down possibly causing a crash. The rest of the data looks acceptable but this inaccuracy so close to the ground is of a major concern. It was therefore decided that a third sensor with range 0.2-1.5m (Medium Range) would be introduced to provide accurate data at the switching point. This meant a third revision was needed in order to ensure accurate and repeatable readings.

4.4 AGL REVISION 3

4.4.1 SIMULINK MODEL

In order to verify the decision to add a third sensor, the medium range sensor was also mapped into Simulink. Everything was replicated with this sensor and the switching logic algorithm was revised to reflect this. The new switching logic code is included in Appendix 9. The logic was very similar to that with two sensors and followed the following rules:

1. Short range sensor is always dominant up to 350mm2. When the short range sensor reads between 350mm and 800mm a sliding gain scale is used between

the short and medium range sensor3. When the short range sensor reads over 800mm and the medium range sensor reads below 1m the

medium range sensor is dominant4. When the short range sensor reads above 800mm and the medium range reads between 1m and

1.4m, a sliding gain scale is used between the medium and long range sensors5. When the short range sensor reads above 800mm and the medium range sensor reads above 1.4m,

the long range is dominant



The code is written in a way that works through the logic in sequence so that the short range sensor is always dominant. This means that if the short range sensor is reading within its accurate range, it is selected regardless of what the medium and long range sensors are reading. This is because the short range sensor is most reliable. The voltage drop off towards the shorter ranges on the long range sensor means that the long range sensor can think it’s at a greater height than it really is. Unless the short range sensor is taken within 10cm of the ground, it will never repeat results, so therefore is the most reliable.

When the short range sensor reads above the medium range sensors inaccurate range, the medium range sensor then becomes dominant. It is known that the height must be at least the same height if not greater than that of the short range sensor, so therefore the medium range sensor takes on the dominant responsibility.

Simulation results are shown in Figure 31

FIGURE 31 - OPTIMISED SIMULATION RESULTS WITH 3 SENSORS

It can be seen that adding the third sensor definitely reduces the noise at the crossover point. The filter gains were increased to help smooth out the response of the sensors at the larger distances. This introduced latency, but is not as much of a problem as the filters catch up with the dynamics by the time the aircraft hits the critical 3m point where it needs to flare. It was now time to test the algorithms on the hardware

4.4.2 HARDWARE TESTING

All algorithms were coded in C onto the slave microprocessor and a simulation landing was conducted by moving the sensors towards a wall in a sinusoidal fashion. The full copy of the code is included in Appendix 8. Results of this are shown in Figure 32.



FIGURE 32 - EXPERIMENTAL AGL DATA 3 SENSORS

By adding the third sensor the crossover noise was removed allowing a much smoother data set. This will really help the aircrafts control system when performing an autonomous landing. More testing was carried out and the sensors seemed to be working nicely giving smooth data right down to about 10-15cm.

Due to the lower limit of the AGL, the unit must be housed fairly high away from the ground to ensure that the lower end of the sensor performance is not reached.

4.5 INTERFACING WITH MICROPILOT

Micropilot requires a PWM input from the AGL in order to operate. An email was sent to Micropilot who gave the following information:

The high time is proportional to height – 1.8ms per foot The cycle time can be set to anything between 5 and 6 Hz The enable line is used to switch off the AGL when it’s not needed The autopilot switched to AGL height when the AGL reads below 5m

Therefore some code was written to create the pulse width needed. The PWM output pin of the PIC was pulled high and then a delay was introduced as a function of measured height (1.8ms per foot). The pin was then immediately pulled low and another delay introduced equal to 0.2 seconds minus the delay time that the pin was held high for. This ensured that the cycle time of the signal was a constant 5 Hz. Once this was coded the unit would be hot pluggable into Micropilot, meaning no further work was needed on the AGL.



4.6 INSTALLATION ISSUES

4.6.1 SENSOR INTERFERENCE

When installing the sensors it was apparent that if the sensors were all pointing towards the same spot, extra noise would be introduced to the sensors and the height reading would become almost unreadable. To overcome this problem the sensors needed to be installed at different angles in order to separate the IR light beams. As the light beams were relatively narrow, this angle only has to be a few degrees so as to avoid interference.

4.6.1 DIVERGENT DYNAMIC BEHAVIOUR DUE TO ROTATION OF AIRCRAFT

When deciding upon the best angles to mount the sensors other possible mounting problems were discovered when using an AGL which is transmitting a beam of light. As the aircraft pitches or rolls, the AGL’s height reading will fluctuate. Luckily as these angles are generally quite small (typically less than 15 degrees) the reduction in height will be relatively small.

cos (15 )=0.9659 Or 96.6%

This means that noise is likely to cause more disturbance than the pitching and rolling of the aircraft.

However, as the aircraft flies down the approach, the aircraft is going to be pitching downwards at around 10 degrees. This means that the sensor will be looking backwards. If the aircraft requires further pitching down in order to lose height, this pitching motion will cause the sensor angle to increase. This increase in pitching angle means that the height the AGL is sending the autopilot will increase further inhibiting a divergent behaviour. This problem is only caused by the fact that the sensor is pointing rearwards down the approach due to the aircraft pitch.

This is still unlikely to cause a massive problem if the landing algorithms are accurate because the height lost due to pitching of the aircraft is much less than the rate at which the aircraft is descending. There will be an upper operational limit that the sensor can cope with in terms of pitching angle. This point will be when the pitching of the aircraft causes the sensor height to increase quicker than height is reducing due to dynamics of the aircraft pitching. If the aircraft has high control authority, then the behaviour may become divergent, but the Pioneer is quite slow to respond, so it’s unlikely to have much effect.

Assuming the aircraft pitches by 1 degrees nose down every 0.1 seconds with a forward speed of 15m/s and height of 5m. The reduction in height due to the sensor angle in relation to the reduction in height due to the aircraft pitching dynamics is given in Table 4.



TABLE 4 - ESTIMATION OF DIVERGENT BEHAVIOUR

Starting Pitch (Nose Down)

Sensor Height Gained

Dynamic Height Lost

10 0.014402938 0.02582056911 0.015902848 0.02574122712 0.017397914 0.02565404313 0.01888768 0.02555904514 0.020371693 0.02545626215 0.0218495 0.02534572416 0.023320652 0.02522746617 0.0247847 0.02510152318 0.026241198 0.02496793419 0.027689703 0.0248267420 0.029129774 0.024677983

This estimation predicts divergent behaviour at around 18 degrees nose down assuming the sensors are mounted directly downwards. Even though this behaviour become divergent here, the height gained in this process is still less than the noise level on the signal, meaning that unless there is drastic oscillatory behaviour on landing this divergent behaviour will be negligible. If the aircraft pitches in the other direction the sensor reading will increase causing the aircraft to pitch downwards, so behaviour in the other direction will never become divergent because of this phenomenon.

A way of ensuring this condition is not reached is by mounting the sensors at angles relative to the estimated pitch of the aircraft at that height. During the descent the aircraft is seen to pitch down at around 10 degrees, so pointing the long range sensor forwards by 10 degrees means that down the approach the sensor is looking directly downwards. As the aircraft flares the medium range sensor comes into effect. At this point the aircraft will have levelled out, so it was decided that pointing the medium range sensor directly downwards would be optimal. The short range sensor would then be reading during the final stage of the flare, where the aircraft is pitched upwards by around 5 degrees. Therefore this sensor would face backwards by 5 degrees.

This means that at all phases of the landing, the appropriate sensor will be looking directly downwards. This means that any deviance in roll and pitch caused by gusts or cross-wind landings will have little effect on height data purely because of the small angle approximations for cos. The final design layout of the sensors looks like that in Figure 33.

FIGURE 33 - SENSOR MOUNTING INSTRUCTIONS



5 MICROPILOT

5.1 HARDWARE INSTALLATION

Having completed the hardware, work began on installing Micropilot within the Pioneer. This required some careful planning in terms of:

Which batteries to use Which speed controller to use GPS mounting position Dynamic Pressure Tapping installation Centre Of Gravity positioning

The autopilot was installed as per the instruction manual (22) and each piece of hardware was secured tightly to the airframe. The GPS chip was mounted on the roof of the vehicle and attached to a grounding sheet of metal to help the GPS pick up signal as shown in Figure 34.

FIGURE 34 - MOUNTING OF GPS

Three batteries were used:

A 2 cell to power Micropilot and the modem. This gave about a 45 minute operational constraint on power

A 3 Cell was required to power servos. This had about a 30 minute operational limit A 4 Cell was required to power the electric engine. This had about a 15 minute operational limit.

The Dynamic pressure tapping was a difficult problem as a metal tube needed installing in clean airflow. Regulation also stipulates that anything protruding a UAV must have a diameter greater than 10mm. The solution to this problem was to drill a hole in the leading edge of the wing tips and glue a brass tube into the hole. As the tube was only 4mm in diameter, a ball was drilled and then glued onto the end of the tube in order to comply with regulation.



5.2 SOFTWARE INSTALLATION & SETUP

Micropilot comes with Horizon ground control software. This program gives a visual representation of the flight profile and allows .vrs and .fly files to be written to the autopilot. See Figure 35

.vrs files contain all the aircraft data which enable to Autopilot to be tuned to the particular airframe. There are many different options that can be seen in Figure 36. This file covers things such as the aircrafts:

Cruise Speed Descent Speed Flare Height Servo configurations

When the settings have been saved, the .vrs file is transmitted to the autopilot via the wireless connection.

.fly files contain the flight profile information, which provides the high level control to the autopilot. It encompasses many functions such as climb, cruise, descend etc. These again are transmitted via the wireless connection

Once the autopilot was configured, post installation checks were conducted as per the Micropilot instruction manual.

FIGURE 35 - HORIZON HOME SCREEN



FIGURE 36 - EDITTING .VRS FILES IN HORIZON

5.3 POST INSTALLATION CHECKS

Once everything was set up correctly, post installation checks were carried out. This involved pulling up a sensor report by communicating to the autopilot via HyperTerminal. The aircraft was tilted and sensors were checked to ensure that they were reading accurate values. Micropilot control was also checked to make sure control movements opposed the motion of the aircraft in order to bring the aircraft straight and level. All these checks were completed and I was happy that everything was functioning as expected. A picture of the finalised aircraft with all electronics installed can be seen in Figure 37.

FIGURE 37 - FULLY INSTALLED MICROPILOT IN A PIONEER



5.4 ADMINISTRATION

In order to conduct a flight test, relations needed to be evolved with Derby Airfield. Due to weather constraints, flight testing was delayed by 2 weeks as the wind was too strong. At this point talks were still ongoing with derby airfield, and while waiting for the weather to improve, the operations manual, and other outdoor flight test forms were designed as described in Chapter 2. A full flight test day was eventually planned and a copy of the drafted Flight Test Programme and flight log is included in Appendix 9.

5.5 FLIGHT TEST 1

Once the weather improved and the regulatory framework was all in place, a flight test day was conducted. This involved Jonathon Clarke who was acting as Pilot, and Owen McAree who was acting as Flight Test Supervisor. The pilot was essentially responsible for the aircraft and ensuring safe operation of the aircraft. The flight test supervisor was in charge of RT and ensuring everything remained safe and procedures as in the operations manual are followed. Further responsibilities of each of the roles can be found in the operations manual as found in Appendix 3.

Upon Arrival at the airfield, a brief was given by the owner of the airfield. He instructed which runways were in operation that day, and which areas to avoid. He also instructed us on other safety issues and what to do in the event of an emergency. We agreed that we would not fly when anything was close to the airfield for our first flight test day in order to get used to the procedures at the airfield. The owner did say that as operations increase, more flexibility with operations can be achieved. Once the brief was complete, all equipment was driven over to where we were based for the day and unloaded.

The first test that was scheduled was sensor data collection through a flight. To do this Micropilot was armed and manual control was taken over the aircraft by Jonathon Clarke using the handset. The autopilot was initiated, and a manual flight was conducted. After the first flight it was obvious that the telemetry data had not started recording, so another flight was prepared in order to get a full data set.

There were many problems when try to conduct tests as there were many manned aircraft landing and departing Derby Airfield through the day. This meant that lots of preparation was needed in order to time the flight for when there was a quiet spot. Due to the installation of the AGL, the battery for the engine was inaccessible without taking off the AGL. However this could not be left plugged in as the battery life was quite poor for the motor. This meant that before each flight the following actions were needed:

1. Turn on Micropilot (10 seconds)2. Wait for sensors to initialise and GPS to lock (60 seconds)3. Turn aircraft upside down and connect motor battery (30 seconds)4. Secure AGL in place (30seconds)5. Pre-flight controls and range check (60 seconds)

All of these things were needed before any flight could be conducted which required over 3 minutes of preparation. If this procedure was started when the airfield was free, by the time the aircraft was ready to fly more traffic would be encountered, meaning all the batteries needed unplugging and the whole process starting again.



After a few failed attempts, the timing improved so that the aircraft was ready at the same time the airfield was available to operate. Unfortunately many of the above pre flight procedures are unavoidable, although an improved method of connecting the motor battery was needed. At the moment the battery is fixed to the underside of the aircraft where the AGL is located as seen in Figure 38, but having the battery accessible from the top would mean that the AGL would not need removing in order to plug in the battery. It also means that the AGL could be taken higher from the floor if there is any problem with the lower range limit of the sensors being reached.

FIGURE 38 - AGL POSITION

5.6 FLIGHT TEST 2

Another flight test was conducted, this time ensuring that the telemetry data was being logged properly. A square circuit was conducted and the aircraft was landed. Telemetry data was downloaded from the autopilot and saved.

From this flight test, a full data set was achieved. More work was done loading .fly files to the autopilot, but time was running out and so had to abandon the day’s activities.

5.7 FLIGHT TEST RESULTS

5.7.1 FLIGHT SPEED

In order to assess the quality of data that the autopilot is using to control its flight, graphs were plotted. The first data that was assessed was speed as shown in Figure 39.

GPS data lagged that of the pressure sensor by about 2-3 seconds. This is expected as GPS as mentioned earlier is quite prone to latency. However both sensors read similar values suggesting that the installation of the dynamic pressure tapping was correct. There will always be a difference between GPS speed and Pressure speed, as one measures ground speed and the other measures airspeed. If it were a really windy day there



would be a much larger difference in these readings. The wind speed was only 4mph on the day of the flight test, so it was expected that the results would be similar.

It can also be seen that as launching into wind the GPS speed is lower than the Pressure speed due to the prevailing wind. As the aircraft turns to the downwind leg, GPS speed increases to beyond that of pressure speed. As the aircraft turns back round to land upwind, the GPS ground speed reduces again to below that of pressure speed. This clearly shows that when the aircraft flies into wind the ground speed reduces with respect to airspeed. When flying downwind, the ground speed is faster than the airspeed which backs up theoretical analysis.

00:00:19 00:00:39 00:00:59 00:01:20 00:01:40 00:02:00 00:02:200

5

10

15

20

25

Pressure Airspeed

GPS speed

Time (HH:MM:SS)

Vel

ocit

y (m

/s)

FIGURE 39 - GPS SPEED VS PRESSURE AIRSPEED

5.7.2 GPS DATA PLOT

GPS co-ordinates were given in the telemetry data. To convert these co-ordinates to distances the Haversine formula are used as in (23). These formulae calculate the distance and bearing between two GPS points. The origin was used as a reference, and then all points were calculated from this. As shown below:

d=2R arctan ( √sin2(∅ 2−∅ 1

2 )+cos∅ 1 cos∅ 2sin2( λ2−λ12 )

√1−sin2(∅ 2−∅ 1

2 )−cos∅ 1 cos∅ 2sin2( λ2−λ12 ) )

EQUATION 4



φ=arctan ( sin (λ2− λ1 )cos∅ 2

cos∅ 2sin∅ 1−cos∅ 1 sin∅2 cos ( λ2−λ1 ) )EQUATION 5

Once distance and bearing are calculated for each point, using simple trigonometry, X and Y distances can be calculated using:

Y=d× cosφ

X=d ×sinφ

Using Google maps, the origin of the data was found. The GPS plot was then overlaid onto the map and scaled so that it matched up with the maps scale. The original plot can be seen in Figure 40 and the Google map overlay is shown in Figure 41

-200 -150 -100 -50 0 50 100

-40

-20

0

20

40

60

80

100

Distance from Origin E-W (m)

Dist

ance

Fro

m O

rigin

N-S

(m)

FIGURE 40 - GPS PLOT OF MICROPILOT FLIGHT



FIGURE 41 - 2D GPS PLOT OVERLAYED ON MAP

The setup area, takeoff run and landing run can all be seen on the plot. This GPS data looks to be of a good quality and would enable sufficient data to enable waypoint navigation as expected. It is also seen that we were operating well within current regulatory frameworks, and within the confines of the airfields restrictions.



5.7.3 HEIGHT DATA

Height Data as streamed from Micropilot is plotted in Figure 42.

00:00:19 00:00:39 00:00:59 00:01:20 00:01:40 00:02:00 00:02:200

5

10

15

20

25

30

35

40

45

50

Time (HH:MM:SS)

Heig

ht (m

)

FIGURE 42 - HEIGHT DATA FROM MICROPILOT

It can be seen that there are some inaccuracies with this data. When the AGL reads above 5m, Micropilot switches to pressure height as measured by the pressure suite. Whilst the aircraft was on the ground, due to the short distance between the sensors and the ground, the sensor reached its minimal operating distance causing the AGL reading to read higher than 5m. This has caused the controller to switch to Pressure height, which was not calibrated properly prior to flight. It can be seen that the bias on the pressure height is around 7 m. Therefore this value was taken off all data that was recorded as pressure height and the graph was redrawn as shown in Figure 43.

This graph shows that if the pressure height can been calibrated correctly prior to flight the height data would be very good. This lower limit of the sensors means that they may need to be installed slightly higher than they are currently, in order to stop the height peaking whilst on the ground. Otherwise any inaccuracies in the pressure height will be introduced as the aircraft touches down. This is possible, by housing the sensors higher up in the underside of the aircraft. The battery is currently in the way but with some modification, some space could be freed up to allow for this.



00:00:19 00:00:39 00:00:59 00:01:20 00:01:40 00:02:00 00:02:200

5

10

15

20

25

30

35

40

Time (HH:MM:SS)

Heig

ht (m

)

FIGURE 43 - POST CALIBRATION HEIGHT

When zooming in to look at the descent as in Figure 44 it can be seen that the height data is of a good quality. Due to the sampling rate of the telemetry data, only 1 Hz of data was recorded, so therefore a full complete data set was not recorded. It does however show that the AGL sensor is working with Micropilot and the data quality is of a good standard.

16:36:20 16:36:24 16:36:28 16:36:33 16:36:370

5

10

15

20

25

30

35

Time (HH:MM:SS)

Heig

ht (m

)

FIGURE 44 - ANALYSIS OF HEIGHT DURING LANDING



5.7.4 3D GPS PLOT

With this calibrates height data, a 3D GPS plot was made and overlaid onto a 3D image of the airfield. Axis and scales were both matched to ensure that the plot was accurate and is shown in Figure 45 below. This figure gives a representation of the airfields size and the area needed to perform outdoor operations.

FIGURE 45 - 3D GPS PLOT

5.7.5 ATTITUDE DATA

Pitch and roll data was plotted for the flight and can be seen in Figure 46 and

From the pitch data is can be seen that the maximum pitch on takeoff of the aircraft is around 25 degrees nose up, and on landing reaches a maximum of 15 degrees nose down. This information confirms that the long range sensor needs pointing forwards by quite a large margin in order to help reduce the divergent behaviour. 10 degrees installation angle seems about right for the moment, although this may need increasing if the aircraft descends with a greater pitch.

The roll data shows that the sensors are reading correctly. The aircraft rolls negatively in all manoeuvres which imply that a left hand circuit was flown. When comparing GPS plots with roll data, each of the turns can be clearly seen to correspond to the increase in roll angle. This means that the attitude data is likely to be accurate and is reading as expected.



00:00:19 00:00:39 00:00:59 00:01:20 00:01:40 00:02:00 00:02:20

-30

-20

-10

0

10

20

30

Time (HH:MM:SS)

Pitc

h (d

eg)

FIGURE 46- PITCH DATA FROM MICROPILOT FLIGHT

00:00:19 00:00:39 00:00:59 00:01:20 00:01:40 00:02:00 00:02:20

-60

-50

-40

-30

-20

-10

0

10

20

Time (HH:MM:SS)

Roll

Angl

e (D

eg)

FIGURE 47 - ROLL DATA FROM MICROPILOT FLIGHT

5.7.6 FURTHER TESTING

Micropilot employs many of these PID loops within a nested structure. Depending upon the mode of flight which the aircraft is in, PID loops that control the aircraft are turned on or off. This is to ensure that the variable that’s being controlled for a particular flight condition is being controlled by the most effective control for that case.



Due to time constraints, no further tests could be performed but the aircraft is now ready for the inner loop PID gains to be tuned. To tune the inner loops Micropilot’s instructions should be followed in full. A specific .fly file has to be loaded into the autopilot which turn off the outer loops of the control and allow the inner control loop gains to be adjusted. Inner loops include:

Elevator to control Pitch Ailerons to control Roll Rudder to control y accelerations

All gains can be tuned mid-flight and once tuned should give smooth stable flight. The outer control loops can then be tuned:

Pitch to control Airspeed Roll to control Heading Pitch to control Altitude Throttle to control Altitude Throttle to control Airspeed Rudder to control Heading Heading to control Crosstrack Pitch to control Descent

Once all these outer loops are tuned, the aircraft will be ready to follow waypoints and conduct all operations of flight.

From experience, it is likely to take at least one flight to tune each gain, so plenty of flight test time is needed in order to complete the installation and setup. This will require many weeks of extensive flight testing.

The landing control algorithms are a little more complicated and require careful planning and consideration. As more confidence is achieved from the control system, the circuit height is reduced, until an autonomous landing is achieved. Little information is given into how the landing control is achieved, so this will need to be investigated by future students.



6 CONCLUSION

This project set out to make a big step towards opening up outdoor fixed-wing operations, and developing an understanding of the control algorithms used to fly them autonomously. Although the title of this project was to develop an autonomous landing system, it was found that there were lots of restrictions and constraints stopping the universities operations outdoors.

The scope of this project was always ambitious as the University has not developed its fixed wing capabilities to the same degree it has rotary aircraft and the risks involved with operating outdoors are much higher. Therefore a regulatory framework was needed in order to satisfy others that the university was operating professionally and safely. Extensive work was carried out developing the framework, internal regulations and procedures in order to fly safely outdoors. This involved writing an Operating Manual, Flight Test Programs, Flight Log Sheets and Manufacturing Sheets. Lots of work was also done in arranging an operating site. Derby airfield is the most suitable location to perform operations, so careful consideration was needed hen approaching them. By developing the regulatory framework and operations manual for Loughborough University gave Derby Airfield the confidence to let us operate there, which was a major breakthrough for the department. Future students will now use the same structure to plan their flight tests and ensure that all regulations are being followed which will save them lots of time and avoid accidents. It also ensures that the University operates within all CAA regulations and students are insured for their operations.

The project started by looking at AGL sensors. Many sensors are available on the market to purchase but most of them were unsuitable for the Universities applications for reasons of noise, compatibility, size, weight, power consumption and cost. Compatibility with hardware was a major issue and therefore the design required both an I2C and PWM output from the AGL in order to be compatible with both the universities Autopilot and Micropilot. This meant that hardware would need development regardless of which sensors were purchased. The Sharp IR sensors that were chosen offered a good solution to the problem, and gave accurate height data with minimal latency. It did however require much more time than was originally thought to develop the hardware which delayed the Installation and testing of Micropilot algorithms which was the projects main aim. It was thought that in order to conduct an autonomous landing, the height data needed to be accurate and repeatable at all times. Having any kind of noise on the data could cause a major accident when landing, which would cost the department dearly. Therefore no shortcuts were taken and it was thought that optimising the AGL sensor and finishing the algorithms would be great benefit for future students wishing to use the hardware and would mean next year’s students could use the hardware for their own applications.

Once the Hardware was developed and had been tested, work started on Installing and setting up Micropilot. In hindsight this could have been done in parallel with the sensor development, but the time taken to conduct the flight tests was heavily underestimated. This factor along with the degradation in weather and extra work caused by finding a suitable operating site and writing operational procedures meant that not enough time was left for tuning the flight control gains and conducting an autonomous landing. However a flight test day was organised properly using the procedures that were developed as part of this project and data acquisition was achieved on a manual flight. This allowed all sensor data to be evaluated properly to ensure the aircraft was functioning as expected and gives any future student the opportunity to really test the algorithms extensively in any future projects. The flight test day also allowed the procedures to be tested and redrafted in order for it to work effectively for future students.

If this project were to be repeated, some distinctive changes would have been made. The AGL-N sensor would have been a better solution for obtaining a height reading as it would have given data up to 50m and has been thoroughly tested and manufactured. Hardware development is a very lengthy process and without professional testing and manufacture the University can never be certain of its limitations and reliability. Also if



anyone wishing to use some old hardware experiences any problems with it, it is very difficult to debug the problems in the original code without the person who wrote the code there to explain what’s happening. This also introduces the problem of people relying on hardware for control, with problems compounding through the various systems.

Hardware should only be developed if a board cannot be purchased to do the same job. Converting serial into PWM or I2C is a relatively simple task, so if one could not be purchased, it would be an easy task making a board to do that. This board would be much easier to test and could even be professionally manufactured if multiples are needed. In the short term buying hardware does cost slightly more money, but when comparing the increase in costs with the increased development speed of the labs, it would actually improve efficiency of operations. If this route had been taken, much less algorithm development would have been required and that would have allowed for more time to be spent testing Micropilot’s algorithms and developing our own autopilot. It also would mean that the AGL could be used on anything without the worry of knowing if it works.

Overall this project did not fulfil exactly what it aimed to do, due to the underestimation of time needed to develop hardware. Operational constraints such as weather, regulation, insurance, and finding a suitable operating site also caused delays. Overall though the project has made some big steps into standardising the way the lab conducts outdoor testing, and developing useful hardware that has multiple operations. Micropilot has been manually flight tested

Continuation of Project

Now that the operating framework is in place, an AGL has been designed and Micropilot sensors tested, the following development work could be undertaken on the back of this project:

Testing of Micropilot and the development of the Universities fixed-wing autopilot control algorithms Further refinement of internal regulations and operational frameworks Developing AGL to be able to calculate roll and pitch data (For Rotary) Interfacing AGL with University Autopilot in order to control helicopters Development of Ground Station



BIBLIOGRAPHY

1. Pike, John. [Online] http://www.fas.org/irp/program/collect/uav.htm.

2. Royal Air Force Official Magazine. 2009 .

3. Zaloga, Stephen J. Unmanned Aerial Vehicles. s.l. : Osprey, 2008.

4. Autopilot Development for Outdoor Model Helecopters. D'Amore, Adam. 2010.

5. CAA. CAP393. Civil Aviation Authority. [Online] 2010. http://www.caa.co.uk/docs/33/CAP393.pdf.

6. —. CAP 722. Civil Aviation Authority. [Online] 2010. http://www.caa.co.uk/docs/33/CAP722.pdf.

7. EuroUSC. BNUC-S Certification Requirements. EuroUSC. [Online] 2010. http://www.eurousc.com/documents/LUASS_011_web.pdf.

8. Sensefly. Swinglet CAM. [Online] www.sensefly.com/products.

9. ANALYSIS OF DEEPSTALL LANDING FOR UAV. Taniguchi, Hiroki. s.l. : The University of Tokyo, 2008.

10. Systems, Egit. Skylark. [Online] http://www.elbitsystems.com/elbitmain/.

11. C-Astral. Brammor. [Online] http://c-astral.com/.

12. MIT. MIT - Videos. [Online] http://aerobatics.mit.edu/videos.html.

13. CAA. UAV regulations. [Online] http://www.caa.co.uk/docs/1416/srg_str_00002-01-180604.pdf.

14. Bot Skool. [Online] 1) http://www.botskool.com/tutorials/fourth-year-projects/autopilot-control-system.

15. The Development of Micro Avionic Systems for UAV’s. Cowling, Patrick. 2011.

16. Development Of An Open Arcitecture AHRS Using Micro Electro Mechanical Sensors. Clarke, Jonathon. 2010.

17. Real-Time Attitude and Position Estimation for Small. Beard, Derek B. Kingston and Randal W.

18. SensComp. 600 Series Environmental Transducer Specification.

19. —. 6500 Series Ranging Module Specification.

20. Mr, Graham Holland (Supervisor Dr W. H. Chen). Airship Flight Control. 2010.

21. Development of an AUtonomous Landing System For Fixed-Wing UAV's. Dunthorne, James. 2011.

22. Micropilot. MP2028 Installation & Operation Manual.

23. Progress Report On Autonomous Terminal Area Manoeuvring For Unmanned Aerial Vehicles. McAree, Owen. 2011.


Final Year Project Report Latest Version

Documents

Transcript of Final Year Project Report Latest Version