ECE 4600 Group Design Project

Design of an Autonomous Flight Controller for anUnmanned Aerial Vehicle

byGroup 02

Bryan Drobot Curtis EinarsonStephanie English Kelly Riha

Final report submitted in partial satisfaction of the requirements for the degree of

Bachelor of Science in Electrical and Computer Engineering in the

Faculty of Engineering of the University of Manitoba

Academic Supervisor

Dr. Witold KinsnerDepartment of Electrical and Computer Engineering

University of Manitoba

Industry Supervisors

Dale George – BASI

Barry Prentice – BASI

Date of Submission

March 10, 2014

Copyright © 2014 Bryan Drobot, Curtis Einarson, Stephanie English, Kelly Riha

Design of an Autonomous Flight Controller

Abstract

Sending goods to Northern Canada is expensive due to the maintenance of roadways and

short travel windows; UAVs may be the solution to this problem. The project proposed

was to build and design an autonomous flight controller for a quadcopter. Four fuzzy

controllers were used to stabilize roll, pitch, yaw, and height. A communication centre

utilizes the ZigBee protocol to communicate between the ground station and the flight

controller to provide autonomous flight. A Master/Slave/Slave topology was facilitated to

incorporate a GPS, ZigBee module, altimeter sensor, and 3-axes gyroscope, accelerometer,

and magnetometer sensors. The GPS and ZigBee were both implemented on separate slaves

while the fuzzy controller and remaining sensors were located on the master.

The flight controller designed allowed for two controllers to be integrated with a com-

mand centre. The two controllers were implemented with a run time of 240 ms. Six

commands for communication were developed and implemented with an average run time

of 36 ms. The two fuzzy controllers and the command methods ran together successfully.

- i -

Design of an Autonomous Flight Controller

Contributions

Bry

anD

rob

ot

Cu

rtis

Ein

arso

n

Ste

ph

anie

En

glis

h

Kel

lyR

iha

Hardware

Microcontroller / Testing ◦ • ◦GPS / Testing •Altimeter / Testing • ◦ZigBee / Testing • ◦Sensor Stick / Testing • ◦

Simulations and Modelling

Controller Design • •Simulations • •

Communication Design

Communication Centre • •

Integration

Control Design • •Software Integration ◦ ◦ ◦ ◦Casing ◦ •

Legend: • Lead task ◦ Contributed

- ii -

Design of an Autonomous Flight Controller

Acknowledgements

The team would like to thank several people for their participation in this project:

� Thank you to our advisor, Dr. Witold Kinsner, for introducing us to this project and

allowing us to learn and grow under your guidance.

� Thank you to our industry sponsors, Barry Prentice and Dale George, for the on

site visits which allowed us to get a better appreciation for airships and lending us a

quadcopter for testing.

� Thank you to our class advisors, Behzad Kordi, Aiden Topping, and Dan Card for

helping with feedback and support.

� Thank you to the tech shop, Allan McKay and Sinisa Janjic, for always being available

to order and accumulate parts.

� Thank you to Mohamed Nasir and Rafi Belal for the support and aid provided.

- iii -

Design of an Autonomous Flight Controller TABLE OF CONTENTS

Table of Contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Hardware 4

2.1 Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Design Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 GPS Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Altimeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Altimeter Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Communication Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 ZigBee Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 3-axes Gyroscope, Accelerometer, Magnetometer . . . . . . . . . . . . . . . 14

2.5.1 Sensor Stick Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Simulations and Modelling 16

3.1 Controller Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Fuzzy Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

- iv -

Design of an Autonomous Flight Controller TABLE OF CONTENTS

3.3 Flight Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Controller Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Control System 27

4.1 Programming Arduino Uno . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Incorporation of Fuzzy Code with AHRS Files . . . . . . . . . . . . . . . . 28

4.3 Individual Tests for Roll, Pitch, Yaw, and Height . . . . . . . . . . . . . . . 30

4.3.1 Program Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.2 PWM Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4 Tests for Integrated Roll, Pitch, Yaw, and Height . . . . . . . . . . . . . . . 34

5 Communication Design 37

6 Integration and Building of the Flight Controller 39

6.1 Integration of Flight Controller . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2 Building of the Flight Controller . . . . . . . . . . . . . . . . . . . . . . . . 40

7 Integration Tests 43

8 Future Improvements 44

9 Conclusions 46

References 48

Appendix A Specifications 51

Appendix B Budget 52

Appendix C Pinout 54

Appendix D Flow Chart 56

Appendix E Software Code 63

Appendix F Curriculum Vitae 64

- v -

Design of an Autonomous Flight Controller LIST OF FIGURES

List of Figures

1.1 Quadcopter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Selected Arduino Uno microcontroller . . . . . . . . . . . . . . . . . . . . . 6

2.2 Selected Venus GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Selected Altimeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Selected XBee module incorporating ZigBee . . . . . . . . . . . . . . . . . . 12

2.5 Selected Sensor Stick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Fuzzy flow chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Quadcopter orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Membership function of desired angle . . . . . . . . . . . . . . . . . . . . . 22

3.4 Membership function of the output . . . . . . . . . . . . . . . . . . . . . . . 23

3.5 Step input response for pitch . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.6 Quadcopter orientation for ESCs . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Initial setup of Arduino Uno and Sensor Stick . . . . . . . . . . . . . . . . . 29

4.2 Roll control test with current angle = 0 ◦ . . . . . . . . . . . . . . . . . . . 30

4.3 Roll control test with current angle = 45 ◦ . . . . . . . . . . . . . . . . . . . 31

4.4 Roll control test with current angle = −45 ◦ . . . . . . . . . . . . . . . . . . 31

4.5 PWM test to four motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.6 PWM output to ESC1: current roll angle = 0 ◦ . . . . . . . . . . . . . . . . 33

4.7 PWM output to ESC1: current roll angle = 45 ◦ . . . . . . . . . . . . . . . 33

4.8 PWM output to ESC1: current roll angle = −45 ◦ . . . . . . . . . . . . . . 34

6.1 Polling sensors flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2 Initial test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.3 Final prototype setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

- vi -

Design of an Autonomous Flight Controller LIST OF FIGURES

C.1 Final version of flight controller pin out . . . . . . . . . . . . . . . . . . . . 55

D.1 Master routine flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

D.2 Slave ZigBee flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

D.3 Command centre flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

D.4 Slave GPS flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

D.5 Fuzzy routine flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

D.6 Fuzzy Controler flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

- vii -

Design of an Autonomous Flight Controller LIST OF TABLES

List of Tables

2.1 Microcontroller summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 GPS summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 GPS Coordinate comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Altimeter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Communication protocol summary . . . . . . . . . . . . . . . . . . . . . . . 12

2.6 Indoor BER at various distances . . . . . . . . . . . . . . . . . . . . . . . . 13

2.7 Indoor BER at various distances . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Rules table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1 Comparison of Arduino Uno and MATLAB outputs summary . . . . . . . . 28

4.2 Run time comparison of two output membership functions . . . . . . . . . . 36

5.1 Command summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

B.1 Team budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

- viii -

Design of an Autonomous Flight Controller LIST OF TABLES

Nomenclature

Symbol Description

AHRS Attitude and Heading Reference System.

BASI Buoyant Aircraft Systems International.

BER Byte Error Rate.

DoF Degrees of Freedom.

ESC Electronic Speed Controller.

GPIO General Purpose Input/Output.

I2C Inter-Integrated Circuit.

IDE Integrated Development Environment.

GPS Global Positioning System.

MPL MPL-3115A2 altimeter.

MPX MPX4115 altimeter.

NaN Not a Number.

NXP NXP LPC 1769 microcontroller.

PAN Personal Area Network.

PCB Printed Circuit Board.

PID Proportional-Integral-Derivative.

RTS Real Time System.

SPI Serial Peripheral Interface.

UART Universal Asynchronous Receiver/Transmitter.

UAV Unmanned Aerial Vehicle.

UMRR UMRR0Ax70x altimeter.

USB Universal Serial Bus.

VBN Visual Base Navigation.

Venus Venus GPS with SMA connector.

- ix -

Design of an Autonomous Flight Controller 1. Introduction

Chapter 1

Introduction

1.1 Motivation

Northern Canada is vast and contains numerous remote communities. The cost of food and

services in these locations is much higher than in the rest of Canada due to the expensive

transport. The expensive transport is caused by short travel windows due to climate and

weather and the high cost of road maintenance. With the roads needing to be constantly

maintained, it makes for dangerous driving conditions. Large UAVs may be a solution to

these issues, being able to provide affordable and reliable transport under almost all weather

conditions to remote locations.

UAVs are aircrafts that are unpiloted and remotely controlled by a ground station or

automated with a controlling computer system. These would be able to provide affordable

and reliable transport under almost all weather conditions to remote locations. UAVs will

be able to decrease transport and infrastructure costs, increase travel windows, and reduce

the environmental effects of constantly repaired roadways.

Quadcopters are a type of UAV similar to a helicopter but have four rotors that are

parallel to the ground, shown in Figure 1.1. The quadcopter is advantageous over the

- 1 -

Design of an Autonomous Flight Controller 1.2 Proposal

helicopter as it allows for more stability, lift, and maneuverability.

Fig. 1.1: Quadcopter

1.2 Proposal

The goal of this project is to design and build a flight controller for a quadcopter. This design

will incorporate a 3-axis accelerometer, gyroscope, and magnetometer sensors, altimeter

sensor, ZigBee modules, and GPS to aid in the control and flight of a quadcopter. The

information acquired by these sensors will be used for control and communication to allow

for stable automated flight.

A design solution was considered that was low cost, low power, user-friendly, and be

able to function in a RTS environment.

- 2 -

Design of an Autonomous Flight Controller 1.3 Specifications

1.3 Specifications

The project that was proposed will have the following requirements: it will be autonomous

and it will stabilize within half a second. Ground station requests will replace the handheld

device and stabilization will be done on board. These station requests will be lift-off, get

location, set location, and land. The specifications were updated and the reasoning is

contained in Appendix A.

- 3 -

Design of an Autonomous Flight Controller 2. Hardware

Chapter 2

Hardware

The following chapter will discuss several hardware parts considered and their individual

testing. The hardware parts include a microcontroller, GPS, altimeter, ZigBee, and 3-axes

gyroscope, magnetometer, and accelerometer sensors. Appendix A contains the breakdown

of the allocated budget for the hardware parts.

2.1 Microcontroller

The microcontroller was the first and most important hardware component to be selected

for the flight controller. The microcontroller acts as the brain of the system allowing it to

make decisions and aid in flight. The requirements for the microcontroller were that it had

to be well suited for RTS and have many GPIOs, a large memory, low purchasing cost,

and the ability to use various peripherals such as: I2C, UART or SPI controllers and PWM

controllers.

The team researched several options for microcontrollers such as APM 2, Arduino Uno,

iNemo, NXP, and Raspberry Pi. Table 2.1 outlines each microcontroller in detail. Each

microcontroller model offered various pros and cons. iNemo was considered the best option

with the ARM Cortex M3 core processor designed for RTS. Although, it was not chosen

- 4 -

Design of an Autonomous Flight Controller 2.1 Microcontroller

for two reasons: high cost and not readily available. The APM 2 was another option,

but ultimately was not selected as the price would take three quarters of the budget. The

Arduino Uno was another option the team considered but was not initially chosen due to the

small flash memory size and slower clock speed. The Raspberry Pi was another inexpensive

option with a fast clock but lacked GPIOs. The NXP was similar to the iNemo, having the

same core processor, but had no on board sensors. Although this option meant purchasing

other hardware sensors separately, it remained an inexpensive option. The team determined

that the NXP was the best fit for the project.

Table 2.1: Microcontroller summary

Microcontroller Clock Core Flash GPIOs Cost

APM 2 [1] 16 MHz Atmega 2560 256 kB 86 $300

Arduino Uno [2] 16 MHz Atmega 328 32 kB 15 $26

iNemo [3] 72 MHz ARM Cortex M3 512 kB 19 $250

NXP [4] 120 MHz ARM Cortex M3 512 kB 70 $30

Raspberry Pi [5] 700 MHz ARM 1176JZF-S Expandable (SD) 8 $50

Once the NXP microcontroller was received, testing began. The team began testing

simple programs to become acquainted with the microcontroller (e.g. causing an LED to

blink) before attempting to incorporate the I2C communication protocol. Unfortunately,

the team was unable to find or create an easy-to-use library with this microcontroller.

Therefore, the team felt it was necessary to move to an alternate microcontroller. However,

as team members were in possession of and had access to Arduino Unos they were instead

selected to aid in initial testing of the sensors.

2.1.1 Design Modifications

A design decision was made to change the microcontroller. Since the hardware sensors

purchased had been tested using the team member’s Arduino Unos, the decision to change

- 5 -

Design of an Autonomous Flight Controller 2.2 GPS

to this microcontroller was made in early January. The Arduino Uno had the slowest clock

of the microcontrollers considered and smaller flash memory, but had a very user-friendly

interface that made for more efficient development of the flight controller. Arduinos have

premade I2C and serial libraries that were uncomplicated to use and operated well when

testing the sensors. Since the Arduino Unos were readily available, no design time was lost

from this microcontroller change.

Fig. 2.1: Selected Arduino Uno microcontroller

By changing from the NXP to the Arduino Uno, as seen in Figure 2.1, this allowed the

team to make significant progress with the project due to the user-friendly IDE. The decision

to switch microcontrollers allowed for the team to work more efficiently and ultimately

complete the project in a timely manner.

2.2 GPS

Research was conducted in order to build background knowledge, enhance understanding

of how GPS works, and review components to consider in selecting a model. Several fea-

tures were considered when researching available GPS devices: size, update rate, power

required, number of channels, antenna, and time to acquire a signal. All of these features

- 6 -

Design of an Autonomous Flight Controller 2.2 GPS

are important in allowing the GPS to acquire a signal quickly and accurately.

After conducting research, the team had several GPS options. The options listed in

Table 2.2 were the Copernicus II, GS407, and Venus. Initially, the team selected the GS407

as it had the largest number of channels which would allow for the quickest option to obtain

a fix on satellites. Although the cost for the module was expensive, faster acquisition time

was more important. The Copernicus II was ruled out early on due to it requiring more

power, increased cost, and lower number of channels. The Venus GPS had only 14 channels,

but overall has similar features to the GS407. The team decided that in an ideal flying

environment having less channels would not hinder the UAV performance.

Table 2.2: GPS summary

Module Antenna Type Start Time Channels Cost Power Requirements

Copernicus II [6] External Cold: 38 sHot: 3 s

12 $75 3.3 V, 44 mA

GS407 [7] Helical Cold: 29 sHot: 1 s

50 $100 3.3 V, 75 mA

Venus [8] External Cold: 29 sHot: 1 s

14 $62 3.3 V, 28 mA

Upon ordering the GS407, it was discovered it was out-of-stock. Therefore, the team

decided to switch to the second option, the Venus GPS, which was readily available and

inexpensive. The GPS that was selected is seen in Figure 2.2.

2.2.1 GPS Testing

Once the GPS was received, the team immediately began to test its accuracy. Initially,

there were issues attempting to acquire a reading. The GPS was powering correctly, but

it could not get a fixed signal due to EM noise and interference. After taking the GPS to

an ideal flying environment a good signal was received. The ground station would be able

- 7 -

Design of an Autonomous Flight Controller 2.2 GPS

Fig. 2.2: Selected Venus GPS

to check before the UAV took flight that the GPS had aquired a valid signal. This allowed

the team to make sure the GPS was receiving correct initial coordinates.

Completion of the testing gave the team several useful pieces of information about the

chosen GPS. The dynamic range was the whole geographical coordinate system and the

sampling frequency 1 Hz. The accuracy of the GPS was found by comparing results from

the GPS to the actual coordinates of various points in Winnipeg. Table 2.3 shows the found

and the actual latitude and longitude at various locations in Winnipeg found at [9]. The

accuracy of the GPS was found to be within 5.3 m of the actual location which was better

than the worst case range of 7.8 m.

Table 2.3: GPS Coordinate comparison

Venus Latitude Actual Latitude Venus Longitude Actual Longitude Accuracy

4952.7145 N 4952.7119 N 09706.5713 W 09706.5749 W 6 m

4948.3020 N 4948.3050 N 09708.8340 W 09708.8300 W 7 m

4948.5211 N 4948.5227 N 09708.0763 W 09708.0758 W 3 m

- 8 -

Design of an Autonomous Flight Controller 2.3 Altimeter

2.3 Altimeter

An altimeter was needed to measure the altitude of the UAV. Several altimeters were com-

pared to determine one that would suit the flight controller’s requirements. The require-

ments for an altimeter were: pressure range, altitude range, altitude precision, sampling

frequency, and cost.

Different altimeters were compared to meet the requirements, MPL, MPX, and UMRR,

shown in Table 2.4. MPL was inexpensive, low power, and used I2C. The UMRR was wa-

terproof, which is ideal as the flying environment will be in all weather conditions. However,

the UMRR was not readily available. The MPX did not incorporate an altitude reading,

therefore was not considered as extra calculations were necessary to convert pressure to

altitude. The team decided on the MPL sensor, seen in Figure 2.3 for its I2C compatibility,

price, overall range, and accuracy.

Table 2.4: Altimeter summary

Module Altitude Range Altitude Precision Sampling Frequency Cost

MPL [10] <10668 m 0.1 m 400 kHz $18

MPX [11] <10668 m 0.1 m Not Listed $18

UMRR [12] <500 m 0.5 m 200 MHz No Price

2.3.1 Altimeter Testing

After receiving the altimeter the team conducted baseline testing using test code and an

Arduino Uno. Indoor and outdoor temperature tests were conducted to prove the altimeter

was working accordingly to specifications. A problem was discovered that an unsigned long

integer was read instead of a signed long integer. After altering the code, expected results of

either positive or negatives temperatures were properly displayed. The temperature sensor

worked well to over +40 ◦C and is accurate to ±1 ◦C.

- 9 -

Design of an Autonomous Flight Controller 2.3 Altimeter

Fig. 2.3: Selected Altimeter

After testing the temperature, testing of the pressure sensor began. An error arose every

time the test code was run as a slightly different reading for altitude was obtained. From

the testing it was determined the altimeter could successfully give the distance between

heights, but obtained incorrect values when reading the altitude above sea level.

Possible solutions for this inconsistency were to either add a height offset set at initial-

ization or to designate the liftoff spot as respective ground. The first solution was to add

a height offset to the height offset register to compensate for the difference in elevation.

However, this solution did not work; the height offset was not adding as expected. This led

to the second solution of designating the initial turn on altitude reading as zero and store

it in memory.

Incorporation of the altimeter to the entire system was simplistic, as communication

with the I2C bus consisted of read values from the MPL’s internal registers. The values

from the registers were manipulated as required to get the current altitude. The altimeter

was accurate to ±0.5 m with differences between heights, but was always off by varying

amounts with respect to sea level altitude.

- 10 -

Design of an Autonomous Flight Controller 2.4 Communication Module

2.4 Communication Module

To allow for a completely autonomous flight controller, the ability to communicate with the

quadcopter was needed. A communication module would allow a ground station to send

commands up to the quadcopter to be interpreted and handled in their specific function-

ality. Several different commands were needed to aid in autonomous flight such as set and

current destination, turn on/off motors, and set and current altitude. Many communication

peripherals exist and four were compared to best suit the needs of the quadcopter.

There are many different communication protocols and the project needed the best one

for its needs. Table 2.5 summarizes the key differences between various communication

technologies. Bluetooth, is a low power wireless standard developed for short distance

applications. Bluetooth offers comparable data rates to the other technologies, due to it

only allowing short distances, it was ruled out for use in the project. Wi-Fi was similar to

ZigBee and Bluetooth in its frequency band it used. Wi-Fi did allow for faster data rates

and larger bandwidth than these two protocols. The distance of Wi-Fi was the factor for

not using it in this project. ZigBee was another low power protocol that has two different

versions, Series One Pro and Series Two Pro.

There are many different communication protocols and the flight controller needed the

best one for its needs. Table 2.5 summarizes the key differences between various commu-

nication technologies. Bluetooth was ruled out since it was designed for short distances.

Wi-Fi allowed for faster data rates however, a short distance range was not ideal for the

quadcopter. Zigbee gave the quadcopter the greatest range but had a slower data rate. The

ZigBee allowed for the largest flight radius and this was deemed more important than a

data rate.

XBee is a communication module that implemented the ZigBee protocol and had two

options, Series One Pro and Series Two Pro. The team went with a Series One Pro instead

of the Series Two Pro since the Series Two Pro required initialization of the modules and

- 11 -

Design of an Autonomous Flight Controller 2.4 Communication Module

Table 2.5: Communication protocol summary

Type Frequency Band Data Rate Range Bandwidth Data Protection

Bluetooth[13] 2.4 GHz 1 Mb/s 10 m 1 MHz 16-bit CRC

Wi-Fi[13] 2.4 GHz 54 Mb/s 100 m 22 MHz 32-bit CRC

ZigBee[13] 2.4 GHz 250 Kb/s 10 - 1600 m 2 MHz 16-bit CRC

network. Series One Pro allowed a plug-and-play technology for implementation.

XBee came with free-to-use software called X-CTU that allowed a terminal to set up

and communicate between the XBee modules. This software allowed the team to manipu-

late the XBee modules to a specific functionality if needed. The purchased module is shown

in Figure 2.4.

Fig. 2.4: Selected XBee module incorporating ZigBee

2.4.1 ZigBee Testing

For initial testing, two XBee modules were utilized for communication: one module to be

incorporated into the flight controller, and the other module to be incorporated into the

ground station. Initially, packets were sent from one terminal to another to verify the

functionality of the XBee modules. The tests conducted were simple packet range tests

- 12 -

Design of an Autonomous Flight Controller 2.4 Communication Module

and distance tests to determine the BER in a noisy and non-noisy environment for overall

functionality.

In Table 2.6, a range test was conducted at increments of 25 m indoors. As distance

was increased the same packet and a confirmation were sent in reply. Up to 75 m indoors,

there was 100 % packet transmission and 0 % BER.

Table 2.6: Indoor BER at various distances

Distance Bytes Sent Bytes Received BER

0 m 30 30 0 %

25 m 30 30 0 %

50 m 30 30 0 %

75 m 30 30 0 %

After indoor tests were completed, the next step was to incorporate outdoor range tests

in a more ideal flying environment. From the Table 2.7, various distance tests were done at

several ranges. Initially, the results were not ideal because packet loss was rapidly increasing

with distance. At 100 m we had 0 % BER, at 250 m we lost 18.66 % BER of the packets

and at 500 m there was 100 % BER. This led to the discovery that the ZigBee antenna was

directional. Repeating this test, directing the antennas into line of sight at 500 m, a 100 %

of the packets were received and 0 % BER.

- 13 -

Design of an Autonomous Flight Controller 2.5 3-axes Gyroscope, Accelerometer, Magnetometer

Table 2.7: Indoor BER at various distances

Distance Bytes Sent Bytes Received BER

0 m 23 0 0 %

0 m 33 0 0 %

Average 0 %

100 m 25 0 0 %

100 m 25 0 0 %

Average 0 %

250 m 25 8 32 %

250 m 25 4 16 %

250 m 25 2 8 %

Average 18.66 %

500 m 25 24 96 %

500 m 25 25 100 %

500 m (Line of Sight) 25 0 0 %

Average 65.33 %

2.5 3-axes Gyroscope, Accelerometer, Magnetometer

The gyroscope, accelerometer and magnetometer were needed to aid the flight controller

in stability. The gyroscope was used to measure the rate of rotation around each axis,

the accelerometer measures acceleration around each axis, and the magnetometer measures

the magnetic field for each axis. These three combined will allow the flight controller to

calculate the roll, pitch, and yaw of the UAV. The requirements for this were to have at

least 9 degrees of freedom and no modularity.

The team researched the sensors to suit these requirements. Three sensor options were

compared: iNemo and APM2, with on-board sensors, and the 9 DoF Sensor Stick, with off-

board sensors. The 9 DoF Sensor Stick was found to have been used by various hobbyists

in similar projects. The team selected the 9 DoF - Sensor Stick, shown in Figure 2.5,

- 14 -

Design of an Autonomous Flight Controller 2.5 3-axes Gyroscope, Accelerometer, Magnetometer

which contained a gyroscope (ITG-3200), accelerometer (ADXL345), and a magnetometer

(HMC5883L). All three sensors had 3-axis of freedom allowing them to rotate around each

axis.

Fig. 2.5: Selected Sensor Stick

2.5.1 Sensor Stick Testing

Once the sensor stick was received, initial testing was done to check the accuracy. After

performing a 360 ◦ rotational test for the gyroscope about the z-axis, the results were un-

expected. The x-, y- and z-axes were affected by noise causing them to fluctuate. This

fluctuation was corrected with calibration and a sensor fusion algorithm. The algorithm

aided in the drifting of the gyroscope and accelerometer with time.

- 15 -

Design of an Autonomous Flight Controller 3. Simulations and Modelling

Chapter 3

Simulations and Modelling

Modelling and simulations were an important part in the development of the flight controller.

Mathematical modeling of flight dynamics is crucial to the derivation of the transfer func-

tions needed to complete the simulations. Simulations were performed to help the team

visualize how the quadcopter would react to different parameters of the controller being

changed and to verify that the control system worked.

In order to design and simulate the entire system, many processes needed to take place.

The first process was to research and choose an appropriate controller. Secondly, a general

knowledge of the mathematical modeling of flight dynamics was obtained to understand how

the transfer functions were derived. Thirdly, the controller was designed and implemented

with the transfer functions in Simulink. Lastly, open-loop, closed-loop and whole system

simulations were performed to verify the functionality of the designed control system.

3.1 Controller Research

In order to choose the controller for the system, various controllers were researched such as

PID, fractional PID, fuzzy, and Kalman filters. Various components needed to be taken into

consideration when selecting an appropriate controller for the system. These components

- 16 -

Design of an Autonomous Flight Controller 3.2 Fuzzy Control

included the linearity of the system, the mathematical complexity of the controller and

the physical constraints of controlling the quadcopter. A PID controller or a Kalman filter

could potentially be implemented. The quadcopter system is non-linear and both of these

control schemes are best suited for linearity. Fractional PID and variations of the Kalman

filter were designed for nonlinear systems. In order to account for non-linearity, fractional

calculus and other complex mathematics were required. Fuzzy can control a nonlinear

system using fuzzy logic and is based on a human interpretation of physically controlling

a system [14]. Since controlling the flight of a quadcopter is well-defined by human pilots

and this system is nonlinear, fuzzy was the most appropriate choice to implement.

3.2 Fuzzy Control

Fuzzy is a control system that is based on the human interpretation of a solution to a

control problem. The process of fuzzy control is represented by the block diagram modified

from, [15], in Figure 3.1. Initially, a crisp input variable from the quadcopter is converted

Fig. 3.1: Fuzzy flow chart

- 17 -

Design of an Autonomous Flight Controller 3.3 Flight Dynamics

to a fuzzy value through fuzzification. The fuzzification process is one of the biggest dif-

ferences of fuzzy control compared to other types of control. As opposed to correcting for

the difference between crisp input variables, fuzzy control uses a fuzzy value that occurs

anywhere in the range from 0 to 1 and determines the necessary change. Once the crisp

input is fuzzified, the fuzzy IF/THEN statements are invoked to determine the output that

represents the appropriate change. This output is then converted back to a crisp value

through defuzzification and fed back to the quadcopter to stabilize the motors.

3.3 Flight Dynamics

In order to perform closed-loop and system simulations, a mathematical model of the flight

dynamics for a quadcopter was needed. After extensive research it was determined that

the model was based on a rotational matrix describing the orientation of the quadcopter as

seen in Figure 3.2. The angles θ, φ, and ψ represent roll, pitch and yaw, respectively.

The rotational matrix R is given by:

R =( cosθcosψ cosψsinθsinφ−sinψcosφ cosψsinθcosφ+sinψsinφcosθsinψ sinψsinθsinφ+cosφcosψ sinψsinθcosψ−cosψsinψ−sinθ sinψcosθ cosψcosθ))

)(3.1)

After choosing an appropriate Euler rotation matrix, the equations of motion could be

developed using moment and force balance found in [16] and [17]:

x = u1(cosψsinθcosφ+ sinψsinφ) (3.2)

y = u1(sinψsinθcosφ− cosψsinφ) (3.3)

z = u1(cosθcosψ) − g (3.4)

- 18 -

Design of an Autonomous Flight Controller 3.3 Flight Dynamics

Fig. 3.2: Quadcopter orientation

ψ = u2 (3.5)

θ = u3 (3.6)

ψ = u4 (3.7)

Where u1, u2, u3, and u4 represent the forces acting on the quadcopter for total thrust,

roll, pitch, and yaw respectively:

u1 = (F1 + F2 + F3 + F4)/m (3.8)

- 19 -

Design of an Autonomous Flight Controller 3.4 Controller Design

u2 = L(F1 − F3)/J1 (3.9)

u3 = l(F2 − F4)/J2 (3.10)

u4 = C(F1 − F2 + F3 − F4)/J3 (3.11)

The forces created by each motor are represented by F1,F2, F3, and F4, seen in

Figure 3.2, l is the length of the frame from rotor to rotor, C is the force-to-moment scaling

factor and J1, J2, and J3 are the moments of inertia with respect to the axes. Mass

and gravity are m and g, respectively. It was important to gain a basic understanding of

modelling flight dynamics because the transfer functions needed for simulations are based

on these equations of motion.

3.4 Controller Design

The initial step in designing a fuzzy controller was to describe the guidelines of flight control

as viewed from a pilot’s perspective. These guidelines would provide the necessary informa-

tion required to start developing the controller. The first observation, from the guidelines in

[18], was that height difference of the roll, pitch and yaw axes could be controlled separately.

Since the parameters could be adjusted separately it was concluded four separate controllers

could be designed to make up our entire system. Next, the team needed to choose one of

the many types of fuzzy controllers to use. The intention to implement the control system

in MATLAB/Simulink limited the types to Mamdani or Sugeno controllers. Mamdani was

chosen because the control input is described more intuitively [14]. After selecting Mamdani

controllers, the required inputs for each controller needed to be determined. The guidelines

- 20 -

Design of an Autonomous Flight Controller 3.4 Controller Design

implied that desired angle and rate of angle change would be the inputs to the roll, pitch,

and yaw controllers, while desired height and height difference would be the inputs to the

height controller. The outputs of all the controllers represented the magnitudes of change

needed to stabilize each parameter respectively.

At this stage in the design of the fuzzy controllers, an abstract and intuitive feel for

the control system was established. Each parameter would correct itself to a desired angle

with regards to how fast it was changing and the outputs of the controllers would be used

collectively to stabilize the motors. The next step was to take the abstract intuition and

provide clear IF/THEN statements to describe exactly how the controller would react. For

example, if the desired pitch angle is positive and the rate of pitch angle change is positive,

then the output needs to “Go Up Much”. These rules were organized and expressed in

Table 3.1.

Table 3.1: Rules table

Rate of AngleChange

Desired Angle Positive Stand Negative

PositiveGo Up Much

(GUM)Go Up (GU) Stay(S)

Stand Go Up (GU) Stay (S) Go Down (GD)

Negative Stay (S) Go Down (GD)Go Down Much

(GDM)

Membership functions for each input and output then needed to be developed. An

important characteristic of membership functions is the bounds for which each function

extends. Developing and testing various input and output membership functions, how-

ever, takes several months and extensive experimental results. Due to timing constraints,

the input and output membership functions were taken and modified from [19] and [20],

respectively. Another important characteristic is the shape of the membership functions.

- 21 -

Design of an Autonomous Flight Controller 3.5 Simulations

Triangular was used because it is the most simple to implement in terms of computational

power and the results varied only slightly when a more complex shape was selected, e.g.

Gaussian. The desired angle input membership function, as seen in Figure 3.3, was modified

to have an input range from -2 to 2. The input range was changed because the input can

be manipulated from the hardware to be within that range.

Fig. 3.3: Membership function of desired angle

Another design modification was to use two inputs instead of three for each controller.

Two inputs were chosen because of the limited computational power and speed of the

microcontroller. It was decided not to modify the output membership function because of

timing constraints. The output membership functions are displayed in Figure 3.4. The input

and output membership functions were similarly designed for each controller. Once the rules

table and the membership functions for each controller were developed, the controllers were

implemented in Simulink.

3.5 Simulations

When the controllers were implemented in Simulink, open-loop simulations were first per-

formed to verify the controllers derived the correct outputs. These simulations were done to

- 22 -

Design of an Autonomous Flight Controller 3.5 Simulations

Fig. 3.4: Membership function of the output

prove the designed IF/THEN statements were correctly controlling the output for a given

set of inputs. As a result of these simulations, there was an expectation to see an output

that was distributed between a minimum of -20 and maximum of 20. These extremes would

occur when the inputs of desired angle and rate of angle change were simultaneously -2 or

2. The IF/THEN statements corresponding to these extreme cases were if desired angle

is positive and rate of angle change is positive then the output must ”Go Down Much”.

Similarly, If desired angle is negative and rate of angle change is negative then the output

must ”Go Up Much”. Using the Surface and Rules Viewer in MATLAB the expected results

were seen and verified that the controllers were individually deriving the correct outputs.

Once it was determined that the controllers derived the correct outputs, the next step

was to progress to closed-loop simulations. Simulations with feedback were important be-

cause it provided a realistic rate of angle change input. In order to produce this realistic

rate of change, transfer functions were need to model the flight dynamics of a quadcopter.

The controllers were simulated with various transfer functions found in literature [21] and

one was chosen that suited each controller best.

A simulated test for the pitch controller with a desired angle, step input of 1, was done

- 23 -

Design of an Autonomous Flight Controller 3.5 Simulations

to test the potential transfer functions. As a result of these simulations, the expectations

were to see an output that oscillated and settling at 1. It was found that a transfer function

that suited the pitch controller resulted in a response with an overshoot of 7.44% and a

settling time (5%) of 0.42 seconds. These results are shown in Figure 3.5, the dashed line

represents the step input and the solid line represents the response of the system. Then

the gain of the transfer function was changed to determine its gain range. When changing

the gain the expected results were to see an output that varied from slow rise time with

no overshoot to fast rise time with substantial overshoot. As the gain was changed the

expected results were outputted and confirmed our predictions. After finding the transfer

function that operated within a gain range, testing different desired angle inputs in the

range of -2 to 2 was started. The system was expected to remain stable and always settle

at the value of the input. The system remained stable but it started settling at different

values. This result was not expected. The transfer functions for the remaining controllers

were found the same way as pitch.

Fig. 3.5: Step input response for pitch

When appropriate transfer functions were found for each controller, the whole system

was designed and simulated. System simulations were important because they were needed

- 24 -

Design of an Autonomous Flight Controller 3.5 Simulations

to ensure the controllers would work together simultaneously to correctly control the motors

of the quadcopter. In order to complete the design of the system, the outputs of all four

controllers needed to be configured appropriately. To start configuring the outputs the

following coordinate system was chosen, as seen in Figure 3.6, in such a way that motors 2

and 4 were along the x-axis and motors 1 and 3 were along the y-axis.

Fig. 3.6: Quadcopter orientation for ESCs

With this orientation the pitch and roll rotations would only be affected by two motors

each, while the yaw and height movements would be affected by all motors. The output

of the roll controller was fed to ESCs 1 and 3, the output of the pitch controller to ESCs

2 and 4, and the outputs of the yaw and height controllers to all the ESCs. Once it was

known how the controller outputs affected each motor the outputs were summed and system

simulations were performed correctly. The ESC configurations follow the force summations

in equations Eq. 3.8 - Eq. 3.11. System simulations were started by just disturbing the pitch

controller with a desired angle input of 1. It was expected to see ESCs 1 and 4 to react

equally and opposite to each other while motors and 1 and 3 would remain constant. Many

- 25 -

Design of an Autonomous Flight Controller 3.5 Simulations

system simulations with disturbances to all controllers simultaneously were performed and

for each case the expected results were achieved. System simulations were completed and

verified that the designed control system would control the motors of the quadcopter.

Many types of controllers were researched, transfer functions were derived from the

mathematical model of flight dynamics, and an understanding of how the quadcopter would

react when the parameters of the controller were changed was gained. This understanding

would contribute to the tuning of the controller when physical experiments took place. Once

the system simulations were complete the team could progress to implementing and testing

the fuzzy controllers on the microcontroller.

- 26 -

Design of an Autonomous Flight Controller 4. Control System

Chapter 4

Control System

The designed fuzzy controller was implemented with the Arduino Uno and Sensor Stick.

Integration of the fuzzy controller code and AHRS files were done in order to perform

program tests. Individual and integrated tests were done to verify the controllers would

work individually and together.

4.1 Programming Arduino Uno

After simulations were complete, the team progressed to programming the Arduino Uno to

utilize the fuzzy controller. Research was done to determine how the team would convert the

MATLAB files over to Arduino C code. Arduino FIST: MATLAB Fuzzy Inference System

to Arduino C Converter [22] was used to transform the files correctly. Modifications were

done to make the code modular for future incorporation.

Initial tests were completed to make sure the code conversion was done without error.

Values were hard coded to represent the inputs of angle and rate of angle change. In

Table 4.1, the Arduino and MATLAB outputs are fairly similar. The difference between

the two outputs was accounted for by rounding errors. The last row of the table shows

beyond the limits of the membership functions test where the expected output should be

- 27 -

Design of an Autonomous Flight Controller 4.2 Incorporation of Fuzzy Code with AHRS Files

0.07. This row was outside the range of the membership functions and is not expected by

the system, resulting in a bigger error.

Table 4.1: Comparison of Arduino Uno and MATLAB outputs summary

Desired Angles Rate of Angle Change Arduino Output MATLAB Output % Diff.

2 0 -6.29 -6.22 1.13%

1 0 -4.98 -4.92 1.22%

0 0 0.07 0.075 6.67%

-1 0 5.58 5.57 0.16%

-2 0 6.76 6.76 0.00%

-3 3 0.09 0.075 20.0%

4.2 Incorporation of Fuzzy Code with AHRS Files

AHRS is a system which provides the actual orientation of the quadcopter in angles as

opposed to rates of angle change read by the Sensor Stick. From this point forward it was

decided that instead of comparing inputs angle and rate of angle change, the fuzzy controller

would compare the inputs desired angle and current angle for correction. Height was not

measured by desired and current angles, but by desired and current height. For all intents

and purpose, desired and current height will be referred to as desired and current angle.

The fuzzy Arduino files and AHRS files were incorporated together. The AHRS code

would act as the main loop and make calls to the fuzzy controller method. Since the

quadcopter should always be trying to stabilize, the fuzzy controller will always be called

after the new angles are calculated.

The sensitivity of the controller was to be determined first. For this initial test the

range of sensitivity for the controller were [-45, 45] for roll and pitch and [-180, 180] for

yaw. Since the input range of the fuzzy controller were [-2, 2] the Sensor Stick readings

needed to be changed to match the sensitivity range. The current roll and pitch angles were

- 28 -

Design of an Autonomous Flight Controller 4.2 Incorporation of Fuzzy Code with AHRS Files

divided by 22.5 and the current yaw angle was divided by 90. Yaw does not need to be as

sensitive because it should change to any direction or angle when a new GPS location is

set. For roll and pitch if the change expected is greater than ±45 ◦ the controller has to be

outputting the maximum for correction.

A preliminary setup was required for the fuzzy controller and the Sensor Stick for initial

testing, as shown Figure 4.1. This setup was used to determine if the fuzzy controller could

operate in the same program as the actual angles were being derived.

Fig. 4.1: Initial setup of Arduino Uno and Sensor Stick

Values for desired and current angles were hardcoded to zero with an expected output

of 0.07, shown in Table 4.1. However, the first problem with combining the two separate

codes became apparent. The issue was that the program would crash when it was part

way through the fuzzy controller method. To pinpoint exactly where the program would

crash, print statements were incrementally added to specific parts within the fuzzy controller

method for debugging purposes. After adding all the necessary print statements the program

ran successfully. It was clear now that the fuzzy controller method needed some extra time

to process some of its internal methods. With this information, all the print statements

were removed and delays of 1 ms were added in their place. Through further testing, delays

were removed to determine the minimum amount of delays to run successfully.

- 29 -

Design of an Autonomous Flight Controller 4.3 Individual Tests for Roll, Pitch, Yaw, and Height

4.3 Individual Tests for Roll, Pitch, Yaw, and Height

The setup in Figure 4.1 allows the fuzzy controller to read in actual angles read by the

Sensor Stick derived by the AHRS code. Roll, pitch, yaw, and height tests were initially

completed separately. The inputs to the fuzzy controller were desired angle and current

angle. All tests had fixed desired angles of zero. Roll and pitch tests were completed for

current angle measured at 0 ◦ and ±45 ◦. Yaw tests were done for current angle measured

at 0 ◦, ±90 ◦, and ±180 ◦. Height tests were done for initial height and ±5 m.

4.3.1 Program Tests

Figure 4.2, Figure 4.3, and Figure 4.4 shows the controller reacting with an expected angle of

0 ◦ and a current angle of 0 ◦ and ±45 ◦. With a positive measured angle it was expected for

ESC1 to increase and ESC3 to decrease to aid in stabilization and vice versa for a negative

measured angle. The outputs achieved were expected. The exact same test was done for

pitch and the expected results were achieved. It was observed it took approximately 360

ms for each call to the controller. With four controllers it would take 1.44 s to update the

quadcopter in flight, and this was unacceptably long. This was unacceptable because the

specification stated the reaction time must be less than half a second. However, the goal

was to integrate all the controllers together first and then reduce the computation time.

Fig. 4.2: Roll control test with current angle = 0 ◦

- 30 -

Design of an Autonomous Flight Controller 4.3 Individual Tests for Roll, Pitch, Yaw, and Height

Fig. 4.3: Roll control test with current angle = 45 ◦

Fig. 4.4: Roll control test with current angle = −45 ◦

Similar results were seen for yaw, all four ESCs were updated correctly. Yaw was

expected to behave like roll and pitch except that the sensitivity of the controller was

reacting within ±180 ◦, instead of ±45 ◦.

Tests for the height controller were conducted by changing and comparing the initial

base height read in and the current height it read. The results were expected as all ESCs

updated to correct for the height difference.

4.3.2 PWM Tests

After configuring the fuzzy controllers with the Arduino Uno, tests were done to determine

the correct pulses were being outputted to the motors. A current amplification setup, using

four BJTs and resistors found in [23], was used because the motors draw about 150 mA and

the Arduino Uno’s GPIOs only output 40 mA. Figure 4.5 displays the entire setup with the

Arduino Uno and four motors. The setup was to resemble the arrangement of an actual

quadcopter.

- 31 -

Design of an Autonomous Flight Controller 4.3 Individual Tests for Roll, Pitch, Yaw, and Height

Fig. 4.5: PWM test to four motors

For roll tests, the quadcopter orientation requires outputs to ESC3 and ESC1. These

results are shown in Figure 4.6, Figure 4.7, and Figure 4.8 from an oscilloscope by viewing

the pulse width modulation created by the Arduino Uno. For a positive measured angle

there was an increase in the width of the pulse to 1.720 ms compared to its resting pulse

width of 1.560 ms. For a negative measured angle there was a decrease in the pulse width to

1.400 ms. The same tests were done for the rest of the controllers and the expected results

were achieved.

- 32 -

Design of an Autonomous Flight Controller 4.3 Individual Tests for Roll, Pitch, Yaw, and Height

Fig. 4.6: PWM output to ESC1: current roll angle = 0 ◦

Fig. 4.7: PWM output to ESC1: current roll angle = 45 ◦

- 33 -

Design of an Autonomous Flight Controller 4.4 Tests for Integrated Roll, Pitch, Yaw, and Height

Fig. 4.8: PWM output to ESC1: current roll angle = −45 ◦

One issue that arose when testing roll was that the pulse period to be outputted to

ESC3 was half the amount of ESC1 for every test. It was discovered that pins 5 and 6 of

the Arduino Uno share the same timer with some other functions which causes the pins to

have a higher duty cycle. This issue was solved by moving the pins to other PWM output

pins. After this change the same period was observed.

4.4 Tests for Integrated Roll, Pitch, Yaw, and Height

After verifying the motors were receiving the correct outputs for different disturbances,

the next step was to integrate multiple controllers together. Roll and pitch were first run

together. This test was expected to run properly, since each controller outputs to their own

set of ESCs. The time allocated to call each controller became an issue when two controllers

were run together because the program would crash within a few iterations. The program

crashed because the Sensor Stick was reading extremely inconsistent values. Instead of

showing 0, when the Sensor Stick was flat, it would show a range of new calculated values,

as if the sensor stick was oscillating in movement. To prove that it was not the fuzzy code,

- 34 -

Design of an Autonomous Flight Controller 4.4 Tests for Integrated Roll, Pitch, Yaw, and Height

a delay of 360 ms was added in its place and the same issue occurred. It was concluded

that one or more of the libraries in the AHRS files was time dependent.

One solution was to modify the time dependent variables in the AHRS files. Only one

variable, G Dt, was found that affected the timing of the Sensor Stick. When G Dt was

decreased, the output of the Sensor Stick changed too quickly which caused the results to

become less accurate. Although, when G Dt was increased, the output would have more

accurate axis readings, but have a slower reaction time. By doubling G Dt, the roll, pitch,

and yaw readings became more consistent without sacrificing too much reaction time. Now

roll and pitch were able to function together with a run time of 720 ms. However, when

three controllers were run together changing G Dt was not sufficient because the program

would not run.

Another way to correct for this timing issue was to modify the original fuzzy controller in

MATLAB. Consequently, modifications were made to the original fuzzy controller to only

utilize three output membership functions instead of five. Decreasing the output mem-

bership functions was decided upon because in terms of computation, every membership

function needs time to compute. Three was the absolute minimum number of member-

ship functions. The two outlying membership functions were removed and the range was

decreased from [-20, 20] to [-12, 12] and the IF/THEN statements were updated. After

testing the reduced controller, the runtime was cut down to 140 ms from 360 ms. These

results are seen in Table 4.2. Although reducing membership functions decreases the ac-

curacy of stabilization, the main priority was to reduce the run time to integrate all four

controllers. Even with using the fuzzy controller with three output membership functions,

three controllers would not run.

- 35 -

Design of an Autonomous Flight Controller 4.4 Tests for Integrated Roll, Pitch, Yaw, and Height

Table 4.2: Run time comparison of two output membership functions

Number of OutputMembership functions

Run Time One Controller Run Time Two Controllers

3 140 ms 280 ms

5 360 ms 720 ms

Many design decisions and tests were implemented and completed. Individual controller

tests for roll, pitch, yaw, and height were successful. However, timing was a predominant

issue and required altering the AHRS code and redesigning the fuzzy controllers. Two

controllers were successfully run together; however three would not work.

- 36 -

Design of an Autonomous Flight Controller 5. Communication Design

Chapter 5

Communication Design

The next step of creating an autonomous UAV was the incorporation of commands into

the system. These commands were used to relay any necessary information that the UAV

needed for flight.

The commands needed to be short and easily differentiable to the flight controller.

Characters were chosen as the first part of the command; several characters would have

different meanings. After the end of message character was typed, the XBee would then

hold the information until requested from the master. The command centre would take

the command sent and distribute it to the proper method. After receiving a command, the

microcontroller had to decipher which commands were sent and act accordingly. This made

the communication code more efficient and saved memory that was limited on the master.

Table 5.1 lists the commands created with their average running times. The four main

commands for setting or changing data, A, D, H, and W, were in the range of 18 to 22 ms.

The start motors command, S, took approximately 22 s to run. This command was slower

because the motors are initially not moving and must be increased in intervals. The turn

off motors command, O, was slower than most of the commands because it must slow the

motors down in intervals.

- 37 -

Design of an Autonomous Flight Controller

Table 5.1: Command summary

Command Definition Time to Execute

A Set altitude / Fly at a certain altitude 18 ms

D Set destination / Go to coordinates 19 ms

H What is my altitude? / Return current altitude 22 ms

O Turn off motors 99 ms

S Start motors 22.54 s

W Where am I? / Return current coordinates 18 ms

- 38 -

Design of an Autonomous Flight Controller 6. Integration and Building of the Flight Controller

Chapter 6

Integration and Building of the

Flight Controller

The final design led to a Master/Slave/Slave architecture for the flight controller. Several

different designed were implemented and revised throughout the building phase. Appendix

C contains the final designed pinout.

6.1 Integration of Flight Controller

The hardware design was to use one Arduino Uno to interface with all the sensors. Baseline

testing of the individual sensors was completed successfully. The altimeter and the Sensor

Stick were integrated on the Arduino Uno successfully utilizing the I2C bus. The integration

allowed polling of each sensor. However, when incorporating the GPS and ZigBee a problem

occurred. The problem was that the GPS and ZigBee modules both required a serial

port and the Arduino Uno only had one available. Subsequently, a Master/Slave topology

combining two Arduino Unos was implemented that allowed the use of two serial ports.

The GPS was incorporated with the slave Arduino Uno and the ZigBee incorporated

on the master Arduino Uno. The GPS was incorporated on the slave because it needed to

- 39 -

Design of an Autonomous Flight Controller 6.2 Building of the Flight Controller

be constantly polled by the fuzzy routines for updated coordinates. The GPS information

was read in on the slaves serial port and saved in a buffer waiting for the request from

the master on the I2C. However, even though the master was receiving commands from

the ground station the master would only receive partial commands. This was due to the

ZigBee being polled halfway through a command population. Adding in a delay to wait

for the ZigBee buffer to fill was an option, however, it was not considered because of the

long run time of the fuzzy controllers. Consequently, this led to the final topology of a

Master/Slave/Slave. The ZigBee was incorporated on its own slave similarly to the GPS

slave.

Three Arduino Unos were required for the Master/Slave/Slave topology. The ZigBee

and GPS were connected to their own Arduino Uno. The master polls the slaves every

loop, as Figure 6.1 shows. A command centre was then created to help the automaticity

of the system. The flow charts for the entire Master/Slave/Slave topology are contained in

Appendix D.

Fig. 6.1: Polling sensors flowchart

6.2 Building of the Flight Controller

Three Arduino Unos and four external sensors were incorporated together into one compact

flight controller by altering the initial layout. Stacking of the Arduino Unos was done to save

space. To alleviate vibrations caused in flight, the stacked Arduino Unos were separated

by ear plugs for the intent to absorb some vibrations. The GPS and ZigBee were placed

- 40 -

Design of an Autonomous Flight Controller 6.2 Building of the Flight Controller

at opposite ends of the breadboard to minimize electromagnetic interference. The GPS

antenna was placed at the highest point to acquire clearest signal. The Sensor Stick was

placed close to the origin to be a proper representation of axes. The minimum amount of

wires were used by sharing buses when possible to save space. As seen in Figure 6.2 and

Figure 6.3, initial and final setups are shown of the flight controller.

Fig. 6.2: Initial test setup

- 41 -

Design of an Autonomous Flight Controller 6.2 Building of the Flight Controller

Fig. 6.3: Final prototype setup

- 42 -

Design of an Autonomous Flight Controller 7. Integration Tests

Chapter 7

Integration Tests

Final integration tests included the fuzzy control, communication, and hardware compo-

nents combined together. From the Master/Slave/Slave design, the master had the fuzzy

controller, AHRS code, and the polling methods. The goal was to make sure that both

control and polling methods could be run in the same main loop. For debugging purposes,

the polling methods were incrementally added to the AHRS main loop. The entire program

was combined successfully and Appendix E contains the software code. This program had

a run time of 280 ms for the two controllers, roll and pitch, plus 36 ms for the average

command and data polling.

The next experimental setup was to connect the prototype to the actual quadcopter.

This was done to reaffirm the initial tests that were done separately. The results were

as expected; the two controllers adjusted the motors correctly while reading and sending

commands.

- 43 -

Design of an Autonomous Flight Controller 8. Future Improvements

Chapter 8

Future Improvements

There are several improvements to the project that could be completed in the future. Some

improvements are required to allow the quadcopter to fly and other will upgrade and advance

the current features.

One improvement would be to replace the current microcontrollers with one that has a

faster clock and uses a multiple core system. This change would allow the system to handle

all four controllers running simultaneously and allow for quicker reaction time.

When the flight controller works as a unit, another improvement to the overall system

would be to refine the command centre. Instead of polling commands from the slave Arduino

Unos interrupt methods should be utilized to save valuable clock cycles. Also, include safe

guard commands to check and determine if the user requested an appropriate command

that would not lead to an error.

Other features that could be upgraded include: allow multiple temperature sensors to

monitor hardware sensors, create a PCB to minimize wires, design a shock absorbing casing

to minimize vibrations during flight, and include a waterproof casing to allow for flight in

all environments.

The project can be expanded to predictive control that uses object avoidance. This

- 44 -

Design of an Autonomous Flight Controller

system would become fully autonomous using VBN for object avoidance. VBN uses a

graphical interface unit to help solve and locate non-linear objects, such as tree lines and

buildings.

The benefits of having these improvements would allow the flight controller to become

practical and usable in a real world environment.

- 45 -

Design of an Autonomous Flight Controller 9. Conclusions

Chapter 9

Conclusions

The purpose of this project was to design and implement an autonomous flight controller

for a UAV. Hardware components were individually researched and selected based on com-

ponent specific requirements. Each component went through baseline testing to verify its

functionality and accuracy. Many types of control systems were researched and fuzzy was

chosen to be implemented. Software simulations of fuzzy control were completed to deter-

mine performance characteristics of ideal flight conditions and gain an intuitive knowledge

of flight dynamics. After hardware selection and simulations were completed, control, and

communication design and testing took place.

As the controller was being designed, timing was discovered to be an issue. Although

timing was reduced to 140 ms for each controller, only two controllers would function

together.

A command centre was designed with automaticity in mind to replace a handheld

remote. A Master/Slave/Slave topology was implemented because of the inability to use

ZigBee, GPS, and fuzzy control on the same microcontroller due to the lack of serial ports

and memory.

Communication and control code were combined with the hardware components to

- 46 -

Design of an Autonomous Flight Controller

make up the autonomous flight controller. More tests were conducted to ensure that both

communication and control collectively worked together. These tests verified that two fuzzy

controllers and the command center worked hand-in-hand.

With the future improvements to the project, the idea of sending goods and services to

Northern Canada with UAVs is tangible.

- 47 -

Design of an Autonomous Flight Controller REFERENCES

References

[1] B. Bonney. (2013, May) The apm 2 board. Arducopter. [Access date: August 15,2013]. [Online]. Available: http://code.google.com/p/arducopter/wiki/APM2board

[2] Arduino. (2013) Arduino uno. [Access date: May 23, 2013]. [Online]. Available:http://arduino.cc/en/Main/arduinoBoardUno#.Uv-0P7StZxg

[3] STMicroelectronics. (2010, February) inemo: inertial module v2 demonstrationboard based on mems sensor and the stm32f103re. [Access date: June 13,2013]. [Online]. Available: http://www.st.com/web/en/resource/technical/document/data brief/CD00264767.pdf

[4] N. Semiconductor. (2014, January) Lpc1769/68/67/66/65/64/63. [Access date:June 15, 2014]. [Online]. Available: http://www.nxp.com/documents/data sheet/LPC1769 68 67 66 65 64 63.pdf

[5] B. Corporation. (2012) Bcm2835 arm peripherals. [Access date: June 15,2013]. [Online]. Available: http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

[6] Trimble. (2009, September) Copernicus ii gps receiver. [Access date: September 30,2013]. [Online]. Available: http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/GPS/63530-10 Rev-B Manual Copernicus-II.pdf

[7] S. E. C. Ltd. Spk-sheet-gs407a. [Access date: November 1, 2013]. [Online]. Available:http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/GPS/SPK-GS407A.pdf

[8] S. T. Inc. (2011, January) Venus638flpx gps receiver data sheet. [Access date:September 18, 2013]. [Online]. Available: http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/GPS/Venus/638/doc/Venus638FLPx DS v07.pdf

[9] D. B. Zwiefelhofer. (2014) Find latitude and longitude. [Access date: December 19,2013]. [Online]. Available: www.findlatitudeandlongitude.com

[10] F. Semiconductor. (2012, July) I2c precision altimeter. [Access date: September 29,2013]. [Online]. Available: http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Pressure/MPL3115A2.pdf

- 48 -

Design of an Autonomous Flight Controller REFERENCES

[11] ——. (2006, July) Integrated silicon pressure sensor altimeter/barometer pressuresensor on-chip signal conditioned, temperature compensated and calibrated. [Accessdate: September 29, 2013]. [Online]. Available: http://www.freescale.com/files/sensors/doc/data sheet/MPX4115.pdf

[12] Smartmicro. (2011, July) Micro radar altimeter data sheet.[Access date: September 28, 2013]. [Online]. Avail-able: http://www.robotsinsearch.com.au/sites/default/files/literature/Micro%20RADAR%20Altimeter%20Datasheet/Micro Radar Altimeter Data Sheet.pdf

[13] J. Lee, Y. Su, and C. Shen, “A comparative study of wireless protocols:bluetooth, uwb, zigbee, and wi-fi,” in in Proc. 33rd Annual Conference of theIEEE Industrial Electronics Society, November 2007, pp. 46–51, [Access date:November 1, 2013]. [Online]. Available: http://eee.guc.edu.eg/Announcements/Comparaitive Wireless Standards.pdf

[14] A. Kaur and A. Kaur, “Comparison of mamdani-type and sugeno-type fuzzyinterface for air conditioning system,” International Journal of Soft Computing andEngineering, vol. 2 (2), pp. 323–325, May 2012, [Access date: September 15, 2013].[Online]. Available: http://www.ijsce.org/attachments/File/v2i2/B0612042212.pdf

[15] P. Shahmaleki, M. Mahzoon, A. Kazemi, and M. Basiri, Vision-Based HierarchicalFuzzy Controller and Real Time Results for a Wheeled Autonomous Robot, MotionControl, M. Control, Ed. InTech, 2010, [Access date: October 2, 2013]. [Online].Available: http://cdn.intechopen.com/pdfs/6578/InTech-Vision based hierarchicalfuzzy controller and real time results for a wheeled autonomous robot.pdf

[16] E. Altug, J. Ostrowski, and R. Mahony, “Control of a quadrotor helicopter usingvisual feedback,” in 2002 IEEE International Conference on Robotics and Automation,Washington, DC, May 2002, pp. 72–77, [Access date: October 15, 2013]. [Online].Available: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1013341&tag=1

[17] S. Al-Hiddabi, “Quadrotor control using feedback linearization with dynamicextension,” in 6th International Symposium on Mechatronics and its Applications,Sharjah, UAE, March 2009, pp. 1–3, [Access date: October 15, 2013]. [Online].Available: http://ieeexplore.ieee.org/xpls/abs all.jsp?arnumber=5164788

[18] D. Abeywardena, L. Amaratugna, S. Amaratugna, S. Shakoor, and A. Munasinghe,“A velocity feedback fuzzy logic controller for stable hovering of a quad rotoruav,” in 2009 International Conference on Industrial and Information Systems,Sri Lanka,, December 2009, pp. 558–562, [Access date: September 15, 2013].[Online]. Available: http://ieeexplore.ieee.org.proxy1.lib.umanitoba.ca/stamp/stamp.jsp?tp=&arnumber=5429800

- 49 -

Design of an Autonomous Flight Controller REFERENCES

[19] M. Olivares-Mendez, P. Campoy, and I. Mellando-Bataller, “See-and-avoid quadcopterusing fuzzy control optimized by cross-entopy,” in 2012 IEEE International Conferenceon Fuzzy Systems, Brisbane, QLP, June 2012, pp. 1–7, [Access date: October 14,2013]. [Online]. Available: http://ieeexplore.ieee.org.proxy1.lib.umanitoba.ca/stamp/stamp.jsp?tp=&arnumber=6251179

[20] M. Santos and V. Lopez., “Intelligent fuzzy controller of a quadrotor,” in2010 International Conference on Intelligent Systems and Knowledge Engineering,Hangzhou, November 2010, pp. 141–146, [Access date: October 14, 2013]. [Online].Available: http://ieeexplore.ieee.org.proxy1.lib.umanitoba.ca/stamp/stamp.jsp?tp=&arnumber=5680812

[21] S. Fernandes, “Guidance and trajectory following of an autonomous vision-guidedmicro quadrotor,” M.S. Thesis, Aero. Eng., IST, Lisbon, Portugal, 2011, [Accessdate: November 2, 2013]. [Online]. Available: https://dspace.ist.utl.pt/bitstream/2295/904712/1/SFernandes dissertacao.pdf

[22] MakeProto. (2012) Arduino fist. [Access date: January 3, 2014]. [Online]. Available:http://www.makeproto.com/projects/fuzzy/matlab arduino FIST/index.php

[23] K. Peters. Bit-101, simple arduino motor control. [Access date: January 8, 2014].[Online]. Available: http://www.bit-101.com/blog/?p=3831

- 50 -

Design of an Autonomous Flight Controller A. Specifications

Appendix A

Specifications

The team modified the specifications because they were not well defined in the proposal. The

initial specifications did not have any metrics or measurable goals that could be obtained.

The specifications needed to be rewritten to have measurable performance goals that were

well defined.

- 51 -

Design of an Autonomous Flight Controller B. Budget

Appendix B

Budget

The final team budget for purchases related to the flight controller is in Table B.1. The

column for cost includes taxes and any shipping and handling fees for the item. From the

ECE Department’s alloted budget of $400, the team spent $339.30.

- 52 -

Design of an Autonomous Flight Controller

Table B.1: Team budget

Item Quantity Cost Supplier

Altimeter

MPL3115A2 1 $ 15.63 ECE Department

GPS

Antenna GPS embedded SMA 1 $ 11.95 Team

Venus GPS with SMA 1 $ 69.35 ECE Department

GPS Breakout 1 $ 2.95 ECE Department

Microcontroller

Arduino Uno 3 $ 78.72 Team

NXP LPC 1769 1 $ 39.95 ECE Department

Quadcopter

Red 1 — BASI

Sensors

9 DoF - Sensor Stick 1 $ 105.21 ECE Department

Transceiver

XBee Series 1 Pro 2 $ 72.14 ECE Department

USB Adapter 1 $ 28.17 ECE Department

XBee Breakout 1 $ 5.90 ECE Department

2 mm 10 pin XBee Socket 4 $ 4.00 Team

Various Components

12VDC High-Speed Motor 4 $ 23.96 Team

Resistors 4 — Tech. Shop

2N2222 NPN 4 — Tech. Shop

ECE Department Cost $ 339.30

Team Cost $ 118.63

Total Cost $ 457.93

- 53 -

Design of an Autonomous Flight Controller C. Pinout

Appendix C

Pinout

The Figure C.1 shows the final pinout for the finished flight controller.

- 54 -

Design of an Autonomous Flight Controller

Fig. C.1: Final version of flight controller pin out

- 55 -

Design of an Autonomous Flight Controller D. Flow Chart

Appendix D

Flow Chart

Appendix D contains the entire flow chart for the flight controller. Figure D.1 shows the

master routine. The master starts with system initialization to turn on and calibrate the

sensors before getting into the main loop. The main loop starts by checking for a new

command from the ZigBee slave in Figure D.2. New commands are dealt with in the

command centre in Figure D.3. Current GPS coordinates are then asked for from the GPS

slave in Figure D.4. These coordinates are saved for future use by the fuzzy control. The

current altitude is then acquired and saved from the altimeter on the I2C bus.

After getting the new coordinates and altitude the flight controller enters the fuzzy

control routine, Figure D.5. The routine starts by calculating the new actual angles and

sets the current angles. The fuzzy control then makes four calls to the fuzzy controller

routine, Figure D.6, for roll, pitch, yaw, and height. After completing the fuzzy controllers

the new values are sent to the ESCs. When the fuzzy control is completed it returns back

to the master to start the main loop over again.

- 56 -

Design of an Autonomous Flight Controller

Fig. D.1: Master routine flowchart

- 57 -

Design of an Autonomous Flight Controller

Fig. D.2: Slave ZigBee flowchart

- 58 -

Design of an Autonomous Flight Controller

Fig. D.3: Command centre flowchart

- 59 -

Design of an Autonomous Flight Controller

Fig. D.4: Slave GPS flowchart

- 60 -

Design of an Autonomous Flight Controller

Fig. D.5: Fuzzy routine flowchart

- 61 -

Design of an Autonomous Flight Controller

Fig. D.6: Fuzzy Controler flowchart

- 62 -

Design of an Autonomous Flight Controller E. Software Code

Appendix E

Software Code

See attached CD for software code.

- 63 -