ENEL589: Fourth Year Engineering Design Project - Part II

Report #1

Department of Electrical and Computer Engineering

University of Calgary, Winter 2013
Project Title: Autonomous Quadrotor

Team Information
Team number

23

Team name

Team UFO

Team leader

Mila Gorobets

2nd Member

Michael Himmelfarb

3rd Member

Thomas Beulah

4th Member

Patrick Beasley

Customer Information
Customer

Microlynx Systems Ltd.

Website

http://www.microlynxsystems.com/

Contact person

Bill Durtler
billd@microlynxsystems.com
107 - 1925 - 18 Ave NE
CALGARY, Alberta
T2E 7T8

Contact address

Is there an IP issue with this project?

No

Is this team in a legal agreement on an IP issue?

No

Table of Contents
1. Introduction ...........................................................................................................................................................4
1.1 Summary of the project .............................................................................................................................4
1.2 Motivations .....................................................................................................................................................4
1.3 Economical aspects......................................................................................................................................5
2. Product Design Specifications ........................................................................................................................6
2.1 Expected performances .............................................................................................................................6
2.2 Specifications related to performance .................................................................................................6
3. Low Level Design .................................................................................................................................................6
3.1 Microcontroller .............................................................................................................................................6
3.2 Graphical User Interface ............................................................................................................................7
3.2.1 Main Thread (Thread 1) ...................................................................................................................8
3.2.2 Sending/Transmitting Thread (Thread 2) ............................................................................ 11
3.2.3 Receiving Thread (Thread 3) ...................................................................................................... 12
3.2.4 GUI Design and Functions ............................................................................................................ 13
3.3 Wireless Communication Link ............................................................................................................. 14
3.4 Flight Control System .............................................................................................................................. 16
3.4.1 Overview.............................................................................................................................................. 16
3.4.2 PID Controller .................................................................................................................................... 18
3.4.3 Implementation ................................................................................................................................ 20
3.5 Avoidance Control System ..................................................................................................................... 20
3.5.1 Overview.............................................................................................................................................. 20
3.5.2 Implementation ................................................................................................................................ 20
4. Test Plan ............................................................................................................................................................... 21
4.1 Graphical User Interface ......................................................................................................................... 21
4.1.1 Testing successful transmission of commands.................................................................... 21
4.2 Wireless Communication Link ............................................................................................................. 22
4.2.1 Bluetooth Transmission Distance ............................................................................................. 22
4.2.2 Successful Command Transmission Rate............................................................................... 23
4.3 Flight Control System .............................................................................................................................. 23
4.3.1 Roll Stability Test ............................................................................................................................. 23
4.3.2 Pitch Stability Test ........................................................................................................................... 24
4.3.3 Yaw Stability Test............................................................................................................................. 24
2

4.3.4 Height Test .......................................................................................................................................... 24

4.3.5 Hovering Test .................................................................................................................................... 24
4.4 Avoidance Control System ..................................................................................................................... 25
4.4.1 Obstacle Detection Test ................................................................................................................. 25
5. Budget.................................................................................................................................................................... 27
6. Health, Safety and Environmental (SHE) Issues .................................................................................. 27
6.1 Potential Hazards ...................................................................................................................................... 27
6.2 Standards and Regulations .................................................................................................................... 28
7. Work plan............................................................................................................................................................. 28
8. References............................................................................................................................................................ 29
9. Glossary................................................................................................................................................................. 29
10. Appendices........................................................................................................................................................ 30
10.1 Appendix 1................................................................................................................................................. 30
10.2 Appendix 2................................................................................................................................................. 31

1. Introduction
1.1 Summary of the project
The project to be carried out involves design and testing of an autonomously stable, but
controllable quadcopter. A quadcopter (also known as a quadrotor helicopter, or a
quadrotor) is a multicopter flying vehicle, whose lift is generated by four equally spaced
rotors. Many implementations of quadrotor systems exist; however, the vast majority of
them are remote-controlled (RC) hobbyist projects. The sizes of these systems also vary
greatly from palm-sized to large ones (built in an attempt to be able to lift humans [1]).
The main goal of this project is to produce a portable quadrotor with a diameter of
approximately 30 cm. This allows for maneuverability and the ability to adapt to various
environments and missions, while also preserving the capacity of the quadrotor to carry
sensors. Greater size essentially allows us to use larger propellers and higher-torque
motors to generate greater lift.
The quadrotor must be battery operated, removing the necessity for cables and tethering of
the vehicle to a certain location. However, for our purposes the quadrotor will be tethered
during all testing to avoid damage. Battery operation allows for our project to be usable in
other applications upon development, where the distance between the operator and the
quadrotor is greater than it is reasonable to have wires for. For our project, however, the
operator-quadrotor range is limited to 5 meters.
The vehicle must be able to hover in a stable configuration (staying within 50 cm of a
specified point in space), but upon user command move at an appropriate rate to a new
position in space. Autonomous ability to hover will allow our project to maintain stability
even if the communication link between the operator and the vehicle is lost. Motion upon
command will provide flexibility for possible future uses (for example, military surveillance,
mining operations, search and rescue).
Another goal is to be able to detect and avoid obstacles. This feature is not often
implemented on commercially available hobby RC aircraft due to the assumption that the
controller will provide adequate directions to the vehicle, and the considerably simpler
design. Adding this ability to our project will increase its versatility in confined
environments.
Finally, on the side of the operator, our goal is to develop a real-time graphical user
interface (GUI) to serve as a controller. The interface should be able to send proper
commands to the quadrotor, display critical data (such as position and motor speed), as
well as allow for path planning.

1.2 Motivations
The purpose of this project is to develop a compact quadrotor capable of displaying several
electrical engineering design qualities control systems, wireless communication,
embedded systems, sensory systems, and user interface design and execution. The final
product is to be used by Microlynx Systems Ltd for trade-show purposes.

The benefits and motivations for the project fall into several categories. First of all, the final
product will provide our sponsor with an adequate demo model to display to potential
customers, in order to present some of the possibilities available in systems design.
Secondly, the area of quadrotor design is fairly new and is developing rapidly; thus, our
project will have the chance to benefit future designs and related research. The addition of
sensory networks (for detecting obstacles) is not common, and investigating control
techniques in this area is important. Developing a communication link that does not rely on
the conventional remote control also provides additional support for other projects in this
area.
The final product will also suit a variety of applications, as described in the previous section.
Small controllable stable aerial vehicles are capable of supplementing military operations,
search and rescue, crop spraying, power line inspections and investigations of confined
spaces, such as caves or collapsed buildings. Developing an affordable vehicle would allow
us to reach into several industries and improve existing technologies.
Lastly, this project is a great opportunity for us to develop design and project management
skills. We are focusing on many areas, which will allow us to apply knowledge earned in
class to practical problems and solutions.

1.3 Economical aspects

Some of the currently available quadrotor models that meet some of our desired
characteristics are shown in Table 1. There are other more sophisticated options available,
but the cost of those models is beyond that allowed for this project.
Table 1: Price comparison of available quadrotor products

Model

Price

Features available

Parrot AR Drone

$250

Controllable with Apple and Android devices

Live-feed camera
Autopilot available for takeoff and landing
High durability and easy repair
Augmented reality games

Blade MQX RTF Micro

Quadcopter

$220

Remote controlled
Advanced stabilization system

AeroSky Quadcopter

$220

Remote controlled

Walkera QR Ladybird Mini

Quadcopter

$80

Adjustable gyro sensitivity

8.5x8.5 cm in size
On-board telemetry system

IdeaFly IFLY 4 Quadcopter

$220

Protective shell for electronics

Accurate altitude holding

To keep our final product competitive, the goal is to keep our project costs near those of the
competitors at least for the prototyping stage, however due to economies of scale this is not
realistic. The ultimate goal is, of course, to provide a competitive product at a lower price.
For initial development, we will use a development kit with a microcontroller that fits our
specifications.

2. Product Design Specifications

2.1 Expected performances
First of all, the quadrotor should be able to stably hover in one spot. This is an important
objective, as the quadrotor control system should be stable in order to ensure that its
movement is predictable. Secondly, the quadrotor should be able to avoid obstacles that
come within 50 cm of it from any direction. This is important for safety reasons to ensure
that if a person comes too close they are not injured and also to protect the quadrotor from
damage if it were to strike an object. Thirdly, the quadrotor should be able to operate within
a 5 m radius of the operator in order to ensure the range is large enough for a meaningful
demonstration. Lastly, the user commands for the quadrotor to move must work sufficiently
for the user to be able to successfully maneuver the quadrotor, which we will consider
successful if there is a 50% success rate. If the quadrotor is able to perform these tasks then
our project will be successful.

2.2 Specifications related to performance

The performance metrics that should be used to assess the performance of the quadrotor
are as follows:

User commands sent to the quadrotor from GUI must have a success rate of 60 %
Wireless communication must operate within a 5 m radius of the operator
Communication system must have a success transmission rate of 400 bytes/second
Stably hover while tethered in one spot with a 50 cm tolerance for 5 seconds
The desired roll, pitch and yaw angles should be achieved with a steady state error
of less than 10 %
The desired height should be achieved with a steady state error of less than 15 %
Disturbances up to 0.34 N should be managed while still meeting the roll and pitch
steady state error specifications
Detect obstacles within a 50 cm radius with a success rate of 60 %

3. Low Level Design

3.1 Microcontroller
The AVR32 UC3-A3256 microcontroller will power the computations of our quadrotor. The
features of this microcontroller are outlined in Table 2.

Table 2: AVR UC3-A3256 features

Microcontroller Requirements

AVR32 UC3-A3256 Specifications

32bit processor so memory addressing will

not be an issue

AVR32 UC3-A3256 is a 32bit

microcontroller

4 GPIO (General Purpose Input/Output) pins GPIO 60+ (far more than required)
for PWM controllers to output to each motor
controller on the quadrotor
1 TWI (Two Wire Interface) for the
accelerometer, gyroscope, and
magnetometer

2 TWI ports

1 USART (Universal Serial Asynchronous

Receiver/Transmitter) for Bluetooth
communication

4 USART ports

6 ADC (Analog Digital Converter) channels

for the Ultrasonic sensor output

8 ADC channels

High CPU clock cycle to execute entire

control system for flight in real time.
Frequency much greater than 8MHz.

66MHz CPU clock cycle

Lots of program memory so the project does

not require too much time on optimization
(over 64KB of memory)

256KB of program memory

The IDE (Integrated Development Environment) for this family of microcontroller is Atmels
AVR Studio 6. This program includes a C compiler for this microcontroller and has many
precompiled libraries. This IDE also supports debugging with the AVR Dragon which will be
our external programmer/debugger for this project. See the schematic attached in
Appendix 1 for details of how the microcontroller is connected to the rest of the quadrotor.

3.2 Graphical User Interface

The graphical user interface will be designed using Visual Studio C++/CLI and will have at
the minimum the following features:

Ability for user to give motion directions to the quadrotor

Ability to view information on current motor speeds, accelerometer readings and
surrounding obstacles

The graphical user interface runs on three separate threads for the majority of its execution.
This separation of processes allows for smoother control. The initialization of these threads
is shown in Figure 1.
Main Thread
Thread to receive information

End

Initialize

Communication
initialized

Initialize

Communication link
broken

Thread to send information

End

Figure 1: Thread relationship

Separation of threads to receive and transmit information allows the threads to queue up
commands at the COM port without interfering with each others operation or excessive
waiting. Furthermore, the sending/transmitting thread (thread 2 as explained below)
spends a large portion of time in suspension.
3.2.1 Main Thread (Thread 1)
The main thread maintains control over the form elements, capturing user inputs from
keyboard, performing calculations, initializing the other two threads and closing them when
the program is over. This thread is the original program thread started when QUI.exe is run.
The main thread spans over several namespaces and a collection of functions, as outlined
briefly below using their class diagrams.
Modelspace::Model

Model

Stores model information for propellers (a single model

for all propellers), and the quadrotor frame.
Has a function that renders the model part using vertex
and normal information.

-^ triangles : array<Triangle>
-^ normals : array<Normal>
-^ vertices : array<Vertex>
-triangleCount : int
-verticesCount : int
-normalCount : int
+<<constructor>> Model() : void
+<<destructor>> ~Model() : void
+loadModel(char *mFilename)() : int
+draw() : void
+Model_init() : void

Figure 2: Model class diagram

OpenGLForm::COpenGL
COpenGL

Handles OpenGL-related functions and variables.

Initializes the rendering frame.
Loads model files and calls rendering functions in Model
class to render the entire model.

+f_one : QUI::Form1^
+quadrotor : ModelSpace::Model^
+prop : ModelSpace::Model^
-m_hDC : HDC
-m_hglrc : HGLRC
+<<constructor>> COpenGL() : void
#<<destructor>> ~COpenGL()
+COpenGL_one(iWidth, iHeight)() : int
+DrawGLScene() : int
+SwapOpenGLBuffers() : void
+KILLGLWindow() : GLvoid
#MySetPixelFormat(HDC hdc)() : GLint
#InitGL() : bool
#ReSizeGLScene(width, height)() : GLvoid

Figure 3: COpenGL class diagram

QUI::Form1

Form1

Maintains the Windows Form.

Receives user input from keyboard and Form
elements.
Initializes and terminates two
communication threads.
Updates the motor speed plots.
Establishes the communication link.
Refreshes the OpenGL rendering every 40ms.

-o_gl : OpenGLForm::COpenGL^ o_gl

-cPort : HANDLE
+^ Form1::returnpanel() : System::Windows::Forms::Panel
+Form1::updateCommand() : int
+<<constructor>> Form1()
#<<destructor>> ~Form1()
-btnConnect_Click(^ sender, ^ e)()
-btnDisconnect_Click(^ sender, ^ e)()
-Form1_KeyUp(^ sender, ^ e)()
-Form1_KeyDown(^ sender, ^ e)()
-timergl_Tick(^ sender, ^ e)()
-btnSend_Click(^ sender, ^ e)()
-btnReturnHome_Click(^ sender, ^ e)()
-btnGoToWaypoint_Click(^ sender, ^ e)()
-btnAddWaypoint_Click(^ sender, ^ e)()

Figure 4: Form1 class diagram

There is also a set of calculation functions which use the QUI namespace, but are not part of
any specific class.
The main thread does not run on a superloop, instead allowing other processes to take time
executing, and performing UI updates at specific timer intervals. Keyboard input and form
button presses are responded to using event functions. The processes on this thread are
shown in Figure 5 through Figure 10.
Communication
link started

Open specified COM

port at 9600 baud

Clearing all
sending flags

Start threads 2
and 3

Communication
link terminated

End threads, release

allocated resources

Close COM port

Turn
communication
indicator red

Turn
communication
indicator green

Figure 5: Communication Link processes

The communication link resources reside on two separate threads (as described further on)
for the majority of the time the information exchange between the main thread and the
others is done using pointers to specific character arrays for outgoing and incoming data.
The accelerometer data is used differently from motor speeds and ultrasonic sensor
readings. The accelerometer data can be used to determine how far the quadrotor has
travelled using a series of mathematical manipulations and is shown in Figure 6.

Accelerometer
data has arrived

Use calculation
functions to produce
quadrotor tilt and
distance traveled

Update tilt angle in

rendering

Update position of
model in rendering
space

Figure 6: Receiving accelerometer data

Motor speed data is used for updating the plots and this data is stored in text files in a
default directory. This process is shown in Figure 7.
Motor speed data
has arrived

Write data to file

Update graphs on
GUI

Figure 7: Receiving motor speed data

Ultrasonic data allows for rendering of obstacles around the quadrotor in the OpenGL panel
as is described in Figure 8. Obstacles are rendered as blocks since no distinction can be
made in terms of size using our sensors. Obstacles above and below the quadrotor are not
rendered because the view will not permit them to be viewed properly; instead, a note will
be displayed in the Messages window in the GUI to tell the operator about the distance to
ceiling and floor.
Ultrasonic data
has arrived

Update obstacles in
rendering

Figure 8: Receiving ultrasonic data

Two different methods can be used by the user to enter directional information. The first is
to enter the values of roll, pitch, yaw and z by hand, and simply transmitting those values as
is shown in Figure 9. This is the method of choice when debugging. A more advanced
method can be utilized that requires more computing as is shown in Figure 10. In that case,
the user will be able to press buttons on the keyboard and move the quadrotor accordingly.
Conversion from directions to proper roll/pitch/yaw/z values will be required.
User has entered
directions

Convert to proper
command (string)

Put command into

character array

Figure 9: User enters roll, pitch, yaw, z directions by hand

10

Update
DIR_TO_SEND
flag

User has pressed

keyboard arrow

Convert direction to
roll/pitch/yaw/z

Convert to proper
command (string)

Put command into

character array

Update
DIR_TO_SEND
flag

User has released

keyboard arrow

Set roll/pitch/yaw/z to
hover configuration

Convert to proper
command (string)

Put command into

character array

Update
DIR_TO_SEND
flag

Figure 10: User enters directions with keyboard

3.2.2 Sending/Transmitting Thread (Thread 2)

The transmitting thread is responsible for sending out directions and information requests
in a timely fashion. It is initialized from the Form class when the user presses the Connect
button and communication is established via a COM port. The thread is a class instance,
diagram of which is shown in Figure 2.
hPort (HANDLE)

comm_CPPThread
+hPort : HANDLE
+^ req : int<array>
+DIR_TO_SEND : bool
-bw_timerAccRequest : BackgroundWorker
-bw_timerMotorsRequest : BackgroundWorker
-bw_timerUltrasonicRequest : BackgroundWorker
+<<constructor>> comm_CPPThread() : void
+<<destructor>> ~comm_CPPThread() : void
+comm_threadProc() : void
+comm_threadAddArguments (HANDLE *pArg1)() : void
+comm_sendDirections() : void
+comm_requestAcc() : void
+comm_requestUltrasonic() : void
+comm_requestMotors() : void
-bw_timerAccRequest_DoWork(^ sender, ^ e)() : void
-bw_timerAccRequest_RunWorkerCompleted(^ sender, ^ e)() : void
-bw_timerUltrasonicRequest_DoWork(^ sender, ^ e)() : void
-bw_timerUltrasonicRequest_RunWorkerCompleted(^ sender, ^ e)() : void
-bw_timerMotorsRequest_DoWork(^ sender, ^ e)() : void
-bw_timerMotorsRequest_RunWorkerCompleted(^ sender, ^ e)() : void

This handle is passed from the

main thread to allow the
processes to use the available
COM port.
req (int<array>)

Space for 3 elements of this

array is allocated using gcnew
(instance of managed type on
the garbage collected heap).
The elements store flags that
represent which information
request (acceleration, motor
Figure 11: comm_CPPThread class diagram
speeds, ultrasonic data) should
be made, if any. Acceleration
requests are made every 500ms, ultrasonic every 2s, and motor speed every 3s.
DIR_TO_SEND
A flag set by the main thread that indicates that user has input directions. The thread uses
this as an indication that information related to motion of the quadrotor should be sent out.
bw_timerAccRequest, bw_timerMotorsRequest, bw_timerUltrasonicRequest
The class uses three background workers to act as timers for noting when an information
request is to be made. The majority of the time is spent suspended in order to reduce the

11

amount of system resources used. This also allows other applications running at the same
time as the GUI to use the available resources.
Each of the background workers has two associated functions _DoWork and
_RunWorkerCompleted, which receive sender information and parameters through the
function arguments.
comm_requestAcc, comm_requestUltrasonic, comm_requestMotors
These functions are associated with the req array. The sole purpose of the functions is to
queue up appropriate commands to be sent at the COM port.
comm_threadProc()
This function defines the operation of this thread. It is responsible for checking request flags
and the flag to send user directions out.
comm_threadAddArguments(HANDLE *pArg1)
This function receives pointers to data from the main process thread. It copies pointer
information into class variables.
comm_sendDirections()
This function is called when DIR_TO_SEND is set to true. The function then queues up a
command at the COM port with roll, pitch and yaw information for the quadrotor.
3.2.3 Receiving Thread (Thread 3)
The purpose of this thread is to poll the receiving flag of the COM port to check if any new
data has arrived. Its operation is completely independent from the transmitting thread. As
such, it will not know when to anticipate data returning even if a request for data
(accelerometer readings, ultrasonic data, motor speeds) was made in the transmission
thread.
comm_pollRX
+comm_port : HANDLE
+<<constructor>> comm_pollRX()
+<<destructor>> ~comm_pollRX()
+comm_pollRXProc() : void
+comm_pollRXAddArguments(HANDLE kPort)() : void

comm_port (HANDLE)
This handle is passed from the main thread to
allow the processes to use the available COM
port for reading values.

Figure 12: comm_pollRX class diagram

comm_pollRXProc()
This is a function that defines the operation of this thread. It remains in a loop and waits
until new data arrives at the COM port. If new data is available, it is read, stored, and a flag is
set to signal that it can be processed by the main thread.

12

comm_pollRXAddArguments(HANDLE *kPort)
This is a function that receives pointers to data from the main process thread. It copies
pointer information into class variables.
3.2.4 GUI Design and Functions
The current GUI design shown in Figure 13 offers the user several inputs and outputs
described below.

The motor speeds are displayed in the plots on the left hand side (on the left of the
3D rendering of the quadrotor in space).
The rendering will display quadrotor tilt at a given time (at intervals of 500ms). The
red arrow displayed in the figure below is a result of pressing a button on the
keyboard. The view of the rendering cannot be changed. Obstacles are to be
rendered around the quadrotor as rectangular blocks.
The roll, pitch, yaw and z fields at the top right of the form can be filled in by the
user. Pressing the Send button will signal the quadrotor to realize that
configuration. Another way to make the quadrotor move is to use the arrow keys on
the keyboard. This will convert the motion commands to roll, pitch, yaw and z
values.
The Messages window will display relevant information, error messages, warnings
and distances to floor and ceiling.
The Distance from Home indicator will tell the operator how far the quadrotor has
moved away from its origin in space. The operator has an option to return home by
following the shortest path available. Similarly, there is an ability to leave waypoints
at the quadrotors current location. The user can return to them using the shortest
possible path.
The Communication Link indicator is red when the communication has not been
established, and green otherwise. The connection and termination is done using the
buttons below it.

13

Figure 13: GUI design

3.3 Wireless Communication Link

The hardware chosen for the wireless communication link is outlined in Table 3.
Table 3: Wireless communication hardware

ASUS Mini Bluetooth USB Dongle

RS232 Mini Wireless Bluetooth Module
Windows Computer

Using the Windows operating system, a standard COM port for RS232 communication will
be emulated. This COM port will be configured with the communication specifications
outlined in Table 4.
Table 4: COM port communication specifications

Baud Rate

9600

Parity

None

Number of Stop Bits

Flow Control

Off

14

The microcontroller USART port will be configured to the same settings as the USART
configuration with the RS232 Mini Wireless Bluetooth Module. AVR Studio 6 has a USART
library which includes functions for configuring the port to the required settings, sending
ASCII characters, sending strings, and reading ASCII characters. These functions will be
utilized to implement our quadrotor command list as shown in Table 5. The command list
will be a switch statement in C code that converts commands sent/read into movement or
graphical information.
Table 5: ASCII character commands

ASCII
Function
Character
Command
A

Get Motor speed #1

Get Motor speed #2

Get Motor speed #3

Get Motor speed #4

Set Roll

Set Pitch

Set Yaw

Set Z

Get Acceleration

Get Proximity

Get Data

Get Time Overflow

Get COM Confirmation

Request COM confirmation

After the ASCII character command, data can be transmitted as is shown in Figure 14. After
data is finished being sent for any command then a # character will be sent (# is a
termination character). After the # is received the system will wait for another valid ASCII
character command to continue the communication. If an invalid command is read then it
will ignore the transmitted information and wait for a valid command.
15

Yes
ASCII
character
command
Sent

Wait for ASCII

character
command to
be received

Is a valid
command?

Yes

Is a data
character a
# ?

Send data

No

No

Figure 14: Communication flow diagram

3.4 Flight Control System

3.4.1 Overview
The flight control system of the quadrotor has four control inputs:

Desired roll angle, des_roll

Desired pitch angle, des_pitch
Desired yaw angle, des_yaw
Desired height , zdes

The purpose of the control system is to realize these inputs. The system will be based upon
proportional-integral-derivative (PID) control loops due to the ease of implementation of
this control method. The control loops will be running on the main microcontroller.
Control loops require feedback which will be provided by an Inertial Measurement Unit
housing an onboard gyroscope and accelerometer. These devices provide data from which
roll, pitch and yaw angles can be calculated. An ultrasonic rangefinder will provide height
feedback. The feedback values will be denoted as follows:

Roll angle, roll

Pitch angle, pitch
Yaw angle, yaw
Height, z

Using sensor feedback, the PID controller can then calculate motor speeds required to
realize the desired control inputs. The motor speeds will be denoted as M1, M2, M3, and M4.
They correspond to the four motors on the quadrotor as shown in Figure 15. A block
diagram of the control system inputs and outputs is shown in Figure 16.

16

Figure 15: Motor Layout

FLIGHT CONTROL
SYSTEM

INPUTS
des_roll

OUTPUTS
M1

PID Controller

des_pitch
des_yaw

M2

M3
Feedback

zdes

M4
Height Data

Ultrasonic
Rangefinder

Inertial
Measurement
Sensor

Calculate feedback:
roll, pitch, yaw, z

Gyro, Accelerometer Data

Calculate acceleration
values

Figure 16: Flight Control Block Diagram

17

Acceleration values

3.4.2 PID Controller

The PID controller has four control loops: a height loop, a roll angle loop, a pitch angle loop,
and a yaw angle loop. The control outputs of these loops are the state space variables, which
must be converted to motor speeds later on. The state space variables are denoted as
follows:

The PID control loop equations to calculate the state space variables are as follows:

The K values are control gains which can be adjusted to provide various responses. These
will be tuned to achieve a fast, underdamped response. Cg is a constant which counteracts
the force of gravity.
The control loops can be expressed in graphical form. An example is shown in Figure 17 for
the pitch angle. Each loop is similar to the one shown in Figure 17, with an exception for the
height loop, which includes a constant to cancel out the constant pull of gravity on the
quadrotor.

Figure 17: Control Loop Example

18

The individual motor speeds (M1, M2, M3, and M4) must be calculated from the state space
variables. To do this, the state space variables are related to the motor speeds using the
following equations:

This represents a matrix equation [U]=[A][M] where

Taking the inverse of matrix A, the motor speeds can be found from [M]=[A]-1[U].
To help design the control system, a Simulink model was created using the control system
outlined above and the following physical model of the quadrotor:

Where:

Jyy= second moment of area about y axis

Jxx= second moment of area about x axis
Jzz= second moment of area about z axis
m=mass of quadrotor
C= proportional consants

The Simulink model is provided in Appendix 2. The values of Jyy, Jxx, Jzz, m and C are not
accurate because the quadrotor is not yet fully assembled with all the parts. Therefore, the
control gains will require tuning later on when the design is implemented. Using
approximate values for the physical model, the control gains of Kpi=10, Kdi=4, KIi=4 were
found to give a stable, fast, underdamped response.

19

3.4.3 Implementation
The control system designed in the Simulink model will be implemented using C code on the
microcontroller. The Inertial Measurement Unit used will be the MinIMU-9 v2 available
from Pololu Robotics and Electronics. This unit interfaces with the microcontroller using I2C
protocol.

3.5 Avoidance Control System

3.5.1 Overview
The goal of the obstacle avoidance system is to identify any obstacle that comes within 50
cm of the quadrotor and successfully move away from the obstacle with a success rate of
60 %. After careful consideration of the sensors available, the Maxbotix LV-EZ1 ultrasonic
sensor was selected for this project. The ultrasonic sensor was chosen as it provides
accurate proximity measurements, is lightweight, has low power consumption, can detect
translucent objects, is reasonably inexpensive and is easy to use and implement.
3.5.2 Implementation
There will be four directional sensors used for detecting obstacles on the sides of the
quadrotor, a fifth sensor will be pointed up to detect obstacles above the quadrotor and a
sixth sensor will be pointed down for an accurate altitude measurement as well as detecting
objects below the quadrotor. The sensors in this configuration should provide sufficient
coverage to provide a 60% success rate for obstacle detection as shown in Figure 18.

Figure 18: Four directional ultrasonic sensor detection spectrum 35 cm from an obstacle

The obstacle avoidance system input and output diagram is shown in Figure 19. The analog
output signal of the ultrasonic sensors is analyzed using an Analog-to-Digital Converter
(ADC) to determine the distance to the nearest obstacle for each sensor.

20

Figure 19: Obstacle avoidance system inputs and outputs diagram

The distance to the obstacle is calculated using the following formula supplied with the
ultrasonic sensors:

As a 3.3 V source is hard-wired to the ADC voltage supply it is used as the upper bound of
the ADC conversion. This represents a distance of 13 m as measured by the sensors, which
is a distance much greater than needed. However, as there is a 10-bit output from the ADC,
the resolution is still sufficient to accurately determine if the distance to the nearest
obstacle is within 50 cm.
If an obstacle is detected, data will be sent to the GUI to provide the user with updated
information on the surrounding environment as well as the current altitude of the
quadrotor. If the distance is within the 50 cm range, pre-determined roll, pitch, yaw and
altitude commands will be sent to the flight control system to maneuver away from the
obstacle.

4. Test Plan
4.1 Graphical User Interface
4.1.1 Testing successful transmission of commands
The purpose of this test is to measure the success rate of receiving and transmitting
commands. This is important in order to make sure that directional commands will be
properly sent to the quadrotor, and that information important for the user will be shown in
the GUI.

21

Procedure to test keyboard input:

1. Set up a testing sequence to be executed by the user. The sequence should involve
pressing each directional key on the keyboard (one at a time).
2. The user will first press and hold each key for a period of approximately 3 seconds,
giving the system ample time to transfer information. The period will then reduce to
2 seconds, and 1 second to complete the test. The keys should be pressed in the
same order in all 3 cases.
3. During these events, the communication system will operate normally, requesting
accelerometer, motor speed and ultrasonic data at appropriate time intervals. The
incoming data will be counted and displayed in the Messages window, which will
allow for results tally of received data.
4. A symbol will be displayed on an LCD screen attached to the microcontroller board
for each valid directional command received from the PC.
5. Percentage of successfully transmitted and received commands will then be
calculated and compared to the desired value.
Procedure to test numerical input:
1. The user will enter 12 (to check all six directional commands twice) prepared roll,
pitch, yaw and z values and send the values out every 4 seconds. There will only be a
single time period used in this test, as there are limitations to how fast a user can
enter values by hand.
2. During these events, the communication system will operate normally, requesting
accelerometer, motor speed and ultrasonic data at appropriate time intervals. The
incoming data will be counted and displayed in the Messages window, which will
allow for results tally of received data.
3. A symbol will be displayed on an LCD screen attached to the microcontroller board
for each valid directional command received from the PC.
4. Percentage of successfully transmitted and received commands will then be
calculated and compared to the desired value.

4.2 Wireless Communication Link

4.2.1 Bluetooth Transmission Distance
The purpose of this test is to determine the maximum distance at which the quadrotor can
be operated at from the user. This will verify the specification that the quadrotor must
operate within a 5 m radius.
Procedure:
1. Open a terminal program that can monitor how many characters have been sent
(such as Realterm) since transmission starts.
2. Have the AVR controller continually send out the same command in an infinite loop.
22

3. Start the AVR controller and the Bluetooth transmitter 1 meter away from the USB
Bluetooth receiver. Separate the AVR controller from the USB Bluetooth receiver by
increments of 1 meter until the terminal program indicates that data has stopped
transmitting. This will provide the furthest distance the quadrotor can operate in
meters.
4.2.2 Successful Command Transmission Rate
The purpose of this test is to determine if the effective rate of successful transmission of
bytes over the Bluetooth channel and to test if near-real time control of the quadrotor is
feasible.
Procedure:
1. Place the quadrotor and the receiver at exactly 5m away from the computer and
Bluetooth dongle (5m is the minimum required specification for this project).
2. The AVR controller will continuously transmit 1000 character commands (1 Byte
each) from the command list without pause.
3. Before the AVR controller starts transmitting, an internal timer on the
microcontroller will be initialized and will keep track of the time taken to send the
1000 character commands.
4. 1000 commands will be divided by the time taken to transmit them producing a
command rate in Bytes/second.

4.3 Flight Control System

Flight control system testing must determine if the quadrotor can achieve stable flight. A
problem that had to be solved when designing the test procedure was the high risk of
damage to the quadrotor hardware in the event of a control system failure. At the same time,
care was taken to ensure that the testing procedure gives accurate results. Taking these
issues into consideration, the following procedure was developed.
4.3.1 Roll Stability Test
The roll stability of the quadrotor will be tested by securing the quadrotor so it has the
freedom to rotate around only the y axis. This will be done using a test apparatus that holds
the quadrotor arms 4 and 2 while allowing the quadrotor to still pivot around the y axis. A
protractor will be fastened to the bottom of the quadrotor which will allow the current roll
to be read with little error. During the test, a 30 gram weight will be hung off arm 1 or 3 to
test the disturbance specification.
Procedure:
1.
2.
3.
4.

Turn on the quadrotor control board

Input a value of 0 for all control inputs including des_roll
Initialize and turn on motors
Record maximum deviations of roll from des_roll
23

5.
6.
7.
8.
9.
10.
11.

Compare recorded error to the steady state error specification

Input a value of 0.2 radians for des_roll.
Record maximum deviations of roll from des_roll
Compare recorded error to the steady state error specification
Hang a 50 gram weight off arm 1 of the quadrotor.
Record maximum deviations of roll from des_roll
Compare recorded error to the steady state error specification

4.3.2 Pitch Stability Test

This is the same test as for the roll stability test, except the quadrotor arms 1 and 3 will be
secured with the freedom to rotate around only the x axis.
4.3.3 Yaw Stability Test
The quadrotor will be fastened to the top of a pole that allows the quadrotor to rotate
around the z axis but stops it from rotating around the x or y axis. A protractor will be
fastened to the quadrotor in the horizontal plane with a reference marker to allow the
current yaw to be read with little error.
Procedure:
1.
2.
3.
4.
5.
6.
7.
8.

Turn on the quadrotor control board

Input a value of 0 for all control inputs including des_yaw
Initialize and turn on motors
Record maximum deviations of yaw from des_yaw
Compare recorded error to the steady state error specification
A value of 0.2 radians is entered for des_yaw.
Record maximum deviations of yaw from des_yaw
Compare recorded error to the steady state error specification

4.3.4 Height Test

The quadrotor with have a leash fastened to the end of each arm. A team member will hold
on to the end of each leash. This is to prevent damage to the quadrotor in the event of a
failure and to prevent the quadrotor from moving in the x or y direction. Measuring line will
be fastened to the bottom of the quadrotor.
Procedure:
1. Command the quadrotor to hover at a height of 20 cm.
2. Read the actual height from the measuring line and compared to the steady state
error specification.
4.3.5 Hovering Test
The quadrotor will have a leash on each arm in the same manner as the height test.
However, tension will only be put on a leash in the event of an imminent crash to protect
the hardware from damage. The quadrotor will be allowed to drift in the x, y and z

24

directions. A circle with a 0.5m radius will be marked on the floor with tape. A timer will be
used to keep track of time.
Procedure:
1.
2.
3.
4.
5.

Place the quadrotor in the center of the circle marked on the floor
Command the quadrotor to hover at a height of 20 cm.
Start the timer
Stop the timer when the quadrotor moves outside the marked circle.
Compare the time with the specification of 5 seconds.

4.4 Avoidance Control System

4.4.1 Obstacle Detection Test
The purpose of this test is to determine if the quadrotor can detect obstacles within 50 cm
of it with a success rate of 60 %. This is important for safety reasons to ensure that the
quadrotor does not strike any object and potentially damage the object or itself.
Procedure:
1. Each sensor will be connected to a separate ADC input on the development board
and will be associated with a certain Light Emitting Diode (LED).
2. An obstacle will be placed within 50 cm of each sensor and if it is operating correctly
the LED should turn on when this happens.
3. An obstacle will also be placed outside of the 50 cm range of the sensor and if it is
operating correctly the LED should not turn on to ensure the sensor is not falsely
detecting obstacles.
This process will be done for each individual sensor, as well as all combinations of the
directional sensors as shown in Table 6. If the top or bottom sensor detects an obstacle, the
quadrotor must simply move in the opposite direction to avoid the obstacle. Therefore, the
5th and 6th sensors on the top and bottom were not included in the combination of sensor
detection situations shown in Table 6. If the test is successful then the obstacle avoidance
system is functioning correctly and it can be assumed it will work in the quadrotor system
with the other components.

25

Table 6: Ultrasonic sensor combinations for the obstacle avoidance system testing

Sensor(s) with
Detection

LED On

1,2,3,4 RAPID FLASH

1,2,3,4 SLOW FLASH

1,2

1,2

1,3

1,3

1,4

1,4

1,2,3

1,2,3

1,2,4

1,2,4

2,3

2,3

2,4

2,4

2,3,4

2,3,4

3,4

3,4

1,2,3,4

1,2,3,4 SOLID

26

5. Budget
Budget outline
Budget request
Materials and supplies

$500

Software

Small equipment

Travel

Books and journals

Subscription to resources

Consultant fee

Others; specify: Shipping of Materials and supplies

$50

Others; specify:
Others; specify:
Total

$550

B) Budget justification: The materials needed for this project are quite sophisticated and
therefore are expensive. As there will only be one quadrotor produced it is not feasible to
buy materials in bulk and lower the costs.
C) Source of funding: Microlynx Systems Ltd.

6. Health, Safety and Environmental (SHE) Issues

6.1 Potential Hazards

Electric shock from the computer or exposed wires

Sound from quadrotor causing headaches
RF radiation from Bluetooth module
Small parts are choking hazards for small children
Unstable control system resulting in loss of control of quadrotor causing damage
Propeller damage due to crashes or miscalculations
Undetected obstacles/unavoidable obstacles being struck by quadrotor
Batteries exploding
27

6.2 Standards and Regulations

CARs 602.45: General Operating and Flight Rules from Canadian Aviation
Regulations (2012-1), Model Aircraft, Kites and Model Rockets
FCC Part 15 American standards for EMC (electromagnetic compatibility) of
devices.
Bluetooth Wireless Communication Standard

7. Work plan
Tasks

Deadline

The low level design is approved and finalized

Jan 25, 2013

The specifications are approved and finalized

Jan 19, 2013

The test plan is approved and finalized

Jan 25, 2013

List of required parts and materials are finalized

Jan 19, 2013

All parts and materials are available by

Feb 15, 2013

First version of the project is implemented

Feb 25, 2013

First iteration of testing is completed

Mar 1, 2013

Further improvements of design and/or test plan

Mar 14, 2013

Final version of the project is implementation

Mar 15, 2013

Testing of the final version of the project is completed

Mar 20, 2013

Final presentation is ready

Mar 27, 2013

Report #2 is ready

Mar 24, 2013

The final version of the poster is printed off

Apr 7, 2013

Capstone design fair (Tentative)

Apr 10, 2013

28

8. References
1. G. Mortimer, German multicopter makes first manned flight, (sUAS News),
[online] 2011, http://www.suasnews.com/2011/11/9691/german-multicoptermakes-first-manned-flight/ (Accessed: 5 November 2012).

9. Glossary
CLI-Command Line Interface: A type of interaction between a user and a computer program
where the user enters in lines of text to be executed.
C++: A common object oriented computer programming language.
I2C - Inter-Integrated Circuit: A protocol used for wired serial communication between a
host device and a slave device. This interface is useful for hooking sensors up in a slave
configuration.
PID Proportional-Integral-Derivative control: A linear control method with control
outputs based on the error between the desired control inputs and actual feedback and the
derivative and integral of this error.

29

10. Appendices
10.1 Appendix 1

30

10.2 Appendix 2
The Simulink model of the control system is shown in this appendix.

31