Autonomous Quadrotor Report #2
Electrical Engineering Fourth Year Design Project
2012-2013
Team #23
Mila Gorobets
Michael Himmelfarb
Thomas Beulah
Patrick Beasley
Industry sponsor: Microlynx Systems Ltd.
1
Table of Contents 1. Introduction ........................................................................................................................................................... 3
1.1 Summary of the project ............................................................................................................................. 3
1.2 Motivations ..................................................................................................................................................... 3
1.3 Economical aspects ...................................................................................................................................... 4
2. Low Level Design ................................................................................................................................................. 5
2.1 Microcontroller ............................................................................................................................................. 5
2.2 Graphical User Interface ............................................................................................................................ 6
2.2.1 Overview ................................................................................................................................................. 6
2.2.2 Main Thread Operation and Functions ...................................................................................... 6
2.2.3 GUI Design and Functions ............................................................................................................ 11
2.3 Wireless Communication Link ............................................................................................................. 12
2.4 Flight Control System .............................................................................................................................. 14
2.4.1 Overview .............................................................................................................................................. 14
2.4.2 PID Controller .................................................................................................................................... 16
2.4.3 Feedback .............................................................................................................................................. 18
2.4.4 Implementation ................................................................................................................................ 18
2.5 Avoidance Control System ..................................................................................................................... 19
2.5.1 Overview .............................................................................................................................................. 19
2.5.2 Implementation ................................................................................................................................ 19
3. Product Design Specifications ..................................................................................................................... 20
3.1 Expected performances .......................................................................................................................... 20
3.2 Specifications related to performance .............................................................................................. 20
4. Testing and Refinement ................................................................................................................................. 21
4.1 Graphical User Interface ......................................................................................................................... 21
4.1.1 Testing successful transmission of commands .................................................................... 21
4.1.2 Testing successful decoding of received commands ......................................................... 23
4.2 Wireless Communication Link ............................................................................................................. 24
4.2.1 Bluetooth Transmission Distance ............................................................................................. 24
4.2.2 Successful Command Transmission Rate ............................................................................... 24
4.3 Flight Control System .............................................................................................................................. 24
2
4.3.1 Test Setup ............................................................................................................................................ 25
4.3.2 Inertial Measurement Unit Test ................................................................................................. 26
4.3.3 Control System Test ........................................................................................................................ 26
4.4 Avoidance Control System ..................................................................................................................... 27
4.4.1 Obstacle Detection Test ................................................................................................................. 27
5. Suggestions for Further Improvements .................................................................................................. 27
5.1 Major Challenges in this Project .......................................................................................................... 27
5.2 Learning through this Project .............................................................................................................. 27
5.3 Suggestions for further improvements ............................................................................................ 28
6. Conclusions.......................................................................................................................................................... 28
7. References ............................................................................................................................................................ 29
8. Glossary ................................................................................................................................................................. 30
9. Appendices .......................................................................................................................................................... 32
9.1 Appendix 1 ................................................................................................................................................... 32
9.2 Appendix 2 ................................................................................................................................................... 33
3
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.
4
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
5
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. Low Level Design
2.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
for PWM controllers to output to each motor
controller on the quadrotor
GPIO 60+ (far more than required)
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 Atmel’s
AVR Studio 6. This program includes a C compiler for this microcontroller and has many
6
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.
2.2 Graphical User Interface
2.2.1 Overview
The graphical user interface was designed using Visual Studio C++/CLI and has the
following features:
The user can give motion directions to the quadrotor by either entering pitch, roll
and yaw values manually, or pressing arrow keys on the keyboard.
o Using arrow keys sends a predefined value to the quadrotor instead of doing
cartesian – to roll/pitch/yaw conversions.
Motor speeds are plotted.
Accelerometer readings are acknowledged, and the rendering mimics the model’s
orientation in space.
Surroundings are rendered in 3D space and the distance to them is indicated.
Distance to floor and ceiling are also shown in the rendered panel.
The original plan was to have the GUI run on three separate threads to control the
communication functions and prevent lag. However, after some research it was discovered
that Microsoft has already implemented a class (SerialPort) that does exactly this – the
event triggers in the main thread, but all processing goes on in another one. The downside
of using this method is that we are constrained to using the first 9 COM ports available on
the computer (COM1-COM10), while the Bluetooth dongle often tries to assign COM port
numbers of over 20.
2.2.2 Main Thread Operation and Functions
The main thread maintains control over the form elements, captures user inputs from
keyboard, performs calculations, initializes the communication link, and processes received
data and displays it. This thread starts the program when QUI.exe is run. The main thread
spans over several namespaces and a collection of functions:
Modelspace::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.
The 3D models for the quadrotor frame and propellers are
available as high resolution and low resolution (1/26th of
the high resolution). As the quadrotor is a small rendering,
we used the low resolution model for faster rendering.
+<<constructor>> Model() : void
+<<destructor>> ~Model() : void
+loadModel(char *mFilename)() : int
+draw() : void
+Model_init() : void
-^ triangles : array<Triangle>
-^ normals : array<Normal>
-^ vertices : array<Vertex>
-triangleCount : int
-verticesCount : int
-normalCount : int
Model
Figure 1: Model Class Diagram
7
OpenGLForm::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.
Renders obstacles as rectangles instead of 3D models to
speed up execution.
QUI::Form1
Maintains the Windows Form.
Receives user input from keyboard and Form
elements.
Initializes and terminates the serial port.
Updates the motor speed plots.
Refreshes the OpenGL rendering every 40ms.
Processes received data every 40ms.
The main thread does not run on a superloop, instead allowing other processes to take time
executing, and performing UI updates and data processing at specific timer intervals.
Keyboard input and form button presses are responded to using event functions. The
processes are described in the subsections that follow.
Bluetooth communication via Serial Port
The original plan for communication was to establish separate threads to prevent
interference between the responsiveness of the main thread and communication via the
COM port. However, it was discovered that there exists a pre-defined class specifically made
for serial communication that runs on a separate thread, thus fulfilling our requirements
quite well. The diagrams in Figure 4 show processes for starting and terminating the
communication link.
+<<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
+f_one : QUI::Form1^
+quadrotor : ModelSpace::Model^
+prop : ModelSpace::Model^
-m_hDC : HDC
-m_hglrc : HGLRC
COpenGL
Figure 2: COpenGL Class Diagram
Figure 3: Form1 Class Diagram
8
The code snippets in Figure 5 show opening the COM port, closing it, and using the circular
buffer to manage data cross thread.
Communication
link started
Open specified COM
port at 9600 baud
Communication
link terminated
Release allocated
resourcesClose COM port
Turn
communication
indicator green
Turn
communication
indicator red
this->spComPort->Open(); // Open COM Port
this->pCommLink->BackColor = System::Drawing::Color::Green; // Set indicator to
green
String ^ commandstring = gcnew String ("COM Port opened. \n"); // Tell the user
this -> txtMessages -> AppendText(commandstring);
delete commandstring; // Release resources
rx_current = displaythis; // Set up the circular buffer
rx_start = displaythis;
rx_end = &displaythis[200*SINGLE_COMMAND_LENGTH];
rx_new = rx_current;
this->spComPort->Close(); // Close COM Port
this->pCommLink->BackColor = System::Drawing::Color::Red; // Set indicator to red
String ^ commandstring = gcnew String ("COM Port closed. \n"); // Tell the user
this -> txtMessages -> AppendText(commandstring);
delete commandstring; // Release string resources
// Check if multiple of 15 bytes (one command) arrived together
int length = this->spComPort->BytesToRead;
if (!(length % 15)){
String ^ indata = this->spComPort->ReadExisting(); // Read data in
datacounter = length; // Counter for main thread to work with
for (int k = 0; k < length; k++)
{
*(rx_current++) = indata[k]; // Keep track of circular buffer pointers
if (rx_current>rx_end){
rx_current = rx_start;
}
}
this->spComPort -> DiscardInBuffer();
}
Figure 4: Communication Processes
Figure 5: Code showing COM port opening, closing and circular buffer use
9
The received data is placed in a circular buffer when it arrives at the COM port. The basic
structure of this is shown in Figure 6.
[0] [1] [2] [3] [4] [5] [6] [7] ... ... ... [N-m] ... [N-3] [N-2] [N-1]
pStart pRead pNew pEnd
Figure 6: Circular Buffer Implementation
The pointer pStart points to the beginning of the array, pEnd always points to the end of the
array, pRead points to the start of the data that has not been processed yet, and pNew is
where the next arriving data is written to.
The pNew pointer loops around the end of the array and moves to pStart when the circular
buffer is filled up. pRead behaves the same way, but is controlled by the processing function.
All data is processed when pRead equals to pNew (when they point to the same address in
memory).
Processing received data
When data arrives at the serial port, as shown in Figure 7, it gets split into three different
sections: motor speeds, pitch/roll/yaw data (which is used to tilt the quadrotor in the
rendering), and the obstacle info.
The actual protocol for transmitting this data is described in depth in the Bluetooth
Communication section of this report. Since we know in advance how all data is going to
arrive (it arrives in a single string), we simply sequentially dismantle the received data and
extract information out of it.
Data has arrived at
serial port
Extract motor
speeds, ultrasonic
data, and roll/pitch/
yaw
Update tilt in
rendering
Update obstacle
locations
Append to motor
speed plots
Display
acknowledgement in
Messages window
Figure 7: Processing Received Data
10
The code snippets in Figure 8 show the code for updating the motor speed plots.
Once the obstacle data is extracted, it is put into global variables. Every 40 ms, the OpenGL
rendering gets refreshed and uses the new obstacle position data then. The obstacles are
rendered as sheets and the code in Figure 9 is for one of the obstacle detection sheets.
The tilt is rendered in the same function as the obstacles. It simply rotates the entire
coordinate system prior to rendering, returning the view to its original state afterwards.
The messages are strings formed out of various bits of information arriving from the
microcontroller, and these get appended to the Message Box in the GUI. There exists an
option to clear the Message Box or save its contents.
Sending user-specified 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 10. This is the method of choice when debugging and testing. A button is
available to quickly set the quadrotor back to hover configuration.
clock_t t;
t = clock(); // Get current clock value
double currenttime = ((double)t - starttime)/CLOCKS_PER_SEC; // Find dt
// Add new points to all graphs
this->chMotor1->Series["Series1"]->Points->AddXY(currenttime, motor1_rx);
this->chMotor2->Series["Series1"]->Points->AddXY(currenttime, motor2_rx);
this->chMotor3->Series["Series1"]->Points->AddXY(currenttime, motor3_rx);
this->chMotor4->Series["Series1"]->Points->AddXY(currenttime, motor4_rx);
// Render boxes for obstacles
// Front
glPushMatrix();
glColor3f(0,0,1); // Set color
glTranslatef(0, 0, -1.0f*us_ahead); // Use position
glBegin(GL_QUADS); // Draw A Quad
glVertex3f(-10.0f, 10.0f, 0.0f); // Top Left
glVertex3f( 10.0f, 10.0f, 0.0f); // Top Right
glVertex3f( 10.0f,-10.0f, 0.0f); // Bottom Right
glVertex3f(-10.0f,-10.0f, 0.0f); // Bottom Left
glEnd();
glPopMatrix();
Figure 8: Code showing updates to the motor speed plots
Figure 9: Code for updating the obstacle detection sheets
11
The second option is to use the arrow keys on the keyboard to input pre-defined commands
for travel into certain directions as shown in Figure 11. The command stays valid until user
releases the key.
2.2.3 GUI Design and Functions
The current GUI design shown in Figure 12 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 about 50 ms
– refresh capabilities depend on the computer used). 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 rendered around the quadrotor as
rectangular sheets. Distances to those objects are also displayed on top of the
OpenGL panel – floor and ceiling are among these values even though they do not
have sheets rendered.
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 pre-defined roll, pitch, yaw
and z values.
User has pressed
keyboard arrow
Convert to proper
command (string)
Assemble
command into a
string
Output to serial
port
Read out
predetermined roll/
pitch/yaw values
User has released
keyboard arrow
Convert to proper
command (string)
Assemble
command into a
string
Output to serial
port
Set roll/pitch/yaw/z to
hover configuration
User is holding a
keyboard arrow
down
No action is taken.
Wait until release
Figure 11: Handling User Data (Keyboard Entry)
User has entered
directions
Extract data out of
textboxes
Assemble
command into a
string
Output to serial
port
Figure 10: Handling User Data (Numerical Entry)
12
The “Messages” window displays relevant information, error messages, warnings
and counts the number of commands received (can be disabled). The window can be
cleared using the “Clear” button right underneath it.
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.
2.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
USART 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.
Figure 12: Final Design of the GUI
13
Table 4: COM port communication specifications
Baud Rate 9600
Parity None
Number of Stop Bits 1
Flow Control Off
The microcontroller USART port will be configured to the same settings as the USART
configuration with the USART 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. A continuous string will be
sent to and from the quadrotor to the computer control program. The command string that
is sent to the computer control program from the quadrotor includes motor speeds,
measured roll, measured pitch, measured, yaw, and obstacle sensor information and is
shown in Table 5. String commands that are sent to the quadrotor include movement
controls such as roll, pitch, yaw and height and are shown in Table 6. The quadrotor
communication link will interrupt the microcontroller when data receives a single byte,
then saves the data and continues operation. This is an improvement to our previous
method because the microcontroller used to wait for the entire string of data to be received
and prevented any other computations to occur during this time. 60bits/(9600bits/s) =
6.25ms which at 66MHz wastes 412500 cycles of the processor. The Sign Byte is used to
represent the direction of the roll, pitch, yaw and height data and the breakdown is shown
in Table 7.
Table 5: Quadrotor’s Sent Data
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Start
Character
Sign
Byte
Motor
1
Motor
2
Motor
3
Motor
4 Roll Pitch Yaw Front Back Left Right Up Down
Table 6: Quadrotor’s Received Data
1 2 3 4 5 6
Start Character Sign Byte Roll Pitch Yaw Height
Table 7: Sign Byte Configuration
Bit Address 7 6 5 4 3 2 1 0
Sign Byte 0 0 0 0 0 roll sign pitch sign yaw sign
14
The type of values expected for the data for sending and receiving data from the quadrotor
are:
Roll, pitch and yaw bytes are represented by integer values from 0- 180 degrees
Motor speeds are represented by integer values between 0-100%
Sensor values (for front, back, and left, right, up and down) are represented by
integer values in dm (decimeter) from 0-256 dm
2.4 Flight Control System
2.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 [2]. 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 13. A block
diagram of the control system inputs and outputs is shown in Figure 14.
15
Figure 13: Motor Layout
OUTPUTSINPUTS
Calculate feedback: θroll, θpitch, θyaw, z
PID Controller
Calculate acceleration
valuesAcceleration values
FLIGHT CONTROL
SYSTEM
Inertial
Measurement
Sensor
M1
θdes_pitch
θdes_yaw
zdes
M2
M3
M4
θdes_roll
Gyro, Accelerometer Data
Ultrasonic
Rangefinder
Height Data
Feedback
Figure 14: Flight Control Block Diagram
16
2.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 15 for
the pitch angle. Each loop is similar to the one shown in Figure 15, with an exception for the
height loop, which includes a constant to cancel out the constant pull of gravity on the
quadrotor.
Figure 15: Control Loop Example
17
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 used in the physical model of the
Simulink simulation are approximate and further tuning of control gains was performed
using a trial and error testing method with the quadrotor prototype.
18
2.4.3 Feedback
The roll feedback angle was calculated from the output of the Inertial Measurement Unit’s
gryoscope as follows:
In the above formula, gyroValue was the number received via the I2C bus for the particular
axis of the gyroscope, and GYROgain is a constant in radians per second obtained using the
sensitivity value on the Inertial Measurement Unit’s datasheet.
The below formula was used to calculate the roll angle due to the accelerometer output.
where Gy is acceleration in the direction of the y-axis (measured by the accelerometer),
Gx is acceleration in the direction of the x-axis, and Gz is acceleration in the direction of the
z-axis.
Next the values were weighted together using a complimentary filter:
where TRUST is a factor between 0 and 1 and represents the amount of trust given to
accelerometer value over the gyroscope. The weighting allows us to minimize the effects of
drift from the gyroscope, and noise of the accelerometer. From several tests, a value of 0.02
was chosen for the TRUST factor.
The pitch angle is calculated in the same fashion as roll. The yaw angle only uses the
gyroscope (as the accelerometer cannot detect spinning around the z axis).
2.4.4 Implementation
The control system designed in the Simulink model was implemented using C code on the
microcontroller. The integration was implemented using the trapezoid method. The
derivative term was taken over 4 points (approximately 40 ms) to smooth out derivative
term. The control loops run at approximately 100 Hz.
Code was written to output a pulse width modulated signal from the microcontroller board
to the electronic speed controllers. The pulse width varies between 1 and 2ms to represent
the commanded motor speed.
The Inertial Measurement Unit used is MinIMU-9 v2 available from Pololu Robotics and
Electronics. This unit interfaces with the microcontroller using I2C protocol.
19
2.5 Avoidance Control System
2.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 [4]. 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.
2.5.2 Implementation
There will be four directional sensors mounted below the propellers 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 16.
Figure 16: Four directional ultrasonic sensor detection spectrum 35 cm from an obstacle
The obstacle avoidance system input and output diagram is shown in Figure 17. 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.
Figure 17: Obstacle avoidance system inputs and outputs diagram
20
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. This last portion for the actual obstacle avoidance has not been implemented,
although it is not a challenge as communication with the GUI has already been established.
3. Product Design Specifications
3.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.
3.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
21
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 %
Detect obstacles within a 50 cm radius with a success rate of 60 %
4. Testing and Refinement
4.1 Graphical User Interface
4.1.1 Testing successful transmission of commands
Keyboard input
The keyboard keys are currently tied to pre-determined directional commands, as
described in the relevant design section. In order to test this, the tests shown in Table 8
were performed.
Table 8: Keyboard input testing
Action Duration (seconds) Success/Failure
Left button pressed (‘A’ key) 3 Success
Right button pressed (‘D’ key) 3 Success
Forward button pressed (‘E’ key) 3 Success
Back button pressed (‘Q’ key) 3 Success
Up button pressed (‘W’ key) 3 Success
Down button pressed (‘S’ key) 3 Success
Left button pressed (‘A’ key) 2 Success
Right button pressed (‘D’ key) 2 Success
Forward button pressed (‘E’ key) 2 Success
Back button pressed (‘Q’ key) 2 Success
Up button pressed (‘W’ key) 2 Success
Down button pressed (‘S’ key) 2 Success
Left button pressed (‘A’ key) 1 Success
Right button pressed (‘D’ key) 1 Success
Forward button pressed (‘E’ key) 1 Success
Back button pressed (‘Q’ key) 1 Success
Up button pressed (‘W’ key) 1 Success
Down button pressed (‘S’ key) 1 Success
22
For testing purposes only, the transmitted code
corresponded to the key (so for “Left”, a string of
“A”s was transmitted). These were received by
an Android phone connected to the Bluetooth. A
screenshot is shown in Figure 18 which was
taken during the 3 second test. The strings of
letters correspond to every key available for
issuing commands. The single “A” (actually A
followed by zeros to indicate hovering flat) is
sent when the key is released. All of the
commands were sent as desired making this test
a complete success.
Numerical Input
The numerical input test results are shown in Table 9 with a 100% success rate.
Table 9: Numerical input test results
Test # Roll Pitch Yaw Z Success/Failure
1 -65 -65 -65 -65 Success
2 66 -66 -66 -66 Success
3 -43 43 -43 -43 Success
4 -69 -69 -69 -69 Success
5 35 -35 35 35 Success
6 33 -33 33 33 Success 7 38 -38 38 38 Success
8 98 -98 98 98 Success
9 69 69 -69 69 Success
10 56 56 -56 56 Success
11 71 71 -71 71 Success
12 42 42 42 42 Success
An explained screenshot for the test is shown in Figure 19. In a lot of cases we might note
that only 5 characters appear to have been received – however, that is deceiving. In reality,
the 6th character is in the ASCII range of 0 to 7, so it might not visually show up in a terminal
program.
Figure 18: Screenshot of transmitted code
23
Figure 19: Screenshot of numerical test output
4.1.2 Testing successful decoding of received commands
In addition to performing testing of successful command transmission from the user to the
quadrotor, we also tested the ability of the GUI to receive and process data. This test was done
in the following fashion:
1. The microcontroller (quadrotor) sent out 100 commands, spaced by 20 ms, through
the Bluetooth link.
2. The GUI was responsible for receiving the commands and keeping track of the
number that have been processed, as well as display the results.
We are proud to say that the GUI was able to receive and process all 100 commands send for
the majority of the trails. In rare cases, the success rate was decreased to 99% (99/100
commands received successfully). A screenshot was taken from the GUI after this test and is
shown in Figure 20.
Figure 20: Screenshot of GUI output of received commands
24
4.2 Wireless Communication Link
4.2.1 Bluetooth Transmission Distance
The purpose of this test was to ensure the Bluetooth communication link was able to work
within a 5m radius to avoid losing communication with the operator. After testing we found
that there was clear and reliable transmission (data we typed in by hand was received and
re-transmitted back to our terminal program for us to observe) of data at 10 m, exceeding
the 5 m requirement. We also tested the communication link at 15 m through a windowed
wall, however at this far of a distance there was a noticeable lag in transmission and some
of the data was lost due to a limited buffer. The test results are shown in Table 10. This test
was able to verify that the Bluetooth communication link would work well within a 5-10m
clear path of the operator.
Table 10: Bluetooth communication transmission distance
Distance (meters) Success/Failure
5 Success
10 Success
15 Partial Success
4.2.2 Successful Command Transmission Rate
The purpose of this test was 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. The maximum data rate that can be used with our current settings is 9600
commands/second. We sent 115,200 ‘A’ characters with a test program through the
Bluetooth link at a distance of 5 m. If communication was being transmitted at the ideal
rate of 9600 bits/s then transmission will last 2 minutes. In our test it, the terminal program
RealTerm took 2 minutes and 1 second to record all 115200 characters. A small amount of
error would be due to starting and stopping the stop clock by hand for timing the test. This
was an excellent result, as it showed that the data would be transferred between the
operator and the development board at the maximum rate with no commands lost. It was
also determined from this test that even within a 10 m radius there is a high probability that
all operator commands would be received by the development board.
4.3 Flight Control System Flight control system testing was not performed using the method specified in Report #1 as
problems with the quadrotor motors arose. The motors on the quadrotor were not
responding correctly to the control systems output. Though many hours were spent
troubleshooting the issue, the problem remains unresolved at this time.
Though live tests were not able to be performed, tests were performed to ensure that both
the control system code and the Inertial Measurement Unit were operating correctly.
25
4.3.1 Test Setup
The test setup used for testing restricted the rotation of the quadrotor to one axis only (the
roll axis) is shown in Figure 21. A protractor was attached to the setup to read the actual
roll angle of quadrotor and is shown in Figure 22.
Figure 21: Test setup configuration restricting motion to one axis
Figure 22: Test setup configuration showing angle measurement setup
26
4.3.2 Inertial Measurement Unit Test
In this test we saved values of our calculated gyroscope and accelerometer values into the
memory of our microcontroller to investigate how our control system was responding to
angle changes.
The values were also measured using a protractor attached to the axis of the setup, while
the quadrotor was disturbed to a specific value. The value measured by the gyroscope was
within 2o of the value seen on the protractor and is shown in Figure 23.
Figure 23: Inertial Measurement Unit Test results
4.3.3 Control System Test
The test was performed in debug mode, where we were able to read the values and plot
them in Excel to produce a time measurement of the angle and the relevant motor speeds.
In this graph we examined roll and the two opposing motors (motors 2 and 4) that control
the roll of our quadrotor. The setup only allows freedom of motion around the roll axis, and
all other movements are negligible. This test demonstrated the control system’s response
to external disturbances while trying to achieve a roll angle of zero degrees. The quadrotor
was moved to a roll angle of 35 degrees and then shortly after to negative 30 degrees. The
control system gains used are shown in Table 11.
Table 11: Control System gains used for testing
Control Gain
Kintegral 2
Kproportional 20
Kderivative -0.01
-50
-40
-30
-20
-10
0
10
20
0 500 1000 1500 2000 2500
Degrees
Inertial Measurement Unit Test
Roll_Accelerometer
Roll_Gyroscope
27
These control gains only describe the motion depicted in the graph and will likely not result
in stable hovering. However we see the dominating effects of proportional and integral
gains. When the quadrotor rolls into the positive direction, Motor 4 increases and Motor 2
decreases in an attempt to return the value of roll to 0. While the roll is held steady at a
position other than 0o it is visible that Motor 4 speed increased further with time and Motor
2 decreased while trying to decrease error in roll.
The same test was performed on the pitch axis giving similar results.
4.4 Avoidance Control System
4.4.1 Obstacle Detection Test
The purpose of this test was to determine if the quadrotor’s ultrasonic sensors could detect
obstacles within 50 cm of it with a success rate of 60 %. A function was written which took
the data from the ultrasonic sensors and illuminated an LED if the detected distance was
less than 50 cm. An obstacle was then brought in front of the sensor near the threshold
distance to see if the LED would illuminate appropriately. This process was carried out for
each ADC channel with the six ultrasonic sensors to ensure all of them were operational and
operating as predicted. The result was that the sensors were very precise and worked very
well such that the obstacle was close to perpendicular. The range with which they can
detect objects was found to be about 40° which was smaller than was originally predicted,
although issues should not arise for preliminary use of the quadrotor. If problems arise with
regard to this limited detection range, more sensors will need to be added to the quadrotor.
The output distance of the ultrasonic sensors was also sent to the User Interface via the
Bluetooth link. The user interface was able to interpret the data sent and accurately sketch
the location of the obstacle and the relative distance it is from the quadrotor. This is a very
useful feature, as if in future variations the quadrotor is no longer within sight of the
operator they can still determine the location of obstacles.
5. Suggestions for Further Improvements
5.1 Major Challenges in this Project
Stable Control System
Power Management
Weight Management
Reducing project scope
5.2 Learning through this Project
Software/Hardware Interfacing
Communication Protocols
Project Planning/Scoping
28
5.3 Suggestions for further improvements
More sophisticated Obstacle Avoidance System (more sensors and functionality)
PCB Development for Control Board (compact design)
Portable Controller (portability)
More robust Control System (robust to extreme disturbances)
More accurate orientation sensing devices (include magnetometer)
Location sensing capabilities (flight tracking)
Waypoint and distance features
6. Conclusions The main goal of this project was to produce a portable quadrotor with a diameter of
approximately 30 cm. To split up the work the project was divided into four different
sections, the GUI, the Communication Link, the Flight Control System and the Obstacle
Avoidance System. The quadrotor was to have a real-time GUI to serve as a controller. This
portion of the project was successfully completed and the basic functionality is
implemented and ready to use. The quadrotor was required to have a wireless
communication link to provide communication between the GUI and the quadrotor. This
link was successfully implemented using the Bluetooth protocol and has been tested to
confirm it is functioning correctly. The quadrotor was required to be able to hover in a
stable configuration and move upon user command 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. However, we faced challenges in producing a
stable control system due to the complexity of the system and inability to isolate the errors
in order to correct them. The quadrotor was required to detect and avoid obstacles. Due to
the simplicity of the commercial ultrasonic sensors, this system was implemented and is
reasonable effective at detecting objects, although the detection range is much smaller than
anticipated. Due to this it would be necessary to use 8-10 ultrasonic sensors instead of only
6 to make the system more robust. As the Flight Control System was unable to achieve
stable hovering, only the detection portion of the system was implemented.
This was a large project with a significant amount of work to be completed for the fourth
year project. The GUI, communication link and obstacle detection system were also
successfully implemented and tested, however the flight control system provided many
challenges. This was an interesting project and allowed for us to expand our knowledge in
several areas previously unexplored in our education.
29
7. References 1. G. Mortimer, “German multicopter makes first manned flight,” (sUAS News),
[online] 2011, http://www.suasnews.com/2011/11/9691/german-multicopter-
makes-first-manned-flight/ [Nov. 5, 2012].
2. G. Raffo, "An Integral Predictive/Nonlinear H-infinity control Structure for
Quadrotor," Universidad de Sevilla, Sevilla, 2010.
3. J. Munoz, W. Premerlani, J. Julio, D. Weibel. "MinIMU-9 v2 Gyro, Accelerometer,
and Compass." Internet: http://www.pololu.com/catalog/product/1268 [Jan. 23,
2013].
4. Y. K. Johann Borenstein, "Obstacle Avoidance with Ultrasonic Sensors," IEEE
Journal of Robotics and Automation Vol 4, pp. 213-218, 1988.
30
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.
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.
COM: Short form of “communication”.
C++: A common object oriented computer programming language.
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.
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.
Receiver line: The line from the USART that received binary data.
Transmitter line: The line from the USART that transmits binary data.
31
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].
32
9. Appendices
9.1 Appendix 1
33
9.2 Appendix 2
