Internet Mobile Robot

Internet Mobile Robot
The Quadcopter
Group 13
Rahul Bura
Mohamed Chande
Vinayak Goge
Hue Vo
Supervisor: Professor Peter X. Liu
A report submitted in partial fulfillment of the requirements

of SYSC-4907 Engineering Project
Department of Systems and Computer Engineering

Faculty of Engineering
Carleton University
April 7, 2010
Abstract
Group 13 consisting of Rahul Bura, Mohamed Chande, Vinayak Goge
and Hue Vo have developed a start-up project as a partial fulfillment for
SYSC 4907 Engineering Project: Internet Mobile Robot: The Quadcopter. The
Internet Mobile Robot April 7th, 2010
objective of the project was to design and implement a Quadcopter
(helicopter with four propellers) that can take flight and be controlled using a
remote client application over the internet.
Currently, different Quadcopter designs have been implemented.
However, most of them have used handheld Radio Control implementations.
With the design implemented in this project, different applications can be
developed to control the Quadcopter over the internet from a remote
location. This opens up different possibilities with the design being applied in
different areas ranging from Surveillance to Virtual Gaming Technologies to
Military Applications.
Different designs were explored and from these designs, it was
determined that we would need a microcontroller to run control algorithms, a
Wi-Fi chip to facilitate wireless communication and a webpage to for user
interaction. Any command received from the WI-Fi chip is processed by the
microcontroller and executed by all the components including motors, speed
controllers and inertial measurement units that are used to stabilize the
Quadcopter.
The communication system implemented a server/client architecture
with the Wi-Fi chip behaving as a server that acts to reply to requests from a
remote client webpage. For the data transfer mechanism, TCP protocol was
used over the Internet to send traffic from the client to the server and
bidirectionally. The webpage, implemented as a simple Graphical User
Department of Systems and Computer Engineering |Carleton University 2

Interface (GUI), is a good replacement for the RC handheld devices and
allows for easy portability from one client to another.

Acknowledgements
We would like to formally thank Professor Peter X. Liu for supervising
and for his guidance throughout the Internet Mobile Robot project as well as
giving us the opportunity to explore and experiment with our creativity.
We would also like to thank the Technical Support Staff, Danny Lemay,
Jerry Buburuz and Daren Russ, for their support throughout the project.
Their prompt actions, experience and knowledge allowed us to surpass
various milestones throughout the duration of the project.

Table of Contents
Abstract.......................................................................................................i
Acknowledgements....................................................................................iii
List of Figures............................................................................................vi
List of Tables............................................................................................viii
1.0 Introduction..........................................................................................1
1.1 Background......................................................................................1
1.2 Motivation........................................................................................3
1.3 Problem Statement..........................................................................3
1.4 Proposed Solution and Accomplishments.........................................3
1.5 Overview of the Remainder of the Report........................................6
2.0 The Engineering Project.......................................................................8
2.1 Health and Safety.............................................................................8
2.2 Engineering Professionalism............................................................9
2.3 Project Management......................................................................10
2.4 Individual Contributions.................................................................11
2.4.1Project Contributions................................................................11
2.4.2Report Contributions................................................................12
3.0 Robot Design......................................................................................13
3.1 Structure........................................................................................13
3.1.1Number of Motors....................................................................13
3.1.2Frame.......................................................................................15
3.2 Communications............................................................................15
3.3 Flight and Stability.........................................................................16
3.4 Flight Control..................................................................................18
3.5 Power.............................................................................................20
4.0 Hardware Components and Construction...........................................22
4.1 Frame and Structure......................................................................22
4.2 Microcontroller...............................................................................24
4.3 Flight and Stability.........................................................................25
4.3.1Propeller and Motor Combination Configuration......................25
4.3.2Electronic Speed Controller (ESC)............................................26
4.3.3Six Degrees of Freedom (DOF).................................................27
4.4 Communications............................................................................28
4.5 Battery...........................................................................................28
4.5.1Flight Time and Battery Power Dependancy............................29
4.6 Design Implementation and Final Structure...................................30
5.0 Stability and Manoeuvre.....................................................................33
5.1 Filtering Noise................................................................................33

5.1.1Noise Reduction.......................................................................33
5.1.2Second Order Complementary Filter........................................34
5.2 Feedback Control...........................................................................35
5.2.1Six Degrees of Freedom (DOF).................................................36
5.2.2System Control Theory.............................................................37
5.2.3Proportional, Integral, Derivative Controller.............................40
5.2.4Feedback Control Mechanism: Inertial Measurement Units......42
5.2.5Feedback Control Loop.............................................................43
5.2.6Flight Tuning Using Ziegler-Nichols Rules................................45
5.3 Flight Configuration and Simulation...............................................46
5.3.1Flight Configuration Methods and Tools...................................46
5.3.2Pre-Flight Tests........................................................................49
5.3.3Flight Control and Results........................................................50
6.0 Wireless Communication (Server)......................................................54
6.1 Communication System Overview..................................................54
6.2 Wireless Standards.........................................................................55
6.2.1ZigBee......................................................................................56
6.2.2Wi-Fi.........................................................................................57
6.3 WiShield Configurations.................................................................58
6.3.1Network Type...........................................................................58
6.3.2TCP vs UDP...............................................................................59
6.4 WiShield Functionality....................................................................64
6.5 Serial Peripheral Interface..............................................................66
6.6 Challenges and Solutions...............................................................69
6.6.1Debugging................................................................................69
6.6.2Pin Conflict...............................................................................71
7.0 Wireless Communication (Client).......................................................73
7.1 Client Design..................................................................................73
7.2 Client Process.................................................................................77
8.0 User Interface.....................................................................................79
8.1 Software Requirements..................................................................80
8.1.1Operating System....................................................................81
8.1.2XAMPP......................................................................................81
8.2 Challenges and Solutions...............................................................83
9.0 Software Integration...........................................................................85
10.0.............................................................................Production Expenses
88
10.1....................................................................................Material Costs
88
11.0.......................................................Conclusion and Recommendations
90
11.1.........................................................................................Conclusion
90

11.2.............................................................................Recommendations
92
References...............................................................................................93
Error: Reference source not found
List of Figures
Figure 1: Rotating pairs of rotors [3]................................................................1
Figure 2: First Generation Design of De Bothezat Quadrotor [3]......................2
Figure 3: Wound Rotor [10]............................................................................16
Figure 4: Brushless Motor Design [11]...........................................................17
Figure 5: Typical Microcontroller....................................................................19
Figure 6: Sketch of Proposed Structure..........................................................23
Figure 7: Initial Frame....................................................................................23
Figure 8 : Aeroquad Shield.............................................................................28
Figure 9: Graph of Flight Time versus Battery Life.........................................30
Figure 10: Wiring Diagram for IMR.................................................................31
Figure 11: Final Design...................................................................................32
Figure 12: Second Order Complementary Filter [15]......................................34
Figure 13: Second Order Complementary Filter [15]......................................35
Figure 14: Possible independent movements in 3D space [16]......................37
Figure 15: Types of Control Systems: (a) Open Loop (b) Feed-Forward (c) Closed
Loop [18]........................................................................................................38
Figure 16: How the damping constant affects the time it takes to reach steady state
[19]................................................................................................................40
Figure 17: PID Controller loop [20].................................................................42
Figure 18: Feedback loop including system, controller and sensor configuration [21]
.......................................................................................................................43
Figure 19: Feedback Control Loop with control components..........................44

Figure 20: Motor Command outputs (S) during simulation of flight with Serial
Monitor...........................................................................................................46
Figure 21: Sensor Data output (Q) during simulation of flight with Serial Monitor
.......................................................................................................................47
Figure 22: AeroQuad Configurator GUI with updatable flight parameters......48
Figure 23: Various sensor outputs with AeroQuad Configurator GUI..............49
Figure 24: Original Communication System Design.......................................55
Figure 25: TCP three-way handshake.............................................................60
Figure 26: Re-designed Communication System............................................63
Figure 27: WiShield Functionality...................................................................64
Figure 28: Handling TCP connection..............................................................65
Figure 29: SPI bus, single-master single-slave...............................................67
Figure 30: WiShield Schematic [27]...............................................................68
Figure 31: Simple Compiler provided for WiShield.........................................71
Figure 32: Ideal Layout of Client System in relation with WiShield................74
Figure 33: Actual Implementation of Client System in relation with Wi-Shield75
Figure 34: Client Design.................................................................................76
Figure 35: Client Process................................................................................78
Figure 36: User Interface................................................................................79
Figure 37: Components of the User Interface.................................................80
Figure 38: Pin 5 of SM (with WiShield) connected to digital pin 32 of PM using a wire
[39]................................................................................................................87
Figure 38: Pin 5 of SM (with WiShield) connected to digital pin 32 of PM using a

wire()

List of Tables
Table 1: Report Contributions........................................................................12
Table 2: Flight Times for 2 Different Designs.................................................14
Table 3: Matching Motors for EPP1045 Propeller............................................25
Table 4: Total Weight Calculation...................................................................29
Table 5: PID gain using Ziegler-Nichols Tuning Rule [17]...............................45
Table 6: Values of KP and corresponding qualitative observations for Ziegler-Nichols

Rule................................................................................................................52
Table 7: Relevant differences between TCP and UDP....................................62
Table 8: List of Materials and Respective Cost...............................................89
Table 8: List of Materials and Respective Cost

Internet Mobile Robot April 7th,
2010
10Introduction
With the recent developments in wireless communications
technology and its increased accessibility and affordability, network-
based applications are now able to expand into new areas. One of
these areas is the domain of Internet Robots. Internet robots have
numerous applications and they can be programmed to perform
multiple functions. The Internet Mobile Robot (IMR) constructed is an
Unmanned Aerial Vehicle (UAV) that will be controlled wirelessly via a
web browser.
1.1Background
The Unmanned Aerial Vehicle built is also
known as a Quadcopter or Quadrotor owing to
the fact that it has four motors and propellers
that stabilize and manoeuvre the robot. Flight
control is achieved by varying the speed of each
rotor to change the thrust and torque about the
center of rotation. The rotors are spinning in Figure 1: Rotating pairs of

rotors()
pairs of angular velocity - two rotate clockwise
and two rotate counter-clockwise. This is illustrated in Figure 1.
Quadcopters have been around for a while and its development
can be generally classified into 2 generations. The first generation of
designs were done to transport cargo and passengers. However, early
Department of Systems and Computer Engineering |Carleton 1

University
2010
prototypes suffered from poor performance () and latter prototypes
required too much pilot workload, due to poor stability ().
Figure 2: First Generation Design of De Bothezat Quadrotor()
The second generation of Quadcopter designs is what the
Internet Mobile Robot falls under. This more recent generation consists
of designs that are commonly designed to be unmanned aerial vehicles
that use electric control systems and sensors to stabilize the aircraft().
There are various advantages of the current generation of Quadrotors
over comparable scale helicopters. Quadrotors have a simpler
mechanism that controls the rotor blades as opposed to a helicopter’s
as mechanical linkages are not required for control of the rotor blades.
This simplifies the design of the vehicle, and reduces maintenance
time and cost (). Also, the use of four rotors allows each individual
rotor to have a smaller diameter than the equivalent helicopter rotor
resulting in less kinetic energy being stored during flight. This reduces
the damage caused should the rotors hit any objects. For small scale

University
2010
vehicles, this makes it safer to interact with in close proximity. Finally,
by enclosing the rotors within a frame, the rotors can be protected
during collisions, permitting flights indoors and in obstacle-dense
environments, with low risk of damaging the vehicle, its operators, or
its surroundings ().
1.2Motivation
Multiple implementations of the Quadcopter currently exist.
However, most of them are Radio Control (RC) implementations.
Having a Wi-Fi implementation would open up the communications to
other possibilities. Adopting this implementation would mean that we
would be abolishing the use of the traditional RC remote controller. In
lieu of this, a control mechanism needs to be created in the form of an
encrypted web browser with a user-friendly Graphical User Interface
(GUI). Also, there are various methods to stabilize the RC Quadcopter
using accelerometers and gyroscopes. Having chosen to adopt a Wi-Fi
implementation, these methods need to be studied and adapted to the
Wi-Fi implementation.
1.3Problem Statement
A Quadcopter needs to be constructed and a Wi-Fi
implementation needs to be done to wirelessly manoeuvre and
stabilize it via the internet, through a web browser.

University
2010
1.4Proposed Solution and Accomplishments

As can be seen from Section 1.3, there were four main areas that
this project concerned itself with. The first goal was to get a
Quadcopter, comprising of the structure and control logic, constructed.
Having done so, a Wi-Fi implementation has to be deployed to control
the system. This system then needs to achieve stability and stable
manoeuvrability. A user control interface also needs to be developed to
control the system in the form of a secure web page.
The Quadcopter can be constructed using various component
parts from hobby shops. Major parts to look at would be the robot’s
frame as well as the robot’s flight and control mechanism. A major
accomplishment was determining the various required parts and where
we could procure them. Having done much preliminary research, a big
contribution to the project, the components were purchased from
various online stores. The construction of the structure itself was an
important accomplishment as it was a necessary component for
testing this year. It will be just as important a component for future
groups working on this project as it will be foundation on which further
applications can be developed. The initial design was constantly
modified to meet changing needs. More can be read in Sections 3.0
and 4.0 regarding the selection of components and the design and
implementation process.

University
2010
The Wi-Fi implementation can be achieved by using a Wi-Fi
module that can communicate remotely with the router. An
accomplishment was to find the right Wi-Fi module to communicate
with the robot remotely via a router. The WiShield from Async Labs
was purchased for this purpose. Commands that the Wi-Fi module
receives are communicated to the microcontroller making the robot
correspond respectively. This was achieved by learning the various
communication protocols (TCP and UDP) and selecting the appropriate
protocol. A good understanding of the extensive documentation that
came with the module was also necessary and can be seen as an
accomplishment since we are now able to write code (client / server)
for this module knowing which functions we would utilize. It is an even
greater accomplishment that we were able to achieve Wi-Fi
controllability as the WiShield is one of the first modules of its kind and
there was neither support nor a debugging mechanism available.
Section 6.0 covers this in detail.
Extensive research was done to determine the means to achieve
stability of the IMR. Results showed that stability can be achieved
using an Inertial Measurement Unit (IMU) and a Proportional-Integral-
Derivative (PID) controller. The IMU is the hardware component and
the PID controller is the software component that complements the
IMU. Two chips work in tandem to provide a Six Degree Of Freedom
(6DOF) IMU. The IMU generates raw accelerometer and gyroscope data

University
2010
that are fed to a filter as inputs so that the speed of the motors can be
varied accordingly to stabilize the Quadcopter. The Quadcopter is able
to stabilize fairly well using this implementation although more testing
and debugging needs to be done for this implementation to work
flawlessly. Due to time constraints, we were unable to get the
Quadcopter completely stable. We were however able to identify why
the Quadcopter is unable to completely stabalize itself and this is a key
contribution to the project this year so that future teams are saved
from looking for causes. Section 5.0 can be referred for further details
regarding stability. The PID Controller was just one component of the
code required for the proper control of the IMR and hence another
major contribution this year was to have a good understanding of the
various component functions required for the proper operation of the
IMR.
A web browser- based GUI was developed using a suite of
scripting languages. One accomplishment was to determine which
languages needed to be used to build this interface. After much
research XAMPP package was selected due to its ability to facilitate
various interfacing as well as the potential for further development in
the future. After having chosen this package, another major
accomplishment was the design of the interface. This design is not
perfect but it’s a good foundation for future designs. It outlines the
basic controls currently but this can be improved upon in the future to

University
2010
provide visual feedback, a battery monitor, telemetry etc. according to
future development of the IMR. Further details can be read in Section
8.0.
Another major accomplishment was the integration of all the
code so that the IMR can function seamlessly. The current solution was
implemented successfully however it is not the most elegant solution.
Section 9.0 has more information with regards to this.
1.5Overview of the Remainder of the Report

The remainder of the report consists of documents that
constitute research needed for the IMR project. These documents may
be in the form of code, calculations, charts or graphs that illustrate or
aid in the understanding of a concept or point. Graphs, figure and
tables will be referred to in the pertinent paragraphs, by their
corresponding numbers. The List of Figures and List of Tables on pages
List of Figures and List of Tables respectively can be referred to as
well.
Section 3.0 will expound on the process of designing the IMR. It
will outline the research and calculations done to come to the final
design of the IMR as well as the component parts. Section 4.0 is
complementary to Section 3.0 and it will outline the components
chosen and the rationale behind each selection. It will also briefly
touch on the construction process of the IMR.

University
2010
Section 5.0 will go into further detail on stability and system
controls. The section will delve deeper into topics such as noise-
handling, filters and filtering as well as feedback loops and the control
mechanism that was used to control the IMR.
Section 6.0, Section 7.0 and Section 8.0 constitute materials on
the communications component of the project. Section 6.0 looks into
how commands are communicated to the IMR. It will look at how the
Wi-Fi module has been utilised and how the functions were
implemented to communicate wirelessly with the IMR. Section 7.0
describes the client process and Section 8.0 comprises of material on
how the user can communicate with the IMR via the GUI created. It
also looks at how the GUI was implemented.
Section 9.0 explains the software integration process and Section
10.0 provides information on the materials purchased. Section 11.0
concludes the report by looking at what we’ve achieved this year. It is
going to briefly outline the accomplishments and detail various
recommendations for future project groups working on the
Quadcopter.

University
2010
20The Engineering Project

2.1Health and Safety
Due to the nature of the project, there are many health and
safety concerns that one should be aware of before working on such a
project. These concerns range from health concerns possibly causing
bodily harm to oneself as well as others. Many measures were taken
to ensure the health and safety of all members as well as other
throughout the span of the project.
As with most engineering projects, a lot of time is spent in front
of a computer whether it be for research and analysis or for the
implementation aspect. Many health concerns can arise if one spends
an extended period of time in front of the computer. Sitting with poor
posture can cause back pains and wrist pains and staring at a screen
for too long may cause one’s eyes to strain. As such, it is
recommended to take regular breaks to not over strain the eyes and to
not cause future back or posture problems.
Specific to this project, there are large propellers slicing through
the air and a mass flying from point to point. Anytime there are large
moving parts that can cause minor to severe bodily harm, one should
take safety precautions. Although the propellers are plastic, the speed
at which it is rotating is enough to penetrate the skin. Before
commencing with any tests or attaching the propellers and allowing
them to spin, one should ensure that there is no one and nothing in the

University
2010
vicinity of the propellers. Also, it is recommended to test in an open
space with plenty of room in case one should lose control of the
Quadcopter. For testing purposes, the Quadcopter should be powered
using the Power Supply until consistent wireless connection and
communication to the Arduino can be established. This way, there is
always a method of turning off the Quadcopter should it start to fly in
an unexpected manner. Once the wireless connection can be proven
to be reliable, one can use the battery to test the Quadcopter.
When working with electrical devices, there can always be a risk
of shock or even electrocution. It is extremely important to take
precautions when handling electrical components and power supplies.
Ensure that everyone that must come in contact with the components
know the risks and the proper method of handling the components.
Any soldering done should be done with proper equipment and
technique. There are guidelines at each soldering station in the labs.
One should read and understand how to properly handle the
equipment before attempting to solder as this can lead to severe
burns.
2.2Engineering Professionalism
Engineering is a profession. It is the process of methodically and
logically coming up with a solution for a given problem. As part of the
requirements for graduation, our team has formally respected all
phases of a development cycle. For it to be considered engineering

University
2010
there must have been some research and analysis of a problem. A
solution was then supplied in the form of a Proposal. Further research
and analysis was done before the design phase of the project, followed
by an interim/progress report (and presentation). Then there was a
period of implementation and testing. The team has followed the
procedures and are coming to the end of the development cycle for the
proposed project.
Throughout the project, our group made sure our decisions were
made responsibly and took precautions to ensure no one in the
immediate society would be harmed during the testing and
development of the project. Should any doubts arise about the
potential safety of anyone, measures were taken to relieve that doubt.
Internally, as a team, each group member has handled
themselves professionally. In the case of a disagreement, the team
would get together and discuss civilly to find a compromise. We have
made decisions for the benefit of the progress of the project without
attempting anything that may be considered immoral or unethical.
Each member took ownership of their duties and ensured that their
work was completed as well as it could be.
2.3Project Management
Our team started our development by doing some research on
our topic of interest. After some brainstorming sessions for possible
ideas, we proceeded with our Quadcopter idea and did some further

University
2010
research and analysis on the topic including possible structure design
and components. The brainstorming session really brought together
the idea and laid a path for the direction we wanted the project to
head in.
As the project progressed, different components were selected
and designated to a “primary” that will be responsible for that
component from then forward. These topics were chosen to be
relatively independent of each other to allow each member to develop
an expertise in that topic and allow for a specific area of work while
working independently.
Team meetings were made regularly to discuss the progress and
any problems encountered. Should a problem arise, the team would
help in finding a solution or suggest any possible alternatives. Any
major changes in the direction of the project would then be discussed
and agreed upon. Deadlines for both the department as well as
internal team deadlines were emphasized and any upcoming events
would be brought up to ensure all team members were aware of their
responsibilities for that deadline. Internal team deadlines were made
to ensure progress was made in a timely manner. Changes to the
project were also made in order to meet deadlines as required. It was
decided that only the core components be done for this year, which
removed many additional features we previously wanted to implement.

University
2010
We also created an online group with Google Groups to allow
every member to add and access any documents another member
may be using. This helped with organizing documents and reports as
well as allowed us to share any useful information with the group in a
well managed, designated area. It quickly became a good source for
referencing any previous discussions and documents.
2.4Individual Contributions
2.4.1Project Contributions
The area of expertise and designated work was assigned as stated
below. The project could be divided into four high level components:
1. Structural Analysis and Design (Rahul Bura)
2. Stability and Manoeuvre (Hue Vo)
3. Wireless Communication (Mohamed Chande – Server, Vinayak
Goge – Client)
4. User Interface and Webpage Design (Vinayak Goge)
The work was assigned as such in order to allow for any additional
required independent work to be done outside of team meeting times. Much
of the work in the development cycle, from Research and Analysis to
Implementation to Component Testing, were done as a team where
suggestions and any further knowledge of the topic by other teammates
could help progress the project more efficiently.
Much of the Research and Analysis was done by all members of the
team with Rahul Bura leading the structural and component selection.
During integration of the project, all members were equally involved,
regardless whose component was being integrated at the time. For formal
University
2010
presentations, all members contributed in different components throughout
the presentation preparation period.
1.1.1Report Contributions
As with the Project Contributions, as previously stated, this report was
written by the person with the most expertise of the topic throughout the
project, as much as possible. The formal contributions are as follows:
Secti Editing and Proof

Author
on Reading
1.0 Rahul Bura Mohamed Chande
2.0 Hue Vo Vinayak Goge
3.0 Rahul Bura Hue Vo
4.0 Rahul Bura Mohamed Chande
5.0 Hue Vo Rahul Bura
6.0 Mohamed Chande Vinayak Goge
7.0 Vinayak Goge Mohamed Chande
8.0 Vinayak Goge Hue Vo
9.0 Mohamed Chande, Hue Vo Rahul Bura
10.0 Rahul Bura, Vinayak Goge Mohamed Chande
Rahul Bura, Mohamed Rahul Bura, Mohamed
11.0 Chande, Vinayak Goge, Hue Chande, Vinayak Goge, Hue
Vo Vo
Table 1: Report Contributions
20Robot Design
Robot design is one of the key components of the project. The
IMR consists of the structure and logic elements. The structure designs
were considered based on manoeuvrability, aerodynamics, and cost of
component parts and feasibility of the design. The logic elements were
chosen on the design decisions made to address the problem
statement. The design process took into consideration key

University
2010
components that include structure of the robot, communications, the
stability mechanism, the controls mechanisms and power.
2.1Structure
The structure is one half of the IMR. The structure houses the
microcontroller and also has the flight mechanism integrated.
Designing the structure design required various design considerations
including the number of motors and frame design.
2.1.1Number of Motors
Technically, any number of motors can be mounted to achieve
flight. However, with every new motor mounted, the weight of the
robot increases. Weight is obviously a concern and we want the IMR to
be as light as possible. There are two types of weight- weight of the
IMR with the basic components mounted components and weight of
extra mounted parts, also known as payload. It is important to note
the correlation between the weight of the IMR , its ability to carry that
weight and the number of motors. Table 2 tabulates these factors to
help with the design decision. 2 designs were considered - the
Quadcopter (4 motors) and the Octcopter (8 motors) as is reflected in
the table.
The metric used to determine the design is flight time and a
2100mAh battery was used as a constant power source to determine
the flight times for all the payloads of each of the two designs. It is

University
2010
assumed that each design is able to carry its own structural weight and
hence they are ignored so only the payload is tabulated.
4 Motors 8 Motors
Design Design
Pay
(Quadcopte (Octocopter
Load(oz)
r) )
0 19.9 11.7 Fl
ig
8 12.6 9.2 h
16 9.2 7.5 t
Ti
24 7.3 6.3
m
32 - 5.3 e
(
M
Table 2: 40 - 4.6 in
Flight Times s)
for 2
Different Designs
As can be observed, with no payload, the Quadcopter can
achieve flight for about 20 minutes and the Octocopter can achieve
flight for about 12 minutes. This demonstrates the effect of the weight
of Octocopter’s frame. It has a decreased time of flight compared to
the Quadcopter without a payload. The maximum payload that the
Quadcopter can carry is 24oz for a period of 7.3 minutes. This is in
contrast to the 40oz that the Octocopter can carry due to the
increased number of motors. However, it can only sustain flight for
about 4.6 minutes which is not ideal. We also expect that the
maximum payload we will have would be less then 16oz. Hence

University
2010
looking at the payload of 16oz, the Quadcopter offers a better
performance and we settled on the four-motor design for our IMR.
2.1.2Frame
The frame of the Quadcopter was next in the design of the
structure. Numerous materials were researched with the criteria that
the material be durable and light. Some of the alternatives considered
were aluminum, balsa wood and carbon fibre reinforced plastic.
Aluminum is a soft, durable, lightweight and malleable metal that is
easy to work with. It has about one-third the density and stiffness of
steel making it significantly lighter (). Balsa wood is one of the lightest
varieties of wood available and strong for its weight, pound for pound.
It’s fairly malleable without compromising its strength (). Carbon fibre
reinforced plastics are composite plastics that have been reinforced
with carbon fibre to provide a high strength-to-weight ratio. The
density of carbon fiber is also considerably lower than the density of
steel, making it ideal for applications requiring low weight().
The design of the frame itself was based on other models. It was
decided that we’ll have a cross-shaped frame with a motor mounted on
each of the four arms. The intersection in the middle would have the
logic and power units mounted on it. The illustration in Figure 6 shows
the preliminary proposed structure.

University
2010
2.2Communications
How we communicated with the robot was a key consideration.
Various alternatives we looked at including ZigBee, Wi-Fi and
Bluetooth. After careful analysis of the specifications and capabilities of
each technology, we decided on implementing Wi-Fi for our robot
design.
Bluetooth technology however was ruled out earlier in the course
of development of the project mainly because of the cost to
transmission range trade-offs. Bluetooth modules can provide
transmission ranges of 1m, 10m and 100m. For our project purposes,
the ideal minimum range was considered to be 100m. With this range,
Bluetooth technology is very expensive. Furthermore, compared to Wi-
Fi and ZigBee, Bluetooth networking is slower and this feature is
undesirable in real-time applications and applications that are sensitive
to network delays.
ZigBee, Wi-Fi standards and their corresponding Radio Frequency
(RF) modules provide specifications that meet the requirements of the
project. As to how Wi-Fi was selected over ZigBee, a detailed
explanation is provided in Section 6.2.
2.3Flight and Stability

For flight, four pairs of propellers and motors are required. There
are numerous motors available that are powered by DC

University
2010
or AC sources. We were particularly interested in DC motors since we
wanted to power components using battery cells. DC motors run on
DC electric power and there are various types that include the Brushed
DC motors and Brushless DC Motors.
Brushed motors refer to the classic DC motor that has a wound
rotor with a split ring commutator which periodically reverses the
current direction between the rotor and the external circuit, and a
magnet stator. () An electrical power source is connected to the rotor

Figure 3:
through the commutator and its brushes providing
Wound Rotor()
current flow and subsequent electromagnetism. With
the commutator switching currents periodically as the rotor turns, the
magnetic poles of the rotor are prevented from ever being fully aligned
with the magnetic poles of the stator field causing the rotor to spin
indefinitely. Essentially, stationary metal contacts that ‘brush’ against
moving metallic contacts are used to transfer electrical energy to coils
on the rotor. However, the brushed implementation has a number of
limitations. Main ones include a limit to the maximum speed of the
machine and the need for replacing the brushes.
The alternative is the brushless
motor. The brushless motor’s
implementation differs from that of the
brushed motors. A brushless motor

University
Figure 4: Brushless Motor
Design()
2010
consists of stationary coils and a rotating magnet. The need for
brushes to provide current to the moving rotor is eliminated and
instead an external electronic controller is used to power up the
stationary coils, which are grouped in phases, causing the magnet to
rotate. () Section 4.3.2 contains further discussion on the electronic
controller. Figure 4 shows the brushless motor design. The star-shaped
component with the blue coils is the rotor and the disk in the top right
corner has the permanent magnet in the shape of a ring and it rotates
around the rotor, about the centre. This design differentiation provides
several advantages over the brushed motors.
Research showed that an ultimate combination of motor and
propeller is needed to be used for optimal thrust power. The
appropriate combination was chosen as can be seen in Section 4.2.
A 6 degree of Freedom (DOF) Inertial Measurement Unit (IMU)
was required for stability and manoeuvring the Quadcopter. An IMU is
an electronic device that measure and reports velocity, orientation and
gravitational forces using accelerometers and gyroscopes in tandem.
Accelerometers measure acceleration relative to freefall and
gyroscopes measure or maintain orientation, based on the principles of
conservation of angular momentum (). Since the Quadcopter is going
to be flying in a three-dimensional space, an IMU that considered the 6
degrees of freedom was essential. The 6 degrees of freedom refers to

University
2010
the fact that the rigid body is able to move about the X, Y and Z axes
independent of each of the 3 axes and of the rotation about any of the
3 axes. This would enable the Quadcopter to move forward, backward,
up, down as well as left and right in three-dimensional space.
2.4Flight Control
To control the Quadcopter, two alternatives were considered.
We could have used a Field-Programmable Gate Array (FPGA) board or
a microcontroller. A FPGA is an integrated circuit that contains
programmable logic components known as Logic Blocks and a
hierarchy or reconfigurable interconnects that allows the blocks to be
connected. These configurations can be programmed using Hardware
Description Language (HDL). However, an FPGA would have been
harder for us to work with as we were not as familiar with it as we are
with our other alternative – the microcontroller.
Microcontrollers are computer systems on a chip.
Microcontrollers have a microprocessor and peripheral functions like a
relatively simple clock, timers, I/O ports and memory implemented on
one chip. Figure 5 illustrates this. Microcontrollers are designed for
smaller or more dedicated applications and hence they may have
lower clock rate frequencies enabling lower power consumptions. This
would be perfect for battery-powered applications such as our
Quadcopter. Microcontrollers were originally programmed in assembly

University
2010
language (low level language – communication at machine level) but
various high level programming languages are now in use as well. Such
languages can be specially written to be microcontroller-specific or be
versions of general purpose languages such as the C programming
language. Compilers and environments may be tools that are provided
by the microcontroller vendors to program or debug the
microcontroller.
Figure 5: Typical Microcontroller
Various microcontroller options were considered as well as there
are numerous manufacturers. Ultimately the cost, form factor and ease
of programming are the criteria that would determine the choice.
2.5Power
The Quadcopter needed a sustainable and portable power source
to power the control unit and the motors. Different types of
rechargeable batteries were researched and a number of chemical
compositions were taken into consideration. Nickel Cadmium (NiCd),

University
2010
Nickel Metal Hydride (NiMH), and Lithium Polymer (LiPo) cells are
currently the most commonly used, but each needs to be charged,
discharged, and stored differently. On top of that, each model may
require a different cell count or battery configuration as well.
Nickel Cadmium or NiCd batteries are less common now but they
are cheap. These batteries have cons as well however. NiCd batteries
need to be fully discharged after each use as failure to do so would
mean that for future discharge cycles, they will not discharge to their
full potential. NiCd batteries also have a low energy density – the
capacity per weight.
Nickel Metal Hydride (NiMH) batteries have numerous
advantages over the NiCd batteries. NiMH cells offer higher energy
density and don’t have the same performance issues attributed to
improper discharge practices as NiCd batteries do.
The latest cells are the Lithium Polymer (LiPo) cells. LiPo cells
offer higher better discharge performance as they provide better
consistency compared to NiCd and NiMH cells. LiPo cells also offer a
significantly higher capacity for their weight; a cell may have twice the
capacity for half the weight of a similarly performing NiMH cell. Hence,
LiPo cells can achieve higher voltage and energy density. LiPo cells
need to be monitored when being charged however. This is the major
deterrent when it comes to adopting this technology. Overcharging can

University
2010
cause the cells to be potential major fire hazards given the amount of
energy packed into such a small space.
The Lithium Polymer battery was chosen in the end due to the
advantages mentioned above.

University
2010
30Hardware Components and

Construction
Hardware components were chosen from the alternatives
presented in Section 3.0. It was important to bear in mind the weight
of each component. There were other decisions that needed to be
made in the process of choosing an individual component. These
decisions were made to ensure compatibility with other component
parts. This will be discussed in each of the sections.
3.1Frame and Structure

Carbon fibre reinforced plastic (Carbon Fibre for short) rods were
used for the arms of the robot. Carbon Fibre Rods are light and proved
to have a higher strength-to-weight ratio when compared pound- for-
pound with the other alternatives. Carbon fibre also has high tensile
strength, low thermal expansion. However, it is relatively expensive
when compared to the other alternatives but the small price
discrepancy was almost negligible looking at the advantages Carbon
Fibre provided, especially since it is significantly lighter and durable
compared to the alternatives mentioned in Section 3.1.2. The sketch in
Figure 6 shows the proposed basic frame of the IMR. Aluminum was
chosen for the square base initially as can be seen in Figure 7. The
figure shows the initial structure with the Carbon Fibre rods and
aluminum square base. The total weight of the fibre rods, the

University
2010
aluminum base and the miscellaneous screws and nuts used to secure
the components is 3.2oz.
Figure 6: Sketch of Proposed Structure
Figure 7: Initial Frame

University
2010
3.2Microcontroller
The Arduino Mega was chosen because of its
greater memory, processing power and number
of ports. It has 54 digital input/output pins, 14 of
which offer Pulse Width Modulation (PWM) that is
required to control the motors, 16 analog inputs
that provide a 10bit resolution each, and 4 Serial UARTs. The Arduino
Mega is a microcontroller board based on the ATmega1280
microprocessor. It has an operating voltage of 5V, input voltage range
from 7V to 12V, 128KB of Flash Memory for storing code, 8KB of SRAM,
4KB of EEPROM and a clock speed of 16MHz. It was a cheaper
alternative to the other options considered. The microcontroller is
widely adopted and hence there is more support for it. There are
numerous ‘shields’ that can be mounted on to it for added
functionality. Examples include the Aeroquad Shield V1.7 and the
WiShield 2.0 that will be discussed in later sections.
The Arduino Mega can be programmed with the Arduino Software
provided free by the developers. The Arduino Integrated Development
Environment (IDE) is written in Java and made for the Processing
programming language. It includes a code editor with features such as
syntax highlighting, brace matching, and automatic indentation, and is

University
2010
also capable of compiling and uploading programs to the board with a
single click.The IDE also comes with a C/C++ library that can be used
to simplify I/O operations. Arduino programs are written in a language
akin to C/C++ and hence it is something that we are familiar with ().
The Arduino Mega contributes a weight of 1.5oz to the IMR.
3.3Flight and Stability

3.3.1Propeller and Motor Combination Configuration
Brushless DC motors were ultimately chosen to provide thrust
power to the IMR. Brushless DC motors have a higher efficiency of 85%
to 90% as opposed to the 75% to 80% efficiency of brushed motors.
This results in reduced noise, longer lifetime and more power. These
motors provide superior power-to-weight ratios and are very light. To
pick the right motor model, the propeller was chosen first. The light
EPP1045 propeller was chosen as they are widely adopted in other
implementations of the Quadcopter. With this design decision, the
matching motor for optimal thrust was sought and research yielded
Table 3 below.

University
2010
Table 3: Matching Motors for EPP1045 Propeller
The table shows the comparison of the performance of the
propeller with various motors. The criteria in consideration are cost,
weight of the motor, maximum thrust achieved in pounds and the
amount of power drawn per pound at maximum thrust. After the
analysis was done, what it came down to was availability. The only
motor available was the Towerpro 2410-09 Open Base Brushless
Motor. The statistics show that it is a cost effective option and that it is
really light at 2.05oz. It could provide better thrust but it is one of the
more power-efficient motors. With a total of four such motors on the
IMR, they will contribute a total weight of 8.2oz. The Amp rating is
13.5A.
The positioning of the motor also contributed to the stability. The
closer the motors are to the centre, the more stable the IMR is.
However, this compromises the manoeuvrability of the IMR as the

University
2010
Quadcopter responds better to change in directions when the motors
are further apart. This increases the signal noise fed into the IMU due
to increased vibration. Extensive testing was done to determine the
perfect distance of the motors from the centre for the right balance
between noise and manoeuvrability.
The propeller/motor configurations also differed. As mentioned in
Section 1.1, there are 2 motors that spin clock-wise and two that spin
counter clockwise. The right propeller had to be mounted on the
corresponding motor to achieve this. The motors were wired to
Electronic Speed Controllers (ESCs) in 2 configurations to ensure the
clock-wise and counter clock-wise rotations of the motors. ESCs are
discussed in Section 4.3.2.
3.3.2Electronic Speed Controller (ESC)

Since a Brushless Motor was chosen, an Electric Speed Controller
was required. A brushless motor controller or brushless ESC (Electronic
Speed Control) is used to vary the speed of a brushless motor. These
function as an interface between the motor and the battery. Controlled
by the microcontroller, the brushless ESC provides variable power to
the motor allowing proportional speed adjustments. The
microcontroller sends PWM signals with different duty cycles to vary
the speed of the motor rotation. Unlike a brushed motor, power cannot
be directly applied to a brushless motor. Instead, the speed control

University
2010
intelligently powers each phase of a brushless motor in sequence,
causing it to rotate.
The Tower Pro w18A Mag8 Digital Brushless Motor ESC was
chosen. This component has a weight of 0.705oz, an Amp rating of 18A
and operates ideally at a voltage of 6V – 12V. These are considerations
that are important to note. The voltage information needs to be noted
for the purpose of selecting the battery. The the total weight
contributed by the 4 ESCs is 2.8oz. The Amp Rating of 18A indicates
the maximum current that the ESC is able to provide continuously to a
motor and it is better to have an ESC with a higher continuous current
rating to ensure that the ESC is able to handle the power requirements
of the motor. The Amp rating 18A is good given the 13.5A rating of
Tower Pro Brushless Motor 2410-09 chosen.
3.3.3Six Degrees of Freedom (DOF)

After much research, two chips from SparkFun were chosen to
provide the 6 DOF for the Inertial Measurement Unit. The first is a
5DOF IMU combo board that incorporates the IDG500 dual-axis
gyroscope and the ADXL335 accelerometer on one single chip. This
board enables the 5 axis of sensing (Roll, Pitch, X,Y,Z) in less than 1
square inch and weighs less than 0.07oz.

Figure 8 : Aeroquad
Shield
The second board is the dual axis IXZ-500
gyro. This senses the angular velocity on the X and Z axes. This board
thus provides Yaw information and it complements the first board that

University
2010
provides Roll and Pitch. These two chips can be mounted onto the
Aeroquad Shield. The Aeroquad Shield is a
printed circuit boards (PCB) that was made
for the Arduino. It was created to mount
the two chips as well as to interface with
the ESC connections. The total weight
contributed by this set-up is 0.75oz.
3.4Communications
The WiShield 1.0 was the chosen Wi-fi module from Async Labs.
This is perfect for the Arduino-based projects and is a ‘shield’ module
that can be directly mounted on the Arduino Mega. This shield provides
802.11b connectivity and is a direct drop-on plug-and-play solution. It
has a 16Mbit serial flash onboard to store web pages and other data.
This space can also be used for storing sensor type data that can be
downloaded in the future. It supports both infrastructure and ad hoc
wireless networks which can be useful in the testing phase. Further
research can be found in Section Wireless Communication (Server).
3.5Battery
The Lithium Polymer (LiPo) cells were chosen since they clearly
provided better performance compared to the NiCd and NiMH battery
types. It is really light and has a good energy density. This is perfect
for the project as more power would be provided from a battery pack
that doesn’t weigh too much. A 11.1V battery was chosen and this is a
University
2010
good volatage rating recalling that the ESCs has a input voltage range
of 6-12V and the microcontroller has an input voltage of 7V to 12V.
3.5.1Flight Time and Battery Power Dependancy

Given that the Quadcopter would have its own weight as well as
other payloads, we needed to do an analysis to see how much load a
certain battery can provide and how much time the battery will provide
for flight given the pay load. The various components and the
corresponding weight calculated in previous sections have been
tabulated in Table 4. The table indicates the weight of the Quadcopter
with its basic component parts. This weight will be considered the IMR
weight. Anything on top of this weight will be considered payload.
Measurements were taken using a 2100mAh battery again to see how
much payload this configuration can take and to see if it is consistent
with the Table 2 in Section 3.1.1. The graph generated can be seen in
Figure 9.
Component Weight(oz)
Base/Frame 4.2
Microcontroller 1.5
EE1045 Propellers and Prop Savers 1.1
2410-09 Motors 8.2
Motor Mounts 0.6
ESCs 2.8
Bindings and Miscellaneous Parts 0.4
Battery 5.2
Total Weight 24.0

University
2010
Table 4: Total Weight Calculation
Figure 9: Graph of Flight Time versus Battery Life
The results above show that with no payload (i.e. 24oz), 19.9
minutes of flight time can be achieved. The graph was extrapolated to
predict the flight time for heavier payloads but it might not necessarily
be realised in reality.
3.6Design Implementation and Final Structure

Having considered the numerous factors to choose component
parts, the eventual implementation of the design was both mechanical
and electrical in nature. Basic mechanical work was done with regards
to the construction of the structure. Minor cutting of the Carbon Fibre
rods and drilling was done. Two acrylic pieces were added as a final
design decision to provide two different levels. The bottom level is
used to store wiring and the battery and the upper level is where the
logic unit is situated. Minor electrical skills were also required to solder
the component parts and wire them. Figure 10 shows the top level
wiring diagram and
shows the final design.

University
2010
Figure 10: Wiring Diagram for IMR

University
2010
Figure 11: Final Design
40Stability and Manoeuvre

There are obviously many factors that affect the flight of the
Quadcopter. The collaboration of components as previously described
is a core factor that determines whether the Quadcopter can take flight
or not; the sections to follow describe ways to stabilize the Quadcopter
when it is in the air as well as the constraints on the system that will
allow us to steer the Quadcopter.

University
2010
4.1Filtering Noise
A clean analog signal is almost impossible to get. It is always
littered with noise whether it is from the AC signal from the outlets that
add 60Hz noise or mechanical motors that cause vibrations. This noise
usually cannot be completely removed but needs to be minimized in
order to get the data that we need. A Second Order Complementary
Filter was used to remove the noise from the accelerometers and
gyroscopes caused by a variety of sources from electrical to
mechanical.
4.1.1Noise Reduction
To obtain the desired signal, it is theoretically possible to use a
filter and isolate the desired signal. Reality is, it is harder than it
sounds. There are many uncontrollable variables ranging from
predictable (such as 60 Hz AC noise) to unpredictable (such as
mechanical vibrations and wind) which may add noise to the system
and make it more difficult to isolate for the desired signal. It is
extremely difficult to eliminate all noise from any given signal. The
noise is mixed in with the desired signal and simply applying a filter
may not be able to remove the noise without also potentially removing
the signal. In fact, it is impossible to remove just the noise without
attenuating the signal if the frequencies overlap or if there are
common frequencies. For this reason, the Signal to Noise Ratio (SNR),
the power ratio between the signal and noise, has more value in noise
reducing processes and is more frequently used in practice. For the

University
2010
purposes of this project, moderately controllable variables such as the
weather and wind are removed by testing in an open space that is
indoors with relatively low draft. Mechanical and electrical noise from
the equipment is monitored and removed as much as possible without
distorting the desired signal itself using a Second Order
Complementary Filter.
4.1.2Second Order Complementary Filter

A complementary filter is a filter with a derivative feedback
through the filter. () The order of a filter determines how many
components that is required. The high level design for a second order
filter requires two integrals from the inputs to the output. Therefore, a
Second Order Complementary Filter is one with two integrals, with the
value of the output being fed back between the first and second
integral. A block diagram of the Second Order Complementary filter
can be seen in Figure 12.
Figure 12: Second Order Complementary Filter()

University
2010
Theoretically and through experiments, it can be seen that the
Second Order Complementary Filter performs drastically better than a
First Order Complementary Filter and without wasting too much more
computation time. It can be seen that a Second Order Complementary
Filter removes the noise from the sensors quite well and leaves a
relatively clean signal as compared to the signal received (refer to
Figure 13).
Figure 13: Second Order Complementary Filter()
4.2Feedback Control
As with most control systems, the time it takes for the system to
reach Steady State is of utmost importance and is part of the tradeoffs
that must be taken into consideration. A system must respond in a

University
2010
timely manner. There are many factors that may affect the response
time but a couple of major factors affecting Transient Response:
Computing/executing speed of system, Communication delay.
Computing speed of system is dependent on the speed of the
microcontroller used, but as processing speed is getting faster and
faster, finding a microcontroller that is fast enough has become less of
a problem. Execution at the optimal speed and with the optimal
response is still very important. There are methods used in control
engineering that optimize the speed at which the system reaches
steady state. Communication delay is inevitable with any system. We
can only ensure that we allow enough time for the message to be
received before re-sending a signal. Further considerations will be
discussed in Section 6.0 Wireless Communication.
4.2.1Six Degrees of Freedom (DOF)

The principle is that a rigid body in three dimensional (3D) space
has six independent ways it can move (or six DOF). The movement
can either be translational or rotational about the X, Y, and Z axis or
combinations thereof (Figure 14). In flight terms, the axes are called
Roll, Pitch, and Yaw. The Roll is tilt from side to side. The pitch is the
elevation of the front. The yaw is the direction of movement relative to
the desired projection, also referred to as side slip. Constraints are
needed for each DOF in order to restrict or enable movement in 3D
space.

University
2010
Figure 14: Possible independent movements in 3D space()
4.2.2System Control Theory

To control an object in 3D space that is free to move about, all
six DOF must be monitored for unplanned directional changes and
adjusted accordingly. Adjustments can either be done manually or
with an automated control system to ensure the object is of the correct
orientation and angle. Control Systems can be classified in to three
categories: Open Loop, Feed-Forward, and Feedback.()
Open Loop Controllers, also referred to as Non-Feedback
Controllers, are useful for systems where the system inputs are directly
related to the system outputs and the desired system state, usually by
a mathematical formula. Feed-forward Control Systems are generally
used when the effect of an input or command to the system produces
a predictable output. Feedback Systems (or Closed-Loop Systems) are
causal systems that are mostly used in systems that require
adjustments and possibly machine learning. The output of causal
systems depends on the previous output(s) of the system. For

University
2010
Feedback System, the output is determined by comparing the previous
output signal and the reference signal. ()
Figure 15: Types of Control Systems: (a) Open Loop (b) Feed-Forward (c)
Closed Loop()
As seen in Figure 15, different types of systems will react
differently to disturbances to the system. From the description of the
project and from the descriptions of the types of systems, a Closed
Loop Feedback System is the most suitable for a Quadcopter that must
adjust according to the sensors that determine its orientation and
direction. There are two types of Feedback Systems: Positive
Feedback Systems and Negative Feedback Systems.()

University
2010
Positive Feedback Systems are causal systems that amplify any
small disturbances to the system. A small perturbation can cause the
system to grow relatively quickly. This is useful when the output of the
system needs to be magnified or enhanced.() In the case of a
Quadcopter, a Positive Feedback Systems would ultimately magnify
any noise present in the system and destabilize the system.
Negative Feedback Systems are also causal systems, but instead
of amplifying any small perturbations they will make up for any
discrepancy between the desired output (according to the input) and
the actual output so that the system can reach the desired output.()
The output of the system is the signal that is fed back into the system.
The difference between the desired signal and the signal fed back is
the command error and will determine how the system should react. If
the desired signal and the feedback signal match, the command error
is zero and the system has reached the desired state.
Along with how a system will reach a stable state is how quickly
a system can reach that steady state. The time it takes to reach
steady state is dependent on the damping of the system. A system
can be described to be underdamped, critically damped, or
overdamped. An underdamped system will overshoot the steady state
value and oscillate about the steady state value before it reaches
steady state. The more underdamped the system, the higher the
amplitude and number of the oscillations. A critically damped system

University
2010
is a system that reaches steady state as quickly as possible without
overshooting the steady state value. An overdamped system will
reach steady state without overshooting the desired value but over a
longer span of time. The dampness of a system is represented by the
damping constant, ζ. If 0 < ζ < 1, the system is considered to be an
underdamped system which means the transient response is
oscillatory. If ζ = 1, the system is described as critically damped and if
ζ > 1 the system is overdamped, as seen in Figure 16.()
Figure 16: How the damping constant affects the time it takes to reach
steady state()
Because of the nature of the system for a Quadcopter, manual
adjustments are very difficult as the response must be instantaneous,
yet human reaction is only so quick. Thus, to steer the Quadcopter, we
must resort to a mechanical-electrical solution: Accelerometers and

University
2010
Gyroscopes. These mechanisms will help direct and control the
direction of motion of the Quadcopter by outputting any possibly
unwanted changes to the system.
4.2.3Proportional, Integral, Derivative Controller

A Proportional, Integral, Derivative (PID) Controller contain three
terms (controllers) that are used to control the gain and thus the
overall response time of the system: Proportional, Integral and
Derivative. PIDs calculate the difference between the output value
and a set desired input value and use it to calculate and control the
gain of the system and maximize the response time. The Proportional
Controller determines the reaction to the current error, the Integral
Controller sums the recent errors and provides a better steady state
response, the Derivative Controller enhances transient response but
uses the rate at which the error has been changing and therefore can
be unpredictable and cause a lot of jitters. Together, the three terms
are used to control the gain and response time of the system. The
tradeoff for speed is how much the system will oscillate. For a system
like the Quadcopter, too much oscillation is undesirable so the gains
will be set accordingly.
The time domain transfer function can be seen and derived
fromFigure 17. The S-Domain transfer function of a PID is: H(s) = K P +
KI/s + KDs = KDs2 + KPs+ KI. Using the S-domain transfer function, one
can determine where the poles and zeros of the system are. The poles

University
2010
are at the denominator factors and the zeros are at the numerator
factors for a fully factored transfer function. For a system to be stable,
all poles must be in the open left half plane (OLHP). If there are any
poles in the open right half plane (OLHP), the system is considered
unstable. Any poles on the imaginary axis is considered marginally
stable (or pure oscillatory). The closer the poles are to the imaginary
axis, the quicker the response, but at the same time the system can
become more oscillatory which is undesirable for a Quadcopter. Over
time, it is expected that the error in the feedback loop approach zero:
the steady state of the system with the current input.()
Figure 17: PID Controller loop()
4.2.4Feedback Control Mechanism: Inertial Measurement Units

Inertial Measurement Units (IMU) are widely used to manoeuvre
and control the direction of moving objects from airplanes to satellites
to rockets. It consists of a combination of accelerometers and
gyroscopes. As previously discussed, for a system such as a
Quadcopter, the system would need to constrain all six DOF in order to
fully navigate the Quadcopter predictably. The three accelerometers

University
2010
can be used to constrain the translational motion along the three
independent axes and the gyroscopes can be used to constrain the
rotational motion about each of the three independent axes.
The accelerometer measures the acceleration relative to the
frame and acts as a motion sensor to determine the direction and
orientation of movement. It would firstly need to be zeroed for a
certain plane. That plane would then be the position of rest. The
output of an accelerometer is simply a voltage level that is increased if
the accelerometer is tilted to one direction, or decreased if it is tilted in
the other direction. From the output of the accelerometer, one can
determine the angle at which the Quadcopter is currently at. With
three accelerometers placed perpendicular to each other, one can
determine the angle for each of the axes.
The gyroscope maintains the direction by detecting the change
in orientation. Gyroscopes maintain the orientation using the concepts
of conservation of momentum. The gyroscope continuously spins
about an axis. Once the spin is axis is skewed, the output will tell us
how the gyroscope is moved and what must be done in order to
balance it out again. As with the accelerometer, the gyroscope also
has to the zeroed to determine the rate of change at the desired
constant value (usually at rest). The gyroscope would then output a
certain voltage level when a change in orientation is detected and this
value can then be used to adjust the orientation accordingly.

University
2010
Using the one device without the other is simply not sufficient.
Both devices must be used in tandem in order to control both the
orientation and direction of movement of the Quadcopter. PIDs will
determine how fast it will reach that steady state while accelerometers
and gyroscopes determine the direction and magnitude of adjustment
required to reach steady state due to the inputs. Both the gyroscopes
and accelerometers can be found in compact forms in an integrated
chip the size of a quarter.
4.2.5Feedback Control Loop

Now that we have generally described all the desired
components that will help stabilize and manoeuvre the Quadcopter, we
can put the components together. A generic form for a feedback
control loop with the controller and sensors is:
Figure 18: Feedback loop including system, controller and sensor

configuration ()
We can replace the generic controller with our controller of
choice: the PID controller. Similarly, the System is our Quadcopter
(consisting of the structure, motors, propellers, etc.) and our output
sensors for the feedback loop are the three accelerometers and three
gyroscopes. Our feedback control loop design for the Quadcopter can
be represented by the block diagram below.

University
2010
Figure 19: Feedback Control Loop with control components
From Figure 19, one can follow the feedback loop to determine
the sequential output of each component. The difference between the
sensor outputs and the reference signal is determined which is then
used by the PID to determine the optimal input to the Quadcoptor so
that the output of the system is as desired (the system output being
the flight orientation and direction). The accelerometer and gyroscope
outputs will then be fed through the filter and the measured command
error will be again calculated. The filter was added after the sensor
data and before calculation of the measured command error so that it
can remove the noise from the sensors before using the signal in any
component of the system.
It should be understood that each control component uses a
different controller. The Quadcopter system as a whole can be split
into different subsystems. The PID values for the Roll control may be
different than that of the Pitch, Yaw or Throttle. In addition to those
PID controllers, there are also different PID controllers for the auto-
levelling (or stabilization) of the Quadcopter to try to optimize the
response to a disturbance to the system.
4.2.6Flight Tuning Using Ziegler-Nichols Rules

University
2010
Many systems can be easily modelled mathematically and an
analytical approach to determining the values for the PID controller can
be used. For systems that are difficult to model mathematically other
approaches such as the Ziegler-Nichols Rule can be used to obtain an
educated estimation for the PID which can later be fine tuned further.
()
Type of KP KI KD
Controller
P 0.5KC 0 0
R
PI 0.45K 1.2/P 0
CR CR
PID 0.6 2/PCR 0.125P

KCR CR
Table 5: PID gain using Ziegler-Nichols Tuning Rule()
To use the Ziegler-Nichols Rule, one must find the critical gain,
KCR, and critical period, PCR, of the system. To find those two values,
one must set KD = 0 and KI = 0 for the PID Controller transfer function:
H(s) = KP + KI/s + KDs. Adjusting only KP, one must find the value that
causes the system to exhibit sustained oscillations. The gain at which
the system exhibits sustained oscillations, is known as the critical gain.
Using the frequency at which the system oscillates, one can find the
critical period. Then according to Table 1, one can choose the desired
values for the PID controller. According to the Ziegler-Nichols Rules,
this PID should exhibit close to optimal response for the system, with
perhaps minor fine tuning around these gain values.

University
2010
4.3Flight Configuration and Simulation

4.3.1Flight Configuration Methods and Tools
There are many variables that must be configured in order to
control the Quadcopter in flight. These variables are stored in EEPROM
and read before and throughout operation. There are two methods of
setting these variables: Using the Serial Monitor or with the aid of
AeroQuad Configurator v1.2.
The Serial Monitor is built into the Arduino development
environment. It allows for serial communication between the Arduino
board and the user computer via USB. This communication medium is
used to upload programs as well as to debug via print statements and
send and request flight configuration parameters.
Figure 20: Motor Command outputs (S) during simulation of flight with
Serial Monitor

University
2010
The commands to send and request flight parameters can be
found in SerialTelemetry.pde and SerialCommand.pde, respectively.
The commands need to be entered in the command line of the serial
monitor. To send or request a command, enter the letter
corresponding to the command, select send and the values will appear
in the Serial Monitor output screen below it. Refer to Figure 20 for the
outputs using the command ‘S’ which requests the motor commands
and various other flight parameters separated by a comma. In the
same manner, one can simulate flight (without propellers attached for
safety reasons) by tilting the Quadcopter and sending the ‘Q’
command to receive continuous sensor data to monitor the change as
the Quadcopter is being moved Figure 21.
Figure 21: Sensor Data output (Q) during simulation of flight with Serial
Monitor

University
2010
Alternatively, AeroQuad Configurator is an open source software
developed by AeroQuad to test and adjust flight parameters of the
Aeroquad before flight. This software can also be used to set various
parameters that control the flight of the Quadcopter such as the PIDs,
filter time constant, transmitter/receiver sensitivity, levelling limits,
etc. Its Graphical User Interface (GUI) is very straight forward and easy
to understand and use (refer to Figure 22). The values can be entered
into the corresponding box and updated by selecting the Update
button at the bottom right corner.
Figure 22: AeroQuad Configurator GUI with updatable flight parameters
In a similar manner, values such as the PID outputs, motor
speeds, sensor values, etc. can be plotted and seen in graphical form
with the AeroQuad Configurator Figure 23. The continuous time line

University
2010
graph helps one to visually see the oscillations occurring and the sizes
of the oscillations.
Figure 23: Various sensor outputs with AeroQuad Configurator GUI
There is known to be a few bugs with this tool when it comes to
setting these parameters. Even if it says the parameters have been
updated, it may not necessarily be so. The values should always be
double checked with the Serial Monitor before flight to ensure the
values were indeed written to EEPROM.
4.3.2Pre-Flight Tests
Before the Quadcopter takes flight, there is a list of tests that
should be executed. This is for the safety of everyone involved and
everyone in the vicinity of the Quadcopter while it is flying. It is to
ensure that the Quadcopter does not fall out of the sky and or crash

University
2010
into anyone. This could prevent damaging the Quadcopter as well as
prevent causing any bodily harm to oneself and others.
1. Increase the throttle to a point where all motors are spinning.
2. Tilt the Quadcopter to the left. The left motor should speed up.
The right motor command should slow down.
3. Tilt the Quadcopter to the right. The right motor should speed
up. The left motor should slow down.
4. Tilt the Quadcopter forward so that the front motor is lower than
the back motor. The front motor should speed up. The rear motor
should slow down.
5. Tilt the Quadcopter up (the front motor should be higher than the
rear motor). The rear motor command should increase. The front
motor command should decrease.
6. Rotate the Quadcopter clockwise. The front and rear motor
commands should increase.
7. Rotate the Quadcopter counter-clockwise. The left and right
motor commands should increase in value.
The above Pre-Flight Tests were referenced from
http://AeroQuad.info and modified for the Quadcopter.() There are also
communication related tests that will be described further in Section
6.0 Wireless Communication.
1.1.1Flight Control and Results

University
2010
As with many projects that rely on a variety of variables and
have a large amount of components that need communicate with each
other, this project encountered many issues during the integration
period of the development cycle. This section will discuss the results
and problems encountered for the flight components as well as the
approach to solve them. Further discussion on integration issues and
solutions will be discussed further in Section 8.0 Integration.
There were many issues that surfaced when the project moved
from the simulation phase to the flight testing phase with all the
components working together. Although the data output, graphs, and
reaction time during simulation were desirable and as expected, when
it came to flight testing and getting the Quadcopter to stabilize on its
own in mid air, it proved to be a more difficult task than anticipated.
Because of the propellers and the need for mobility, the flight
data during could not be downloaded while the Quadcopter was in
flight. It was expected that with all the hardware components working
simultaneously that some extra fine tuning would be required for the
PIDs, filter bandwidth, receiver sensitivity, as well as determining the
appropriate centre of gravity (CoG). A software compensation was also
made for the motors since the motors may not be able to use the same
voltage level to reach the same speed. All of the above considerations
were taken into account during the flight testing phase.

University
2010
Along with the meticulous positioning of all the components, as
previously described, light weights were added at the end of the
propeller arms as needed during testing to eliminate the CoG as a
potential problem causing the drifting. Enhancements to the structure
midway through the term to minimize the amount of vibrations were
also done to eliminate the idea, as much as possible, that the structure
was not rigid enough. Thereafter, work was done on the assumption
that most of the variables that can still affect the flight of the
Quadcopter lie in the software implementation and stability modelling.
As seen in video Video\PID_underdamped, the roll and pitch of
the Quadcopter will readjust when it is forced off its equilibrium
position. It can also be seen that this levelling PID combination causes
the system to oscillate many times before it reaches its equilibrium
point again. This is a sign that the system is very underdamped.
Similarly, Video\PID_overdamped, it can be seen that the system
takes some time to readjust as it relatively slowly moves back to the
equilibrium point. As previously stated, it is desirable to attain a
critically damped system. In practice, it is very difficult to attain and a
5% overshoot is considered desirable. In
Video\PID_closeToCriticallyDamped, it can be seen that the rate at
which it readjusts relative to the overdamped has visibly increased and
the number of oscillations and magnitude of oscillations has
significantly decreased.

University
2010
The above videos and oscillations were obtained with the
following KP values and KI = 0 and KD = 0 for the Roll and Pitch:
KP Observations
3.7 • Underdamped
5 • 3-4 oscillations before it stabilizes
4.7 • Close to critically Damped
5 • 1-2 small oscillations
5.7 • Overdamped
5 • Difficult to tip off axis. Resistant to
change
6.7 • Overdamped
5 • Very difficult to tip off axis. Highly
resistant to change
Table 6: Values of KP and corresponding qualitative observations for
Ziegler-Nichols Rule
To use Ziegler-Nichols Rules for tuning PIDs, it is known that a
sustained oscillatory state must be found. The Roll and Pitch PIDs were
programmed to have a KP of 4.75 which has, thus far, the most optimal
response. It can be seen in Video\PID_sustainedOscillation that with a
levelling KP of 6 and KI = 0 and KD = 0 (for both the pitch and roll), one
can get the system to exhibit a sustainable oscillatory state.
Therefore, with Ziegler-Nichols Rules, the PID gains that will have the
optimal response should be KP = 3.6, KI = 2.22 and KD = 0.1125 (refer
to Table 6: Values of KP and corresponding qualitative observations for
Ziegler-Nichols Rule). The response for this set of gain values
remained relatively oscillatory (Video\PID_ZieglerNichols). Although,
the Ziegler-Nichols Rules does state that fine tuning may be required
as the gain values are only estimates for the optimal gain values.

University
2010
As the project progressed, the issue with the drift was narrowed
down to the collaboration of PIDs and zeroing the sensors
appropriately. The Quadcopter demonstrates the ability to readjust if
it is pushed off the equilibrium state therefore the sensors are
outputting appropriate values to cause this to occur. It was
determined that if the sensors were zeroed at an angle, the
accelerometers would take that to be the zero point and adjust the
output accordingly in order to move the system as a whole back to that
angle (if no pitch and no roll were initially applied). Further testing
should be done to ensure proper collaboration between the PIDs and
sensor output values.
10Wireless Communication (Server)

1.1Communication System Overview
As it is stated in the problem statement, the aim of the project is
to control and manoeuvre a Quadcopter wirelessly over the internet.
An overview of the communication system for the Quadcopter is shown
in Figure 24, where a client process communicates with a Wi-Fi chip on
board a microcontroller, via internet.
The internet is used widely around the world and thus one of the
advantages of implementing this design is so that eventually it can be
widely used. Different wireless standards were considered so as to be
able to connect the Quadcopter to a wide Local area network that is

University
2010
configured to access the internet. Some of the standards looked at
include ZigBee and WiFi for wireless personal area networks (WPANs),
which are discussed further in section 6.2 of this report.
The ideal design implements the TCP protocol in the uplink and
UDP protocol in the downlink as shown in Figure 24. TCP is used in the
uplink for control commands and UDP is used in downlink for feedback.
This design is choice is verified by examining the different protocols
and their advantages and disadvantages as described in section 6.3.2.
However, due to a re-definition of project goals mid-way through the
project to exclude parts of the original goals such as video feedback,
the communication system had to be re-designed to reflect this
change. This is discussed in section 6.3.2 and an updated
communication system is shown later in Figure 26 of section 6.3.2 to
illustrate the change in project goals.
Figure 24: Original Communication System Design
With the standards mentioned above, a number of things had to
be looked at, such as the choice of the WiFi chip to work with the
selected Arduino Microcontroller. Furthermore depending on the type
of feedback, appropriate transport protocols were chosen. The
following sections illustrate the different design options explored and
the solutions chosen for the project. Furthermore, the operations of the

University
2010
WiFi Chip as well as the challenges faced in implementations and the
respective solutions are also discussed in detail.
1.2Wireless Standards
For our project purposes, an RF transceiver module was needed
to communicate with a remote client process as well as the Arduino
Microcontroller so as to control the Quadcopter. Several RF modules
were investigated for different wireless standards, and some have
been detailed in the following sub sections. The solution for the project
is also identified and discussed in the subsequent sub sections.
1.2.1ZigBee
ZigBee is a wireless mesh networking standard that is based on
the IEEE 802.15.4 specification for WPANs. The technology behind
ZigBee is simpler and less expensive. Due to its low cost, the
technology can be widely deployed in wireless control and monitoring
applications, for instance home automation. ZigBee is targeted at
radio-frequency (RF) applications that require a low data rate, long
battery life, and secure networking. The low power-usage allows longer
life with smaller batteries, and the mesh networking provides high
reliability and larger range ().
XBee RF transceiver modules are embedded solutions providing
wireless end-point connectivity to devices. These modules use ZigBee
networking protocol for fast point-to-multipoint or peer-to-peer

University
2010
networking. They are designed for high-throughput applications
requiring low latency and predictable communication timing ().
The XBee chip is ideal for our quad-copter communication
purposes and is designed to work with the Arduino Microcontroller.
However, since the client application accesses the internet, there
needs to be a device that connects the XBee module to a wireless local
area network (WLAN), simply because the standards used for WLANs
and XBee’s are different and hence translation is needed ().
ConnectPort X4 gateway is a router that is capable of connecting
an XBee module with a WLAN; it provides IP Network connectivity to
WPANs. This Gateway collects data from XBee chips and sends it to
client application on a WLAN, using Ethernet. The Gateway however is
very expensive and costs $449.0 separately ().
One of the goals of the project is to minimize the overall cost of
the project and thus this option was deemed too expensive for our
purposes.
1.2.2Wi-Fi
Wi-Fi is a specification based on IEEE 802.11 standard. Devices
configured to run Wi-Fi can connect to the Internet if they are within
range of a wireless network connected that can access the Internet.
Wi-Fi also allows communications directly from one computer to
another without the involvement of an access point. This is otherwise
known as ad-hoc mode of Wi-Fi transmission ().

University
2010
WiShield is an RF transceiver that brings Wi-Fi connectivity to the
Arduino platform. This shield was built specifically for the Arduino
platform and allows throughputs of 1Mbps and 2 Mbps. It uses low
power and implements ad-hoc as well as access point Wi-Fi
transmission. Furthermore, it has the ability to create secured
networks with different encryption mechanisms().
With just a few configuration parameters to set, this device
connects directly to a WLAN. No translations are required in terms of
wireless standards and thus no additional costs were incurred. Due to
its low cost, specifications and its ability to directly connect to a WLAN,
this option was deemed the best solution for our project purposes.
1.3WiShield Configurations
As discussed in the section 6.2.2, the Wishield has different
configuration alternatives. Options are available for the type of
network, transport protocol and encryption mechanisms. The following
subsections elaborate more on the available choices and solutions for
our project.
1.3.1Network Type
The WiShield has in-built implementations of wireless area
network connectivity using either access points or ad-hoc networks.
Access Points:
With Access points such as routers, different security encryption
mechanisms are implemented such as Wired Equivalent Privacy (WEP)

University
2010
and W-Fi Protected Access (WPA) algorithms. Connection to a specific
wireless area network requires re-configuring routers to reserve an IP
address specifically for the WiShield. To connect to these access
points, encryption keys have to be specified as part of the WiShield
configuration.
Ad-hoc:
Ad-hoc provides direct communication between the WiShield and
a remote PC. Similarly, for security purposes, encryption keys can be
specified. Ad-hoc network provides for easier debugging conditions, as
it eliminates an extra variable; that is the access point.
Therefore, for our development and testing conditions, ad-hoc
network was used. This configuration worked very well in the course of
development of the software for wireless communication.
1.3.2TCP vs UDP
The WiShield has two alternatives in terms of transport protocols
that can be implemented. These protocols were provided as
independent applications and therefore only one at a time could be
used for communication purposes. The protocol applications provided
in the WiShield are those of UDP and TCP. The following subsections,
elaborate in detail how the protocols work, their advantages,
disadvantages and how they fit in the goals of the project.
TCP:

University
2010
TCP is the transmission control protocol. TCP provides a
communication service at an intermediate level between an
application program and the Internet Protocol (IP). TCP is connection
oriented; it uses the three-way handshake to establish a connection
between two communicating parties as illustrated in Figure 25. The
connection establishment process begins with the client process
attempting to connect to the WiShield by sending a synchronization
(SYN) message. The WiShield then replies to this SYN message with an
acknowledgement (ACK) to signify that a connection has been
established and that data transfer can begin. As part of the three-way
handshake, the client then replies by sending an ACK to acknowledge
that a connection has been established.
Figure 25: TCP three-way handshake

University
2010
TCP is a reliable stream delivery service that guarantees delivery
of a data stream sent from one host to another without duplication or
losing data.
Since the packet transfer is done wirelessly and wireless
channels are not reliable, a technique known as positive
acknowledgment with retransmission is used to guarantee reliability of
packet transfers. This fundamental technique requires the receiver to
respond with an acknowledgment message if it receives the data. Each
packet sent by a source has an identifier or a sequence number, and
once the packet is sent, the sender waits for an acknowledgment
before sending the next packet. Hence the packets arrive in order at
the receiver side of the communication, guaranteeing reliability. To
account for lost packets, a timeout is set and if this time expires then
the packet is re-transmitted.
TCP is optimized for accurate delivery rather than timely
delivery, and therefore, TCP sometimes incurs relatively long delays
while waiting for out-of-order messages or retransmissions of lost
messages. It is not particularly suitable for real-time applications such
as Video or Voice over IP. ()
TCP implements the mechanism known as congestion control,
which in theory throttles the sender side if the network is congested.
Throttling of the Sender can have huge negative impacts in terms of
real-time applications.

University
2010
UDP:
With User Datagram Protocol (UDP), computer applications can
send messages, in this case referred to as datagrams, to other hosts
on an Internet Protocol (IP) network without requiring prior
handshaking to set up transmission channels or data paths. The client
must explicitly attach IP address and port of destination to each
packet. The server must then extract the IP address and port of the
client from the received packet. Equipped with this information, the
server can reply to the appropriate client with the proper information.
()
Thus, UDP provides an unreliable service and datagrams may
arrive out of order, appear duplicated, or go missing without notice.
UDP assumes that error checking and correction is either not
necessary or performed in the application, avoiding the overhead of
such processing at the network interface level. ()
UDP is used best in real-time applications such as Voice over IP
and Video Feedback as these applications can tolerate loss of packets
rather than huge delays in the network packets as in the case of TCP.
Table 7 shows the advantages and disadvantages of UDP and TCP.
Based on the comparison, the appropriate transport protocol was
selected for the Quadcopter operations.
Category TCP UDP
Reliability Reliable Unreliable

University
2010
Connection Has states Stateless

States
Congestion Yes No
control
Overhead More Less
Table 7: Relevant differences between TCP and UDP
From Table 7, it can be concluded that TCP is best where reliable
communication is needed; in this case for the Quadcopter control
commands. UDP is best for real-time applications that can tolerate
packet loss; in this case if video feedback is implemented. Thus, the
ideal way of implementing the design is to use TCP for control
commands in uplink and UDP for feedback in the downlink as shown in
Figure 24Figure 24: Original Communication System Design of section 6.1.
The project goals were re-defined earlier in the course of
development of the project to exclude video feedback. Hence the
feedback connection was implemented using TCP, as seen in Figure 26.
Moreover, as discussed in section 6.3.2, the WiShield only implements
one application at a time, either UDP or TCP; this is consistent with the
re-defined project goals.
As a note, for future groups that may undertake a similar project,
a separate Wi-Fi chip will be needed to take care of video feedback; if
video feedback is a priority.

University
2010
1.4WiShield Functionality
Figure 27: WiShield Functionality
As described in Figure 27, once the code is loaded into the
WiShield, network parameters such as source IP address, destination IP
address, network type as well as the security type are configured first.
Once the parameters have been configured and verified, the Wishield
Figure 26: Re-designed Communication System

will attempt to connect to a WLAN using the parameters specified. If
the connection cannot be established, then it will keep on trying to
connect. Once the connection has been established, the connection
state updated and the code implementation proceeds to invoke a
function that handles the connection based on the Transport protocol
selected.
Figure 28: Handling TCP connection
The function Handlle Connection described in Figure 28, begins
by opening up a TCP socket at port 1000; port dedicated for TCP
communication on the WiShield. From there, the TCP connection state
enters a wait state, listening on this port for data to be transmitted
from the Client Application to its socket buffer. If the data is received,
it stores this data in the socket buffer. The data was then parsed to

University
2010
determine if it is valid or corrupted from the wireless transfer. The
routine then continues to invoke a function that runs the motors
accordingly. These control functions were implemented in the code
that runs on the Arduino microcontroller. The WiShield communicates
with the Arduino microcontroller through a serial to parallel interface
whose operation is described further in section 6.5. Once the
commands have been executed, the WiShield was programmed to
reply to the client application with the previous command executed.
Furthermore, the socket buffer was emptied to allow for new data to be
stored. The connection state was also changed to wait state to indicate
that the WiShield is waiting for a new command from the client
application.
1.5Serial Peripheral Interface

Serial Peripheral Interface also known as SPI bus is a
synchronous serial data link standard that operates in full duplex
mode. A full duplex mode is a system in which parties can
communicate bi-directionally simultaneously.
In SPI, devices communicate in master/slave mode where the
master device initiates the data frame and the slave device is the
recipient of this data frame. For communication between the
Microcontroller and WiShield, this approach is used ().
The SPI bus specifies four logic signals:
• SCLK — Serial Clock (output from master)

University
2010
• MOSI/SIMO — Master Output, Slave Input (output from
master)
• MISO/SOMI — Master Input, Slave Output (output from
slave)
• SS — Slave Select (active low; output from master)
Figure 29, shows these signals in a single-slave configuration, as
in the case of the Microcontroller-WiShield communication. SCLK is
generated by the master and is an input to all slaves; this case only
one slave. MOSI carries data from master to slave. MISO carries data
from slave back to master. A slave device is selected when the master
asserts its SS signal ().
For example, if the WiShield sends control commands to the
microcontroller, then the WiShield becomes the master which then
asserts the SS signal to select the microcontroller as the slave and the
communication proceeds.
Figure 29: SPI bus, single-master single-slave
For the WiShield, Digital pins 10 to 13 are allocated for SPI
purposes; communication with the Arduino microcontroller. These pins
are highlighted in Figure 30, which is the schematic of the WiShield RF
transceiver module.

University
2010
Figure 30: WiShield Schematic ()
During each SPI clock cycle, a full duplex data transmission
occurs in which:
•master sends a bit on the MOSI line; slave reads it from the
same line
•slave sends a bit on the MISO line; master reads it from the
same line

University
2010
Transmissions normally involve two shift registers of some given
word size, such as eight bits, one in the master and one in the slave;
they are connected in a ring. Data is usually shifted out with the most
significant bit first, while shifting a new least significant bit into the
same register. After that register has been shifted out, the master and
slave have exchanged register values ().
Then each device takes that value and invokes appropriate
functions with it, such as running motor functions in the case of
Arduino microcontroller. If there is more data to exchange, the shift
registers are loaded with new data and the process repeats.
With this serial communication process, if the SPI pins are in use,
then they cannot be used for any other purpose. As such, a challenge
arose in that digital pins 10 to 13 are also Pulse Width Modulation
(PWM) pins required for motor functionality. This challenge, along with
others is described in section 6.6. Solutions to these challenges are
justified in the same section as well.
1.1Challenges and Solutions

The following section describes the different challenges faced in
the duration of the project, in terms of design and implementation of
the wireless communication interface. The following challenges came
up and their respective solutions are outlined as well.
1.1.1Debugging

University
2010
The software development is done using two languages, Arduino
language and Embedded C. Arduino language is used to initialize and
run the WiShield where as C language is used to program the server
implementation of the WiShield. The WiShield presents a major
problem when it comes to debugging a program implementation, as
there is no integrated development environment (IDE) that comes with
the product. The WiShield only comes with a simple compiler that
verifies the correctness of syntax. Figure 31 shows the simple compiler
that comes with the WiShield.
As a solution to this problem, a somewhat different approach was
used. Debugging statements were added into the outgoing packets
and then verified in the client application which runs on a remote PC.
With this approach, if an execution reaches a point in the code that
needs to be debugged, then at this point comments were inserted into
the outgoing packet. At the client process depending on the comments
displayed, it was possible to know exactly where the execution of the
code reached. This presented us with a direction in which to follow in
the process of server implementation on the WiShield.

University
2010
Figure 31: Simple Compiler provided for WiShield
1.1.2Pin Conflict
The biggest challenge faced in the implementation of the WiFi
communication is Pin conflict. As mentioned in section 6.5, Pins used to
interface the Arduino board with the WiShield, otherwise known as SPI
pins were also used as Pulse Width Modulation (PWM) Pins for motor
control. The pins in conflict were digital pins 10 to 13 as indicated in
the schematic provided for the WiShield in Figure 30 of section 6.6. In

University
2010
proper operation, these pins are used for only one purpose, either SPI
communication or Motor control.
There may be different ways of solving this problem, but the best
solutions considered by our group are briefly illustrated in this section.
A detailed explanation of the actual integration process is given in
section 9.0.
The first solution considered was generation of PWM signals in
software. With these signals, there was no need to use PWM pins to
control the motors. Instead, any digital pin other than the SPI pins
could be used for motor control. Hence digital pins 10 to 13 could be
used for SPI communication purposes only. This solution is the best
solution; nevertheless because of time constraint on our part, as more
effort was put in quad-copter stability, this implementation was not
feasible.
The second solution was to use two microcontrollers. A primary
microcontroller (PM) was used only to run the stability and
maneuvering software. A secondary microcontroller (SM) stacked with
a WIShield was used solely for the purpose of Wi-Fi communication
with the remote client application. The PM was then connected to the
SM physically using wires on certain pins. The digital pins 10 to 13
need not be avoided, as the WiShield did not use the SPI interface to
communicate with the SM. This solution was implemented successfully
and the demonstration was recorded and shown on the poster fair. The

University
2010
complete integration process which uses this implementation is
explained in detail on section 9.0 of this project report.
20Wireless Communication (Client)

A client is an application or a system which requires remote
service from another system, usually a server. The following section
describes how the client system developed satisfies the project’s
objectives.
The objective of the client system was to control the quad-copter
through a graphical user interface. The client system is developed in
order to provide service to the user. In the overall communication
system the user is referred to as the client since the user is one that
sends requests to Wi-Shield mounted on the Arduino microcontroller.
2.1Client Design
Earlier in the winter term, a client script was written in Arduino
language and embedded C. This script was developed concurrently
with the server script to establish a wireless communication between
Wi-Shield and a user, in this case a user running on Fedora 10
operating system. This communication was achieved through an ad-
hoc network between a laptop running Fedora 10 environment and Wi-
Shield.
Initially, UDP protocol was implemented in the wireless
communication between the client and the server script. UDP protocol

University
2010
was chosen since live video feedback was one of the user interface
objectives. However, after re-definition of the project goals mid-way
through the year, live video feedback was excluded. Therefore, this
exclusion of live video feedback influenced the change in transport
protocol. The client and server script which were implemented using
UDP needed to be redesigned to employ TCP protocol.
The following figure illustrates the ideal behaviour of how the
client system should interact with Wi-Shield.
Figure 32: Ideal Layout of Client System in relation with WiShield
User, who is also the client, utilizes the user interface to select
which command the quad-copter should execute. This command is
formed into an IP packet and then sent over the internet to the server
which is running the XAMPP services. The server executes the PHP
code and sends the appropriate manoeuvre command to the Wi-Shield;
in turn the Wi-Shield calls the C subroutine which turns the motors
accordingly. After receiving the manoeuvre command, Wi-Shield sends
a reply back to the server, in turn sends the reply back to the client
which is displayed through the user interface.
Figure 33: Actual Implementation of Client System in relation
with Wi-Shield illustrates implementation of communication between
Wi-Shield and a user, and how the client system actually interacts with
Wi-Shield.

University
2010
Figure 33: Actual Implementation of Client System in relation with Wi-

Shield
In contrast with the ideal behaviour of the client system
described above, user, in this case, is a system which is running on
Fedora 10 platform; and in addition the system also has locally
installed and running XAMPP services. The locally running XAMPP
services on the user system is necessary since during the development
phase the web browser, which embodies the user interface, was not
hosted on a server in order to keep the project cost down and
moreover, was not essential to the development phase.
User selects which command the quad-copter should execute
through the user interface. This command is embodied into a packet
along with the PHP and HTML code. The locally running XAMPP services
execute the PHP code in the packet and forward the embedded
manoeuvre command to the Wi-Shield over the Ad-Hoc network. Once
Wi-Shield receives the command, it calls respective C subroutine which
turns the motors accordingly. Subsequent to the receiving of the
command, Wi-Shield sends a reply back to the user. The XAMPP

University
2010
services encase the reply with appropriate PHP and HTML code and
display it on the web browser.
Figure 34: Client Design
Figure 34 illustrates the way the client side communication was
designed to operate. Upon invocation, the client script setups a socket
and initializes the connection by binding a port in the computer. After
the connection is setup, it asks the user to input a move, where the
user would like the quad-copter to move to. If the input provided by
the user is valid and within predefined commands then the input is
sent to the Wi-Shield through the setup connection. Afterwards, the
client waits until it receives a reply from the Wi-Shield and then asks
the user for another move.
2.2Client Process
Figure 35 describes process which was developed and followed
on the client side of wireless communications.
Initially, user selects which command to send to the quad-copter
through the web user interface. The selected command is then sent to
the client process through “from User” stream. The client process
sends the command to the server via “to Server” socket. The server
with XAMPP services receives the command and processes it. After
processing the server sends a reply through “from Server” socket.
Client process reads the reply and sends it to the user interface via “to

University
2010
User” stream. Once the user interface receives the reply, it displays
the reply to the user through the web interface.
Figure 35: Client Process

University
2010
30User Interface
User interface was developed using HTML coding with embedded
PHP scripting. HTML was used to develop the basic structure of the
user interface, such as the titles, buttons and etc. PHP was used to
implement the client code developed earlier in the term.
Figure 36: User Interface
As seen in the following figure, using PHP the layout of the user
interface was successfully divided into menu, header and frame
partitions.

University
2010
Figure 37: Components of the User Interface
Figure 37 illustrates the components of the user interface and
the purpose of the components. In the “Frame” area, there is an image
which shows where the live video feedback would be visible, if in the
future a camera is mounted on the quad-copter. Moreover, a display
box below the image lists all the previous commands sent, if the user
wants to track the movement of the quad-copter since the initial start.
Below the display box are the basic controls of the quad-copter such as
left, right, up, down and hover.
3.1Software Requirements
All software used to develop the user interface and the client
side communication codes are open source software, in other words
free. They were obtained through the respective official websites.
3.1.1Operating System

University
2010
The client side communication code was developed using the
Arduino Programming environment. However, the
client code which communicates with the Wi-
Shield had to be executed in Linux environment.
Therefore, Fedora 10 was used as the operating
system for the client side communications.
Fedora is free open source operating system which is based on a
Linux environment. Release 10 of Fedora was installed and used for
the project since it is fairly new and stable. However, in future newer
releases of Fedora can be used, since Fedora supports backward
capability ().
3.1.2XAMPP
XAMPP is a tool which allows website
designers and programmers to test their work
on their own computer without any access to
the internet. To simplify the development and
testing process, most of the security features
were disabled by default. However, these
security features can be enabled once the
website is on the internet ().
XAMPP for Linux with version 1.7.3a was installed.
The XAMPP 1.7.3a package contains:
• Apache Web Service

University
2010
• PHP Service
• PHP extensions
• MYSQL Database
• Perl
• Server Side Includes (SSI) and etc.
Due to various scripting services, Apache Web service, SQL
Database support and many more functionalities, XAMPP package
offers great varieties of functionalities which will be useful for future
scalability of the wireless communication between Wi-Shield and user
interface ().
Apache Web Server is used as a host
server for websites with static and dynamic
content. A locally installed version of Apache
is useful when developing web applications
since the programmer can preview and debug the code during
development phase. Moreover, Apache also provides server-side
programming language support for scripts including but not limited to
Perl and PHP ().
PHP is a scripting language designed for
web development in order to produce dynamic
web pages. This is achieved by integrating PHP
code with HTML code. Moreover, a server which hosts a website with
embedded PHP scripting needs a PHP processor module in order to

University
2010
execute the PHP code. However, most of the web host services offer
free PHP support on their servers, thus making use of PHP to develop
website even more cost effective. During development phase, PHP
service was enabled on the client computer().
During development and testing phase of the project only the
following services were enabled while using XAMPP:
• Apache Web Service
• PHP Service
• PHP extensions
1.1Challenges and Solutions

Various challenges were dealt with during the research,
development and testing phase of the client system.
One of the issues stumbled upon was the Wi-Shield connectivity
problem. While developing the primary server and client
communication earlier in the development phase, there seem to be no
response from the Wi-Shield to the client even though all the code
seemed to be accurate and properly thought out. There was no
network setup phase that even occurred as intended. The Arduino
Programming environment did not come with any debugger tools
which could be used to fix the code. This obstacle was overcome by
the use of Wireshark, which is an open-source network protocol
analyzer. It is used to troubleshoot networks, communications protocol
development. Wireshark achieves this by analyzing the packet traffic

University
2010
through the system, which it is installed on. With the help of Wireshark,
it came to attention that the client was sending “Gratuitous ARP
request”, which is an Address Resolution Protocol request packet
where the source and destination IP are the same. This pointed out the
error in the Wi-Shield header file, which asked for the wrong IP address
as an input. It should have asked for the client IP address rather than
its own IP address ().
Moreover, another issue developed when integrating User
Interface code and client code developed earlier in the term. Proper
manoeuvre code in client code needed to be called when a specific
button was clicked. For example, the client code that sends the Left
command must be called when user clicks on the Left button.
Therefore, PHP code must call the client code, written in C language,
each time a direction button is clicked. However, a C function call
made in PHP doesn’t execute when the button is clicked; it executes
when the page loads. This behaviour occurs due to the fact that PHP is
a server side script; in other words, PHP is executed on a server which
hosts the website. In order to get around this problem, PHP form
method can be employed. After clicking on a button, the PHP code fills
out a “form” with the C code embedded within the PHP code and sends
it to the server; which executes the PHP code and forwards the
appropriate manoeuvre command to Wi-Shield. For example, if Right
button was clicked, the PHP code for that button with the embedded C

University
2010
code will be sent to the server as a form entry. Afterwards, the server
would execute the PHP code and send turn Right command to Wi-
Shield().
20Software Integration
This section discusses the software integration of the Wi-Fi
communication module with the embedded system module that was
responsible with stability and manoeuvring of the Quadcopter.
As discussed in chapter 6.6.2, the solution chosen was to
introduce an independent Secondary Microcontroller (SM). A Primary
Microcontroller (PM) was used solely to run motors and control the
motion of the Quadcopter. The SM was used with the WiShield for Wi-Fi
communications purposes only. The WIShield thus does not have to
communicate with the SM through the SPI interface, as the Quadcopter
control software was uploaded onto the PM.
With this configuration, an interface between the two
microcontrollers was needed so that they can communicate and
exchange control commands. To do this, wires were used to physically
connect the microcontrollers on some digital pins. Control commands

University
2010
were sent from the SM to the PM, which then consequently ran the
motors appropriately.
Each wired connection was used to indicate a control command
sent from the client application. With this process, every control
command from the client process requires usage of two pins, one on
each microcontroller. Some of the commands used to run the
Quadcopter include start, stop, increase revolutions and decrease
revolutions. An example is provided below to show how the two
microcontrollers communicate when a start command is issued from
the client application.
This example illustrates the course of action that takes place
when a start command is issued. To start up the Quadcopter, the client
application issues a command that is received by the WiShield that is
mounted onto the SM. The WiShield process then turns the voltage on
digital pin 5 of the SM to +5V. Digital pin 5 of the SM is physically
connected to digital pin 32 of the PM using wires as shown in Figure
38. Turning digital pin 5 to +5V forces pin 32 on the PM to change its
voltage to +5V.
The WiShield process then waits for 10ms to change the voltage
on pin 5 back to 0V. This again forces digital pin 32 back to 0V. The
motor control process was programmed to poll pin 32 once every 2ms;
to inspect any change in the voltage of the pin. Since the voltage on
the pin is programmed to remain at +5V for 10ms and the motor

University
2010
control process takes 2ms on average to run, it provides enough time
for the motor control process to read this command and respond
accordingly. For all the control commands, dedicated pins were used
and polled as described in the example above.
WiShield
Figure 38: Pin 5 of SM (with WiShield) connected to digital pin 32 of PM

using a wire()
The addition of the secondary microcontroller however adds to
the overall weight of the Quadcopter. The overall weight of the copter
becomes 1Kg. This does not present a problem as the motors chosen
are capable of lifting up to 2 Kg of weight. Furthermore, the batteries
used, can power both the microcontrollers and provide up to 5 minutes
of flight time before they drain. The integration process was

University
2010
implemented with apparent success and the two microcontrollers
communicated as expected.
30Production Expenses
3.1Material Costs
Unit
ITEM # Total NOTE
Price
Tower Pro 2410-09 6 US $6.39 Brushless Motors
Tower Pro Brushless
6 US $9.99 Brushless Speed Controller
Speed Controller
TowerPro Alloy Stick Mount for the motors that
4 US $2.00
Mount for Motors also act as heat sinks
Carbon Fibre Tubing 4 US $2.62 750x6mm
US $187.90 Propeller saver that
Prop Saver with 3mm
1 US $3.99 prevents propeller from
Bands
breaking free
Rhino 2150mAh Lipoly
2 US $9.69 Rechargeable Battery Pack
Pack
Turnigy 2-3 Cell Lipoly
1 US $5.95 Battery Charger
Balance/Charger
Arduino MEGA Module 2 $70.40 Microcontroller Module
CAD
AsyncLabs WiFI Shield 1 $59.78 WiFi Module
$309.23
Low cost Ultrasonic
3 $26.33 Ultrasonic Sensor
Range Finder
Counter Rotating Pair
EPP1045 Propellors 3 $6.95 CAD $33.50
Propellers
Gyro Breakout Board -
US
IDG500 Dual 500 1 Gyroscope Board
$39.95
degree/sec US $133.90
IMU 5 Degrees of US Gyroscope Chip to control
1
Freedom $74.95 stability of UAV
US Interface for Gyroscope to
AeroQuad Shield v1.5 1
$24.95 microcontroller
US $
Stackable Headers 2
7.90 CAD $62.95 Necessary male and female
US $ headers to mount the
Right Angle Headers 1
1.95 Gyroscope and
Straight Male Header (9 US $ microcontroller
4
Pin) 3.00

University
2010
US $
Female Header (5 Pin) 2
1.50
Female Header (9 Pin) 2 US $1.90
Used in order concurrently
Arduino Microcontroller
1 $49.99 develop wireless
Basic Kit
communication code
CAD $66.84
6 Foot USB cable 1 $2.99 Used with the basic kit
Mini Breadborad 1 $4.29 For custom circuit design
Used for preliminary testing
18A DC Power Supply 1 $139.99
of UAV
CAD
Stronger than Rhino
3-cell 2200mAh Battery $203.38
1 $39.99 2150mAh. Used for final
Pack
testing and presentation
CAD
Total
$999.70
Table 8: List of Materials and Respective Cost
The total prices in the above table include shipping cost and
applicable taxes.
The above table specifies the materials purchased in order to
construct the Quadcopter robot with ability of controlling it over the
internet. New parts were required since it is a first year that this
project has been worked on. Moreover, higher performance parts were
necessary due to the aerial nature of the project. The cost of the
materials for this project has accumulated up to $999.70 (CAD).

University
2010
40Conclusion and Recommendations

4.1Conclusion
This section will reiterate the problems faced in this project and
their proposed solutions as well as the accomplishments with regards
to the problems.
Since the Quadcopter is a new implementation of the Internet
Mobile Robot, a new design of the robot was needed. The Quadcopter
needed to be designed and constructed to meet the project criteria.
Research was done on current remote-controlled Quadcopters to come
up with our own design for our implementation of the Quadcopter.
Based on these current models, component parts were researched to
meet the needs of our design. The design consisted of both a
mechanical and electrical elements. The Quadcopter was constructed
after the component parts were acquired from various sources using
mechanical and electrical engineering knowledge. This
accomplishment is vital for future groups as the completed prototype
will be the foundation on which further functionality and applications
can be developed.

University
2010
This project also undertook the challenge of implementing a Wi-Fi
communications design on the traditionally remote-controlled
Quadcopter. As such, this is one of the few Quadcopters that use Wi-Fi
technology for communications. Much research was done and the
WiShield 1.0 was used to achieve Wi-Fi connectivity to communicate
remotely with the router. A big accomplishment is the understanding of
the documentation for the module and learning how to program it
successfully. The WiShield itself is a new module and it was a
challenge to debug as well. These challenges were overcome however,
with meticulous code reiteration and testing. This accomplished in the
Quadcopter being able to receive commands and reply with simple
feedback.
Since the Quadcopter is flying in 3-D space, a stability
mechanism was required to ensure stability during flight as well as
during directional changes. A hardware and software solution was
proposed. The hardware solution consists of using accelerometers and
gyroscopes in tandem as an Inertial Measurement Unit. The software
solution complements the hardware solution by taking the raw data
from the gyroscopes and accelerometers into a filter to stabilize the
Quadcopter. Stability was a major task to accomplish but rigorous
testing and debugging proved successful.

University
2010
With the design decision to adopt a Wi-Fi implementation, there
was also a new task of coming up with a control unit. A solution
proposed to tackle this was the development of a web browser- based
GUI. The GUI was designed and implemented. The implementation is in
its preliminary stages as is the design, leaving it open to future
development. Regardless, it is good groundwork to build upon.
With so many software component parts, the integration of the
code was also exigent. Debugging and careful inspection of the code
was done to ensure that there was no mistake in the coding. Numerous
bugs were discovered and resolved.
As such, all the problems that motivated this project have been
addressed. Solutions have been provided but these solutions can
always be further improved on.
4.2Recommendations
The Project has been a great success but as it is a pioneering
one, there are a myriad of possibilities that can be realized by future
groups. The next immediate step is to find a better way of integrating
the wireless module with the microcontroller. Also in the immediate
future, perhaps sonar sensors can be incorporated so that the IMR is
able to prevent crashes. Also feasible in the next phase is the addition
of video feedback. The WiShield can perhaps stream the video feed
wirelessly back to the router. This addition will greatly increase the

University
2010
scope of potential applications for the IMR. Another possible addition to
the project would be the development of a smart-phone application to
control the IMR.

University
2010
References
[1] Leishman, J.G., Principles of Helicopter Aerodynamics. New York :
Cambridge University Press, 2000.
[2] Anderson, S.B., "Historical Overview of V/STOL Aircraft Technology." NASA

Technical Memorandum. Vol. NASA, March.
[3] , Quadrotor- Wikipedia. Wikipedia. [Online] [Cited: March 18, 2010.]

http://en.wikipedia.org/wiki/Quadrotor.
[4] Hoffman, G.M., et al., "The Stanford Testbed of Autonomous Rotorcraft for
Multi Agent Controls(STARMAC)." Proceedings of the 23rd Digital Avionics
System Conference. November, 2004.
[5] Pounds, P., Mahony, R. and Corke, P., "Modelling and Control of a Quad-
Rotor Robot." Proceedings of the Australasian Conference on Robotics and
Automation. December, 2006.
[6] Hoffman, G., et al., "Quadcopter Helicopter Flight Dynamics and Control:
Theory and Experiment." Conference of the American Institute of Aeronautics
and Astronautics. 2007, 20-23 August.
[7] , Aluminium - Wikipedia. Wikipedia. [Online] [Cited: Septermber 23, 2009.]

http://en.wikipedia.org/wiki/Aluminium.
[8] What is Balsa Wood? WiseGeek. [Online] [Cited: September 23, 2009.]
http://www.wisegeek.com/what-is-balsa-wood.htm.
[9] Carbon Fiber - Wikipedia. Wikipedia. [Online] [Cited: September 23, 2009.]
http://en.wikipedia.org/wiki/Carbon_fiber#cite_note-1.
[10] Commutator - Wikipedia. Wikipedia. [Online] [Cited: September 23,

2009.] http://en.wikipedia.org/wiki/Commutator_(electric).
[11] Brushless DC Electric Motor - Wikipedia. Wikipedia. [Online] [Cited:

September 23, 2009.]
http://en.wikipedia.org/wiki/Brushless_DC_electric_motor.
[12] Kabai, Sandor., "Gyroscope." Wolfram Demonstrations Project.
[13] , Arduino. http://www.arduino.cc/en/. [Online] [Cited: April 1, 2010.]

University
2010
[14] Complementary Filter. Integrated Publishing. [Online] [Cited: March 28,

2010.] http://www.tpub.com/content/nasa1995/NASA-95-tp3525/NASA-95-
tp35250026.htm.
[15] 2nd Order Comp Filter. Quaduino. [Online] [Cited: March 28, 2010.]
http://www.rcgroups.com/forums/showpost.php?
p=12082524&postcount=1286.
[16] Stone, B.J., Degrees of Freedom. THe University of Western Australia.

[Online] [Cited: January 16, 2010.]
http://school.mech.uwa.edu.au/~bjs/Vibration/OneDOF/DOF6.gif.
[17] Ogata, Katsuhiko., Modern Control Engineering Fifth Edition. Upper Sadle
River : Prentice Hall, 2010.
[18] , Control Systems. Wikipedia. [Online] [Cited: March 28, 2010.]

http://en.wikipedia.org/wiki/File:Control_Systems.png.
[19] 2nd Order Damping Ratios. Wikipedia. [Online] [Cited: March 28, 2010.]
http://en.wikipedia.org/wiki/File:2nd_Order_Damping_Ratios.svg.
[20] File:Pid-feedback-nct-int-correct.png. Wikipedia. [Online] October 26,

2006. [Cited: January 23, 2010.] http://en.wikipedia.org/wiki/File:Pid-
feedback-nct-int-correct.png.
[21] File:Feedback Loop with descriptions. Wikipedia. [Online] [Cited: March

28, 2010.]
http://en.wikipedia.org/wiki/File:Feedback_loop_with_descriptions.svg.
[22] Pre-flight Checkout. Aeroquad. [Online] [Cited: March 28, 2010.]

http://aeroquad.com/content.php?118.
[23] ZigBee - Wikipedia. Wikipedia. [Online] [Cited: 03 21, 2010.]

http://en.wikipedia.org/wiki/ZigBee.
[24] XBee & XBee-PRO. Digi. [Online] [Cited: 10 21, 2009.]

http://www.digi.com/products/wireless/point-multipoint/xbee-series1-
module.jsp#overview.
[25] ConnectPort X Gateways for Drop-In Networking. Digi. [Online] [Cited: 10

11, 2009.]
http://www.digi.com/products/wirelessdropinnetworking/connectportxgatewa
ys.jsp#overview.
[26] Wi-Fi - Wikipedia. Wikipedia. [Online] [Cited: 10 20, 2009.]

http://en.wikipedia.org/wiki/Wi-Fi.

University
2010
[27] WiShield 1.0 - Asynclabs Documents. asynclabs. [Online] [Cited: 10 23,

2009.] http://asynclabs.com/wiki/index.php?title=WiShield_1.0.
[28] Transmission Control Protocol - Wikipedia. Wikipedia. [Online] [Cited: 03

25, 2010.] http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
[29] ch2_2010 notes. Instructor:. [Online] 03 25, 2010.

http://www.sce.carleton.ca/courses/sysc-4502/w10/ch2_2010.pdf.
[30] User DEatagram Protocol - Wikipedia. Wikipedia. [Online] [Cited: 03 27,

2010.] http://en.wikipedia.org/wiki/User_Datagram_Protocol.
[31] Understanding the SPI bus with NI LabVIEW. Developer Zone. [Online]
[Cited: 03 27, 2010.] http://zone.ni.com/devzone/cda/tut/p/id/9119.
[32] Serial Peripheral Interface Bus - Wikipedia. Wikipedia. [Online] [Cited: 03

28, 2010.] http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus.
[33] Fedora Project (operating system). Wikipedia. [Online] [Cited: 12 28,

2009.] http://en.wikipedia.org/wiki/Fedora_%28operating_system%29.
[34] Apache Friends - XAMPP for Linux. Apache Friends. [Online] [Cited: 3 02,
2010.] http://www.apachefriends.org/en/xampp-linux.html.
[35] Apache HTTP Server. Wikipedia. [Online] [Cited: 3 02, 2010.]

http://en.wikipedia.org/wiki/Apache_HTTP_Server.
[36] PHP. Wikipedia. [Online] [Cited: 3 04, 2010.]

http://en.wikipedia.org/wiki/PHP.
[37] Gratuitous_ARP. The Wireshark Wiki. [Online] [Cited: 3 10, 2010.]

http://wiki.wireshark.org/Gratuitous_ARP.
[38] PHP:exec - Manual. PHP Manual. [Online] [Cited: 3 15, 2010.]

http://php.net/manual/en/function.exec.php.
[39] blinkm-arduino-mega_inline.png. amazonaws. [Online] [Cited: 03 29,

2010.] http://s3.amazonaws.com/satisfaction-
production/s3_images/58147/blinkm-arduino-mega_inline.png.
[40] What Is PID. Expertune. [Online] [Cited: March 28, 2010.]

http://www.expertune.com/tutor.html.

University

Internet Mobile Robot - The Quad Copter

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Internet Mobile Robot - The Quad Copter

Încărcat de

Drepturi de autor:

Formate disponibile

A report submitted in partial fulfillment of the requirements

Department of Systems and Computer Engineering

and Hue Vo have developed a start-up project as a partial fulfillment for

objective of the project was to design and implement a Quadcopter

remote client application over the internet.

Currently, different Quadcopter designs have been implemented.

However, most of them have used handheld Radio Control implementations.

With the design implemented in this project, different applications can be

developed to control the Quadcopter over the internet from a remote

different areas ranging from Surveillance to Virtual Gaming Technologies to

Different designs were explored and from these designs, it was

determined that we would need a microcontroller to run control algorithms, a

Wi-Fi chip to facilitate wireless communication and a webpage to for user

microcontroller and executed by all the components including motors, speed

The communication system implemented a server/client architecture

bidirectionally. The webpage, implemented as a simple Graphical User

Department of Systems and Computer Engineering |Carleton University 2

Interface (GUI), is a good replacement for the RC handheld devices and

allows for easy portability from one client to another.

Department of Systems and Computer Engineering |Carleton University 3

giving us the opportunity to explore and experiment with our creativity.

Their prompt actions, experience and knowledge allowed us to surpass

various milestones throughout the duration of the project.

Department of Systems and Computer Engineering |Carleton University 1

Department of Systems and Computer Engineering |Carleton University 1

Department of Systems and Computer Engineering |Carleton University 2

Figure 2: First Generation Design of De Bothezat Quadrotor [3]......................2

Figure 3: Wound Rotor [10]............................................................................16

Figure 4: Brushless Motor Design [11]...........................................................17

Figure 5: Typical Microcontroller....................................................................19

Figure 6: Sketch of Proposed Structure..........................................................23

Figure 7: Initial Frame....................................................................................23

Figure 8 : Aeroquad Shield.............................................................................28

Figure 9: Graph of Flight Time versus Battery Life.........................................30

Figure 10: Wiring Diagram for IMR.................................................................31

Figure 11: Final Design...................................................................................32

Figure 12: Second Order Complementary Filter [15]......................................34

Figure 13: Second Order Complementary Filter [15]......................................35

Figure 14: Possible independent movements in 3D space [16]......................37

Figure 17: PID Controller loop [20].................................................................42

Figure 19: Feedback Control Loop with control components..........................44

Department of Systems and Computer Engineering |Carleton University 3

Figure 22: AeroQuad Configurator GUI with updatable flight parameters......48

Figure 23: Various sensor outputs with AeroQuad Configurator GUI..............49

Figure 24: Original Communication System Design.......................................55

Figure 25: TCP three-way handshake.............................................................60

Figure 26: Re-designed Communication System............................................63

Figure 27: WiShield Functionality...................................................................64

Figure 28: Handling TCP connection..............................................................65

Figure 29: SPI bus, single-master single-slave...............................................67

Figure 30: WiShield Schematic [27]...............................................................68

Figure 31: Simple Compiler provided for WiShield.........................................71

Figure 32: Ideal Layout of Client System in relation with WiShield................74

Figure 33: Actual Implementation of Client System in relation with Wi-Shield75

Figure 34: Client Design.................................................................................76

Figure 35: Client Process................................................................................78

Figure 36: User Interface................................................................................79

Figure 37: Components of the User Interface.................................................80

Figure 38: Pin 5 of SM (with WiShield) connected to digital pin 32 of PM using a

Department of Systems and Computer Engineering |Carleton University 2

Table 2: Flight Times for 2 Different Designs.................................................14

Table 3: Matching Motors for EPP1045 Propeller............................................25

Table 4: Total Weight Calculation...................................................................29