Department of Electrical and Computer Engineering
Schulich School of Engineering
University of Calgary
Fall 2012
4th Year Project Report #2
Preliminary Design Document
Group # 23
Team UFO
Quadrotor
Group Members:
Sponsor’s Name:
Mila Gorobets
Thomas Beulah
Michael Himmelfarb
Patrick Beasley
Microlynx Systems Ltd
Dec 3, 2012
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, whose lift is generated by four equally spaced rotors.
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 capacity of the quadrotor to carry sensors.
The designed quadrotor must have an operator-vehicle range of at least 10 meters, 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 for 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 using 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-show
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 unmanned 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 implementation, 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.
SENSOR DATA
ULTRASONIC SENSOR DATA
AVOIDANCE
CONTROL
USER COMMANDS
USER COMMANDS
GRAPHICAL
USER INTERFACE
WIRELESS
COMMUNICATION LINK
UPDATE COMMANDS
UPDATE COMMANDS
MICROCONTROLLER
LOOKUP TABLE
USER INPUT
OBSTACLE AVOIDANCE COMMANDS
TOP LEVEL DIAGRAM
ACCELEROMETER VALUES
MOTOR SPEEDS VALUES
FLIGHT
CONTROL
SYSTEM
USER COMMANDS
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 motors 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 connected to the microcontroller using a USART
(Universal Serial Asynchronous Receiver/Transmitter) serial interface. Software on the
microcontroller side will receive information from the user and adapt motor speeds 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 direction, and others.
2.4 Obstacle Avoidance Control
Ultrasonic sensors will be used to determine the proximity of objects near the quadrotor. These
sensors will communicate with the microcontroller through an I2C (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 method for this project is Top-Down Design. From the system level
architecture, the design of the semi-autonomous quadrotor consists of four modules which
communicate with each other. These modules are the user interface, 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 the quadrotor’s status, and provides a way for
the user to input desired 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 be transferred by the wireless communication link. A microcontroller
lookup table deciphers binary commands from the wireless link. The user interface sends motion
commands that are specified by the user to the flight control system. The flight control receives
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 the 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 requires physical hardware which is shown in the 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 designed. 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 the 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 microcontroller 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
environment, and monitoring key components of the system. The proposed solution 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 “Main
Features” section. The general design diagram of the GUI and its interfaces is shown in Figure 3.
INPUTS
UPDATE
COMMANDS
OUTPUTS
Lookup Table
Quadrotor
starts up
Accelerometer
data arrives
3D model updated
Speed data
arrives
Plots updated
Ultrasonic
sensor data
arrives
USER
COMMANDS
3D model updated
Echo request
received
USER INPUT
User requests
travel to
waypoint
User adds
waypoint
Update Form and 3D
model
User presses
key
User releases
key
Figure 3. Graphical 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 decrease it if
needed for lower resolution screens.

3D model of the quadrotor in the surrounding environment: the user 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 extensive 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 explained 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 case, 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 selected 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 interruption.

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 must 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 scheme is used:
COMMUNICATION
COMMUNICATION
CLASS
CLASS
OPENGL
OPENGL CLASS
CLASS
FORM
FORM CLASS
CLASS
CALCULATIONS
CALCULATIONS
CLASS
CLASS
Figure 4. Colour scheme
Beginning of Flight
Quadrotor starts up
Establish
Establish
communication
communication link
link
Update
communication
light in UI
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
communication link.
Sending data to the quadrotor
User presses key
Convert user view
to normalized
directions
User releases key
Send
Send command
command to
to
stop
stop
Send
Send commands
commands to
to
quadrotor
quadrotor
Wait
Wait for
for response
response
with
accelerometer
with accelerometer
and
and speed
speed data
data
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 directions 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 whether 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.
User requests travel
to waypoint
Calculate directions
from current
position to
waypoint
Send
Send commands
commands to
to
quadrotor
quadrotor
Wait
Wait for
for response
response
with
accelerometer
with accelerometer
and
and speed
speed data
data
Figure 7. Travel to pre-set waypoint event chain
Receiving data from quadrotor
The 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 accelerometer data
is used to keep track of motion and position.
Accelerometer data
arrives
Calculate
Calculate current
current
position
position and
and
orientation
orientation in
in space
space
Speed data arrives
Update motor plots
Update OpenGL
struct
Update OpenGL
model (10 ms
intervals)
Figure 8. Receiving accelerometer and motor speed data
In order to maintain the rendering of the surrounding environment, the quadrotor will also send
obstacle information to the GUI. No 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, and the obstacle
detection system might not have time to relay all of the information at every time interval.
Ultrasonic sensor
data arrives
Calculate new
rendering of
surroundings
Update the
surroundings struct
Update OpenGL
model (10 ms
intervals)
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 broken, and emergency
landing procedures will be initiated).
Echo request
received
Return
Return echo
echo to
to
quadrotor
quadrotor
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 it is stored until user requests
travel to set waypoint.
User adds waypoint
Store (x,y,z) and
increment waypoint
count
Add entry into
OpenGL waypoint
struct
Update OpenGL
model (10 ms
intervals)
Figure 11. Handling user input
A summary of the overall GUI design (a sketch of the current concept) can be found in Appendix
A.
3.3 Wireless Communication Link
BLUETOOTH HIGH LEVEL DESIGN
OUTPUTS
INPUT
Wireless
Channel
USER
COMMANDS
USART
Communication
User
Commands
USB Bluetooth
Wireless Dongle
OUTPUTS
USER
COMMANDS
User
Commands
Bluetooth Wireless
Module
Update
Commands
UPDATE
COMMANDS
Update
Commands
INPUT
UPDATE
COMMANDS
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 common 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 by the GUI.
Communication between the quadrotor and the computer 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, forward or backwards.
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 which 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 relative
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 microcontroller 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 overflows 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 confirmation 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
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
Data format
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
COM confirmation
Send Confirmation that communication is
established
Receive request to confirm communication
is established
3.5 Avoidance Control System
X
X
1 Byte
--
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 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.
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 measurement is quite accurate assuming that the angle of reflection from the object
is not great [1]. As the distance increases it is necessary for the object 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
pointed down for an accurate altitude measurement. The sensors in this 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. Depending 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 directions 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
1
2
Direction Moved
South
East
3
4
1, 2
1, 2, 3
2, 3
2, 3, 4
3, 4
1, 3, 4
1, 4
1, 2, 4
1, 3
2, 4
1, 2, 3, 4
North
West
Southeast
East
Northeast
North
Northwest
West
Southwest
South
West or East
North or South
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 predetermined command associated with the sensor that detected the obstacle needs 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 system 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 angles can be found in
Appendix 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 data 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 calculated 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 return 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 magnetometer is similar to a compass; it will provide
information 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 system, 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 system, nonlinear 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 power in the microcontroller. 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 model 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 manipulations of a flat
plane made to match the actual propeller in shape.
The current state 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 validate 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
block 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
Part #
Description
Maxbotix LV-MaxSonar-EZ1
MB1010
Sonar Rangefinder
MinIMU-9 v2 Gyro,
Accelerometer, and Compass
MinIMU-9 v2
IMU
Turnigy 1811 brushless Outrunner
T1811-2900/8142
2900kv
Turnigy 6A electronic speed
TR-6A/4318
controller
Turnigy Integrated PCB Micro9332000001/22607
Quad (KIT)
5030 Propellers (Black) - 3xCW
9332000002/22753
and 3xCCW
Turnigy balancer & Charger 2STurnigy-3S/7637
3S
Turnigy 2S 35-40C 850mAh
N850.2S.25
nanotech LiPo
AT32UC3A3-XPLD
AT32UC3A3-XPLD- microprocessor development
ND
board
Good Quality 3.3VDC 30ft
Wireless Bluetooth RF
Transceiver Module Card RS232
TTL
Mini USB 2.0 Bluetooth Adapter
Dongle for PC Laptop
ManufacturerSupplier
Quantity Unit Price Cost
Maxbotix
Pololu
5
$24.95
$124.75
Pololu
Pololu
1
$49.95
$49.95
Turnigy
HobbyKing
5
$9.72
$48.60
Turnigy
HobbyKing
5
$6.56
$32.80
Turnigy
HobbyKing
1
$14.99
$14.99
HobbyKing
2
$3.45
$6.90
Turnigy
HobbyKing
1
$4.49
$4.49
Turnigy
HobbyKing
1
$5.99
$5.99
Atmel
digikey
2
$31.98
$63.96
Ebay
2
$6.09
$12.18
Ebay
2
$1.60
TOTAL
$3.20
$367.81
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 – Wireless communication standard for short-range data transmission
Bluetooth USB dongle: A USB device that connects to a computer and allows wireless
communication 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 images, rather than text commands (such as those used in the Command
Prompt).
Gyroscope: A mechanical device that determines angular position in 3D space using angular
moment.
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.
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 method 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 games.
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 Asynchronous Receiver/Transmitter: A protocol used for wired serial
communication between two devices.
USB – Universal Serial Bus: A type of connection (both physical and logical) between an
external electronic device and a computer. This 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,"
Universidad de Sevilla, Sevilla, 2010.