Automatic Takeoff and Landing of Unmanned Fixed Wing Aircrafts a Systems Engineering Approach

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

Automatic Takeoff and Landing of Unmanned Fixed Wing Aircrafts A Systems Engineering Approach

Magnus Vestergren Master of Science Thesis in Computer Science Automatic Takeoff and Landing of Unmanned Fixed Wing Aircrafts A Systems Engineering Approach Magnus Vestergren LiTH-ISY-EX--16/5009--SE

Supervisor: Ola Dahl isy, Linköpings universitet Thom Magnusson Instrument Control Sweden AB Examiner: Tomas Svensson isy, Linköpings universitet

Division of Computer Engineering Department of Electrical Engineering Linköping University SE-581 83 Linköping, Sweden

The purpose of this thesis is to extend an existing autopilot with automatic takeoff and landing algorithms for small fixed wing unmanned aircrafts. The work has been done from a systems engineering perspective and as for solution candidates this thesis has a bias towards solutions utilizing fuzzy logic. The coveted promises of fuzzy logic was primarily the idea to have a design that was easily tunable with very little knowledge beyond flight experience for a particular aircraft. The systems engineering perspective provided a way to structure and reason about the project where the problem has been decoupled from different solutions and the work has been divided in a way that would allow multiple aspects of the project to be pursued simultaneously. Though the fuzzy logic controllers delivered functional solutions the promises related to ease of tuning was not fulfilled in a landing context. This might have been a consequence of the designs attempted but in the end a simpler solution outperformed the implemented fuzzy logic controllers. Takeoff did not present the same issues in tuning but did require some special care to handle the initial low airspeeds in an hand launch.

iii

Contents

List of Figures viii

List of Tables x

Notation xi

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

2 Background - Fuzzy logic 3 2.1 Criticisms of fuzzy logic ...... 4 2.2 Fuzzy logic in a control system ...... 5 2.2.1 Fuzzy inference system ...... 5 2.2.2 Mamdani inference system ...... 6 2.2.3 Sugeno fuzzy inference system ...... 8

3 Background - Fixed wing aircrafts 11 3.1 Stall ...... 11 3.2 Landing a fixed wing UAV ...... 13 3.3 Takeoff with a fixed wing UAV ...... 14 3.4 The ground effect ...... 14

4 Background - Splines 15

5 Desired system properties 19 5.1 Landing ...... 19 5.2 Takeoﬀ ...... 19

6 System components 21 6.1 Spy Owl 100 ...... 21 6.2 Spy Owl 200 ...... 21 6.2.1 Altimeter ...... 22 6.3 EasyPilot 3.0 ...... 23 6.3.1 Sensor unit ...... 24

v vi Contents

6.3.2 Simulation ...... 25 6.4 SkyView Ground Control Software ...... 25 6.5 STANAG 4586 ...... 25 6.6 External factors ...... 26

7 Performance 27 7.1 Measurements ...... 27 7.1.1 Landing ...... 28 7.1.2 Takeoﬀ ...... 28 7.2 Autopilot ...... 29 7.3 Consequences of deviations from the desired behavior ...... 29 7.3.1 Landing ...... 29 7.3.2 Takeoﬀ ...... 29

8 Cost 31

9 Design 33 9.1 Fuzzy logic ...... 33 9.1.1 Mamdani aggregation ...... 34 9.1.1.1 Integration ...... 34 9.1.1.2 Custom ...... 34 9.1.1.3 Precomputed ...... 35 9.1.1.4 Aggregation summary ...... 36 9.2 Landing controller ...... 36 9.2.1 Fuzzy controller ...... 36 9.2.2 Flare ...... 37 9.3 Approach trajectory ...... 37 9.3.1 Pitch lookahead ...... 38 9.4 Approach/Descend trajectory ...... 39 9.5 Keeping the aircraft on track ...... 40 9.6 Takeoff Controller ...... 40 9.7 Consequences, difficulties and limitations ...... 40 9.8 Stall ...... 41 9.9 Operator ...... 42 9.9.1 Landing ...... 42 9.9.2 Takeoff ...... 42 9.10 Retry and abort conditions ...... 44

10 Implementation 45 10.1 Fuzzy logic ...... 45 10.1.1 Membership functions ...... 45 10.1.2 Aggregation ...... 46 10.1.2.1 Mamdani custom algorithm ...... 46 10.1.3 Defuzziﬁcation ...... 48 10.2 Landing controller ...... 49 10.2.1 Approach controller ...... 49 10.2.2 Flare ...... 50 Contents vii

10.3 Approach trajectory ...... 51 10.4 Lookahead ...... 51 10.5 Takeoﬀ controller ...... 52

11 Results 55 11.1 Execution performance ...... 55 11.1.1 How the memory performance was measured ...... 55 11.1.2 How the execution performance was measured ...... 56 11.1.3 Execution performance measurements ...... 56 11.2 Flight performance ...... 57 11.2.1 How the performance was measured ...... 57 11.2.2 Landing simulation results ...... 58 11.2.3 Landing real world results ...... 59 11.2.4 Takeoff simulation results ...... 63 11.2.5 Takeoff real world results ...... 65 11.3 Trade-off requirements ...... 65

12 Conclusions 69 12.1 Landing ...... 70 12.2 Takeoﬀ ...... 70 12.3 Fuzzy logic ...... 70 12.4 Systems engineering ...... 71 12.5 Future work ...... 71

Bibliography 73 List of Figures

2.1 Potential membership function for the class of tall men...... 4 2.2 Common steps in a fuzzy inference system...... 6 2.3 The steps and their relations in a Mamdani type fuzzy inference system...... 7 2.4 The aggregation step in a Mamdani fuzzy inference system illustrated with the max aggregation method...... 8 2.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, in this case, is about 17◦...... 12 3.2 Illustration of the airflow on an airfoil in normal and stall conditions [14]...... 12

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

6.1 Spy Owl 100...... 22 6.2 Spy Owl 200...... 23 6.3 EasyPilot block diagram from the viewpoint of this thesis...... 24 6.4 EasyPilot 3.0...... 24 6.5 User interface of SkyView GCS...... 26

9.1 System design block diagram...... 34 9.2 Rough outline of a basic approach trajectory...... 39 9.3 Landing route as presented in SkyView GCS...... 43

10.1 The triangle and trapezoid membership functions...... 46 10.2 Illustration of the aggregation step using the max aggregation method. 47 10.3 The result of the custom aggregation method...... 48 10.4 Creating a segment from two points and dividing the segment into a triangle and a rectangle...... 48 10.5 Illustration of of the segments needed to consider during defuzziﬁ- cation after aggregation with integration and the custom aggregation method...... 49

viii LIST OF FIGURES ix

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

11.1 Simulated landing with fuzzy logic controller regulating the throttle and pitch...... 58 11.2 Simulated landing with fuzzy logic controller regulating the throttle...... 59 11.3 Simulated landing with the lookahead algorithm...... 60 11.4 Spy Owl 100 landing with fuzzy logic controller regulating the throttle and pitch...... 61 11.5 Spy Owl 100 landing with the lookahead controller...... 62 11.6 Spy Owl 200 landing with the lookahead controller...... 63 11.7 Horizontal distance (left/right from the UAVs point of view) of the Spy Owl 100 from the desired landing trajectory...... 64 11.8 Takeoﬀ data from a hand launch with Spy Owl 100...... 66 11.9 Takeoﬀ data from a hand launch with Spy Owl 200...... 66 List of Tables

6.1 Spy Owl 100 Specifications...... 22 6.2 Spy Owl 200 Specifications...... 23 6.3 Fluke 414D with Porcupine LR4 interface board specifications. . . 23

9.1 Memory consumption, in number of values, required for the precomputed values...... 36 9.2 Abort conditions and possible actions...... 44

10.1 Landing fuzzy rule set: Regulate altitude with the throttle and airspeed with the desired pitch...... 50 10.2 Landing fuzzy rule set: Regulate throttle after altitude and keep a ﬁxed pitch...... 50 10.3 Fuzzy rule set abbreviations and descriptions...... 50 10.4 Takeoﬀ fuzzy rule set: Simple rule set where the input is the airspeed of the aircraft output is the desired pitch level...... 52

11.1 Memory consumption for the fuzzy logic and lookahead controllers. 57 11.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 ﬁnal adjustments before touchdown. GCS Ground Control Station. PID- Proportional-Integral-Derivative controller. Controller Pitch Indication of how much the aircraft’s nose is point up or down. Roll Indication of how much the aircraft has been rotated to the left or right as seen from behind the aircraft. Rudder Control surface to control the yaw of an aircraft. UAV Unmanned Aerial Vehicle.

1 Problem 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 be used with fixed wing aircrafts for several applications. For a fixed wing aircraft landing and takeoff are the most critical elements of a mission, at ICS these are currently carried out by a human pilot. The goals of automating takeoff and landing are to minimize the risks and increase repeatability of a flight at the same time as reducing the dependence on a human pilot; as the capabilities of the autopilot are improved the need for a skilled pilot is reduced. For unmanned fixed wing aircrafts there are several common techniques to simplify the process of piloted or automated landing, such as the use of parachute, net (where the aircraft 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 not as 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 complete fixed wing systems developed by ICS. For both the standalone and complete systems the end user often have very little to no experience with fixed wing aircrafts; this reinforces the need to minimize the dependence on a human pilot. For the end user this means that more energy and effort can be spent on their needs rather than operating the aircraft. A repeatable system also inspires confidence and when considering that the payloads used in unmanned aircrafts often consist of very expensive and fragile camera equipment this becomes an important factor for the system as a whole. At the time for this thesis the only missing pieces in the EasyPilot for achieving a fully autonomous system, where the autopilot is in control throughout the flight, are takeoff and landing. The purpose of this thesis is to extend the autopilot to include automatic takeoff for hand thrown aircrafts as well as automatic belly landing. For this fuzzy logic 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 perform automatic landing and takeoff of fixed wing aircrafts? Is it feasible to implement fuzzy logic on the EasyPilot 3.0 (and similar embedded systems)? Is fuzzy logic a suitable alternative for implementing landing and takeoff controllers on embedded systems? The takeoff and landing controllers developed for this thesis will be able to utilize the existing control surface controller as well as having access to filtered sensor data. The EasyPilot has been developed with the intention of being easily adaptable to different types of fixed wing UAVs with as little calibration and tuning as possible. It is therefore desirable for the takeoff and landing controllers to 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 approach has been inspired by A. Wayne Wymore and his book Model-Based Systems En- gineering [15]. Wymore stresses the importance of not stating the problem in terms of a preconceived solution [15, p. 8]. Ian Ross, former president of Bell Laboratories 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 in the process, (Ian Ross) With a systems engineering approach this thesis hopes to encapsulate the idea that the problem and solution should be decoupled. The problem is described in terms of desired behavior (section 5) and the solution candidates as restricted by the available components, possible techniques and external factors (section 6). A quantitative way of evaluating diﬀerent systems in terms of performance (section 7) and cost (section 8) is presented. With the previous sections in mind designs are proposed (section 9), implemented (section 10) and evaluated (section 11). One goal with the distribution of the sections is that they should be as independent as possible and be able to stand on their own. If fuzzy logic were to be abandoned as a solution candidate the goal of the controller should still be the same. The performance and cost could still be evaluated regardless of approach and since the evaluation is independent of the diﬀerent solutions, even those not conceived or mentioned in this thesis, can be compared on equal terms. Similarly if, for instance, this thesis relies on an assumption that doesn’t hold for other scenarios or makes use of an component that isn’t available for another project the reader should be able to deduce the consequences and their magnitudes. 2 Background - Fuzzy logic

Fuzzy logic is a form of multi-valued logic which arose to address the problem of describing and handling partial truths, which was first studied by Jan Lukasiewics [4, loc.331] . The beginning of fuzzy logic is often credited to Lotfi A. 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 problematic in regular set theory. An example that is brought up is the class of tall men that illustrates the imprecision often used by humans. Few would be comfortable with an arbitrarily small difference in height making the difference of whether a person is tall or not (sorites paradox). A fuzzy set on the other hand allows for partial membership and can thus distinguish people who are somewhat tall or very tall in a way that is in better agreement with natural language and everyday conversation [17, p. 338]. In Zadeh’s paper the degree of membership in a set is decided by a membership function fmf (x) where each value of x is mapped to a real number in the interval [0, 1], the degree of membership. In figure 2.1 a potential membership function for the class of tall men is presented. Other potential problems with typical two valued logic is illustrated with the law of excluded middle that states that a proposition is either true, or its negation must be. When dealing with clear definitions this might not be a problem, but there is often more information conveyed within natural language and thus some information is lost in translation. Whether this is a problem or not depends on ones viewpoint. For situations where it is considered to be a problem computing with words is a methodology where emphasis is put on dealing with words rather than numbers and symbols, trying to preserve the information conveyed in natural language. In the paper Fuzzy logic = computing with words [18] Zadeh notes that 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 computing with words.

1 0.8 0.6 0.4 0.2

Degree of membership 0 1 1.2 1.4 1.6 1.8 2 Length [m]

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 from those who practice more traditional and apparent rigorous ﬁelds. Although as Zadeh emphasize in his paper Is there a need for fuzzy logic? [19], there are many misconceptions about fuzzy logic and that fuzzy logic itself isn’t fuzzy. And as Bergmann [4] points out, misconceptions of fuzzy logic is probably partly due to conﬂation 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 is illustrated 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 fuzzy logic is. Zadeh offers us not only a radically non-standard logic, but also a radically non-standard conception of the nature of logic. It would scarcely be an exaggeration to say that fuzzy logic lacks every feature that the pioneers of modern logic wanted logic for; it sacrifices what have traditionally been regarded as the crucial advantages of formalism–precise, formal rules of inference, the security offered by consistency and completeness results. [...] Still, though fuzzy logic represents such a dramatic departure from the logical tradition, that it does so isn’t, of itself, a cogent criticism of the enterprise. The question is, rather, whether there are good reasons for 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-eﬀective solution to a wide range of real world problems is the primary reason that fuzzy logic has found so many successful applications in industry to date. Understanding this driving force of the success of fuzzy logic will prevent us from falling into the trap of debating “whether fuzzy logic can accomplish what X can not accomplish” where X is an alternative technology such as probability theory, control theory, etc. Such a debate is usually not fruitful because it ignores one important issue – cost. A better question to ask is “What is the diﬀerence between the cost of a fuzzy logic approach 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 fuzzy logic toolbox where it is argued that the gains of using fuzzy logic is often that it is easy to implement, easy to understand and easy to maintain and calibrate - not that it is the only or computationally the most eﬃcient 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 and fuzzy logic in the broad sense. Fuzzy logic in the narrow sense is aimed at being a generalization of classical logic whereas fuzzy logic in the broad sense deals with human reasoning and practical applications such as fuzzy set theory, fuzzy control systems and expert systems. The background provided in this chapter will be focused on the parts relevant for this thesis, which is mainly fuzzy logic in the broad sense as a fuzzy control system.

2.2.1 Fuzzy inference system A Fuzzy Inference System (FIS) can be used as a base for a fuzzy control system and maps a set of inputs to a set of outputs using fuzzy logic. The general steps involved are usually:

• Fuzziﬁcation

• Fuzzy inference

• Defuzziﬁcation

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 a fuzzy inference system is the temperature of a warm beverage, say coffee, is 80 ◦C it gets fuzzified into a large degree of hot. 6 2 Background - Fuzzy logic

Crisp input

Fuzziﬁcation

Fuzziﬁed input

Fuzzy inference

Fuzzy output

Defuzziﬁcation

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 of if-then rules, to produce a fuzzy output, i.e. if temperature of coffee is just right then drink. Defuzzification takes the fuzzy output from the fuzzy inference step and usually produces a crisp output, as with the steps above the exact process of doing defuzzification varies but in general you want to consider the output from the inference step and produce a crisp value - for each of the outputs. If some rule in the fuzzy inference step concludes that you should drink fast and another that you should drink slowly the result might be drink moderately, or if it is considered to be of greater importance that we shouldn’t drink too little coffee the result might 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 used fuzzy inference system, it stores the knowledge in the form of if-then rules and compared to the Sugeno inference system (section 2.2.3) it is considered to be easy to deal with but tends to be much more expensive computationally. The steps and relations involved in a Mamdani type fuzzy inference system are depicted in ﬁgure 2.3.

Fuzzification Each input is fuzzified with the means of, usually several, membership functions. The input variable for the coffee temperature might have three membership functions associated with it: cold, just right and hot. 2.2 Fuzzy logic in a control system 7

Crisp input

Fuzziﬁcation

Fuzziﬁed input

Rule evaluation

Rule outputs

Implication

Implication res.

Aggregation

Fuzzy output

Defuzziﬁcation

Crisp output

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

Rule evaluation A rule for the input described above might say: If coffee temperature is hot or coffee temperature is cold then desire to drink is low. Where desire to drink is an output of the system with perhaps two membership functions associated with it, low and high. The terms that appear in the if-part is called antecedents and the terms that appear in the then part is called the consequents. If there are multiple antecedents they are combined with the use of a fuzzy operator, and or or. There are many different functions used when implementing fuzzy operators but a common and simple function used for and is min, that uses the smallest value produced by the antecedents. The corresponding function commonly used for or is max, that uses the largest value produced by the antecedents. 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.

Implication The result of the rule evaluation is mapped to the output member function with the use of an implication function. The result of the implication function is a fuzzy set and the simplest, and still commonly used, is the min function where the output member function is capped at the height corresponding to result of the rule evaluation. 8 2 Background - Fuzzy logic

Aggregation Aggregation takes the result from all of the rules in the form of fuzzy sets and combines them to a single fuzzy output for each of the outputs. A common method for doing this is max, which combines the greatest contribution from each rule into a combined fuzzy set, se ﬁgure 2.4. For Mamdani this is the main step that is considered computationally heavy and not always suitable for embedded systems.

1 1 1 0.8 0.8 0.8 0.6 0.6 0.6 0.4 0.4 0.4 0.2 0.2 0.2 0 0 0 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 Result of rule 1 Result of rule 2 Result of rule 3

1 0.8 0.6 0.4 0.2 0 0 0.2 0.4 0.6 0.8 1 Result of aggregation

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

Defuzzification The output from the aggregation is in the form of of a fuzzy set and the output of the defuzzification is usually a single number per output. The output is most commonly calculated by calculating the center of gravity of the fuzzy set on the x-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 much with the Mamdani fuzzy inference system. The main diﬀerences between between Mamdani and Sugeno is that Mamdani focuses on leveraging human reasoning when the rules for the system is compiled. A Sugeno rule on the other hand 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, as described in equation 1. Compared with Mamdani it becomes apparent that the 2.2 Fuzzy logic in a control system 9

1 0.8

0.6 CGX 0.4 0.2 0 0 0.2 0.4 0.6 0.8 1

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

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

Pn wi zi output = i=1 Pn wi i=1

Equation 1: Output in a Sugeno system.

3 Background - Fixed wing aircrafts

The main forces that affect a flying fixed wing aircraft are the thrust generated from the propulsion system, lift that is generated from the wings, the weight that pulls the aircraft downwards and the drag that counteracts the movement in the direction of the aircraft. Drag can be divided in parasite drag and induced drag where parasite drag is comprised of all of the forces that works against the direction of travel that doesn’t contribute to the flight, whereas induced drag is the drag that is associated with the generation of lift. Lift is of great importance when flying. In a particular fixed wing aircraft during level flight the most important factor that affects the lift is the Angle Of Attack, which is the angle between the relative wind and the airfoil. When the angle 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 typical relationship between lift and angle of attack is illustrated in figure 3.1. Other factors that affect the lift of an aircraft is the airfoil, wing area as well as air density, 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 attack 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 induced drag which in turn results in the aircraft not being able to sustain level flight. The airfoil of the wing is often designed as to stall at the root of the wing first, 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 not stall 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 coeﬃcient of lift and angle of attack, illustrating the eﬀects of a stall [13]. The critical angle of attack, in this case, is about 17◦.

6°, steady flow

15°, stall point, maximum lift separation point

25°

relative wind separated flow

Figure 3.2: Illustration of the airflow on an airfoil in normal and stall conditions [14]. 3.2 Landing a fixed wing UAV 13 of the ailerons are still as effective as possible. The angle of attack or speed at which a fixed wing aircraft stalls is not constant but depends on factors such as air density, ground effect (section 3.4) engine thrust and is affected by flight maneuvers such as abrupt changes in attitude, after for instance a dive or during a sharp turn [2, p. 4-3, 4-22]. The flight characteristics of a stalling aircraft is greatly dependent on the aircraft itself, particularly the center of gravity of the aircraft is of great importance since it decides whether the aircraft has a tendency to drop the nose in a stalling condition or not. Dropping the nose is often desirable since it will increase the speed of the aircraft and reduce the angle of attack, thus if the center of gravity is off the pilot might not be able to exit the stall and the aircraft will plummet to the ground [2, p. 4-22].

3.2 Landing a ﬁxed wing UAV

In broad terms landing consists of four stages, where the first stage concerns aligning the aircraft with the landing area and position itself for the next stage. The second stage, the approach, descends the aircraft towards the touchdown point in a constant glide slope. The third stage, the flare, concerns with the last adjustments before touchdown with the goal of reducing the vertical speed, transition to a desired touchdown attitude and aligning the aircraft in the direction of the aircraft velocity vector. The fourth stage concerns with stopping the aircraft on the ground. In a belly landing the high friction between the aircraft and the ground will inevitably slow the aircraft to a complete stop in such a short amount of time that there isn’t much room for adjustments after touchdown. A runway landing on the other hand is more delicate, taking much longer to slow down and requires much more care after touchdown, making sure that the aircraft stays on the runway and doesn’t fall over. Landing should always be done towards the wind and preferably straight into it, if there is side-wind present the aircraft will approach the landing area slightly sideways and should, at last possible moment, align itself in the direction it moves before touchdown. The main controllers during the approach and flare are the elevator and the throttle that both have an impact on the angle of attack which in turn also affects the velocity of the aircraft. Larger aircrafts often have flaps that both slow the aircraft down and increase the lift (thus reducing the stall speed) and/or other form of 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 reasonable time without any form of air-brake, while descending, is by itself often a challenge. 14 3 Background - Fixed wing aircrafts

3.3 Takeoff with a ﬁxed wing UAV

Performing a takeoff with a fixed wing UAV is significantly less intricate than landing. The main parts consists of getting into air, which depends on whether the aircraft is launched from hand throw, catapult or runway, and climbing to a specified altitude while avoiding any obstacles. In a hand launch or a catapult launch the aircraft starts off airborne and the main challenge in this case is to maintain control of the aircraft despite the fact that the airspeed can be very low at the same time as ensuring that the aircraft does not loose too much altitude. In the case of a runway launch the aircraft will need to gain enough speed to be able become 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 the increased angle of attack results in greater lift, the wing can be considered to have the same lift as when flying in level flight and thus the maximum climb rate is mainly 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 by the airflow being restricted by the ground surface [2, p. 4-9]. For a fixed wing aircraft the ground effect increases the lift and reduces the induced drag, for a large aircraft this can present difficulties when trying to slow down at low altitudes. 4 Background - Splines

A spline in a computer graphics context is a smooth curve that is defined by a set of control points. There are many different types of splines but they can be classified into two different sets; interpolation splines, where the curve goes through each control point and approximation splines where the control points need not to go through the control points. A common way to specify a spline is with blending functions that specify how much each control point in the spline should influence the curve, the sum of all blending functions will always equals to 1. Two types of splines that make use 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 four control points. The equations for the blending functions that make up such a curve is presented in equation 2 and illustrated in figure 4.1. The Catmull-Rom spline is an interpolation spline that is defined from four control points. Unlike the Bézier curve the spline is only defined for the inner most two control points. The equations for the blending functions that make up a 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 the Catmull-Rom spline reveal that both begin and end with exactly one blending function contributing to the curve; this implies that the curve will intersect with a control point at the beginning and end of the curve.

15 16 4 Background - Splines

B = (1 u)3 0 − B = 3u(1 u)2 1 − B = 3(1 u)u2 2 − 3 B3 = u

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

C = u3/2 + u2 u/2 0 − − C = 3u3/2 5u2/2 + 1 1 − C = 3u3/2 + 2u2 + u/2 2 − C = u3/2 u2/2 3 −

Equation 3: Blending functions for the Catmull-Rom spline, where u is on the interval [0, 1]. Note that the spline is only deﬁned between the second and third control point.

0.8

B0 B3

0.6 B1 B2

0.4

0.2

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

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

0.8 B1 B2

0.6

0.4

0.2

B3 B0

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Figure 4.2: Blending functions for the Catmull-Rom spline. Note that the two blending functions with negative contributions are for the ﬁrst and last control points; that are outside of the deﬁned curve.

5 Desired system properties

This chapter describes some desired properties that have been identified for the takeoff and landing of a fixed wing aircraft. The system properties described in this chapter are to be considered high level system properties and does not detail any 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 the airstrip and wind), speed (relative to the ground and wind) and the location of the aircraft at the time of touchdown. The desired attitude and speed at touchdown depends on the aircraft used and the goal of the landing controller is to get as close to the desired parameters as possible at the point of the touchdown. A decent touchdown, according to the criteria above, requires long preparations to line up and descend the aircraft in a controlled fashion. Compared to manned 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 rely very heavily on sensors and aircraft characteristics as well as leaving little room for margin when it comes to unforeseen external inﬂuences, such as wind gusts. When close to the ground the controller should not make use of roll to turn the aircraft since this might force a wing into the ground.

5.2 Takeoff

As this thesis is mainly about hand throw launches the aircrafts starts oﬀ airborne. The aircraft should be launched straight into the wind as to maximize the initial airspeed of the aircraft. The goal of the takeoﬀ 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 is primarily only in the beginning of a takeoff that it is of great importance to launch straight into the wind it is desirable, from the point of view of the operator, for the aircraft to maintain its course. Making it easier to plan the takeoff and avoid any obstacles. The takeoff is less delicate than the landing since it does not have to aim for a specific point to complete the launch. The controller can focus on an optimal ascend with much less regard for the surroundings or care about following a specific path. 6 System components

The hardware components available for this thesis was mainly decided before- hand. Everything should be developed for the EasyPilot and not requiring any external hardware - with, if deemed necessary, the exception of an altimeter. The hardware available on the EasyPilot is described in section 6.3. As for the implementation this thesis has a clear bias towards fuzzy logic, as described in the problem description. The EasyPilot also dictates that C should be the implementation language and in terms of software and algorithms the controller has access to the source code and inner loop controllers already developed for the EasyPilot. As a consequence of the architecture, described in section 9, the controller will not have direct access to the sensors but will work on processed and ﬁltered 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 aircraft is sold as a training solution and is especially suitable for development since it is cheap, easy to modify and repair. The Spy Owl 100 is depicted in ﬁgure 6.1 and for this thesis the Spy Owl 100 has been equipped with an laser altimeter (section 6.2.1). Some speciﬁcations 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 (section 6.1) a goal is to be able to test the result on the Spy Owl 200. This will also give an indication on how much work is needed to adapt for diﬀerent aircrafts and 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 Specifications Wing span 1.8 m Length 1.2 m Endurance Up to 60 minutes Engine 350W electric motor Maximum takeoff 3 kg weight Extra payload 0.5 kg Table 6.1: Spy Owl 100 Specifications.

and purpose built aircraft where flight characteristics and endurance have been prioritized as well as featuring better payload capabilities. The Spy Owl 200 is depicted 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 is a hand held Fluke-414D distance measurement tool with a Porcupine Electronics LR4 circuit board. The LR4 is a third party interface board from which the laser measurements can be read through a serial interface rather than the display on the instrument itself. The speciﬁcations 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 Specifications Wing span 2 m Length 1.5 m Endurance Up to 100 minutes Engine Electric motor Maximum takeoff 6.5 kg weight (hand launched) Extra payload 1.7 kg Table 6.2: Spy Owl 200 Specifications.

6.3 EasyPilot 3.0

The EasyPilot 3.0 (EasyPilot) is a STANAG 4586 (section 6.5) compliant autopilot developed by ICS that has mainly been targeting fixed wing aircrafts (depicted in figure 6.4). The EasyPilot consists of two units, a main unit that ties everything together and executes both inner and outer loop controllers as well as being in charge of 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 of view of this thesis as a block diagram in figure 6.3.

Fluke 414D with porcupine LR4 speciﬁcations Range 0.1 to 50 m Accuracy 3mm max, 2 mm typical Power consumption <1W Measurement rate 0.4 to 2.5 Hz Table 6.3: Fluke 414D with Porcupine LR4 interface board speciﬁcations. 24 6 System components

MAIN UNIT

AHRS

Inner loop Autoland controllers Takeoff

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 existing inner loop controllers. The inner loop controllers in the EasyPilot compare the current state, as described by the sensor unit, with the desired state, as described by 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 EasyPilot are 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 for short. The AHRS provides the main unit with attitude, heading and yaw information 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 the sensor unit is processed and then delivered to the main unit at a frequency of 50Hz.

The performance of the sensor unit Some experience gathered prior to this thesis is that the attitude data delivered by the 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 in part due to the interference in the aircraft. The aircraft used for testing has the engine in the back, battery in the front and the EasyPilot in the center of gravity of the aircraft. This means that the current from the battery to the engine travels alongside the EasyPilot and aﬀects 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 be quite good in a short time frame. However, both the altitude as measured by the air pressure sensors and the GPS can drift over time and result in a large error during a ﬂight session. An initial estimate can be a positive or negative error of 10m.

6.3.2 Simulation The EasyPilot support hardware in the loop simulation for the FlightGear Flight Simulator which allows designs to be tested quickly. FlightGear Flight Simulator is an open source ﬂight 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 consequence of this is that during the simulation the sensor data is an exact representation of the state of the aircraft and will thus not share the characteristics and imperfections of real sensors.

6.4 SkyView Ground Control Software

SkyView Ground Control Software [5], or SkyView GCS, is a Windows application 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 test flights as well as recording flights and provide real time information during test flights. 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 UAV interoperability is a NATO standard that aims to promote interoperability of UAV systems. 26 6 System components

Figure 6.5: User interface of SkyView GCS.

Through interoperability the goal is to enable increased flexibilities and capabilities to significantly enhance the war fighting capabilities of the forces. While STANAG 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 mentioned in this section. The most notable external factor affecting the aircraft is most likely wind. For a small UAV the effect of the wind can be substantial where the wind speed can get close to the desired airspeed of the aircraft in a landing context. Of large importance is also wind gusts and other irregularities of the air surrounding the aircraft. From the point of view of the takeoff and landing controller there are other external factors that will significantly affect the performance. One of those factors is the data coming from the sensor unit (section 6.3.1) where both the accuracy and frequency can have a huge impact on what the takeoff and landing controller can do. The performance of the aircraft is also outside of the scope for an outer loop controller but something that will have an impact on what can be done. The performance of the aircraft is also dependent on, aside from the characteristics of the aircraft itself, the center of gravity and weight of the aircraft which can greatly be affected by any payload used in the aircraft. 7 Performance

As indicated by the desired behavior (section 5) the most important performance metric of the landing controller is the speed, attitude and location of the aircraft at the time of touchdown. In order to build confidence for the system the results should be repeatable and work well in different wind conditions. Related to the touchdown is the planning leading up to the touchdown, in most cases this will follow some sort of desired trajectory and different solutions can be evaluated by comparing how well they follow the desired trajectory as well as the expected consequences of the deviations from the trajectory. The expected consequences is helpful during the development and tuning of a landing controller when performing tests with a real aircraft. In simulation the cost of a failed landing is nonexistent but with a real aircraft the cost can be severe. To minimize 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 hit the desired touchdown point.

7.1 Measurements

What aspects of a landing is of most importance depends on the aircraft and the type of landing performed. The consequences of deviations from the desired behavior is discussed in section 7.3. The weighting of the results will thus not necessarily be the same in different contexts, but the measurements themselves should still be relevant. Wymore talks about the weighting of different solution candidates for a given system in terms of trade-off requirements and suggests that methods and algorithms can be used to decide what aspects of the, often conflicting, desired aspects of performance and cost should be prioritized. For the system developed in

27 28 7 Performance this thesis a discussion of the trade-oﬀs is presented in section 11.3.

7.1.1 Landing Some performance metrics for the landing has been identiﬁed and during the approach 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 desired approach trajectory.

• Diﬀerence 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 interest to the operator. These parameters are greatly dependent on the prevailing conditions, subjectively one can get the idea of the performance of the flare from observations. But comparing the raw numbers in isolation is not believed to be fruitful.

• How much does the aircraft drift to the left/right during the ﬂare. • How long does the aircraft travel during the ﬂare.

At the point of touchdown it is too late to change anything so the performance of the touchdown is thus a function of how well the approach and ﬂare has suc- ceeded. For the touchdown the following parameters has been identiﬁed.

• 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 stabilize the roll, increase the airspeed and gain altitude at the same time. The performance is greatly affected by the throw itself which determines the initial attitude and speed of the aircraft. For a given throw the following parameters have been identified.

• How much altitude is lost using the point of throw as reference. • How long distance it takes for the aircraft to begin its ﬁnal ascend. • How well the aircraft maintains the desired course. 7.2 Autopilot 29

7.2 Autopilot

The performance of the autopilot has mainly been identiﬁed to the following parameters.

• Memory consumption. • Execution time.

There are lots of other potential parameters and resources that could be of interest depending on the hardware. Such as timers, inputs and outputs (for communicating with external sensors) that could aﬀect the impact of the implemented controllers. But the most relevant and suitable for comparison is believed to be just memory consumption and the execution time.

7.3 Consequences of deviations from the desired behavior

The consequences of not being able to maintain the desired behavior can be unfortunate. If the aircraft doesn’t behave as expected there are few guarantees that remains, which of course is the goal of the desired behavior in the ﬁrst place. An involuntary touchdown, or crash, will at best only risk damaging the aircraft and the components within. But may also risk crashing into and doing real damage to anything nearby, such as people, houses, vehicles or other aircrafts. Following are some of the consequences in a landing or takeoﬀ context.

7.3.1 Landing Of the factors discussed in section 5.1 the attitude is arguably the most delicate during a landing context. A bad attitude just before touchdown might force a wing into the ground or get the nose stuck at high speed. The airspeed of the aircraft isn’t subject to as swift changes as the attitude, but the airspeed aﬀect the ability to maintain the desired attitude and if the ground speed is too high the risk of damage increases as well as the consequences of a bad attitude. Unless a runway is targeted the desired location of the touchdown typically includes a wide margin of where a touchdown is acceptable, the faster the aircraft travels the shorter, in time, the margin will be. If a runway is targeted the consequences of missing the runway can be severe depending on the terrain. For the aircraft considered in this thesis the attitude is considered to be the most importance aspect of a successful landing.

7.3.2 Takeoff The most critical part of the takeoﬀ during a hand or catapult launch is in the very beginning. The aircraft is being subject to external forces that doesn’t necessarily align that well with the intended air ﬂow around the aircraft and control surfaces. 30 7 Performance

This is also when the aircraft itself is moving very slowly, is close to stall speeds and where the margins are at its lowest. Mishaps in this stage, such as not being able to maintain the altitude, will quickly result in a touchdown. This could also be the result of the throw itself (insufficient speed or bad attitude), wind gusts or the controllers inability to keep the aircraft toward the wind. If the aircraft isn’t aligned towards the wind or if the direction is affected during the launch the reduced apparent wind speed will hinder the aircrafts ability to maintain altitude and the increased side wind will make it harder to maintain control over the attitude, both increasing the risk of a crash. Once the airspeed has improved and if the aircraft has not lost too much of its altitude over ground the remainder of the launch is just a steady climb. The intended direction ought to include some margins so the takeoff controller should have no problems to finish the takeoff. 8 Cost

The cost of implementing the takeoff and landing controller is, under the assumption that a suitable autopilot and aircraft already is available, mainly the time taken for research and implementation and evaluation. During the evaluation real life flight tests require the most resources, something that involves several people as well as at the very least risking an aircraft with autopilot if anything were to go awry. The cost of equipping an aircraft with the takeoff and landing controller also includes any altimeter used and any modifications (material and time) required to equip the aircraft and autopilot with the altimeter. Each aircraft model equipped will also require additional tuning and evaluation. Any altimeter used would also take up precious space and usable payload weight of the aircraft. In the point of view of the autopilot the takeoff and landing controller will require processing power and memory resources, both of which can be significant for 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 the EasyPilot have been further investigated in section 11.1. Since the EasyPilot is a general purpose autopilot the time taken to tune and adapt the controllers to a new aircraft is of great importance. A simple design that can be quickly understood by an operator is desirable and would reduce the maintenance costs of the controller significantly at the same time as providing a compelling sales pitch.

9 Design

From the viewpoint of this thesis the system consist of a controller for takeoff and landing 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 diagram in figure 6.3. The system takes its input from the sensor unit and produces outputs in the form of desired behavior to the inner loop controllers. The sensor unit processes sensor data and ensures that the input data is filtered and as accurate as possible. The inner loop controllers tries to achieve the desired result by controlling the control surfaces of the aircraft. All the components that the main unit deals with have not been depicted, most notably the communication with the ground control station is performed by the main unit. The communication itself doesn’t have any impact of the behavior of the takeoff and landing controller but seeing as it is the ground control station that logs all data, the data that is available for analysis is affected. The data is collected by the ground control station at a frequency of about 6Hz from real flights and about 12Hz during simulations.

9.1 Fuzzy logic

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

33 34 9 Design

Current state Desired pitch, Sensor data and behavior roll, heading... Servo positions

Takeoff and Inner loop AHRS landing controller controllers

High level takeoff Specialized controllers General purpose and landing planner for takeoff and landing fuzzy controller

Difference between Inputs, current and desired outputs, behavior. rules

Figure 9.1: System design block diagram.

9.1.1 Mamdani aggregation

The, computationally, most challenging part of the Mamdani type fuzzy inference system (section 2.2.2) is the aggregation step. It is the main reason for why a Mamdani inference system is not always feasible to implement in embedded systems. For this reason diﬀerent solutions have been sought and compared. The solution taken by open source alternatives [20, 7, 10] (not targeting embedded systems) have all been using some form of integration. As integration is the cause of concern regarding the performance a faster solution would be desirable. The advantage of using integration is that it is easy to implement and that it is a general solution that will work with no added eﬀort regardless of how the output from the implication step looks. This is a compelling argument in an general purpose 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 divided into a number of integration steps. For each step the output of each rule (after the implication method has been applied) is fed into the aggregation method, resulting in an output for that particular step. The use of integration implies a trade oﬀ between performance and precision, where a low number of integration steps will be faster to execute but with worse precision than when using a higher number of integration steps.

9.1.1.2 Custom

With knowledge of how the membership functions will look and how the rules will 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 not impact the behavior of the controller. A lot of the potential constraints that was conceived have the basis in the output membership functions used. The most commonly used membership function used 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 for optimizations during aggregation. Further motivation for the triangular membership function is realized when considering the nature of fuzzy logic (as described in section 2) where simplicity is held high regard. Limiting the output membership function to triangular membership functions does not necessarily ensure that the aggregation step only needs to handle triangles. The implication step will affect the shape of the output membership function for each rule and the possible optimizations of the aggregation method must be applicable on the result from the implication method. Using the triangu- lation membership function and the max implication function (which is the most common implication function) the aggregation step would have to be able to handle symmetric trapezoids (in the form of cut-off triangles) as well as triangles. Another constraint that was identified was in the way the output membership functions could overlap. If the membership functions could not overlap more than 50% of each other the aggregation step would at most only have to deal with two membership functions at the same time. Since the fuzzy inference system is static the output membership functions can be known to be stored in order of appearance in the output space. This ensures that the aggregation step will not have to search through all membership functions to discover which membership functions might overlap. If, for instance, the output membership functions are traversed from smaller to greater output values the algorithm would only have to 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. This solution trades memory consumption for runtime performance and can potentially be really fast. To produce a somewhat equivalent result as the integration approach all possible input combinations with a sufficiently high precision must be generated, computed and ultimately be stored on the autopilot. The memory required greatly depends on the number of inputs, outputs and how fine grained the generated inputs are. The lookup table would have to contain the combination of all different values for each input and map each combination to each output. A naive approach to calculate the memory required for the lookup table can be seen in equation 4. The memory consumption could most likely be reduced while preserving adequate precision with the help of interpolation. 36 9 Design

#inputs #outputs #values per input Memory consumption (#values) 3 2 30 54000 3 2 50 250000 4 2 30 1620000 Table 9.1: Memory consumption, in number of values, required for the precomputed values.

#inputsY ( #values(I )) #outputs i ∗ i=1

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 benefits of being able to trade performance with precision. It can also provide a simple interface to integrate to various different membership functions. The custom algorithm is designed as to improve the performance without sacrificing accuracy, but while imposing a few constraints. It will also require much more work to implement and is tightly coupled with the available membership functions. The precomputed aggregation method relies heavily on available memory; to get an idea of the necessary memory requirements for the precomputed values Table 9.1 lists the memory consumption (in number of values) required for different cases (the algorithm used to measure the memory consumption is present in section 9.1.1.3). While no analysis have been done to exactly determine how many values are needed per input and output or how many inputs are desirable one can note that the memory consumption doesn’t scale well. Even with very modest number of inputs, outputs and number of values this puts some limitations on the experimentation possible. Under the assumption that each value can be fitted into a byte, limiting the range of all variables to 256 different values on most 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 was mostly 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 ﬁxed wing UAVs are often tightly coupled with the aircraft used. Examples of such solutions include parachute, deep stall and net landings. The landing techniques used by larger aircrafts put emphasis on a soft touchdown and was therefor believed to be more suitable to a general purpose landing controller, especially considering that the payload used in UAVs often consist of fragile camera equipment. Following is two techniques used for manned aircrafts that have been targeted.

Regulate throttle after altitude and pitch after speed This technique regulates the airspeed solely by the pitch of the aircraft. If the aircraft is speeding the pitch of the aircraft is increased, consequently if a greater speed is desired the pitch of the aircraft is decreased. The altitude is regulated with the help of the throttle. To increase altitude the throttle is increased and to decrease the altitude the throttle is lowered.

Regulate throttle after altitude and keep a fixed pitch Similarly to the first technique the altitude is regulated with the help of the throttle, the difference being that the (desired) pitch is completely fixed. This puts some, aircraft specific, constraints on the possible slopes of the aircraft can achieve.

9.2.2 Flare It was decided not to try to do any last second adjustments in the flare for two main reasons. The first reason was that such adjustments, if necessary, would leave very little room for margin and if they were not necessary for a safe touchdown they would be wasteful and too risky to try to implement. Also it was assumed that the altitude over ground data would not be accurate enough, this put 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 the flare. In order to avoid forcing a wing to the ground the aircraft should maintain level flight and with the ailerons dedicated to keeping the aircraft in level flight the only means to control the course is with the rudder. As the airspeed of the aircraft is decreasing the lift of the aircraft will be reduced resulting in a faster descent until the aircraft touches the ground. During this 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 altitude and 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 heavily used in computer graphics. The landing controller decides what inputs and what outputs are needed from the approach trajectory. The parameters used that are relevant for the approach trajectory are the speed difference between the current and desired airspeed and the altitude difference between the current and desired altitude. For the fuzzy controllers the altitude difference is measured at the current position of the aircraft while the pitch lookahead solution will calculate the difference between the current altitude and the desired altitude where the aircraft is expected to be in the future. For this two popular spline algorithms used in computer graphics was targeted, the Bézier curve and the Catmull-Rom spline (section 4). Both splines will allow the desired altitude to be calculated anywhere along the spline at any time. For the pitch lookahead approach the controller allows for a simpler trajectory to be used since the lookahead solution doesn’t care about evaluating the desired altitude at the current position but only cares about the desired altitude in the future, this is described in section 9.3.1. The target trajectory is a very simple trajectory consisting of two stages. The first stage is concerned with reducing the altitude over ground as much as possible and the idea of the second stage is to reduce the descent rate in preparation for the touchdown. A simple rough outline of the desired trajectory is illustrated in figure 9.2, the outline illustrated can be generated from four control points connected by straight lines. The simplicity of the rough outline has some desired properties, it is easy to adjust the slope and altitude of the trajectory by adjusting the control points. This is desired because the parameters that make up the trajectory may change during a flight (by the operator). Additionally the aircraft should preferably not be required to line up with the starting point exactly to ensure a smooth transition to the beginning of the trajectory. The sharp transitions between the segments in figure 9.2 makes it a less than ideal trajectory and the goal of the algorithms presented in this section is to take this rough outline as an input and generate a smooth trajectory that is suitable as guide for a fixed wing aircraft. Since the desired trajectory could change in flight the spline must be able 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 simple trajectory consisting of a couple of straight lines (similar to the rough outline in ﬁgure 9.2), calculates where the aircraft should preferably be on the trajectory in x seconds at the current speed and aiming the aircraft towards that point. This algorithm will cut the corners of the speciﬁed trajectory. During the most critical stages 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 that not considered to be a problem. 9.4 Approach/Descend trajectory 39

Level ﬂight

First stage

Second stage Ground 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 headwind or one could optimize for a specified descend ratio relative to the ground. In the case of the EasyPilot, which doesn’t have a real sense of the wind direction or speed, a descent ratio relative to the headwind would have to rely on the difference between ground speed and air speed as a measurement of the headwind. Both have their advantages and disadvantages. When optimizing the descend ratio relative to the headwind the touchdown point will depend on the accuracy of the headwind measurement, also any steady state error will accumulate over time and may potentially shift the touchdown point significantly. Optimizing for the descend ratio relative to the ground speed will unavoidably affect the throttle and angle of attack of the aircraft. The resulting trajectory might also be much longer than what is needed since any headwind will reduce the rate of descend. Initial tests in the simulator confirmed that optimizing the descend ratio relative to the headwind resulted in a constant drift, as a consequence of the steady state error, during the approach. All the attempts made to get the aircraft to hit the desired touchdown point failed, with the error only increasing as the approach was extended. As a result the focus has been on regulating the descend ratio relative to the ground speed and, in the late stages of a landing, disregard the trajectory in favor of preparing the aircraft for touchdown. The hope is that the aircraft will not have 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 desired track, especially during a runway landing where the consequences of missing the runway can be severe. The main source of information about the aircraft position comes from the GPS. Keeping the aircraft on a desired track has already been solved by the EasyPilot when flying regular missions; if the existing solution is good enough to meet the requirements there isn’t much motivation to come up with something else. However, the existing code for navigation has some unfortunate, in a landing context, properties. The navigation puts a greater emphasis on targeting a waypoint than following a line. The further away from the targeted waypoint the aircraft is the more freedom the aircraft has to move about and the closer the aircraft is to the waypoint the more aggressive the navigation algorithm becomes. Problems with this approach is that it can be difficult tune and understand without experience and specifically for landing missions the fact that the current algorithm becomes more aggressive the closer the aircraft is towards a given waypoint presents a number of problems. Ideally you would want the aircraft to follow the desired track as closely as possible during the whole descend. The issues with the current tracking algorithm in a landing context was enough incentive 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 the same idea could be used to calculate a desired heading. The lookahead algorithm would behave in the same way regardless of the distance towards the tracking waypoints as well as being easier to tune even with no previous experience.

9.6 Takeoff Controller

The goal of the takeoﬀ controller is to gain altitude as fast as possible in a controlled fashion. A simple approach to achieve this is to use a ﬁxed throttle while trying to achieve a desired airspeed. Any speed excess of the desired airspeed can be exploited by increasing the angle of attack of the aircraft. An increased angle of attack will both reduce the airspeed and increase the climb rate. If the airspeed drops the angle of attack can be decreased which will ensure that the airspeed is maintained at the cost of a reduced climb rate.

9.7 Consequences, difﬁculties and limitations

The late stages of a landing should align the aircraft with the true heading of the aircraft in order to avoid it tipping over after touchdown. The performance of the sensor unit, as described in section 6.3.1, presents some diﬃculties to achieving the desired behavior. As both an accurate heading (section 9.7) and accurate altitude (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. In the simulated environment the controller will be blessed with accurate readings but care must be taken to ensure that the sensors are good enough for the task when performing ﬂight tests.

Heading The EasyPilot has a 3-axis magnetometer that can be used to get the heading of the aircraft, unfortunately the data can be a bit unreliable and is susceptible to interference which makes them tough to rely on. An accurate heading can be calculated from GPS data, a problem the heading data that is calculated from a GPS is that it only takes the aircraft movements into account and not the true heading of the aircraft. The difference between the true heading and the GPS heading is a function of side-wind and this is of particular importance when landing. The heading also presents problems during takeoff. The GPS heading is not available when the aircraft is stationary as well as being unreliable when the aircraft is moving slowly. The aircraft will thus have difficulties knowing the heading in low speeds and is especially vulnerable of misalignment in the early stages of a takeoff.

Altimeter precision Getting an accurate reading of the altitude (over ground) is of great importance when landing at the same time as being hard to know reliably. The EasyPilot has an absolute pressure sensor as well as GPS height and the control station has access to altitude data. The difficulty with GPS height is that it is not that accurate on the z-axis and the difficulty with the absolute pressure sensor is that the pressure can change during the time of the flight, resulting in an offset in the altitude. A laser altimeter is used in order to solve the mentioned issues by calibrating the other sensors and smoothly adjusting the landing algorithms to the new information.

9.8 Stall

Landing and takeoff presents many challenges that relate to how to avoid stalling and how to exit a stall. As noted in section 3.1 the stall characteristics vary greatly for different aircrafts and finding a way to detect or exit a stall that is somewhat independent of the aircraft used is considered to be a tough problem with no clear solution. A serious evaluation of the problem is considered outside the scope of this thesis and the goal is to design a controller with enough margins that stalling will 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 the ability 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 imminent, if a retry (section 9.10) is automatically triggered the autopilot could be designed as to be able to increase the margins of angle of attack and airspeed in order to avoid a potential stall.

9.9 Operator

The operator must be able to control the aircraft and initiate a landing or takeoff. The aircrafts are controlled through SkyView GCS, a ground control station application developed by ICS. For each landing the information that an operator needs to specify is, in the simplest case, the desired touchdown location and direction. 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 is defined by waypoints. It seemed prudent to implement the takeoff and landing as routes 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 context must be setup to convey the necessary information.

9.9.1 Landing Information for the landing requires two waypoints. One to specify the desired touchdown point and another to specify the direction. To help the operator to get an idea of how much distance the landing preparations require a third waypoint is generated where the descent begins. For the operator this means that a landing route consists of at least three waypoints. The last two waypoints are set to the ground altitude, this altitude is fetched when calibrating the aircraft before launch, and the third to last waypoint is set to the start altitude over ground speciﬁed for the aircraft. Any waypoints before the last three will remain untouched and the aircraft can be commanded to any of them. If the aircraft is commanded directly to one of the last two waypoints the aircraft is redirected to the third to last waypoint. A landing route overlayed on a map from SkyView GCS is illustrated in ﬁg- ure 9.3.

9.9.2 Takeoff The information for the takeoff also requires two waypoints. The first waypoint specifies the starting point for the takeoff and the second specifies the direction from the starting point. To help the operator to get an idea of how much distance a launch requires the second waypoint is moved, in the specified direction, to the maximum distance expected for the takeoff. The maximum distance is not calculated based on the prevailing conditions at launch since it depends on variables not known at the time of planning or even takeoff (such as wind speed). The maximum distance is based upon the minimum expected climb rate that the vehicle 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 2 through 6 makes up a landing route where waypoint 4 marks the beginning of the descend, waypoint 5 marks the desired touchdown point and waypoint 6 defines the direction of the landing from the desired touchdown point. takeoff distance can be calculated. This will give the operator an idea of how long the takeoff distance is at the most. When the aircraft reaches the desired altitude it will start loitering and awaiting any new commands from the operator. When the launch has been initiated the first waypoint is moved to the current position of the aircraft; this to ensure that the operator don’t have to care about the exact launch point and that the transition to the desired heading is as smooth as possible. The launch route can also be generated automatically internally on the aircraft; the first waypoint is generated when the launch is initiated, the second waypoint is generated when the aircraft has traveled some specified distance from 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 that an accurate heading can be produced Until the aircraft reaches the second waypoint it will fly blindly, trying to keep the aircraft as steady as possible and only target a heading once the second waypoint has been generated. The automated approach is more hazardous since a bad launch might steer the aircraft slightly before the second waypoint has been generated, this will affect the position of the second waypoint which the aircraft will follow for the remainder of the launch. Thus if there are obstacles nearby a takeoff route is preferred since it will ensure that the aircraft does not veer too far off the specified course. 44 9 Design

Problem Action Too far off from the Adjust the trajectory and try again, make sure trajectory. that the adjusted trajectory is still within the bounds of the specified landing area. Air speed too high. The landing parameters probably needs to be fine tuned. Ground speed too high. If the air speed is within acceptable bounds this is an indicator of tail wind, possible solution is to retry and land in the opposite direction. True heading and the There is most likely too much side wind, ro- direction of travel differ tate landing route or land manually. too much. Heading, pitch or roll Hopefully this was just due to a wind gust error exceeded during but if not the aircraft might have to be landed flare. manually. Can’t find ground with Lower the trajectory and try again. altimeter. 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 controller could detect and abort a bad landing before touchdown. The criteria for aborting a landing will depend on the specific aircraft used as well as the landing area. An aborted landing could be retried, possibly with changed parameters. An abort could make use of the takeoff controller to quickly gain altitude and then start to loiter, awaiting new commands from the operator. Time constraints didn’t allow for them to be implemented but a few possible retry 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. 10 Implementation

The designs in section 9 that have been implemented are presented in this chapter. If not stated otherwise everything described has been developed in the C programming language for the EasyPilot.

10.1 Fuzzy logic

Following the ideas mentioned in section 9.1 some effort has been spent on making the implementation easy to adapt. With the use of function pointers and enumerations that represent different supported methods it has been ensured that adding to and extending any part of the fuzzy inference system is straight forward. This to allow for different designs to be tested as well as allowing methods to be added later on to support new types of systems. The implementation was focused around the Mamdani fuzzy inference system. The following sections follows the background on fuzzy logic (section 2) and treats the implementation details worth mentioning.

10.1.1 Membership functions The implemented membership functions are the triangle and the trapezoid membership functions, both have been defined as a number of points. The triangle is made up of three points, two of which must be on the x-axis and the third specifies where the top should be. The third point must be in between the other two points on the x-axis. The trapezoid membership function is made up of four points, two points must be on the x-axis and the other two specify where the top points 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 the height 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 can be entailed by the order of the points. If different slopes/heights of the membership functions are desired the whole membership function can be scaled by a constant factor. The membership functions and the points that make them up are illustrated in figure 10.1.

P1 P1 P2

P0 P2 P0 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 algorithms was implemented. Integration was ﬁrst implemented because it was simple and allowed for some early tests. The integration implementation also provides a reference point for any other algorithm tested. The aggregation step combines the output from the fuzzy implication step for each of the fuzzy rules using the aggregation method. The process is detailed, using the max aggregation method, in ﬁgure 10.2.

10.1.2.1 Mamdani custom algorithm The custom Mamdani aggregation algorithm tries to take advantage of the constraints listed in section 9.1.1.2. Those constraints as well as other identiﬁed constraints 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 and no 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 step as 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 aggregation method.

lines and a trapezoid can be constructed out of three lines (this can be realized by looking at ﬁgure 10.1).

Iterating all lines, from the ﬁrst (lowest value on the x-axis) to the last each line is tested for intersections. At the point of each intersection a new point is generated 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 sequential order quickly and at the same time reduce the search space drastically when looking for intersection points. The result of the custom aggregation algorithm is illustrated in ﬁgure 10.3.

The performance of the custom aggregation methods mainly depends on the number of output membership functions. One key aspect of the custom aggregation method is that the aggregation result consists of points that are based on the intersections from the implication step. This is thus the optimal representation, in terms of number of points, of the aggregation result and has the potential to both speed up the defuzziﬁcation step signiﬁcantly and being more precise when compared with the result from the integration method. 48 10 Implementation

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 was implemented for the Mamdani fuzzy inference system. The defuzzification implementation is the same regardless of whether the integration or custom aggregation algorithm is used. The result from the aggregation step is treated as a set of points. Two points make up a segment and the center of gravity and mass calculations are done by first dividing each segment into a triangle and a rectangle, which is illustrated in figure 10.4.

P0 T

X0 R X1

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

The center of gravity calculation of the triangle can be simpliﬁed a lot when noting that the it is only the center of gravity on the x-axis that is of interest and that the triangle will always be a right triangle. With those observations the equation for the center of gravity on the x-axis is shown in equation 5.

y(x0) < y(x1): cogx(T ) = x0 + Tbase/3 y(x ) > y(x ): cog (T ) = x + 2 T /3 0 1 x 0 ∗ base

Equation 5: Center of gravity on the x-axis for triangle T . See ﬁgure 10.4 for reference. 10.2 Landing controller 49

Combined with the rectangle the center of gravity for rectangle R and triangle T is shown in equation 6. Similarily the center of gravity for all segments combined is calculated with help of equation 7. The process is illustrated in ﬁgure 10.5, note that the custom aggregation method results in far fever points to consider which will speed up the calculations signiﬁcantly.

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

Equation 6: Center of gravity on the x-axis for segment S with triangle T and rectangle R. See ﬁgure 10.4 for reference.

Pn (coxx(Si) area(Si)) i=1 ∗ cogx(tot) = Pn area(Si) i=1

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- fuzziﬁcation after aggregation with integration and the custom aggregation method.

10.2 Landing controller

10.2.1 Approach controller For the approach controller two diﬀerent sets of fuzzy rules were settled upon after testing diﬀerent behaviors in the simulator. Both controllers are based on 50 10 Implementation

Airspeed Altitude VL ML ZO MH VH VH VH VH VH VH VL ZO ZO ZO VH VH MH MH MH MH MH ML ZO ZO ZO MH MH ML ML ZO MH MH ZO ML ML ZO MH MH VL VL ML ML ML MH VL VL ZO ZO ZO VL VL VL VL VL VH VL VL ZO ZO ZO Table 10.1: Landing fuzzy rule set: Regulate altitude with the throttle and airspeed with the desired pitch. Each column corresponds to a diﬀerence between the actual and desired airspeed from Very Low to Very High. Simi- larly each row corresponds to a diﬀerence between the actual and the desired altitude. Each cell (outside of the row/column headers) corresponds to the output of the rule. The bottom left output of each cell corresponds to the throttle output and the top right output corresponds to the desired pitch output. Abbreviations used is described in Table 10.3.

Altitude VL ML ZO ML VL Throttle output VH MH ZO ML VL Table 10.2: Landing fuzzy rule set: Regulate throttle after altitude and keep a ﬁxed pitch. Abbreviations used is described in Table 10.3.

techniques used in large aircrafts controlled by human pilots and is described further in section 9.2.1. The ﬁrst set of rules tries to regulate the altitude with the help of the throttle and the airspeed with the help of the pitch of the aircraft and is described in Table 10.1. The second set of rules tries to keep a constant pitch and regulates the 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 ﬂare relies heavily on the inner control loops to keep the aircraft stable. When the ﬂare is initiated the engine is turned

Abbreviation Description VL Very Low ML Medium Low ZO Zero MH Medium High VH 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 the aircraft level with the ground. The rudder tries to keep the aircraft aligned with the runway, since the ailerons will not be used to guide the aircraft a different set of parameters for the inner loop rudder controller was implemented for use during the flare.

10.3 Approach trajectory

All of the designs proposed has been implemented, the reasoning for implementing all designs was to be able to compare them with each other. Since the shape of the approach trajectory is based on parameters suitable for a particular aircraft it was of importance to make sure that the trajectory would not misbehave for any reasonable parameters. Ultimately being conﬁdent about the behavior in all scenarios was the biggest deciding factor between the designs. All designs were ﬁrst implemented in matlab for evaluation and then implemented in C on the autopilot.

10.4 Lookahead

The lookahead algorithm was implemented both for regulating the heading of the aircraft as well as the desired pitch of the aircraft. The calculation of the desired heading and the desired pitch are done separately, mainly to keep it simple and since not all landing algorithms make use of the lookahead algorithm when calculating the desired pitch. When calculating the desired heading this means that the difference in altitude 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 that the resulting lookahead distance can be a bit longer than expected (since only two dimensions are taken into account when calculating the lookahead distance). This will result in more gentle changes to the produced outputs for when the aircraft has drifted a long way from the desired trajectory. For a typical approach the differences should be much smaller than the desired lookahead distance so it should not affect the performance in any significant way. The algorithm works by taking the current speed and multiplies it with the length of the lookahead (in seconds), this results in a distance, denoted by d. The approach trajectory is traversed from the current position (the position on the trajectory 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 the aircraft 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. 52 10 Implementation

Trajectory Parallell to the ground Lookahead point

Closest point on the trajectory

Lookahead length, d

Figure 10.6: Illustrating the lookahead algorithm.

Airspeed VL ML ZO MH VH Pitch output VL ML ZO MH VH Table 10.4: Takeoﬀ fuzzy rule set: Simple rule set where the input is the airspeed of the aircraft output is the desired pitch level. Abbreviations used is 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 precision that is desirable in a landing controller. The fuzzy controller described here was the simplest that could be imagined, with the intent of extending it and developing further where it was deemed necessary. The idea behind the takeoff controller implemented is to use a fixed throttle, typically max or close to max throttle, and adjust the pitch after the airspeed. If the airspeed is greater than a configurable desired speed the pitch of the aircraft is increased. This results in a greater ascend rate and at the same time a reduced airspeed. If the airspeed drops the pitch is lowered which in turn should increase the airspeed. The initial rule set for the fuzzy controller is presented in Table 10.4. From the perspective of the operator two ways of initiating a takeoff was implemented. One where the operator would upload a launch mission consisting of two waypoints. The first waypoint to indicate the starting position and the second to indicate the direction of the launch. For the sake of not having to launch exactly where the first waypoint was placed and to avoid mishaps the autopilot moves the first waypoint to its current GPS position of the aircraft when the launch 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 first waypoint where the hand launch was initiated and the second waypoint after a configurable distance had been traveled. The idea being that the aircraft would keep a straight enough line in the beginning of the launch and then continue on straight. In addition to the fuzzy controller there were a few edge cases related to the takeoff that needed special consideration. The very low airspeeds at the moment of the launch motivated the use of an offset on the elevator to ensure that the aircraft could maintain a proper pitch level. For the sake of simplicity a simple offset that was linearly reduced as the airspeed was increased was proposed to begin with. There was also some concerns regarding maintaining the course of the aircraft. As the primary source of heading for the aircraft is GPS and movement is required to get a heading from the GPS. In addition the heading taken from GPS coordinates reported during standstill or low ground speeds can vary a lot and lack precision it was decided to not bother with the exact heading of the aircraft in the very beginning of the launch. The reasoning above in combination with that in the first stage of the takeoff lift is crucial motivated the landing controller to keep a fixed roll level. This increases the risk that the aircraft gets off course but considering we don’t have an accurate view of it’s heading and that any roll would decrease the potential lift of the aircraft the risk felt justified. The roll is fixed until two parameters have been fulfilled. The first of which ensures that the aircraft has reached a configurable altitude, in order to maximize lift and avoid banking close to the ground. The second that the aircraft has traveled a configurable distance, so that we can get an accurate heading in relation to the launch point. The second parameter also implies that we have some confidence that the airspeed is large enough. When both parameters have been exceeded the aircraft will start navigation and follow the takeoff direction. Lastly, the takeoff controller still utilizes the inner loop controllers and it was feared that the integral parts of the PID-controllers would wind up too much during the first stage of the launch. Thus it was decided to reset the integral part of the inner loop controllers for the first part of the takeoff, they would not have time to stabilize anyway so the takeoff could never be allowed to rely on them in the first place.

11 Results

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

11.1 Execution performance

Some eﬀort has been spent on quantifying the resources used by the controllers. The resources targeted have been processor utilization and memory usage on the autopilot. The methodology for measuring memory consumption is described in section 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 with some 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 measuring them can be a bit tricky. The stack usage was investigated in two ways. The ﬁrst way was to make use of inbuilt functions in the gcc compiler used. Adding the parameter f stack usage produces information about each function and, where available,− its stack− usage. 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 it can also only calculate the usage for each function individually. There is still the problem knowing which functions call which and the maximum call depth. The other way the stack was calculated was by declaring a variable in the main function, the address of this variable was used to get the starting point of the stack. Immediately afterwards the memory allocated for the stack was cleared (ﬁlled with zeroes) followed by the execution of a normal mission on the autopilot. The stack memory used was calculated by looking at a memory dump of the stack and see how much of the data was untouched. Isolating the stack usage only used by the landing controller would be quite time consuming and it was not considered important enough to pursue, the main point of calculating the memory consumption was to ensure that the usage was within acceptable bounds and that no nasty surprises would arise from memory overconsumption. The heap was calculated, for the landing controller, by wrapping all of the functions that was used to allocate memory on the heap with functions that also kept track of how much requested memory was used. This was only done for the fuzzy controllers, memory allocated on the heap for the rest of the autopilot was not considered.

11.1.2 How the execution performance was measured The EasyPilot is conﬁgured to have an interrupt that ﬁres once every millisecond, this interrupt is used to calculate the execution time by counting the occurrence of the interrupt during relevant parts of the code. One problem with this approach is precision, for many of the relevant parts a millisecond is a very coarse measurement. To combat this and to be sure that the measured values are typical each 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 pitch lookahead controller in a landing context is presented in Table 11.1. The stack usage has been calculated following the methodology in section 11.1.1 where the memory area of the stack is investigated. As a base a regular mission on the autopilot was performed, when initiating a landing the change in stack utilization was examined. That the stack usage in Table 11.1 indicates 0 bytes means that the area used by the stack did not increase as a result of initiating and performing a landing; not that the stack usage itself was 0 bytes. Though memory consumption often is a scarce resource it can be noted that the fuzzy controllers are mostly within acceptable bounds, the variants utilizing integration indicates that it doesn’t scale too well. Some care might be needed if the controller is extended with more rules and or outputs. The execution time for the same controllers is present in Table 11.2. As expected the lookahead algorithm requires much less processing time and that the custom fuzzy aggregation method is indeed quicker than the variants utilizing integration. 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 within acceptable bounds. However, the integration algorithm has less margins and consequently has a bigger impact on what else the autopilot can attempt to process at the same time.

Extended* Max Controller stack usage heap usage Fuzzy integration 50 steps 0 bytes 3936 bytes Fuzzy integration 100 steps 0 bytes 5536 bytes Fuzzy integration 200 steps 0 bytes 8736 bytes Fuzzy custom algorithm 0 bytes 2976 bytes Lookahead 0 bytes 0 bytes Table 11.1: Memory consumption for the fuzzy logic and lookahead controllers. * See section 11.1.3 for details.

Controller Execution time Fuzzy integration 50 steps 8.61 ms Fuzzy integration 100 steps 14.4 ms Fuzzy integration 200 steps 25.8 ms Fuzzy custom algorithm 3.10 ms Lookahead 0.161 ms Table 11.2: Time to perform one iteration of the fuzzy logic and lookahead controllers.

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 clear that the second stage of the approach trajectory, as outlined in figure 9.2, is not present in the real world flight tests. This reason for this was to shorten the required approach, the slower descend rate of the second stage was not deemed necessary 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 and make sure that the touchdown is within acceptable bounds. The results of simulation and real life ﬂight 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

Simulation 30.0 110.0

100.0 25.0 90.0 20.0 AGL [m] 80.0 15.0 Ground Speed [m/s] 70.0 Airspeed [m/s]

10.0 Pitch [degree] ]

60.0 m Vertical Error [m] [

Units Speed Error [m/s] 50.0 5.0 AGL

40.0 0.0 30.0 5.0 − 20.0 10.0 − 10.0

15.0 0.0 − 0 50 100 150 200 250 300 350 400 450 500 550 Samples Figure 11.1: Simulated landing with fuzzy logic controller regulating the throttle and pitch.

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

11.2.2 Landing simulation results The results of the simulations were inspiring, tuning was straight forward and each controller could easily be tuned to produce excellent results. Subjectively the responsiveness of the algorithms seemed excellent and although it’s hard to expect as good results in the real world the algorithms do what they were designed to do and shows promise.

Simulated landing with throttle and pitch fuzzy controller ﬁgure 11.1 depicts a landing with the fuzzy controller that regulates the throttle based on an altitude error and the desired pitch based on an airspeed error. The graph shows, when stabilized, a vertical error of about 0.85m and a speed error of about 0.6m/s during the ﬁrst part of the descend and well below 0.1m and 0.1m/s respectively for the second part of the descend.

Simulated landing with fixed pitch fuzzy controller figure 11.2 depicts a landing with the fuzzy controller that regulates the throttle based on an altitude error and tries to maintain a fixed pitch. The graph 11.2 Flight performance 59

Simulation 30.0 110.0

100.0 25.0 90.0 20.0 AGL [m] 80.0 15.0 Ground Speed [m/s] 70.0 Airspeed [m/s]

10.0 Pitch [degree] ]

60.0 m Vertical Error [m] [

Units Speed Error [m/s] 50.0 5.0 AGL

40.0 0.0 30.0 5.0 − 20.0 10.0 − 10.0

15.0 0.0 − 0 50 100 150 200 250 300 350 400 450 500 Samples Figure 11.2: Simulated landing with fuzzy logic controller regulating the throttle. illustrates some oscillating behavior to the speed, altitude and the pitch of the aircraft. This behavior was hard to get rid of and is most likely because of the aircraft used for the simulations. The pitch of the simulated aircraft is severely aﬀected by the throttle. To combat this eﬀectively it is probably needed to feed forward 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 simulator and even with the oscillations the controller typically kept the vertical error within 1m and within 1m/s. The oscillating behavior shown is not believed to be present for the aircrafts considered for this work and the results still shows some promise.

Simulated landing with pitch lookahead controller ﬁgure 11.3 depicts a landing with the pitch lookahead algorithm. When stabilized this shows a very low vertical error of at worst about 0.3m and a speed error of no more than 0.1m/s.

11.2.3 Landing real world results Unfortunately, the real world ﬂight tests didn’t perform as well as the simulations. Most of the landing controllers were not able to adequately follow the landing trajectory regardless of tuning. There were several issues, one of the ma- jor was controlling the airspeed. The real world ﬂight tests introduced a much 60 11 Results

Simulation 30.0 110.0

100.0 25.0 90.0 20.0 AGL [m] 80.0 15.0 Ground Speed [m/s] 70.0 Airspeed [m/s]

10.0 Pitch [degree] ]

60.0 m Vertical Error [m] [

Units Speed Error [m/s] 50.0 5.0 AGL

40.0 0.0 30.0 5.0 − 20.0 10.0 − 10.0

15.0 0.0 − 0 50 100 150 200 250 300 350 400 450 500 550 Samples Figure 11.3: Simulated landing with the lookahead algorithm. greater lag between throttle and increased airspeed as well as the effect of throttle increase or decrease were significantly weaker than in the simulator. This is further aggravated by the airspeed sensor on the EasyPilot which was not that responsive. Another difference between the simulation and real flight tests was that 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 landing controllers didn’t control the throttle but rather the desired airspeed and letting the internal throttle controller handle the rest. Tuning the throttle controller to be both adequate for cruise speeds and landing speeds was difficult and especially ensuring that the controller responded quickly enough when used as a means 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 drag ratio of the Spy Owl 200 would only make matters worse. This was enough motivation for pursuing the lookahead alternative. In the lookahead alternative the throttle controller only tries to maintain a fixed airspeed, it would thus not be as sensitive for deviations and it would have much longer time to stabilize itself during the descent. Any errors introduced by side wind would be small enough to be secondary to the risks associated with landing the aircraft at an angle.

Spy Owl 100 landing with throttle and pitch fuzzy controller ﬁgure 11.4 depicts a landing of the Spy Owl 100 with the fuzzy controller that 11.2 Flight performance 61

Spy Owl 100 40.0 40.0 AGL [m] 35.0 Ground Speed [m/s] 35.0 Airspeed [m/s] 30.0 Pitch [degree] Vertical Error [m] 30.0 25.0 Speed Error [m/s] 25.0 20.0 ] m 15.0 20.0 [ Units AGL 10.0 15.0 5.0 10.0 0.0 5.0 5.0 − 10.0 0.0 − 0 20 40 60 80 100 120 140 160 180 Samples Figure 11.4: Spy Owl 100 landing with fuzzy logic controller regulating the throttle and pitch. regulates the throttle based on an altitude error and the desired pitch based on an airspeed error. The aircraft is constantly below the desired trajectory with about 3 1m and the speed error is about 2m. The experiences tuning this controller ± ± were a bit diﬃcult and it was not as responsive to disturbances as one could have hoped.

Spy Owl 100 landing with pitch lookahead controller figure 11.5 depicts a landing of the Spy Owl 100 with the pitch lookahead algorithm. The aircraft again keeps itself below the desired trajectory but with greater accuracy, 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± anymore. When close to the ground the engine is also reduced and this is at the point where speed error is dropped from the graph. By the time this flight was performed the confidence for the laser altimeter had increased and the flare had been lowered, it is not nearly as easily detected in the graph but it is initiated at sample 238. The sudden change in the vertical error at sample 233 is because of sudden change in the values from the altimeter.

Spy Owl 200 landing with pitch lookahead controller ﬁgure 11.6 depicts a landing of the Spy Owl 200 with the pitch lookahead algorithm. Similarly to Spy Owl 100 the aircraft held itself below the desired trajectory with about 0.5 0.5m. The speed error however were a bit worse, steadily ± 62 11 Results

Spy Owl 100 40.0 25.0 AGL [m] 35.0 Ground Speed [m/s] Airspeed [m/s] 30.0 Pitch [degree] 20.0 Vertical Error [m] 25.0 Speed Error [m/s]

20.0

15.0 ] m 15.0 [ Units AGL 10.0 10.0

5.0

0.0 5.0

5.0 − 10.0 0.0 − 0 25 50 75 100 125 150 175 200 225 Samples Figure 11.5: Spy Owl 100 landing with the lookahead controller. increasing from 2m to 2m/s. This is partly because the inner loop controllers was not as ﬁne tuned− on the Spy Owl 200 as the Spy Owl 100. Before the descend begins the aircraft performs a quick turn and the Spy Owl 200 lost a lot of airspeed from the turn. This wound up the integral of the throttle controller which in turn, during the descend, made the aircraft slowly overshoot the desired airspeed. Compared to the fuzzy controllers the pitch lookahead algorithm was more responsive to errors in altitude compared to the trajectory.

Horizontal distance Example data of the horizontal distance from the desired trajectory from a landing with the Spy Owl 100 is presented in figure 11.7. From the point of view of the operator this was very satisfactory results. The aircraft didn’t make any sudden 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 aircraft had just performed a u-turn to align for the runway and had not had time to recover. The large deviation in the beginning shows that the aircraft is a tad bit aggressive and overshoots the desired path a bit. This could be improved by lengthening the lookahead but at the cost of having a larger static error when the aircraft was properly aligned. The horizontal performance performed consistently and quickly inspired confidence to the point where the horizontal distance was dropped from the logs to make room for other data. When side wind is present the aircraft would incur a 11.2 Flight performance 63

Spy Owl 200 35.0 25.0 AGL [m] 30.0 Ground Speed [m/s] Airspeed [m/s] 25.0 Pitch [degree] 20.0 Vertical Error [m] 20.0 Speed Error [m/s]

15.0 15.0 ] m 10.0 [ Units AGL 5.0 10.0

0.0

5.0 5.0 − 10.0 − 15.0 0.0 − 0 25 50 75 100 125 150 175 200 225 250 275 300 325 Samples Figure 11.6: Spy Owl 200 landing with the lookahead controller. larger deviation from the path but considering the nature of a ﬁxed wing landing the horizontal distance is less critical than the vertical distance and was never considered to be a problem.

11.2.4 Takeoff simulation results

Simulating a takeoff in flight gear was not straight forward, the concept of a hand launch is foreign to FlightGear as it is not designed for small UAVs. During development two ways of testing the takeoff controller was used. The first was to start the takeoff routine while the aircraft was already airborne. While great for testing the overall functionality this meant that the takeoff was initiated with a much higher than realistic airspeed. It did thus not take into account the crucial part 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 was touching the ground, causing the aircraft to spin uncontrollably. Though takeoffs could be performed while the aircraft was turning the data from the early stage of the takeoff is not of much use. Since the first stage of the takeoff is the most critical and important part of the takeoff it was not of much help when developing the takeoff controller and consequently it was decided to not include data from simulated takeoffs here either. 64 11 Results

Spy Owl 100 35.0 AGL [m] 30.0 Distance from path [m]

25.0

20.0

15.0 Meters

10.0

5.0

0.0

5.0 − 0 15 30 45 60 75 90 105 120 135 150 Samples Figure 11.7: Horizontal distance (left/right from the UAVs point of view) of the Spy Owl 100 from the desired trajectory. The altitude over ground is shown as a reference. 11.3 Trade-oﬀ requirements 65

11.2.5 Takeoff real world results One problem with comparing the flight data from different takeoffs is that there are lots of external factors that are hard to factor in. This includes the wind but most importantly the crucial part of the takeoff in a hand launch is impacted by the throw of the aircraft. Subjectively though the controller quickly inspired confidence as it consistently and reliably performed the takeoff as designed. The fears discussed during the implementation (section 10.5) regarding being able to maintain the pitch and course of the aircraft would seem to be unfounded in the real world. The aircraft maintains the desired course and does not drift off during the first crucial stage of the takeoff. The aircraft also maintains a good attitude throughout the takeoff. Though the idea was to extend the controller after real life flight tests, this did not seem necessary since the results were satisfactory once proper tuning was in place. Subjectively the tuning is fairly straight forward and forgiving, the biggest issue regarding the tuning is probably related to the nature of the takeoff - the aircraft is very close to the ground and if something goes wrong there is not much time to recover.

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

Takeoff with Spy Owl 200 Data from a takeoff with the Spy Owl 200 is depicted in figure 11.9. The behavior of the launch is similar to Spy Owl 100 but there are a few differences to note. The Spy Owl 200 has a more powerful engine and can afford a steeper and quicker ascend. Despite this, in the very beginning of the launch, it can be noted that the aircraft begins its ascend later than Spy Owl 100. From the graph this is hard to explain, the aircraft tries to and succeeds with maintaining an aggressive pitch but the aircraft doesn’t increase its altitude as much as expected. This turned out to at least partly be because the acceleration and vibrations during the initial stage of the launch affects the gyroscopes (and possible the sensor fusion algorithms). The pitch level of the Spy Owl 200 during launch as reported by the sensors is greater than in reality. Once this has been identified it can be sufficiently combated by a larger elevator offset until the aircraft has reached a destined airspeed or altitude.

11.3 Trade-off requirements

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

Spy Owl 100 35.0 60.0

30.0 50.0

25.0 40.0

20.0 ] m 30.0 [ Units 15.0 AGL

20.0 10.0 AGL [m] Ground Speed [m/s] 10.0 5.0 Airspeed [m/s] Pitch [degree] 0.0 0.0 0 25 50 75 100 125 150 175 Samples Figure 11.8: Takeoﬀ data from a hand launch with Spy Owl 100.

Spy Owl 200 30.0

40.0 25.0

20.0 30.0 ] m 15.0 [ Units

20.0 AGL

10.0

AGL [m] 10.0 5.0 Ground Speed [m/s] Airspeed [m/s] Pitch [degree] 0.0 0.0 0 10 20 30 40 50 60 70 80 Samples 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 different aircrafts. 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 as there was enough resources left for the communication, inner loop controllers and other parts of the autopilot that are required for the takeoff and landing controllers to be operational. Though all else being equal a design requiring less resources would of course be desirable, but given the constraint envelope of the EasyPilot hardware utilization was not considered to be a priority. As an example, the Sugeno fuzzy inference system (briefly described section 2.2.3) was abandoned as a candidate, even though it had a resource advantage compared to Mamdani, when it was realized that Mamdani was much better suited to the priorities of the project. This was of course under the assumption 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 to evaluate the trade-off between performance and cost. The lookahead algorithms provided the easiest interface for the operator at the same time as requiring the least resources and still being the most performant design.

12 Conclusions

Some conclusions regarding the work done for this thesis is presented in this section. There is always room for improvements but the most suitable controllers developed for this thesis is still in use well after this thesis was completed. The most critical aspect of the landing turned out to be controlling the altitude; not necessarily because it was harder to tune but because the consequences of altitude errors was much greater. This stems from the desired approach where the vertical velocity is much less than the speed of the aircraft; the impact of altitude errors on the distance from the desired touchdown point is thus greatly ampliﬁed. Following is an attempt to answer the questions stated in section 1:

Does the EasyPilot 3.0 have the necessary hardware needed to perform automatic landing and takeoﬀ of ﬁxed wing aircrafts?

Yes; the reasoning and the results of this thesis suggest that the EasyPilot hardware is mostly well suited to perform automatic landing and takeoff of fixed wing aircrafts. The EasyPilot is missing integrated sensors to accurately determine the altitude over ground as well as the true heading of the aircraft. The former is important if accuracy is needed and if last second adjustments are necessary in a landing 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 similar embedded systems)?

Yes; though computationally intensive fuzzy logic is feasible to implement on embedded hardware, especially when tailoring the implementation to the constraints of the given system. Though there are of course practical limitations on possible designs.

69 70 12 Conclusions

Is fuzzy logic a suitable alternative for implementing landing and takeoﬀ controllers on embedded systems?

Possibly; with the results of this thesis in mind it might be hard to justify the cost of fuzzy logic controllers; however, it would be a mistake to blindly accept that as representative for other implementations. Section 12.1 lists some possible reasons as to why the designs attempted in this thesis didn’t perform as well as one 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 benefits of fuzzy logic touted in the background chapter (section 2) was that the process could be easily adapted and fine tuned. Especially appealing was the prospect of making use of computing with words and not require that the operator had special knowledge about the inner workings of the landing controller. Though it is indeed possible to get good results the tuning turned out to be quite difficult. Good results also resulted in creating an unfortunate and complex coupling between the inner loop controllers and the landing controller, something that is particularly undesirable in a general purpose autopilot. Perhaps one of the biggest causes for the issues related to the fuzzy controllers was the overly reliance on the throttle as a means controlling the descend directly. This could partially be explained by the characteristics of the simulated aircraft. Though completely invaluable during the development the simulator did 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 have been more time to explore different controllers for the approach. The much simpler lookahead algorithm on the other hand proved to have similar performance while at the same time being easier to tune, easier to understand and require fewer parameters to consider.

12.2 Takeoff

The hand thrown takeoﬀ performed good as could be expected and the resulting 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 one wants to further diﬀerentiate the behavior between low and high altitudes or take other parameters into account.

12.3 Fuzzy logic

As the performance of embedded systems constantly evolve the performance cost of 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 implementation 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 selling points. Though this is not necessarily a fault of fuzzy logic, in hindsight there are a few things that could have been done diﬀerently. For one the fuzzy controllers primarily looked at larger aircrafts for inspiration. Though the idea was to mimic the soft touchdown of a manned aircraft this overlooked some of the diﬀerences in characteristics that a smaller UAV exhibit. Especially the overly reliance on using the throttle as a means to regulate the descend rate was problematic to tune.

12.4 Systems engineering

The systems engineering perspective helped to separate goal from implementation. The potential benefits from this was experienced during this thesis where the idea for the pitch-lookahead controller for the landing approach was conceived from real world experiences. During real world flight tests on the Spy Owl 100 it was discovered that the flight and tuning characteristics of the controllers deviated a lot from the simulator. Because of the nature of the difficulties it was also believed that there was a fair chance that it would only get worse on the Spy Owl 200. It was also predicted that the tuning of Spy Owl 100 could not easily be transferred to Spy Owl 200. For these reasons the pitch-lookahead was thought up, implemented and tested on both Spy Owl 100 and Spy Owl 200 with desirable and expected results. This might seem like a natural progression in a project consisting of mainly one person. The benefits should become more apparent on larger projects where different implementations could be produced by different teams. The systems engineer 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 parallel with the other implementations as well. With a detailed insight but also an understanding of the project as a whole the systems engineer can detect potential issues 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 true heading of the vehicle could improve the performance of the landing controller and ensure that the aircraft can align itself with the runway just before touchdown. This will also be beneficial if automatic landing with landing gears is attempted. Automatic retry and abort conditions and automatically adjusting or suggesting landing parameters for retries could also be investigated. The takeoff controller could be extended with support for catapult which is an effective 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 approach that reduces the throttle after the aircraft has been sufficiently airborne could be implemented. As for fuzzy logic the Sugeno fuzzy inference system with automatic rule generation could be an interesting topic to explore, perhaps mainly for the inner loop controllers where there the effects of the different output signals affect each other in 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, Bernhard Buckel, Cameron Moore, Curt Olson, Dave Perry, Michael Selig, Darrell Walisser, 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. URL https://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 ﬂight simulator, September 2012. URL http://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 74 Bibliography

[11] Ingemar Ragnemalm. Polygons feel no pain. 2010. Cited on page 15. [12] Michio Sugeno. Industrial Applications of Fuzzy Control. Elsevier Science Inc., 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; accessed 2016-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, IEEE Transactions on, 4(2):103 –111, may 1996. ISSN 1063-6706. doi: 10.1109/ 91.493904. Cited on page 3. [19] Lotﬁ 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.