Fuzzy Controller Autopilot For A Fixed Wing Unmanned Aerial Vehicle PDF

FUZZY CONTROLLER AUTOPILOT FOR A FIXED WING
UNMANNED AERIAL VEHICLE
by
DOMINIC TIMOTHY JORDAN
A mini-dissertation 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 INTRODUCTION AND BACKGROUND ............................................................................................................. 1.1
1.2 PROBLEM STATEMENT .............................................................................................................................. 1.4
1.3 THE PROJECT OBJECTIVE............................................................................................................................ 1.5
1.4 SCOPE OF THE PROJECT............................................................................................................................. 1.5
1.5 DESIGN METHODOLOGY TO BE FOLLOWED .................................................................................................... 1.5
1.6 DELIVERABLES ........................................................................................................................................ 1.7
1.7 OVERVIEW OF THE DOCUMENT .................................................................................................................. 1.7
1.8 CONCLUSION .......................................................................................................................................... 1.9
2 CHAPTER 2: REQUIREMENTS ANALYSIS ................................................................................................ 2.1
2.1 INTRODUCTION ....................................................................................................................................... 2.1
2.2 IDENTIFIED ISSUES AND CONSTRAINTS .......................................................................................................... 2.1
2.3 ASSUMPTIONS AND EXCLUSIONS................................................................................................................. 2.6
2.4 REQUIREMENTS SPECIFICATION .................................................................................................................. 2.6
3 CHAPTER 3: LITERATURE STUDY ........................................................................................................... 3.1
3.1 INTRODUCTION AND OVERVIEW ................................................................................................................. 3.1
3.2 STANDARDS AND LEGAL CONSIDERATIONS .................................................................................................... 3.1
3.3 THEORY AND METHODS ............................................................................................................................ 3.1
3.4 TOOLS................................................................................................................................................. 3.23
3.5 SIMILAR WORK ..................................................................................................................................... 3.27
3.6 CONCLUSION ........................................................................................................................................ 3.35
4 CHAPTER 4: DESIGN .............................................................................................................................. 4.1
4.2 DETAILED DESIGN .................................................................................................................................... 4.1
4.3 DESIGN ALTERNATIVES ........................................................................................................................... 4.15
4.4 CONCLUSION ........................................................................................................................................ 4.15
5 CHAPTER 5: IMPLEMENTATION ............................................................................................................ 5.1
5.2 INDIVIDUAL SYSTEM INCREMENT IMPLEMENTATION PROCESS AND ISSUES ........................................................... 5.1
5.3 INTEGRATION PROCESS AND ISSUES ........................................................................................................... 5.19
5.4 COST SUMMARY.................................................................................................................................... 5.19
5.5 SETTING UP AND USING THE SYSTEM ......................................................................................................... 5.20
5.6 CONCLUSION ........................................................................................................................................ 5.23
6 CHAPTER 6: RESULTS ............................................................................................................................ 6.1
6.2 TEST AND EVALUATION STRATEGY, SETUP AND METHODOLOGY ......................................................................... 6.1
6.3 COMPONENT TESTING .............................................................................................................................. 6.2
6.4 SYSTEM TESTING ................................................................................................................................... 6.22
6.5 FURTHER RESULTS DISCUSSION ................................................................................................................. 6.22
6.6 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 FUZZY REASONING ................................................................................................................................. 10.1
DT Jordan 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].............................................................................. 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: 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 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: Fuzzy PD controller ........................................................................................................ 3.15
Figure 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: Aircraft yaw control ....................................................................................................... 3.20
Figure 3-21: Aircraft pitch control ..................................................................................................... 3.20
Figure 3-22: Aircraft roll control ........................................................................................................ 3.21
Figure 3-23: Inner loops of the autopilot ........................................................................................... 3.22
Figure 3-24: Outer loops of the autopilot .......................................................................................... 3.22
Figure 3-25: Simple Pitch-altitude hold autopilot .............................................................................. 3.22
Figure 3-26: More complex pitch-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: 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: 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 acting on a plane during a turning ..................................................................... 3.32
Figure 3-39: Heading error membership functions Figure 3-40: Roll angle membership functions
3.33
Figure 3-41: change of roll angle membership functions .................................................................. 3.33
Figure 3-42: The control 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 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-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 MEANING
3-D Dirty, dull and dangerous
ACM Association for computing machinery
API Application programming interface
BOA Bisector of area
CAA Civil aviation authority
COG Centre of gravity
COGS Centre of gravity method for singletons
DUBSI Dutchroll Blockset for Simulink
ECSA Engineering council of South Africa
FAA US Federal Aviation Administration
FAM Fuzzy associative memory
FDC Flight dynamics and control
FINC fuzzy incremental controller
FP Fuzzy proportional
FPD Fuzzy proportional derivative
FPD+I fuzzy proportional integral
GUI Graphical user interface
HIL Hardware in the loop
ICAO International Civil Aviation Organisation
IDE Integrated development environment
IEEE Institute for electrical and electronic engineers
INS Inertial navigation system
Kbps Kilobytes per second
LM Leftmost maximum
MALE Medium-altitude long endurance
MIMO Multiple-input-multiple-output
MOM Mean of maxima method
NB Negative Big
Neg Negative
NM Negative Medium
OS Operating systems
PB Positive Big
PD Proportional derivative
PID Proportional, integral derivative
Pos Positive
RC Remote controlled
RM Rightmost maximum
SBC Single boarded computer
SISO Single-input-single-output
TBA To be announced
TCP/IP Transmission control protocol/Internet protocol
UAV Unmanned aerial vehicle
UCAV Unmanned combat air vehicle
DT Jordan 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 pilots 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 birds-
eye-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 link, 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 Proportional constant
KI Integral constant
KD Proportional constant
e: 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 DATE
Hand in chapter 1 and the project As soon as possible 3 March 2008
management plan
Hand in chapter 2,3 7 April 2008
Deliver first seminar Conference date to be TBA
announced
Hand in chapter 4 Last day of block week 30 May 2008
Hand in chapter 5,6 First Friday day of fourth term 12 September 2008
Delivery of second seminar Conference date to be TBA

announced
Hand in draft version of mini- Last day of fourth day 24 October 2008
dissertation (one copy for evaluation by
study leader)
Hand in mini-dissertation First day of Exam 3 November 2008
Oral Examination During the normal examination 3-21 November 2008
time period, to be arranged with
study leader
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 Chapter 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 Chapter 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 Chapter 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 Chapter 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 Chapter 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 Africas 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 groups 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
o Speed and latency
o Safety critical requirements
o The precision and accuracy requirements
o Reliability and availability requirements
The operational requirements such as:
o Expected physical environment requirements
o Expected technological environment requirements
o Maintainability and support requirements
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 1024768 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 fuzzy-
controller 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 Johannesburgs 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
e: Error term
u Controller output
sampling time , the approximation becomes:

When dealing with digital controllers, the equation shown above has to be approximated. With a
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 experts 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 experts 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 multiple-
input-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. If error is Neg and change in error is Neg then output is NB

2. If error is Neg and change in error is Zero then output is NM
3. If error is Neg and change in error is Pos then output is Zero
4. If error is Zero and change in error is Neg then output is NM
5. If error is Zero and change in error is Zero then output is Zero (2)
6. If error is Zero and change in error is Pos then output is PM
7. If error is Pos and change in error is Neg then output is Zero
8. If error is Pos and change in error is Zero then output is PM
9. 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
ERROR CHANGE IN ERROR OUTPUT
Neg Pos Zero
Neg Zero NM
Neg Neg NB
Zero Pos PM
DT Jordan 2008 3.4

Zero Zero Zero

Zero Neg NM
Pos Pos PB
Pos Zero PM
Pos Neg 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
Or
x x
x + x x x
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 Figure 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:
1 13 4
-./0 1 =
1 2 7
26 4
Where:
1 is the independent variable on the universe

The maximum value is 1
13 is the peak relative to the universe

6 is the standard deviation
The bell membership function is given by:
1 13 4/ ?@
-89:: 1 = ;1 + < = >
6
A is a usually positive extra value that affects the width of the membership function, as well
Where:
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:
BC = - ,C
DDD -,C EAG
H
DDD
Depending on the firing strength, one can determine the activation of a rule. This is typically
weighing factor IC [0, 1] which is the degree of confidence (this is determined by the designer).
determined by making use of the multiplication operator * or min. A rule k can be weighted by a
Using this, the firing strength is now modified too:
BC = IC BC
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:
-1 1
=
-1
1 is a running point in the discrete universe

Where:
-1 ) 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:
-O O
=
-O
O is the position of the singleton H in the universe

Where:
-O ) is equal to the firing strength B of rule H
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.
S R/S
= P1Q -11 = -11 U
RT S
1 is a running point in the universe

Where:
-1) is its membership value in the membership function

VH is the leftmost value of the universe
VA1 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:
WX X
@ HO Y@ ,
4 HO Y4 , ,
C HO YC
[ = G
@ ,
4 , ,
C
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 oscillations 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 error E falls between two neighbouring
discreet values in the universe, Ei and Ei+1, such that Ei < E < Ei+1 and the change in error CE falls
between two neighbouring discrete values in the universe such that CEj < CE < CEj+1
The resulting control signal is found by interpolating linearly in the E axis direction between the first
pair:
@ = G\; ^H, , ^H + 1,

And the second pair
4 = G\; ^H, + 1, ^H + 1, + 1
= G_\; @ , 4
And in the CE axis direction,
Where the function g is linear interpolation, and Fij 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
characteristics. If the connectives and for the min and max respectively, then this introduces
might lead to nonlinear characteristics. Secondly the interface engine can cause nonlinear
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

conclusions sets `O , 1a , O must be the sum of the peak positions.

Since the number of terms in each family determines the number of rules. With singleton
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 = ^\, _\ equivalent to the
summation = \ + _\, the following conditions have to be fulfilled:
1. Triangular sets, crossing at m = 0.5

2. Rules: complete -combination
3. Define as *
4. Use conclusion singletons, positioned at sum of input peak positions
5. 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. Build and tune a conventional PID controller

2. Replace it with a linear fuzzy controller
3. Make the fuzzy controller nonlinear
4. 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:
b = Xcd\
e db
Where the function f denotes the rule based mapping. It is generally nonlinear, but with the linear
approximation:
Xcd\
e d\

The control signal is thus given by:
b = d\
db = d\ db

The gains of the fuzzy controller correspond to the gains of the linear controller by the following
d\ db =
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

b = Xd\
, d_\
g db
This time, the function f is a rule base mapping, and its surface depends on two variables. When
making use of the linear approximation:
Xd\
, d_\
g d\
+ d_\
g
The control signal now becomes:
d_\
b = d\ db
+
g
d\
And the gains are related by:
d\ db =
d_\
=
d\
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:
b = hXcd\
, d_\
g e + dW\
k db
ij@
Making use of the linear approximation, the control signal now becomes:
T
d_\ dW\
b = d\ db h
+
g +
k
d\ d\
ij@
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:
d\ db =
d_\
=
d\
dW\ 1
=
d\
The incremental controller adds a change in control signal to the current control signal. This is
3.3.4.4 Fuzzy incremental control
done by:
= 1 +

1 1
= +

with = 0. A block diagram of a fuzzy incremental controller (FINC) is given in Figure 3-16:
It can be seen that this was taken from the equation representing the output of a PID controller,
Figure 3-16: Fuzzy incremental control
The fuzzy incremental controller is very similar to the FPD controller. As a result, the conclusion in
GPU, since the control signal b is the sum of all the previous increments, then the control signal
the rule base is now called the change in output (cu), and thus the gain of the output is accordingly
given by:
T
b = Xcd\
, d_\
g e d_b
ij@
Since the mapping here is usually nonlinear, with a favourable choice of design there can be a linear
approximation. This is given by:
T
d\
b d_\ d_b h
+
k
d_\
ij@
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 Kp 1/Ti Td
FP GE*GU
FInc GCE*GCU GE/GCE
FPD GE*GU GCE/GE
FPD+I GE*GU GIE/GE GCE/GE
3.3.4.5 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
simple example of this is as follows: Suppose that the controller gain has been tuned to d\ = 100
Saturation of the input signal leads to the upsetting on the linearity of the fuzzy controller [12]. A
for a particular plant. If d\ is set to d\ = 400 and tune all the other gains in accordance to Table 3-
4, and keep the proportional gain, differential time, as well as the integral time the same, then the
controller saturates.
To avoid this, and keeping to Table 3-4, a scaling term setting is added:
cd\
+ d_\
g e db
To
1
cB d\
+ B d_\
g e db
B
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 of
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 given in Figure 3-31 [42]
DT Jordan 2008 3.22

Figure 3-26: More complex pitch-altitude hold autopilot
Here, the control variable is:
o =p+B
The controller does not hold the flight angle p 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
Matlabs 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
o This is the tools that allows the developer to create Matlab functions and files
The Matlab mathematical function library
o This is a vast collection of computational algorithms
DT Jordan 2008 3.23

The Matlab language

o This is a high level language used to perform computations
Graphics
o This includes the tools to display visually display data in the form of e.g. graphs
The Matlab application programming interface (API)
o This library allows the developer to write c and Fortran programs that communicate
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
students 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 worlds 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 specifically
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 FuzzyC 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 various 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
o Altitude error negative (AEN)
o Altitude error stale (AES)
o Altitude error positive (AEP)
For the change in altitude error
o Negative change (NC)
o Stable change (SC)
o Positive change (PC)
For the airspeed
o Small airspeed (SA)
o Medium airspeed (MA)
o Big airspeed (BA)
DT Jordan 2008 3.27

The linguistic variables describing the outputs are:

For the elevator
o Negative elevator (NE)
o Stable elevator (SE)
o Positive elevator (PE)
For the throttle
o Low throttle (LT)
o Medium throttle (MT)
o High throttle (HT)
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

For the heading error
o Center 1 (C1)
o Too Right (TR)
o Right (R)
o Center (C)
o Left (L)
o Too Left (TL)
o Center 2 (C2)
For the change of heading error
o Negative (N)
o Stable (S)
o Positive (P)

For the roll angle
o Too left (TL)
o Left (L)
o Ahead (A)
o Right (R)
o Too right (TR)
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
o Right big (rb)
o Right medium (rm)
o Right small (rs)
o Zero
o Left big (lb)
o Left medium (lm)
o Left small
For the heading error:
o Negative big (nb)
o Negative medium (nm)
o Negative small (ns)
o Zero
o Positive big (pb)
o Positive medium (pm)
o Positive small (ps)
Controller outputs:
The linguistic variables that represent the controller outputs are as follows:
For the roll command:
o Right big (rb)
o Right medium (rm)
o Right small (rs)
o Zero
o Left big (lb)
o Left medium (lm)
o Left small
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 Takagi-
Sugeno 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 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 non-
linear, 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
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 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

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:
o Scopes
o Addition blocks
o Multiplication blocks
o Etc.
Adequate model of a UAV in Simulink that has the following inputs:
o Rudder control input
o Aileron control input
o Elevator control input
o Throttle control input
Adequate model of a UAV in Simulink with the following block outputs:
o Outputs of various UAV sensor inertial navigation system (INS) readings
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:
o Atmosphere model
o Earth model
Fuzzy controller support in the form of Simulink Blocksets that will consist of interfaces
for specifying:
o Controller inputs
DT Jordan 2008 4.1

Chapter 4: Design
o Controller outputs
o Controller membership functions and linguistic variables
o The fuzzy if-then rule base
Simulink blocks to allow the UAV to be seen graphically in an external flight simulator
e.g. Flightgear, X-Plane, Microsoft flight simulator
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= 71 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 31 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 151 vector of the aircraft states [u v w p q r e0 ex ey ez Lat Lon Alt mfuel Weng ]T
2. Sensors = the 181 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 31 vector of aircraft velocity in wind axes [Va ]T in the units of [m/s rad rad]
Angular Acc = the 31 vector of body angular accelerations [ pg qg rg ]T

Mach = the current aircraft Mach number
Euler = the 31 vector of the attitude of the aircraft given in Euler angles [ ]T , in the
units of radians
AeroCoeff = the 61 vector of aerodynamic coefficients [CD CY CL Cl Cm Cn ]T , in the units of
rad1
EngCoeff = the 51 vector of engine coefficients [MAP tg/u tgv09: BSFC P]T given in the
PropCoeff = the 31 vector of propeller coefficients [J CT CP ]T
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 model 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 27-30 lb, 10 ft
Engine 24 cc, 1.2 kw, fuel injected using premium unleaded petrol
Navigation GPS
Operation
Staff for Launch and 3 people: Controller, Technician, Pilot/Maintenance
Recovery
Staff for Flight Operations
1 Person for up to 3 aircraft
Ground Equipment Proprietary Staging Box, personal computer (laptop), GPS
antenna, aviation and local communications radios
Flight Fully autonomous, under Base Command
Launch and Recovery Launch from car roof rack (catapult option), land on belly,
Autonomous or with pilot
Ground & air UHF or Satcoms (Iridium) to Aerosonde, VHF to field staff
communications 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, 2 Vaisala RSS901 Sondes for temperature, pressure and
Humidity, Wind 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 31 vector of geographic position [Lat Lon Alt] in the units of [rad rad m]
Euler = the 31 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

Matlabs 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 latitude-
longitude 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 papers 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 outputs
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 Section 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

NC S PC
AEN PE PE PE
Altitude AES PE S NE
error 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:

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:
SA HT
Airspeed MA MT
BA 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 latitude-
longitude 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 Section 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
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

N S P
TR R R TR
R TL L L
C L A R
heading L R R TR
error TL TL L L
C1 L A R
C2 L A R
DT Jordan 2008 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" --disable-

splash-screen --native-fdm=socket,in,30,,5500,udp --fdm=external
Figure 4-23: Starting Flightgear in external mode to accept 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 latitude-
longitude 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

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

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.

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 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-splash-

screen --native-fdm=socket,in,30,,5500,udp --fdm=external
5.2.3 Altitude fuzzy logic controller framework setup

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 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: 0.5*pi/180
Bank angle to Aileron Integral: 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 5.7

Figure 5-10: Bank Angle to Aileron PI system

There were no issues encountered during this implementation phase.
5.2.4 Altitude fuzzy controller setup

Matlabs FIS editor that is provided with the fuzzy logic toolbox was used to construct the fuzzy
interference system. The initial controllers 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.1 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 enable 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 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 Type Value
AEN Trapezodial [-400 -400 -100 -4]
AES Triangular [-5 0 5]
AEP Trapezodial [4 100 400 400]
Table 5-2: Change in altitude error membership function linguistic variables and their values
NC Trapezodial [-100 -100 -0.2]
S Triangular [-0.3 0 0.3]
PC 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
PPPE Constant 0.045
PPE Constant 0.02
PE Constant 0.0025
S Constant 0
NE Constant -0.005
NNE Constant -0.05
NNNE Constant -0.09
DT Jordan 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

NC S PC
AEN PPPE PPE PPE
Altitude AES PE S NE
error AEP 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

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 Latitude-
Longitude 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 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

There were no issues encountered during this implementation phase
DT Jordan 2008 5.16

5.2.6 Latitude-Longitude fuzzy controller setup
Again, Matlabs 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.1 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 values
C1 Triangular [-6.283 -6.283 -6.257]
TR Trapezodial [-6.28 -6.184 -4.204 -3.142]
R Trapezodial [-3.142 -2.094 -0.1047 -0.00873]
C Triangular [-0.0262 0 0.0262]
L Trapezodial [0.00873 0.1047 2.094 3.142]
TL Trapezodial [3.142 4.204 6.184 6.283]
C2 Triangular [6.257 6.283 6.283]
Table 5-6: Change in heading error membership function linguistic variables and their values
N Triangular [-1 -1 -0.1284]
S Triangular [-0.15 0 0.15]
P 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
TTR Constant 16
TR Constant 8.5
R Constant 2
A Constant 0
L Constant -2
TL Constant -8.5
TTL Constant -16
The original fuzzy if-then were also changed as follows:
1. If Heading error is TR and Change of heading error is N then Roll angle is TR

2. If Heading error is TR and Change of heading error is S then Roll angle is TR
3. If Heading error is TR and Change of heading error is P then Roll angle is TTR
4. If Heading error is R and Change of heading error is N then Roll angle is TTL
5. If Heading error is R and Change of heading error is S then Roll angle is TL
6. If Heading error is R and Change of heading error is P then Roll angle is TL
7. If Heading error is C and Change of heading error is N then Roll angle is R
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 L
10. If Heading error is L and Change of heading error is N then Roll angle is TR
11. If Heading error is L and Change of heading error is S then Roll angle is TR
12. If Heading error is L and Change of heading error is P then Roll angle is TTR
13. If Heading error is TL and Change of heading error is N then Roll angle is TTL
14. If Heading error is TL and Change of heading error is S then Roll angle is TL
15. If Heading error is TL and Change of heading error is P then Roll angle is TL
16. If Heading error is C1 and Change of heading error is N then Roll angle is R
DT Jordan 2008 5.18

18. If Heading error is C1 and Change of heading error is P then Roll angle is L
19. If Heading error is C2 and Change of heading error is N then Roll angle is R
21. 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

N S P
TR TR TR TTR
R TTL TL TL
C R A L
heading L TR TR TTR
error TL TTL TL TL
C1 R A L
C2 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 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" --disable-

splash-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 5-
29:
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 latitude-
longitude 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.
Matlabs 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 Matlabs 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

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:
Latitude: -26.180
Longitude: 27.998
Altitude: 1000m
The latitude and longitude coordinates were set to the coordinates of the Electrical and Electronic
department at the University of Johannesburgs 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
Altitude Latitude Longitude setpoint Test passing Test failing
Test Test description
setpoint (m) setpoint (deg) (deg) requirements requirements
Sustained Set up the Simulink file to allow the UAV 1000m -29.977 30.944 The UAV The UAV does not
forward flight to fly from Johannesburg to Durban. remains flying remain flying after
mode test Run the Simulink file for 2000s after 2000s 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
o 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
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 failing
Test Test setup Test passing requirements
requirements
Temporary disconnect the controller inputs of the Flightgear should indicate a visual model of the UAV banking Any other results other
User blue Aerosonde UAV block of Figure 5-29 and to the left. The Current Altitude scope should indicate that than that of the test
interface replace it by a constant 71 matrix input set to [0 the current altitude decreasing, while the Current bank Passing Requirements
test -0.1 0 0 0.4 13 1]T. Run the Simulink file for 100s. angle scope should indicate that the UAV is banking to the
left

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
a speed of 29m/s. To test these requirements, the following tests were performed. For this entire test, the wind input to the blue Aerosonde UAV block
was set to [0 0 0]T i.e. no background wind present. The initial UAV latitude, longitude and altitude setpoints were set to, -26.180, 27.998 and 1000m
respectively- the GPS coordinates of the University of Johannesburg obtained from Google earth. The test setup used is given in Table 6-3:
Table 6-3: Process to test the accuracy of the controller

Setpoints
Test Test failing
Test Test setup and description Lat() Long Alt(m) Test passing requirements
# requirements
()
Set up the set point of the altitude 0 27.998 1050 The Current altitude scope in The UAV altitude
controller to be 50m above the current Figure 5-28 should indicate the does not increase to
Altitude
position of the UAV i.e. 1050m. The UAV altitude increase from 1000m 1050m and/or the
controller 1
latitude and longitude setpoints are chosen to 1050m with an accuracy of accuracy exceeds
test
to result in a heading angle setpoint of 0. 1.5m. The Current airspeed 1.5m.The UAV speed
Run the Simulink file for 1800s (1/2 hour) scope waveform should 29m/s exceeds 29m/s
controller to be 50m bellow the current Figure 5-28 should indicate the does not decrease to
Altitude position of the UAV i.e. 950m. The latitude UAV altitude increase from 1000m 950m and/or the
2
test and longitude setpoints are chosen to to 1050m with an accuracy of accuracy exceeds
result in a heading angle setpoint of 0. 1.5m. The Current airspeed 1.5m.The UAV speed
Run the Simulink file for 1800s (1/2 hour) scope waveform should 29m/s exceeds 29 m/s
controller to be the same as the current Figure 5-28 should indicate the does not remain at
Altitude position of the UAV i.e. 1000m. The UAV altitude remaining at 1000m 1000m and/or the
3
test latitude and longitude setpoints are chosen with an accuracy of 1.5m. The accuracy exceeds
to result in a heading angle setpoint of 0. Current airspeed scope 1.5m.The UAV speed
Run the Simulink file for 1800s (1/2 hour) waveform should 29m/s exceeds 29 m/s
Set up the set points of the latitude- -31.18 14.26 1000 The Current Heading scope in Either the UAV
longitude controller so that the resulting Figure 5-28 should indicate the heading angle does
Lat-long heading angle setpoint is 110 to the right UAV heading angle decrease from not decrease to 250
controller 4 of the current position of the UAV i.e. - 360 to 250 with an accuracy of and/or the accuracy
test 110, and an altitude setpoint of 1000m. 1.5. The Current airspeed scope exceeds 1.5. The
Run the Simulink file for 1800s (1/2 hour) waveform should 29m/s UAV speed exceeds
29 m/s
DT Jordan 2008 6.5

Chapter 6: Results
Lat-long heading angle setpoint is 300 to the right UAV heading angle increase from not increase to 60
controller 5 of the current position of the UAV i.e. - 0 to 60 with an accuracy of 1.5. and/or the accuracy
test 300, and an altitude setpoint of 1000m. The Current airspeed scope exceeds 1.5. The
Run the Simulink file for 1800s (1/2 hour) waveform should 29m/s UAV speed exceeds
29 m/s
Set up the set points of the latitude- 0 27.998 1000 The Current Heading scope in Either the UAV
Lat-long heading angle setpoint is the same as the UAV heading angle remaining at 0 not remain at 0
controller 6 current position of the UAV i.e. 0, and an with an accuracy of 1.5. The and/or the accuracy
test altitude setpoint of 1000m. Run the Current airspeed scope exceeds 1.5. The
Simulink file for 1800s (1/2 hour) waveform should 29m/s UAV speed exceeds
29m/s
Lat-long heading angle setpoint is 110 to the left of UAV heading angle increase from not increase to 110
controller the current position of the UAV i.e. 110, 0 to 110 with an accuracy of 1.5. and/or the accuracy
7
test and an altitude setpoint of 1000m. Run the The Current airspeed scope exceeds 1.5. The
29 m/s
Lat-long heading angle setpoint is 300 to the left of UAV heading angle decrease from not decrease to 300
controller 8 the current position of the UAV i.e. -300, 360 to 300 with an accuracy of and/or the accuracy
test and an altitude setpoint of 1000m. Run the 1.5. The Current airspeed scope exceeds 1.5. The
29 m/s
The purpose for the tests in this section were to test both the altitude controller as well as the heading controller. These were tested in tests 1-3 and tests
3-8 respectively. The parameters were set up as to cover all possible scenarios in terms of moving from the current state of the UAV to that set by the
setpoints.
DT Jordan 2008 6.6

Chapter 6: Results

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 latitude-
longitude 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
6.3.4 The operation of the UAV in different physical environments test setup and methodology
6.3.4.1 Test setup

Requirement 2.4.5.1 states that the autopilot should control the UAV for wind speeds up to and including 0.5m/s blowing from all possible directions. To
test this requirement, the following tests were performed. The initial UAV latitude, longitude and altitude setpoints were set to, -26.180, 27.998 and
1000m respectively- the GPS coordinates of the University of Johannesburg obtained from Google earth. For these tests the effects of the 13 wind input
matrix [WN WE WD ]T are tested between -0.5 m/s to 0.5 m/s. The effects of the WD directional wind will be tested on the altitude controller by having an
altitude setpoint of 1050m, while the latitude and longitude setpoints will be chosen that will result in a heading angle setpoint of 0. The effects of the WN
WE directional winds will be investigated on the latitude-longitude controller by having the latitude and longitude setpoints resulting on the heading angle
setpoint of 100, and the altitude setpoint will be set to 1000m. Since the accuracy requirements of the altitude controller were changed to 10m to be more
realistic, the modified requirements will apply to these tests.
Table 6-4: Process to test the response against different weather conditions
Setpoints/ Constants
Test Test Passing Test failing
Test Test Setup Long Alt
# Lat () Wind (m/s) requirements requirements
() (m)
Response 1 Set up the set point of the altitude controller 0 27.998 1050 [0 0 -0.5] The Current altitude Either the UAV
to to be 50m above the current position of the scope in Figure 5-28 does not reach
different UAV i.e. 1050m. The longitude and latitude should indicate the UAV the altitude
weather setpoints are chosen to result in a heading altitude increase to the setpoint and/or
conditions angle setpoint of 0. Run the Simulink file for setpoint with an the accuracy
1800s (1/2 hour) accuracy of 10m exceeds 10m
DT Jordan 2008 6.16

Chapter 6: Results
Response 6 Set up the set point of the altitude controller 0 27.998 1050 [0 0 0.1] The Current altitude Either the UAV
DT Jordan 2008 6.17

Chapter 6: Results
Response 11 Set up the set point of the altitude controller -31.18 56.354 1000 [-0.5 -0.5 0] The Current heading Either the UAV
to to be the same as the current position of the scope in Figure 5-28 does not reach
different UAV i.e. 1000m. The longitude and latitude should indicate the UAV the heading angle
weather setpoints are chosen to result in a heading heading angle increase setpoint and/or
conditions angle setpoint of 100. Run the Simulink file to the setpoint with an the accuracy
for 1800s (1/2 hour) accuracy of 1.5 exceeds 1.5
DT Jordan 2008 6.18

Chapter 6: Results
Response 16 Set up the set point of the altitude controller -31.18 56.354 1000 [0.1 0.1 0] The Current heading Either the UAV
DT Jordan 2008 6.19

Chapter 6: Results
For simplicity reasons, the test result obtained were documented in the form of a table. The results for the tests described in Table 6-4 are found in Table 6-
5. All aircraft are subjected to varying wind conditions while flying, and thus the effect of wind on the controllers performance has to be investigated. Even
large aircraft are not designed to operate in the most severe weather conditions possible, and thus there will be a limitation on the largest wind speed that
the aircraft can safely handle, and that the designed controller can withstand. The purpose of this test phase was to investigate the effect of wind blowing
from different directions on the UAV. The results obtained will hopefully lead to discovering which directional wind has the greatest effect on the UAV. For
this reason, it is important to note what the 13 wind input matrix represents, mainly [WN WE WD ]T in the units of m/s. During the Aerosonde UAV
transatlantic flight of 1998, the planners expected the UAV to encounter wind speeds up to 0.5 m/s, and thus the tests were designed to take into
consideration all values up to this range.
An altitude setpoint of 1050m was chosen, and the latitude and longitude setpoints were chosen that resulted in a heading angle setpoint of 0. These were
used for the first ten tests. This was chosen because the average UAV climb rate is the smallest when the altitude set point is higher than the current
altitude. Since the z-axis directional wind will have the greatest effect on the UAV in terms of the UAV climbing and descending capability, these will be
DT Jordan 2008 6.20

Chapter 6: Results
investigated under various WD 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 of 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 WD 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 # Scope/ Display Setpoint Oscillations Oscillation Oscillation Additional comments
reading used reached present max value min value
1 Current altitude scope 1055m 1054.7m
2 Current altitude scope 1055m 1054.7m
3 Current altitude scope 1054.95m 1054.65m
5 Current altitude scope X NA NA The altitude settles at 1054.5m
11 Current Heading scope 99.5 99.48
12 Current Heading scope X NA NA The heading angle settles at 99.5
DT Jordan 2008 6.21

Chapter 6: Results
Attention is now turned to the effects of the WN 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 controllers capability.
The robustness of the controller had to be tested. As a result the autopilots 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
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 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
operators 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 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 non-
equilibrium state. Three papers were found that are very similar to the scope of this project. This
included A Framework for Fuzzy Based 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 of 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, 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 can 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

http://people.bath.ac.uk/jw329/Advantages%20and%20Disadvantages.htm
[3] RC operating frequencies in SA

http://www.samaa.org.za/new_pages/frequencies.shtml
[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
[11] Missy Frederick,UAV use growing worldwide, Space News, 23 January 2006
http://www.space.com/spacenews/archive06/UAV_012306.html
[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
[15] 10 Key principles of agile software development

http://kw-agiledevelopment.blogspot.com/2007/02/10-things-you-need-to-know-about-
agile.html
[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/
[18] Wikipedia: MQ-1_Predator,

http://en.wikipedia.org/wiki/MQ-1_Predator
[19] Wikipedia: RQ-4_Global_Hawk

http://en.wikipedia.org/wiki/RQ-4_Global_Hawk
[20] Mathworks: Fuzzy Logic Toolbox, what is fuzzy logic

www.mathworks.com/access/helpdesk/help/toolbox/fuzzy/fp72.html
[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
[23] Suramya.com Technical Section: About Artifical Intelligence

http://tech.suramya.com/about_AI/
[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
[25] Civil Aviation Authority

http://www.caa.co.za/
[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
[27] The national institute of ethics (USA): Nine basic steps to personal ethical decision making,
http://www.niee.org/pd.cfm?pt=AECM
[28] IEEE code of ethics,

http://www.ieee.org/portal/pages/iportals/aboutus/ethics/code.htm
[29] The engineering council of South Africa code of professional conduct

http://www.ecsa.co.za/Legal/2CodeofConduct/2006/ECSACodeofConduct_17March2006.ht
m
[30] The ACM code of ethics and professional conduct

http://www.acm.org/about/code-of-ethics
[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-of-
flight.freeola.com/Aviation%20history/evolution%20of%20technology/autopilot.htm
Referenced on 2 April 2008
[33] Zhang Huaguang, Liu Derong, Fuzzy Modelling and Fuzzy Control, Birkhuser, Boston 2006
[34] Kovai 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] strm K, Hgglund T, PID controllers: theory, design and tuning 2nd 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 2nd 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
[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
[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
[49] Horstmann C, Computing Concepts with C++ Essentials 3rd Edition, John Wiley and Sons, New
Jersey 2003
[50] Wikepedia: C Sharp (programming language)

http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29
[51] Microsoft: Project DreamSpark

https://downloads.channel8.msdn.com
[52] Wikepedia: Dev-C++

http://en.wikipedia.org/wiki/Dev-C%2B%2B
[53] X-Plane: Laminar Research

http://www.x-plane.com/about.html
[54] X-Plane Plugin SDK Home Page

http://www.xsquawkbox.net/xpsdk/phpwiki/index.php?FrontPage
DT Jordan 2008 8.4

References
[55] Flight dynamics and control toolbox

http://home.wanadoo.nl/dutchroll/
[56] The Dutchroll Blockset for Simulink

http://home.wanadoo.nl/dutchroll/dubsi.html
[57] Fuzz-C
http://bytecraft.com/Fuzzy_Logic
[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
[61] Wikipedia: Microsoft Flight Simulator

http://en.wikipedia.org/wiki/Microsoft_Flight_Simulator
[62] FlouLib v 3.3

http://www.listic.univ-savoie.fr/modules.php?name=Content&pa=show&acronym=FlouLib
[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/
[68] The Aerosonde system

http://www.aerosonde.com/downloads/the_aerosonde_system.doc
[69] Atlantic crossing by Aerosonde

http://www.barnardmicrosystems.com/L4E_atlantic_crossing_I.htm
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]

ECSA OUTCOME LEVEL ASSESSED
1: Problem solving Problem solving skills are to be
demonstrated during execution of the
Learning outcome: project.
Demonstrate competence to identify, assess, formulate and solve
convergent and divergent engineering problems creatively and
innovatively
2: Application of scientific and engineering Application of scientific and engineering
knowledge knowledge are demonstrated by
application to the project.
Learning outcome:
Demonstrate competence to apply knowledge of mathematics,
basic science and engineering sciences from first principles to solve
engineering problems
3: Engineering Design Engineering design is demonstrated by the
design work required for the project.
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.
5: Engineering methods, skills and tools, The demonstration of engineering
including Information Technology methods is one of the cornerstones of the
course and is assessed during tests and
Learning outcome: project execution.
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.1 FUZZY REASONING
Traditional classical sets are defined as a collection of elements or objects 1 w which can be finite,
In order to understand fuzzy logic and fuzzy control, one has to first understand fuzzy sets.
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 end-
between the endpoint can represent the various degree of membership for an element 1 in some
point values 0 and 1 conform to no membership or full membership respectively. The values in
universe w.
The definition of fuzzy sets is now as follows [12]:
Definition Fuzzy sets: Given a collection of objects x a fuzzy set in x is defined as a set of
y`x, xa | x x{
ordered pairs
Where -| 1 is called the membership function for the set of all objects 1 in
x.
For the above definition, the symbol stands for defined as The membership function relates to
each 1 a membership grade -| 1, 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 `x, xa.
This is known as a fuzzy singleton.
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.
= - 1 = - 1
For all x
A fuzzy set is a subset of fuzzy set if is less than or equal to . i.e.
- 1 - 1
For all x
Other set operations include the fuzzy union, intersection and compliment.
The fuzzy union of and defined on the mutual universe x is:
y`x, xa | x x and x = max x, x{
An example of the union operator are presented in the Figure 10.2:
Figure 10-2: Union of two fuzzy sets A and B
The fuzzy intersection of and defined on the mutual universe x is:
y`x, xa | x x and x = min x, x{
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 defined on the mutual universe x is:
y`x, xa | 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.
A hedge takes a linguistic value and modifies its meaning. Consider a membership function x
that describes a young person. Hedges of this might include the following membership functions:
x = 4 x
x = x
@/4
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 1[
The simple Cartesian product of and is described by:
= y`x, ya | x , [ {
The fuzzy binary relation is defined as: Let and be fuzzy sets defined on and respectively.
Then the fuzzy sets in with the membership function
y`x, ya , x, y| x, y {
Is a binary fuzzy relation
The fuzzy Cartesian product is defined as: Let and be fuzzy sets defined on and
respectively. Then the fuzzy set in with the membership function
= y`x, ya , x, y | x , [ , x, y = min x, x{
Is the Cartesian product of and
There is also also have compositions of relations.
The fuzzy relational composition is defined as follows: Let and be two fuzzy relations defined on
and respectively. Then the fuzzy set in with the membership function:
= ``x, za, x, y y, za x , y , z

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

Appendix B
When dealing with fuzzy sets, the connective statements are similar to that of Boolean set theory.
The only difference is that the set values of the fuzzy sets might fall in the interval [0, 1].
An example comparison between a Boolean OR truth table and a fuzzy O truth table is given in the
left and right Figure 10.6 and Figure 10.7 respectively:
Figure 10-6: Fuzzy AND truth table Figure 10-7: Boolean AND truth table
The basic approach to interence is to reach some sort of conclusion taking into consideration the
facts and reasoning. In mathematical terms this might be:
[ ]
The above approach is typically referred to as if-then rules.
A backward approach to develop a fuzzy-system is given by Jantzen [12]. This approach consists of
the following steps:
1. Decide which laws (tautologies) are required
2. Define and, or, not, implication and equivalence
3. Check by means of a truth table whether the laws in step 1 hold
4. If not, return back to step 2
Consider the simple example of controlling an air conditioner:

If the room is warm, then set the cooling power to 500 watts
Set the cooling temperature to 500 watts

Current temperature is 21oC
DT Jordan 2008 10.5

Fuzzy Controller Autopilot For A Fixed Wing Unmanned Aerial Vehicle PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fuzzy Controller Autopilot For A Fixed Wing Unmanned Aerial Vehicle PDF

Uploaded by

Copyright:

Available Formats

FUZZY CONTROLLER AUTOPILOT FOR A FIXED WING

UNMANNED AERIAL VEHICLE

DOMINIC TIMOTHY JORDAN

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

ELECTRICAL AND ELECTRONIC ENGINEERING SCIENCE WITH

STUDY LEADER: MR FRANCOIS DU PLESSIS

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

Figure 3-43: Test case 1 ..................................................................................................................... 3.34

DT Jordan 2008 iii

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

LIST OF SYMBOLS AND ABBREVIATIONS

1 CHAPTER 1: PROBLEM STATEMENT

1.1 INTRODUCTION AND BACKGROUND

2. Research and development:

3. Civil and commercial uses:

5. Target and decoy:

DT Jordan 2008 1.1

Figure 1-1 Remote Controlled UAV

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

DT Jordan 2008 1.2

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

5. Scheduling and task allocation:

DT Jordan 2008 1.3

1.2 PROBLEM STATEMENT

DT Jordan 2008 1.4

1.3 THE PROJECT OBJECTIVE

1.4 SCOPE OF THE PROJECT

1.5 DESIGN METHODOLOGY TO BE FOLLOWED

Figure 1-4: Iterative development process [13]

DT Jordan 2008 1.5

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

For more information on the ECSA outcomes, please refer to Appendix A.

DT Jordan 2008 1.6

Delivery of second seminar Conference date to be TBA

1.7 OVERVIEW OF THE DOCUMENT

Figure 1-6: Design documentation framework [5]

DT Jordan 2008 1.7

DT Jordan 2008 1.8

DT Jordan 2008 1.9

2 CHAPTER 2: REQUIREMENTS ANALYSIS

2.2 IDENTIFIED ISSUES AND CONSTRAINTS

DT Jordan 2008 2.1

2.2.1.1 Availability of software libraries

2.2.1.2 Availability of simulation packages

Figure 2-1: Simulation environment

2.2.1.3 Accuracy of the controller

2.2.1.4 Processing speed

2.2.1.5 Availability of adequate suitable aircraft model

DT Jordan 2008 2.2

2.2.1.6 Availability of suitable flying conditions

2.2.1.7 Taking off and landing of the UAV

2.2.1.8 Load Shedding

2.2.1.9 Fuel availability

2.2.2 Financial and economic

DT Jordan 2008 2.3

2.2.6 Environmental impact

2.2.7 Ethical considerations

2.2.7.1 Facts behind the project

DT Jordan 2008 2.4

2.2.7.2 Stakeholders concerned

2.2.7.3 Motivations of the Stakeholders

2.2.7.4 Alternative solutions

2.2.7.5 Most ethical alternative solution

sampling time , the approximation becomes:

1 is a running point in the discrete universe

-1 ) is its membership value in the membership function