Automatic Takeoff and Landing of Unmanned Fixed Wing Aircrafts1055556/FULLTEXT01.pdf · Landing of...

Master of Science Thesis in Computer ScienceDepartment of Electrical Engineering, Linköping University, 2016

Automatic Takeoff andLanding of UnmannedFixed Wing AircraftsA Systems Engineering Approach

Magnus Vestergren

Master of Science Thesis in Computer Science

Automatic Takeoff and Landing of Unmanned Fixed Wing AircraftsA Systems Engineering Approach

Magnus Vestergren

LiTH-ISY-EX--16/5009--SE

Supervisor: Ola Dahlisy, Linköpings universitet

ThomMagnussonInstrument Control Sweden AB

Examiner: Tomas Svenssonisy, Linköpings universitet

Division of Computer EngineeringDepartment of Electrical Engineering

Linköping UniversitySE-581 83 Linköping, Sweden

Copyright © 2016 Magnus Vestergren

Abstract

The purpose of this thesis is to extend an existing autopilot with automatic take-off and landing algorithms for small fixed wing unmanned aircrafts. The workhas been done from a systems engineering perspective and as for solution candi-dates this thesis has a bias towards solutions utilizing fuzzy logic. The covetedpromises of fuzzy logic was primarily the idea to have a design that was easilytunable with very little knowledge beyond flight experience for a particular air-craft.

The systems engineering perspective provided a way to structure and reasonabout the project where the problem has been decoupled from different solutionsand the work has been divided in a way that would allow multiple aspects of theproject to be pursued simultaneously.

Though the fuzzy logic controllers delivered functional solutions the promisesrelated to ease of tuning was not fulfilled in a landing context. This might havebeen a consequence of the designs attempted but in the end a simpler solutionoutperformed the implemented fuzzy logic controllers. Takeoff did not presentthe same issues in tuning but did require some special care to handle the initiallow airspeeds in an hand launch.

iii

Contents

List of Figures viii

List of Tables x

Notation xi

1 Problem description and approach 11.1 A systems engineering approach . . . . . . . . . . . . . . . . . . . . 2

2 Background - Fuzzy logic 32.1 Criticisms of fuzzy logic . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Fuzzy logic in a control system . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Fuzzy inference system . . . . . . . . . . . . . . . . . . . . . 52.2.2 Mamdani inference system . . . . . . . . . . . . . . . . . . . 62.2.3 Sugeno fuzzy inference system . . . . . . . . . . . . . . . . 8

3 Background - Fixed wing aircrafts 113.1 Stall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Landing a fixed wing UAV . . . . . . . . . . . . . . . . . . . . . . . 133.3 Takeoff with a fixed wing UAV . . . . . . . . . . . . . . . . . . . . . 143.4 The ground effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Background - Splines 15

5 Desired system properties 195.1 Landing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Takeoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 System components 216.1 Spy Owl 100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.2 Spy Owl 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.2.1 Altimeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.3 EasyPilot 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.3.1 Sensor unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

v

vi Contents

6.3.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.4 SkyView Ground Control Software . . . . . . . . . . . . . . . . . . 256.5 STANAG 4586 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.6 External factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7 Performance 277.1 Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.1.1 Landing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.1.2 Takeoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7.2 Autopilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.3 Consequences of deviations from the desired behavior . . . . . . . 29

7.3.1 Landing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.3.2 Takeoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

8 Cost 31

9 Design 339.1 Fuzzy logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

9.1.1 Mamdani aggregation . . . . . . . . . . . . . . . . . . . . . 349.1.1.1 Integration . . . . . . . . . . . . . . . . . . . . . . 349.1.1.2 Custom . . . . . . . . . . . . . . . . . . . . . . . . 349.1.1.3 Precomputed . . . . . . . . . . . . . . . . . . . . . 359.1.1.4 Aggregation summary . . . . . . . . . . . . . . . . 36

9.2 Landing controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369.2.1 Fuzzy controller . . . . . . . . . . . . . . . . . . . . . . . . . 369.2.2 Flare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9.3 Approach trajectory . . . . . . . . . . . . . . . . . . . . . . . . . . . 379.3.1 Pitch lookahead . . . . . . . . . . . . . . . . . . . . . . . . . 38

9.4 Approach/Descend trajectory . . . . . . . . . . . . . . . . . . . . . 399.5 Keeping the aircraft on track . . . . . . . . . . . . . . . . . . . . . . 409.6 Takeoff Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409.7 Consequences, difficulties and limitations . . . . . . . . . . . . . . 409.8 Stall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419.9 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

9.9.1 Landing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429.9.2 Takeoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

9.10 Retry and abort conditions . . . . . . . . . . . . . . . . . . . . . . . 44

10 Implementation 4510.1 Fuzzy logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

10.1.1 Membership functions . . . . . . . . . . . . . . . . . . . . . 4510.1.2 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

10.1.2.1 Mamdani custom algorithm . . . . . . . . . . . . . 4610.1.3 Defuzzification . . . . . . . . . . . . . . . . . . . . . . . . . 48

10.2 Landing controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4910.2.1 Approach controller . . . . . . . . . . . . . . . . . . . . . . 4910.2.2 Flare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Contents vii

10.3 Approach trajectory . . . . . . . . . . . . . . . . . . . . . . . . . . . 5110.4 Lookahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5110.5 Takeoff controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

11 Results 5511.1 Execution performance . . . . . . . . . . . . . . . . . . . . . . . . . 55

11.1.1 How the memory performance was measured . . . . . . . . 5511.1.2 How the execution performance was measured . . . . . . . 5611.1.3 Execution performance measurements . . . . . . . . . . . . 56

11.2 Flight performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 5711.2.1 How the performance was measured . . . . . . . . . . . . . 5711.2.2 Landing simulation results . . . . . . . . . . . . . . . . . . . 5811.2.3 Landing real world results . . . . . . . . . . . . . . . . . . . 5911.2.4 Takeoff simulation results . . . . . . . . . . . . . . . . . . . 6311.2.5 Takeoff real world results . . . . . . . . . . . . . . . . . . . 65

11.3 Trade-off requirements . . . . . . . . . . . . . . . . . . . . . . . . . 65

12 Conclusions 6912.1 Landing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7012.2 Takeoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7012.3 Fuzzy logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7012.4 Systems engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . 7112.5 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Bibliography 73

List of Figures

2.1 Potential membership function for the class of tall men. . . . . . . 42.2 Common steps in a fuzzy inference system. . . . . . . . . . . . . . 62.3 The steps and their relations in a Mamdani type fuzzy inference

system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 The aggregation step in a Mamdani fuzzy inference system illus-

trated with the max aggregation method. . . . . . . . . . . . . . . . 82.5 Mamdani defuzzifcation example, taking the center of gravity on

the x-axis of the fuzzy set to produce an output. . . . . . . . . . . . 9

3.1 A typical relation between coefficient of lift and angle of attack,illustrating the effects of a stall [13]. The critical angle of attack, inthis case, is about 17◦. . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Illustration of the airflow on an airfoil in normal and stall condi-tions [14]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Blending functions for a Bézier curve with four control points. . . 164.2 Blending functions for the Catmull-Rom spline. . . . . . . . . . . . 17

6.1 Spy Owl 100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.2 Spy Owl 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.3 EasyPilot block diagram from the viewpoint of this thesis. . . . . . 246.4 EasyPilot 3.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.5 User interface of SkyView GCS. . . . . . . . . . . . . . . . . . . . . 26

9.1 System design block diagram. . . . . . . . . . . . . . . . . . . . . . 349.2 Rough outline of a basic approach trajectory. . . . . . . . . . . . . . 399.3 Landing route as presented in SkyView GCS . . . . . . . . . . . . . 43

10.1 The triangle and trapezoid membership functions. . . . . . . . . . 4610.2 Illustration of the aggregation step using the max aggregation method. 4710.3 The result of the custom aggregation method. . . . . . . . . . . . . 4810.4 Creating a segment from two points and dividing the segment into

a triangle and a rectangle. . . . . . . . . . . . . . . . . . . . . . . . 4810.5 Illustration of of the segments needed to consider during defuzzifi-

cation after aggregation with integration and the custom aggrega-tion method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

viii

LIST OF FIGURES ix

10.6 Illustrating the lookahead algorithm. . . . . . . . . . . . . . . . . . 52

11.1 Simulated landing with fuzzy logic controller regulating the throt-tle and pitch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

11.2 Simulated landing with fuzzy logic controller regulating the throt-tle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

11.3 Simulated landing with the lookahead algorithm. . . . . . . . . . . 6011.4 Spy Owl 100 landing with fuzzy logic controller regulating the

throttle and pitch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6111.5 Spy Owl 100 landing with the lookahead controller. . . . . . . . . 6211.6 Spy Owl 200 landing with the lookahead controller. . . . . . . . . 6311.7 Horizontal distance (left/right from the UAVs point of view) of the

Spy Owl 100 from the desired landing trajectory. . . . . . . . . . . 6411.8 Takeoff data from a hand launch with Spy Owl 100 . . . . . . . . . 6611.9 Takeoff data from a hand launch with Spy Owl 200 . . . . . . . . . 66

List of Tables

6.1 Spy Owl 100 Specifications. . . . . . . . . . . . . . . . . . . . . . . 226.2 Spy Owl 200 Specifications. . . . . . . . . . . . . . . . . . . . . . . 236.3 Fluke 414D with Porcupine LR4 interface board specifications. . . 23

9.1 Memory consumption, in number of values, required for the pre-computed values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

9.2 Abort conditions and possible actions. . . . . . . . . . . . . . . . . 44

10.1 Landing fuzzy rule set: Regulate altitude with the throttle and air-speed with the desired pitch. . . . . . . . . . . . . . . . . . . . . . . 50

10.2 Landing fuzzy rule set: Regulate throttle after altitude and keep afixed pitch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

10.3 Fuzzy rule set abbreviations and descriptions. . . . . . . . . . . . . 5010.4 Takeoff fuzzy rule set: Simple rule set where the input is the air-

speed of the aircraft output is the desired pitch level. . . . . . . . . 52

11.1 Memory consumption for the fuzzy logic and lookahead controllers. 5711.2 Time to perform one iteration of the fuzzy logic and lookahead

controllers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

x

Notation

Glossary and acronyms

Term Explanation

AGL Altitude Over Ground.Ailerons Control surface to control the roll of an aircraft.Airspeed The speed of the aircraft relative to the air.Attitude Pitch and roll of an aircraft.Elevator Control surface to control the pitch of an aircraft.

Flare The final adjustments before touchdown.GCS Ground Control Station.PID-

Controller Proportional-Integral-Derivative controller.

Pitch Indication of how much the aircraft’s nose is point upor down.

Roll Indication of how much the aircraft has been rotatedto the left or right as seen from behind the aircraft.

Rudder Control surface to control the yaw of an aircraft.UAV Unmanned Aerial Vehicle.

xi

1Problem description and approach

Instrument Control Sweden AB (ICS ) has produced a miniature autopilot, EasyP-ilot 3.0 (EasyPilot ), for unmanned vehicles; the EasyPilot has been adapted to beused with fixed wing aircrafts for several applications. For a fixed wing aircraftlanding and takeoff are the most critical elements of a mission, at ICS these arecurrently carried out by a human pilot. The goals of automating takeoff and land-ing are to minimize the risks and increase repeatability of a flight at the sametime as reducing the dependence on a human pilot; as the capabilities of the au-topilot are improved the need for a skilled pilot is reduced. For unmanned fixedwing aircrafts there are several common techniques to simplify the process ofpiloted or automated landing, such as the use of parachute, net (where the air-craft is flown straight into net that catches the airframe), and deep stall landings.These are however greatly dependent on the airframe and payloads used and notas suitable for a general purpose autopilot as a more traditional approach.

The EasyPilot is sold both as a standalone autopilot as well as a part of com-plete fixed wing systems developed by ICS . For both the standalone and completesystems the end user often have very little to no experience with fixed wing air-crafts; this reinforces the need to minimize the dependence on a human pilot. Forthe end user this means that more energy and effort can be spent on their needsrather than operating the aircraft. A repeatable system also inspires confidenceand when considering that the payloads used in unmanned aircrafts often consistof very expensive and fragile camera equipment this becomes an important fac-tor for the system as a whole. At the time for this thesis the only missing piecesin the EasyPilot for achieving a fully autonomous system, where the autopilot isin control throughout the flight, are takeoff and landing.

The purpose of this thesis is to extend the autopilot to include automatic take-off for hand thrown aircrafts as well as automatic belly landing. For this fuzzylogic has been suggested as a solution candidate and consequently this project

1

2 1 Problem description and approach

will have a bias towards solutions utilizing fuzzy logic.Based on the above this thesis aims to treat the following questions:

Does the EasyPilot 3.0 have the necessary hardware needed to per-form automatic landing and takeoff of fixed wing aircrafts?

Is it feasible to implement fuzzy logic on the EasyPilot 3.0 (and similarembedded systems)?

Is fuzzy logic a suitable alternative for implementing landing andtakeoff controllers on embedded systems?

The takeoff and landing controllers developed for this thesis will be able toutilize the existing control surface controller as well as having access to filteredsensor data. The EasyPilot has been developed with the intention of being easilyadaptable to different types of fixed wing UAVs with as little calibration andtuning as possible. It is therefore desirable for the takeoff and landing controllersto be designed as to minimize any added effort of tuning the EasyPilot .

1.1 A systems engineering approach

This thesis has been done with a systems engineering approach, the approachhas been inspired by A. Wayne Wymore and his book Model-Based Systems En-gineering [15]. Wymore stresses the importance of not stating the problem interms of a preconceived solution [15, p. 8]. Ian Ross, former president of BellLaboratories Inc., was quoted in The New York Times [1] with a similar view:

It’s a foolish thing to tell a research person what the problem is —you’ll get the answer to that problem and miss a brilliant discovery inthe process, (Ian Ross)

With a systems engineering approach this thesis hopes to encapsulate the ideathat the problem and solution should be decoupled. The problem is described interms of desired behavior (section 5) and the solution candidates as restricted bythe available components, possible techniques and external factors (section 6).

A quantitative way of evaluating different systems in terms of performance(section 7) and cost (section 8) is presented. With the previous sections in minddesigns are proposed (section 9), implemented (section 10) and evaluated (sec-tion 11).

One goal with the distribution of the sections is that they should be as inde-pendent as possible and be able to stand on their own. If fuzzy logic were to beabandoned as a solution candidate the goal of the controller should still be thesame. The performance and cost could still be evaluated regardless of approachand since the evaluation is independent of the different solutions, even those notconceived or mentioned in this thesis, can be compared on equal terms. Similarlyif, for instance, this thesis relies on an assumption that doesn’t hold for other sce-narios or makes use of an component that isn’t available for another project thereader should be able to deduce the consequences and their magnitudes.

2Background - Fuzzy logic

Fuzzy logic is a form of multi-valued logic which arose to address the prob-lem of describing and handling partial truths, which was first studied by JanLukasiewics [4, loc.331] . The beginning of fuzzy logic is often credited to LotfiA. Zadeh and his paper about Fuzzy Sets [17] that came out in 1965.

In that paper Zadeh states that objects in the real world, more often than not,does not have a clear definition of membership and explains why this is problem-atic in regular set theory. An example that is brought up is the class of tall menthat illustrates the imprecision often used by humans. Few would be comfortablewith an arbitrarily small difference in height making the difference of whether aperson is tall or not (sorites paradox). A fuzzy set on the other hand allows forpartial membership and can thus distinguish people who are somewhat tall orvery tall in a way that is in better agreement with natural language and everydayconversation [17, p. 338].

In Zadeh’s paper the degree of membership in a set is decided by a member-ship function fmf (x) where each value of x is mapped to a real number in theinterval [0, 1], the degree of membership. In figure 2.1 a potential membershipfunction for the class of tall men is presented.

Other potential problems with typical two valued logic is illustrated with thelaw of excluded middle that states that a proposition is either true, or its negationmust be. When dealing with clear definitions this might not be a problem, butthere is often more information conveyed within natural language and thus someinformation is lost in translation. Whether this is a problem or not depends onones viewpoint. For situations where it is considered to be a problem computingwith words is a methodology where emphasis is put on dealing with words ratherthan numbers and symbols, trying to preserve the information conveyed in natu-ral language. In the paper Fuzzy logic = computing with words [18] Zadeh notesthat computing with words underlies almost all applications of fuzzy logic and

3

4 2 Background - Fuzzy logic

that the main contribution of fuzzy logic is that it is a methodology for computingwith words.

1 1.2 1.4 1.6 1.8 20

0.2

0.4

0.6

0.8

1

Length [m]

Deg

ree

ofm

embe

rshi

p

Figure 2.1: Potential membership function for the class of tall men.

2.1 Criticisms of fuzzy logic

There have been plenty of criticism of fuzzy logic, the combination of wide appli-cability and vagueness has probably contributed to the overall skepticism fromthose who practice more traditional and apparent rigorous fields. Although asZadeh emphasize in his paper Is there a need for fuzzy logic? [19], there are manymisconceptions about fuzzy logic and that fuzzy logic itself isn’t fuzzy. And asBergmann [4] points out, misconceptions of fuzzy logic is probably partly due toconflation of fuzzy logic in the narrow sense and broad sense (section 2.2).

However, it is not hard to understand why fuzzy logic has been criticized, as isillustrated by a quote from Haack ’s paper Do we need “fuzzy logic”? [6, p. 441]:

It should be apparent, by now, just how radical a departure fuzzylogic is. Zadeh offers us not only a radically non-standard logic, butalso a radically non-standard conception of the nature of logic. Itwould scarcely be an exaggeration to say that fuzzy logic lacks everyfeature that the pioneers of modern logic wanted logic for; it sacrificeswhat have traditionally been regarded as the crucial advantages offormalism–precise, formal rules of inference, the security offered byconsistency and completeness results. [...]

Still, though fuzzy logic represents such a dramatic departure fromthe logical tradition, that it does so isn’t, of itself, a cogent criticism ofthe enterprise. The question is, rather, whether there are good reasonsfor such a departure. I shall argue that there are not.

(Susan Haack)

A response to some of the criticism is done by Yen in the paper Fuzzy Logic -A Modern Perspective [16, p. 2]:

2.2 Fuzzy logic in a control system 5

Indeed, providing a cost-effective solution to a wide range of realworld problems is the primary reason that fuzzy logic has found somany successful applications in industry to date. Understanding thisdriving force of the success of fuzzy logic will prevent us from fallinginto the trap of debating “whether fuzzy logic can accomplish whatX can not accomplish” where X is an alternative technology such asprobability theory, control theory, etc. Such a debate is usually notfruitful because it ignores one important issue – cost. A better ques-tion to ask is “What is the difference between the cost of a fuzzy logicapproach and the cost of an approach based on X to accomplish a cer-tain task?” (John Yen)

The case made by Yen resonates well with the Matlab user guide for its fuzzylogic toolbox where it is argued that the gains of using fuzzy logic is often thatit is easy to implement, easy to understand and easy to maintain and calibrate- not that it is the only or computationally the most efficient way of doing it [8,p. 1-18, 1-20].

2.2 Fuzzy logic in a control system

Fuzzy logic has evolved in two main subsets, fuzzy logic in the narrow sense andfuzzy logic in the broad sense. Fuzzy logic in the narrow sense is aimed at beinga generalization of classical logic whereas fuzzy logic in the broad sense dealswith human reasoning and practical applications such as fuzzy set theory, fuzzycontrol systems and expert systems.

The background provided in this chapter will be focused on the parts relevantfor this thesis, which is mainly fuzzy logic in the broad sense as a fuzzy controlsystem.

2.2.1 Fuzzy inference system

A Fuzzy Inference System (FIS) can be used as a base for a fuzzy control systemand maps a set of inputs to a set of outputs using fuzzy logic. The general stepsinvolved are usually:

• Fuzzification

• Fuzzy inference

• Defuzzification

Their relationships is depicted in figure 2.2.Fuzzification usually takes the inputs in the form of a crisp values and fuzzi-

fies them into fuzzy sets with the help of member functions. If the input to afuzzy inference system is the temperature of a warm beverage, say coffee, is 80 ◦Cit gets fuzzified into a large degree of hot.


Fuzzification

Fuzzy inference

Defuzzification

Crisp input

Fuzzified input

Fuzzy output

Crisp output

Figure 2.2: Common steps in a fuzzy inference system.

The fuzzy inference step makes use of expert knowledge, often in the form ofif-then rules, to produce a fuzzy output, i.e. if temperature of coffee is just rightthen drink.

Defuzzification takes the fuzzy output from the fuzzy inference step and usu-ally produces a crisp output, as with the steps above the exact process of doingdefuzzification varies but in general you want to consider the output from theinference step and produce a crisp value - for each of the outputs. If some rulein the fuzzy inference step concludes that you should drink fast and another thatyou should drink slowly the result might be drink moderately, or if it is consid-ered to be of greater importance that we shouldn’t drink too little coffee the resultmight still be drink fast.

Two of the more common fuzzy inference systems are Mamdani (section 2.2.2)and Sugeno (section 2.2.3).

2.2.2 Mamdani inference system

The Mamdani inference system is considered to be the most commonly usedfuzzy inference system, it stores the knowledge in the form of if-then rules andcompared to the Sugeno inference system (section 2.2.3) it is considered to beeasy to deal with but tends to be much more expensive computationally.

The steps and relations involved in a Mamdani type fuzzy inference systemare depicted in figure 2.3.

FuzzificationEach input is fuzzified with the means of, usually several, membership functions.The input variable for the coffee temperature might have three membership func-tions associated with it: cold, just right and hot.


Fuzzification

Rule evaluation

Implication

Aggregation

Defuzzification

Crisp input

Fuzzified input

Rule outputs

Implication res.

Fuzzy output

Crisp output

Figure 2.3: The steps and their relations in a Mamdani type fuzzy inferencesystem.

Rule evaluationA rule for the input described above might say: If coffee temperature is hot orcoffee temperature is cold then desire to drink is low.

Where desire to drink is an output of the system with perhaps two member-ship functions associated with it, low and high. The terms that appear in theif -part is called antecedents and the terms that appear in the then part is calledthe consequents.

If there are multiple antecedents they are combined with the use of a fuzzyoperator, and or or. There are many different functions used when implement-ing fuzzy operators but a common and simple function used for and is min, thatuses the smallest value produced by the antecedents. The corresponding func-tion commonly used for or is max, that uses the largest value produced by theantecedents. The result of the fuzzy operator is scaled with the weight of the rule,where the weight is typically a value between zero and one.

ImplicationThe result of the rule evaluation is mapped to the output member function withthe use of an implication function. The result of the implication function is afuzzy set and the simplest, and still commonly used, is the min function wherethe output member function is capped at the height corresponding to result ofthe rule evaluation.


AggregationAggregation takes the result from all of the rules in the form of fuzzy sets andcombines them to a single fuzzy output for each of the outputs. A commonmethod for doing this is max, which combines the greatest contribution fromeach rule into a combined fuzzy set, se figure 2.4. For Mamdani this is the mainstep that is considered computationally heavy and not always suitable for embed-ded systems.

0 0.2 0.4 0.6 0.8 10

0.20.40.60.8

1

Result of rule 1

0 0.2 0.4 0.6 0.8 10

0.20.40.60.8

1

Result of rule 2

0 0.2 0.4 0.6 0.8 10

0.20.40.60.8

1

Result of rule 3

0 0.2 0.4 0.6 0.8 10

0.20.40.60.8

1

Result of aggregation

Figure 2.4: The aggregation step in a Mamdani fuzzy inference system illus-trated with the max aggregation method.

DefuzzificationThe output from the aggregation is in the form of of a fuzzy set and the outputof the defuzzification is usually a single number per output. The output is mostcommonly calculated by calculating the center of gravity of the fuzzy set on thex-axis. The defuzzification step is illustrated in figure 2.5.

2.2.3 Sugeno fuzzy inference system

The Sugeno fuzzy inference system was introduced in 1985 [12] and share muchwith the Mamdani fuzzy inference system. The main differences between be-tween Mamdani and Sugeno is that Mamdani focuses on leveraging human rea-soning when the rules for the system is compiled. A Sugeno rule on the otherhand is on the following form: If input 1 is x and input 2 is y then output is z =ax + by + c. The output is compiled as the weighted average, wi , of all rules, asdescribed in equation 1. Compared with Mamdani it becomes apparent that the


0 0.2 0.4 0.6 0.8 10

0.2

0.4

0.6

0.8

1

CGX

Figure 2.5: Mamdani defuzzifcation example, taking the center of gravity onthe x-axis of the fuzzy set to produce an output.

Sugeno fuzzy inference system has a clear advantage when it comes to executionperformance.

output =

n∑i=1wizi

n∑i=1wi

Equation 1: Output in a Sugeno system.

3Background - Fixed wing aircrafts

The main forces that affect a flying fixed wing aircraft are the thrust generatedfrom the propulsion system, lift that is generated from the wings, the weightthat pulls the aircraft downwards and the drag that counteracts the movementin the direction of the aircraft. Drag can be divided in parasite drag and induceddrag where parasite drag is comprised of all of the forces that works against thedirection of travel that doesn’t contribute to the flight, whereas induced drag isthe drag that is associated with the generation of lift.

Lift is of great importance when flying. In a particular fixed wing aircraftduring level flight the most important factor that affects the lift is the Angle OfAttack, which is the angle between the relative wind and the airfoil. When theangle of attack is increased so does the lift (at the cost of increased induced drag)until the critical angle of attack is reached where the maximum lift is generated.Beyond the critical angle of attack the aircraft will stall (section 3.1); a typicalrelationship between lift and angle of attack is illustrated in figure 3.1. Otherfactors that affect the lift of an aircraft is the airfoil, wing area as well as airdensity, which depends on pressure, temperature and humidity [2, p. 4-7].

3.1 Stall

A stall occurs when the angle of attack increased beyond the critical angle of at-tack at which point the airflow separates from the wing’s surface (see figure 3.2),resulting in drastically reduced lift (figure 3.1) as well as a greatly increased in-duced drag which in turn results in the aircraft not being able to sustain levelflight. The airfoil of the wing is often designed as to stall at the root of the wingfirst, by having the greatest angle of attack at the root, and then propagating out-wards. This is done so that the part of the wing where the ailerons reside will notstall first and thus ensuring that in the beginning of a stall the control surface

11

12 3 Background - Fixed wing aircrafts

Figure 3.1: A typical relation between coefficient of lift and angle of attack,illustrating the effects of a stall [13]. The critical angle of attack, in this case,is about 17◦.

6°, steady flow

15°, stall point, maximum lift

25°

relativewind

separation point

separated flow

Figure 3.2: Illustration of the airflow on an airfoil in normal and stall condi-tions [14].

3.2 Landing a fixed wing UAV 13

of the ailerons are still as effective as possible. The angle of attack or speed atwhich a fixed wing aircraft stalls is not constant but depends on factors such asair density, ground effect (section 3.4) engine thrust and is affected by flight ma-neuvers such as abrupt changes in attitude, after for instance a dive or during asharp turn [2, p. 4-3, 4-22].

The flight characteristics of a stalling aircraft is greatly dependent on the air-craft itself, particularly the center of gravity of the aircraft is of great importancesince it decides whether the aircraft has a tendency to drop the nose in a stallingcondition or not. Dropping the nose is often desirable since it will increase thespeed of the aircraft and reduce the angle of attack, thus if the center of gravityis off the pilot might not be able to exit the stall and the aircraft will plummet tothe ground [2, p. 4-22].

3.2 Landing a fixed wing UAV

In broad terms landing consists of four stages, where the first stage concernsaligning the aircraft with the landing area and position itself for the next stage.The second stage, the approach, descends the aircraft towards the touchdownpoint in a constant glide slope. The third stage, the flare, concerns with the lastadjustments before touchdown with the goal of reducing the vertical speed, tran-sition to a desired touchdown attitude and aligning the aircraft in the directionof the aircraft velocity vector.

The fourth stage concerns with stopping the aircraft on the ground. In a bellylanding the high friction between the aircraft and the ground will inevitably slowthe aircraft to a complete stop in such a short amount of time that there isn’t muchroom for adjustments after touchdown. A runway landing on the other hand ismore delicate, taking much longer to slow down and requires much more careafter touchdown, making sure that the aircraft stays on the runway and doesn’tfall over.

Landing should always be done towards the wind and preferably straightinto it, if there is side-wind present the aircraft will approach the landing areaslightly sideways and should, at last possible moment, align itself in the directionit moves before touchdown.

The main controllers during the approach and flare are the elevator and thethrottle that both have an impact on the angle of attack which in turn also affectsthe velocity of the aircraft. Larger aircrafts often have flaps that both slow the air-craft down and increase the lift (thus reducing the stall speed) and/or other formof air-brakes. However, UAVs of the sizes relevant for the EasyPilot (section 6.3)usually lack flaps or other air-brakes. Slowing the aircraft down in reasonabletime without any form of air-brake, while descending, is by itself often a chal-lenge.

14 3 Background - Fixed wing aircrafts

3.3 Takeoff with a fixed wing UAV

Performing a takeoff with a fixed wing UAV is significantly less intricate thanlanding. The main parts consists of getting into air, which depends on whetherthe aircraft is launched from hand throw, catapult or runway, and climbing to aspecified altitude while avoiding any obstacles. In a hand launch or a catapultlaunch the aircraft starts off airborne and the main challenge in this case is tomaintain control of the aircraft despite the fact that the airspeed can be very lowat the same time as ensuring that the aircraft does not loose too much altitude. Inthe case of a runway launch the aircraft will need to gain enough speed to be ablebecome airborne on its own at the same time as keeping itself on the runway.

When climbing, aside from the initial increase in the climb angle, where theincreased angle of attack results in greater lift, the wing can be considered to havethe same lift as when flying in level flight and thus the maximum climb rate ismainly dependent on the available thrust and weight of the aircraft [2, p. 4-21].

3.4 The ground effect

The ground effect affects an aircraft that is close to the ground, this is caused bythe airflow being restricted by the ground surface [2, p. 4-9]. For a fixed wing air-craft the ground effect increases the lift and reduces the induced drag, for a largeaircraft this can present difficulties when trying to slow down at low altitudes.

4Background - Splines

A spline in a computer graphics context is a smooth curve that is defined bya set of control points. There are many different types of splines but they canbe classified into two different sets; interpolation splines, where the curve goesthrough each control point and approximation splines where the control pointsneed not to go through the control points.

A common way to specify a spline is with blending functions that specifyhow much each control point in the spline should influence the curve, the sumof all blending functions will always equals to 1. Two types of splines that makeuse of blending functions is the Bézier curve and the Catmull-Rom spline [11,p. 88, 90].

The Bézier curve is an interpolating spline that is, usually, defined from fourcontrol points. The equations for the blending functions that make up such acurve is presented in equation 2 and illustrated in figure 4.1.

The Catmull-Rom spline is an interpolation spline that is defined from fourcontrol points. Unlike the Bézier curve the spline is only defined for the innermost two control points. The equations for the blending functions that make upa Catmull-Rom spline is presented in equation 3 and illustrated in figure 4.2.

The illustration of the blending functions for both the Bézier curve and theCatmull-Rom spline reveal that both begin and end with exactly one blendingfunction contributing to the curve; this implies that the curve will intersect witha control point at the beginning and end of the curve.

15

16 4 Background - Splines

B0 = (1 − u)3

B1 = 3u(1 − u)2

B2 = 3(1 − u)u2

B3 = u3

Equation 2: Blending functions for the Bézier curve with four control points,where u is on the interval [0, 1].

C0 = −u3/2 + u2 − u/2C1 = 3u3/2 − 5u2/2 + 1

C2 = −3u3/2 + 2u2 + u/2

C3 = u3/2 − u2/2

Equation 3: Blending functions for the Catmull-Rom spline, where u is onthe interval [0, 1]. Note that the spline is only defined between the secondand third control point.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.2

0.4

0.6

0.8

1

B0

B1 B2

B3

Figure 4.1: Blending functions for a Bézier curve with four control points.

17

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

0

0.2

0.4

0.6

0.8

1

B0

B1 B2

B3

Figure 4.2: Blending functions for the Catmull-Rom spline. Note that thetwo blending functions with negative contributions are for the first and lastcontrol points; that are outside of the defined curve.

5Desired system properties

This chapter describes some desired properties that have been identified for thetakeoff and landing of a fixed wing aircraft. The system properties described inthis chapter are to be considered high level system properties and does not detailany specifics as this is greatly dependent on the aircraft used.

5.1 Landing

The most important factors of a successful landing is the attitude (relative to theairstrip and wind), speed (relative to the ground and wind) and the location of theaircraft at the time of touchdown. The desired attitude and speed at touchdowndepends on the aircraft used and the goal of the landing controller is to get asclose to the desired parameters as possible at the point of the touchdown.

A decent touchdown, according to the criteria above, requires long prepara-tions to line up and descend the aircraft in a controlled fashion. Compared tomanned aircrafts no care need to be taken to ensure passenger comfort. How-ever, large last minute maneuvers are not desirable since they would have to relyvery heavily on sensors and aircraft characteristics as well as leaving little roomfor margin when it comes to unforeseen external influences, such as wind gusts.When close to the ground the controller should not make use of roll to turn theaircraft since this might force a wing into the ground.

5.2 Takeoff

As this thesis is mainly about hand throw launches the aircrafts starts off airborne.The aircraft should be launched straight into the wind as to maximize the initialairspeed of the aircraft. The goal of the takeoff controller is to maintain the course

19

20 5 Desired system properties

towards the wind and ascend the aircraft in a controlled fashion. While it isprimarily only in the beginning of a takeoff that it is of great importance to launchstraight into the wind it is desirable, from the point of view of the operator, forthe aircraft to maintain its course. Making it easier to plan the takeoff and avoidany obstacles.

The takeoff is less delicate than the landing since it does not have to aim fora specific point to complete the launch. The controller can focus on an optimalascend with much less regard for the surroundings or care about following aspecific path.

6System components

The hardware components available for this thesis was mainly decided before-hand. Everything should be developed for the EasyPilot and not requiring anyexternal hardware - with, if deemed necessary, the exception of an altimeter. Thehardware available on the EasyPilot is described in section 6.3.

As for the implementation this thesis has a clear bias towards fuzzy logic, asdescribed in the problem description. The EasyPilot also dictates that C shouldbe the implementation language and in terms of software and algorithms the con-troller has access to the source code and inner loop controllers already developedfor the EasyPilot . As a consequence of the architecture, described in section 9, thecontroller will not have direct access to the sensors but will work on processedand filtered data that is delivered by the sensor unit.

6.1 Spy Owl 100

The aircraft available for this thesis is the Spy Owl 100 . The Spy Owl 100 aircraftis sold as a training solution and is especially suitable for development since itis cheap, easy to modify and repair. The Spy Owl 100 is depicted in figure 6.1and for this thesis the Spy Owl 100 has been equipped with an laser altimeter(section 6.2.1). Some specifications for the Spy Owl 100 are available in Table 6.1.

6.2 Spy Owl 200

Although all of the testing and development will be on the Spy Owl 100 (sec-tion 6.1) a goal is to be able to test the result on the Spy Owl 200 . This will alsogive an indication on how much work is needed to adapt for different aircraftsand how easily tuned the controllers are. The Spy Owl 200 is a much more rugged

21

22 6 System components

Figure 6.1: Spy Owl 100.

Spy Owl 100 SpecificationsWing span 1.8 mLength 1.2 mEndurance Up to 60 minutesEngine 350W electric mo-

torMaximum takeoffweight

3 kg

Extra payload 0.5 kgTable 6.1: Spy Owl 100 Specifications.

and purpose built aircraft where flight characteristics and endurance have beenprioritized as well as featuring better payload capabilities. The Spy Owl 200 isdepicted in figure 6.2 and some of its specifications are available in Table 6.2.

6.2.1 Altimeter

For this thesis the aircraft was equipped with a laser altimeter. The laser used isa hand held Fluke-414D distance measurement tool with a Porcupine ElectronicsLR4 circuit board. The LR4 is a third party interface board from which the lasermeasurements can be read through a serial interface rather than the display onthe instrument itself. The specifications for the solution, as presented by Porcu-pine Electronics, can be read in Table 6.3.

6.3 EasyPilot 3.0 23

Figure 6.2: Spy Owl 200.

Spy Owl 200 SpecificationsWing span 2 mLength 1.5 mEndurance Up to 100 minutesEngine Electric motorMaximum takeoffweight (hand launched)

6.5 kg

Extra payload 1.7 kgTable 6.2: Spy Owl 200 Specifications.

6.3 EasyPilot 3.0

The EasyPilot 3.0 (EasyPilot ) is a STANAG 4586 (section 6.5) compliant autopilotdeveloped by ICS that has mainly been targeting fixed wing aircrafts (depictedin figure 6.4).

The EasyPilot consists of two units, a main unit that ties everything togetherand executes both inner and outer loop controllers as well as being in chargeof all communication with the ground. The other unit is dedicated to sensors(section 6.3.1), reading values from each sensor, perform sensor fusion and com-municate the results to the main unit. The system is illustrated from the point ofview of this thesis as a block diagram in figure 6.3.

Fluke 414D with porcupine LR4 specificationsRange 0.1 to 50 mAccuracy 3mm max,

2 mm typicalPower consumption <1WMeasurement rate 0.4 to 2.5 Hz

Table 6.3: Fluke 414D with Porcupine LR4 interface board specifications.


AHRS

MAIN UNIT

Inner loopcontrollers

AutolandTakeoff

Servos Sensors

Figure 6.3: EasyPilot block diagram from the viewpoint of this thesis.

This thesis will be developed on the main unit and make use of the existinginner loop controllers. The inner loop controllers in the EasyPilot compare thecurrent state, as described by the sensor unit, with the desired state, as describedby the outer loop controllers, and produces servo outputs with the goal to com-mand the aircraft to the desired state. The inner loop controllers in the EasyPilotare based on PID controllers.

Figure 6.4: EasyPilot 3.0.

6.3.1 Sensor unit

The sensor unit incorporates an attitude heading reference system, or AHRS forshort. The AHRS provides the main unit with attitude, heading and yaw infor-mation about the aircraft and the data is collected from three axis gyroscopes,

6.4 SkyView Ground Control Software 25

accelerometers and magnetometers. The sensor unit also incorporates a GPS re-ceiver and sensors for static and dynamic air pressure. The data collected by thesensor unit is processed and then delivered to the main unit at a frequency of50Hz.

The performance of the sensor unitSome experience gathered prior to this thesis is that the attitude data delivered bythe sensor unit is very good and is not likely to be of any hindrance in this thesis.The magnetometers on the other hand can be quite unreliable, this is probably inpart due to the interference in the aircraft. The aircraft used for testing has theengine in the back, battery in the front and the EasyPilot in the center of gravityof the aircraft. This means that the current from the battery to the engine travelsalongside the EasyPilot and affects the sensors.

The positional data, as reported by the GPS and the air speed and altitude,as reported by the static and dynamic air pressure sensors, are considered to bequite good in a short time frame. However, both the altitude as measured by theair pressure sensors and the GPS can drift over time and result in a large errorduring a flight session. An initial estimate can be a positive or negative error of10m.

6.3.2 Simulation

The EasyPilot support hardware in the loop simulation for the FlightGear FlightSimulator which allows designs to be tested quickly. FlightGear Flight Simulatoris an open source flight simulator licensed under the GPL license [9] [3, p. 17]and is a popular target for customizations.

The hardware in the loop simulation disables the sensor unit (section 6.3.1)and feeds the EasyPilot with data directly from FlightGear instead. A conse-quence of this is that during the simulation the sensor data is an exact represen-tation of the state of the aircraft and will thus not share the characteristics andimperfections of real sensors.

6.4 SkyView Ground Control Software

SkyView Ground Control Software [5], or SkyView GCS, is a Windows applica-tion made by ICS for controlling STANAG 4586 (section 6.5) compliant aircrafts.For this thesis SkyView GCS will be used for controlling and planning all testflights as well as recording flights and provide real time information during testflights. The user interface for SkyView GCS is presented in figure 6.5.

6.5 STANAG 4586

STANAG 4586, standard interfaces of UAV control system (UCS) for NATO UAVinteroperability is a NATO standard that aims to promote interoperability of UAVsystems.


Figure 6.5: User interface of SkyView GCS.

Through interoperability the goal is to enable increased flexibilities and capa-bilities to significantly enhance the war fighting capabilities of the forces. WhileSTANAG 4586 is a military standard it is also used by many civilian projects.

6.6 External factors

Some of the external factors have been identified and the most notable are men-tioned in this section. The most notable external factor affecting the aircraft ismost likely wind. For a small UAV the effect of the wind can be substantial wherethe wind speed can get close to the desired airspeed of the aircraft in a landingcontext. Of large importance is also wind gusts and other irregularities of the airsurrounding the aircraft.

From the point of view of the takeoff and landing controller there are other ex-ternal factors that will significantly affect the performance. One of those factorsis the data coming from the sensor unit (section 6.3.1) where both the accuracyand frequency can have a huge impact on what the takeoff and landing controllercan do. The performance of the aircraft is also outside of the scope for an outerloop controller but something that will have an impact on what can be done. Theperformance of the aircraft is also dependent on, aside from the characteristicsof the aircraft itself, the center of gravity and weight of the aircraft which cangreatly be affected by any payload used in the aircraft.

7Performance

As indicated by the desired behavior (section 5) the most important performancemetric of the landing controller is the speed, attitude and location of the aircraftat the time of touchdown. In order to build confidence for the system the resultsshould be repeatable and work well in different wind conditions.

Related to the touchdown is the planning leading up to the touchdown, inmost cases this will follow some sort of desired trajectory and different solutionscan be evaluated by comparing how well they follow the desired trajectory aswell as the expected consequences of the deviations from the trajectory. The ex-pected consequences is helpful during the development and tuning of a landingcontroller when performing tests with a real aircraft. In simulation the cost ofa failed landing is nonexistent but with a real aircraft the cost can be severe. Tominimize the risk one can make use of a virtual touchdown point in the air, ob-serve the behavior and abort long before the aircraft would have hit the ground.The observations will indicate where and with what certainty the aircraft will hitthe desired touchdown point.

7.1 Measurements

What aspects of a landing is of most importance depends on the aircraft andthe type of landing performed. The consequences of deviations from the desiredbehavior is discussed in section 7.3. The weighting of the results will thus notnecessarily be the same in different contexts, but the measurements themselvesshould still be relevant.

Wymore talks about the weighting of different solution candidates for a givensystem in terms of trade-off requirements and suggests that methods and algo-rithms can be used to decide what aspects of the, often conflicting, desired as-pects of performance and cost should be prioritized. For the system developed in

27

28 7 Performance

this thesis a discussion of the trade-offs is presented in section 11.3.

7.1.1 Landing

Some performance metrics for the landing has been identified and during theapproach the following are the main parameters of interest.

• Distance in altitude from the desired approach trajectory.

• Left/right distance (from the point of view of the aircraft) from the desiredapproach trajectory.

• Difference in actual and desired airspeed.

Once the flare has started it is no longer of interest to follow an exact path.The goal with the flare is to align and prepare the aircraft before touchdown,anything else takes a back seat. But there are still a few parameters that are of in-terest to the operator. These parameters are greatly dependent on the prevailingconditions, subjectively one can get the idea of the performance of the flare fromobservations. But comparing the raw numbers in isolation is not believed to befruitful.

• How much does the aircraft drift to the left/right during the flare.

• How long does the aircraft travel during the flare.

At the point of touchdown it is too late to change anything so the performanceof the touchdown is thus a function of how well the approach and flare has suc-ceeded. For the touchdown the following parameters has been identified.

• Aircraft attitude, roll, pitch and heading.

• Ground and airspeed.

• Vertical velocity.

7.1.2 Takeoff

The performance of a hand launched takeoff is all about the critical first few mo-ments after the aircraft is let go. The goal of the takeoff controller is to stabilizethe roll, increase the airspeed and gain altitude at the same time. The perfor-mance is greatly affected by the throw itself which determines the initial attitudeand speed of the aircraft. For a given throw the following parameters have beenidentified.

• How much altitude is lost using the point of throw as reference.

• How long distance it takes for the aircraft to begin its final ascend.

• How well the aircraft maintains the desired course.

7.2 Autopilot 29

7.2 Autopilot

The performance of the autopilot has mainly been identified to the followingparameters.

• Memory consumption.

• Execution time.

There are lots of other potential parameters and resources that could be ofinterest depending on the hardware. Such as timers, inputs and outputs (forcommunicating with external sensors) that could affect the impact of the imple-mented controllers. But the most relevant and suitable for comparison is believedto be just memory consumption and the execution time.

7.3 Consequences of deviations from the desiredbehavior

The consequences of not being able to maintain the desired behavior can be un-fortunate. If the aircraft doesn’t behave as expected there are few guarantees thatremains, which of course is the goal of the desired behavior in the first place. Aninvoluntary touchdown, or crash, will at best only risk damaging the aircraft andthe components within. But may also risk crashing into and doing real damageto anything nearby, such as people, houses, vehicles or other aircrafts. Followingare some of the consequences in a landing or takeoff context.

7.3.1 Landing

Of the factors discussed in section 5.1 the attitude is arguably the most delicateduring a landing context. A bad attitude just before touchdown might force awing into the ground or get the nose stuck at high speed. The airspeed of theaircraft isn’t subject to as swift changes as the attitude, but the airspeed affect theability to maintain the desired attitude and if the ground speed is too high therisk of damage increases as well as the consequences of a bad attitude.

Unless a runway is targeted the desired location of the touchdown typicallyincludes a wide margin of where a touchdown is acceptable, the faster the air-craft travels the shorter, in time, the margin will be. If a runway is targeted theconsequences of missing the runway can be severe depending on the terrain.

For the aircraft considered in this thesis the attitude is considered to be themost importance aspect of a successful landing.

7.3.2 Takeoff

The most critical part of the takeoff during a hand or catapult launch is in the verybeginning. The aircraft is being subject to external forces that doesn’t necessarilyalign that well with the intended air flow around the aircraft and control surfaces.

30 7 Performance

This is also when the aircraft itself is moving very slowly, is close to stall speedsand where the margins are at its lowest. Mishaps in this stage, such as not beingable to maintain the altitude, will quickly result in a touchdown. This could alsobe the result of the throw itself (insufficient speed or bad attitude), wind gustsor the controllers inability to keep the aircraft toward the wind. If the aircraftisn’t aligned towards the wind or if the direction is affected during the launchthe reduced apparent wind speed will hinder the aircrafts ability to maintainaltitude and the increased side wind will make it harder to maintain control overthe attitude, both increasing the risk of a crash.

Once the airspeed has improved and if the aircraft has not lost too much ofits altitude over ground the remainder of the launch is just a steady climb. Theintended direction ought to include some margins so the takeoff controller shouldhave no problems to finish the takeoff.

8Cost

The cost of implementing the takeoff and landing controller is, under the assump-tion that a suitable autopilot and aircraft already is available, mainly the timetaken for research and implementation and evaluation. During the evaluationreal life flight tests require the most resources, something that involves severalpeople as well as at the very least risking an aircraft with autopilot if anythingwere to go awry.

The cost of equipping an aircraft with the takeoff and landing controller alsoincludes any altimeter used and any modifications (material and time) requiredto equip the aircraft and autopilot with the altimeter. Each aircraft model equippedwill also require additional tuning and evaluation. Any altimeter used would alsotake up precious space and usable payload weight of the aircraft.

In the point of view of the autopilot the takeoff and landing controller willrequire processing power and memory resources, both of which can be significantfor a fuzzy control system and is thus a common deterrent for embedded systems.For this reason the resources utilized by the takeoff and landing controller on theEasyPilot have been further investigated in section 11.1.

Since the EasyPilot is a general purpose autopilot the time taken to tune andadapt the controllers to a new aircraft is of great importance. A simple designthat can be quickly understood by an operator is desirable and would reduce themaintenance costs of the controller significantly at the same time as providing acompelling sales pitch.

31

9Design

From the viewpoint of this thesis the system consist of a controller for takeoff andlanding and its immediate surroundings consists of a sensor unit (section 6.3.1)and inner loop controllers (section 6.3). The system is illustrated as a block dia-gram in figure 6.3. The system takes its input from the sensor unit and producesoutputs in the form of desired behavior to the inner loop controllers. The sensorunit processes sensor data and ensures that the input data is filtered and as ac-curate as possible. The inner loop controllers tries to achieve the desired resultby controlling the control surfaces of the aircraft. All the components that themain unit deals with have not been depicted, most notably the communicationwith the ground control station is performed by the main unit. The communi-cation itself doesn’t have any impact of the behavior of the takeoff and landingcontroller but seeing as it is the ground control station that logs all data, the datathat is available for analysis is affected. The data is collected by the ground con-trol station at a frequency of about 6Hz from real flights and about 12Hz duringsimulations.

9.1 Fuzzy logic

The experimental nature of fuzzy logic (as described in section 2) made a com-pelling argument toward a design that would allow for customization and allowchanges between, for instance, different aggregation methods to be made effort-lessly. It also quickly became apparent that the customization should be decou-pled from the logic concerned with high level landing and takeoff routines thatshould not need to be bothered with details regarding the flight characteristicsof any specific aircraft. These realizations are the main motivations for the im-plemented structure of the takeoff and landing controller that is illustrated as ablock diagram in figure 9.1.

33

34 9 Design

AHRSTakeoff and

landing controllerInner loop controllers

High level takeoff and landing planner

Specialized controllers for takeoff and landing

General purposefuzzy controller

Difference between current and desired behavior.

Inputs,outputs,rules

Desired pitch,roll, heading...

Current stateand behaviorSensor data Servo positions

Figure 9.1: System design block diagram.

9.1.1 Mamdani aggregation

The, computationally, most challenging part of the Mamdani type fuzzy infer-ence system (section 2.2.2) is the aggregation step. It is the main reason for whya Mamdani inference system is not always feasible to implement in embeddedsystems. For this reason different solutions have been sought and compared.

The solution taken by open source alternatives [20, 7, 10] (not targeting em-bedded systems) have all been using some form of integration. As integration isthe cause of concern regarding the performance a faster solution would be desir-able. The advantage of using integration is that it is easy to implement and that itis a general solution that will work with no added effort regardless of how the out-put from the implication step looks. This is a compelling argument in an generalpurpose solution and is probably a reason for why it seems to be so prevalent.

9.1.1.1 Integration

When implementing aggregation with integration the output space is dividedinto a number of integration steps. For each step the output of each rule (afterthe implication method has been applied) is fed into the aggregation method,resulting in an output for that particular step. The use of integration implies atrade off between performance and precision, where a low number of integrationsteps will be faster to execute but with worse precision than when using a highernumber of integration steps.

9.1.1.2 Custom

With knowledge of how the membership functions will look and how the ruleswill be applied a custom algorithm was developed for this thesis. The goal when

9.1 Fuzzy logic 35

developing the algorithm was to first find suitable constraints that would notimpact the behavior of the controller.

A lot of the potential constraints that was conceived have the basis in the out-put membership functions used. The most commonly used membership functionused in the literature of this thesis have been the triangular membership function.The simplicity of the triangular membership function makes it easy reason about(when creating the rules of the fuzzy inference system) as well as allowing foroptimizations during aggregation. Further motivation for the triangular member-ship function is realized when considering the nature of fuzzy logic (as describedin section 2) where simplicity is held high regard.

Limiting the output membership function to triangular membership func-tions does not necessarily ensure that the aggregation step only needs to handletriangles. The implication step will affect the shape of the output membershipfunction for each rule and the possible optimizations of the aggregation methodmust be applicable on the result from the implication method. Using the triangu-lation membership function and the max implication function (which is the mostcommon implication function) the aggregation step would have to be able to han-dle symmetric trapezoids (in the form of cut-off triangles) as well as triangles.

Another constraint that was identified was in the way the output membershipfunctions could overlap. If the membership functions could not overlap morethan 50% of each other the aggregation step would at most only have to deal withtwo membership functions at the same time. Since the fuzzy inference system isstatic the output membership functions can be known to be stored in order ofappearance in the output space. This ensures that the aggregation step will nothave to search through all membership functions to discover which membershipfunctions might overlap. If, for instance, the output membership functions aretraversed from smaller to greater output values the algorithm would only haveto check the next membership function for any intersection.

9.1.1.3 Precomputed

Another alternative is to use one of the previously mentioned solutions is to com-pute the outputs of possible inputs and store the result in a lookup table. Thissolution trades memory consumption for runtime performance and can poten-tially be really fast.

To produce a somewhat equivalent result as the integration approach all possi-ble input combinations with a sufficiently high precision must be generated, com-puted and ultimately be stored on the autopilot. The memory required greatlydepends on the number of inputs, outputs and how fine grained the generatedinputs are.

The lookup table would have to contain the combination of all different valuesfor each input and map each combination to each output. A naive approach tocalculate the memory required for the lookup table can be seen in equation 4. Thememory consumption could most likely be reduced while preserving adequateprecision with the help of interpolation.

36 9 Design

#inputs #outputs #values per input Memory consumption (#values)3 2 30 540003 2 50 2500004 2 30 1620000

Table 9.1: Memory consumption, in number of values, required for the pre-computed values.

(#inputs∏i=1

#values(Ii)) ∗ #outputs

Equation 4: Memory required, in number of values, for naive approach.

9.1.1.4 Aggregation summary

The integration method should be fairly quick to implement, it also has benefitsof being able to trade performance with precision. It can also provide a simpleinterface to integrate to various different membership functions. The customalgorithm is designed as to improve the performance without sacrificing accuracy,but while imposing a few constraints. It will also require much more work toimplement and is tightly coupled with the available membership functions.

The precomputed aggregation method relies heavily on available memory; toget an idea of the necessary memory requirements for the precomputed valuesTable 9.1 lists the memory consumption (in number of values) required for dif-ferent cases (the algorithm used to measure the memory consumption is presentin section 9.1.1.3). While no analysis have been done to exactly determine howmany values are needed per input and output or how many inputs are desirableone can note that the memory consumption doesn’t scale well. Even with verymodest number of inputs, outputs and number of values this puts some limita-tions on the experimentation possible. Under the assumption that each value canbe fitted into a byte, limiting the range of all variables to 256 different values onmost of todays relevant hardware (including the hardware used for this thesis),the memory consumption of the precomputed values will still, at the very best,take a significant amount of the memory available on the EasyPilot .

9.2 Landing controller

9.2.1 Fuzzy controller

When looking at how to implement and tune the fuzzy controller inspiration wasmostly gathered from how large, manned, aircrafts were controlled. The main

9.3 Approach trajectory 37

reason for this was because the conceived solutions that explicitly target fixedwing UAVs are often tightly coupled with the aircraft used. Examples of suchsolutions include parachute, deep stall and net landings. The landing techniquesused by larger aircrafts put emphasis on a soft touchdown and was therefor be-lieved to be more suitable to a general purpose landing controller, especially con-sidering that the payload used in UAVs often consist of fragile camera equipment.

Following is two techniques used for manned aircrafts that have been tar-geted.

Regulate throttle after altitude and pitch after speedThis technique regulates the airspeed solely by the pitch of the aircraft. If theaircraft is speeding the pitch of the aircraft is increased, consequently if a greaterspeed is desired the pitch of the aircraft is decreased.

The altitude is regulated with the help of the throttle. To increase altitude thethrottle is increased and to decrease the altitude the throttle is lowered.

Regulate throttle after altitude and keep a fixed pitchSimilarly to the first technique the altitude is regulated with the help of thethrottle, the difference being that the (desired) pitch is completely fixed. Thisputs some, aircraft specific, constraints on the possible slopes of the aircraft canachieve.

9.2.2 Flare

It was decided not to try to do any last second adjustments in the flare for twomain reasons. The first reason was that such adjustments, if necessary, wouldleave very little room for margin and if they were not necessary for a safe touch-down they would be wasteful and too risky to try to implement. Also it wasassumed that the altitude over ground data would not be accurate enough, thisput some restrictions on what could be done during the flare.

For the aircraft used the engine should not be running during touchdown,this means that the engine will have to be turned off during the beginning of theflare. In order to avoid forcing a wing to the ground the aircraft should maintainlevel flight and with the ailerons dedicated to keeping the aircraft in level flightthe only means to control the course is with the rudder.

As the airspeed of the aircraft is decreasing the lift of the aircraft will bereduced resulting in a faster descent until the aircraft touches the ground. Duringthis phase the autopilot should try to maintain a desirable touchdown pitch.

9.3 Approach trajectory

The goal of the approach trajectory is to take the aircraft down from high altitudeand smoothly transition to a lower descent rate in preparation for touchdown.Not too much effort was planned for this step as it seemed like a solved problem

38 9 Design

with many solutions available from other areas, such as splines that is heavilyused in computer graphics.

The landing controller decides what inputs and what outputs are needed fromthe approach trajectory. The parameters used that are relevant for the approachtrajectory are the speed difference between the current and desired airspeed andthe altitude difference between the current and desired altitude. For the fuzzycontrollers the altitude difference is measured at the current position of the air-craft while the pitch lookahead solution will calculate the difference between thecurrent altitude and the desired altitude where the aircraft is expected to be inthe future.

For this two popular spline algorithms used in computer graphics was tar-geted, the Bézier curve and the Catmull-Rom spline (section 4). Both splines willallow the desired altitude to be calculated anywhere along the spline at any time.For the pitch lookahead approach the controller allows for a simpler trajectoryto be used since the lookahead solution doesn’t care about evaluating the desiredaltitude at the current position but only cares about the desired altitude in thefuture, this is described in section 9.3.1.

The target trajectory is a very simple trajectory consisting of two stages. Thefirst stage is concerned with reducing the altitude over ground as much as possi-ble and the idea of the second stage is to reduce the descent rate in preparationfor the touchdown. A simple rough outline of the desired trajectory is illustratedin figure 9.2, the outline illustrated can be generated from four control pointsconnected by straight lines. The simplicity of the rough outline has some desiredproperties, it is easy to adjust the slope and altitude of the trajectory by adjust-ing the control points. This is desired because the parameters that make up thetrajectory may change during a flight (by the operator). Additionally the aircraftshould preferably not be required to line up with the starting point exactly to en-sure a smooth transition to the beginning of the trajectory. The sharp transitionsbetween the segments in figure 9.2 makes it a less than ideal trajectory and thegoal of the algorithms presented in this section is to take this rough outline as aninput and generate a smooth trajectory that is suitable as guide for a fixed wingaircraft. Since the desired trajectory could change in flight the spline must beable to be generated on the fly.

9.3.1 Pitch lookahead

An alternative to the spline algorithms is an algorithm that, based on a very sim-ple trajectory consisting of a couple of straight lines (similar to the rough outlinein figure 9.2), calculates where the aircraft should preferably be on the trajectoryin x seconds at the current speed and aiming the aircraft towards that point. Thisalgorithm will cut the corners of the specified trajectory. During the most criticalstages of the trajectory, where the aircraft is close to the ground, any corner cut-ting will only increase the altitude margin over the ground and is because of thatnot considered to be a problem.

9.4 Approach/Descend trajectory 39

Ground

Level flight

First stage

Second stage

Touchdown

Figure 9.2: Rough outline of a basic approach trajectory.

9.4 Approach/Descend trajectory

In order to hit a desired touchdown point two main approaches were considered.One could either optimize for a specified descend ratio relative to the headwindor one could optimize for a specified descend ratio relative to the ground. In thecase of the EasyPilot , which doesn’t have a real sense of the wind direction orspeed, a descent ratio relative to the headwind would have to rely on the differ-ence between ground speed and air speed as a measurement of the headwind.

Both have their advantages and disadvantages. When optimizing the descendratio relative to the headwind the touchdown point will depend on the accuracyof the headwind measurement, also any steady state error will accumulate overtime and may potentially shift the touchdown point significantly.

Optimizing for the descend ratio relative to the ground speed will unavoid-ably affect the throttle and angle of attack of the aircraft. The resulting trajectorymight also be much longer than what is needed since any headwind will reducethe rate of descend.

Initial tests in the simulator confirmed that optimizing the descend ratio rela-tive to the headwind resulted in a constant drift, as a consequence of the steadystate error, during the approach. All the attempts made to get the aircraft tohit the desired touchdown point failed, with the error only increasing as the ap-proach was extended.

As a result the focus has been on regulating the descend ratio relative to theground speed and, in the late stages of a landing, disregard the trajectory in favorof preparing the aircraft for touchdown. The hope is that the aircraft will nothave time to drift too much during the flare.

40 9 Design

9.5 Keeping the aircraft on track

During the descend the aircraft must not drift too much away from the desiredtrack, especially during a runway landing where the consequences of missing therunway can be severe. The main source of information about the aircraft positioncomes from the GPS. Keeping the aircraft on a desired track has already beensolved by the EasyPilot when flying regular missions; if the existing solution isgood enough to meet the requirements there isn’t much motivation to come upwith something else.

However, the existing code for navigation has some unfortunate, in a land-ing context, properties. The navigation puts a greater emphasis on targeting awaypoint than following a line. The further away from the targeted waypointthe aircraft is the more freedom the aircraft has to move about and the closer theaircraft is to the waypoint the more aggressive the navigation algorithm becomes.

Problems with this approach is that it can be difficult tune and understandwithout experience and specifically for landing missions the fact that the currentalgorithm becomes more aggressive the closer the aircraft is towards a given way-point presents a number of problems. Ideally you would want the aircraft tofollow the desired track as closely as possible during the whole descend.

The issues with the current tracking algorithm in a landing context was enoughincentive for looking at alternative solutions. An alternative solution was to sim-ply utilize the same lookahead algorithm conceived for the altitude trajectory(section 9.3.1). Instead of using a lookahead algorithm to get a desired pitch thesame idea could be used to calculate a desired heading. The lookahead algorithmwould behave in the same way regardless of the distance towards the trackingwaypoints as well as being easier to tune even with no previous experience.

9.6 Takeoff Controller

The goal of the takeoff controller is to gain altitude as fast as possible in a con-trolled fashion. A simple approach to achieve this is to use a fixed throttle whiletrying to achieve a desired airspeed. Any speed excess of the desired airspeedcan be exploited by increasing the angle of attack of the aircraft. An increasedangle of attack will both reduce the airspeed and increase the climb rate. If theairspeed drops the angle of attack can be decreased which will ensure that theairspeed is maintained at the cost of a reduced climb rate.

9.7 Consequences, difficulties and limitations

The late stages of a landing should align the aircraft with the true heading of theaircraft in order to avoid it tipping over after touchdown. The performance ofthe sensor unit, as described in section 6.3.1, presents some difficulties to achiev-ing the desired behavior. As both an accurate heading (section 9.7) and accuratealtitude (section 9.7) are problematic to measure this will most likely set con-

9.8 Stall 41

straints in how much side-wind the controller can deal with during landing. Inthe simulated environment the controller will be blessed with accurate readingsbut care must be taken to ensure that the sensors are good enough for the taskwhen performing flight tests.

HeadingThe EasyPilot has a 3-axis magnetometer that can be used to get the heading ofthe aircraft, unfortunately the data can be a bit unreliable and is susceptible tointerference which makes them tough to rely on. An accurate heading can becalculated from GPS data, a problem the heading data that is calculated from aGPS is that it only takes the aircraft movements into account and not the trueheading of the aircraft. The difference between the true heading and the GPSheading is a function of side-wind and this is of particular importance whenlanding.

The heading also presents problems during takeoff. The GPS heading is notavailable when the aircraft is stationary as well as being unreliable when theaircraft is moving slowly. The aircraft will thus have difficulties knowing theheading in low speeds and is especially vulnerable of misalignment in the earlystages of a takeoff.

Altimeter precisionGetting an accurate reading of the altitude (over ground) is of great importancewhen landing at the same time as being hard to know reliably. The EasyPilothas an absolute pressure sensor as well as GPS height and the control stationhas access to altitude data. The difficulty with GPS height is that it is not thataccurate on the z-axis and the difficulty with the absolute pressure sensor is thatthe pressure can change during the time of the flight, resulting in an offset in thealtitude.

A laser altimeter is used in order to solve the mentioned issues by calibrat-ing the other sensors and smoothly adjusting the landing algorithms to the newinformation.

9.8 Stall

Landing and takeoff presents many challenges that relate to how to avoid stallingand how to exit a stall. As noted in section 3.1 the stall characteristics vary greatlyfor different aircrafts and finding a way to detect or exit a stall that is somewhatindependent of the aircraft used is considered to be a tough problem with no clearsolution. A serious evaluation of the problem is considered outside the scope ofthis thesis and the goal is to design a controller with enough margins that stallingwill not occur rather than trying to detect and/or exit a stall if it were to happen.

In order to mitigate the consequences of a stall the controller will have theability to swiftly abort (section 9.10) a landing if the operator detects that a stall,or any other danger, is imminent. If the controller have difficulties maintaining

42 9 Design

its flight trajectory during landing this might be an indication that a stall is im-minent, if a retry (section 9.10) is automatically triggered the autopilot could bedesigned as to be able to increase the margins of angle of attack and airspeed inorder to avoid a potential stall.

9.9 Operator

The operator must be able to control the aircraft and initiate a landing or take-off. The aircrafts are controlled through SkyView GCS , a ground control stationapplication developed by ICS . For each landing the information that an opera-tor needs to specify is, in the simplest case, the desired touchdown location anddirection. For a hand thrown takeoff only the direction needs to be specified.

A mission in SkyView GCS contains one or several routes and each route isdefined by waypoints. It seemed prudent to implement the takeoff and landing asroutes in SkyView GCS , especially considering that the STANAG 4586 standard,which SkyView GCS follows, has defined special landing and takeoff route types.To convey the needed information the waypoints in a landing or takeoff contextmust be setup to convey the necessary information.

9.9.1 Landing

Information for the landing requires two waypoints. One to specify the desiredtouchdown point and another to specify the direction. To help the operator to getan idea of how much distance the landing preparations require a third waypointis generated where the descent begins. For the operator this means that a landingroute consists of at least three waypoints.

The last two waypoints are set to the ground altitude, this altitude is fetchedwhen calibrating the aircraft before launch, and the third to last waypoint is setto the start altitude over ground specified for the aircraft. Any waypoints beforethe last three will remain untouched and the aircraft can be commanded to anyof them. If the aircraft is commanded directly to one of the last two waypointsthe aircraft is redirected to the third to last waypoint.

A landing route overlayed on a map from SkyView GCS is illustrated in fig-ure 9.3.

9.9.2 Takeoff

The information for the takeoff also requires two waypoints. The first waypointspecifies the starting point for the takeoff and the second specifies the directionfrom the starting point. To help the operator to get an idea of how much distancea launch requires the second waypoint is moved, in the specified direction, tothe maximum distance expected for the takeoff. The maximum distance is notcalculated based on the prevailing conditions at launch since it depends on vari-ables not known at the time of planning or even takeoff (such as wind speed). Themaximum distance is based upon the minimum expected climb rate that the vehi-cle has specified, using the minimum expected climb rate the maximum expected

9.9 Operator 43

Figure 9.3: Landing route as presented in SkyView GCS. Waypoint 2through 6 makes up a landing route where waypoint 4 marks the begin-ning of the descend, waypoint 5 marks the desired touchdown point andwaypoint 6 defines the direction of the landing from the desired touchdownpoint.

takeoff distance can be calculated. This will give the operator an idea of how longthe takeoff distance is at the most. When the aircraft reaches the desired altitudeit will start loitering and awaiting any new commands from the operator.

When the launch has been initiated the first waypoint is moved to the currentposition of the aircraft; this to ensure that the operator don’t have to care aboutthe exact launch point and that the transition to the desired heading is as smoothas possible. The launch route can also be generated automatically internally onthe aircraft; the first waypoint is generated when the launch is initiated, the sec-ond waypoint is generated when the aircraft has traveled some specified distancefrom the starting point and gained some specified altitude from the starting point.This avoids that the waypoints end up too close too each other and ensures thatan accurate heading can be produced

Until the aircraft reaches the second waypoint it will fly blindly, trying tokeep the aircraft as steady as possible and only target a heading once the secondwaypoint has been generated. The automated approach is more hazardous since abad launch might steer the aircraft slightly before the second waypoint has beengenerated, this will affect the position of the second waypoint which the aircraftwill follow for the remainder of the launch. Thus if there are obstacles nearby atakeoff route is preferred since it will ensure that the aircraft does not veer toofar off the specified course.

44 9 Design

Problem ActionToo far off from thetrajectory.

Adjust the trajectory and try again, make surethat the adjusted trajectory is still within thebounds of the specified landing area.

Air speed too high. The landing parameters probably needs to befine tuned.

Ground speed too high. If the air speed is within acceptable boundsthis is an indicator of tail wind, possible solu-tion is to retry and land in the opposite direc-tion.

True heading and thedirection of travel differtoo much.

There is most likely too much side wind, ro-tate landing route or land manually.

Heading, pitch or rollerror exceeded duringflare.

Hopefully this was just due to a wind gustbut if not the aircraft might have to be landedmanually.

Can’t find ground withaltimeter.

Lower the trajectory and try again.

Table 9.2: Abort conditions and possible actions.

9.10 Retry and abort conditions

Considering the consequences of a failed landing it would be desirable if the con-troller could detect and abort a bad landing before touchdown. The criteria foraborting a landing will depend on the specific aircraft used as well as the landingarea. An aborted landing could be retried, possibly with changed parameters. Anabort could make use of the takeoff controller to quickly gain altitude and thenstart to loiter, awaiting new commands from the operator.

Time constraints didn’t allow for them to be implemented but a few possibleretry and abort conditions have been identified and is presented in Table 9.2.Ultimately the operator has the last say and must supervise the whole flight.

10Implementation

The designs in section 9 that have been implemented are presented in this chap-ter. If not stated otherwise everything described has been developed in the Cprogramming language for the EasyPilot .

10.1 Fuzzy logic

Following the ideas mentioned in section 9.1 some effort has been spent on mak-ing the implementation easy to adapt. With the use of function pointers andenumerations that represent different supported methods it has been ensuredthat adding to and extending any part of the fuzzy inference system is straightforward. This to allow for different designs to be tested as well as allowing meth-ods to be added later on to support new types of systems. The implementationwas focused around the Mamdani fuzzy inference system.

The following sections follows the background on fuzzy logic (section 2) andtreats the implementation details worth mentioning.

10.1.1 Membership functions

The implemented membership functions are the triangle and the trapezoid mem-bership functions, both have been defined as a number of points. The triangleis made up of three points, two of which must be on the x-axis and the thirdspecifies where the top should be. The third point must be in between the othertwo points on the x-axis. The trapezoid membership function is made up of fourpoints, two points must be on the x-axis and the other two specify where the toppoints should be. The points on the x-axis must encompass the other two points.

Each point is defined and stored from low to high values on the x-axis and theheight of the triangle and trapezoid membership functions is fixed. This means

45

46 10 Implementation

that each point can be completely defined by the x-value, since the y-value canbe entailed by the order of the points. If different slopes/heights of the mem-bership functions are desired the whole membership function can be scaled bya constant factor. The membership functions and the points that make them upare illustrated in figure 10.1.

P0

P1

P2 P0

P1 P2

P3

Figure 10.1: The triangle and trapezoid membership functions.

10.1.2 Aggregation

Of the alternatives mentioned in section 9.1.1 integration and the custom algo-rithms was implemented. Integration was first implemented because it was sim-ple and allowed for some early tests. The integration implementation also pro-vides a reference point for any other algorithm tested.

The aggregation step combines the output from the fuzzy implication step foreach of the fuzzy rules using the aggregation method. The process is detailed,using the max aggregation method, in figure 10.2.

10.1.2.1 Mamdani custom algorithm

The custom Mamdani aggregation algorithm tries to take advantage of the con-straints listed in section 9.1.1.2. Those constraints as well as other identifiedconstraints related to the implementation are:

• The memberfunctions must either be a triangle or a symmetric trapezoid(as descriped in section 9.1.1.2)

• At most two memberfunctions can overlap for any value on the x-axis andno memberfunction can be completely within another

• Memberfunctions must not overlap beyond the middle-point

• The memberfunctions must be stored in ascending order on the x-axis

The custom aggregation algorithm treats the result from the implication stepas a series of lines. The contribution from a triangle can be constructed out of two

10.1 Fuzzy logic 47

Ilustration of the input to the aggregation step.

Ilustration of the output of the aggregation step.

Figure 10.2: Illustration of the aggregation step using the max aggregationmethod.

lines and a trapezoid can be constructed out of three lines (this can be realizedby looking at figure 10.1).

Iterating all lines, from the first (lowest value on the x-axis) to the last eachline is tested for intersections. At the point of each intersection a new point is gen-erated and the path with the greatest contribution is preserved when proceeding.The purpose of storing the output membership functions in order of appearance(from low to high on the x-axis) is to be able to traverse all lines in sequentialorder quickly and at the same time reduce the search space drastically when look-ing for intersection points. The result of the custom aggregation algorithm isillustrated in figure 10.3.

The performance of the custom aggregation methods mainly depends on thenumber of output membership functions. One key aspect of the custom aggrega-tion method is that the aggregation result consists of points that are based on theintersections from the implication step. This is thus the optimal representation,in terms of number of points, of the aggregation result and has the potential toboth speed up the defuzzification step significantly and being more precise whencompared with the result from the integration method.


Generated point Generated point

Figure 10.3: The result of the custom aggregation method is marked in black.

10.1.3 Defuzzification

Based on the literature and similar projects only the x-axis centroid method wasimplemented for the Mamdani fuzzy inference system.

The defuzzification implementation is the same regardless of whether the inte-gration or custom aggregation algorithm is used. The result from the aggregationstep is treated as a set of points. Two points make up a segment and the centerof gravity and mass calculations are done by first dividing each segment into atriangle and a rectangle, which is illustrated in figure 10.4.

X0 X1

P0

P1

T

R

Figure 10.4: Creating a segment from two points and dividing the segmentinto a triangle and a rectangle.

The center of gravity calculation of the triangle can be simplified a lot whennoting that the it is only the center of gravity on the x-axis that is of interestand that the triangle will always be a right triangle. With those observations theequation for the center of gravity on the x-axis is shown in equation 5.

y(x0) < y(x1) : cogx(T ) = x0 + Tbase/3

y(x0) > y(x1) : cogx(T ) = x0 + 2 ∗ Tbase/3

Equation 5: Center of gravity on the x-axis for triangle T . See figure 10.4 forreference.

10.2 Landing controller 49

Combined with the rectangle the center of gravity for rectangle R and trian-gle T is shown in equation 6. Similarily the center of gravity for all segmentscombined is calculated with help of equation 7.

The process is illustrated in figure 10.5, note that the custom aggregationmethod results in far fever points to consider which will speed up the calcula-tions significantly.

cogx(S) = x0 +cogx(ST ) ∗ area(ST ) + cogx(SR) ∗ area(SR)

area(ST ) + area(SR)

Equation 6: Center of gravity on the x-axis for segment S with triangle Tand rectangle R. See figure 10.4 for reference.

cogx(tot) =

n∑i=1

(coxx(Si) ∗ area(Si))

n∑i=1area(Si)

Equation 7: The combined center of gravity on the x-axis for n segments.

Result from integration method. Result from custom method.

Figure 10.5: Illustration of of the segments needed to consider during de-fuzzification after aggregation with integration and the custom aggregationmethod.

10.2 Landing controller

10.2.1 Approach controller

For the approach controller two different sets of fuzzy rules were settled uponafter testing different behaviors in the simulator. Both controllers are based on


Altitude Airspeed VL ML ZO MH VH

VL ZO VH ZO VH ZO VH VH VH VH VH

ML ZO MH ZO MH ZO MH MHMH MHMH

ZO ML ML ML ML ZO ZO MHMH MHMH

MH VL VL VL VL ZO ML ZO ML ZO ML

VH VL VL VL VL ZO VL ZO VL ZO VL

Table 10.1: Landing fuzzy rule set: Regulate altitude with the throttle andairspeed with the desired pitch. Each column corresponds to a differencebetween the actual and desired airspeed from Very Low to Very High. Simi-larly each row corresponds to a difference between the actual and the desiredaltitude. Each cell (outside of the row/column headers) corresponds to theoutput of the rule. The bottom left output of each cell corresponds to thethrottle output and the top right output corresponds to the desired pitchoutput. Abbreviations used is described in Table 10.3.

Altitude VL ML ZO ML VL

Throttle output VH MH ZO ML VLTable 10.2: Landing fuzzy rule set: Regulate throttle after altitude and keepa fixed pitch. Abbreviations used is described in Table 10.3.

techniques used in large aircrafts controlled by human pilots and is describedfurther in section 9.2.1.

The first set of rules tries to regulate the altitude with the help of the throttleand the airspeed with the help of the pitch of the aircraft and is described inTable 10.1. The second set of rules tries to keep a constant pitch and regulatesthe descend rate with the throttle and is described in Table 10.2.

10.2.2 Flare

Following the design in section 9.2.2 the flare relies heavily on the inner controlloops to keep the aircraft stable. When the flare is initiated the engine is turned

Abbreviation DescriptionVL Very LowML Medium LowZO ZeroMH Medium HighVH Very High

Table 10.3: Fuzzy rule set abbreviations and descriptions.

10.3 Approach trajectory 51

off and the inner loops are commanded to keep a configurable pitch and keep theaircraft level with the ground. The rudder tries to keep the aircraft aligned withthe runway, since the ailerons will not be used to guide the aircraft a differentset of parameters for the inner loop rudder controller was implemented for useduring the flare.

10.3 Approach trajectory

All of the designs proposed has been implemented, the reasoning for implement-ing all designs was to be able to compare them with each other. Since the shape ofthe approach trajectory is based on parameters suitable for a particular aircraftit was of importance to make sure that the trajectory would not misbehave forany reasonable parameters. Ultimately being confident about the behavior in allscenarios was the biggest deciding factor between the designs.

All designs were first implemented in matlab for evaluation and then imple-mented in C on the autopilot.

10.4 Lookahead

The lookahead algorithm was implemented both for regulating the heading ofthe aircraft as well as the desired pitch of the aircraft. The calculation of the de-sired heading and the desired pitch are done separately, mainly to keep it simpleand since not all landing algorithms make use of the lookahead algorithm whencalculating the desired pitch.

When calculating the desired heading this means that the difference in al-titude between the aircraft and the lookahead point are not taken into account.Similarly when calculating the desired pitch the aircraft is assumed to be right be-neath or on top of the desired trajectory. A consequence of this approach is thatthe resulting lookahead distance can be a bit longer than expected (since onlytwo dimensions are taken into account when calculating the lookahead distance).This will result in more gentle changes to the produced outputs for when the air-craft has drifted a long way from the desired trajectory. For a typical approachthe differences should be much smaller than the desired lookahead distance so itshould not affect the performance in any significant way.

The algorithm works by taking the current speed and multiplies it with thelength of the lookahead (in seconds), this results in a distance, denoted by d. Theapproach trajectory is traversed from the current position (the position on thetrajectory that is the closest to the aircraft) and distance d in the landing direction.The desired pitch or heading is calculated as the pitch or heading required for theaircraft to hit the lookahead point from the current position of the aircraft.

The algorithm is shown in equation 8 and is illustrated in figure 10.6.


α

Lookahead length, d

Trajectory

Lookahead point

Closest point on the trajectory

Parallell to the ground

Figure 10.6: Illustrating the lookahead algorithm.

Airspeed VL ML ZO MH VH

Pitch output VL ML ZO MH VHTable 10.4: Takeoff fuzzy rule set: Simple rule set where the input is theairspeed of the aircraft output is the desired pitch level. Abbreviations usedis described in Table 10.3.

desired_pitch = α = atan2(lookahead_agl − aircraf t_agl, d)

Equation 8: The equation used to get the pitch towards the lookahead point(agl = altitude over ground).

10.5 Takeoff controller

The demands for the takeoff controller doesn’t require the same type of precisionthat is desirable in a landing controller. The fuzzy controller described here wasthe simplest that could be imagined, with the intent of extending it and develop-ing further where it was deemed necessary. The idea behind the takeoff controllerimplemented is to use a fixed throttle, typically max or close to max throttle, andadjust the pitch after the airspeed. If the airspeed is greater than a configurabledesired speed the pitch of the aircraft is increased. This results in a greater as-cend rate and at the same time a reduced airspeed. If the airspeed drops thepitch is lowered which in turn should increase the airspeed. The initial rule setfor the fuzzy controller is presented in Table 10.4.

From the perspective of the operator two ways of initiating a takeoff was im-plemented. One where the operator would upload a launch mission consisting oftwo waypoints. The first waypoint to indicate the starting position and the sec-ond to indicate the direction of the launch. For the sake of not having to launchexactly where the first waypoint was placed and to avoid mishaps the autopi-lot moves the first waypoint to its current GPS position of the aircraft when thelaunch is initiated. The other way to initiate a launch would be to do a blind

10.5 Takeoff controller 53

launch. The operator would just initiate the launch and throw the aircraft. Simi-larly to the two waypoints in the launch mission the aircraft would create the firstwaypoint where the hand launch was initiated and the second waypoint after aconfigurable distance had been traveled. The idea being that the aircraft wouldkeep a straight enough line in the beginning of the launch and then continue onstraight.

In addition to the fuzzy controller there were a few edge cases related to thetakeoff that needed special consideration. The very low airspeeds at the momentof the launch motivated the use of an offset on the elevator to ensure that theaircraft could maintain a proper pitch level. For the sake of simplicity a simpleoffset that was linearly reduced as the airspeed was increased was proposed tobegin with.

There was also some concerns regarding maintaining the course of the air-craft. As the primary source of heading for the aircraft is GPS and movement isrequired to get a heading from the GPS. In addition the heading taken from GPScoordinates reported during standstill or low ground speeds can vary a lot andlack precision it was decided to not bother with the exact heading of the aircraftin the very beginning of the launch.

The reasoning above in combination with that in the first stage of the takeofflift is crucial motivated the landing controller to keep a fixed roll level. Thisincreases the risk that the aircraft gets off course but considering we don’t havean accurate view of it’s heading and that any roll would decrease the potentiallift of the aircraft the risk felt justified.

The roll is fixed until two parameters have been fulfilled. The first of whichensures that the aircraft has reached a configurable altitude, in order to maxi-mize lift and avoid banking close to the ground. The second that the aircraft hastraveled a configurable distance, so that we can get an accurate heading in rela-tion to the launch point. The second parameter also implies that we have someconfidence that the airspeed is large enough. When both parameters have beenexceeded the aircraft will start navigation and follow the takeoff direction.

Lastly, the takeoff controller still utilizes the inner loop controllers and it wasfeared that the integral parts of the PID-controllers would wind up too muchduring the first stage of the launch. Thus it was decided to reset the integral partof the inner loop controllers for the first part of the takeoff, they would not havetime to stabilize anyway so the takeoff could never be allowed to rely on them inthe first place.

11Results

Even though different aircrafts have different characteristics and requirementsthe measurements can be evaluated against the desired properties and can thusbe a used as a means to compare different solutions. Note that the interpretationof deviations, especially during flight tests, will often have to be subjective. Awind gust will unavoidably affect the aircraft and the actions taken by the con-troller in absence of accurate wind data is hard to evaluate objectively as wellas compare to other test runs on paper. A subjective interpretation by someonewith flight experience is believed to be accurate enough for both evaluation andcomparison, especially in conjunction with test data.

11.1 Execution performance

Some effort has been spent on quantifying the resources used by the controllers.The resources targeted have been processor utilization and memory usage on theautopilot. The methodology for measuring memory consumption is described insection 11.1.1, and similarly section 11.1.2 deals with processor utilization.

The results of the measurements are presented in section 11.1.3 along withsome notes about their interpretation.

11.1.1 How the memory performance was measured

In C the memory consumption can be divided into the stack and heap and mea-suring them can be a bit tricky.

The stack usage was investigated in two ways. The first way was to make useof inbuilt functions in the gcc compiler used. Adding the parameter −f stack −usage produces information about each function and, where available, its stackusage. This doesn’t tell the whole picture, it can only calculate the stack correctly

55

56 11 Results

when the stack allocations are statically allocated and while this is common itcan also only calculate the usage for each function individually. There is still theproblem knowing which functions call which and the maximum call depth.

The other way the stack was calculated was by declaring a variable in themain function, the address of this variable was used to get the starting pointof the stack. Immediately afterwards the memory allocated for the stack wascleared (filled with zeroes) followed by the execution of a normal mission on theautopilot. The stack memory used was calculated by looking at a memory dumpof the stack and see how much of the data was untouched. Isolating the stackusage only used by the landing controller would be quite time consuming andit was not considered important enough to pursue, the main point of calculatingthe memory consumption was to ensure that the usage was within acceptablebounds and that no nasty surprises would arise from memory overconsumption.

The heap was calculated, for the landing controller, by wrapping all of thefunctions that was used to allocate memory on the heap with functions that alsokept track of how much requested memory was used. This was only done for thefuzzy controllers, memory allocated on the heap for the rest of the autopilot wasnot considered.

11.1.2 How the execution performance was measured

The EasyPilot is configured to have an interrupt that fires once every millisecond,this interrupt is used to calculate the execution time by counting the occurrenceof the interrupt during relevant parts of the code. One problem with this ap-proach is precision, for many of the relevant parts a millisecond is a very coarsemeasurement. To combat this and to be sure that the measured values are typicaleach measurement is performed many times before calculating an average.

11.1.3 Execution performance measurements

Memory consumption for a fuzzy logic controller with 50 rules and the pitchlookahead controller in a landing context is presented in Table 11.1. The stackusage has been calculated following the methodology in section 11.1.1 where thememory area of the stack is investigated. As a base a regular mission on the au-topilot was performed, when initiating a landing the change in stack utilizationwas examined. That the stack usage in Table 11.1 indicates 0 bytes means thatthe area used by the stack did not increase as a result of initiating and perform-ing a landing; not that the stack usage itself was 0 bytes. Though memory con-sumption often is a scarce resource it can be noted that the fuzzy controllers aremostly within acceptable bounds, the variants utilizing integration indicates thatit doesn’t scale too well. Some care might be needed if the controller is extendedwith more rules and or outputs.

The execution time for the same controllers is present in Table 11.2. As ex-pected the lookahead algorithm requires much less processing time and that thecustom fuzzy aggregation method is indeed quicker than the variants utilizing in-tegration. The performance gaps will only increase as more rules and/or outputs

11.2 Flight performance 57

are added. Though as with the memory consumption all algorithms are withinacceptable bounds. However, the integration algorithm has less margins and con-sequently has a bigger impact on what else the autopilot can attempt to processat the same time.

ControllerExtended*stack usage

Maxheap usage

Fuzzy integration 50 steps 0 bytes 3936 bytesFuzzy integration 100 steps 0 bytes 5536 bytesFuzzy integration 200 steps 0 bytes 8736 bytesFuzzy custom algorithm 0 bytes 2976 bytesLookahead 0 bytes 0 bytes

Table 11.1: Memory consumption for the fuzzy logic and lookahead con-trollers.* See section 11.1.3 for details.

Controller Execution timeFuzzy integration 50 steps 8.61 msFuzzy integration 100 steps 14.4 msFuzzy integration 200 steps 25.8 msFuzzy custom algorithm 3.10 msLookahead 0.161 ms

Table 11.2: Time to perform one iteration of the fuzzy logic and lookaheadcontrollers.

11.2 Flight performance

Following is data and interpretations from simulations and real world flight tests.A note about the approach trajectory; looking at the results it becomes clearthat the second stage of the approach trajectory, as outlined in figure 9.2, is notpresent in the real world flight tests. This reason for this was to shorten the re-quired approach, the slower descend rate of the second stage was not deemednecessary for the landings presented here.

11.2.1 How the performance was measured

The goal of the approach trajectory is to align the aircraft with the runway andmake sure that the touchdown is within acceptable bounds. The results of sim-ulation and real life flight tests are presented section 11.2.2 and section 11.2.3.The reasoning for the measurements used is described in section 7.1.1.

58 11 Results

0 50 100 150 200 250 300 350 400 450 500 550−15.0

−10.0

−5.0

0.0

5.0

10.0

15.0

20.0

25.0

30.0

Samples

Units

Simulation

0.0

10.0

20.0

30.0

40.0

50.0

60.0

70.0

80.0

90.0

100.0

110.0

AGL[m

]

AGL [m]

Ground Speed [m/s]

Airspeed [m/s]

Pitch [degree]

Vertical Error [m]

Speed Error [m/s]

Figure 11.1: Simulated landing with fuzzy logic controller regulating thethrottle and pitch.

All of the measurements have been collected with the on board sensors on theEasyPilot , while those might not align perfectly with the real world it’s also thesame data that the takeoff and landing controllers have access to.

11.2.2 Landing simulation results

The results of the simulations were inspiring, tuning was straight forward andeach controller could easily be tuned to produce excellent results. Subjectivelythe responsiveness of the algorithms seemed excellent and although it’s hard toexpect as good results in the real world the algorithms do what they were de-signed to do and shows promise.

Simulated landing with throttle and pitch fuzzy controllerfigure 11.1 depicts a landing with the fuzzy controller that regulates the throttlebased on an altitude error and the desired pitch based on an airspeed error. Thegraph shows, when stabilized, a vertical error of about 0.85m and a speed error ofabout 0.6m/s during the first part of the descend and well below 0.1m and 0.1m/srespectively for the second part of the descend.

Simulated landing with fixed pitch fuzzy controllerfigure 11.2 depicts a landing with the fuzzy controller that regulates the throt-tle based on an altitude error and tries to maintain a fixed pitch. The graph


0 50 100 150 200 250 300 350 400 450 500−15.0

−10.0

−5.0

0.0

5.0

10.0

15.0

20.0

25.0

30.0

Samples

Units

Simulation

0.0

10.0

20.0

30.0

40.0

50.0

60.0

70.0

80.0

90.0

100.0

110.0

AGL[m

]

AGL [m]

Ground Speed [m/s]

Airspeed [m/s]

Pitch [degree]

Vertical Error [m]

Speed Error [m/s]

Figure 11.2: Simulated landing with fuzzy logic controller regulating thethrottle.

illustrates some oscillating behavior to the speed, altitude and the pitch of theaircraft. This behavior was hard to get rid of and is most likely because of theaircraft used for the simulations. The pitch of the simulated aircraft is severelyaffected by the throttle. To combat this effectively it is probably needed to feedforward the throttle and reduce the desired pitch when increasing the throttle.There didn’t seem to be much point in trying to address peculiarities in the simu-lator and even with the oscillations the controller typically kept the vertical errorwithin 1m and within 1m/s. The oscillating behavior shown is not believed to bepresent for the aircrafts considered for this work and the results still shows somepromise.

Simulated landing with pitch lookahead controllerfigure 11.3 depicts a landing with the pitch lookahead algorithm. When stabi-lized this shows a very low vertical error of at worst about 0.3m and a speed errorof no more than 0.1m/s.

11.2.3 Landing real world results

Unfortunately, the real world flight tests didn’t perform as well as the simula-tions. Most of the landing controllers were not able to adequately follow thelanding trajectory regardless of tuning. There were several issues, one of the ma-jor was controlling the airspeed. The real world flight tests introduced a much

60 11 Results

0 50 100 150 200 250 300 350 400 450 500 550−15.0

−10.0

−5.0

0.0

5.0

10.0

15.0

20.0

25.0

30.0

Samples

Units

Simulation

0.0

10.0

20.0

30.0

40.0

50.0

60.0

70.0

80.0

90.0

100.0

110.0

AGL[m

]

AGL [m]

Ground Speed [m/s]

Airspeed [m/s]

Pitch [degree]

Vertical Error [m]

Speed Error [m/s]

Figure 11.3: Simulated landing with the lookahead algorithm.

greater lag between throttle and increased airspeed as well as the effect of throt-tle increase or decrease were significantly weaker than in the simulator. This isfurther aggravated by the airspeed sensor on the EasyPilot which was not thatresponsive. Another difference between the simulation and real flight tests wasthat the pitch was affected by the commanded throttle in the simulated aircraft,this magnifies the effects of using the throttle as a means to regulate the altitude.

The inner loop throttle controller also presented some problems, the landingcontrollers didn’t control the throttle but rather the desired airspeed and lettingthe internal throttle controller handle the rest. Tuning the throttle controllerto be both adequate for cruise speeds and landing speeds was difficult and es-pecially ensuring that the controller responded quickly enough when used as ameans of regulating the altitude.

These problems were realized during initial testing on the Spy Owl 100 . Con-sidering the nature of the difficulties it was predicted that the better lift to dragratio of the Spy Owl 200 would only make matters worse. This was enough mo-tivation for pursuing the lookahead alternative. In the lookahead alternative thethrottle controller only tries to maintain a fixed airspeed, it would thus not beas sensitive for deviations and it would have much longer time to stabilize itselfduring the descent. Any errors introduced by side wind would be small enoughto be secondary to the risks associated with landing the aircraft at an angle.

Spy Owl 100 landing with throttle and pitch fuzzy controllerfigure 11.4 depicts a landing of the Spy Owl 100 with the fuzzy controller that


0 20 40 60 80 100 120 140 160 180−10.0

−5.0

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

40.0

Samples

Units

Spy Owl 100

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

40.0

AGL[m

]

AGL [m]

Ground Speed [m/s]

Airspeed [m/s]

Pitch [degree]

Vertical Error [m]

Speed Error [m/s]

Figure 11.4: Spy Owl 100 landing with fuzzy logic controller regulating thethrottle and pitch.

regulates the throttle based on an altitude error and the desired pitch based on anairspeed error. The aircraft is constantly below the desired trajectory with about3 ± 1m and the speed error is about ±2m. The experiences tuning this controllerwere a bit difficult and it was not as responsive to disturbances as one could havehoped.

Spy Owl 100 landing with pitch lookahead controllerfigure 11.5 depicts a landing of the Spy Owl 100 with the pitch lookahead algo-rithm. The aircraft again keeps itself below the desired trajectory but with greateraccuracy, about 0.5 ± 0.5m. The speed error also improved to about ±0.75m/s.The flare starts at sample 238 at which point the vertical error isn’t valid any-more. When close to the ground the engine is also reduced and this is at thepoint where speed error is dropped from the graph. By the time this flight wasperformed the confidence for the laser altimeter had increased and the flare hadbeen lowered, it is not nearly as easily detected in the graph but it is initiated atsample 238. The sudden change in the vertical error at sample 233 is because ofsudden change in the values from the altimeter.

Spy Owl 200 landing with pitch lookahead controllerfigure 11.6 depicts a landing of the Spy Owl 200 with the pitch lookahead algo-rithm. Similarly to Spy Owl 100 the aircraft held itself below the desired trajec-tory with about 0.5 ± 0.5m. The speed error however were a bit worse, steadily

62 11 Results

0 25 50 75 100 125 150 175 200 225−10.0

−5.0

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

40.0

Samples

Units

Spy Owl 100

0.0

5.0

10.0

15.0

20.0

25.0

AGL[m

]

AGL [m]

Ground Speed [m/s]

Airspeed [m/s]

Pitch [degree]

Vertical Error [m]

Speed Error [m/s]

Figure 11.5: Spy Owl 100 landing with the lookahead controller.

increasing from −2m to 2m/s. This is partly because the inner loop controllerswas not as fine tuned on the Spy Owl 200 as the Spy Owl 100 . Before the de-scend begins the aircraft performs a quick turn and the Spy Owl 200 lost a lotof airspeed from the turn. This wound up the integral of the throttle controllerwhich in turn, during the descend, made the aircraft slowly overshoot the desiredairspeed.

Compared to the fuzzy controllers the pitch lookahead algorithm was moreresponsive to errors in altitude compared to the trajectory.

Horizontal distanceExample data of the horizontal distance from the desired trajectory from a land-ing with the Spy Owl 100 is presented in figure 11.7. From the point of view ofthe operator this was very satisfactory results. The aircraft didn’t make any sud-den maneuvers and landed where expected. As shown in the figure (figure 11.7)the aircraft starts of being 15m of course. The cause for this is because the air-craft had just performed a u-turn to align for the runway and had not had timeto recover. The large deviation in the beginning shows that the aircraft is a tadbit aggressive and overshoots the desired path a bit. This could be improved bylengthening the lookahead but at the cost of having a larger static error when theaircraft was properly aligned.

The horizontal performance performed consistently and quickly inspired con-fidence to the point where the horizontal distance was dropped from the logs tomake room for other data. When side wind is present the aircraft would incur a


0 25 50 75 100 125 150 175 200 225 250 275 300 325−15.0

−10.0

−5.0

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

Samples

Units

Spy Owl 200

0.0

5.0

10.0

15.0

20.0

25.0

AGL[m

]

AGL [m]

Ground Speed [m/s]

Airspeed [m/s]

Pitch [degree]

Vertical Error [m]

Speed Error [m/s]

Figure 11.6: Spy Owl 200 landing with the lookahead controller.

larger deviation from the path but considering the nature of a fixed wing landingthe horizontal distance is less critical than the vertical distance and was neverconsidered to be a problem.

11.2.4 Takeoff simulation results

Simulating a takeoff in flight gear was not straight forward, the concept of a handlaunch is foreign to FlightGear as it is not designed for small UAVs. Duringdevelopment two ways of testing the takeoff controller was used. The first was tostart the takeoff routine while the aircraft was already airborne. While great fortesting the overall functionality this meant that the takeoff was initiated with amuch higher than realistic airspeed. It did thus not take into account the crucialpart of the controller or make a convincing real life test.

The second method of test was starting directly from the ground. This ex-posed issues that FlightGear had with its physics engine once the aircraft wastouching the ground, causing the aircraft to spin uncontrollably. Though take-offs could be performed while the aircraft was turning the data from the earlystage of the takeoff is not of much use. Since the first stage of the takeoff is themost critical and important part of the takeoff it was not of much help when de-veloping the takeoff controller and consequently it was decided to not includedata from simulated takeoffs here either.

64 11 Results

0 15 30 45 60 75 90 105 120 135 150−5.0

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

Samples

Meters

Spy Owl 100

AGL [m]

Distance from path [m]

Figure 11.7: Horizontal distance (left/right from the UAVs point of view) ofthe Spy Owl 100 from the desired trajectory. The altitude over ground isshown as a reference.

11.3 Trade-off requirements 65

11.2.5 Takeoff real world results

One problem with comparing the flight data from different takeoffs is that thereare lots of external factors that are hard to factor in. This includes the wind butmost importantly the crucial part of the takeoff in a hand launch is impactedby the throw of the aircraft. Subjectively though the controller quickly inspiredconfidence as it consistently and reliably performed the takeoff as designed.

The fears discussed during the implementation (section 10.5) regarding beingable to maintain the pitch and course of the aircraft would seem to be unfoundedin the real world. The aircraft maintains the desired course and does not driftoff during the first crucial stage of the takeoff. The aircraft also maintains a goodattitude throughout the takeoff.

Though the idea was to extend the controller after real life flight tests, this didnot seem necessary since the results were satisfactory once proper tuning was inplace. Subjectively the tuning is fairly straight forward and forgiving, the biggestissue regarding the tuning is probably related to the nature of the takeoff - theaircraft is very close to the ground and if something goes wrong there is not muchtime to recover.

Takeoff with Spy Owl 100Data from a takeoff with the Spy Owl 100 is depicted in figure 11.8. Observingthe pitch of the aircraft one can identify the desire to at all cost preserve andincrease the altitude at the very beginning of the launch. As the altitude and air-speed is increasing the pitch is lowered and focus is given to increase the airspeedbefore increasing the pitch again for the final ascend.

Takeoff with Spy Owl 200Data from a takeoff with the Spy Owl 200 is depicted in figure 11.9. The be-havior of the launch is similar to Spy Owl 100 but there are a few differences tonote. The Spy Owl 200 has a more powerful engine and can afford a steeper andquicker ascend. Despite this, in the very beginning of the launch, it can be notedthat the aircraft begins its ascend later than Spy Owl 100 . From the graph thisis hard to explain, the aircraft tries to and succeeds with maintaining an aggres-sive pitch but the aircraft doesn’t increase its altitude as much as expected. Thisturned out to at least partly be because the acceleration and vibrations duringthe initial stage of the launch affects the gyroscopes (and possible the sensor fu-sion algorithms). The pitch level of the Spy Owl 200 during launch as reportedby the sensors is greater than in reality. Once this has been identified it can besufficiently combated by a larger elevator offset until the aircraft has reached adestined airspeed or altitude.

11.3 Trade-off requirements

Wymore describes the trade-off between performance and cost as trade-off re-quirements. Formulating trade-off requirements will, if done correctly, allow any

66 11 Results

0 25 50 75 100 125 150 1750.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

Samples

Units

Spy Owl 100

0.0

10.0

20.0

30.0

40.0

50.0

60.0

AGL[m

]

AGL [m]

Ground Speed [m/s]

Airspeed [m/s]

Pitch [degree]

Figure 11.8: Takeoff data from a hand launch with Spy Owl 100.

0 10 20 30 40 50 60 70 800.0

5.0

10.0

15.0

20.0

25.0

30.0

Samples

Units

Spy Owl 200

0.0

10.0

20.0

30.0

40.0AGL[m

]

AGL [m]

Ground Speed [m/s]

Airspeed [m/s]

Pitch [degree]

Figure 11.9: Takeoff data from a hand launch with Spy Owl 200.

11.3 Trade-off requirements 67

candidates to be evaluated against the priorities for any given project [15, p. 15].For this thesis a lot of emphasis was being put on a design that was easy to

understand and tune by an operator as well as being easily adaptable to differentaircrafts. Though, in order to even be considered a design must perform reason-ably and inspire some confidence.

As for cost any resource available on the EasyPilot was at disposal as long asthere was enough resources left for the communication, inner loop controllersand other parts of the autopilot that are required for the takeoff and landingcontrollers to be operational. Though all else being equal a design requiring lessresources would of course be desirable, but given the constraint envelope of theEasyPilot hardware utilization was not considered to be a priority.

As an example, the Sugeno fuzzy inference system (briefly described sec-tion 2.2.3) was abandoned as a candidate, even though it had a resource ad-vantage compared to Mamdani, when it was realized that Mamdani was muchbetter suited to the priorities of the project. This was of course under the assump-tion that a Mamdani system was feasible on the targeted hardware to begin with;which was not obvious at the beginning of the project.

For the implemented designs in this project it would appear to be simple toevaluate the trade-off between performance and cost. The lookahead algorithmsprovided the easiest interface for the operator at the same time as requiring theleast resources and still being the most performant design.

12Conclusions

Some conclusions regarding the work done for this thesis is presented in thissection. There is always room for improvements but the most suitable controllersdeveloped for this thesis is still in use well after this thesis was completed. Themost critical aspect of the landing turned out to be controlling the altitude; notnecessarily because it was harder to tune but because the consequences of altitudeerrors was much greater. This stems from the desired approach where the verticalvelocity is much less than the speed of the aircraft; the impact of altitude errorson the distance from the desired touchdown point is thus greatly amplified.

Following is an attempt to answer the questions stated in section 1:

Does the EasyPilot 3.0 have the necessary hardware needed to per-form automatic landing and takeoff of fixed wing aircrafts?

Yes; the reasoning and the results of this thesis suggest that the EasyPilot hard-ware is mostly well suited to perform automatic landing and takeoff of fixed wingaircrafts. The EasyPilot is missing integrated sensors to accurately determine thealtitude over ground as well as the true heading of the aircraft. The former isimportant if accuracy is needed and if last second adjustments are necessary in alanding context; the latter is of particular interest if attempting runway landings.

Since the EasyPilot can be made to make use of external sensors, as exempli-fied in this thesis, these points can be remedied.

Is it feasible to implement fuzzy logic on the EasyPilot 3.0 (and similarembedded systems)?

Yes; though computationally intensive fuzzy logic is feasible to implement onembedded hardware, especially when tailoring the implementation to the con-straints of the given system. Though there are of course practical limitations onpossible designs.

69

70 12 Conclusions

Is fuzzy logic a suitable alternative for implementing landing andtakeoff controllers on embedded systems?

Possibly; with the results of this thesis in mind it might be hard to justify thecost of fuzzy logic controllers; however, it would be a mistake to blindly acceptthat as representative for other implementations. Section 12.1 lists some possiblereasons as to why the designs attempted in this thesis didn’t perform as well asone could have hoped.

12.1 Landing

The problems identified in the flight performance real world results (section 11.2.3)related to the tuning of the fuzzy controllers is discouraging. The biggest benefitsof fuzzy logic touted in the background chapter (section 2) was that the processcould be easily adapted and fine tuned. Especially appealing was the prospectof making use of computing with words and not require that the operator hadspecial knowledge about the inner workings of the landing controller. Thoughit is indeed possible to get good results the tuning turned out to be quite diffi-cult. Good results also resulted in creating an unfortunate and complex couplingbetween the inner loop controllers and the landing controller, something that isparticularly undesirable in a general purpose autopilot.

Perhaps one of the biggest causes for the issues related to the fuzzy controllerswas the overly reliance on the throttle as a means controlling the descend di-rectly. This could partially be explained by the characteristics of the simulatedaircraft. Though completely invaluable during the development the simulatordid not present the same issues or flight characteristics found in the real world.If the issues in the real world had been present in the simulator there would havebeen more time to explore different controllers for the approach.

The much simpler lookahead algorithm on the other hand proved to have sim-ilar performance while at the same time being easier to tune, easier to understandand require fewer parameters to consider.

12.2 Takeoff

The hand thrown takeoff performed good as could be expected and the result-ing fuzzy controller is arguably too simple to warrant the need for fuzzy logic.Though if sticking with the fuzzy controller it could easily be extended if onewants to further differentiate the behavior between low and high altitudes ortake other parameters into account.

12.3 Fuzzy logic

As the performance of embedded systems constantly evolve the performance costof fuzzy logic does not seem to be that prohibitive anymore. Some care will al-

12.4 Systems engineering 71

ways be required when choosing the hardware and when designing the imple-mentation but for many use cases fuzzy logic will be a valid alternative.

As for this thesis fuzzy logic did fall a bit short on some of its other promises.The tuning process turned out to be excessive, which was one of the main sellingpoints. Though this is not necessarily a fault of fuzzy logic, in hindsight there area few things that could have been done differently. For one the fuzzy controllersprimarily looked at larger aircrafts for inspiration. Though the idea was to mimicthe soft touchdown of a manned aircraft this overlooked some of the differencesin characteristics that a smaller UAV exhibit. Especially the overly reliance onusing the throttle as a means to regulate the descend rate was problematic totune.

12.4 Systems engineering

The systems engineering perspective helped to separate goal from implementa-tion. The potential benefits from this was experienced during this thesis wherethe idea for the pitch-lookahead controller for the landing approach was con-ceived from real world experiences. During real world flight tests on the SpyOwl 100 it was discovered that the flight and tuning characteristics of the con-trollers deviated a lot from the simulator. Because of the nature of the difficultiesit was also believed that there was a fair chance that it would only get worse onthe Spy Owl 200 . It was also predicted that the tuning of Spy Owl 100 couldnot easily be transferred to Spy Owl 200 . For these reasons the pitch-lookaheadwas thought up, implemented and tested on both Spy Owl 100 and Spy Owl 200with desirable and expected results.

This might seem like a natural progression in a project consisting of mainlyone person. The benefits should become more apparent on larger projects wheredifferent implementations could be produced by different teams. The systemsengineer could pick up lessons learned in one team and apply them to another.With the groundwork done a new team could be assembled and work in parallelwith the other implementations as well. With a detailed insight but also an un-derstanding of the project as a whole the systems engineer can detect potentialissues and help steer the project in a new direction early on.

12.5 Future work

Making the autopilot aware of the prevailing wind conditions as well as the trueheading of the vehicle could improve the performance of the landing controllerand ensure that the aircraft can align itself with the runway just before touch-down. This will also be beneficial if automatic landing with landing gears isattempted. Automatic retry and abort conditions and automatically adjusting orsuggesting landing parameters for retries could also be investigated.

The takeoff controller could be extended with support for catapult which is aneffective way of launching aircrafts which might be too heavy for a hand launch.

72 12 Conclusions

Currently the takeoff controller is a bit firm on the throttle, a more gentle ap-proach that reduces the throttle after the aircraft has been sufficiently airbornecould be implemented.

As for fuzzy logic the Sugeno fuzzy inference system with automatic rule gen-eration could be an interesting topic to explore, perhaps mainly for the inner loopcontrollers where there the effects of the different output signals affect each otherin a more direct and apparent way.

Bibliography

[1] Bell labs: Adapting to monopoly’s end. http://www.nytimes.com/1987/03/09/business/bell-labs-adapting-to-monopoly-s-end.html?pagewanted=all. [Online; accessed 2016-04-10]. Cited on page 2.

[2] F.A. Administration. Pilot’s Handbook of Aeronautical Knowledge: FAA-H-8083-25A. FAA Handbooks. Aviation Supplies & Academics, Incorporated,2008. Cited on pages 11, 13, and 14.

[3] Michael Basler, Martin Spott, Stuart Buchanan, Jon Berndt, BernhardBuckel, Cameron Moore, Curt Olson, Dave Perry, Michael Selig, DarrellWalisser, et al. The FlightGear Manual. 2013. URL http://mapserver.flightgear.org/getstart.pdf. Cited on page 25.

[4] Merrie Bergmann. An Introduction to Many-Valued and Fuzzy Logic.Cambridge University Press, 1 edition, 2008. Ebook edtion, ISBN13:9780521707572. Cited on pages 3 and 4.

[5] UAS Europe. Skyview gcs, 2013. URL http://uas-europe.se/index.php/products/skyview-ground-control-station-software.Cited on page 25.

[6] Susan Haack. Do we need “fuzzy logic”? International Journal of Man-Machine Studies, 11(4):437 – 445, 1979. ISSN 0020-7373. doi: 10.1016/S0020-7373(79)80036-X. Cited on page 4.

[7] Marvin Lemos. Embedded fuzzy logic library, November 2012. URLhttps://github.com/zerokol/eFLL. Cited on page 34.

[8] Inc MathWorks. MATLAB Fuzzy Logic Toolbox: User’s Guide. MathWorks,Incorporated, 2012. Cited on page 5.

[9] FlightGear project. Flightgear flight simulator, September 2012. URLhttp://www.flightgear.org/. Cited on page 25.

[10] Juan Rada-Vilela. fuzzy-lite, November 2012. URL http://code.google.com/p/fuzzy-lite/. Cited on page 34.

73

http://www.nytimes.com/1987/03/09/business/bell-labs-adapting-to-monopoly-s-end.html?pagewanted=all




http://mapserver.flightgear.org/getstart.pdf

http://mapserver.flightgear.org/getstart.pdf

http://uas-europe.se/index.php/products/skyview-ground-control-station-software

http://uas-europe.se/index.php/products/skyview-ground-control-station-software

https://github.com/zerokol/eFLL

http://www.flightgear.org/

http://code.google.com/p/fuzzy-lite/

http://code.google.com/p/fuzzy-lite/

74 Bibliography

[11] Ingemar Ragnemalm. Polygons feel no pain. 2010. Cited on page 15.

[12] Michio Sugeno. Industrial Applications of Fuzzy Control. Elsevier ScienceInc., New York, NY, USA, 1985. ISBN 0444878297. Cited on page 8.

[13] Wikimedia. File:lift curve.svg, . URL https://commons.wikimedia.org/wiki/File:Lift_curve.svg. [Online; accessed 2016-04-24].Cited on pages viii and 12.

[14] Wikimedia. File:stallformation.svg, . URL https://commons.wikimedia.org/wiki/File:StallFormation.svg. [Online; accessed2016-04-24]. Cited on pages viii and 12.

[15] A. Wayne Wymore. Model-Based Systems Engineerin. CRC Press, 1993.ISBN13: 978-0849380129. Cited on pages 2 and 67.

[16] J. Yen. Fuzzy logic-a modern perspective. Knowledge and Data Engineering,IEEE Transactions on, 11(1):153 –165, jan/feb 1999. ISSN 1041-4347. doi:10.1109/69.755624. Cited on pages 4 and 5.

[17] L. A. Zadeh. Fuzzy sets. Information and Control, 8(3):338–353, 6 1965.Cited on page 3.

[18] L.A. Zadeh. Fuzzy logic = computing with words. Fuzzy Systems, IEEETransactions on, 4(2):103 –111, may 1996. ISSN 1063-6706. doi: 10.1109/91.493904. Cited on page 3.

[19] Lotfi A. Zadeh. Is there a need for fuzzy logic? Information Sciences, 178(13):2751 – 2779, 2008. ISSN 0020-0255. doi: 10.1016/j.ins.2008.02.012.Cited on page 4.

[20] Michael Zarozinski. Free fuzzy logic library, November 2012. URL http://ffll.sourceforge.net/. Cited on page 34.

https://commons.wikimedia.org/wiki/File:Lift_curve.svg

https://commons.wikimedia.org/wiki/File:Lift_curve.svg

https://commons.wikimedia.org/wiki/File:StallFormation.svg

https://commons.wikimedia.org/wiki/File:StallFormation.svg

http://ffll.sourceforge.net/

http://ffll.sourceforge.net/

Automatic Takeoff and Landing of Unmanned Fixed Wing Aircrafts1055556/FULLTEXT01.pdf · Landing of...

Documents

Transcript of Automatic Takeoff and Landing of Unmanned Fixed Wing Aircrafts1055556/FULLTEXT01.pdf · Landing of...