Report #1 - WordPress.com

sploshtribeSoftware and s/w Development

Dec 14, 2013 (3 years and 5 months ago)

204 views



Department of Electrical and Computer Engineering

Schulich School of Engineering

University of Calgary


Fall 2012


4
th

Year Project Report #2

Preliminary Design Document

Group # 23

Team UFO

Quadrotor



Group Members:

Mila Gorobets

Thomas Beulah

Michael Himmelfarb

Patrick Beasley

Sponsor’s Name:

䵩捲潬y湸⁓y獴敭猠i瑤



䑥c″Ⱐ㈰ㄲ

Table of Contents

1.

Introduction

................................
................................
................................
.............................

3

2.

System Level Architecture

................................
................................
................................
......

4

2.1 Graphical User Interface (GUI)
................................
................................
.............................

4

2.2 Flight Control System

................................
................................
................................
...........

4

2.3 Bluetooth Wireless Communication

................................
................................
.....................

5

2.4 Obstacle Avoidance Control

................................
................................
................................
.

5

3.

Preliminary Design

................................
................................
................................
..................

5

3.1 Top Level

................................
................................
................................
..............................

5

Physical Components:

................................
................................
................................
.............

6

3.2 User Interface

................................
................................
................................
........................

7

3.3 Wireless Communication Link
................................
................................
............................

13

3.4 Microcontroller Lookup Table

................................
................................
............................

14

Definition of Commands:

................................
................................
................................
......

14

Command Table

................................
................................
................................
....................

15

3.5 Avoidance Control System
................................
................................
................................
..

15

Sensor Functionality

................................
................................
................................
..............

16

Sensor Implementation

................................
................................
................................
..........

16

Obstacle Avoidance

................................
................................
................................
...............

18

3.6 Flight Control System

................................
................................
................................
.........

18

Feedback

................................
................................
................................
................................

19

Control Method
................................
................................
................................
......................

19

Flight Control System Diagram

................................
................................
.............................

20

4.

Prototypes

................................
................................
................................
..............................

21

4.1 User Interface

................................
................................
................................
......................

21

4.2 Flight Control System

................................
................................
................................
.........

22

5.

Bill of Materials

................................
................................
................................
.....................

24

6.

Appendix A
................................
................................
................................
............................

25

7.

Appendix B

................................
................................
................................
............................

26

8.

Glossary

................................
................................
................................
................................
.

26

9.

References

................................
................................
................................
.............................

28


1.

Introduction


The project to be carried out involves design and testing of an autonomously stable, but
user
controllable, quadrotor. A quadrotor

(
also known as a
quadcopter or helicopter
) is a multicopter
flying vehicle,

whos
e lift is generated by four equally spaced ro
tors.

The main goal of this project is to produce

a portable
, battery
-
operated

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 capac
ity of the quadrotor to carry sensors.

The designed quadrotor must have an operator
-
vehicle range of at least 10 meter
s
, and
guaranteed flight time of at least 2 minutes.

The vehicle must be able to hover in a stable
configuration (staying within 15 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 fo
r possible future uses (for example,

military surveillance, mining operations, search and rescue).
The vehicle must also be able to
detect and autonomously avoid obstacles. User commands will be delivered usi
ng a graphical
user interface (GUI), with a maximum delay of 500 ms. The GUI will also aim to provide
valuable system information to the operator, such as motor speed, location of nearby obstacles,
and important points in space.


This project will create

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.

Final uses of this project will involve trade
-
sh
ow
demonstrations by the sponsor, as well as the possibility of use for military surveillance, search
and rescue and exploration purpose. The design process itself will have the opportunity to
influence the on
-
going research in the area of robotics and unm
anned aerial vehicles.

The following report describes the preliminary designs carried out for the key sections of this
project. We used the top
-
down design methodology, and thus the project is split up into four
distinct areas: obstacle avoidance implement
ation, control system,
communication link and the
GUI.

2.

System Level Architecture

The diagram describing the interaction of our
system’s

components is shown in
Figure
1
.
Main
parts of the system architecture are further described in the sections below.

Figure
1
.

Top Level System Diagram

2
.1
Graphical User
Interface

(GUI)


The GUI is an interface that allows the user to control the quadrotor. From the GUI
,

the user can
control the direction the quadrotor moves, observe graphs of the motor speeds with time, retrace
paths taken, and examine the quadrotor

in relative 3D space as a rendering. The GUI
communicates with the microcontroller through the Bluetooth wireless link. The GUI sends and
receives commands
,

which are mapped into

a command table shown

in

Table
1
.

2
.2
Flight Control System


The quadrotor must be able to hover. This requires motors, accelerometers,
a
gyroscope, and
a
microcontroller in order to remain
in a constant position
. The moto
rs will provide lift, while the
accelerometer and the gyroscope provide information to the microcontroller

which

processes
the

information and updates motor speed.


2
.3
Bluetooth Wireless Communication


The communication between the user and the quadrotor

will be established with a
Bluetooth
module and a computer.

This module will be connecte
d to the microcontroller using

a

USART
(Universal Serial Asynchronous Receiver/Transmitter)
serial interface. Software on the
microcontroller side will receive informa
tion from the user and adapt motor speed
s

to implement
the movement desired by the user.

All data transferred through the Bluetooth communication
channel will need to be converted into commands that the computer program can understand. To
do this we will

implement a command table to allow fluid communication of commands. There
will be commands for motor speed, proximity detection, movement direct
ion
,

and others
.


2
.4 Obstacle
Avoidance Control


Ultrasonic sensors will be used to determine the proximity o
f objects

near

the quadrotor. These
sensors will communicate with the microcontroller through an I
2
C

(Inter
-
Integrated Circuit)
serial interface. Their information will be used by the microcontroller to prevent the quadrotor
from colliding with
obstacles
in the

environment.
In order for the avoidance control to be
autonomous
,
it must communicate directly with the flight control system to override the

user
flight commands

and prevent collision.

3.

Preliminary Design

3
.1 Top Level


The chosen design meth
od for this project is Top
-
Down
Design.
From the system level
architecture, t
he design of the semi
-
auton
omous quadrotor consists of four

modules which
communicate with each other. These modules are the user interfac
e, wireless communication
link,

avoidance

control system, and the flight control system.

The arrows indicate how different
types of data are

passed between each of the modules.

Each of these modules will be described in
detail
in
this report.

The user interface

gives feedback to the user about t
he quadrotor’s status, and pro
vides a way for
the user to input

d
esired commands
.

The avoidance control module and the flight control
module are onboard the quadrotor. Therefore all data that flows between
the user interface and
the onboard systems must b
e transferred by the wireless communication link.

A
microcontroller
lookup table deciphers binary commands from the wireless link.

T
he user interface sends mo
tion
commands that are specified by the user to the flight control system
. The flight control rec
eives
these commands and executes them by controlling the quadrotor’s motor speeds. It returns three
axis acceleration values and the four motor speeds to the user interface. The avoidance system
detects obstacles and sends information about them back to t
he user interface. It then sends a
command to the flight control system that will make the quadrotor move away from the obstacle

if it is within 50 cm
.

Physical Components:

Each

module require
s

physical hardware

which is shown in

t
he

physical component diagram
in
Figure
2
.



Figure
2
.

Physical Component Top Level Diagram

The actual quadrotor frame is not being developed
in this project


rather, the components are
purchased, and the electronic components are what
will be
design
ed
. The components for the
quadrotor were a part of a kit, which included the frame, motors, a battery, propellers and motor
speed controllers. An
Atmel microcontroller development board was also purchased separately.

The chosen kit features a lightweight, affordable frame, small motors, propellers of proper size,
motor speed controllers suitable for the motors chosen, and a LiPo battery to power th
e motors.

The microcontroller board was chosen because of the abundance of input/output pins and
communication ports. The maximum operating frequency of the microcontroller is 66MHz,
which allows for many mathematical operations per second. This is important in our
application
due to the control system implementation, which requires multiple fast calculations in order to
adjust the motor speeds properly.

The microcon
troller board will be mounted at

the center of the assembled frame.


3
.2
User Interface


The purpose of the graphical user interface (GUI) in this project is to provide the quadrotor
operator with means of sending commands
(
via a computer
)
, visualizing the surrounding
environm
ent
,

and monitoring key components
of the system. The proposed solut
ion is to be
designed using managed Visual C++ (through Visual Studio 2010) and should be able to
communicate with the quadrotor using Bluetooth via the USB port.

The implementation will use four classes, with the applications of each described in the “Mai
n
Features” section. The general design diagram of the GUI and its interfaces
is

shown
in
Figure
3
.


Figure
3
. Gr
aphical user interface inputs and outputs


Main Features



Main graphical user interface window: this is where the user inputs will be gathered, and
outputs displayed. It will contain all features described below.

Implementation:

The form will be occupying
its own class (“Form”), and designed using Visual Studio’s form
elements. The window size will be 1080x1920

pixels
, but with an ability to d
ecrease it if
needed for lower resolution

screens.




3D model of the quadrotor in the surrounding environment: the u
ser will be able to change
the
view and use the rendered graphics

(obstacles and waypoints)

to plan further actions.

Implementation:

This is to be done using an embedded OpenGL frame in a Windows Form (this is created in
Visual C++/CLI). OpenGL is chosen

because of its relative ease of implementation in
managed C++, and prior knowledge of the conventions and syntax.

The 3D model itself will be developed in Autodesk Maya


provided for free to University of
Calgary students. This software allows for an ex
tensive development of the model using
complex shapes and textures. The final model will have color
-
coded propellers to
differentiate between the four available (these colors will also correspond to those on the
motor speed plots


this is further explaine
d below).

The OpenGL frame will be contained in its own class (“OpenGL”), and during refreshing it
will run on its own thread to permit other processes to continue uninterrupted. The OpenGL
panel will be refreshed every 10 ms; this time is chosen based on

prior testing


it allows for
smooth accurate rendering (not noticeable to the human eye).




Ability to add waypoints: the user will have the option to leave markers at certain locations in
space to indicate points of interest.

Implementation:

In this cas
e, the implementation will be shared between the OpenGL and the Form classes.
The command to add a waypoint will come from the Form class, the information
(coordinates) of the position will be stored in an array, and a spherical marker will be
rendered in
OpenGL. The marker will indicate the marker’s coordinates and the number.

The program will by default leave a “Home” marker to represent the quadrotor’s origin. A
button will be available on the main form to return to “Home” position at any time using the
safest path available. A separate button will allow the user to travel to a sele
cted waypoint
(can be selected
in the OpenGL panel).

Form updates will be handled on a separate thread in order to permit the communication link
to function without interruptio
n.




Maintain a communication link with the quadrotor. This software feature will send motion
commands to the quadrotor and receive accelerometer and motor speed data back. The
time
delay between when the user sends a command and when the quadrotor reacts m
ust be at
most 500 ms.

Implementation:

The communication link will occupy its own class (“Communication”) and will reside on the
main thread. All of the other classes will branch from this thread

on start

up
. The link will have
direct contact with the USB
port to which the Bluetooth transceiver module is connected.
Received motor data will be sent to the Form class for updating the plots. The accelerometer data
will be communicated with the Calculations class in order to calculate current speed and
position
. The Communication class will also be responsible for checking and echoing link checks
with the quadrotor periodically.

The following diagrams

describe various required actions, and information flow within the GUI.
For convenience, the following color sc
heme is used:


Figure
4
. Colour scheme


Beginning of Flight


Figure
5
. Initialization of the communication link

In the
instance illustrated in Figure 5
, the software is being initialized to interface with the
quadrotor prior to flight. An echo
request
will be received from the quadrotor
,

and this will
establish the communication link. This path will also be taken in the event of restoration of a lost
com
munication link.


Sending data to the quadrotor


Figure
6
. Sending user input to the quadrotor

When
a

user is entering data
, as shown in
Figure
6
,

motion/direction information will be
constantly sent to the quadrotor until the pressed keys are released. Since the user is able to rotate
the environment in 3D space, the desired direction
s will need to be converted to a standardized
view. For example, if the user rotates the view by 90 degrees and desires for the quadrotor to
move left (from the operator’s point of view), the normalized motion will either be forward or
back depending on wh
ether the rotation was clockwise or counterclockwise.

In certain cases, the user might desire to travel to a previously set waypoint (or the “Home”
waypoint). This event chain is shown
in
Figure
7
. The chain is similar to that for regular
commands, except for the fact that the Calculation class will calculate an entire set of directions
to reach the final destination and send them out in proper order.


Figure
7
. Travel to pre
-
set waypoint event chain

Receiving data from quadrotor

T
he GUI requires feedback from the quadrotor in the form of accelerometer and motor speed
data. The motor data will go towards updating the plots on the GUI, and the a
ccelerometer data
is used to keep track of motion and position.


Figure
8
. Receiving accelerometer and motor speed data

In order to maintain the rendering of the surrounding environment, the quadrotor will also send
obstacle infor
mation to the GUI.
N
o request for this information

is generated by
the GUI


the
application will simply wait for a message with information to arrive. This is done because the
quadrotor system’s priority will be in the communication and control systems, a
nd the obstacle
detection system might not have time to relay all of the information at every time interval.


Figure
9
. Receiving ultrasonic data

Echo requests

Periodically, the GUI will receive an echo request from the communication system on board of
the quadrotor. In this case, there will be a need to process the echo, and to answer it in a set
period of time (otherwise the communication link will be deemed br
oken, and emergency
landing procedures will be initiated).


Figure
10
. Handling Echo requests


User Input

The user input has been described above for when directions need to be sent out. The controller
might also want to add waypoints at certain locations, and this event chain is demonstrated
below. This information is never relayed to the quadrotor, instead i
t is stored until user requests
travel to set waypoint.


Figure
11
. Handling user input

A summary of the overall GUI design (a sketch of the current con
cept) can be found in Appe
ndix
A
.


3
.3
Wireless Com
munication Link


Figure
12
.

Bluetooth High Level Design

The Bluetooth communication link connects the quadrotor and the
user
’s computer through a
wireless channel. The Atmel microcontroller is connected
to the Bluetooth module through a
USART connection which has 1 power pin (3.3V), 1 com
mon ground, Tx (Transmitter
)

line, and
Rx (Receiver
)

line
. On the computer side
,

the Bluetooth USB dongle connects through a USB
2.0 port. The Bluetooth dongle requires

drivers to be installed on the computer which emulates a
serial
communication (COM)

port. Data received by the Bluetooth dongle will be sent to this
emulated COM port, where it can be accessed b
y the GUI
.

Communication between the quadrotor and the comp
uter is fully duplex
.

This

means that data
can be sent from the quadrotor to the computer and from the computer to the quadrotor
simultaneously
. The user will specify commands that need to be sent to the quadrotor
,

such as
moving

left, right, up
,

down, fo
rward

or

backward
s
. However, the GUI will
also
require
information to update the relative position of the 3D rendering and real time graphs of motor
speed. In this case
,

the
data will be sent from the microcontroller back to the GUI.


3
.4 Microcontroller

Lookup Table


The microcontroller will be programmed to receive and transmit data with binary commands
from a command table. Each command will be given a binary instruction code, but currently the
microcontroller look
-
up table describes how these
commands will be used.


Definition of Commands:

Get Motor #X

speed
: The microcontroller sends an unsigned integer through the Bluetooth
module wh
ich represents motor speed in percent.

Go X:

The microcontroller receives an unsigned integer that tells the
quadrotor to move in a
certain
direction.

Get Acceleration:

The microcontroller sends seven unsigned integers through the Bluetooth
module. The first unsigned integer will represent acceleration in the X direction, the second
represents acceleration in the

Y direction, and the third represents acceleration in the Z direction.
The last 4 unsigned integers represent an integer number of 1us intervals that have passed since
the quadrotor started. Keeping track of relative time is important for updating the re
lat
ive
position of the quadrotor

in the GUI.

Get Proximity:

The microcontroller sends an unsigned integer through the Bluetooth module
,

which represents
the
distance from the center of the quadrotor to a detected obstacle (in cm)
.

Get Orientation:

The micr
ocontroller sends a floating point number through the Bluetooth
module which represents
the quadrotor
orientation (in degrees).

Get Time Overflow:

The microcontroller sends an unsigned integer through the Bluetooth
module when the relative time data overfl
ows and needs to be compensated.

Get COM confirmation
:

The microcontroller sends an unsigned integer through the Bluetooth
module which requests confirmation that the wireless link has been established.

COM confirmation
:

The microcontroller receives a conf
irmation from the GUI that data can be
sent through the wireless Bluetooth communication link.

Command Table

Table
1
.

Bluetooth Command Table





Microcontroller



Commands

Description

Send Data

Receive Data

Data format

Get Motor
speed #1

Sends motor speed for graphical application

X



1 Byte unsigned integer

Get Motor speed #2

Sends motor speed for graphical application

X



1 Byte unsigned integer

Get Motor speed #3

Sends motor speed for graphical application

X



1 Byte unsigned

integer

Get Motor speed #4

Sends motor speed for graphical application

X



1 Byte unsigned integer

Go Left

Receives direction



X

--

Go Right

Receives direction


X

--

Go Forward

Receives direction


X

--

Go Back

Receives direction


X

--

Go Up

Receives direction


X

--

Go Down

Receives direction


X

--

Stop

Receives Stop



X

--

Get Acceleration

Sends: Acceleration X Y Z data, Current
relative time data

X



1 Byte unsigned integer








1 Byte unsigned integer








1 Byte unsigned integer









4 Bytes unsigned integer

Get Proximity

Sends Proximity data: Left ,Right, Front,
Back

X



1 Byte unsigned integer








1 Byte unsigned integer








1 Byte unsigned integer









1 Byte unsigned integer

Get Orientation

Sends Orientation
in degrees

X



1 byte scientific

Get Time Overflow

Send if Time counter overflows

X



1 Byte unsigned integer

Get COM confirmation

Send Confirmation that communication is
established


X

1 Byte

COM confirmation

Receive request to confirm communication
is

established

X



--


3
.5

Avoidance Control System


In order to build an obstacle avoidance system for the quadrotor
, it is necessary to have some
way of sensing the surrounding environment in order to detect obstacles. After careful
consideration of the sensors available, the Maxbotix LV
-
EZ1 ultrasonic sensor was selected for
this project. The ultrasonic sensor was cho
sen 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.

Sensor
Functionality

The ultrasonic sensor transmits a sound wave and

evaluates the echo that returns back to the
sensor. The distance to the object can be determined in several ways, but for this project the
voltage of the echo

that

the sensor receives will be used to determine the distance to the obstacle.
This distance m
easurement is quite accurate

assuming

that the angle of reflection from

the object
is not

great
[1]
. As t
he distance increases it is

necessary for the obje
ct to be almost

perpendicular
to the sensor in order for the echo to be received.

Sensor Implementation

There will be four sensors
used

for detecting objects in all directions

and
a

fifth sensor will be
point
ed

down for an accurate altitude measurement. The sensors in th
is configuration should
provide sufficient coverage for obstacle detection as shown in

Figure
13
.




Figure
13
.

Ultrasonic sensor detection spectrum at 35cm.


The four sensors directed outwards from the quadrotor will be coordinated such that the
quadrotor will attempt to maneuver away from
any obstacle that comes within a 50

cm radius of
the quadrotor
. Depend
ing on which sensors detect an obstacle, the obstacle avoidance system
will have pre
-
determined commands that will be sent to the control system to direct the
movement. The diagram showing the layout of
the ultrasonic sensors and their

orientation is
shown

in

Figure
14
.




Figure
14
.

Diagram of directional sensor layout showing there numbering and orientation
with respect to the cardinal coordinate system.


An

overview
of the pre
-
determined direction
s

the quadrotor will move

in

when
the sensors detect
an object is

summarized in
Table
2
. As the quadrotor will not always necessarily be pointing
north, these reference directions are simply used as a starting reference and will be associated
with

certain commands to move the quadrotor in the appropriate direction as if it was always
pointing north. Therefore it will not be a factor if the quadrotor rotates, it will always move in
such a way as to avoid the obstacle. The sensor numbers shown in
Table

2

are associated with
the sensor labeling shown in
Figure
14

with the cardinal reference

system.

Table
2
.

List showing the pre
-
determined direction the quadrotor will fly given cardinal
reference system

Sensor(s) with
Detection

Direction Moved

1

South

2

East

3

North

4

West

1, 2

Southeast

1, 2, 3

East

2, 3

Northeast

2, 3, 4

North

3, 4

Northwest

1, 3, 4

West

1, 4

Southwest

1, 2, 4

South

1, 3

West or East

2, 4

North or South

1, 2, 3, 4

Land


Obstacle Avoidance

The obstacle avoidance system input and output diagram is shown in
Figure
15
. The data
provided by the sensors is analyzed to determine the distance to the nearest obstacle in all
directions. The
distance is

calculated

based on the voltage of the echo that is returned to the
sensor from the object. This distance will then be sent to the
GUI

to provide the user with
updated information on the
surrounding environment
.
If the distance is less than 50cm
,
the pre
-
determined
command associated with the sensor that detected the obstacle

need
s

to be sent to
override the control system to maneuver away from the obstacle.


Figure
15
.

Obstacle avoidance system inputs and outputs diagram.


3
.6

Flight Control System

The purpose of the flight control system is to realize the desired values

of

the roll angle, pitch
angle, yaw angle and vertical velocity of the quadrotor. These desired values are the flight
control sy
stem inputs and will come

from the microcontroller

lookup table. This lookup table
will have predefined control inputs for every type of command that is sent from the
GUI

over the
wireless communication link.

Diagrams defining the roll, pitch and yaw a
ngles can be found in
Append
ix B
.
The control system will realize these inputs by sending appropriate outputs to the
motor speed controllers.
Another purpose of the control system is to provide acceleration data for
position tracking and quadrotor orientation data.

The acceleration d
ata will be sent back over the
wireless communication link to the user interface.

Feedback

For the control system to fulfill its purpose, it must have a way of getting feedback
about the

current quadrotor orientation and accelerations. This data will come
from an inertial
measurement unit

(IMU)
. This unit must have an onboard gyroscope, accelerometer, and
magnetometer. The accelerometer is needed to provide acceleration data for position tracking.
The quadrotor’s roll, pitch, and yaw angles can also be calc
ulated from the acceleration vectors,
however these are prone to error from vibrations in the quadrotor frame. Therefore, the
gyroscope is used to measure the angles as well. However, the gyroscope suffers from drift error
(when the gyroscope does not retu
rn to the original zero point), so the angles calculated from the
accelerometer data can be averaged with the angles given from the gyroscope data to provide the
most accurate measurements. The magne
tometer is similar to a compass; i
t will provide
informat
ion on the quadrotor’s absolute orientation. This will allow the control system to
determine which the way the quadrotor should move when the user is directing it using an
external coordinate system as a reference.

Control Method

Inside the control syste
m, a control method must be chosen which will realize the given control
inputs using the provided feedback. There are many different types of control methods that could
be implemented on a quadrotor.
As
the quadrotor is an under
-
actuated
,

non
-
linear syste
m, non
-
linear control methods can provide the most accurate control

[2]
. Examples of these methods are
non
-
linear H
-
infinity control and back
-
stepping control. However, these methods are very
complex and difficult to implement.

Linear control methods include LQR controllers and PD
(proportional
-
derivative) controllers. For this project, the PD control method was chosen because
it achieves good performance while being very simple to implement. It also uses less
computational pow
er in the microcontrol
ler.

Since the main goal of the project is to develop a
semi
-
autonomous quadrotor and not a more accurate flight control system, the PD controller will
suffice.

The PD control method requires the error between the feedback from the
IMU and desired
control inputs. It calculates the motor speeds based on the error functions and the derivatives of
the error functions. The block diagram of a

PD controller can be seen in
Figure
16
.


Figure
16
.

PD Controller Diagram

Flight Control System Diagram

The entire flight control system can now be represented by the block diagram

shown in
Figure
17
.


Figure
17
.

Flight Control System Block Diagram

4.

Prototypes

4
.1 User Interface


Work has been carried out on the 3D model for the graphical user interface OpenGL panel. This
3D model is a representation of the actual hardware, and serves the purpose of showing the
operator the orientation and position of the vehicle in space.

The mod
el was created in Autodesk Maya 2012 using a variety of available tools. The simple
shapes were made using Boolean manipulations on regular shapes


subtracting one shape from
another, merging shapes, and so on. The propellers were made using bend manipula
tions of a flat
plane made to match the actual propeller in shape.

The current stat
e of the 3D model is shown in
Figure
18
. The model will be converted to the
format
that can be read and imported into the OpenGL frame. The propellers will be rendered in
different colors to match with those used for plots in the GUI.


Figure
18
: User Interface 3D Model Prototype


4
.2
Flight Control System

To va
lidate and verify that the

flight control system can achieve the desired control inputs, a
simulation was made in Simulink. This required some detailed design steps which will not be
explained in depth in this high level design report, but the model can be

seen in the Simulink
bloc
k diagram in
Figure
19
.


Figure
19
.

Simulink Prototype of Flight Control System

The simulation shows that with the proper control gains, this control scheme is stable and can
achieve the desired inputs. Example outputs of the simulation
are shown in
Figure
20

for control
inputs: roll angle=0, pitch angle=0.5 radians, yaw angle=0, vertical velocity=0.


Figure
20
. Simulunk Simulation Outputs

5.

Bill of Materials

Table
3
.

Bill of Materials



6.

Appendix
A


Figure
21
. Current state of the GUI design

7.

Appendix
B


Figure
22
. Roll, pitch and yaw angle diagrams

8.

Glossary

Accelerometer:

A device used to determine acceleration in the X, Y, Z directions.

Bluetooth


W
ireless communication standard for short
-
range data transmission

Bluetooth USB dongle:

A USB device that connects to a computer and allows wireless
communicatio
n through an emulated serial communication

port.

COM:

Short form of

“communication”
.

GUI


Graphical User Interface:

An interface that allows users to interact with the device (send
commands) using im
ages, rather than text commands

(
such as those used in the Command
Prompt
)
.

Gyroscope:

A mechanical device that determines angular position in 3D s
pace using angular
moment.

I
2
C

-

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
.

IMU

-

Inertial Measurement Unit
:

An onboard unit that uses accelerometers, gyroscopes and
magnetometers to measure the orientation and acceleration of a moving vehicle.

LiPo
:

Lithium polymer battery: rechargeable batteries.

LQR

-

Linear Quadratic Regulator control
: A linear control metho
d based on optimizing a
certain quantity
.

OpenGL


Open Graphics Library:

Multiplatform graphics application programming interface. It
allows for visualization of 3D spaces in virtual reality applications, visualization
, flight
simulation and video ga
mes.

PD

-

Proportional Derivative control
:

A linear control method with control outputs based on the
error between the desired control inputs and actual feedback and the derivative of this error
.

Receiver line:

The line from the USART that received binary data.

Transmitter line:

The line from the USART that transmits binary data.

Ultrasonic sensor:

A sensor that sends an ultrasonic sound wave and waits for the reflected wave
to return
in order
to measure proximity.

USART

-

Universal Serial Asynchro
nous Receiver/
Transmitter
:

A

protocol used for wired serial
communication between two devices.

USB


Universal Serial B
us:

A type of connection (both physical and logical) between an
external electronic device and a computer. Th
is can be used to exchange data

and power
the
external device.

3D


Three dimensional space:
Geometric representation of an object using a three
-
parameter
model of the physical universe. The parameters are typically either [x, y, z] (Cartesian space) or
[width, length, height].


9.

References


[1]

Y. K. Johann Borenstein, "Obstacle Avoidance with Ultrasonic Sensors,"
IEEE Journal of
Robotics and Automation Vol 4,
pp. 213
-
218, 1988.

[2]

G. Raffo, "An Integral Predictive/Nonlinear H
-
infinity control Structure for Quadrotor,"
Uni
versidad de Sevilla, Sevilla, 2010.