Abstract - This paper explores the building of a translational velocity fuzzy controller and a multi-modal altitude fuzzy controller within the Mamdani Matlab fuzzy logic controller designer, and using the X- intersect points of the membership functions of the input sets, the controllers are converted onto C++ adopting the weighted average deffuzification method. Ideal altitude and translational velocity controllers are proposed, then after consideration of such factors as coding the rule base, the controllers were changed to try and most accurately reflect that of the ideal ones using only 3 rules. Tests were then carried out to validate the working order of the controllers inputs and outputs whilst the drone was in flight and the results are discussed and evaluated in preparation for a machine learning algorithm to be implemented.

INTRODUCTION

In this project Generalised Probabilistic Fuzzy Multi-Objective Reinforcement Learning (GPFMORLPT) is used in an attempt to combine a fuzzy inference engine with probabilistic theory for the purpose of controlling an autonomous drone in its efforts to find the best possible route to a target whilst overcoming environmental obstacles. The drone is to be placed at differing starting points multiple times on a grid seeking the best path using a stochastic re-inforcement learning algorithm which will eventually converge to do so.In this report we will focus on the deterministic implementation of the fuzzy inference system specifically. Designed to control the attitude and translational velocity of the drone, are two separate mandami controllers created first through the Matlab fuzzy controller, then converted to C++ after evaluation of some defuzification techniques, and which of them would be most practical to use within this C++ framework. Here testing will be carried out through the use of the rule viewer of the Matlab fuzzy controller designer, and print f statements of C++ in conjunction with one another to inspect accuracy of the proposed defuzification method . The aim is to autonomously implement gradual, non-crisp changes in each controllers outputs dependent on the inputs of each controller, ensuring that small changes in a controllers inputs do not ever result in large changes in a controllers output in effect giving smooth control of the drones altitude and translational velocity with each controller being comprised of 2 inputs and 1 output.The objective is to allow the drone to be in a hovering state throughout the majority of its operation whilst ascending higher if the target appears near the edge of the grid to lessen possibility of losing the target. The drone should also decelerate when close to the ground or close to the target to

avoid damaging the drone and to allow for precise landings but accelerate the higher it goes or the further away from the target it is.

1. FUZZY LOGIC 1.1 Drone specifications

FIGURE 1.1: AR DRONE 2.0 ELITE EDITION

The Parrot AR.Drone 2.0 Elite Edition is a Wi-Fi controlled quadcopter. The battery is a 1000mAh lithium polymer with 12 minutes of flying time. The front facing camera is high definition (720p) with a 60 frames per second (FPS) refresh rate whilst the downward facing one operates at 30 FPS. Both cameras have the ability to record. The drone comes with an ultrasound sensor built in with an operating range of 6 meters with an accelerometer and a gyroscope.

1.2 Multi-Modal Fuzzy Altitude Controller Overview

The fuzzy logic controllers define the linguistic variables, construct membership functions and a rule base, take crisp inputs and create fuzzy values through fuzzification which interprets measurements of input variables. Viewable in figure 1.5, x1 and y1 and determine the degree to which these inputs belong to each of the appropriate fuzzy sets in this unrelated example.

Figure 1.5 Fuzzification of the input variables example (not related to the altitude controller designed by ourselves) Then an evaluation and combination of the results of each rule then finally converts the output back to crisp values, this process is known as defuzzification and is obtained by the

Optimized Multi model Fuzzy Altitude and Translational Velocity Controller for Artificially Intelligent Unmanned Aerial

Vehicle and testing within the C++ FrameworkA. Deepak, E. Ryan, & O. Abimbola

School of CSE, University of Salford, Manchester M5 4WT, UK

{D.Ajayakumar, B.Ogundipe, R.Edwards7}@edu.salford.ac.uk

inference process[12]. These steps are illustrated in figure 1.2, the multi modal fuzzy altitude controller. It enables smooth control of the drone’s altitude and maintains a hovering height while close to the target, gradually rising as the target is further away as to lessen the possibility of the drone becoming lost.The inputs for altitude control are Distance from the ground in centimeters and target area in pixels. The distance from ground is calculated by the Ultra-Sonic sensor, The target area is picked up through the image processing which has been pre-set to recognize green elsewhere in the program through the high dynamic range (HDR) camera which is best suited to perform this task due to being able to see many more shades of colour by having 12 or 14 bits of intensity information per channel compared to the 8 bits of a typical camera with the ability to significantly enhance ordinary images by bringing out detail in dark regions[1].

Figure 1.2: Multi Modal Fuzzy Altitude Controller Structure

1.3 Fuzzy Translational Velocity Controller Overview

The Translational Velocity Controller controls the drone’s translational velocity in x-axis and y-axis. The inputs for the velocity controller are Distance to ground, and distance to goal in pixels. The distance to goal is calculated by the distance formula given in equation 1 where x1 and y1 are at the centroid of the grid. The centroid of the target are x2 and y2.

Figure 1.3 Fuzzy Translational Velocity Controller Structure

Equation 1 - Distance formula

1.4 Mamdani method vs Sugeno method

The Mamdani inference technique is used for both multi model fuzzy altitude controller and the translational velocity controller. Mamdani's fuzzy inference method is the most commonly seen fuzzy methodology, it is intuitive and widely accepted. Madami was preferred over the Sugeno method as we preferred the output as a fuzzy set rather than a linear expression. It was deemed although more computationally demanding the mamdami would be the easiest to implement on the C++ framework while “min” is used in the Mamdani FISs for implication, the Sugeno FISs adopts “product” for implication[7]. The Sugeno system is an adaptive technique used when the need is to customize the membership functions to best model the data in mathematical analysis.

The Mamdani-style fuzzy inference process is performed in four steps:

1.Fuzzification of the input variables2.Rule evaluation (inference)3.Aggregation of the rule outputs (composition)4.Defuzzification

1.5 Fuzzy logic summary

Machines can only process Boolean data such as ‘1’ or ‘0’. In order for machines to process vague language input such as 'Somehow Low', the crisp input is converted to a linguistic variable with fuzzy components. Fuzzy logic deals with degrees of truth rather than absolute truths and is said to be a superset of Boolean logic[13], allowing machines to output in terms of a percentage rather than a ‘1’ or ‘0’.

The fuzzy process is crisp to fuzzy then back to crisp, the reason the crisp variable is needed to change to a fuzzy variable is that no absolute crisp variable exists in terms of the real world, for example the temperature could be said to be ‘high’ when infact it will always be measured in degrees and not simply ‘high’ or ‘low’[14].

2. FUZZY LOGIC CONTROLLERS DESIGN

2.1 Rule Shortening

Figure 2.3 - The 3D graph of the ideal altitude controller before shortening the rule to 3

Figure 2.4 - The 3D graph of the altitude controller after shortening the rules to 3

Figure2.2 - The 3D graph of the speed controller after shortening the rules to 3

Figure2-1 - The 3D graph of the ideal speed controller before shortening the rule to 3

Figure 2.5 – 3D graph showing Rejected Possibility when amending the speed controller to best match the ideal original

Figure 2.7 - The Antecedent and Asymmetric ‘distance to target’ input after shortening the rules to 3

Figure 2.6 – The Antecedent and symmetric ‘distance to ground’ input

Firstly we will discuss the rules. When creating the original fuzzy logic controllers, ideal controllers were created that used more than 3 rules in the beginning. The problem arose when converting into C++. Rule clashes were preventing us from creating more rules than there were membership functions of the outputs of each fuzzy logic controller. The problem was the μ’s variables were attributed to the output membership functions directly in the code, making us unable to set more than 3 as we had 3 membership functions on each controller. This meant compromising some of what we wanted the graphs to look like but we were able to use the OR function to correct the graphs taking them as close to the original ideal ones as we could, by implementing the OR function in the rule base we were able to more flexibly design the graphs. When programming the rules into the C++ the fuzzy OR statement was done by returning the max of two values and the fuzzy AND statement was done by returning the MIN of two values, satisfying Demorgans rule and proving useful for programming the rule base.

It should be noted that for the speed controller 3D graph, we preferred having a high speed when the drone was high up yet close to the target as seen in figure2, which should not happen unless there is such a case of manual interference with the drone, over having the drone move at high speeds when the drone was Low down (in height) and far away from the targets shown in figure 5, this choice of compromise arose as the ideal graph was not so easy to replicate using 3 rules and as a result figure 5 was rejected as a candidate for our amended speed controller in favour of figure 2.

2.2 Speed Controller Design

The first task was to identify the inputs, the speed controller was required to have 2 inputs, one would be ‘distance to target’ and the other would be ‘distance to ground’. ‘Distance to ground’ was measured by the downward facing ultrasonic sensor and had a range of 0-300 centimeters. ‘Distance to target’ was measured by firstly finding the centroid of the grid by dividing both totals of the X and Y pixels of the grid over 2. Then by using the straight line formula we were able to find the distance to the centroid at any given point in the grid. The range was taken to be 365.6 by calculating from the corner of the grid to the centroid which would be the furthest possible distance away.

When it came to designing the input set’s using the membership functions there were some general principles to

Figure 2.9 – Output of speed controller

Equation 2 - Weighted Average defuzification formula

Figure 2.8 – the ‘distance to target’ input before the shortening the rules to 3

follow. These being, each membership function overlapping with its nearest membership function only once resulting in a case where each input value will belong to no more than two fuzzy sets[8], and fuzzy sets should always sum to 1, meaning the point two membership functions intersect will always be 0.5 on the Y axis creating what is known as Antecedent Membership Functions which could be either asymmetric or symmetric[9].

The type of membership functions used were triangular and trapezoidal, which is true throughout this entire project. When using membership functions of this kind, as opposed to Gaussian, the graphs after defuzzification show more gradual changes, appearing smoother with less sharp peaks and troughs, which is what is required for both change in speed and altitude, allowing changes to happen more gradually, in accordance with the stipulation, that in no instance should a small change in the input create a large change in the output[11], excluding the case of the shoulders in a trapezoidal membership function[11].

As mentioned in chapter 2.1, the speed fuzzy controller underwent a redesign process to make the updated graph match more accurately with the ideal graph, during this, the ‘distance to target’ input was also redesigned. This was appropriate as the graph was showing a reading of zero for significant parts of the left hand side of the surface viewer graph when the rules were reduced to 3 whilst using the original ‘distance to target’ input seen in figure 8. This would have caused the translational velocity to cease before reaching the target and so the ideal ‘distance to target’ input was modified from figure 8 to figure 7. The original design in figure 8 was so that there would be only a gradual change in speed when far away but a slightly more sharp change in speed when arriving closer, achieved by the less steeply sloped membership functions when the far and veryFar membership functions intersect, and the move heavily steeped slopes when the near and far membership functions intersect.

The output for the Speed controller for which the range was required to be between minus two and two, was designed

around our defuzification method which was the weighted average. Weighted average defuzification requires each membership function to be symmetrical. The weighted average method was chosen over the more popular center of gravity method due to computational simplicity[10]. The center of gravity method requires performing integration in C++ would be demanding due to integrals not being readily available in the program. To execute the center of gravity method would require writing a lengthy formula to handle any integration which could be time consuming and likely difficulties arising during the parsing process. The weighted average method performs fuzzification by weighting each functions in the output by its respective maximum membership value[10].

2.3 Altitude Controller design

The inputs for the altitude controller were ‘target area’ and again ‘distance to ground’. The advantage of using this kind of multi-modal approach is the ability to have added precision over that of which just one input could give, increasing flexibility and providing an advantageous effect in that each input is acting as a failsafe to the other. If suddenly the lighting failed, presuming there was no other source of light, even with the added sensitivity to light the HVR colour recognition system provides you would most likely lose the target area input, but as the ultrasound would remain unaffected the drone would remain operational.

The amount of pixels in a single grid square was used as the range by multiplying pixels in Y by pixels in X and dividing the result by 25 as it was a 5x5 grid giving a range of 9111.

This approach allowed us to work in terms of percentages when deciding how much of the target should be in a single square before descending or ascending and the membership functions were designed accordingly. It was decided that between 20% and 57.5% of the target in a grid square would be sufficient for the drone to hover but this was an estimation and could be altered by reworking the membership functions after testing if required.

The distance to ground input for the altitude controller was designed differently to that of the speed controller, leaving a shouldered area in the center allowing for a hovering distance observable in figure 11, the objective here was to give a hovering range of approximately 30 centimeters at altitude equal to between 135 and 165 centimeters. Although, it is apparent, that by the slanted nature of the graph in figure 4, When compared to the flat part of the ideal graph in figure 3, by reducing the rules, the result may have the drone making constant slight alterations in altitude when hovering. This could be confirmed in testing, with our prediction being that the drone would appear to bob up and down slightly.

The output of the altitude controller has a required range of minus two to two and is identical in design to that of the speed controller.

3. DEFUZIFICATION

When selecting the defuzification method we used four criteria stated by Hellendoorn and Thomas [11] in which to measure the methods and decide upon one. These being continuity, Disambiguity, Plausibility and Computational simplicity. A defuzzification method should always result in a unique value with no ambiguity ruling out the Center of largest area technique. Computation simplicity was a huge factor for us due to the timeframe and ruled the Center of sum technique.

A popular one is the centroid technique. It finds the point where a vertical line would slice the aggregate set into two equal masses. Mathematically this center of gravity (COG) can be expressed as:

Equation 3- Centroid Of Gravity equation

The centroid defuzzification method finds a point representing the center of gravity of the aggregated fuzzy set A, on the interval [a, b] where center of area, x is the value of the linguistic variable, and a and b represent the range of the linguistic variable. Figure 3.1 illustrates the CoA defuzzification method.

Figure 3.1: CoA defuzzification method

Once again due to computational simplicity, the Centroid method looked at in equation 3 and figure 3.1 were rejected.

Eventually the weighted average method was chosen as it best met the criteria stated by Hellendoorn and Thomas [11].Rather than integrating across the two-dimensional function to find the centroid, you use the weighted average of a few data points. The Weighted Average can be mathematically represented as:

Equation 4 – Weighted Average Method

Figure 3.2: Weighted average method

Figure 2.10 – The amount the target area is filling a grid box in pixels, named the ‘Target Area Pixels’

Figure 2.11 – The ‘distance to ground’ input

4 TESTING AND VALIDATION OF THE CODE WITH COMPARISON OF C++ AND MATLAB

4.1 Membership functions used for fuzzification of inputs

Figure 4.1 Triangular/Trapezoidal membership function

For both fuzzy controllers the input membership functions used are triangular membership function and trapezoidal membership functions. The triangular membership function returns 0 when the input value is less than parameter a or grater then parameter c. And for inputs between a and c it returs a value in the range of 0 to 1. Equation 5 describes the triangular membership function mathematically

Equation 5 - Triangular membership function

The trapezoidal membership function returns 0 when the input value is less than parameter a or grater then parameter d. And for inputs between a and d it returs a value in the range of 0 to 1. The equation below describes the triangular membership function mathematically.

Equation 6 – Trapezoid membership function

Triangular membership function code in C++

float Trimf(float x, float a, float b, float c){

if (x <= a)return 0.0;

else if (x >= a && x <= b)return (float)((x - a) / (b - a));

else if (x >= b && x <= c)return (float)((c - x) / (c - b));

else return 0.0;}

Trapezoidal membership function code in C++

float Trapmf(float x, float a, float b, float c, float d){

float fx;if (x <= a)

fx = 0.0;else if (x >= a && x <= b)

fx = (float)((x - a) / (b - a));else if (x >= b && x <= c)

fx = 1;else if (x >= c && x <= d)

fx = (float)((d - x) / (d - c));else fx = 0.0;

return (float)fx;}

4.2 Fuzzy AND and OR operations

OR fuzzy operation

Our Fuzzy system made use of the classical fuzzy operation union:

AB(x) = max [A(x), B(x)]

Equation 7 – Fuzzy OR function

AND fuzzy operation

Our Fuzzy system made use of the classical fuzzy operation intersection:

AB(x) = min [A(x), B(x)]

Equation 8 – Fuzzy AND function

If a given fuzzy rule has multiple antecedents, the fuzzy operator (AND or OR) is used to obtain a single number that represents the result of the antecedent evaluation seen in figure 4.2.

Figure 4.2 - Mamdani inference Rule evaluation

4.1TESTING

It was important to make sure the code written in C++ was performing its defuzification in the correct manner. After all debugging and errors were corrected, A printf statement was used to test the weighted average formula , the same input variables were put into the C++ code as the Matlab fuzzy logic designer using its rule viewer as seen in figure 4.3 and 4.4. The values were matching accurately with an error of only around 1% shown in figure 4.4 and 4.5.

Figure 4.3 – Snippet of the C++ output variables for testing the fuzzy controllers

Figure 4.4 – Rule viewer in the Matlab fuzzy logic designer, with the variable inputs for testing the fuzzy controllers

Figure 4.5 – Results of the test showing that the C++ implementation was successful

A test was carried out to ensure the straight line formula had been implemented correctly again using printf statements, for this test the target was put in front of the camera at different positions on the grid, after some corrections to the way the formula was implemented on the C++, we were getting tangible values that were consistent of what we expected, there was a minor issue in that two on the 4 corners were not showing correct values that we were not able to rectify in time. We used fabs to ensure that a value would always remain positive in this part as an issue with the square rooting,

that must have had been applied elsewhere in the code, was rectified by removing the sqrt and adding fabs to stop the dip into minus values which should not have occurred in any case.

Figure 4.6– Near the centre the distance to goal was showing correct values

Figure 4.7 – Near the centre the distance to goal was showing correct values

Figure 4.8 – When the target was in the top right corner the distance to goal was correct

When the target was moved up and down and left to right the X distance and Y distance was changing correctly after rectification as originally there was an error due to incorrect inverting on the y axis, the solution of which can be seen in figure 4.9.

Figure 4.9 – A snippet of the code showing the solution to resolve the unwanted inversion of the y axis

The last test was checking the altitude was displaying and calculating correctly, for this the drone had to be in flight, when we put the green target underneath we also noticed that when viewing from the bottom camera portions of the target were not being detected, seen in figure 4.11. Some alteration would be needed from the HDR settings to increase sensitivity to green to correct this but the higher resolution front facing camera did not have these issues. From figure 4.10 we see the altitude displaying the correct value of 0.62 meters confirming this part was working.

Figure 4.10 – An image to show the altitude value displaying and calculating correctly

Figure 4.11 - An image to show the image detection detecting green not working efficiently

Figure 4.12 – A snippet of the weighted average formula highlighting the part that finds the centroid of the triangular

membership function

In this part of the weighted average formula highlighted in figure 4.12 the centroid of the membership function is being found, additionally we tested the rule that only symmetrical membership functions could be implemented in the weighted average method by putting some asymmetrical trapezoids and entering the formula to find the centroid of a trapezium in place of the centroid of a triangle formula and found that it was not possible as stated by Timothy J. Ross (Ross).

5 CONCLUSIONS

Using the fuzzy logic toolbox in Matlab and the C++ framework we were able to create a multimodal program for the drone using the weighted average method of defuzification. From various tests we were able to create a working program that successfully replicates the output values of the mamdani controllers with that coded in C++. We have implemented a system in where the farther away the drone is from the target the faster it will go and will begin to go higher when the distance to the target becomes large as to help prevent loss of visual contact of the target. The Multimodal aspect of this project provided flexibility when designing the inputs to be able to create a more precise altitude control, whilst giving the drone an element of safety given that each input is acting as a failsafe for the other.

ACKNOWLEDGMENTS

We would like to acknowledge Mr. John Pinder for the ongoing help in the project.

REFERENCES

[1] RAANAN FATTAL , DANI LISCHINSKI T ,MICHAEL WERMAN , (2002). GRADIENT DOMAIN HIGH DYNAMIC RANGE COMPRESSION

[2] Oscar Cordon, (2011) A historical review of evolutionary learning methods for Mamdani-type fuzzy rule-based systems: Designing interpretable genetic fuzzy systems : International Journal of Approximate Reasoning Volume 52 Issue 6, September, 2011 Pages 894-913  [3] Bellman, R. E. 1957b. Dynamic Programming. Princeton, NJ: Princeton

University Press.

[4] Bottou, L. (2010). Large-Scale Machine Learning with Stochastic Gradient Descent. In Proceedings of COMPSTAT'2010. Paris: Physica-Verlag HD. p177-186.

[5] E Lughofer, P Angelov, X Zhou (2007) - Fuzzy Systems Conference.

Available http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4295393

[6] S G Chern, CY Lee, CC Wang (2008) CPT-based liquefaction assessment by using fuzzy-neural network .Journal of Marine Science and Technology, Vol. 16, No. 2, pp. 139-148 (2008)Available: http://jmst.ntou.edu.tw/marine/16-2/139-148.pdf

[7] Yang Wang. (2014). A Comparison of Mamdani and Sugeno Fuzzy Inference Systems for Traffic Flow PredictionP14

[8] Qingqing Zhou, M. P. (n.d.). A Membership Function Selection Method for Fuzzy Neural Networks. 1.

[9] Langari, J. Y. (n.d.). Fuzzy Logic: Intelligence, control, and Information,. 19-23.

[10] Ross, T. J. (n.d.). Fuzzy Logic with Engineering Applications.

[11] Hellendoorn, H. and Thomas, C. (1993) Defuzzification in fuzzy controllers.

[12] A short fuzzy logic tutorial (2010) Available at-http://cs.bilkent.edu.tr/~zeynep/files/short_fuzzy_logic_tutorial.pdf

[13]Mike Watts, lecture 4 http://mike.watts.net.nz/Teaching/IIS/Lecture4.pdf

[14] Ying Bai and Dali Wang Fundamentals of Fuzzy Logic Control – Fuzzy Sets, Fuzzy Rules and Defuzzifications pg 17