Fuzzy Controller Autopilot for a Fixed Wing Unmanned Aerial Vehicle

FUZZY CONTROLLER AUTOPILOT FOR A FIXED WING UNMANNED AERIAL VEHICLE by

DOMINIC TIMOTHY JORDAN

A mini-dissertation submitted submitted for the partial fulfilment of the degree

BACCALAUREUS INGENERIAE in

ELECTRICAL AND ELECTRONIC ENGINEERING SCIENCE WITH INFORMATION TECHNOLOGY AS ENDORSEMENT at the

STUDY LEADER: MR FRANCOIS DU PLESSIS 2008

Table of Contents

TABLE OF CONTENTS 1

CHAPTER 1: PROBLEM STATEMENT ...................................................................................................... 1.1

1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2

CHAPTER 2: REQUIREMENTS ANALYSIS ................................................................................................ 2.1

2.1 2.2 2.3 2.4 3

INTRODUCTION AND OVERVIEW ................................................................................................................. 4.1 DETAILED DESIGN .................................................................................................................................... 4.1 DESIGN ALTERNATIVES ........................................................................................................................... 4.15 CONCLUSION........................................................................................................................................ 4.15

CHAPTER 5: IMPLEMENTATION ............................................................................................................ 5.1

5.1 5.2 5.3 5.4 5.5 5.6 6

INTRODUCTION AND OVERVIEW ................................................................................................................. 3.1 STANDARDS AND LEGAL CONSIDERATIONS .................................................................................................... 3.1 THEORY AND METHODS ............................................................................................................................ 3.1 TOOLS ................................................................................................................................................. 3.23 SIMILAR WORK ..................................................................................................................................... 3.27 CONCLUSION........................................................................................................................................ 3.35

CHAPTER 4: DESIGN .............................................................................................................................. 4.1

4.1 4.2 4.3 4.4 5

INTRODUCTION ....................................................................................................................................... 2.1 IDENTIFIED ISSUES AND CONSTRAINTS.......................................................................................................... 2.1 ASSUMPTIONS AND EXCLUSIONS................................................................................................................. 2.6 REQUIREMENTS SPECIFICATION .................................................................................................................. 2.6

CHAPTER 3: LITERATURE STUDY ........................................................................................................... 3.1

3.1 3.2 3.3 3.4 3.5 3.6 4

INTRODUCTION AND BACKGROUND ............................................................................................................. 1.1 PROBLEM STATEMENT .............................................................................................................................. 1.4 THE PROJECT OBJECTIVE ............................................................................................................................ 1.5 SCOPE OF THE PROJECT ............................................................................................................................. 1.5 DESIGN METHODOLOGY TO BE FOLLOWED .................................................................................................... 1.5 DELIVERABLES ........................................................................................................................................ 1.7 OVERVIEW OF THE DOCUMENT .................................................................................................................. 1.7 CONCLUSION.......................................................................................................................................... 1.9

INTRODUCTION AND OVERVIEW ................................................................................................................. 5.1 INDIVIDUAL SYSTEM INCREMENT IMPLEMENTATION PROCESS AND ISSUES .......................................................... ............................................................ 5.1 5.1 INTEGRATION PROCESS AND ISSUES ........................................................................................................... 5.19 COST SUMMARY.................................................................................................................................... 5.19 SETTING UP AND USING THE SYSTEM ......................................................................................................... 5.20 CONCLUSION........................................................................................................................................ 5.23

CHAPTER 6: RESULTS ............................................................................................................................ 6.1 6.1

6.1 6.2 6.3 6.4 6.5 6.6

INTRODUCTION AND OVERVIEW ................................................................................................................. 6.1 METHODOLOGY ................................................................ TEST AND EVALUATION STRATEGY, SETUP AND METHODOLOGY ......................................................................... ......... 6.1 COMPONENT TESTING .............................................................................................................................. 6.2 SYSTEM TESTING ................................................................................................................................... 6.22 FURTHER RESULTS DISCUSSION................................................................................................................. 6.22 CONCLUSION........................................................................................................................................ 6.23

7

CHAPTER 7: CONCLUSION ..................................................................................................................... 7.1

8

REFERENCES ........................................ ................................................................................................. 8.1

9

APPENDIX A .......................................................................................................................................... 9.1

10

APPENDIX B ........................................................................................................................................ 10.1 10 .1

10.1

DT Jordan

FUZZY REASONING ................................................................................................................................. 10.1

2008

i

Table of Contents

TABLE OF CONTENTS 1

CHAPTER 1: PROBLEM STATEMENT ...................................................................................................... 1.1

1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2

CHAPTER 2: REQUIREMENTS ANALYSIS ................................................................................................ 2.1

2.1 2.2 2.3 2.4 3

INTRODUCTION AND OVERVIEW ................................................................................................................. 4.1 DETAILED DESIGN .................................................................................................................................... 4.1 DESIGN ALTERNATIVES ........................................................................................................................... 4.15 CONCLUSION........................................................................................................................................ 4.15

CHAPTER 5: IMPLEMENTATION ............................................................................................................ 5.1

5.1 5.2 5.3 5.4 5.5 5.6 6

INTRODUCTION AND OVERVIEW ................................................................................................................. 3.1 STANDARDS AND LEGAL CONSIDERATIONS .................................................................................................... 3.1 THEORY AND METHODS ............................................................................................................................ 3.1 TOOLS ................................................................................................................................................. 3.23 SIMILAR WORK ..................................................................................................................................... 3.27 CONCLUSION........................................................................................................................................ 3.35

CHAPTER 4: DESIGN .............................................................................................................................. 4.1

4.1 4.2 4.3 4.4 5

INTRODUCTION ....................................................................................................................................... 2.1 IDENTIFIED ISSUES AND CONSTRAINTS.......................................................................................................... 2.1 ASSUMPTIONS AND EXCLUSIONS................................................................................................................. 2.6 REQUIREMENTS SPECIFICATION .................................................................................................................. 2.6

CHAPTER 3: LITERATURE STUDY ........................................................................................................... 3.1

3.1 3.2 3.3 3.4 3.5 3.6 4

INTRODUCTION AND BACKGROUND ............................................................................................................. 1.1 PROBLEM STATEMENT .............................................................................................................................. 1.4 THE PROJECT OBJECTIVE ............................................................................................................................ 1.5 SCOPE OF THE PROJECT ............................................................................................................................. 1.5 DESIGN METHODOLOGY TO BE FOLLOWED .................................................................................................... 1.5 DELIVERABLES ........................................................................................................................................ 1.7 OVERVIEW OF THE DOCUMENT .................................................................................................................. 1.7 CONCLUSION.......................................................................................................................................... 1.9

INTRODUCTION AND OVERVIEW ................................................................................................................. 5.1 INDIVIDUAL SYSTEM INCREMENT IMPLEMENTATION PROCESS AND ISSUES .......................................................... ............................................................ 5.1 5.1 INTEGRATION PROCESS AND ISSUES ........................................................................................................... 5.19 COST SUMMARY.................................................................................................................................... 5.19 SETTING UP AND USING THE SYSTEM ......................................................................................................... 5.20 CONCLUSION........................................................................................................................................ 5.23

CHAPTER 6: RESULTS ............................................................................................................................ 6.1 6.1

6.1 6.2 6.3 6.4 6.5 6.6

INTRODUCTION AND OVERVIEW ................................................................................................................. 6.1 METHODOLOGY ................................................................ TEST AND EVALUATION STRATEGY, SETUP AND METHODOLOGY ......................................................................... ......... 6.1 COMPONENT TESTING .............................................................................................................................. 6.2 SYSTEM TESTING ................................................................................................................................... 6.22 FURTHER RESULTS DISCUSSION................................................................................................................. 6.22 CONCLUSION........................................................................................................................................ 6.23

7

CHAPTER 7: CONCLUSION ..................................................................................................................... 7.1

8

REFERENCES ........................................ ................................................................................................. 8.1

9

APPENDIX A .......................................................................................................................................... 9.1

10

APPENDIX B ........................................................................................................................................ 10.1 10 .1

10.1

DT Jordan

FUZZY REASONING ................................................................................................................................. 10.1

2008

i

List of Figures

LIST OF FIGURES Figure 1-1 Remote Controlled UAV..................................................... ...................................................................................................... ................................................. 1.2 Figure 1-2: Predator Medium Altitude Long Endurance UAV [17] ...................................................... ...................................................... 1.2 Figure 1-3: RQ-4 Global Hawk UAV [19] .............................................................................................. 1.3 Figure 1-4: Iterative development process [13] .................................................................................. 1.5 Figure 1-5: Incremental development process and prototyping [13] ................................................. 1.6 Figure 1-6: Design documentation framework [5].............................................................................. [5].............................................................................. 1.7 Figure 2-1: Simulation environment .................................................................................................... .................................................................................................... 2.2 Figure 2-2: UAV fuzzy controller autopilot user interface ................................................................... ................................................................... 2.6 Figure 3-1: Human controlled process......................................................... ................................................................................................. ........................................ 3.2 Figure 3-2: Fuzzy controller controlling a process ......................................................................... ............................................................................... ...... 3.3 Figure 3-3: 3 -3: Example of 15 membership functions: ................................................. .............................................................................. ............................. 3.6 Figure 3-4: Graphical construction of control signal with a Matlab generated interface [12] ............ 3.7 Figure 3-5: One input, one output rule base with non-singleton output sets..................................... 3.9 Figure 3-6: Example of a Mamdani controller ..................................................................................... ..................................................................................... 3.9 Figure 3-7: Example FLS controller .............................................................................................. .................................................................................................... ...... 3.10 Figure 3-8: Interpolation between two lines (a), in the interval of overlap of two membership functions (b) ............................................................................................................................. ....................................................................................................................................... .......... 3.11 Figure 3-9: Sugeno interface with w ith singleton output ............................................... .......................................................................... ........................... 3.11 Figure 3-10: Control surface that corresponds to the rule base in Figure 3-4 .................................. 3.12 Figure 3-11: Phase trajectory with matching fuzzy controller output ............................................... 3.12 Figure 3-12: Linear control surface that acts as a summation U=E+CE ............................................. ............................................. 3.14 Figure 3-13: Fuzzy proportional controller ........................................................................................ ........................................................................................ 3.15 Figure 3-14: 3 -14: Fuzzy PD controller ........................................................................................................ ........................................................................................................ 3.15 Figure 3-15: 3 -15: Fuzzy PID controller ....................................................................................................... ....................................................................................................... 3.16 Figure 3-16: Fuzzy incremental control ............................................................................................. 3.17 Figure 3-17: Scaling of a FPD controller ...................................................... ............................................................................................. ....................................... 3.18 Figure 3-18: The axis of movement of a fixed wing aircraft .............................................................. 3.19 Figure 3-19: Aircraft control surface .................................................. .................................................................................................. ................................................ 3.19 Figure 3-20: 3 -20: Aircraft Air craft yaw control ........................................................................................ ....................................................................................................... ............... 3.20 Figure 3-21: Aircraft pitch control ..................................................................................................... 3.20 Figure 3-22: Aircraft roll control ........................................................................................................ ........................................................................................................ 3.21 Figure 3-23: 3 -23: Inner loops of the autopilot .................................................... ........................................................................................... ....................................... 3.22 Figure 3-24: 3 -24: Outer loops of the autopilot ..................................................................................... .......................................................................................... ..... 3.22 Figure 3-25: 3 -25: Simple Sim ple Pitch-altitude hold autopilot .................................................. .............................................................................. ............................ 3.22 Figure 3-26: More complex pitch-altitude pitc h-altitude hold autopilot ................................................................. ................................................................. 3.23 Figure 3-27: System configuration of a framework fuzzy based UAV navigation and control .......... 3.27 Figure 3-28: Altitude error membership functions Figure 3-29: Change in Altitude error membership functions ....................................................................................................................... ....................................................................................................................... 3.29 Figure 3-30: Airspeed membership functions Figure 3-31: 3-31: Elevator Elevator membership functions....... 3.29 Figure 3-32: Throttle command membership functions ................................................................... ..................................................................... 3.29 Figure 3-33: Change of heading error membership functions Figure 3-34: Heading error membership functions 3.30 Figure 3-35: 3 -35: Roll angle membership functions ...................................................... .................................................................................. ............................ 3.30 Figure 3-36: Plane passing through a target point ............................................................................ 3.30 Figure 3-37: Change of altitude ......................................................................................................... ......................................................................................................... 3.31 Figure 3-38: Forces Fo rces acting on a plane during a turning ..................................................................... 3.32 Figure 3-39: Heading error membership functions Figure 3-40: 3 -40: Roll angle membership functions 3.33 Figure 3-41: change of roll angle membership functions .................................................................. .................................................................. 3.33 Figure 3-42: The control co ntrol surface ........................................................................................................ ........................................................................................................3.34 DT Jordan

2008

ii

Table of Contents

Figure 3-43: Test case 1 ..................................................................................................................... 3.34 Figure 3-44: Autopilot controller structure ....................................................................................... 3.35 Figure 4-1: Aerosonde UAV.................................................................................................................. 4.2 Figure 4-2: Navion general aviation airplane ....................................................................................... 4.2 Figure 4-3: Aerosim UAV Simulink Blockset......................................................................................... 4.3 Figure 4-4: Internal structure of an aeroplane model within the Aerospace Blockset ....................... 4.4 Figure 4-5: Time variation of the altitude of the UAV during the transatlantic flight ......................... 4.5 Figure 4-6: Aerosim's Simulink Blockset for Flightgear 0.9.8 ............................................................... 4.6 Figure 4-7: Interface to specify controller inputs/outputs .................................................................. 4.7 Figure 4-8: Interface to specify membership functions ....................................................................... 4.7 Figure 4-9: Interface to specify rules ................................................................................................... 4.8 Figure 4-10: High level system block diagram ..................................................................................... 4.8 Figure 4-11: Fuzzy altitude controller with inputs and outputs .......................................................... 4.9 Figure 4-12: Properties of the Mamdani fuzzy controller ................................................................... 4.9 Figure 4-13: Altitude error membership function Figure 4-14: Change of altitude error membership function 4.10 Figure 4-15: Airspeed membership function ..................................................................................... 4.10 Figure 4-16: Throttle membership function Figure 4-17: Elevator membership function ............ 4.10 Figure 4-18: Fuzzy latitude longitude controller with inputs and outputs ........................................ 4.12 Figure 4-19: Heading error membership function ............................................................................. 4.12 Figure 4-20: Change of heading error ................................................................................................ 4.12 Figure 4-21: Roll angle ....................................................................................................................... 4.13 Figure 4-22: Flightgear 0.9.8 properties block ................................................................................... 4.14 Figure 4-23: Starting Flightgear in external mode to accept connections from Matlab ................... 4.14 Figure 5-1: UAV framework setup ....................................................................................................... 5.1 Figure 5-2: Aerosonde UAV block properties ...................................................................................... 5.2 Figure 5-3: Connection with Flightgear setup...................................................................................... 5.3 Figure 5-4: FlightGear 0.9.8 Interface Blockset properties.................................................................. 5.3 Figure 5-5: Invoking Flightgear to accept UDP connections using the command in the Aerosim User guide .................................................................................................................................................... 5.4 Figure 5-6: Obtaining inputs and outputs for the Altitude fuzzy logic controller................................ 5.5 Figure 5-7: Altitude fuzzy logic input parameter calculator subsystem .............................................. 5.6 Figure 5-8: Altitude fuzzy logic controller block properties ................................................................. 5.6 Figure 5-9: System with bank angle stabilizing PI controller ............................................................... 5.7 Figure 5-10: Bank Angle to Aileron PI system ...................................................................................... 5.8 Figure 5-11: Loading a FIS structure into the Workspace.................................................................... 5.8 Figure 5-12: Editing the Simulation configuration parameters ........................................................... 5.9 Figure 5-13: Editing the configuration parameters to allow for the execution of FIS systems ........... 5.9 Figure 5-14: Changing the controller properties block to enable execution ..................................... 5.10 Figure 5-15: The controller properties block of the new Sugeno type controller ............................. 5.10 Figure 5-16: Modified Simulink diagram with optimised Altitude controller inputs and outputs .... 5.11 Figure 5-17: Modified altitude error membership function .............................................................. 5.12 Figure 5-18: Modified change of altitude error membership function ............................................. 5.12 Figure 5-19: Modified Altitude fuzzy logic input parameter calculator subsystem ........................... 5.13 Figure 5-20: Control Surface of altitude controller ............................................................................ 5.14 Figure 5-21: Obtaining inputs and outputs for the heading fuzzy logic controller............................ 5.15 Figure 5-22: Latitude-Longitude fuzzy logic input parameter calculator subsystem ........................ 5.16 Figure 5-23: Latitude- Longitude controller block properties............................................................ 5.16 Figure 5-24: Converting the Roll angle command to an aileron command with a PI controller ....... 5.16 Figure 5-25: Modified Heading error membership function ............................................................. 5.17 Figure 5-26: Final change of heading error membership function .................................................... 5.17 DT Jordan

2008

iii

Table of Contents

Figure 5-27: Control Surface of latitude-longitude controller ........................................................... 5.19 Figure 5-28: System shown when opening the “Fuzzy_controller_for_UAV.mdl” file...................... 5.21 Figure 5-29: Changing the time of day settings in Flightgear ............................................................ 5.22 Figure 6-1: System test plan................................................................................................................. 6.1 Figure 6-2: Indication of UAV banking to the left ................................................................................ 6.3 Figure 6-3: Altitude plot for user interface test Figure 6-4: Bank angle plot for user interface test 6.4 Figure 6-5: The altitude plot for 1050m set point ............................................................................... 6.7 Figure 6-6: The airspeed plot for a 1050m set point ........................................................................... 6.7 Figure 6-7: Output of "current altitude" scope for test 2 .................................................................... 6.8 Figure 6-8: Output of the “Current airspeed” scope for test 2 ............................................................ 6.9 Figure 6-9: Output of "current altitude" scope for test 3 .................................................................. 6.10 Figure 6-10: Output of the “Current airspeed” scope for test 3 ........................................................ 6.10 Figure 6-11: Output of "Current Heading" scope for test 4 ............................................................... 6.11 Figure 6-12: Output of the “Current airspeed” scope for test 4 ........................................................ 6.11 Figure 6-13: Output of "Current Heading" scope for test 5 ............................................................... 6.12 Figure 6-14: Output of the “Current airspeed” scope for test 5 ........................................................ 6.12 Figure 6-15: Output of "Current Heading" scope for test 6 ............................................................... 6.13 Figure 6-16: Output of the “Current airspeed” scope for test 6 ........................................................ 6.13 Figure 6-17: Output of "Current Heading" scope for test 7 ............................................................... 6.14 Figure 6-18: Output of the “Current airspeed” scope for test 7 ........................................................ 6.14 Figure 6-19: Output of "Current Heading" scope for test 8 ............................................................... 6.15 Figure 6-20: Output of the “Current airspeed” scope for test 8 ........................................................ 6.15 Figure 10-1: Two definitions of the set of "tall people" .................................................................... 10.2 Figure 10-2: Union of two fuzzy sets A and B .................................................................................... 10.2 Figure 10-3: Intersection of two fuzzy sets A and B........................................................................... 10.3 Figure 10-4: Fuzzy compliment of A and B ........................................................................................ 10.3 Figure 10-5: Hedging on the linguistic variable "young" ................................................................... 10.4 Figure 10-6: Fuzzy AND truth table Figure 10-7: Boolean AND truth table ................................. 10.5

DT Jordan

2008

iv

List of Tables

LIST OF TABLES Table 1-1: Deliverables.........................................................................................................................1.7 Table 3-1: Relational based format of rule base.................................................................................. 3.4 Table 3-2: Linguistic based table of rule base ...................................................................................... 3.5 Table 3-3: Two input, single output FAM table: ................................................................................ 3.12 Table 3-4: Relationship between the linear fuzzy and PID gains ....................................................... 3.18 Table 4-1: Aerosonde UAV specifications ............................................................................................ 4.4 Table 4-2: Altitude Fuzzy Controller FAM 1 .......................................................................................4.11 Table 4-3: Altitude Fuzzy Controller FAM 2 .......................................................................................4.11 Table 4-4: Altitude Fuzzy Controller FAM 3 .......................................................................................4.11 Table 4-5: Latitude-Longitude Fuzzy Controller FAM ........................................................................ 4.13 Table 5-1: Altitude error membership function linguistic variables and their values ....................... 5.12 Table 5-2: Change in altitude error membership function linguistic variables and their values....... 5.12 Table 5-3: Elevator membership function linguistic variables and their values ................................ 5.12 Table 5-4: Altitude Fuzzy Controller FAM .......................................................................................... 5.13 Table 5-5: Heading error membership function linguistic variables and their values ....................... 5.18 Table 5-6: Change in heading error membership function linguistic variables and their values ...... 5.18 Table 5-7: Roll angle membership function linguistic variables and their values.............................. 5.18 Table 5-8: Modified latitude-longitude fuzzy controller FAM ........................................................... 5.19 Table 6-1: Sustained forward flight mode test .................................................................................... 6.2 Table 6-2: Procedure to test the user interface................................................................................... 6.3 Table 6-3: Process to test the accuracy of the controller .................................................................... 6.5 Table 6-4: Process to test the response against different weather conditions ................................. 6.16 Table 6-5: Test results ........................................................................................................................ 6.21 Table 9-1: ECSA engineering outcomes [16] ........................................................................................ 9.1 Table 10-1: Logical operators symbols .............................................................................................. 10.4

DT Jordan

2008

v

List of symbols are abbreviations

LIST OF SYMBOLS AND ABBREVIATIONS SYMBOL/ ABBREVIATION

3-D ACM API BOA CAA COG COGS DUBSI ECSA FAA FAM FDC FINC FP FPD FPD+I GUI HIL ICAO IDE IEEE INS Kbps LM MALE MIMO MOM NB Neg NM OS PB PD PID Pos RC RM SBC SISO TBA TCP/IP UAV UCAV

DT Jordan

MEANING

Dirty, dull and dangerous Association for computing machinery Application programming interface Bisector of area Civil aviation authority Centre of gravity Centre of gravity method for singletons Dutchroll Blockset for Simulink Engineering council of South Africa US Federal Aviation Administration Fuzzy associative memory Flight dynamics and control fuzzy incremental controller Fuzzy proportional Fuzzy proportional derivative fuzzy proportional integral Graphical user interface Hardware in the loop International Civil Aviation Organisation Integrated development environment Institute for electrical and electronic engineers Inertial navigation system Kilobytes per second Leftmost maximum Medium-altitude long endurance Multiple-input-multiple-output Mean of maxima method Negative Big Negative Negative Medium Operating systems Positive Big Proportional derivative Proportional, integral derivative Positive Remote controlled Rightmost maximum Single boarded computer Single-input-single-output To be announced Transmission control protocol/Internet protocol Unmanned aerial vehicle Unmanned combat air vehicle

2008

vi

Chapter 1: Problem Statement

1

CHAPTER 1: PROBLEM STATEMENT

1.1 INTRODUCTION AND BACKGROUND The fixed wing aircraft has proven itself extremely useful in many fields since its invention by the Wright brothers. These fields range from military and commercial use, to aiding in the conduction of scientific research. The invention of the unmanned aerial vehicle (UAV) has further expanded the use of the aircraft. UAVs are typically controlled with the aid of programmed flight plans, and onboard control systems. They are usually classified into the following main groups [7]: 1. Combat: These aircraft are usually used to provide attacking ability for high-risk missions, where it might be dangerous to use a manned aeroplane. This type of UAV is commonly referred to as the unmanned combat air vehicle (UCAV). 2. Research and development: Here, the UAVs are commonly used to further expand and develop existing UAV technologies. This will allow the UAVs to further expand into other fields. An example of this is the use of UAVs to test aircraft in various detrimental situations. In most cases, the used of a manned aircraft would have probably put a pilot’s life in jeopardy. 3. Civil and commercial uses: The scope of UAVs in commercial and civil usage is extremely vast. These range from the hobbyist fling micro RC airplanes, to the use of the UAV to record sports games from a birdseye-view perspective. 4. Reconnaissance: In this area, the UAVs are used to intelligently monitor and gather information in e.g. military zones. 5. Target and decoy: During military training sessions, a UAV might be used to simulate aircraft behaviour. This type of simulation could be used for e.g. target practice. For the reasons mentioned above, UAVs are often said to perform the dull, dangerous and dirty jobs, and UAV missions are often called 3-D missions. According to Col. John Burke, a UAV specialist in the United States Army [8], UAVs can perform dull but sometimes necessary tasks like flying a specific flying pattern for reconnaissance. They can go into certain dirty environments, where there are possible threats of been exposed to dangerous environments like chemical, biological or nuclear threats. They can further be sent on missions into dangerous environments. The major advantage of these aircraft is that many limitations associated with manned aircraft are no longer a constraint. With manned aircraft, the flight duration of many missions, as well as the success of the mission is usually dependant more on operator constraints like pilot fatigue. Many aircraft accidents are usually based on pilot error relating to fatigue [10]. Many fixed wing aircraft accidents in the 1980s are related to pilots been awake for more than 12 hours prior to the accident. For this reason, the US Federal Aviation Administration (FAA) has set out strict rules and regulations relating the amount of rest that pilots should have, to the expected flight duration. DT Jordan

2008

1.1


With more “dull” missions, fatigue is reached faster in comparison to other more exciting missions, and human performance decreases as a function of flight hours. With UAV missions, the UAV is just as alert in the first hour of flight as in the last. For this reason, the endurance of a UAV aircraft is more dependent on the percentage of fuel burned as a function of total weight. The size of the aircraft is also greatly reduced, since they do not have to have the pilot on board. According to Dr Greg Addington, the air vehicles directorate program manager for propulsion integration [9], the size of a UAV is dependent on three aspects, mainly: • Mission requirements, such as the range, speed etc. • The payload requirements, such as the weapon requirements etc. • The propulsion path flow length of the aircraft, which is responsible for providing lift for the aircraft. Current UAV research programs are focusing on developing small UAVs (2-5kg) that are capable of taking off from a small truck. Typical remote controlled (RC) aircraft can be easily carried by a single person.

Figure 1-1 Remote Controlled UAV

The United States UAV programs are typically associated with using these types of aircraft for surveillance purposes [11]. Using this type of technology is much cheaper than using satellites. A number of air forces have UAVs as part of their fleet. The most popular of these include the Predator and the Global Hawk.

Figure 1-2: Predator Medium Altitude Long Endurance UAV [17]

The Predator has been used in the United States military since 1995, and is classified as been the militaries medium-altitude long endurance (MALE) unmanned aircraft system. The Predator has been used in combat in various zones such as Afghanistan, Iraq and Serbia. The aircraft can be used for reconnaissance purposes, and is also capable of carrying two missiles for combat purposes. The total USA military Predator programme consists of four aircraft, a satellite communication li nk, and a ground control station. The total crew working on the programme consists of about 55 people. The cost associated with the early development Predator is approximately $3.2 million per aircraft.

DT Jordan

2008

1.2


Figure 1-3: RQ-4 Global Hawk UAV [19]

The United States military added the RQ-4 Global Hawk UAV to her fleet in 2006 as an improvement of the Predator. This UAV has improved surveillance capabilities compared to its predator predecessor, and is mainly used for surveillance purposes. It is also the first UAV to be certified by the FAA to fly on its own. The aircraft has become so popular that many other air forces have shown increasing interest in the UAV. Each Global Hawk costs approximately $132 million. Although the aircraft advantages indicate that there is a vast scope for the uses of UAVs, they also come with their disadvantages. These will usually result if the control system controlling the plane fails, resulting in the possibility of the UAV crashing. This could put the lives of the general public at jeopardy. With the constant improvement of computer processing power, it can be said that the advantages far outweigh the disadvantages of UAVs and that there is scope for developing a system that will encapsulate the advantages. For this reason, most of the current research in UAVs is focused on incorporating autonomy into the aircraft. This is mainly focused on the ability of the aircraft to make decisions without any human intervention. It is said that this is the bottleneck for future developments in the industry. Research into autonomy is separated into the following fields [7]: 1. Communications: Here, the core focus is handling communication between multiple agents. 2. Trajectory Generation: Given a certain path from one point to the other, the focus here is to determine the best control manoeuvre to follow the path. 3. Motion planning: Determine the most optimal path, given certain constraints. 4. Sensor fusion: This involves combining the information obtained from different sensors to use for further analysis. 5. Scheduling and task allocation: Using the time and equipment constraints, an optimal distribution of tasks among various agents is addressed. DT Jordan

2008

1.3


6. Cooperative tactics: An optimal distribution of sequences between agents is addressed to increase the success of a mission. All of the above can ultimately lead to the ability of the aircraft control to mimic human behaviour. This mini-dissertation will fall under the unmanned aerial vehicle research group at the University of Johannesburg.

1.2 PROBLEM STATEMENT The full power of the UAV comes into their ability to fly without any human intervention. This can be accomplished with the aid of control systems, which will influence the behaviour of the aircraft by changing the outputs according to rules that depict how the aircraft should react. Classical control theory makes use of a mathematical model of the system, in the form of differential or state space equations, to define a relationship that transforms the output of the system to that of a desired state. The major drawback of classical control theory is that it requires a mathematical model of the system. With larger systems, it is often extremely difficult to formulate the mathematical model of the system, as the model is often nonlinear. Modelling the system can become extremely expensive as the size and complexity of the system increases. In most control systems, the common used controller is the proportional-integral-derivative (PID) controller that adjusts the output of the system according to the following equation:

=ሺ  ∙ ሻ+൬  ∙න ሺ ሻ ൰+ ൬ ஽ ∙ ൰ Where: • • • •

KP KI KD e:

Proportional constant Integral constant Proportional constant Error term

The main advantage of the PID controller is that it does not require a mathematical model of the system, and the constants are easily tuneable using various formalised tuning techniques, however it usually assumes that the system been modelled is linear. Fuzzy controllers also do not require a mathematical model of the system, and rather replaces it with a set of if-then rules. These rules generally only describe a small section of the whole system. The main advantage of using a fuzzy controller is that the automatic process control mimics the conscious behaviour of human operators, whether the process is linear or not. As Lotfi Zadeh, the mathematician regarded to be the father of fuzzy logic, stated " In almost every case you can build the same product without fuzzy logic, but fuzzy is faster and cheaper [20]." In terms of automatic control of a UAV, the problem that arises is if it is possible to develop an autopilot that mimics human behaviour. The controller should also be cheap enough, and should be easy to integrate with the aircraft.

DT Jordan

2008

1.4


1.3 THE PROJECT OBJECTIVE Fuzzy logic has made it possible to make decisions with simple if-then rules. This type of logic mimics the human thinking process and forms part of many artificial intelligence solutions. As mentioned in Section 1.2, the main advantages of using fuzzy controllers are • The mathematical modelling of the system need not be known • The controller mimics human behaviour The objective of this project is thus to develop a fuzzy controller autopilot for a UAV fixed wing aircraft. The fuzzy controller autopilot should be tested in a simulation environment that will mimic the behaviour of the aircraft in real life. If further time allows, the controller will be verified with hardware in the loop (HIL) simulation. If further time allows, the controller will be physically implemented in the form of a single boarded circuit (SBC).

1.4 SCOPE OF THE PROJECT The project will be limited to developing an autopilot for a fixed wing aircraft to sustain forward flight. The project will also have the following constraints: • The autopilot controller should be a fuzzy controller • The autopilot should be limited to keeping the aircraft in sustained forward flight. Furthermore, the main part of the project should be limited to simulating the controller. As mentioned in the section above, the implementation of the controller with a HIL simulation as well as that of a SBC is a growth option of the controller dependant on time constraints.

1.5 DESIGN METHODOLOGY TO BE FOLLOWED The success of any project requires a good design methodology. For this project the agile methodology will be used [13]. This method focuses on the recursive development of increments throughout the lifecycle of the project. Typical approaches involved with processes that use agile methodologies are shown in Figure 3 and Figure 1-4.

Figure 1-4: Iterative development process [13]

DT Jordan

2008

1.5


Figure 1-5: Incremental development process and prototyping [13]

In the agile process, each iterative phase consists of planning, design, implementation, testing as well as the documentation of a system increment. Activities involved during each iteration phase should be completed 100% by the end of the process. The main advantage of this is that after completing each phase, it is clearer to see the overall progress of the project. Frequent contacts with the client enable the engineer to have a clear understanding of the requirements of the project. These can range from the initial high level user requirements acquired in the initial phase of the project, to emergent requirements acquired further on in the development process. Traditional design methodologies focus on the initial goal of capturing all the known requirements early in the development process. The main reason for this is because systems are often very difficult to modify after requirements immerge later on in the development process. With agile processes, the requirements evolve during the system development phase. However, the timescale allocated for a project does not change. The requirements for each phase are captured in the most minimal form possible i.e. just enough to allow the development of each phase to be tested efficiently. For any agile development process to work, it is crucial to start development with the core, most important features. These features should be developed as early as possible in the development process. It can be said that the agile method is the constant cycle of the analysing, developing and testing steps. Using this methodology will result in reducing the risk of the overall project, since the engineer is constantly aware of the parts of the project have been completed. The development process often leads to an increased value of the overall product. This is because incremental development results in the possibility of releasing a product when it is deemed well enough, rather than waiting for the entire product to be released. The budget is used more efficient with agile methodology, then with other methodologies. This is because there is still a possibility of releasing an early version of the product, even if the budget is exceeded. Other design methodologies often lead to the scrapping of the entire project if allocated costs are exceeded. Part of the purpose of this project is to prove that the student has achieved the first five outcomes as set out by the Engineering council of South Africa (ECSA) [16]. For this reason, attention will be placed on each of these five outcomes during the project life cycle phase. For more information on the ECSA outcomes, please refer to Appendix A.

DT Jordan

2008

1.6


1.6 DELIVERABLES The deliverables as given in Table 1-1 will be submitted for evaluation: Table 1-1: Deliverables

ACTIVITY

WHEN

Hand in chapter 1 and the project management plan Hand in chapter 2,3 Deliver first seminar Hand in chapter 4 Hand in chapter 5,6 Delivery of second seminar Hand in draft version of minidissertation (one copy for evaluation by study leader) Hand in mini-dissertation Oral Examination

As soon as possible

Conference date to be announced Last day of block week First Friday day of fourth term Conference date to be announced Last day of fourth day

First day of Exam During the normal examination time period, to be arranged with study leader

DATE

3 March 2008 7 April 2008 TBA 30 May 2008 12 September 2008 TBA 24 October 2008

3 November 2008 3-21 November 2008

1.7 OVERVIEW OF THE DOCUMENT The design of the project will be split up into the following sections as given in Figure 1-6

Figure 1-6: Design documentation framework [5]

Each phase for the design will consist of the following areas: •

During the project management process, the required management processes are set to successfully complete the design process. Throughout this process, risks are identified and planned, as well as monitoring plans and contingency plans set. The plan will further contain financial considerations, as well as any equipment procurement processes.

DT Jordan

2008

1.7


•

In the problem statement phase, the problem is introduced. The objectives of the design project are addressed, as well as the context it falls under. The scope of the project is further included in this section.

•

The requirements analysis phase follows up the problem statement phase. Here, the problem is further analysed. The project requirements are listed, as well as the quality and performance specifications.

•

Next, the Literature review phase follows up on the problem statement. Here, the issues involved are further understood, as well as available knowledge collected.

•

For the design phase, all the previous gained knowledge is used to create design options for the solution. Designs are weighed against the requirements, and one design is chosen as the final design.

•

In the implementation phase, the final chosen design is implemented and made to work.

•

The results phase consists of a critical evaluation of the chosen design, with constant reference to the requirements.

•

Finally in the conclusion phase, the success of the project is critically judged.

To accomplish all of the above project requirements, the document is to be split up into seven chapters. These will consist as follows: Chapter 1 will introduce the reader to the work to be presented. The reasons for the project are

explained, such as the actual problem and why it is a problem. The extent to which the problem is going to be addressed is further addressed, as well as the benefits of solving the problem. Next, the requirements analysis phase will be represented in C hapter 2. This will consist of analysing the problem in more detail. Here, it will be addressed how the problem is intended to be solved, as well as any known constraints that will affect the solution. The literature review will address the current state of technology surrounding the project. This will be represented in C hapter 3. This will entitle the collection of anything that will help in solving the problem. Facts that were collected during the design phase will be used to design the proposed solution. This is to be presented in C hapter 4. Tests to be later performed are also included in this section. A design is chosen, and this is to be implemented during the implementation phase. This section is to include steps in implementing the design, as well as issues that were encountered. This is presented in Chapter 5. The results of the implemented solution are then discussed in C hapter 6. These include indicating that the proposed design actually works. Finally, Chapter 7 is the conclusion of the project, which ties the whole project together, from beginning to end.

DT Jordan

2008

1.8


1.8 CONCLUSION Fixed wing UAVs have become a part of the aviation family, and are well suited to perform the dull, dangerous and dirty work that is often needed. For this reason, a lot of research is focused on improving their capability and areas of usage. The ultimate goal of all UAV research fields is to eventually get the aircraft to fly without any human intervention. This would minimise human constraints typically associated with manned aircraft missions, like fatigue. However, the trade-off lies in accomplishing the plane to fly with the accuracy of a human, but without having the constraints typically associated with manned flight. Classical as well as modern control system theory allows for the development on an autopilot. However, the design of most control systems requires a mathematical equation relating the input to the output of the system. With larger systems it is extremely difficult to find such an equation. The power in PID and fuzzy controllers are that a mathematical model of the system is not needed. Although the PID controller is the easiest to tune and is the most common controller used in industry, it does not fully mimic the human way of thinking. Fuzzy controllers are based on the theory of fuzzy logic, and represent the human way of thinking. With the aid of a fuzzy controller, it is possible to model a complex system with a few if-then rules. Fuzzy controllers are often cheaper compared to other controllers. The design of a fuzzy controller autopilot will achieve the requirements of keeping a fixed wing aircraft in sustained forward flight. For the purpose of the project, the initial design will be limited to a simulation based project. If further time allows, the controller will be expanded in terms of implementing the controller with a HIL and SBC. To achieve the objectives of the project, a suitable design methodology has to be in place. In this project, the agile design methodology will be used, which focuses on the iterative process of integrating increments into the project. Attention will also be placed on achieving the first five ECSA outcomes. Furthermore, the documentation part of the project will be separated into seven chapters. These range from the initial problem statement, to the conclusion of the project. This mini-dissertation will fall under the unmanned aerial vehicle research group at the University of Johannesburg department of electrical and electronic engineering science.

DT Jordan

2008

1.9

Chapter 2: Requirements Analysis

2 CHAPTER 2: REQUIREMENTS ANALYSIS 2.1 INTRODUCTION The purpose of this chapter is to analyse the problem presented in C hapter 1 in further detail. This will be done by identifying the issues and the constraints associated with the project. These issues will have to be addressed in the design. The first type of constraint that will be identified is the technical constraints associated with the project. This will be done by discussing all the issues and constraints associated with the project. The financial and economic constraints will then be addressed which will focus on how the economic environment will impact the project. Since every engineering project will impact the social environment in some form, the social aspects and constraints of the project will have to be addressed. The legal framework of the project will then be further addressed. Safety aspects of the project will also be addressed. The impact on the environment by any engineering project can result in serious legal consequences. The environmental constraints of the project will be addressed. One of the ECSA outcomes is the appropriate application of ethical aspects to projects. For this reason, ethical considerations associated with the project are to be addressed. Usability considerations and limitations are also to be addressed. Since every project makes use of certain assumptions, the limitations of the assumptions to be made will be addressed. Furthermore, the requirements of the projects will be identified and listed. Quality and performance specifications will be set in this chapter. Although it was stated in Chapter 1 that the agile method will be followed that focuses on the constant incremental development of requirements, it is often better to understand all the issues associated with the project at the beginning to ensure that the project life cycle runs smoothly. This will also lead to a better understanding of the project. This document will also set the high-level user requirements. The emergent requirements will be made visible during the project life-cycle phase. Since the agile process will be used, the requirements stated in this chapter are likely to change during the project life cycle phase.

2.2 IDENTIFIED ISSUES AND CONSTRAINTS 2.2.1 Technical The success of many projects is often related to the technical constraints and the availability of adequate technology to support the project. For this reason the identified issues and constraints are as follows:

DT Jordan

2008

2.1


2.2.1.1 Availability of software libraries

The success of most software and engineering projects is highly dependent on using previously done work and technology. Since this project is highly software based, the availability of software libraries and suitable platforms would result in an efficient use of available technology rather having to redesign them. Procurement of these libraries is often an issue, as legal constraints associated with software usage are often a problem. For this project, the software constraint will be limited to making use of open source software, and software that the electronic and electrical engineering department has already purchased. Software already purchased by the department includes Matlab and Microsoft Visual Studio. 2.2.1.2 Availability of simulation packages

Since this project is mainly simulation based, the availability of a simulation platform is a constraint and a major issue that inhibits the success of the project. The fuzzy controller as well as the aircraft flight is to be simulation based with the connection between the two sub-systems shown in Figure 2-1.

Figure 2-1: Simulation environment

The main purpose of the network connection is to send controller commands between the fuzzy controller and the aircraft simulator, as well as to send current information of the aircraft to the fuzzy controller. The two sub-systems can be run either on the same computer, or be separated on different computers as shown in Figure 2-1. 2.2.1.3 Accuracy of the controller

The accuracy of the controller to sustain forward flight is a technical constraint of the project. Since human pilots are able to control the aircraft in most detrimental situations, the fuzzy controlled autopilot will have to be able to do this also. Also, with autopilots on manned aircraft, the pilot is able to disengage the autopilot in cases of emergencies. With UAVs, the fuzzy controlled autopilot will have to respond to dangerous situations, or alert staff on the ground control station that a problem has been encountered. 2.2.1.4

Processing speed

Since the controller will be implemented on a desktop or laptop computer, the controller will be digitally based. For this reason it will have to sample the current state of the aircraft fast enough, as well as accommodate for any information delays. Asymptotic analysis [21] on the algorithm used will have to be performed on the algorithm implemented to analyse the run time of the algorithm. Furthermore, the network connection speed will have to be fast enough to make sure that there is no significant delay in the system. 2.2.1.5 Availability of adequate suitable aircraft model

In order for the controller to be adequately tested, a suitable aircraft model will have to be made available. This model will also have to communicate appropriate information regarding the current state of the aircraft to the Fuzzy controller. The model should also be able to accept aircraft control commands from the controller.

DT Jordan

2008

2.2


The model should also accurately simulate the dynamics of the aircraft in order for the controller to simulate real life response. However, the equations governing the model are not necessary, as fuzzy controllers do not require them. The model is only needed to simulate the response. 2.2.1.6 Availability of suitable flying conditions

The fuzzy controller will have to work under the entire spectrum of weather conditions experienced in South African skies. For this reason, the accuracy regarding the response of the aircraft under these conditions is vital in order to accurately control the aircraft, as well as to test its robustness. 2.2.1.7 Taking off and landing of the UAV

Since a requirement of the aircraft is to sustain forward flight, in order to test the controller, the aircraft will have to be taken off and landed with the aid of a human controller on the ground control station. 2.2.1.8 Load Shedding

South Africa’s national electricity supplier ESKOM is currently experiencing a problem with the demand exceeding the supply of electricity. For this reason, major technical constraints is the controller as well as the simulation platform failing as a result of the power supply failing. The load shedding can also delay the delivery and the design process. 2.2.1.9

Fuel availability As stated in Chapter 1, the flight duration is usually based on the availability of fuel. For this reason,

the controller will have to efficiently use fuel. The amount of on board fuel available is also a limitation on the manoeuvrability i.e. it might manoeuvring the UAV in the non ideal way might result in the uneconomical use of fuel.

2.2.2 Financial and economic Since the majority of costs of the project are associated with procuring appropriate software, most of the budget will be allocated here. The hardware required is mainly desktop computers and laptops. For this project, the computers available at the department will be used, as well as a personal laptop. Since the department has already procured most of the software needed, the costs associated for any additional software needed will be covered by the UAV research group’s budget.

2.2.3 Social Allowing computers to perform tasks that are usually allocated to humans has numerous social considerations [22]. These include the constant question that the designer has to ask, mainly: Where is the limitation and borderline on what computers are allowed to do? With autopilots replacing the need for a human controller, the question to ask is whether replacing the human controller with an automatic one will have any social implications? Parties arguing for the use of artificial intelligence [24] comment that the availability of intelligent systems will make expert knowledge available to a wider range of the population. In terms of UAVs, this will mean that trained experts will no longer be needed to keep the UAV in sustained flight, and the UAVs can lead to the beneficiation of society. Experts also argue that artificial intelligent systems will allow humans to focus more on activities that are natural to human nature. In modern society, many people spend too much time working, and do not have time to focus on themselves and their family. However current political and economical situations does not allow for this type of utopian life.

DT Jordan

2008

2.3


On the other hand, many people are against the use of using artificial intelligence systems. Replacing the human operator with that of a machine might lead to the potential economic destruction in the form of how society thinks about work, and many people think that a stable economic society cannot exist if only a small fraction of society performs productive work.

2.2.4 Legal The Civil Aviation Authority (CAA) is responsible for ensuring a safe civil aviation environment in South Africa [25]. The CAA sets rules that must conform to those set by International Civil Aviation Organisation (ICAO) which is based in Canada. T here are only very few structured standards set by the CAA for UAVS in South Africa, the standards set by the ICAO will be referenced, mainly the standards set by the United Kingdom [26]. These include legal constraints in terms of the minimum allowed communication link speed between the ground and the UAV, as well as certification procedures. For more information, refer to [26]. The scope of this project is mainly simulation based, and as a result, most of the certification processes associated with certifying the controller will be ignored.

2.2.5 Safety In sustained forward flight, there is a possibility that the aircraft may encounter detrimental situations e.g. engine failure or severe weather conditions. Human pilots are trained to deal professionally with these situations, and thus an equivalent autopilot will have to also. Although UAVS do not have passengers on board, they still pose a safety threat to the general public. This might include hazardous payloads which might pose a significant threat to the general public if the UAV crashes. Even UAVS without payloads are dangerous as they can cause significant injury to the general public if they crash. For this reason, the controller will have to safely control the aircraft.

2.2.6 Environmental impact Society is becoming more aware of environment in the form of air pollution. For this reason, government has set strict laws relating to this. The fuzzy controller should thus efficiently make use of fuel and not make unnecessary manoeuvres. As stated in section 2.2.5 the plane also poses a significant threat to damaging the environment if it crashes.

2.2.7 Ethical considerations In order to investigate the ethical considerations associated with the project, the following key aspects set by professional organisations will be considered: • The national institute of ethics (USA) nine steps to personal ethical decision making [27] • IEEE code of ethics [28] • The engineering council of South Africa code of professional conduct[29] • The ACM code of ethics and professional conduct [30] 2.2.7.1

Facts behind the project As stated in Chapter 1 UAVs perform the dull, dirty and dangerous work and this is their main reason

for their existence.

DT Jordan

2008

2.4


However, many people argue that it is impossible to develop an autopilot that has the accuracy of a human operator. 2.2.7.2 Stakeholders concerned

The major stakeholders concerned with the project are the companies manufacturing the UAVS, as well as the Governmental organisations. The autopilot to be developed will have to conform to the rules and regulations set by the government.Other parties concerned include human UAV operators. Their main concern will probably be that their job of controlling the aircraft will now be replaced by a machine based autopilot. As stated in Section 2.2.3, the general public is a major stakeholder, as the development of any autopilot will influence and affect the economic stability of country. 2.2.7.3

Motivations of the Stakeholders

UAV companies are mainly concerned with the scarcity of human operators. With increasing costs, it is also becoming more difficult to find these operators. The development of an autopilot controller would thus decrease the overall costs needed to operate these UAVs. With a fuzzy controlled autopilot, the controller will mimic a human controller closely, and thus decrease the costs associated with procuring and using human controllers. Flight duration times can increase immensely with an autopilot as fatigue no longer becomes a constraint associated with flight time. A human controller will only be needed to take off and land the aircraft. 2.2.7.4 Alternative solutions

The obvious alternative is the use of a human controller to keep the UAV in sustained forward flight. With this approach, flight duration time will become a constraint. Another alternative is to use a traditional controller that makes use of classical control theory methods. With this approach, the equations representing the dynamics of the UAV will be needed i.e. each type of UAV will have a different type of equation. A PID controller can also be used. This type of controller does not require equations representing the mathematical model of the system, and is commonly use in many control solutions. The disadvantage of this type of controller is that it does not mimic the human approach of controlling systems. 2.2.7.5

Most ethical alternative solution

It is clear that the controller will have to mimic a human controller in order for the UAV to be safe. In terms of controllers, the best approximation is a fuzzy controller. For this reason, the most ethical alternative solution will be using a human controller.

2.2.8 Usability considerations The user interface of the controller will have to include: • An option to engage/disengage the autopilot controller • UAV camera shots • Information indicating control actions the UAV must take A simple user interface of the controller is given in the Figure 2-2:

DT Jordan

2008

2.5


Figure 2-2: UAV fuzzy controller autopilot user interface

2.3 ASSUMPTIONS AND EXCLUSIONS In order to successfully complete these projects, the following assumptions will have to be made:

2.3.1 The use of a simulation based platform One of the advantages of a fuzzy controller is that it does not require the equations representing the mathematical model the system. However, in order to simulate the controller and its response with a UAV, the model of the UAV will be need. Due to time constraints, the model of a UAV will not be investigated. The use of a simulation platform will be used, and will be assumed that the model is accurate in mimicking true aircraft dynamics.

2.3.2 The use of a human controller Since the controller will only be used to keep the UAV in sustained forward flight, it will be assumed that a human controller will be used to take off and land the aircraft. The human controller will then have the option to engage/disengage the auto pilot in sustained forward flight mode.

2.4 REQUIREMENTS SPECIFICATION 2.4.1 Introduction Although it was stated in Chapter 1 that an agile methodology will be used for this project, the baseline requirements that are needed to successfully complete the project need to be addressed.

DT Jordan

2008

2.6


During the results phase, the degree to which the requirements are to be filled will be discussed. To perform this, the flowing requirements will be addressed: • Functional and data requirements • Usability and humanity requirements • Performance requirements such as Speed and latency o o Safety critical requirements The precision and accuracy requirements o Reliability and availability requirements o • The operational requirements such as: Expected physical environment requirements o o Expected technological environment requirements Maintainability and support requirements o • Security requirements • Cultural and political requirements • Legal requirements

2.4.2 Functional and data requirements The controller should have the following functional requirements: 2.4.2.1 Sustained forward flight

The controller should be able to keep a fixed-wing UAV in sustained forward flight for a finite amount of time. The autopilot should be in the form of an altitude and heading hold autopilot. 2.4.2.2

Fuzzy controller

The autopilot controller should be a fuzzy based controller.

2.4.3 Usability and humanity requirements The following look and feel requirements were identified: 2.4.3.1

User interface

The user interface should be a single form based software interface that consists of the following items: 1. Visual model of the UAV 2. Information indicating control actions the UAV must take

2.4.4 Performance requirements The following performance requirements were identified: 2.4.4.1 Speed and latency

1. The fuzzy based controller autopilot should be able to keep the UAV in sustained forward flight, for speeds up to and bellow 105 km/h or 29 m/s. These values were randomly chosen and are subject to change. 2.4.4.2 Safety critical requirements

The following safety critical requirements were identified: 1. The controller should not allow the UAV to fly in airspace other than that specified by the CAA [26] 2.4.4.3

Precision and accuracy requirements

The following precision and accuracy requirements were identified:

DT Jordan

2008

2.7


1. The controller should be accurate to 1.5m and/or 1.5° in accordance with the planned flight path. These values were randomly chosen and their suitability for the job will only be discussed in Chapter 6. Since the agile design methodology was used for this project, changing these requirements later in the project will not inhibit the success of the project.

2.4.5 Operational requirements The following operational requirements were identified: 2.4.5.1

Expected physical environment requirements

The following expected physical and environmental requirements were identified: 1. The fuzzy controller autopilot should control the UAV for wind speeds up to and including 0.5m/s blowing in all possible directions. These values were randomly chosen and their suitability for the job will only be discussed in Chapter 6. Since the agile design methodology was used for this project, changing these requirements later in the project will not inhibit the success of the project. 2.4.5.2

Expected technological environmental requirements

The following expected technological environmental requirements were identified: 1. The controller should be able to operate on a Microsoft Vista or Microsoft XP operating system 2. The controller should be able to operate on a Intel Pentium 4 desktop computer or a Intel Centrino laptop processor

2.4.6 Cultural and political requirements The following cultural and political requirements were identified: 2.4.6.1

User interface resolution

The resolution of the user interface should be 1024×768 pixels to allow for easy visibility.

2.4.7 Legal requirements The following legal requirements were identified: 2.4.7.1

Compliance standards

The following compliance standards were identified: 1. The controller should adhere to all the standards as set by the CAA [26]

DT Jordan

2008

2.8

Chapter 3: Literature Study

3 CHAPTER 3: LITERATURE STUDY 3.1 INTRODUCTION AND OVERVIEW The purpose of this chapter is to provide an overview of the current state of technology surrounding the project. This will mean including all the background theory, applications, and standards applicable to the project. This will contain all that is necessary and relevant to developing the fuzzycontroller autopilot for the fixed wing UAV. The background knowledge and insight gained in this chapter is vital to successfully complete the design phase of the project with an increased confidence. The majority of resources that will be used to complete this project will be book based, as well as previous dissertations and academic journals based. The use of internet based resources will be kept to a minimum, as these are not usually peer reviewed or edited, and thus their accuracy is questionable. To complete this chapter, the relevant background theory and methods will be discussed. Only the theory that has a direct impact on the mini-dissertation will be addressed. Since the implementation of the project will be hardware and software based, these aspects relevant to the project will also have to be discussed. This will also include the availability of the tools, as well as any procurement procedures and problems. An overview of similar work is to be discussed and addressed. This will include a comparison between the previous/existing products and what the dissertation is trying to achieve.

3.2 STANDARDS AND LEGAL CONSIDERATIONS 3.2.1 Standards Since this mini-dissertation is simulation based, standards and legal constraints are not applicable to this project. However, if the fuzzy controller autopilot to be developed was to be used to control a real aircraft, the standards as set by the CAA of South Africa [25] as well as that set by the CAA regarding the guidance of UAV flight rules and regulations [26] are applicable.

3.2.2 Legal constraints The legal constraints applicable to this project will be limited to making sure that all the software packages used is legally licensed, as well as not infringing intellectual property rights regarding the use of previously down work.

3.3 THEORY AND METHODS 3.3.1 Introduction The purpose of this section is to thoroughly discuss all the background theory that will be needed to successfully complete the project. For simplification purposes, only the theory which does not form part of the control theory course syllabus at the University of Johannesburg’s electronic and electrical engineering department will be discussed.

DT Jordan

2008

3.1


3.3.2 PID controllers In most control systems, the common used controller is the proportional-integral-derivative (PID) controller that adjusts the output of the system according to the following equation:

= ௣ ൬ + 1௜ න ሺ ሻ + ௗ ൰

Where: • • • • •

KP

Proportional gain Integral time Derivative time Error term Controller output

௜ௗ

e: u

When dealing with digital controllers, the equation shown above has to be approximated. With a sampling time , the approximation becomes:

௦

ሺ ሻ = ௣ ቆ ሺ ሻ+ 1௜ ෍ ሺ ሻ ௦ + ௗ ሺ ሻ− ௦ሺ −1ሻቇ

The main advantage of the PID controller is that it does not require a mathematical model of the system, and the constants are easily tuneable with the aid of standardised procedures. For information regarding PID controllers, refer to [40].

3.3.3 Fuzzy controllers 3.3.3.1

Introduction

The main purpose of fuzzy-controllers is to try and make machines understand the natural language associated with human reasoning, and behave similar to a human operator [12]. They have been used since the mid 1970s with their first implication been controlling cement kilns and steam engines. Their main advantage is that they are proven quite effective when trying to control nonlinear systems that are difficult to model and are often accompanied by some uncertainties [33]. Fuzzy controllers make use of fuzzy logic developed by Zadeh [36].This uses if-then rules to describe how a human will reasons. A typical diagram of a control process that makes use of a human controller is given in the Figure 3-1:

Figure 3-1: Human controlled process

With fuzzy control, the human operator is replaced with an equivalent fuzzy-controller. A simplified version of this is shown in Figure 3-2:

DT Jordan

2008

3.2


Figure 3-2: Fuzzy controller controlling a process

The method proposed by Jantzen [12] in developing a fuzzy controller consists of the following steps: 1. Design a PID controller 2. Replace the PID controller with a linear fuzzy controller 3. Make the controller nonlinear 4. Fine-tune it 3.3.3.2

Fuzzy reasoning

For more information referring to fuzzy reasoning, refer to Appendix B 3.3.3.3

Fuzzy controller composition

Typical plants that makes use of fuzzy controllers, such as the one represented in Figure 3-2, will typically consist of the following two “if-then” rules (amongst others) [37]: 1. If error is Negative and change in error is Negative then control is Negative Big (NB) 2. If error is Negative and change in error is Zero then control is Negative Medium (NM) There are at least four chief methods for finding controller rules [37]. These are: 1. Expert experience and control engineering knowledge: In this approach, trained experts and operators are questioned in the form of a carefully set out questionnaire. This approach has been used on the cement kiln described in Section 3.2.3.1.

2. Based on the operators control actions: Here, the designer observes the operators control actions, or examines the operators control book, which reveals the input-output relation, as well as the fuzzy if then rules. 3. Based on a fuzzy model of the plant: In this method, the fuzzy control rules are obtained by inverting a fuzzy model of the plant. This is typically only relevant to low order systems, and requires the fuzzy models of the open and closed plant are available. 4. Based on learning: This is a self organising controller that determines the rules itself. Typical fuzzy controllers, like the one presented in Figure 3-2, consists of four overall stages and elements [35]: 1. A rule based: This consists of if-then rules that describe a human expert’s natural language description on how to achieve good control of a process.

DT Jordan

2008

3.3


2. An interface mechanism: This is also sometimes referred to as the interface engine or the fuzzy interface module. This mimics a human expert’s decision on how to best control the process making use of the available knowledge. 3. A fuzzification interface: This part of the controller converts the inputs that the controller has into information that the interface mechanism can interpret and use to activate and apply the available rules. 4. A defuzzification interface: This converts the outputs of the interface mechanism into inputs for the process. 3.3.3.3.1

Fuzzification interface:

The main purpose of this block is to take the controller input, and lookup the relative membership function to derive the appropriate membership grade. 3.3.3.3.2

The rule based:

This section of the controller allows for single-input-single-output (SISO) control, as well as multipleinput-multiple-output (MIMO) control. Typical SISO control assumes that the goal of the controller is to regulate the plant to a specific setpoint. If it is assumed that the controller has two inputs, mainly error and change in error , then typical if-then rules of the process are: 1. 2. 3. 4. 5. 6. 7. 8. 9.

If error is Neg and change in error is Neg then output is NB If error is Neg and change in error is Zero then output is NM If error is Neg and change in error is Pos then output is Zero If error is Zero and change in error is Neg then output is NM If error is Zero and change in error is Zero then output is Zero (2) If error is Zero and change in error is Pos then output is PM If error is Pos and change in error is Neg then output is Zero If error is Pos and change in error is Zero then output is PM If error is Pos and change in error is Pos then output is PB

Where the input signals are: • Error • Change in error And the fuzzy sets are: • Zero • Positive (Pos) • Negative (Neg) • Negative big (NB) • Negative medium (NM) • Positive big (PB) In a simple table based relational format, the rules are as follows: Table 3-1: Relational based format of rule base

DT Jordan

ERROR

CHANGE IN ERROR

OUTPUT

Neg Neg Neg Zero

Pos Zero Neg Pos

Zero NM NB PM

2008

3.4


Zero Zero Pos Pos Pos

Zero Neg Pos Zero Neg

Zero NM PB PM Zero

In Table 3-1, the two left most columns represent inputs to the controller, while the on the right the controller output. Each row represents a rule. Table 3-1 can be compacted even further in the form of a linguistic table given in Table 3-2. This is sometimes also referred to as a fuzzy associate memory table (FAM). Table 3-2: Linguistic based table of rule base

Change in error

Neg

Zero

Pos

Neg NB NM Zero Error Zero NM Zero PM Pos Zero PM PB In Table 3-2, the axis represents the inputs; while the values inside the table represent the outputs. The linguistic variables “and” or “ or” are always defined in pairs. Two common definitions of “ and” and “or” are given in the relationships bellow:

∧ ℬ ≡ min ሺμ ሺxሻ, μℬሺxሻሻ ∨ ℬ ≡ max ሺμ ሺxሻ, μℬሺxሻሻ ∧ℬ ≡ μ ሺxሻ∗ μℬሺxሻ ∨ℬ ≡ μ ሺxሻ+μℬሺxሻ−μ ሺxሻ∗ μℬሺxሻ Or

Another important aspect is to define the entire universe that contains all acceptable measurements. This might include scaling the measured input to a specific interval Standard universe include [12]: • The controller might use real numbers over the interval [-1, 1] • Due to early computers having limited memory, earlier controllers made use of the variables [-6, 6] • One could use the interval [-100, 100], which corresponds to the full percentage range of measurement • The 12 bit conversion of converting an analog signal to its digital representation can be used. This will correspond to the range [0, 4095] • A shifted 12 bit conversion [-2047, 2048] can be used that accommodates for negative numbers The choice of the standard universe to be used is based on the range of the expected inputs to the controller.

DT Jordan

2008

3.5


As stated in Section 3.2.2.2, membership functions can take many forms and shapes. The designer is then left to the task of choosing an appropriate membership function. Generic rules of thumb that apply when choosing membership functions are [12]: • The membership function should have an appropriate range that accommodates the expected range of noise that might be included in the measurement • Overlap of membership functions is desirable • There should be no gap between membership functions • The number of sets in a family is dependent on the width of the membership function An example of 15 membership functions are given in F igure 3-3

Figure 3-3: Example of 15 membership functions:

Equations of some commonly used membership functions include: The Gaussian membership function based on the exponential function:

ଶ ሻ −ሺ − ଴ ௔௨௦௦ሺ ሻ= ቈ 2 ଶ ቉

Where: • • • •

The maximum value is 1 is the independent variable on the universe is the peak relative to the universe is the standard deviation

଴

The bell membership function is given by:

ିଵ ଶ௔ − ଴ ஻௘௟௟ሺ ሻ= ൤1+ቀ ቁ ൨ Where: •

is a usually positive extra value that affects the width of the membership function, as well as the slope of the sides.

DT Jordan

2008

3.6


3.3.3.3.3

The fuzzy interface mechanism:

A graphical construction of the interface represented in Table 3-1 is given in Figure 3-4. In this figure, the error is 0 and the change is error is -50

Figure 3-4: Graphical construction of control signal with a Matlab generated interface [12]

For each rule, the fuzzy interface engine looks up the vertical line where the vertical line interests the membership function. The firing strength indicates the degree of fulfilment of the rules present. In the case of Figure 3-4, the firing strength is given by:

௞ = ,௞ሺ

ሻ∧ ℬ,௞ሺ ℎ

ሻ

Depending on the firing strength, one can determine the activation of a rule. This is typically determined by making use of the multiplication operator * or min. A rule k can be weighted by a weighing factor which is the degree of confidence (this is determined by the designer). Using this, the firing strength is now modified too:

௞ ∈ [0,1]

௞∗ = ௞ ∗ ௞

In the accumulation phase, all the activated conclusions are activated, making use of the max operator. 3.3.3.3.4

The defuzzification interface mechanism:

The resulting set must be converted into a single number. This must be of the form that the plant understands. Several defuzzification methods exist [36]:

DT Jordan

2008

3.7


The Centre of Gravity (COG) method uses the centre of gravity value of the fuzzy set. This is given in the following equation for the discrete case:

Where: • •

௜ሺ ௜

= ∑∑௜ ௜ ሺሺ ௜ሻ௜ሻ௜

is a running point in the discrete universe ) is its membership value in the membership function

In the continuous case, the summation sign is replaced by the integral operation. The centre of gravity method for singletons (COGS) can be used in the case when the conclusions are singletons. This is given by the following equation:

Where: • •

= ∑∑௜௜ ሺሺ ௜௜ሻሻ ௜ሺ ௜

is the position of the singleton in the universe ) is equal to the firing strength of rule

௜

The bisector of area (BOA) method makes use of the abscissa of the vertical line that divides the area under the curve into two equal lines.

௫ =ቊ ቤන௜௡ ሺ ሻ

Where: • • • •

௔௫ = න௫ ሺ ሻ

ቋ

ሺ

is a running point in the universe ) is its membership value in the membership function is the leftmost value of the universe is the rightmost value of the universe

For the discrete case, the BOA method is not defined. In the mean of maxima method (MOM), an initiative choice is made to choose the point with the strongest possibility. The leftmost maximum (LM) and the rightmost maximum (RM) method chooses the left most or right most maximum respectively. An example of a one input, one output rule base with non-singleton output set is given in Figure 3-5:

DT Jordan

2008

3.8


Figure 3-5: One input, one output rule base with non-singleton output sets.

3.3.3.4

Rule based controller

Numerous types of fuzzy controllers have developed over time [12]. This includes the Mamdani , the FLS, and the Sugeno control. The differences between these two will be explained later. With a SISO fuzzy controller, there are the following essential rules: 1. If error is Neg then control is Neg 2. If error is Zero then control is Zero 3. If error is Pos then control is Pos It can be seen that the SISO system has the basic form of a fuzzy proportional controller, as the controller output action has the same sign as the controller input. 3.3.3.4.1

The Mamdani controller:

An example of a Mamdani controller is given in Figure 3-6:

Figure 3-6: Example of a Mamdani controller

DT Jordan

2008

3.9


In Figure 3-6, each rule corresponds to one row. A particular instance of error corresponds to the doted vertical line, while the firing strength is indicated by vertical dashed lines. In the Mamdani controller, the activation function min is applied. For defuzzification, the COGS method is used. 3.3.3.4.2

The Fls controller:

An example of a FLS controller is given in Figure 3-7 :

Figure 3-7: Example FLS controller

The difference between the Mamdani controller and the FLS controller is the activation function “product” is used, which results in a scaling of the conclusion sets. The real FLS controller uses the BOA method for defuzzification, although the one given in Figure 3-7 uses COGS method. 3.3.3.4.3

The Sugeno controller:

The conclusions can be linear or complex functions of the inputs [38]. The general rule structure for this is:

A simple example is:

ሺ ଵ ଵ , ଶ ଶ , … , ௞ ௞ሻ ℎ = ሺ ଵ , ଶ,…, ௞ሻ If error is Zero and change in error is Zero then control y=c

In the example: 1. If error is Large then the output is Line 1 2. If error is Small then the output is Line 2 Figure 3-8 shows the rules interpolating between the two lines, in the interval where the membership functions overlap. The Sugeno fuzzy controller for these rules is shown in Figure 3-9. In

this example the controller applies singleton conclusions, where the accumulation operation is “+” and the defuzzification method is COGS, where the rules interpolate between the two lines:

DT Jordan

2008

3.10


Figure 3-8: Interpolation between two lines (a), in the interval of overlap of two membership functions (b)

Figure 3-9: Sugeno interface with singleton output

Sugeno controllers thus differs from Mamdani controllers in their defuzzification characteristics. With Sugeno controllers, the output is either linear or constant. This type of controller is used when linear or constant controller outputs are acceptable in terms of the controllers requirements. This reduction of controller complexity when compared to the Mamdani controller also leads to faster controller performance due to simplicity in terms of the number of executions required during each execution loop. 3.3.3.5

Table based controller

When dealing with discrete universes [37], it is possible to calculate all the possible thinkable combinations of inputs, before the controller performs any actions. Here, the relation between all possible input combinations and their corresponding outputs are arranged in the form of a table i.e. with two dimensional input and one dimensional output, the result is a two dimensional table. With three inputs, the result is a three dimensional table. With a simple input of error and change in error , the result is a two dimensional table:

DT Jordan

2008

3.11


Table 3-3: Two input, single output FAM table:

With a two-input-two-output FAM table, the control surface is a mesh plot of the relationship between error and change in error, with the control action on the conclusion side, and the inputs on the premise side. This is given in Figure 3-10

Figure 3-10: Control surface that corresponds to the rule base in Figure 3-4

With an overshoot response, after a positive step in the reference, a plot of the point (error, change in error) will follow a trajectory in the table, which spirals clockwise from the lower left corner of the table towards the centre. This is similar to a phase plane trajectory, which is a plot of a variable against its own derivative. An example of a phase trajectory is given in [34]

Figure 3-11: Phase trajectory with matching fuzzy controller output

DT Jordan

2008

3.12


It is important for the designer to make sure that the “resolution” of the table is not too coarse. If this is the case, then limit cycles might occur, which is osc illations about the reference. The table also allows the error to drift away from the centre cell until it jumps into a neighbouring cell with a non-zero control action. To prevent this, bilinear interpolation can be made use of. The definition of bilinear interpolation is as follows: Consider a two-dimensional table, where the computed erro r ‘E’ falls between two neighbouring discreet values in the universe, E i and Ei+1, such that Ei < E < E i+1 and the change in error CE falls between two neighbouring discrete values in the universe such that CE j < CE < CE j+1 The resulting control signal is found by interpolating linearly in the E axis direction between the first pair: And the second pair

And in the CE axis direction,

ሺ ; ሺ, ሻ, ሺ +1, ሻሻ ଶ = ሺ ; ሺ, +1ሻ, ሺ +1, +1ሻሻ = ሺ ; ଵ, ଶሻ ଵ=

Where the function g is linear interpolation, and F ij is the fuzzy lookup table (I, j=1,2,…) A three dimensional table can be easily be reshaped into a two-dimensional relationship representation. This is done by rearranging the table into four columns. The first three representing the three inputs, and the one for the control action u. Jantzen[12] states that limit cycles are unique to non-linear systems. A typical example might be if there is a deadzone such that the plant drifts away from its equilibrium position until a certain point, where the controller takes action to move its back towards its equilibrium. In the phase plane, the limit cycle is defined as a closed and isolated curve. The trajectory must be closed, indicating its periodic nature, and isolated indicating that nearby trajectories converge towards it or diverge from it. When dealing with fuzzy controllers, there are mainly three sources of nonlinearity [12], mainly the rule base, the membership functions as well as the nonlinear input scaling. The rules themselves might lead to nonlinear characteristics. Secondly the interface engine can cause nonlinear characteristics. If the connectives and for the min and max respectively, then this introduces nonlinear characteristics into the system. Thirdly, several defuzzification methods are nonlinear.

∧ ∨

According to Jantzen [12], it is possible to construct a rule-base with linear input-output characteristics. This will consist of taking the following aspects into consideration: •

The designer should make sure that the premise universes are large enough for the inputs to stay within the limits. This must be done to make sure that saturation does not occur. Each premise family should contain a number of terms, with an overlap such that the sum of the membership values for any particular input instance is 1. This is performed by making use of duplicates of symmetric, triangular sets that cross their neighbour sets at the membership value µ =0.5

DT Jordan

2008

3.13


• •

௜, 1 ௜

Since the number of terms in each family determines the number of rules. With singleton conclusions sets , must be the sum of the peak positions. Multiplication has to be made use of for the connective

∧

When using conclusion singletons, it is often an advantage. This is because the rule base becomes equivalent to a plain summation of the inputs.

=+

The following conditions are needed to achieve a fuzzy controller summation , the following conditions have to be fulfilled: 1. 2. 3. 4. 5.

= ሺ, ሻ

equivalent to the

Triangular sets, crossing at m = 0.5 Rules: complete ∧-combination Define ∧ as * Use conclusion singletons, positioned at sum of input peak positions Use sum-accumulation and COGS defuzzification

With the linear controller presented in Figure 3-12

Figure 3-12: Linear control surface that acts as a summation U=E+CE

3.3.4 Linear Fuzzy PID controller The fuzzy PID controller [12] is a fuzzy version of the PID controller. The only difference is with the fuzzy PID controller, the control signal is formulated by means of rules. As stated earlier, the method for designing a fuzzy PID controller proposed by Jantzen [12] is given by: 1. 2. 3. 4.

Build and tune a conventional PID controller Replace it with a linear fuzzy controller Make the fuzzy controller nonlinear Fine-tune the controller

3.3.4.1

Fuzzy Proportional controller

When dealing with discrete time, a proportional controller is defined by:

ሺ ሻ= ௣ ሺ ሻ The fuzzy proportional controller has the following block diagram:

DT Jordan

2008

3.14


Figure 3-13: Fuzzy proportional controller

The noticeable difference between the two controllers is that the FP (Fuzzy Proportional) is that the FP controller has two tuning gains GE and GU, while the crisp one only has 1 The control signal is thus given by:

ሺ ሻ= ൫ ∗ ሺ ሻ൯∗ Where the function f denotes the rule based mapping. It is generally nonlinear, but with the linear approximation:

൫ ∗ ሺ ሻ൯≈ ∗ ሺ ሻ ሺ ሻ= ∗ ሺ ሻ∗ = ∗ ∗ ሺ ሻ ∗ =௣

The control signal is thus given by:

The gains of the fuzzy controller correspond to the gains of the linear controller by the following equation: 3.3.4.2

Fuzzy PD controller

Depending on the plant dynamics, the derivative action might help to predict the future error. The PD controller can make use of the derivative action improve the close loop stability. The equation for the discrete PD controller is given by:

ௗ

ሺ ሻ= ௣ ቆ ሺ ሻ+ ௗ ሺ ሻ− ௦ሺ −1ሻቇ

The possible cases of are now considered: • If =0, the result is a purely proportional controller • If is gradually increased, it will dampen possible ossifications • If is increased too much, the entire system will become overdamped, and the system will start to oscillate again

ௗௗ ௗ

The block diagram of a fuzzy PD controller is given in Figure 3-14:

Figure 3-14: Fuzzy PD controller

In general, the control signal is given by: DT Jordan

2008

3.15


ሺ ሻ= ሺ ∗ ሺ ሻ, ∗ ሶሺ ሻሻ∗

This time, the function f is a rule base mapping, and its surface depends on two variables. When making use of the linear approximation:

ሺ ∗ ሺ ሻ, ∗ ሶሺ ሻሻ≈ ∗ ሺ ሻ+ ∗ ሶሺ ሻ ሺ ሻ= ∗ ∗ ሺ ሺ ሻ+ ሶሺ ሻሻ ∗ =௣ =ௗ

The control signal now becomes:

And the gains are related by:

The linear approximation is only valid for the case when the fuzzy control surface is a plane acting like a summation 3.3.4.3

Fuzzy PD+I controller

The fuzzy PID (FPD+I) controller acts on three inputs, mainly error, integral error, and the change in error. A block diagram of a fuzzy PID controller is given in Figure 3-15

Figure 3-15: Fuzzy PID controller

The controller signal is thus:

ሺ ሻ= ቎ ൫ ∗ ሺ ሻ, ∗ ሶሺ ሻ൯+

௡ ෍௝ୀଵ ሺ ሻ ௦቏∗

Making use of the linear approximation, the control signal now becomes:

ሺ ሻ= ∗ ∗቎ ሺ ሻ+ ሶሺ ሻ+ DT Jordan

2008

௡ ෍௝ୀଵ ሺ ሻ ௦቏ 3.16


The comparing the gains of the fuzzy PID controller with that of a crisp PID controller, the gains now become:

3.3.4.4

∗ =௣ =ௗ = 1௜

∆ ሺ ሻ= ሺ −1ሻ+∆ ሺ ሻ ௦ ⇒ ∆ ሺ ሻ= ௣ ቆ ሺ ሻ− ௦ሺ −1ሻ + 1௜ ሺ ሻቇ

Fuzzy incremental control

The incremental controller adds a change in control signal done by:

to the current control signal. This is

ௗ =0

It can be seen that this was taken from the equation representing the output of a PID controller, with . A block diagram of a fuzzy incremental controller (FINC) is given in Figure 3-16:

Figure 3-16: Fuzzy incremental control

The fuzzy incremental controller is very similar to the FPD controller. As a result, the conclusion in the rule base is now called the change in output (cu), and thus the gain of the output is accordingly GPU, since the control signal is the sum of all the previous increments, then the control signal given by:

ሺሻ ௡ ሺ ሻ= ෍ሺ௝ୀଵ ൫ ∗ ሺ ሻ, ∗ ሶሺ ሻ൯∗ ∗ ௦ሻ

Since the mapping here is usually nonlinear, with a favourable choice of design there can be a linear approximation. This is given by:

௡ ෍ሺ௝ୀଵ ሺ ሻ∗ ௦ሻ+

ሺ ሻ≈ ∗ ∗቎

ሺ ሻ቏

The Table 3-4 gives the relationship between the linear fuzzy and the PID gains:

DT Jordan

2008

3.17


Table 3-4: Relationship between the linear fuzzy and PID gains

Controller

FP FInc FPD FPD+I 3.3.4.5

Kp

1/Ti

Td

GE*GU GCE*GCU GE/GCE GE*GU GCE/GE GE*GU GIE/GE GCE/GE

Tuning of PID controllers

Several tuning methods exist for tuning the PID controllers. These include the Ziegler-Nicholas method, as well as the hand tuning method. For further information regarding tuning the controllers, refer to [12] or [40]. 3.3.4.6 Scaling

= 100

Saturation of the input signal leads to the upsetting on the linearity of the fuzzy controller [12]. A simple example of this is as follows: Suppose that the controller gain has been tuned to for a particular plant. If is set to and tune all the other gains in accordance to Table 34, and keep the proportional gain, differential time, as well as the integral time the same, then the controller saturates.

= 400

To avoid this, and keeping to Table 3-4, a scaling term setting is added:

To

൫ ∗ ሺ ሻ+ ∗ ሶሺ ሻ൯∗ ൫ ∗ ∗ ሺ ሻ+ ∗ ∗ ሶሺ ሻ൯∗ ∗ 1

Where α is the scaling factor. This results in the block diagram given in Figure 3-17 :

Figure 3-17: Scaling of a FPD controller

3.3.5 Aircraft flight and control Aircraft have three axis of rotation, mainly the lateral, longitudinal and vertical axis. These are shown in Figure 3-18:

DT Jordan

2008

3.18


Figure 3-18: The axis of movement of a fixed wing aircraft

It can be seen that the aircraft is free to move in six degrees of freedom [41]. Simple aircraft are controlled by making use of the three control surfaces. These are typically the aileron, the rudder as well as the elevator. Their respective locations on the fixed wing aircraft are given in Figure 3-19. The main function of the control systems is to modify the flow of the air around the aircraft. This is turn twists the aircraft to allow it to rotate around the centre of gravity.

Figure 3-19: Aircraft control surface

3.3.5.1

Yaw control

The movement around the yaw axis is typically controlled by making use of the rudders connected to the aircraft. The effect of this is the generation of a camber on the surface of the vertical stabiliser. Due to this effect, the whole fin is turned so as to be inclined to the flow. The effect of rudder movement on yaw control is shown in Figure 3-21.

DT Jordan

2008

3.19


Figure 3-20: Aircraft yaw control

The force is applied behind the centre of gravity, and as a result the response of the aircraft is movement in the yaw direction. Yaw control is not commonly used as the primary means of changing direction, except when the aircraft is very close to the ground surface. 3.3.5.2

Pitch control

Pitch on the aircraft is typically controlled by means of moving the elevator allocated at the back of the plane. The effect of elevator movement on pitch control is shown in Figure 3-22.

Figure 3-21: Aircraft pitch control

If the elevator is deflected upwards, the angle of attack of the wing is increased. This results in the airflow around the elevator forcing the rear of the aircraft down, and as a result the pitch angle of the aircraft is increased. Similarly, deflecting the elevator downwards results in the pitch of the aircraft decreasing, and the aircraft begins to dive. 3.3.5.3

Roll control

Roll control is achieved by means of the ailerons that are allocated on the wings of the aircraft. The effect of aileron movement on roll control is shown in Figure 3-22.

DT Jordan

2008

3.20


Figure 3-22: Aircraft roll control

The ailerons are operated differentially i.e. as the one goes up, the other one goes down. The roll movement is caused by the difference in lift caused on the two wings. If the right aileron goes up and the right one goes down, the left wing will have a greater lift coefficient, and as a result the aircraft will roll to the right. 3.3.5.4 A coordinated turn

To turn an aircraft as best as possible, the aircraft has to be banked [41]. The lift must be increased so that the vertical component balances the weight of the aircraft, while the horizontal must be of the right magnitude as to provide centripetal force that is required for the turn. To perform the turn, the rudder control is needed to keep the aircraft pointing in the intended direction. Excessive use of the rudder must be avoided, as this can lead to a skidding effect. The model of a particular aircraft will determine the exact amount of aileron and rudder movement required to move the aircraft. In general, a combination of both is needed to execute a perfect turn. 3.3.5.5

Problems with roll control

A major constrained when moving any aircraft is the avoidance of stalling. This very dangerous situation happens when the angle of attack of the wing is too big, and is usually between 14°-16°. When flying at low speeds, and with wing angles close to the stalling angle, a downward deflection of the wing will produce and increase in drag, while the upward aileron deflection will cause a reduction [41]. The result is the aircraft will turn towards the lowered aileron, which is the reverse o f the normal response.

3.3.6 Autopilots The functions of an autopilot of an aircraft can be divided into the following two groups [45]: •

Guidance: These are used to determine the course and speed of the aircraft based on the inputs of some reference system to be followed by the aircraft

•

Control: This is the application of appropriate forces and movements to the vehicle that will establish a form of equilibrium state of the aircraft, as well as restore the disturbed aircraft to an equilibrium state. This is to be done within the aircraft desired limits.

The control loops must ensure that there is a fast and stable response to the commands. They should eliminate the effects of any disturbances. The basic autopilot structure can be divided into two sections, mainly the inner-loop and the outer-loop. The inner loop is presented in Figure 3-28, while the outer loop is presented in Figure 3-29.

DT Jordan

2008

3.21


The control function is done by the inner loop. This controls the pitch as well as the roll altitude of the aircraft. The outer loop guides the aircraft along the desired path.

Figure 3-23: Inner loops of the autopilot

Figure 3-24: Outer loops of the autopilot

It is very important to take into consideration the way in which the autopilot is engaged and disengaged [42]. Incorrect use of this can result in the aircraft having dangerous transient responses. 3.3.6.1

Pitch-Altitude hold autopilot

The block diagram of a simple pitch-altitude hold autopilot is given in Figure 3-30 [46].

Figure 3-25: Simple Pitch-altitude hold autopilot

Where: • • • •

“e” is the voltage applied to the controller “δv” is the voltage applied to the control surface “δe” is the incremental elevator angle “θ” is the resulting change in pitch

The block diagram of a more complex pitch- altitude hold autopilot is g iven in Figure 3-31 [42]

DT Jordan

2008

3.22


Figure 3-26: More complex pitch-altitude hold autopilot

Here, the control variable is:

=+

The controller does not hold the flight angle constant as this changes with the flight conditions. The dynamic compensation block Gc(s) is needed if the requirements are a small steady-state error and a good transient response. The inner loop feedback provides additional feedback and promotes good short period damping.

3.4 TOOLS 3.4.1 Introduction The purpose of this section is to research any tools that will possibly be needed to complete the project. This will include software, hardware and other additional tools. The availability as well as the constraints associated with each tool will also be discussed.

3.4.2 Programming tools 3.4.2.1

Matlab version 7.0

Matlab is a high-performance software package used for technical computing. Features of this program include: • Math and computation • Algorithm development • Data acquisition • Modelling, simulation and prototyping • Data analysis, exploration and visualization • Scientific and engineering graphics • Application development as well as graphical user interface GUI building Matlab’s basic element is the array, and is used across universities as well as in the industry. It also consists of many libraries in the form of toolboxes, which contain functions and methods to solve specific problems. These include the signal processing, control systems, neural networks, fuzzy logic, as well as many other toolboxes. The typical Matlab environment consists of the following sections: • The development environment This is the tools that allows the developer to create Matlab functions and files o • The Matlab mathematical function library This is a vast collection of computational algorithms o

DT Jordan

2008

3.23


• • •

The Matlab language This is a high level language used to perform computations o Graphics This includes the tools to display visually display data in the form of e.g. graphs o The Matlab application programming interface (API) This library allows the developer to write c and Fortran programs that communicate o with Matlab

The following tools are standard with Matlab 7.0. 3.4.2.2 Simulink

Simulation is a section of Matlab that enables the designer to model, simulate as well as analyse dynamic systems. The designer firstly creates a block diagram that depicts the relationship between the systems inputs, outputs and states. The user can then simulate the dynamic system for a finite amount of time. 3.4.2.3

Control systems toolbox

This toolbox in Matlab is a collection of Matlab functions that provides functions for designing control systems. This includes functions to perform complex arithmetic computations such as eigenvalues, root-finding and matrix inversion. 3.4.2.4

Fuzzy logic toolbox

This Matlab toolbox has build in tools that allow the designer to create and edit fuzzy systems. This can be done either within the Matlab framework or in Simulink. C programs can be used to call upon fuzzy systems within Matlab. The design can either be build with command line arguments, or with the aid of a GUI. 3.4.2.5 Aerospace Blockset

This is a Blockset within Simulink to provide aerospace system design, integration as well as simulation. These include environmental models and equations of motion, as well as gain scheduling and animation. 3.4.2.6

Real time workshop

This extension of Matlab and Simulink is used to automatically generate source code from Simulink models to create real time software applications. This includes libraries to automatically generate C code from a Simulink model. 3.4.2.7 c/c++ programming language

C is a high level programming language that was and has been used and standardised since 1985 [49]. This was after it was originally implemented in 1972 at the Bell Laboratories. Most of the code for general purpose operating systems is usually written in C. The c++ language extends on the c language by allowing for object orientated programming. c++ is a hybrid language i.e. the programmer can design software in either a c-like style, an object orientated style or both. 3.4.2.8 The C# programming language

The c# programming language was developed by Microsoft. It is a combination of the c++ language, as well as aspects from other programming languages such as Delphi and Java [50]. It is the most modern language to be included in the Visual Studio package.

DT Jordan

2008

3.24


3.4.2.9

Microsoft Visual Studio 2005

Microsoft Visual Studio 2005 is the main integrated development environment (IDE) developed by Microsoft [48]. It can be used to develop console as well as GUI applications for frameworks supported by Microsoft Windows. The environment has a code-editor, IntelliSense as well as an integrated debugger. Other tools include design tools for designing GUIs. The main languages supported by Visual studio include c/c++ (in Visual c++), VB.NET (in Visual Basic.NET) as well as c# (in Visual c#). The University of Johannesburg has acquired licences to use Visual studio on campus, as well as on student’s personal computers. The only requirement is that the student is registered at the University. From February 2008, Bill Gates initiated project DreamSpark that allows student to obtain Microsoft Visual Studio 2008 for free [51]. However, this service is not yet available to students in South Africa. 3.4.2.10 Dev-C++

Dev-C++ is an open source IDE that can be used to programming in c/c++ [52]. This runs extensively in Microsoft windows.

3.4.3 Aircraft simulation tools 3.4.3.1 X-Plane

X-Plane developed by Laminar research is the world’s most realistic flight simulator [53]. This simulator can be used on personal computers. This includes realistic models of real weather conditions as well as over 40 types of aircraft. Real terrain is also simulated. The software package performs the following steps to propagate the flight [53]: 1. Element break down : 2. Velocity determination 3. Coefficient determination 4. Force build-up 5. Back to step 2 All of the above steps are performed at a rate of 15 times per second. 3.4.3.2

The X-Plane Plug in SDK

This plug in allows developers to write external programs, typically in the c language, that interact with the X-Plane simulator [54]. 3.4.3.3

Microsoft flight simulator

Microsoft flight simulator is arguably the most popular flight simulator amongst the general public [61]. With the earliest version been released as early as 1982, the simulator has evolved much over time. Current versions include: • The ability to download weather simulations based on real data • The ability to download a software development kit to help simulate third party efforts • Ability to connect with virtual pilots over the network The major drawback of the simulator is the difficulty on obtaining open source add-ons. The simulator itself is also not free.

DT Jordan

2008

3.25


3.4.3.4

Flightgear flight simulator

The FlightGear simulator software package is an open source flight simulator development project [60]. The main purpose of this project is to provide a flight simulatorr environment that is specifica lly aimed at the academic environment. The latest version of Flightgear is version 1.0.0. Features of this simulator include: • Ability to run on all major operating systems • Simulation of flight dynamics • Simulation of 20 000 real world airports • Accurate placing of sky features relative to the current computer lock time • Ability to connect with instances of external programs 3.4.3.5 Aerosim Blockset

This Blockset is a Matlab/Simulink block that provides components for the nonlinear rapid development of aircraft dynamic models [59]. It is based on practical experience and is based on the experience encountered during the development process of a dynamic model of a UAV. The features of this Blockset include: • Full simulation of nonlinear aircraft dynamics • Possibility of outputting to Microsoft flight simulator or Flightgear • Complete aircraft models • Ability to generate c code form the Simulink models with the aid of real time workshop 3.4.3.6

The flight dynamics and control (FDC) toolbox

The flight dynamic and control tool contains the Simulink as well as the Matlab tools to simulate flights [55]. The toolbox is open source, and can be accessed through the Simulink interface, or from the Matlab workspace. 3.4.3.7 The Dutchroll Blockset for Simulink (DUBSI)

The DUBSI is a small block-library with general purpose Simulink blocks that can be used for aviation. [56].The main difference with this toolbox and the DUBSI toolbox is that the DUBSI toolbox is not limited to flight dynamic applications.

3.4.4 Fuzzy logic tools 3.4.4.1

Fuzzy–C pre-processor for fuzzy logic

This pre-processor translates a source file that consists of mixed fuzzy logic statements and C statements into pure C code [57]. An external C complier can then be used to compile the code. 3.4.4.2

Fuzzy Interface Systems toolbox for Matlab (FISMAT)

This fuzzy interface systems toolbox for Matlab contains vario us tools are available that help support developing systems [58]. This includes libraries to perform arithmetic operators, fuzzification and defuzzification libraries and algorism, as well as different forms of approximate reasoning. 3.4.4.3

FlouLib

FlouLib contains tools to develop fuzzy systems in Simulink [62]. It was developed by three professors at the Université de Savoie. The toolbox contains a number of tools for developing fuzzy logic systems using the Mamdani fuzzy interface system, or the Takagi-Sugeno fuzzy interface system.

DT Jordan

2008

3.26


3.5 SIMILAR WORK 3.5.1 Introduction The purpose of this section is to identify similar products that have been developed. This will include work done both in the commercial as well as academic environment. The identified work will serve as a bench mark for this mini-dissertation.

3.5.2 A Framework for Fuzzy Logic Based UAV Navigation and Control 3.5.2.1

Background

The purpose of this paper is to develop a fuzzy logic based autonomous navigation and control for a UAV [63]. The system configuration is given in Figure 3-28

Figure 3-27: System configuration of a framework fuzzy based UAV navigation and control

The tools used to complete this project are entirely based in the Matlab environment, while the aircraft is simulated with Aerosim aeronautical simulation block set. The control module is composed of the altitude module, the latitude-longitude module, and the error calculating block. 3.5.2.2

The fuzzy logic control system

All the fuzzy control modules are of the Mamdani type. 3.5.2.2.1 Altitude fuzzy logic controller

The altitude fuzzy logic controller has three inputs: • Altitude error • Change in altitude error • Airspeed The output is the throttle command as well as the elevator command. The linguistic variables describing the inputs of the controller are: • For the altitude error Altitude error negative (AEN) o Altitude error stale (AES) o Altitude error positive (AEP) o • For the change in altitude error o Negative change (NC) Stable change (SC) o Positive change (PC) o • For the airspeed o Small airspeed (SA) Medium airspeed (MA) o Big airspeed (BA) o DT Jordan

2008

3.27


The linguistic variables describing the outputs are: • For the elevator Negative elevator (NE) o Stable elevator (SE) o Positive elevator (PE) o • For the throttle Low throttle (LT) o Medium throttle (MT) o High throttle (HT) o 3.5.2.2.2

Latitude-Longitude fuzzy logic controller:

The latitude-longitude controller has the following inputs: • Heading error • Change in heading error The output is the roll angle of the aircraft The linguistic variables describing the inputs of the controller are: • For the heading error Center 1 (C1) o Too Right (TR) o Right (R) o Center (C) o o Left (L) o Too Left (TL) Center 2 (C2) o • For the change of heading error Negative (N) o o Stable (S) o Positive (P) The linguistic variables describing the inputs of the controller are: • For the roll angle o Too left (TL) Left (L) o Ahead (A) o Right (R) o Too right (TR) o 3.5.2.3

Membership functions

3.5.2.3.1 Altitude fuzzy logic controller

The membership functions of the corresponding linguistic variables are shown in Figure 3-29 to Figures 3-33.

DT Jordan

2008

3.28


Figure 3-28: Altitude error membership functions

Figure 3-29: Change in Altitude error membership functions

Figure 3-30: Airspeed membership functions

Figure 3-31: Elevator membership functions

Figure 3-32: Throttle command membership functions

3.5.2.3.2

Latitude-Longitude fuzzy logic controller

The membership functions of the corresponding linguistic variables are shown in Figure 3-34 to Figures 3-36

DT Jordan

2008

3.29


Figure 3-33: Change of heading error membership functions

Figure 3-34: Heading error membership functions

Figure 3-35: Roll angle membership functions

3.5.2.4

Results and discussion

The first phase of their test results was set at determining the trajectory that will be followed when moving from an initial latitude-longitude to the latitude-longitude values as specified by the setpoint. The results shown in Figure 3-37 show the UAV moving from an initial latitude-longitude of 35.5, 24.15 to 35.3 and 24.6 respectively.

Figure 3-36: Plane passing through a target point

The corresponding UAV altitude is shown in Figure 3-38:

DT Jordan

2008

3.30


Figure 3-37: Change of altitude

Although the results shown in Figure 3-37 are based on the latitude and longitude setpoints it is not sure where the results shown in Figure 3-38 originated, as the paper does not give any indication of the initial altitude and the set point altitude. However, assuming that the set point altitude is approximately 1240m, Figure 3-38 clearly has oscillations around the altitude set point with a peak to peak amplitude of approximately 25m. It is thus assumed that the heading controller works, while the altitude controller clearly results in too many oscillations. The authors of the paper claim that these oscillations are based on the fact that the controller design was based on human pilots experience rather than observations on actual flight performance. As a result, the authors of the paper decided to perform research into developing algorithms for membership functions tuning based on evolutionary genetic methods. Another difference to the project to be implemented is the limitation of the controller in the Simulink environment only. The controller to be developed will probably use an external program to simulate the aircraft in a more visual way.

3.5.3 Roll Control of Unmanned Aerial Vehicles using Fuzzy Logic 3.5.3.1

Introduction

The purpose of this paper is to provide an intelligent approach to the roll control problem associated with UAVs [64]. This is done by assuming that the altitude of the UAV remains relatively constant during the roll transition. In terms of the roll angle movement, there are three different types of motion, namely: • A motion with zero roll angle • A right turn (with a non zero roll angle) • A left turn (with a non zero roll angle) A diagram of the forces acting on a plane during a turn are given in Figure 3-39:

DT Jordan

2008

3.31


Figure 3-38: Forces acting on a plane during a turning

In this paper, the NEARCHOS UAV was used. This is a high payload, medium range and endurance, multi-role inhabitant aerial vehicle. The authors first developed a model of the ideal trajectory. They then ran exhaustive physical tests on the UAV in order to obtain data that will lead to information about ideal UAV trajectories. Next, they designed and implemented the fuzzy controller. The goal of the fuzzy controller is to mimic the ideal UAV trajectory. 3.5.3.2

Fuzzy controller

The fuzzy controller of this UAV is of the Mamdani type. The control system was implemented entirely in MATLAB with the aid of the fuzzy control toolbox. The controller inputs are the roll angle and the heading error. The outputs of the controller are the change of the roll angle. Controller inputs: The linguistic variables that represent the controller inputs are as follows: • For the roll angle Right big (rb) o Right medium (rm) o Right small (rs) o o Zero o Left big (lb) Left medium (lm) o Left small o • For the heading error: o Negative big (nb) o Negative medium (nm) Negative small (ns) o Zero o Positive big (pb) o Positive medium (pm) o Positive small (ps) o Controller outputs: The linguistic variables that represent the controller outputs are as follows: • For the roll command: Right big (rb) o Right medium (rm) o Right small (rs) o o Zero Left big (lb) o Left medium (lm) o Left small o DT Jordan

2008

3.32


3.5.3.3

Membership functions

The membership function of the controller inputs are given in Figure 3-40 and Figure 3-41

Figure 3-39: Heading error membership functions

Figure 3-40: Roll angle membership functions

And the controller output shown in Figure 3-42:

Figure 3-41: change of roll angle membership functions

3.5.3.4

The rule base

The rule base is based on a total of 49 if-then rules. The control surface is given in Figure 3-43:

DT Jordan

2008

3.33


Figure 3-42: The control surface

3.5.3.5

Results and discussion

The goal of the designed controller is to follow the ideal developed trajectory. As a result, a comparison between the two was used as a test bed. Test case one had the results as shown in Figure 3-44, where the continuous lines and discontinuous lines represent the desired and simulated trajectories respectively.

Figure 3-43: Test case 1

Three other test results showed that the controller also follows the trajectory. The results also conclude that the controller is able to handle sharp variations in roll angle, and has very small declinations. Further research of this project includes the optimisation of the rule base using evolutionary algorithms. This will create a robust fuzzy logic controller leading to a better approximation of the ideal trajectory. The design method in this paper uses a unique approach by first creating an ideal trajectory model, and then trying to mimic the model with the aid of the fuzzy controller. An alternative approach might be first creating a model based on observing pilots execution of the trajectory, and then

DT Jordan

2008

3.34


basing the fuzzy model on this approach. This approach was effectively applied to roll control. However, in order to have a fully autonomous navigation system, some sort of control in the longitudinal plane is needed.

3.5.4 Combining fuzzy and PID control for an unmanned helicopter The purpose of this paper is to combine the use of the PID controller and the fuzzy autopilot in developing an autopilot for a helicopter UAV [65]. This will mean that the altitude/ attitude controller is a fuzzy Mamdani controller, while a PID controller is used for the roll, pitch and yaw controller. The control scheme is given in Figure 3-45:

Figure 3-44: Autopilot controller structure

Simulation results have shown that the controller is very accurate when compared to the most realistic model available. There are plans to take the controller further by designing the TakagiSugeno regulator.

3.6 CONCLUSION The use of previously written literature is vital to the success of any project, as this provides a firm foundation for the design and implementation phases that are to follow. Although most projects require some form of legal boundary, this does not really relevant to this mini-dissertation. This is because this project is to be mostly simulation based, and as a result legal standards are not really needed. Fuzzy logic has been used to develop fuzzy controllers since the early 1970s, with the first implication been the controlling of cement c ement kilns. The controller makes use of fuzzy sets, membership functions, linguistic variables as well as if-then rules for the decision process. The major advantages of these controllers are that they do not require a mathematical model of the system to be controlled, and mimic human behaviour very closely. These type of controllers generally consist of four stages, mainly the rule base, the interface mechanism, the fuzzification interface as well as the defuzzification interface. There is not set method or standard for developing a fuzzy controller. The method proposed by Jantzen consists of four steps in designing the controller, mainly designing a PID controller for the process, replacing the controller with a linear fuzzy controller, making the fuzzy controller nonlinear, and then finally fine tuning the controller. Although this method exists, the overall design process still entitles trial and error. Simple aircraft are typically controlled by making use of three control surfaces. The ailerons, rudder and elevator control the roll, yaw and pitch movements respectively. The autopilot to be developed developed will be an altitude and heading hold autopilot.

DT Jordan

2008

3.35


The Matlab environment has many tools that will aid in the implementation as well as experimental process. This includes various internal toolboxes such as the control systems and fuzzy logic toolboxes. A GUI environment that can be used to visualise dynamic systems is also available. Other libraries in Matlab include the aerospace Blockset, as well as the real time workshop. External libraries are also available that can be added to Matlab. Fuzzy support tools include the FISMAT as well as the Floulib toolboxes. External aircraft simulation blocks include the Aerosim Blockset, the FDC toolbox as well as the DUBSI toolbox. Visual flight simulator programs include the X-plane, Microsoft flight simulator, and Flightgear flight simulator packages. High level programming languages include c, c++ and the c# languages. These are usually developed in IDE environments such as Microsoft Visual studio, or the t he freeware Dev C++. Numerous research has focused on applying fuzzy logic and fuzzy controllers to UAVs. Three similar papers to the project are “ A framework for fuzzy based navigation and control” , “Roll control of unmanned aerial vehicles using fuzzy logic” and “Combining fuzzy and PID control for an unmanned helicopter”.

All of the above found literature and tools can aid in the successful completion of the project, and as a result Chapter 4 will focus on the design of the fuzzy controller autopilot for the fixed wing UAV.

DT Jordan

2008

3.36

Chapter 4: Design

4 CHAPTER 4: DESIGN 4.1 INTRODUCTION AND OVERVIEW The purpose of this chapter is to discuss and to provide the design process that will be followed to complete the project. This will be given in the form of functional block diagrams. Furthermore, various variations in the form of high level designs will be discussed. Each functional block in the high level diagram will then be further discussed and described in the form of its specifications, purpose, expected inputs and expected outputs. The detailed design of each component is also to include the maths and physical science describing the component, as well as the use of software and hardware tools that will be used to implement the project. Since it was stated in Chapter 1 that the agile design methodology will be used, that focuses on the rapid develop of system increments, the design of the individual components will not be thoroughly completed in this phase. Since the paper by Doitsidis et al [63] discussed in Section3.5.2 had similar goals to this project, the design as well as the implementation phase will be focused on improving their results obtained.

4.2 DETAILED DESIGN 4.2.1 Components needed In Section 3.4.2., it was stated that Matlabs Simulink is well known and used to design and simulate dynamic systems, and thus makes a very efficient and effective tool for designing control systems. To effectively design the fuzzy controller autopilot for a fixed wing UAV, the following components will be needed: • Standard Simulink blocks including: Scopes o Addition blocks o Multiplication blocks o Etc. o • Adequate model of a UAV in Simulink that has the following inputs: Rudder control input o Aileron control input o Elevator control input o Throttle control input o • Adequate model of a UAV in Simulink with the following block outputs: Outputs of various UAV sensor inertial navigation system (INS) readings o indicating UAV position, orientation and velocity • Adequate model of various physical environments and constraints that the UAV will experience, in the form of Simulink block sets such as: Atmosphere model o Earth model o • Fuzzy controller support in the form of Simulink Blocksets that will consist of interfaces for specifying: Controller inputs o

DT Jordan

2008

4.1

Chapter 4: Design

Controller outputs Controller membership functions and linguistic variables o The fuzzy if-then rule base o Simulink blocks to allow the UAV to be seen graphically in an external flight simulator e.g. Flightgear, X-Plane, Microsoft flight simulator o

•

4.2.2 Tool support 4.2.2.1

The Aerosim Blockset

The Aerosim simulation Blockset, developed by u-dynamics [59], provides various ways of simulating functional blocks used within the aeronautical environment. These Blocksets can be used in Simulink, and thus will be used as the chief design tool. The main advantage of this Blockset is that it is available free of charge for academic and non-commercial use. The Blockset library also includes the model of two aircrafts, mainly the Aerosonde UAV given in Figure 4-1, as well as the Navion general aviation airplane given in Figure 4-2 [66].

Figure 4-1: Aerosonde UAV

Figure 4-2: Navion general aviation airplane

Since one of the requirements of the project is that a model of the UAV will not be investigated, the Aerosonde UAV will be used as provided by the Blockset. It will be assumed that this included model is accurate and correct. The Simulink block of the UAV as well as its inputs and outputs is given in Figure 4-3:

DT Jordan

2008

4.2

Chapter 4: Design

Figure 4-3: Aerosim UAV Simulink Blockset

The block has the following inputs [66]: • Controls= 7×1 vector of the controls of the aircraft [flap elevator aileron rudder throttle mixture ignition]T in the units of [rad rad rad rad frac ratio bool] • Winds = the 3×1 vector of background wind velocities that the UAV will experience. This is given in the navigation frame [WN WE WD ]T , in the units of m/s • RST = this is the integrator reset flag, and can take the value of either 0 or 1. All the integrators are reset on the rising-edge The block has the following outputs [66]: 1. States= the 15×1 vector of the aircraft states [u v w p q r e 0 ex ey ez Lat Lon Alt mfuel Weng ]T 2. Sensors = the 18×1 vector of sensor data [Lat Lon Alt VN VE VD ax ay az p q r pstat pdyn OAT Hx Hy Hz ]T 3. VelW = the 3×1 vector of aircraft velocity in wind axes [V a β α]T in the units of [m/s rad rad] • Mach = the current aircraft Mach number • Angular Acc = the 3×1 vector of body angular accelerations [ ]T • Euler = the 3×1 vector of the attitude of the aircraft given in Euler angles [φ θ ψ] T , in the units of radians • AeroCoeff = the 6×1 vector of aerodynamic coefficients [C D CY CL Cl Cm Cn ]T , in the units of

p ሶ qሶ rሶ

−1

rad

• • • • • • • •

PropCoeff = the 3×1 vector of propeller coefficients [J C T CP ]T EngCoeff = the 5×1 vector of engine coefficients [MAP BSFC P]T given in the units of [kPa kg/s kg/s g/(W*hr) W] Mass = the current aircraft mass, in the units of kg ECEF = the 3 × 1 vector of aircraft position in the Earth-centred, Earth-fixed frame [ X Y Z ]T . MSL = the aircraft altitude above mean-sea-level, in the units of m AGL = the aircraft altitude above ground, in the units of m REarth = the Earth equivalent radius, at current aircraft location, in the units of m AConGnd = the aircraft-on-the-ground flag (0 if aircraft above ground, 1 if aircraft is on the ground).

DT Jordan

ሶ ௔௜௥ ሶ ௙௨௘௟

2008

4.3

Chapter 4: Design

A simplified internal structural model of all aeroplane models within the Aerosim Blockset is given in Figure 4-4 [66]. This also applies to the Aerosonde UAV.

Figure 4-4: Internal structure of an aeroplane mode l within the Aerospace Blockset

From Figure 58, it can be seen that the Aerosonde model takes into consideration the atmosphere and the earth model, as a function of wind velocities, and thus provides an accurate simulation environment. It is also important to note the following important specifications of the Aerosonde UAV [68]: Table 4-1: Aerosonde UAV specifications

Specifications

Weight, wing span Engine Navigation

27-30 lb, 10 ft 24 cc, 1.2 kw, fuel injected using premium unleaded petrol GPS Operation

Staff for Launch and Recovery Staff for Flight Operations Ground Equipment Flight Launch and Recovery Ground & air communications

3 people: Controller, Technician, Pilot/Maintenance 1 Person for up to 3 aircraft Proprietary Staging Box, personal computer (laptop), GPS antenna, aviation and local communications radios Fully autonomous, under Base Command Launch from car roof rack (catapult option), land on belly, Autonomous or with pilot UHF or Satcoms (Iridium) to Aerosonde, VHF to field staff and other aircraft, internet to command center and users. Performance

Speed, Climb 18 – >32 ms-1, Climb >2.5 ms-1 at sea level Range, Endurance with no >1800 miles, >30 h additional payload Altitude Range Up to 20,000 ft (medium weight) Payload Maximum 5 lb with full fuel load

DT Jordan

2008

4.4

Chapter 4: Design

Standard Instrumentation

Temperature, Pressure, Humidity, Wind

2 Vaisala RSS901 Sondes for temperature, pressure and humidity, and a proprietary wind system.

In 1998, the Aerosonde UAV also became the first UAV to cross the Atlantic [69]. The UAV was planned to encounter wind speeds up to a maximum value of 0.5m/s during the mission. The time variation of the altitude of the UAV during the mission is shown in Figure 4-5:

Figure 4-5: Time variation of the altitude of the UAV during the transatlantic flight

4.2.2.2

Flightgear flight simulator As stated in Section 3.4.3.4, the Flightgear flight simulation package provides an accurate and

graphical flight simulation package. Another advantage of this simulation package is that it is possible to start the application in external mode, allowing the aircraft to be controlled with an external program [67]. The aircraft controller can either be located on the same computer as Flightgear, or on a different computer located on the same local network. With the Aerosim Blockset, it is possible to connect to connect to the Flightgear. The Blockset allows the user to connect to Flightgear versions 0.92, 0.9.4, 0.9.6 and 0.9.8. The Simulink block to connect to Flightgear 0.9.8 is given in Figure 4-6. The block communicates with Flightgear by making use of the UDP protocol. However, with the Aerosim Blockset it is not possible to obtain data from Flightgear to be used within Matlab and Simulink.

DT Jordan

2008

4.5

Chapter 4: Design

Figure 4-6: Aerosim's Simulink Blockset for Flightgear 0.9.8

The Blockset inputs most concerned with for this project are the first three, mainly: • Position = the 3×1 vector of geographic position [Lat Lon Alt] in the units of [rad rad m] • Euler = the 3 ×1 vector of Euler angles [φ θ ψ ]T in the units of radians • Airspeed = the current aircraft airspeed, in the units of m/s The only output of the block is a visual representation of the aircraft within Flightgear flight simulator. 4.2.2.3

The fuzzy logic toolbox

Matlab’s fuzzy logic toolbox allows the user to create fuzzy interference systems, as well as provides tools for integrating these fuzzy systems with Simulink. The wizard integrated into this toolbox makes the design of fuzzy systems easier, and includes GUIs to specify the controller inputs/outputs, fuzzy membership functions and fuzzy rule base. These are given in Figure 4-7 to Figure 4-9 respectively.

DT Jordan

2008

4.6

Chapter 4: Design

Figure 4-7: Interface to specify controller inputs/outputs

Figure 4-8: Interface to specify membership functions

DT Jordan

2008

4.7

Chapter 4: Design

Figure 4-9: Interface to specify rules

4.2.3 High level design The high level system block diagram is given in Figure 4-10:

Figure 4-10: High level system block diagram

Although most of the literature discussed in Chapter 3 does not use altitude control and latitudelongitude control as typical autopilots, the paper used by Doitsidis et al [63] uses this approach. Since the goal of this project is to improve their results, the same approach is used. All of the system blocks above will be implemented with the Aerosim Blockset, except Flightgear, which is a separate external application. The choice of the tools to be used is not necessarily fixed, since one of the features of the agile methodology is that the design often changes with emerging requirements. Although the choice of tools for the fuzzy controller is likely to remain fixed, the robustness of the controller can only be tested when integrating it with different UAV models and different environments, such as the X-Plane XPDS developed by Sam Claasen. DT Jordan

2008

4.8

Chapter 4: Design

The Blocksets already described in the sections above are: • The Aerosonde UAV model that is included in Aerosim will be used. This block is given in Figure 4-3 and description given in Section 4.2.2.1 • The Flightgear flight simulation package. • The Flightgear 0.9.8 interface block The remaining functional Blocksets will now be discussed. 4.2.3.1 The fuzzy altitude controller In Section 3.5.2 the paper titled A Framework for Fuzzy Logic Based UAV Navigation and Control was

discussed. This paper’s goals closely resemble the requirements of the project, and thus will be used as the initial foundation of the project. However, this paper does not include the fuzzy rule base that was used to implement the project, and does not provide certain vital information that is imperative to the success of the project e.g. controller parameters. The designed altitude controller with the inputs and outputs are given in Figure 4-11

Figure 4-11: Fuzzy altitude controller with inputs and out puts

The controller will be a Mamdani type controller, and has the following properties as given in Figure 4-12:

Figure 4-12: Properties of the Mamdani fuzzy controller

The membership functions for the inputs are given in Figure 4-13 to Figure 4-15, where the altitude error is measured in meters, and the airspeed is measured in meters per second.

DT Jordan

2008

4.9

Chapter 4: Design

Figure 4-13: Altitude error membership function

Figure 4-14: Change of altitude error membership function

Figure 4-15: Airspeed membership function

The membership functions for the controller outputs are given in Figure 4-16 and Figure 4-17, where the elevator is measured in radians. The meaning of the abbreviations of the linguistic variables can be found in S ection 3.5.2.2

Figure 4-16: Throttle membership function

Figure 4-17: Elevator membership function

The fuzzy rule base chosen for the altitude controller are: 1. If Altitude error is AEN and Change of altitude error is NC then Elevator is PE and Throttle is HT

2. If Altitude error is AEN and Change of altitude error is S then Elevator is PE and Throttle is MT

3. If Altitude error is AEN and Change of altitude error is PC then Elevator is PE and Throttle is LT

4. If Altitude error is AES and Change of altitude error is NC then Elevator is PE and Throttle is MT

5. If Altitude error is AES and Change of altitude error is S then Elevator is S and Throttle is MT

DT Jordan

2008

4.10

Chapter 4: Design

6. If Altitude error is AES and Change of altitude error is PC then Elevator is NE and Throttle is MT

7. If Altitude error is AEP and Change of altitude error is NC then Elevator is NE and Throttle is LT

8. If Altitude error is AEP and Change of altitude error is S then Elevator is NE and Throttle is MT

9. If Altitude error is AEP and Change of altitude error is PC then Elevator is NE and Throttle is HT

10. If Airspeed is SA then Throttle is HT 11. If Airspeed is MA then Throttle is MT 12. If Airspeed is BA then Throttle is LT The rules in terms of a FAM, where the altitude error and change of altitude error are the inputs, and elevator the output is given in Table 4.2: Table 4-2: Altitude Fuzzy Controller FAM 1

Change in altitude error

Altitude error

NC S PC AEN PE PE PE AES PE S NE AEP NE NE NE

The FAM where the altitude error and change of altitude error are the inputs, and the Throttle the output is given in Table 4.3: Table 4-3: Altitude Fuzzy Controller FAM 2


NC S PC AEN HT MT LT Altitude AES MT MT MT error AEP LT MT HT The FAM where the airspeed is the input, and the Throttle the output is given in Table 4.4: Table 4-4: Altitude Fuzzy Controller FAM 3

Airspeed

SA MA BA

HT MT LT

The values for the elevator controller output were based on experimentation, and was chosen to prevent the UAV from stalling. 4.2.3.2

The fuzzy latitude-longitude controller

The fuzzy latitude-longitude controller based on the controller given in Section 3.5.2 has the inputs and the outputs given in Figure 4-18:

DT Jordan

2008

4.11

Chapter 4: Design

Figure 4-18: Fuzzy latitude longitude controller with inputs and outputs

Similar to the fuzzy altitude controller, a Mamdani type controller will also be used for the latitudelongitude controller, with the same controller properties as given in Figure 4-12. The membership functions for the inputs are given in Figure 4-19 and Figure 4-20, where the heading error is measured in radians, and the airspeed is measured in meters per second.

Figure 4-19: Heading error membership function

Figure 4-20: Change of heading error

The output membership function is given in Figure 4-21, where the roll angle is measured in degrees. The meaning of the abbreviations of the linguistic variables can be found in S ection 3.5.2.2

DT Jordan

2008

4.12

Chapter 4: Design

Figure 4-21: Roll angle

The fuzzy rule base chosen are: 1. If Heading error is TR and Change of heading error is N then Roll angle is R 2. If Heading error is TR and Change of heading error is S then Roll angle is R 3. If Heading error is TR and Change of heading error is P then Roll angle is TR 4. If Heading error is R and Change of heading error is N then Roll angle is TL 5. If Heading error is R and Change of heading error is S then Roll angle is L 6. If Heading error is R and Change of heading error is P then Roll angle is L 7. If Heading error is C and Change of heading error is N then Roll angle is L 8. If Heading error is C and Change of heading error is S then Roll angle is A 9. If Heading error is C and Change of heading error is P then Roll angle is R 10. If Heading error is L and Change of heading error is N then Roll angle is R 11. If Heading error is L and Change of heading error is S then Roll angle is R 12. If Heading error is L and Change of heading error is P then Roll angle is TR 13. If Heading error is TL and Change of heading error is N then Roll angle is TL 14. If Heading error is TL and Change of heading error is S then Roll angle is L 15. If Heading error is TL and Change of heading error is P then Roll angle is L 16. If Heading error is C1 and Change of heading error is N then Roll angle is L 17. If Heading error is C1 and Change of heading error is S then Roll angle is A 18. If Heading error is C1 and Change of heading error is P then Roll angle is R 19. If Heading error is C2 and Change of heading error is N then Roll angle is L 20. If Heading error is C2 and Change of heading error is S then Roll angle is A 21. If Heading error is C2 and Change of heading error is P then Roll angle is R The rules in terms of a FAM, where the heading error and change of heading error are the inputs, and roll angle the output is given in Table 4.5: Table 4-5: Latitude-Longitude Fuzzy Controller FAM

Change in heading error

heading error

DT Jordan

TR R C L TL C1 C2

2008

N R TL L R TL L L

S P R TR L L A R R TR L L A R A R

4.13

Chapter 4: Design

4.2.3.3

The Matlab/ Flightgear interface

The properties for the Flightgear 0.9.8 interface block in Figure 4-6 is given in Figure 4-22:

Figure 4-22: Flightgear 0.9.8 properties block

Where: • •

Hostname=The IP address of the machine where the Flightgear flight simulation package is located. Port=The communication port.

To start Flightgear in external mode, the following command line arguments are used, assuming that a Windows operating system is used: • Use the command prompt to navigate the folder where Flightgear is installed • Using the command prompt, navigate to the following folder within the Flightgear directory “..\bin\win32” • Type in the following command into the command prompt: “fgfs --fg-root="C:\Program Files\FlightGear\data" --disablesplash-screen --native-fdm=socket,in,30,,5500,udp --fdm=external”

Figure 4-23: Starting Flightgear in external mode to a ccept connections from Matlab

DT Jordan

2008

4.14

Chapter 4: Design

4.3 DESIGN ALTERNATIVES Unlike the fixed design process of classical controllers, the design of fuzzy controllers often follows an iterative process where the controller properties are tuned until adequate performance is met. This will certainly mean that the fuzzy membership functions, as well as the fuzzy rule base will have to be tuned, and thus the initial design given above will probably change. However, the inputs and the outputs of both of the fuzzy controllers will probably remain fixed. Since the design is based on previously done work, it can be said that the design above is the most appropriate for the job.

4.3.1 System testing Since the agile design methodology is used for this project, recursive testing is done as each individual component is added to the system. As a result, the need to perform system testing is already exhausted in the component testing phase. This again proves the advantage of using the agile design methodology over other more traditional methods.

4.4 CONCLUSION Commonly used tools in the control systems environment as well as the aviation environment will be used to successfully complete this project. In the control systems environment this will entitle Simulink for the overall system framework and the fuzzy logic toolbox for the altitude and latitudelongitude fuzzy logic controllers. In the aviation environment, the Aerosim Blockset will be used to represent a mathematical model of the Aerosonde UAV and the external environment, while the Flightgear flight simulation package will be used to visually see the UAV and the fuzzy controller autopilot in place. The Altitude fuzzy control system will consist of the altitude error, change of the altitude error, and the airspeed as the controller inputs; while the elevator angle and the throttle firing strength will be the controller outputs. The heading fuzzy control system will consist of the heading error and the change of heading error as the controller inputs, while the roll angle will be the controller outputs. The design of the altitude fuzzy controller, heading fuzzy control system and their respective membership functions are heavily based on the paper titled A Framework for Fuzzy Logic Based UAV Navigation and Control [6]. The fuzzy rule base will consist of 12 rules for the altitude fuzzy controller, and 21 rules for the latitude-longitude controller. Although a solid foundation in terms of the initial design is set, the controller design is likely to change and will have to be fine-tuned until adequate performance is met. This will be accomplished by following a recursive process between the design, implementation and testing phase.

DT Jordan

2008

4.15

Chapter 5: Implementation

5 CHAPTER 5: IMPLEMENTATION 5.1 INTRODUCTION AND OVERVIEW The purpose of this chapter is to describe the actual implementation process for the project. This will range from the construction of the individual components, to the integration of the entire system. In almost all projects, the implementation phase of any project does not usually work out as planned, as things usually go wrong. The purpose of this chapter is thus to discuss all the issues involved during the construction phase of the project. As a result, the initial design as given in Chapter 4 is inevitable to change. These might range from changing the individual components to changing the entire system. The changes in the original design often aid someone who would like to further expand on the project, and thus all documented changes are very helpful. Since it was stated that the agile design methodology is used for this project, the implementation phase of this project will lead to emergent requirements. Another property of the agile methodology is that each small system increment is recursively added to the system. How each increment is added to the entire system will be brought forward during this implementation phase.

5.2 INDIVIDUAL SYSTEM INCREMENT IMPLEMENTATION PROCESS AND ISSUES 5.2.1 UAV framework setup 5.2.1.1

Implementation process

The two fuzzy controllers described in Chapter 4 require certain controller inputs in the form of UAV INS readings. As a result, the application framework has to be set up in Simulink to obtain these readings. This makes use of various blocks in the Aerosim Blockset as well as standard Simulink blocks. The setup of this is given in Figure 5-1:

Figure 5-1: UAV framework setup

The Simulink diagram given in Figure 5-1 has the following properties: DT Jordan

2008

5.1


• • • •

The blue Aerosonde UAV block is the actual model of the Aerosonde UAV shown in Figure 4-1, with the various inputs and outputs The green R2D block is used to convert the radians UAV Euler angle output to degrees The red Stop Simulation when A/C on the ground is used to stop the currently running Simulink simulation as soon as the UAV touches the ground The three brown Airspeed, Bank Angle and Heading angle blocks are used to indicate the current UAV airspeed, bank angle and heading angle given in the units of m/s, degrees and degrees respectively

Furthermore, the initial properties of the UAV Blockset are set up as shown in Figure 5-2:

Figure 5-2: Aerosonde UAV block properties

5.2.1.2

Implementation issues

There were no issues encountered during this implementation phase.

5.2.2 Connection with Flightgear setup 5.2.2.1


The UDP protocol was used to make the network connection between Flightgear and the Simulink file. The Simulink file as well as the Flightgear interface is given in Figure 5-3:

DT Jordan

2008

5.2


Figure 5-3: Connection with Flightgear setup

The setup properties of the FlightGear 0.9.8 Interface block is shown in Figure 5-4:

Figure 5-4: FlightGear 0.9.8 Interface Blockset properties

Due to availability constraints, the same computer was used for executing Flightgear as well as the overall Simulink file. However, this can be easily changed by specifying the “Host Name” parameter to the IP address of the computer where Flightgear is installed . Any free port can also be used. For this project, the port 5500 is used. To set up the Flightgear interface to accept connections from the Simulink file, the same procedure was followed as given in Section 4.2.3.3. 5.2.2.2


The initial command used to set up the connection on the Flightgear side was used as provided in the Aerosim user guide [66]. This states that the following command c ommand should be used:

DT Jordan

2008

5.3


fgfs --native-fdm=socket,in,30,,5500,udp --fdm=external

However, Flightgear produces the following output when executing this command as shown in Figure 5-5:

Figure 5-5: Invoking Flightgear to accept UDP connections using the command in the Aerosim User guide

As a result, the command has to be expanded to include the path where Flightgear is installed. Assuming that it is installed in the “C:\Program Files” directory, the command used has to be extended to: fgfs --fg-root="C:\Program Files\FlightGear\data" --disable-splashscreen --native-fdm=socket,in,30,,5500,udp --fdm=external

5.2.3 Altitude fuzzy logic controller framework setup 5.2.3.1


The altitude Fuzzy logic controller given in Section 4.2.3.1 has the following controller inputs: • Altitude error • Change of altitude error • Airspeed And the following controller outputs: • Elevator • Throttle To incorporate these changes, the Simulink file was expanded as shown in Figure 5-6. The Altitude fuzzy logic controller input parameter calculator subsystem block is responsible for calculating the inputs required for the Altitude fuzzy logic controller . The outputs of the controller are directly connected to the Elevator and Throttle input control command respectively. The block diagram of the Altitude fuzzy logic input parameter calculator subsystem block is shown in Figure 5-7.

DT Jordan

2008

5.4


Figure 5-6: Obtaining inputs and outputs for the Altitude fuzzy logic controller

DT Jordan

2008


Figure 5-7: Altitude fuzzy logic input parameter calculator subsystem

The parameter setup of the orange Altitude Fuzzy logic controller block is given in Figure 5-8:

Figure 5-8: Altitude fuzzy logic controller block properties

5.5


Figure 5-7: Altitude fuzzy logic input parameter calculator subsystem

The parameter setup of the orange Altitude Fuzzy logic controller block is given in Figure 5-8:

Figure 5-8: Altitude fuzzy logic controller block properties

Where the “FIS matrix” field indicates the fuzzy interface structure that the block must use. The FIS matrix must currently exist in the MATLAB workspace to prevent Matlab from throwing an error. Implementing the altitude controller without some sort of aileron control in place would result in the UAV either rolling to the left or right. This will in turn result in the altitude of the UAV dropping. As a result, the altitude controller cannot be designed without some sort of aileron controller in place. The purpose of this temporary controller will be to maintain a 0° UAV bank angle. The aerosonde_demo5 demo that is included in the Aerosim Blockset has this controller in the form of a PI controller. This controller has the desired bank angle as it setpoint, and outputs an aileron control command. Testing this controller, it was found that the performance was adequate, and thus the controller was inserted without any modification [66]. From Figure 5-9, it can be seen that the output of the Bank Angle to PID controller subsystem block is connected directly to the aileron UAV control input. The block diagram of the Bank Angle to PID controller subsystem is given in Figure 5-10: Where the two gains are as follows: • Bank angle to Aileron Proportional: • Bank angle to Aileron Integral:

0.5*pi/180 0.05*pi/180

These values were taken directly from the aerosonde_demo5 Simulink diagram and were assumed to be tuned.

DT Jordan

2008

5.6


Figure 5-9: System with bank angle stabilizing PI controller

DT Jordan

2008


Figure 5-10: Bank Angle to Aileron PI system

5.2.3.2



5.2.4 Altitude fuzzy controller setup 5.2.4.1


Matlab’s FIS editor that is provided with the fuzzy logic toolbox was used to construct the fuzzy interference system. The initial controller’s properties, input/outputs and membership functions were set up as the designed in Figure 4-11 to 4-16. Furthermore, the fuzzy if-then rules of the FAM tables of Table 4-1 to Table 4-3 were also implemented with the aid of the FIS editor. The entire FIS system has to be loaded into the Workspace in order for the Simulink file to execute correctly. This is performed with the option given in Figure 5-11:

5.7


Figure 5-10: Bank Angle to Aileron PI system

5.2.3.2



5.2.4 Altitude fuzzy controller setup 5.2.4.1


Matlab’s FIS editor that is provided with the fuzzy logic toolbox was used to construct the fuzzy interference system. The initial controller’s properties, input/outputs and membership functions were set up as the designed in Figure 4-11 to 4-16. Furthermore, the fuzzy if-then rules of the FAM tables of Table 4-1 to Table 4-3 were also implemented with the aid of the FIS editor. The entire FIS system has to be loaded into the Workspace in order for the Simulink file to execute correctly. This is performed with the option given in Figure 5-11:

Figure 5-11: Loading a FIS structure into the Workspace

5.2.4.2 5.2.4.2.1

Implementation issues Parameter setup issues

When trying to run the initial Simulink file, Matlab gives the following message: MinMax does not accept 'boolean' signals. The input and output signal(s) of 'initial_implementation/ Altitude Fuzzy Logic Controller/FIS Wizard/Defuzzification2/Max (COA)' must be one of the MATLAB 'uint8', 'uint16', 'uint32', 'int8', 'int16', 'int32', 'single', or 'double' data types, or one of the Fixed-point data types

It was found that when including fuzzy interference systems into Simulink models, the configuration parameters shown in Figure 5-12 has to be edited:

DT Jordan

2008

5.8


Figure 5-12: Editing the Simulation configuration parameters

Under the “Optimization” tab of the configuration parameters, the default selection of “Implement logic signals as Boolean data (vs. double)” has to be unselected as shown in Figure 5-13. This is due to the way that Matlab internally represents fuzzy system. The Matlab help files also state that this modification is a necessity when dealing with fuzzy controllers.

Figure 5-13: Editing the configuration parameters to allow for the execution of FIS systems

5.2.4.2.2

Controller issues

Unlike the case of PID controllers, the tuning of fuzzy controllers is often a very tedious task. This coupled with Matlab issues makes the entire tuning process very difficult. The approach used for this project was a trial and error method. The main problem encountered with Matlab is that some controller setup changes can result in the currently executing Simulink file to magically stop half way through the simulation process, without conveying any information to the user. It was found that the initial fuzzy controller parameter setup options as given in Figure 4-11 can cause this to happen. Discussion groups on the internet tribute this to a bug in the fuzzy logic toolbox encountered when . A documented solution to this problem could not be found; however it seems that changing the “Implication” parameter block as shown in Figure 5-14 has to “prod” solved this problem. DT Jordan

2008

5.9


Figure 5-14: Changing the controller properties block to e nable execution

Optimising the execution speed is also an issue encountered. As a result, the originally designed Mamdani controller was changed to a Sugeno type controller. This type of controller has constant membership functions as its controller output, and thus execution speed is increased. This is because there is no need to execute the defuzzification algorithms associated with Mamdani type controllers. The Sugeno controller used has different controller properties to that of the Mamdani controller shown in Figure 5-14. The default properties of the Sugeno controller are shown in Figure 5-15:

Figure 5-15: The controller properties block of the new Sugeno type controller

For the Sugeno controller, the default Sugeno controller properties were used. While testing the membership functions of the originally designed controller, it was found that the controller had an overshoot and/or undershoot of about 10m. This was far from the specifications stated in Chapter 2, and change was needed. When dealing with airspeed and altitude control of UAVs, the following issues were encountered: • The throttle cannot be used to single handily control the airspeed. In order to do this, a combination of both the throttle control as well as the elevator angle control is needed. However, the elevator is needed to control the altitude of the UAV. As a result it was decided that the originally designed fuzzy if-then rules regarding airspeed had to be changed, and the elevator angle was now only used to control the altitude. During the experimentation phase it was also found that firing the throttle at half of its firing strength also results in further undershoot. It was thus decided to only use the throttle only at its maximum firing strength, and thus the throttle membership function was eliminated from the controller, and replaced by a constant input. This again led to faster execution as less CPU time is needed during each controller execution loop. The modified Simulink diagram taking these new modifications into consideration is given in Figure 5-16:

DT Jordan

2008

5.10


Figure 5-16: Modified Simulink diagram with optimised Altitude controller inputs and outputs

During the trial and error phase of tuning the controller it was decided that more linguistic variables should be added to the Elevator membership function given in Figure 4-16, as well as tune the other existing membership functions. Through experimentation, it was found that the most optimised membership functions for the Altitude error and Change of altitude membership functions was tuned as shown in Figure 5-17 and Figure 5-18 respectively.

DT Jordan

2008


Figure 5-17: Modified altitude error membership function

Figure 5-18: Modified change of altitude error membership function

From Figure 5-17 it can be seen that the altitude fuzzy logic controller allows for inputs in the range of ± 400m of the current altitude. The exact values of linguistic variables for the modified altitude error and change of altitude error membership functions are given in Tables 5-1 and Tables 5-2 respectively:

5.11


Figure 5-17: Modified altitude error membership function

Figure 5-18: Modified change of altitude error membership function

From Figure 5-17 it can be seen that the altitude fuzzy logic controller allows for inputs in the range of ± 400m of the current altitude. The exact values of linguistic variables for the modified altitude error and change of altitude error membership functions are given in Tables 5-1 and Tables 5-2 respectively: Table 5-1: Altitude error membership function linguistic variables and their values

Linguistic variable

AEN AES AEP

Type

Value

Trapezodial [-400 -400 -100 -4] Triangular [-5 0 5] Trapezodial [4 100 400 400]

Table 5-2: Change in altitude error membership function linguistic variables and their values

Linguistic variable

NC S PC

Type

Value

Trapezodial [-100 -100 -0.2] Triangular [-0.3 0 0.3] Trapezodial [0.2 100 100]

Since a Sugeno type fuzzy controller was used, the Elevator output membership function was simply constants. The value of the constants representing each linguistic variable is given in Table 5-3: Table 5-3: Elevator membership function linguistic variables and their values

Linguistic variable

PPPE PPE PE S NE NNE NNNE

DT Jordan

Type

Value

Constant 0.045 Constant 0.02 Constant 0.0025 Constant 0 Constant -0.005 Constant -0.05 Constant -0.09

2008

5.12


The new fuzzy if-then rules are: 1. If Altitude error is AEN and Change of altitude error is NC then Elevator is PPPE 2. If Altitude error is AEN and Change of altitude error is S then Elevator is PPE 3. If Altitude error is AEN and Change of altitude error is PC then Elevator is PPE 4. If Altitude error is AES and Change of altitude error is NC then Elevator is PE 5. If Altitude error is AES and Change of altitude error is S then Elevator is S 6. If Altitude error is AES and Change of altitude error is PC then Elevator is NE 7. If Altitude error is AEP and Change of altitude error is NC then Elevator is NNE 8. If Altitude error is AEP and Change of altitude error is S then Elevator is NNE 9. If Altitude error is AEP and Change of altitude error is PC then Elevator is NNNE The rules in terms of a FAM, where the altitude error and change of altitude error is the input, and elevator the output is given in Table 5.4: Table 5-4: Altitude Fuzzy Controller FAM


AEN Altitude AES error AEP

NC S PC PPPE PPE PPE PE S NE NNE NNE NNNE

Since the airspeed was no longer considered for the Altitude fuzzy logic controller, the modified “Altitude fuzzy logic controller input parameter calculator” subsystem is shown in Figure 5-19:

Figure 5-19: Modified Altitude fuzzy logic input parameter calculator subsystem

The tuning method proposed by Jantzen [12] was also used to tune the Fuzzy controller. This was done by placing gains at the controller inputs and output, and tuning them until adequate performance was met. This tuning process was performed with the aid of sliders that is included as part of the standard Simulink library. The tuning process revealed that a gain of 4 at the elevator control output resulted in the best performance. The control surface of the altitude controller is shown in Figure 5-20:

DT Jordan

2008

5.13


Figure 5-20: Control Surface of altitude controller

5.2.5 Latitude-Longitude fuzzy logic controller framework setup 5.2.5.1


The latitude-longitude fuzzy logic controller as designed in Section 4.2.3.1 has the following controller inputs: • Heading error • Change of heading error And the following controller outputs: • Roll angle To incorporate these changes, the Simulink file was expanded as given in Figure 5-21.The LatitudeLongitude fuzzy logic input parameter calculator subsystem block is responsible for calculating the inputs for the Latitude-Longitude fuzzy logic controller block. The heading angle setpoint was calculated using basic trigonometry, after taking into consideration the current latitude and longitude coordinates, as well as the desired latitude and longitude coordinates. A detailed diagram of the Latitude-Longitude fuzzy logic input parameter calculator subsystem block is shown in Figure 5-22:

DT Jordan

2008

5.14


Figure 5-21: Obtaining inputs and outputs for the heading fuzzy logic controller

DT Jordan

2008


Figure 5-22: Latitude-Longitude fuzzy logic input parameter calculator subsystem

The purpose of green “MOD maths function” block is to convert all possible desired heading angle inputs to the range [0, 360]. The parameter setup of orange Latitude-Longitude fuzzy logic controller block is given in Figure 5-23:

5.15


Figure 5-22: Latitude-Longitude fuzzy logic input parameter calculator subsystem

The purpose of green “MOD maths function” block is to convert all possible desired heading angle inputs to the range [0, 360]. The parameter setup of orange Latitude-Longitude fuzzy logic controller block is given in Figure 5-23:

Figure 5-23: Latitude- Longitude controller block properties

Where the “FIS matrix” field indicates the fuzzy interface structure that the block must use. The FIS matrix must currently exist in the MATLAB workspace to prevent Matlab from throwing an error. The block diagram for the Bank angle to aileron PID controller is similar to that shown in Figure 5-10. The only difference is that the roll angle output of the Heading controller is now used as the Bank angle setpoint. A diagram of this is shown in Figure 5-24:

Figure 5-24: Converting the Roll angle command to an aileron command with a PI controller

5.2.5.2


There were no issues encountered during this implementation phase

DT Jordan

2008

5.16


5.2.6 Latitude-Longitude fuzzy controller setup 5.2.6.1


Again, Matlab’s FIS editor that is provided with the fuzzy logic toolbox was used to construct the Fuzzy inference system. The initial controller properties, inputs/outputs as well as membership functions were set up as designed in Figure 4-18 to Figure 4-20. Furthermore, the fuzzy if-then rules as given in the FAM table of Table 4-4 were also implemented with the aid of the FIS editor. The entire FIS system was again loaded into the Matlab workspace, as shown in Figure 5-11. 5.2.6.2 5.2.6.2.1

Implementation issues Parameter setup issues

Since all the parameter setup issues were already sorted out in Section 5.2.4.2.1, no further issues of this nature were encountered. 5.2.6.2.2

Controller issues

As with the case with the altitude controller, it was found that the Mamdani type controller could again be changed to a Sugeno controller. This leads to an increase in execution speed. The properties of the Sugeno controller were changed to that shown in Figure 5-15. When testing the originally designed controller, it was found that there was an overshoot and/or undershoot of approximately 10°. As a result, both the heading fuzzy controller as well as the bank angle to aileron PI controller had to be tuned. Through trial and error, it was found that the heading error membership function had to be tuned, and that the change in heading error membership functions remained unchanged. The membership functions of both the heading error as well as the change of heading error are given in Figure 5-25 and Figure 5-26 respectively.

Figure 5-25: Modified Heading error membership function

Figure 5-26: Final change of heading error membership function

DT Jordan

2008

5.17


The exact values of linguistic variables for the modified altitude error and change of altitude error membership functions are given in Tables 5-5 and Tables 5-6 respectively: Table 5-5: Heading error membership function linguistic variables and their va lues

Linguistic variable

C1 TR R C L TL C2

Type

Value

Triangular [-6.283 -6.283 -6.257] Trapezodial [-6.28 -6.184 -4.204 -3.142] Trapezodial [-3.142 -2.094 -0.1047 -0.00873] Triangular [-0.0262 0 0.0262] Trapezodial [0.00873 0.1047 2.094 3.142] Trapezodial [3.142 4.204 6.184 6.283] Triangular [6.257 6.283 6.283]

Table 5-6: Change in heading error membership function linguistic variables and their values

Linguistic variable

N S P

Type

Value

Triangular [-1 -1 -0.1284] Triangular [-0.15 0 0.15] Triangular [0.1284 1 1]

Since a Sugeno type fuzzy controller was used, the Roll angle output membership function was simply constants. The value of the constants representing the linguistic variables are given in Table 5-7 : Table 5-7: Roll angle membership function linguistic variables and their values

Linguistic variable

Type

Value

TTR TR R A L TL TTL

Constant Constant Constant Constant Constant Constant Constant

16 8.5 2 0 -2 -8.5 -16

The original fuzzy if-then were also changed as follows: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.

If Heading error is TR and Change of heading error is N then Roll angle is TR If Heading error is TR and Change of heading error is S then Roll angle is TR If Heading error is TR and Change of heading error is P then Roll angle is TTR If Heading error is R and Change of heading error is N then Roll angle is TTL If Heading error is R and Change of heading error is S then Roll angle is TL If Heading error is R and Change of heading error is P then Roll angle is TL If Heading error is C and Change of heading error is N then Roll angle is R If Heading error is C and Change of heading error is S then Roll angle is A If Heading error is C and Change of heading error is P then Roll angle is L If Heading error is L and Change of heading error is N then Roll angle is TR If Heading error is L and Change of heading error is S then Roll angle is TR If Heading error is L and Change of heading error is P then Roll angle is TTR If Heading error is TL and Change of heading error is N then Roll angle is TTL If Heading error is TL and Change of heading error is S then Roll angle is TL If Heading error is TL and Change of heading error is P then Roll angle is TL If Heading error is C1 and Change of heading error is N then Roll angle is R

DT Jordan

2008

5.18


17. 18. 19. 20. 21.

If Heading error is C1 and Change of heading error is S then Roll angle is A If Heading error is C1 and Change of heading error is P then Roll angle is L If Heading error is C2 and Change of heading error is N then Roll angle is R If Heading error is C2 and Change of heading error is S then Roll angle is A If Heading error is C2 and Change of heading error is P then Roll angle is L

The modified rules in terms of a FAM, where the heading error and change of heading error is the input, and roll angle the output is given in Table 5.8: Table 5-8: Modified latitude-longitude fuzzy controller FAM

Change in heading error

heading error

TR R C L TL C1 C2

N S P TR TR TTR TTL TL TL R A L TR TR TTR TTL TL TL R A L R A L

The control surface of the latitude-longitude controller is shown in Figure 5-27:

Figure 5-27: Control Surface of latitude-longitude controller

5.3 INTEGRATION PROCESS AND ISSUES Since the agile methodology was used, all the integration issues were sorted out when appending the individual increments to the entire system. The result was that integration issues were already encountered in the individual system increment implementation process.

5.4 COST SUMMARY The main software tools used to implement this project were as follows: 1. Matlab v7.0.0.19920 (R14) 2. Simulink 3. Fuzzy logic Toolbox 4. Aerosim Blockset v1.2 5. Flightgear v0.9.8a

DT Jordan

2008

5.19


The electrical and electronic engineering department at the University of Johannesburg has already acquired licences for the first three, while Flightgear is open source. The Aerosim Blockset is also available freely when used for academic research and non-commercial use. As a result no additional money was spent on this project.

5.5 SETTING UP AND USING THE SYSTEM 5.5.1 Installing the system The installation files for both the Aerosim Blockset as well as Flightgear can be found on the CD provided with this document under the “Installation files” directory. The following steps need to be followed to install the required software: 1. Install an adequate version of Matlab on the computer that is going to be used. The Matlab version should include Simulink as well as the Fuzzy logic toolbox 2. Run the Aerosim setup file and follow the instructions. The files might have to be unzipped first 3. Run the Flightgear setup file and follow the instructions

5.5.2 Running the system The Matlab files are all saved in the directory “Fuzzy controller autopilot for a fixed Wing UAV” of the CD provided with this document. The following steps need to be followed to run the system: 1. Copy the entire “Fuzzy controller autopilot for a fixed Wing UAV” directory to an appropriate folder on the computer to be used e.g.: “C:\Fuzzy controller autopilot for a fixed Wing UAV” 2. Invoke a new instance of Matlab 3. Change the Matlab current directory to point to the directory of the copied “Fuzzy controller autopilot for a fixed Wing UAV” directory e.g. “C:\Fuzzy controller autopilot for a fixed Wing UAV” 4. Invoke the altitude fuzzy logic controller by typing the following command into the Matlab command prompt: fuzzy Altitude_fuzzy_logic_controller_sugeno

5. Export the FIS structure to the Matlab work space as shown in Figure 5-11. The workspace variable must be called “Altitude_fuzzy_logic_controller_sugeno” 6. Check that the FIS structure is in the Matlab workspace 7. Invoke the heading fuzzy logic controller by typing the following command into the Matlab command prompt: fuzzy Latitude_Longitude_fuzzy_logic_controller_sugeno

8. Export the FIS structure to the Matlab work space as shown in Figure 5-11. The workspace variable must be called “Latitude_Longitude_fuzzy_logic_controller_sugeno” 9. Check that the FIS structure is in the Matlab workspace 10. Open up the “Fuzzy_controller_for_UAV.mdl” Simulink file. This will open up the following Simulink file

DT Jordan

2008

5.20


Figure 5-28: System shown when opening the “Fuzzy_controller_for_UAV.mdl” file

DT Jordan

2008


11. The three circled “UAV latitude setpoint”, “UAV longitude setpoint” and “UAV altitude setpoint” blocks are the three setpoints that can be changed. The altitude setpoint can be any value in the units of meters up to a range of 400m above or below the current altitude. The initial altitude is 1000m. The latitude and longitude setpoints can be any value in degrees, taking into consideration that the initial values are the coordinates of the Electrical and electronic engineering department at the University of Johannesburg. 12. If the user would not like to view the UAV in Flightgear, then the Simulink simulation can simply be started, and various readings can be read from the numerous displays or scopes. If the user would like to see a visual model of the UAV in Flightgear, the following steps have to be followed: 1. Follow steps 1-11 above 2. Open up the command prompt 3. Use the command prompt to navigate to the folder where Flightgear is installed e.g. “C:\Program Files\FlightGear” 4. Use the command prompt to navigate to the “\bin\Win32” directory within Flightgear 5. Type the following command into the command prompt: “fgfs --fg-root="C:\Program Files\FlightGear\data" --disablesplash-screen --native-fdm=socket,in,30,,5500,udp -fdm=external”

6. Flightgear is now set up to accept connections from Simulink. The Simulink simulation can now be started, and there is a visual model of the aircraft executing the control manoeuvres within Flightgear.

5.21


11. The three circled “UAV latitude setpoint”, “UAV longitude setpoint” and “UAV altitude setpoint” blocks are the three setpoints that can be changed. The altitude setpoint can be any value in the units of meters up to a range of 400m above or below the current altitude. The initial altitude is 1000m. The latitude and longitude setpoints can be any value in degrees, taking into consideration that the initial values are the coordinates of the Electrical and electronic engineering department at the University of Johannesburg. 12. If the user would not like to view the UAV in Flightgear, then the Simulink simulation can simply be started, and various readings can be read from the numerous displays or scopes. If the user would like to see a visual model of the UAV in Flightgear, the following steps have to be followed: 1. Follow steps 1-11 above 2. Open up the command prompt 3. Use the command prompt to navigate to the folder where Flightgear is installed e.g. “C:\Program Files\FlightGear” 4. Use the command prompt to navigate to the “\bin\Win32” directory within Flightgear 5. Type the following command into the command prompt: “fgfs --fg-root="C:\Program Files\FlightGear\data" --disablesplash-screen --native-fdm=socket,in,30,,5500,udp -fdm=external”

6. Flightgear is now set up to accept connections from Simulink. The Simulink simulation can now be started, and there is a visual model of the aircraft executing the control manoeuvres within Flightgear. NB:

Depending on the Computer setup, a firewall might prevent the UDP connection from taking place. This can be fixed by turning off the firewall.

The following hints might be helpful in Flightgear: 1. The configuration settings within Flightgear might result in the Aircrafts surroundings been dark, and visualisation difficult. The “Time of day” settings can be changed as shown in 529:

Figure 5-29: Changing the time of day settings in Flightgear

DT Jordan

2008

5.22


2. One can also toggle the view within Flightgear by making use of the “v” key. For most cases, the helicopter view is the best view.

5.6 CONCLUSION As was inevitable, the initial design had to be changed resulting from unexpected issues. Since the agile methodology was used for this project, it was found that most of the problems were discovered in the implementation of the individual system increments. The first problem encountered was making the network connection between Simulink and Flightgear. This was because the initial command taken directly from the Aerosim user guide was incomplete and took assumptions into place. As a result, this command was changed. The designed controller had three controller setpoints, mainly altitude, heading angle and airspeed. However, during the implementation phase it was found that there it was very difficult to control both the airspeed as well as the altitude simultaneously. As a result, it was decided to eliminate the airspeed from the controller. The throttle controller output was also eliminated as this lead to an increase in overshoot and undershoot. This meant that a constant throttle input of the maximum firing strength was used for the UAV. The Mamdani controller for both the altitude and latitudelongitude controller was replaced by a Sugeno controller to allow for faster execution speed. Furthermore, the designed linguistic variables, membership functions and if-then rules had to be tuned to allow for an optimised performance. The tuning process was done on a trial and error basis. To convert the roll angle output of the heading controller to an aileron UAV command input, a bank angle to aileron PI controller was used, where the gains were taken from the aerosonde_demo5 demo of the Aerosim Blockset. This PI controller was tested first and the results show that it is working correctly. Matlab’s real time workshop is used to convert Simulink files to that of a high-level language such as C/C++. The main reason for this is faster execution speed. When trying to use Matlab’s real time workshop, it was found that conversion process failed. Although Matlab never communicated a detailed error message, it was assumed that the reason for this failed conversion process was because the Aerosim Blockset was used, that does no form part of standard Matlab libraries. The conversion process is definitely a growth option of the project. Although all the issues were addressed, it can be said that the implementation phase was a successful after testing the project. The testing phase is the next phase in the project, and the entire test process will be documented in Chapter 6.

DT Jordan

2008

5.23

Chapter 6: Results

6 CHAPTER 6: RESULTS 6.1 INTRODUCTION AND OVERVIEW The success of any project can only be confirmed if adequate test strategies are in place. This is done by testing the implemented project against the specifications stated in Chapter 2. Although it is very likely that not all of the planned tests will be passed, the results will still give an indication if the implementation was successful or not. These results will be given in the form of tables as well as graphs. This raw test data will then be processed to obtain vital information about the implemented system. Since this project was heavily based on previously done work, a thorough comparison between this implemented project as well and the results of the previously done work will also be documented. Finally the information obtained from the test results will be summarised in the conclusion of this chapter.

6.2 TEST AND EVALUATION STRATEGY , SETUP AND METHODOLOGY The purpose of this part of the design is to define the purpose, objective and the overall structure of the test plan of the system. The tests will be split up into two main sections, mainly component testing and system testing. The component testing phase will be split up into the altitude fuzzy controller test, and the latitude-longitude controller test. The block diagram of the testing plan is given in Figure 6-1:

Figure 6-1: System test plan

In this section, the requirements that were set in Section 2.4 will be tested. The tests will be performed as described below. For all the tests, the initial latitude, longitude and altitude positions were set to the following coordinates: -26.180° • Latitude: 27.998° • Longitude: 1000m • Altitude: The latitude and longitude coordinates were set to the coordinates of the Electrical and Electronic department at the University of Johannesburg’s Auckland Park Kingsway campus. This information was read directly from Google Earth. The Simulink file shown in Figure 5-28 was used during this testing phase. The file used is the “Fuzzy controller autopilot for a fixed Wing UAV.mdl” file found on the CD that came with this document. All the setup steps as discussed in Section 5.5 were performed prior to performing any tests.

DT Jordan

2008

6.1

Chapter 6: Results

6.3 COMPONENT TESTING

6.3.1 Keeping the UAV in sustained forward flight mode 6.3.1.1

Test setup

Requirement 2.4.2.1 states that the controller should be able to keep a fixed-wing UAV in sustained forward flight for a finite amount of time. To prove this requirement, the following test was performed. The latitude and longitude setpoints were chosen to represent the runway of Durban international airport, and were taken directly from readings on Google Earth. Table 6-1: Sustained forward flight mode test

Test

Test description

Sustained forward flight mode test

Set up the Simulink file to allow the UAV to fly from Johannesburg to Durban. Run the Simulink file for 2000s

Altitude setpoint (m) 1000m

Latitude setpoint (deg) -29.977

Longitude setpoint (deg) 30.944

Test passing requirements The UAV remains flying after 2000s

Test failing requirements The UAV does not remain flying after 2000s

6.3.1.2 Test results and discussion The visual model of the UAV flying in Flightgear was witnessed for the entire 2000s Flight time. As a result, it can be confirmed that it seems to be working, and it can be concluded that this requirement is met.

6.3.2 The user interface test setup and methodology 6.3.2.1

Test setup

Requirement 2.4.3.1 states that the user interface should: • Indicate a visual model of the UAV Indicate control actions that the UAV must take •

To test this requirement, the following test will be performed: The system will run for 100s • If the Visual model of the UAV is shown in Flightgear, and a display of the control actions that the UAV must take is shown correctly, the o test is a passed

DT Jordan

2008

6.2

Chapter 6: Results

o

The test will be performed by inserting a constant control input in the UAV

The following test as given in Table 6-2 was setup to test this requirement : Table 6-2: Procedure to test the user interface

Test

Test setup

Test passing requirements

User interface test

Temporary disconnect the controller inputs of the blue ”Aerosonde UAV” block of Figure 5-29 and replace it by a constant 7×1 matrix input set to [0 T -0.1 0 0 0.4 13 1] . Run the Simulink file for 100s.

Flightgear should indicate a visual model of the UAV banking to the left. The “Current Altitude” scope should indicate that the current altitude decreasing, while the “Current bank angle” scope should indicate that the UAV is banking to the left

Test failing requirements Any other results other than that of the test Passing Requirements

6.3.2.2 Test results and discussion Flightgear indicated the UAV in the visual state as shown in Figure 6-2:

Figure 6-2: Indication of UAV banking to the left

DT Jordan

2008

6.3

Chapter 6: Results

The test will be performed by inserting a constant control input in the UAV

o

The following test as given in Table 6-2 was setup to test this requirement : Table 6-2: Procedure to test the user interface

Test

Test setup

Test passing requirements

User interface test

Temporary disconnect the controller inputs of the blue ”Aerosonde UAV” block of Figure 5-29 and replace it by a constant 7×1 matrix input set to [0 T -0.1 0 0 0.4 13 1] . Run the Simulink file for 100s.

Flightgear should indicate a visual model of the UAV banking to the left. The “Current Altitude” scope should indicate that the current altitude decreasing, while the “Current bank angle” scope should indicate that the UAV is banking to the left

Test failing requirements Any other results other than that of the test Passing Requirements

6.3.2.2 Test results and discussion Flightgear indicated the UAV in the visual state as shown in Figure 6-2:

Figure 6-2: Indication of UAV banking to the left

DT Jordan

2008

6.3

Chapter 6: Results

While the readings of the “Current Altitude” and “Current bank angle” scopes are shown in Figure 6-3 and Figure 6-4 respectively:

Figure 6-3: Altitude plot for user interface test

Figure 6-4: Bank angle plot for user interface test

From Figure 6-2, a visual model of the UAV banking to the left can be seen, which functioned as predicted. The plots given in Figure 6-3 and Figure 6-4 also confirm this. As result, it can be concluded that the interface seems to be working, and that the requirements are met. However, it is clear that the aircraft shown in Flightgear does not resemble the Aerosonde UAV model. This is because Flightgear does not have built in libraries of the Aerosonde UAV, and thus the Cessna Skyhawk model is used. However the purpose of the Flightgear interface is focused on visualising the aircrafts response to different setpoints, rather than having an exact replica of the UAV used in Simulink.

6.3.3 The precision, accuracy, speed and latency test setup and methodology 6.3.3.1

Test setup

Requirement 2.4.4.3 states that the altitude and latitude-longitude controllers should not allow the UAV to deviate more than 1.5m or 1.5° from the planned flight path respectively. Furthermore, Requirement 2.4.4.1 states that the controller should to keep the UAV in sustained forward mode flight up to

DT Jordan

2008

6.4

Chapter 6: Results

While the readings of the “Current Altitude” and “Current bank angle” scopes are shown in Figure 6-3 and Figure 6-4 respectively:

Figure 6-3: Altitude plot for user interface test

Figure 6-4: Bank angle plot for user interface test

From Figure 6-2, a visual model of the UAV banking to the left can be seen, which functioned as predicted. The plots given in Figure 6-3 and Figure 6-4 also confirm this. As result, it can be concluded that the interface seems to be working, and that the requirements are met. However, it is clear that the aircraft shown in Flightgear does not resemble the Aerosonde UAV model. This is because Flightgear does not have built in libraries of the Aerosonde UAV, and thus the Cessna Skyhawk model is used. However the purpose of the Flightgear interface is focused on visualising the aircrafts response to different setpoints, rather than having an exact replica of the UAV used in Simulink.

6.3.3 The precision, accuracy, speed and latency test setup and methodology 6.3.3.1

Test setup

Requirement 2.4.4.3 states that the altitude and latitude-longitude controllers should not allow the UAV to deviate more than 1.5m or 1.5° from the planned flight path respectively. Furthermore, Requirement 2.4.4.1 states that the controller should to keep the UAV in sustained forward mode flight up to

DT Jordan

2008

6.4

Chapter 6: Results

6.3.3.2 Test results and discussion For Test 1 stated in Table 6-3, the altitude and airspeed waveforms of the UAV are shown in Figure 6-5 and Figure 6-6 respectively:

Figure 6-5: The altitude plot for 1050m set point

Chapter 6: Results

6.3.3.2 Test results and discussion For Test 1 stated in Table 6-3, the altitude and airspeed waveforms of the UAV are shown in Figure 6-5 and Figure 6-6 respectively:

Figure 6-5: The altitude plot for 1050m set point

Figure 6-6: The airspeed plot for a 1050m set point

Zooming into Figure 6-5, it can be seen that the altitude stabilises at 1046m. Test 1 was set to prove that the contoller is capable of moving the UAV to an altitude higher than the current position of the UAV. The results that were obtained from Test 1 shown in Figure 6-5 indicates that the altitude controller moves the altitude of the UAV from its initial value of 1000m, and stabilises it at 1046m.

DT Jordan

2008

6.7

Chapter 6: Results

This is a -4m shift away from the specified setpoint of 1050m. The reason for this is as follows. One of the problems when using fuzzy controllers to control non-linear systems is the formation of oscillations around the setpoint often referred to as limit cycles. This unique phenomenon is discussed on Page 3-13.This means that there is interpolation between the equilibrium point and a non-equilibrium point. In order to prevent this, the control surface shown in Figure 5-20 should thus have a wide enough settling band region that will eventually allow the control variable to settle resulting from only one rule been fired. This means that for the implemented controller, a condition must be eventually met where only rule 5 is fired. This means that the linguistic variables AES and S of the altitude error and change of altitude error membership functions respectively has to cover a wider range. The problem with this is that the larger these are made, the further away the UAV altitude settles from the desired setpoint. It was found that the chosen range for the implemented membership function resulted in the best performance in terms of the smallest range that prevented oscillations. The slider gain of 4 for the elevator output of the altitude controller also helped to minimise these oscillations. As a result an alternative design could have been implemented that resulted in oscillations. This would have meant that the settling band is much smaller, resulting in the altitude of the UAV been closer to the desired setpoint. In terms of the accuracy requirements, this is -4m off the required setpoint. However, the question is asked if this requirement was ever realistic? Taking into consideration typical INS altitude sensors such as GPS have an accuracy of approximately 15m, it is clear that the initial requirements are unrealistic. Both the current latitude, longitude, heading angle and altitude controller inputs are fed directly from the real states of the UAV. These states are obviously unavailable in the real Aerosonde UAV and are instead based on INS readings, with each sensor having their own specified accuracy. As a result, a more realistic approach would have been to use the states obtained from a simulated INS sensor readings, and the initial requirements were never realistic, and an altitude controller accuracy of 10m is more realistic, and the results are definitely in range. Figure 6-6 indicates the airspeed of the UAV settling at approximately 28m/s. Since the airspeed requirements are that the airspeed should remain bellow 29m/s, the results confirm this and thus the requirements are met for Test 1.

Figure 6-7: Output of "current altitude" scope for test 2

DT Jordan

2008

6.8

Chapter 6: Results

Figure 6-8: Output of the “Current airspeed” scope for test 2

For Test 2 stated in Table 6-3, the altitude and airspeed waveforms of the UAV are shown in Figure 6-7 and Figure 6-8 respectively , where the altitude waveform stabilises at 954m. The setpoint in this test was set to prove that the controller is capable of moving the UAV to an altitude setpoint lower than the current position of the UAV. In this particular test, a setpoint of 50m bellow the current position of the UAV was chosen. Figure 6-7 indicates that the altitude settles at 954m, which is 4m above the desired setpoint. However, similar to the discussion for Test 1, the initial accuracy requirements of 1.5m was not realistic and appropriate, and the results obtained are in the range of the modified requirements of 10m. The airspeed waveform shown in Figure 6-8 indicates that the airspeed eventually settle at 28m/s. However, during the descend; the UAV reaches a maximum speed of 36 m/s. This is far above the maximum allowed range and as a result the original airspeed requirements are not met for this particular test. Although the specifications of the Aerosonde UAV given in Table 4-1 limit the maximum speed of the UAV to 32 m/s, the altitude controller still manages to settle the UAV at the desired altitude setpoint. Thus, the original requirements were not realistic and can thus be changed. However, tests on the real Aerosonde UAV will have to be performed to see in the UAV can safely handle this velocity/ Test 3 deals with the most common case when dealing with autopilots- maintaining the current

heading angle and setpoints. This will mean that the altitude will have to maintain the current altitude of 1000m. The result shown in Figure 6-9 depicts the altitude of the UAV initially fall to 996m, and then increase till 1004m. This result obtained is again realistic when taking into consideration the accuracy of the INS sensor readings and as a result the modified requirements are met. The airspeed waveform shown in Figure 9-10 also indicate that the airspeed settles to 28.1 m/s and as a result the airspeed test is passed.

DT Jordan

2008

6.9

Chapter 6: Results

Figure 6-9: Output of "current altitude" scope for test 3


Since all the altitude controller test results were discussed, attention is now turned to the latitudelongitude controller test results and discussion, set out in Test 4-Test 8 . The latitude and longitude setpoints in Test 4 was chosen that will result in a heading angle setpoint of -110°. The system should thus interpret this as 250°. Figure 6-11 confirms this, where the heading angle stabilises to 249.5°. This is in the specified tolerance range and as a result the requirements for this test were met. With the latitude-longitude controller, there are four linguistic variables responsible for the settling band in Figure 5-25 and Figure 5-26. These are linguistic variables “C”, “C1” and “C2” of the heading error membership function, and “S” of the change of heading error membership function. DT Jordan

2008

6.10

Chapter 6: Results

The if-then rules that will result in the settling band been fired are rules 8, 17 and 20. Similar to the altitude controller, narrowing the settling band will result in the UAV heading angle reaching closer values to the setpoint. However, this will again result in oscillations, which increase wear and tear on the aileron servos. The airspeed waveform shown in Figure 6-12 shows the airspeed stabilise at 28.1m/s, remaining in the specification range of 29 m/s. Thus, the airspeed requirements for this test are fulfilled.

Figure 6-11: Output of "Current Heading" scope for test 4


Test 5 was set to gain insight into the controller response. In this case, the latitude and longitude

setpoints were chosen that would result in a heading angle set point of 60°. For this test, it is DT Jordan

2008

6.11

Chapter 6: Results

expected that the UAV will roll to the left. The heading angle waveform shown in Figure 6-13 confirms this, where it is found that the controller results in the heading angle settling at 59.5°. This in the tolerance range and thus it can be concluded that the accuracy requirements are met. Investigating the airspeed plot shown in Figure 6-14, the maximum airspeed is again 28.1m/s, which is within the tolerance range of 29m/s.



The common latitude-longitude autopilot case is now tested in Test 6. This is setting the latitude and longitude setpoint that will result in the heading angle setpoint as the same value as the current UAV heading angle. Since the initial UAV heading angle is 0°, the latitude and longitude setpoints for Test

DT Jordan

2008

6.12

Chapter 6: Results

6 were chosen that resulted in a heading angle setpoint of 0°. The results depicted in Figure 6-15

shows the heading angles stabilise at 359.8° i.e. -0.2° from the setpoint. This is in the tolerance range and as a result the passing requirements for this test are met. The airspeed waveform of Figure 6-16 indicates the airspeed of the UAV settle at 28m/s which is in the requirements range of 29m/s, and thus the airspeed test requirements are fulfilled.



The remaining two tests investigate the response of the heading controller to set point values symmetrical to the ones of Test 4 and Test 5. For Test 7 , the resulting heading angle setpoint was set to 110°. The quickest way to reach this setpoint value will be rolling to the left, which the results DT Jordan

2008

6.13

Chapter 6: Results

shown in Figure 6-17 substantiate. This figure shows the heading angle waveform stabilise at 109.5° i.e. -0.5° off the desired setpoint i.e. within the desired accuracy range and the requirements are met. Since the airspeed waveform in Figure 6-17 shows the UAV airspeed stabilise at 28.1m/s i.e. within the tolerance range, it can be said that both the heading controller accuracy requirements are fulfilled.



The final test used latitude and longitude setpoints that resulted in a heading setpoint of 300°. As expected, the heading angle waveform given in Figure 6-19 shows the UAV taking the shortest possible path to reach this point i.e. rolling to the right, and eventually settling at 299.6° i.e. -0.4° off DT Jordan

2008

6.14

Chapter 6: Results

the desired setpoint. The airspeed also settles at 28.1m/s i.e. within the accuracy requirements of 29m/s. As a result both the heading controller as well as the airspeed accuracy requirements are fulfilled for this test.



DT Jordan

2008

6.15

Chapter 6: Results

investigated under various W D wind speeds for the first 10 tests. Test 1 sets the input wind vector to [0 0 -0.5]. This meant that there is a vertical wind speed of 0.5m/s moving away from the ground. The altitude setpoint is 1050m, which should result in the UAV reaching its altitude setpoint much faster compared to the time taken with no wind present. The results for the first test shown in Table 6-5 show that the undesirable case of oscillations present. Although this is the case, the peak values of the altitude during the oscillation phase remains in the tolerance range. However, the constant switching o f the elevator control will clearly lead to an increased wear and tear of the servos. Another limitation with Simulink is that there is a step change between the different elevator commands. With a real UAV, there is a switching time constraint. However, for the Simulink simulation, it can concluded that the altitude controller is capable of controlling the altitude in for all W D wind speeds in the -0.5m/s and 0.5m/s range, with the side effects of oscillations. This covers the designed wind speed range. Table 6-5: Test results

Test # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Scope/ Display reading used Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope

DT Jordan

Setpoint reached

Oscillations present



















X





















     



X X X X X

















Oscillation max value 1055m 1055m 1054.95m 1054.9m NA 1045.8m 1045.6m 1045.45m 1045.35m 1045.35m 99.5° NA NA NA NA NA 99.52° 99.515° 99.51° 99.53°

2008

Oscillation min value 1054.7m 1054.7m 1054.65m 1054.5m NA 1045.3m 1045.2m 1045.15m 1045.1m 1045.05m 99.48° NA NA NA NA NA 99.51° 99.5° 99.5025° 99.52°

Additional comments

The altitude settles at 1054.5m

The heading angle settles at 99.5° The heading angle settles at 99.5° The heading angle settles at 99.5° The heading angle settles at 99.5° The heading angle settles at 99.5°

6.21

Chapter 6: Results

investigated under various W D wind speeds for the first 10 tests. Test 1 sets the input wind vector to [0 0 -0.5]. This meant that there is a vertical wind speed of 0.5m/s moving away from the ground. The altitude setpoint is 1050m, which should result in the UAV reaching its altitude setpoint much faster compared to the time taken with no wind present. The results for the first test shown in Table 6-5 show that the undesirable case of oscillations present. Although this is the case, the peak values of the altitude during the oscillation phase remains in the tolerance range. However, the constant switching o f the elevator control will clearly lead to an increased wear and tear of the servos. Another limitation with Simulink is that there is a step change between the different elevator commands. With a real UAV, there is a switching time constraint. However, for the Simulink simulation, it can concluded that the altitude controller is capable of controlling the altitude in for all W D wind speeds in the -0.5m/s and 0.5m/s range, with the side effects of oscillations. This covers the designed wind speed range. Table 6-5: Test results

Test # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Scope/ Display reading used Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current altitude scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope Current Heading scope

Setpoint reached

Oscillations present













 



X

























    

X X X X X

















DT Jordan

Oscillation max value 1055m 1055m 1054.95m 1054.9m NA 1045.8m 1045.6m 1045.45m 1045.35m 1045.35m 99.5° NA NA NA NA NA 99.52° 99.515° 99.51° 99.53°

Oscillation min value 1054.7m 1054.7m 1054.65m 1054.5m NA 1045.3m 1045.2m 1045.15m 1045.1m 1045.05m 99.48° NA NA NA NA NA 99.51° 99.5° 99.5025° 99.52°

Additional comments

The altitude settles at 1054.5m

The heading angle settles at 99.5° The heading angle settles at 99.5° The heading angle settles at 99.5° The heading angle settles at 99.5° The heading angle settles at 99.5°

2008

Chapter 6: Results

Attention is now turned to the effects of the W N WE winds on the UAV. These two directional winds will have the greatest effect on the heading angle controllers response, and thus their effect will be investigated in Tests 11-20. This was done by setting the input wind matrix to [X X 0] T, where the initial X value was set to -0.5m/s and was increased by 0.1m/s during tests 11-20. The setpoints of the altitude, latitude and longitude controller were chosen so resulting in an altitude and heading setpoint of 1000m, and 100° respectively. The results of Table 6-5 show that the heading controller has a better performance remaining in the settling band compared to the altitude controller. Out of the 10 tests performed, only half of them resulted in oscillations. The maximum and minimum values of the oscillations also indicate that the peak to peak values are very small. It can thus conclude that the heading controller is much more robust compared to the altitude controller.

6.4 SYSTEM TESTING Since the agile design methodology is used for this project, recursive testing is done as each individual component is added to the system. As a result, the need to perform system testing is already exhausted in the component testing phase. This again proves the advantage of using the agile design methodology over other more traditional methods.

6.5 FURTHER RESULTS DISCUSSION The controller accuracy, speed, latency and operation under different physical environments tests have now been discussed. The question is now asked if the results show an improvement of the previously implemented work? Attention is first drawn to the paper by Doitsidis et al [63] that was discussed in Section 3.5.2. The initially implemented design in Chapter 4 was very similar to this, as the main purpose of the

6.21

Chapter 6: Results

Attention is now turned to the effects of the W N WE winds on the UAV. These two directional winds will have the greatest effect on the heading angle controllers response, and thus their effect will be investigated in Tests 11-20. This was done by setting the input wind matrix to [X X 0] T, where the initial X value was set to -0.5m/s and was increased by 0.1m/s during tests 11-20. The setpoints of the altitude, latitude and longitude controller were chosen so resulting in an altitude and heading setpoint of 1000m, and 100° respectively. The results of Table 6-5 show that the heading controller has a better performance remaining in the settling band compared to the altitude controller. Out of the 10 tests performed, only half of them resulted in oscillations. The maximum and minimum values of the oscillations also indicate that the peak to peak values are very small. It can thus conclude that the heading controller is much more robust compared to the altitude controller.

6.4 SYSTEM TESTING Since the agile design methodology is used for this project, recursive testing is done as each individual component is added to the system. As a result, the need to perform system testing is already exhausted in the component testing phase. This again proves the advantage of using the agile design methodology over other more traditional methods.

6.5 FURTHER RESULTS DISCUSSION The controller accuracy, speed, latency and operation under different physical environments tests have now been discussed. The question is now asked if the results show an improvement of the previously implemented work? Attention is first drawn to the paper by Doitsidis et al [63] that was discussed in Section 3.5.2. The initially implemented design in Chapter 4 was very similar to this, as the main purpose of the implementation phase of the project was to improve their results obtained. The authors of this paper mentioned that they had a problem with the altitude controller in terms of the presence of oscillations around the setpoint. Figure 3-38 shows that that they managed to achieve oscillations of about 25m peak to peak around the setpoint. Although the authors fail to mention anything about the wind conditions for this test, it can assumed that they took into consideration the wind specification of 0.5 m/s, conditions similar to the first transatlantic Aerosonde UAV flight. The result obtained by the improved altitude fuzzy controller discussed in Chapter 6 has the side effect of oscillations in the presence of background wind. However, the peak to peak value of the oscillations around the setpoint has a maximum value of 0.3m, which is much smaller than the previously implemented work, and negligible when taking into consideration the accuracy of most UAV altitude sensors. The only major effect of the oscillations is increased wear and tear on the elevator servos. In Section 3.3.6.4 it was stated that a coordinated turn should make use of both the aileron as well as the rudder control. This implemented solution does not make use of the latter. The main reason is due to the requirements of a UAV model which will have to be investigated to find the control rudder and aileron control actions that will result in the most optimal use of both. The tuning method used for this project was rather based on a trial-and-error method. It is now asked if the developed fuzzy autopilot is the most optimal in terms of controller performance? The answer for this question is most definitely no. The paper Nikolos I.K et al [64] discussed in Section 3.5.3 used a different approach in designing the controller. The method used first obtained the model of the UAV, and then used the model to obtain an ideally desired trajectory. This ideal trajectory was then used as a basis for designing the controller. The results obtained in the paper clearly show that the controller trajectory closely followed the ideal one. This proves that the design method initially based on model analysis yields a far better performance compared to a design method based on pilots instinct.

DT Jordan

2008

6.22

Chapter 6: Results

As a result, the results obtained in this project can definitely be improved if the model of the UAV was first obtained, although this was not an initial requirement of the project. However, if the requirement of not investigating the model is maintained, then the controller can still be based on the data obtained from a human pilot following an ideal trajectory. In this case, a self learning fuzzy controller can be used. This is definitely a growth option for this project. The only constraint with this approach is that the controller performance will be a function of the pilots experience, and thus a suitable pilot will definitely be needed. Although this controller was designed and implemented successfully by means of simulation in Simulink and Flightgear, the simulation does not represent the maximum possible execution speed of the controller. This is because there is a lot of background processing that MATLAB performs during each execution loop, uncontrollable by the developer. Thus, the conversion to a higher level programming language is definitely an advantage. Conversion to a language such as C/C++ would result in faster execution since the complier converts the source code to assembly language. This is the direct link between software and hardware when dealing with computers, and thus execution will be faster. This is a growth option of the project that will have to be performed if the controller is to be implemented on a real UAV.

6.6 CONCLUSION Any implemented project can only be verified if adequate test strategies are in place. For this particular project, this meant splitting up the tests into different scenarios i.e. in terms of the relationship between the current state of the UAV and the setpoints. The first test that was performed was set to investigate if the implemented system was working correctly i.e. the interface between Flightgear and Simulink. The test results concluded that these requirements were met. The tests were then further split up into the accuracy tests as well as the airspeed tests, initially with no background wind present. For the accuracy tests, the altitude controller always caused the altitude so settle ±4m away from the setpoint, while the heading controller caused the heading angle to settle ±0.5° from the setpoint. This resulted on the widening of the settling band to prevent oscillations. Since the accuracy of the heading controller is more important than that of the altitude controller, the advantage of the agile methodology was used to change the accuracy requirement on chapter 2 from 1.5m to 10m. This was found to be more realistic as most UAV altitude sensors have an accuracy of approximately 10m. The modification of the initial altitude controller accuracy requirements to make it more realistic resulted in all the accuracy test passing requirements to be fulfilled. The airspeed tests were passed for all of the tests, except when the altitude setpoint was below the current altitude. However, this does not jeopardise the controller’s capability. The robustness of the controller had to be tested. As a result the autopilot’s controlling capability was tested in different wind conditions, taking into consideration the planned background wind specification of the Aerosonde UAV during its first transatlantic flight in 1998. The results obtained indicate that the addition of wind results in the inability of the altitude controller to remain in the settling band, resulting in oscillations around the desired setpoint. This can be avoided by broadening the settling band; However, this will also influence the accuracy of altitude controller in the absence of wind. Oscillations also lead to an increased wear and tear on the servos, something which should be avoided. The tests also proved that not only are the latitude-longitude controller more accurate than the altitude controller, but it is also more robust in background wind. Oscillations were only present in half of the tests for the latitude-longitude controller. Although this controller improved immensely on the previously implemented work, the project can definitely be improved. The constant switching of the elevator and aileron controls definitely leads to increased wear and tear and this will have to be improved if the controller is to be used on a real DT Jordan

2008

6.23

Chapter 6: Results

UAV. This is done by making sure that there are no limit cycles. The design method used here was also based on a trial and error method rather than using a model to obtain an ideal trajectory, and then basing the fuzzy controller on the results obtained. The previously done work discussed in Chapter 3 proves that the latter method clearly leads to better performance. The only constraint is that a model of the UAV is needed. The alternative method can still be used. This will mean that the data obtained from a humans pilot flying an ideal trajectory will be used to design a controller. However the results obtained will be a function of pilot experience. The execution speed of this project can still be optimised if the Simulink diagram is converted to a higher level programming language such as C/C++. This is definitely a growth option of this project.

DT Jordan

2008

6.24

Chapter 7: Conclusion

7 CHAPTER 7: CONCLUSION CONCLUSION The dictionary defines engineering as “The discipline dealing with the art or science of applying scientific knowledge to practical problems”. During the design and implementation phases of the project, many engineers often forget that their main goal is to solve an engineering problem. Thus it is often necessary to surface time and time again during the design and implementation phase to make sure that one always has this chief goal in mind. Chapter 1 introduced the problem as well as the background framework surrounding the project. It

discussed how UAVs have become increasingly popular in the last couple of years, resulting from their ability to be used across many fields. Most modern day UAV research is focused around trying to eventually reach a stage where the UAV can fly without any human intervention. This would be to an advantage as this would minimise m inimise typical constraints associated with human flight, such a fatigue. However, the controller should also allow the UAV to fly with the accuracy of a human operator. The autopilot for the fixed wing UAV will be implemented with the aid of a control system. Fuzzy as well as PID controllers have the advantage in that they do not require a mathematical model of the system to be controlled. This model is often very difficult to obtain with larger non-linear systems. Although PID controllers work very well, their main disadvantage is that they do not mimic human operator’s way of thinking. Fuzzy controller on the other hand makes use of Fuzzy logic that was developed by Lotfi Zadeh. This type of control is often referred to as controlling with words, where the control of large systems is often executed with the aid of if-then rules. The main objective of this project was thus to develop a controller that has the accuracy of a human operator, but does not require a mathematical model of the t he system to be investigated. During the literature study of Chapter 3, the basic theory behind fuzzy controllers, as well as similar implemented work was discussed. The tools that will be used to successfully complete this project were also discussed. The basic fuzzy logic controller consists of four overall stages, mainly a fuzzification interface, a rule base, an interface mechanism as well as the defuzzification interface. Two popular types of fuzzy controllers exist, mainly the Mamdani and Sugeno fuzzy controllers, with the chief difference between the two been their defuzzification characteristics. The major problem encountered with fuzzy controllers when controlling non-linear systems is the formation oscillations around the setpoint, often referred to as limit cycles. This occurs when the settling band region is not made wide enough, resulting in interpolation between the equilibrium state and the nonequilibrium state. Three papers were found that are very similar to the scope of this project. This included A Framework for Fuzzy Based B ased UAV Navigation and Control [63], Roll Control of Unmanned Aerial Vehicles using Fuzzy Logic [64], and Combining Fuzzy and PID Control for an Unmanned Helicopter [65]. The first paper had had very similar goals for this project, and was thus used as the chief foundation for this project. However, the results of this paper yielded very large oscillations around the reference in terms of the altitude controller, and thus one o f the goals of this project was to improve these oscillations. The paper was also very vague when dealing with the details in how the system was implemented, as well as the background circumstances surrounding the test setup. This paper also limited the implementation to a Simulink based system, with the incorporation of the Aerosim Blockset as well as the fuzzy logic toolbox into their solution. The UAV used in their solution was the Aerosonde UAV. This model is included as part of the Aerosim toolbox. Since the chief foundation for this project, the paper by Doitsidis et al [63] used an altitude as well as a latitude-longitude controller autopilot, both of these were used were kept for this project. The initial accuracy requirements of the altitude and latitude-longitude controllers were set to 1.5m and 1.5° respectively. Another requirement was that the autopilot should be able to control the UAV in

DT Jordan

2008

7.1

Chapter 7: Conclusion

wind speeds up to 0.5m/s. This requirement was based on the expected wind conditions encountered by the Aerosonde UAV during its first transatlantic flight in 1998. The implemented solution used three set points, mainly the latitude, longitude and altitude given in the units of degrees, degrees and meters respectively. The initial results obtained indicated that limit cycles were present. This was overcome by widening the stable region of the membership functions. However, this widening resulted in the control variable settling at an offset of 4m for the altitude controller, and 0.5° for the latitude-longitude controller. Although this was not in the original accuracy range, it was noted that most INS sensors on UAVs typically have an accuracy of 10-15m. As a result, the original accuracy requirement was changed to 10m for the altitude controller. Testing the autopilot in wind, it was found that the wind resulted in the limit cycles. Although these are undesirable, the control variable still remained within the specifications. Some of the initial requirements stated in Chapter 2 were not taken into consideration, such as an option to engage/disengage the controller. This was not performed due to time constraints, however the Aerosim Blockset is included with a Simulink-Joystick interface block that could be used. Other growth options for this project include the incorporation of a throttle fuzzy controller into the autopilot. For this implementation, no throttle controller was included which resulted in an inefficient autopilot. Numerous design methods are also available when designing fuzzy controllers. For this project, a trial and error basis was used. However, a self learning fuzzy controller could be used. This will not require a model, mo del, and will be based on the data obtained from letting a pilot follow an ideal trajectory. Genetic algorithms can also be used to tune the membership functions, which will result in a more efficient autopilot. A neural fuzzy controller could also be investigated. This will result in a solution that incorporates the advantages of both fuzzy as well as neural network controllers. If the model is used, the equations representing the ideal trajectory c an be obtained. This can in turn be used to design the fuzzy controller. Investigating previously done work, it was found that this approach yielded better results in comparison to designing the controller without a model. Another advantage of this approach is that the model can be used to investigate if limit cycles will be present. Although there is definite growth for this project, the implemented controller is still sufficient to place on a real UAV. The procedure for this is as follows: 1. The Simulink file must be converted to a high level programming language such as C/C++, and executed on a single board computer 2. Sliders are to be placed at the controller inputs and outputs and will have to be tuned in order to adapt to the dynamics of the fixed wing UAV used (assuming that the Aerosonde UAV is not used) Since the major objectives have been met of the project, it can be concluded that the project was a success and that there is definite growth options for anyone who would like to continue.

DT Jordan

2008

7.2

References

8 REFERENCES [1]

Wikipedia: Unmanned aerial aircraft,

http://en.wikipedia.org/wiki/Unmanned_aerial_vehicle, Referenced on 23 February 2008 [2]

Advantages and disadvantages of unmanned aerial vehicles vehicles

http://people.bath.ac.uk/jw329/Advantages%20and%20Disadvantages.htm Referenced on 23 February 2008 [3]

RC operating frequencies in SA http://www.samaa.org.za/new_pages/frequencies.shtml

Referenced on 23 February 2008 [4]

Steeb Wili Hans, The Nonlinear Workbook, Chapter 17, World Scientific, Singapore 2005

[5]

Clarke, W.A., “Design Project Document Framework ”, ”, Department of Electrical and Electronic Engineering Science, Faculty of Engineering and the Built Environment, University of Johannesburg, 2008

[6]

Clarke, W.A., “Project Investigation Study Guide”, Department of Electrical and Electronic Engineering Science, Faculty of Engineering and the Built Environment, University of Johannesburg, 2008

[7]

Unmanned Aerial Aircraft

http://theuav.com/ Referenced on 4 March 2008 [8]

Sandy Riebeling, Unmanned aerial vehicles do dull, dirty, dangerous work , The Huntsville Times

[9]

Dull, dirty and dangerous

http://www.military-aerospace-technology.com/article.cfm?DocID=152 Referenced 4 March 2008 [10]

Pilot fatigue

http://aeromedical.org/Articles/Pilot_Fatigue.html Referenced 4 March 2008 [11]

Missy Frederick,”UAV use growing worldwide”, Space News, 23 January 2006 http://www.space.com/spacenews/archive06/UAV_012306.html Referenced 4 March 2008

[12]

Jantzen Jan, Foundations of Fuzzy Control, Wiley, England 2007

[13]

Sommerville Ian, Software engineering , 8th edition, Chapter 17, Addison Wesley, England 2007

DT Jordan

2008

8.1

References

[14]

Wikipedia: Agile software development ,

http://en.wikipedia.org/wiki/Agile_software_development Referenced on 5 March 2008 [15]

10 Key principles of agile software development

http://kw-agiledevelopment.blogspot.com/2007/02/10-things-you-need-to-know-aboutagile.html Referenced on 5 March 2008 [16]

Meyer, J., “System Engineering and Design study guide ”, Department of Electrical and Electronic Engineering Science, Faculty of Engineering and the Built Environment, University of Johannesburg, 2007

[17]

Air Force Technology - Predator - Unmanned Aerial Vehicle UAV

http://www.airforce-technology.com/projects/predator/ Referenced on 5 March 2008 [18]

Wikipedia: MQ-1_Predator ,

http://en.wikipedia.org/wiki/MQ-1_Predator Referenced on 5 March 2008 [19]

Wikipedia: RQ-4_Global_Hawk

http://en.wikipedia.org/wiki/RQ-4_Global_Hawk Referenced on 5 March 2008 [20]

Mathworks: Fuzzy Logic Toolbox, what is fuzzy logic www.mathworks.com/access/helpdesk/help/toolbox/fuzzy/fp72.html Referenced on 9 March 2008

[21]

Michael T. Goodrich, Roberto Tamassia Data Structures and Algorithms in Java , 4th edition, Chapter 4, John Wiley & Sons, United States of America 2006

[22]

AI-Social and Ethical considerations

http://www.aaai.org/aitopics/pmwiki/pmwiki.php/AITopics/Ethics Referenced on 26 March 2008 [23]

Suramya.com Technical Section: About Artifical Intelligence

http://tech.suramya.com/about_AI/ Referenced on 26 March 2008 [24]

Margaret A. Boden, The Age of Intelligent Machines: The social impact of Artificial Intelligence, The Age of Intelligent Machines 1990 http://www.kurzweilai.net/meme/frame.html?main=/articles/art0162.html Referenced 26 March 2008

[25]

Civil Aviation Authority

http://www.caa.co.za/ Referenced 26 March 2008 [26]

AERONAUTICAL COMMUNICATIONS PANEL (ACP): Unmanned Aerial Vehicles Update on the Progress with the UK http://www.icao.int/anb/panels/ acp/WG/f/wgf15/ACP-WGF15-WP18-uav.doc

DT Jordan

2008

8.2

References

Referenced 26 March 2008 [27]

The national institute of ethics (USA): Nine basic steps to personal ethical decision making,

http://www.niee.org/pd.cfm?pt=AECM Referenced 26 March 2008 [28]

IEEE code of ethics,

http://www.ieee.org/portal/pages/iportals/aboutus/ethics/code.htm Referenced 26 March 2008 [29]

The engineering council of South Africa code of professional conduct

http://www.ecsa.co.za/Legal/2CodeofConduct/2006/ECSACodeofConduct_17March2006.ht m Referenced 26 March 2008 [30]

The ACM code of ethics and professional conduct

http://www.acm.org/about/code-of-ethics Referenced 26 March 2008 [31]

Wikipedia: Autopilot

http://en.wikipedia.org/wiki/Autopilot Referenced on 2 April 2008 [32]

Century of flight: The development of the autopilot

http://www.century-offlight.freeola.com/Aviation%20history/evolution%20of%20technology/autopilot.htm Referenced on 2 April 2008 [33]

Zhang Huaguang, Liu Derong, Fuzzy Modelling and Fuzzy Control , Birkhäuser, Boston 2006

[34]

Kovačić Zdenko, Bogdan Stepan, Fuzzy Controller Design, Taylor & Francis group, 2006

[35]

Passino Kevin, Yurkovich Stephen, Fuzzy Control, Addison-Wesley, 1998

[36]

Zadeh LA, Fuzzy sets, Information and control, Chapter 8, 1965

[37]

Jantzen Jan, Design of Fuzzy Controllers, Technical University of Denmark Department of Automation, Tech. report no 98-E 864 (design), 19 Aug 1998.

[38]

Takagi T and Sugeno M, Fuzzy identification and systems and its application to modelling and control, IEEE transactions on Systems, man, and cybernetics, 116-132, 1985

[39]

Hill, G., Horstkotte, E. and Teichrow, J, Fuzzy-C development- users Manuel Togai Infralogic, 1990

[40]

Åström K, Hägglund T, PID controllers: theory, design and tuning 2 nd edition, Instrument Society of America, New-York 1995

[41]

Barnard R.H., Philpott D.R., Aircraft Flight , Longman, Harlow 2000

DT Jordan

2008

8.3

References

[42]

Stevens B.L, Lewis F.L, Aircraft control and simulation 2 nd edition, John Wiley and Sons, New Jersey 2003

[43]

Thai Technics.Com: Flight Directional Control

http://www.thaitechnics.com/fly/control.html Referenced 10 April 2008 [44]

Introduction to Aircraft Control

http://dcb.larc.nasa.gov/Introduction/Controls/sld001.htm Referenced 10 April 2008 [45]

Rauw, M.O.: "A Simulink Environment for Flight Dynamics and Control analysis - Application to the DHC-2 'Beaver' ".Part II: "Nonlinear analysis of the 'Beaver' autopilot". MSc-thesis, Delft University of Technology, Faculty of Aerospace Engineering. Delft, The Netherlands, 1993

[46]

Aircraft autopilot design

http://www.duke.edu/~tkm8/Aircraft%20Autopilot%20Design.doc Referenced 10 April 2008 [47]

Marais, E., “Informatics 2b lecture notes: Chapter 2 ”, Academy of Information Technology , Faculty of Science, University of Johannesburg, 2006

[48]

Wikepedia: Microsoft Visual Studio

http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Referenced 13 April 2008 [49]

Horstmann C, Computing Concepts with C++ Essentials 3 rd Edition, John Wiley and Sons, New Jersey 2003

[50]

Wikepedia: C Sharp (programming language)

http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29 Referenced 13 April 2008 [51]

Microsoft: Project DreamSpark

https://downloads.channel8.msdn.com Referenced 13 April 2008 [52]

Wikepedia: Dev-C++

http://en.wikipedia.org/wiki/Dev-C%2B%2B Referenced 13 April 2008 [53]

X-Plane: Laminar Research

http://www.x-plane.com/about.html Referenced 13 April 2008 [54]

X-Plane Plugin SDK Home Page

http://www.xsquawkbox.net/xpsdk/phpwiki/index.php?FrontPage Referenced 13 April 2008

DT Jordan

2008

8.4

References

[55]

Flight dynamics and control toolbox

http://home.wanadoo.nl/dutchroll/ Referenced 13 April 2008 [56]

The Dutchroll Blockset for Simulink

http://home.wanadoo.nl/dutchroll/dubsi.html Referenced 13 April 2008 [57]

Fuzz-C

http://bytecraft.com/Fuzzy_Logic Referenced 14 April 2008 [58]

Lofti A, Fuzzy Interface Systems toolbox for Matlab (FISMAT) , Department of Electrical and Computer Engineering, University of Queensland, 1993

[59]

AeroSim Blockset

http://www.u-dynamics.com/aerosim/ Reference 14 April 2008 [60]

FlightGear

http://www.flightgear.org/introduction.html Referenced 15 April 2008 [61]

Wikipedia: Microsoft Flight Simulator

http://en.wikipedia.org/wiki/Microsoft_Flight_Simulator Referenced 15 April 2008 [62]

FlouLib v 3.3

http://www.listic.univ-savoie.fr/modules.php?name=Content&pa=show&acronym=FlouLib Referenced 15 April 2008 [63]

Doitsidis L., Valavanis K. P., Tsourveloudis N. C., Kontitsis M. “A Framework for Fuzzy Logic Based UAV Navigation and Control”, Proceedings of the 2004 IEEE International Conference on Robotics & Automation New Orleans, LA, April 2004 .

[64]

Nikolos I. K., Doitsidis L., Christopoulos V. N., Tsourveloudis N. C., “Roll Conrol of Unmanned Aerial Vehicles using Fuzzy Logic”, WSEAS Transactions on System, pp.1039-1047, Issue 2, vol. 4, 2003.

[65]

Sanchez E. N, Becerra H.M, Velez C. M “Combining fuzzy and PID control for an unmanned helicopter” NAFIPS 2005 Annual Meeting of the North American Fuzzy Information Processing Society ,

2005 [66]

Aerosim, Aeronautical Simulation Blockset v1.2 Users Guide,

http://www.u-dynamics.com/aerosim/ Referenced 1 July 2008

DT Jordan

2008

8.5

References

[67]

Flightgear, The Flightgear Manuel v1.0, December 15 2007

http://www.flightgear.org/ Referenced 1 July 2008 [68]

The Aerosonde system

http://www.aerosonde.com/downloads/the_aerosonde_system.doc Referenced 1 July 2008 [69]

Atlantic crossing by Aerosonde

http://www.barnardmicrosystems.com/L4E_atlantic_crossing_I.htm Referenced 1 July 2008

DT Jordan

2008

8.6

Appendix A

9 APPENDIX A The first five outcomes as set by ECSA are as follows: Table 9-1: ECSA engineering outcomes [16]

1:

ECSA OUTCOME Problem solving

LEVEL ASSESSED

Problem solving skills are to be demonstrated during execution of the project.

Learning outcome: Demonstrate competence to identify, assess, formulate and solve convergent and divergent engineering problems creatively and innovatively

2:

Application of scientific and engineering knowledge are demonstrated by application to the project.

Application of scientific and engineering knowledge

Learning outcome: Demonstrate competence to apply knowledge of mathematics, basic science and engineering sciences from first principles to solve engineering problems

3:

Engineering design is demonstrated by the design work required for the project.

Engineering Design

Learning outcome: Demonstrate competence to perform creative, procedural and non procedural design and synthesis of components, systems, engineering works, products or processes.

4:

Investigations, experiments and data analysis

Limited assessment of investigation, experimental and data analysis.

Learning outcome: Demonstrate competence to design and conduct investigations and experiments.

The demonstration of engineering methods is one of the cornerstones of the course and is assessed during tests and project execution.

5: Engineering methods, skills and tools, including Information Technology Learning outcome: Demonstrate competence to use appropriate engineering methods, skills and tools, including those based on information technology.

DT Jordan

2008

9.1

Appendix B

10 APPENDIX B 10.1FUZZY REASONING

∈

In order to understand fuzzy logic and fuzzy control, one has to first understand fuzzy sets. Traditional classical sets are defined as a collection of elements or objects which can be finite, countable or overcountable [4]. With classical sets, a single element can either belong to a set or not. Here the degree of membership of an element belonging to a set is either true or false. Zadeh, the founder of fuzzy logic, stated [12] : “ Clearly, the ‘class of all real numbers that are greater than one’ or ‘the class of beautiful woman’ or ‘the class of old men’ do not constitute classes or sets in the usual mathematical sense of these terms.” For this reason, fuzzy sets were developed [4]. These extend the classical notation of binary membership to accommodate various degrees of membership over the interval [0, 1]. Here, the endpoint values “0” and “1” conform to no membership or full membership respectively. The values in between the endpoint can represent the various degree of membership for an element in some universe . The definition of fuzzy sets is now as follows [12]: Definition Fuzzy sets:

Given a collection of objects ordered pairs Where .

஺ሺ ሻ

a fuzzy set

in

is defined as a set of

≡ ሼ x,μ ሺxሻ |x ∈ ሽ

is called the membership function for the set of all objects

≡ ஺ሺ ሻ

in

For the above definition, the symbol “ ” stands for “defined as” The membership function relates to

each a membership grade

, a real number in the closed interval [0, 1].

It can also be seen that when working with fuzzy sets, it is necessary to work with pairs This is known as a fuzzy singleton.

x,μ ሺxሻ

.

Consider the description of tall people. With classical set theory, people smaller than 1.75m might be considered not tall, while people taller than 1.75m might be considered tall. With fuzzy set theory, the degree of membership indicates how tall a person is. Both the fuzzy and crisp sets are presented in the Figure 10.1:

DT Jordan

2008

10.1

Appendix B

Figure 10-1: Two definitions of the set of "tall people"

Membership functions come in many forms. These include trapezoidal as well as triangular shapes. Fuzzy sets have their own operations also [12]. Two fuzzy sets are equal is they have the same membership function i.e.

= ℬ ≡ ሺ ሻ= ℬሺ ሻ

For all x A fuzzy set

is a subset of fuzzy set

For all x

ℬ

if

is less than or equal to

⊆ ℬ ≡ ሺ ሻ≤ ℬሺ ሻ

ℬ

. i.e.

Other set operations include the fuzzy union, intersection and compliment. The fuzzy union of

ℬ ∪ℬ ≡ሼx,μ ∪ℬሺxሻ |x ∈ and μ ∪ℬሺxሻ= max ሺμ ∪ℬሺxሻ, μ୆ሺxሻሻሽ and

defined on the mutual universe

is:

An example of the union operator are presented in the Figure 10.2:

Figure 10-2: Union of two fuzzy sets A and B

ℬ ∩ℬ ≡ሼx,μ ∩ℬሺxሻ |x ∈ and μ ∩ℬሺxሻ= min ሺμ ∪ℬሺxሻ,μ୆ሺxሻሻሽ

The fuzzy intersection of

and


is:

An example of the intersection operator are presented in the Figure 10.3:

DT Jordan

2008

10.2

Appendix B

Figure 10-3: Intersection of two fuzzy sets A and B

The fuzzy compliment of


is:

ҧ ≡ ሼ x,μ ҧሺxሻ |x ∈ and μ ҧሺxሻ= 1− μ ሺxሻሻሽ

Figure 10-4: Fuzzy compliment of A and B

Fuzzy logic also makes use of linguistic variables. This takes a linguistic value, which is a fuzzy set that is defined on a universe.

μ ሺxሻ

A hedge takes a linguistic value and modifies its meaning. Consider a membership function that describes a young person. Hedges of this might include the following membership functions:

μ୴ୣ୰୷ ሺxሻ= μଶ ሺxሻ μ୫୭୰ୣ ୭୰ ୪ୣୱୱ ሺxሻ= μଵ/ଶሺxሻ μୣ୶୲୰ୣ୫ୣ୪୷ ሺxሻ= μଷ ሺxሻ μୱ୪୧୥୦୲୪୷ ሺxሻ= μଵ/ଷሺxሻ Their membership functions are given in Figure 10.5:

DT Jordan

2008

10.3

Appendix B

Figure 10-5: Hedging on the linguistic variable "young"

The relation

ℛ

describes the relation between two sets and is typically written in the form

The simple Cartesian product of

and

is described by:

ℛ

× = ሼ x,y |x ∈ , ∈ ሽ ℬ × ℛ ≡ ሼ x,y ,μୖሺx,yሻ|ሺx, y ሻ ∈ × ሽ ℛ⊆ × ℬ × ×ℬ =ሼx,y ,μ ×ℬሺx,yሻ|x ∈ , ∈ ,μ ×ℬሺx,yሻ= minሺμ ሺxሻ, ሺμℬሺxሻሻሽ ℬ ℛ × × × ℛ ∘ =ቐ x, z , ራ୷ μℛሺx,yሻ∩ μ ሺy,zሻ ቮx ∈ ,y ∈ ,z ∈ ቑ ℛ

The fuzzy binary relation is defined as: Let and be fuzzy sets defined on Then the fuzzy sets in with the membership function

and

respectively.

Is a binary fuzzy relation

The fuzzy Cartesian product is defined as: Let and be fuzzy sets defined on respectively. Then the fuzzy set in with the membership function

Is the Cartesian product of

and

and

There is also also have compositions of relations.

The fuzzy relational composition is defined as follows: Let and respectively. Then the fuzzy set in

and be two fuzzy relations defined on with the membership function:

Is the composition of with

In classical Boolean set theory, linguistic connection between sets use typical words like “if”, “and” “not” and “or”. The symbols used are: Table 10-1: Logical operators symbols

SYMBOL

CONNECTIVE STATEMENTS

∧∨

Not And Or

¬

DT Jordan

2008

10.4

Fuzzy Controller Autopilot for a Fixed Wing Unmanned Aerial Vehicle

Recommend Documents