internet mobile robot

Internet Mobile RobotThe Quadcopter

Group 13Rahul Bura

Mohamed ChandeVinayak 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 EngineeringFaculty of Engineering

Carleton University

April 7, 2010

April 7th, 2010

AbstractGroup 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 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 1

April 7th, 2010

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

portability from one client to another.


April 7th, 2010

AcknowledgementsWe 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.


April 7th, 2010

Table of Contents

Abstract.................................................................................................................................... i

Acknowledgements................................................................................................................iii

List of Figures..........................................................................................................................vi

List of Tables.........................................................................................................................viii

1.0 Introduction.....................................................................................................................11.1 Background.................................................................................................................11.2 Motivation..................................................................................................................31.3 Problem Statement.....................................................................................................31.4 Proposed Solution and Accomplishments..................................................................31.5 Overview of the Remainder of the Report..................................................................6

2.0 The Engineering Project...................................................................................................82.1 Health and Safety.......................................................................................................82.2 Engineering Professionalism.......................................................................................92.3 Project Management................................................................................................102.4 Individual Contributions...........................................................................................11

2.4.1 Project Contributions........................................................................................112.4.2 Report Contributions........................................................................................12

3.0 Robot Design.................................................................................................................133.1 Structure...................................................................................................................13

3.1.1 Number of Motors............................................................................................133.1.2 Frame................................................................................................................15

3.2 Communications.......................................................................................................153.3 Flight and Stability....................................................................................................163.4 Flight Control............................................................................................................183.5 Power.......................................................................................................................20

4.0 Hardware Components and Construction.....................................................................224.1 Frame and Structure.................................................................................................224.2 Microcontroller.........................................................................................................244.3 Flight and Stability....................................................................................................25

4.3.1 Propeller and Motor Combination Configuration.............................................254.3.2 Electronic Speed Controller (ESC).....................................................................264.3.3 Six Degrees of Freedom (DOF)..........................................................................27

4.4 Communications.......................................................................................................284.5 Battery......................................................................................................................28

4.5.1 Flight Time and Battery Power Dependancy.....................................................294.6 Design Implementation and Final Structure.............................................................30

5.0 Stability and Manoeuvre................................................................................................335.1 Filtering Noise...........................................................................................................33

5.1.1 Noise Reduction................................................................................................33


April 7th, 2010

5.1.2 Second Order Complementary Filter................................................................345.2 Feedback Control......................................................................................................35

5.2.1 Six Degrees of Freedom (DOF)..........................................................................365.2.2 System Control Theory......................................................................................375.2.3 Proportional, Integral, Derivative Controller.....................................................405.2.4 Feedback Control Mechanism: Inertial Measurement Units.............................425.2.5 Feedback Control Loop.....................................................................................435.2.6 Flight Tuning Using Ziegler-Nichols Rules..........................................................45

5.3 Flight Configuration and Simulation.........................................................................465.3.1 Flight Configuration Methods and Tools...........................................................465.3.2 Pre-Flight Tests..................................................................................................495.3.3 Flight Control and Results.................................................................................50

6.0 Wireless Communication (Server).................................................................................546.1 Communication System Overview............................................................................546.2 Wireless Standards...................................................................................................55

6.2.1 ZigBee...............................................................................................................566.2.2 Wi-Fi..................................................................................................................57

6.3 WiShield Configurations...........................................................................................586.3.1 Network Type....................................................................................................586.3.2 TCP vs UDP........................................................................................................59

6.4 WiShield Functionality..............................................................................................646.5 Serial Peripheral Interface........................................................................................666.6 Challenges and Solutions..........................................................................................69

6.6.1 Debugging.........................................................................................................696.6.2 Pin Conflict........................................................................................................71

7.0 Wireless Communication (Client)..................................................................................737.1 Client Design.............................................................................................................737.2 Client Process...........................................................................................................77

8.0 User Interface................................................................................................................798.1 Software Requirements............................................................................................80

8.1.1 Operating System..............................................................................................818.1.2 XAMPP..............................................................................................................81

8.2 Challenges and Solutions..........................................................................................83

9.0 Software Integration......................................................................................................85

10.0 Production Expenses......................................................................................................8810.1 Material Costs...........................................................................................................88

11.0 Conclusion and Recommendations................................................................................9011.1 Conclusion................................................................................................................9011.2 Recommendations....................................................................................................92

References.............................................................................................................................93


April 7th, 2010

List of FiguresFigure 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


April 7th, 2010

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-Shield............................75

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


April 7th, 2010

List of TablesTable 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


April 7th, 2010

1.0 IntroductionWith 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.1 Background

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 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 prototypes suffered from poor performance [1]

and latter prototypes required too much pilot workload, due to poor stability [2].


Figure 1: Rotating pairs of rotors [3]

April 7th, 2010

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

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 [4]. 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 [5]. 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 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 [6].


April 7th, 2010

1.2 Motivation

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.3 Problem 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.

1.4 Proposed 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.


April 7th, 2010

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.

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


April 7th, 2010

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 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.


April 7th, 2010

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

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.5 Overview 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 6 and 8 respectively can be

referred to as well.


April 7th, 2010

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.

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.


April 7th, 2010

2.0 The Engineering Project

2.1 Health 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 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


April 7th, 2010

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.2 Engineering 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 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.


April 7th, 2010

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.3 Project 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 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.


April 7th, 2010

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.

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.4 Individual Contributions

2.4.1 Project 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)


April 7th, 2010

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 presentations, all members contributed in different components throughout the

presentation preparation period.

2.4.2 Report 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:

Section Author Editing and Proof Reading1.0 Rahul Bura Mohamed Chande2.0 Hue Vo Vinayak Goge3.0 Rahul Bura Hue Vo4.0 Rahul Bura Mohamed Chande5.0 Hue Vo Rahul Bura6.0 Mohamed Chande Vinayak Goge7.0 Vinayak Goge Mohamed Chande8.0 Vinayak Goge Hue Vo9.0 Mohamed Chande, Hue Vo Rahul Bura

10.0 Rahul Bura, Vinayak Goge Mohamed Chande

11.0 Rahul Bura, Mohamed Chande, Vinayak Goge, Hue Vo

Rahul Bura, Mohamed Chande, Vinayak Goge, Hue Vo

Table 1: Report Contributions


April 7th, 2010

3.0 Robot DesignRobot 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 components that

include structure of the robot, communications, the stability mechanism, the controls

mechanisms and power.

3.1 Structure

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.

3.1.1 Number 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.


April 7th, 2010

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 assumed that each design is able to carry its own

structural weight and hence they are ignored so only the payload is tabulated.

Table 2: Flight Times 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 looking at the payload


Pay Load(oz)

4 Motors Design

(Quadcopter)

8 Motors Design

(Octocopter)

0 19.9 11.7 Flight Time (M

ins)

8 12.6 9.2

16 9.2 7.5

24 7.3 6.3

32 - 5.3

40 - 4.6

April 7th, 2010

of 16oz, the Quadcopter offers a better performance and we settled on the four-motor

design for our IMR.

3.1.2 Frame

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 [7]. 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 [8]. 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 [9].

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.

3.2 Communications

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


April 7th, 2010

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.

3.3 Flight and Stability

For flight, four pairs of propellers and motors are required. There are numerous

motors available that are powered by DC 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 Department of Systems and Computer Engineering |Carleton University 16

Figure 3: Wound Rotor [10]

April 7th, 2010

magnet stator. [10] An electrical power source is connected to the rotor through the

commutator and its brushes providing 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 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. [11] 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,


Figure 4: Brushless Motor Design [11]

April 7th, 2010

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 [12]. 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 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.

3.4 Flight 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.


April 7th, 2010

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 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.


April 7th, 2010

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.

3.5 Power

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), 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


April 7th, 2010

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 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.


April 7th, 2010

4.0 Hardware Components and ConstructionHardware 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.

4.1 Frame 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


April 7th, 2010

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 aluminum base and the miscellaneous screws and nuts used to

secure the components is 3.2oz.

Figure 6: Sketch of Proposed Structure


April 7th, 2010

Figure 7: Initial Frame

4.2 Microcontroller

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


April 7th, 2010

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 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 [13]. The Arduino Mega contributes a weight of 1.5oz to the IMR.

4.3 Flight and Stability

4.3.1 Propeller 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.


April 7th, 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 Quadcopter responds better to change in directions

when the motors are further apart. This increases the signal noise fed into the IMU due


April 7th, 2010

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.

4.3.2 Electronic 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 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


April 7th, 2010

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.

4.3.3 Six 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. 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 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.


Figure 8 : Aeroquad Shield

April 7th, 2010

4.4 Communications

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 6.0.

4.5 Battery

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 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.

4.5.1 Flight 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


April 7th, 2010

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

Table 4: Total Weight Calculation


April 7th, 2010

0 2 4 6 8 10 120

2

4

6

8

10

12

Flying weight vs Battery Life

2100mAh

Flying Weight in Ounces (oz)

Batt

ery

Life

( Min

s)

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.

4.6 Design 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.


April 7th, 2010

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.


April 7th, 2010

Figure 10: Wiring Diagram for IMR


April 7th, 2010

Figure 11: Final Design


April 7th, 2010

5.0 Stability and ManoeuvreThere 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.

5.1 Filtering 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.

5.1.1 Noise 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


April 7th, 2010

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 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.

5.1.2 Second Order Complementary Filter

A complementary filter is a filter with a derivative feedback through the filter.

[14] 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.


April 7th, 2010

Figure 12: Second Order Complementary Filter [15]

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 [15]

5.2 Feedback 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 timely manner. There are many factors that


April 7th, 2010

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.

5.2.1 Six 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.


April 7th, 2010

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

5.2.2 System 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. [17]

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

Feedback System, the output is determined by comparing the previous output signal

and the reference signal. [17]


April 7th, 2010

Figure 15: Types of Control Systems: (a) Open Loop (b) Feed-Forward (c) Closed Loop [18]

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. [17]

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


April 7th, 2010

enhanced. [17] 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. [17] 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 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


April 7th, 2010

response is oscillatory. If ζ = 1, the system is described as critically damped and if ζ > 1

the system is overdamped, as seen in Figure 16. [17]

Figure 16: How the damping constant affects the time it takes to reach steady state [19]

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 Gyroscopes. These mechanisms will help direct and

control the direction of motion of the Quadcopter by outputting any possibly unwanted

changes to the system.

5.2.3 Proportional, 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


http://upload.wikimedia.org/wikipedia/commons/9/94/2nd_Order_Damping_Ratios.svg

April 7th, 2010

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) = KP + 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 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. [17]


April 7th, 2010

Figure 17: PID Controller loop [20]

5.2.4 Feedback 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 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


April 7th, 2010

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.

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.

5.2.5 Feedback 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:


April 7th, 2010

Figure 18: Feedback loop including system, controller and sensor configuration [21]

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.

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.


April 7th, 2010

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.

5.2.6 Flight Tuning Using Ziegler-Nichols Rules

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. [17]

Type of Controller KP KI KD

P 0.5KCR 0 0

PI 0.45KCR 1.2/PCR 0

PID 0.6 KCR 2/PCR 0.125PCR

Table 5: PID gain using Ziegler-Nichols Tuning Rule [17]

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


April 7th, 2010

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.

5.3 Flight Configuration and Simulation

5.3.1 Flight 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.


April 7th, 2010

Figure 20: Motor Command outputs (S) during simulation of flight with Serial Monitor

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.


April 7th, 2010

Figure 21: Sensor Data output (Q) during simulation of flight with Serial Monitor

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.


April 7th, 2010

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 graph helps one to visually see the oscillations occurring

and the sizes of the oscillations.


April 7th, 2010

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.

5.3.2 Pre-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 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.


April 7th, 2010

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. [22] There are also communication related tests that will

be described further in Section 6.0 Wireless Communication.

5.3.3 Flight Control and Results

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


April 7th, 2010

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.

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


April 7th, 2010

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.

The above videos and oscillations were obtained with the following KP values and

KI = 0 and KD = 0 for the Roll and Pitch:

KP Observations3.75 Underdamped

3-4 oscillations before it stabilizes4.75 Close to critically Damped

1-2 small oscillations5.75 Overdamped

Difficult to tip off axis. Resistant to change6.75 Overdamped

Very difficult to tip off axis. Highly resistant to changeTable 6: Values of KP and corresponding qualitative observations for Ziegler-Nichols Rule


April 7th, 2010

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 K P

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.

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.


April 7th, 2010

6.0 Wireless Communication (Server)

6.1 Communication 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 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.


April 7th, 2010

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 WiFi Chip as well as

the challenges faced in implementations and the respective solutions are also discussed

in detail.

6.2 Wireless 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


TCP: Control Commands

UDP: Feedback

April 7th, 2010

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.

6.2.1 ZigBee

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 [23].

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 networking. They are designed for high-throughput

applications requiring low latency and predictable communication timing [24].

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 [25].

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


April 7th, 2010

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 [25].

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.

6.2.2 Wi-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 [26].

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 [27].

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.


April 7th, 2010

6.3 WiShield 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.

6.3.1 Network 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) 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.


April 7th, 2010

6.3.2 TCP 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:

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.


April 7th, 2010

Figure 25: TCP three-way handshake

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.


April 7th, 2010

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. [28]

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.

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. [29]

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. [30]

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


April 7th, 2010

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

Connection States Has states Stateless

Congestion control Yes No

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.


April 7th, 2010


TCP: Control Commands

TCP: Feedback

Figure 26: Re-designed Communication System

April 7th, 2010

6.4 WiShield 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 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


Start

WiShield Network

Configuration

Connect to Network

Handle Connection

Connected ?

Update Connection

Status

YES

NO

April 7th, 2010

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


Data Valid

?Write to a digital Pin

Send Reply

Update Connection State

NAKACK

Empty buffer

Open TCP Socket

Initialize Connection State

Listen on Port

Data Received? Store data in buffer

Parse data

YESNO

April 7th, 2010

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 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.

6.5 Serial 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 [31].

The SPI bus specifies four logic signals:

SCLK — Serial Clock (output from master)

MOSI/SIMO — Master Output, Slave Input (output from master)

MISO/SOMI — Master Input, Slave Output (output from slave)


April 7th, 2010

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 [31].

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.


Master Slave

SCLK

MOSI

MISO

SS

April 7th, 2010

Figure 30: WiShield Schematic [27]

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

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


April 7th, 2010

bit into the same register. After that register has been shifted out, the master and slave

have exchanged register values [32].

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.

6.6 Challenges 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.

6.6.1 Debugging

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


April 7th, 2010

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.


April 7th, 2010

Figure 31: Simple Compiler provided for WiShield

6.6.2 Pin 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 proper

operation, these pins are used for only one purpose, either SPI communication or Motor

control.


April 7th, 2010

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 complete integration process which uses this implementation is

explained in detail on section 9.0 of this project report.


April 7th, 2010

7.0 Wireless 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.

7.1 Client 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 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


April 7th, 2010

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.


April 7th, 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 services encase the reply with appropriate PHP and HTML code

and display it on the web browser.


April 7th, 2010

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


Reply Received?

Setup Socket and Connection

Bind to port in computer

Ask user for the next move

Verify the input

Send user input to Wi-Shield

Wait for Reply

True

False

False

True

April 7th, 2010

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.

7.2 Client 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 User” stream. Once the user

interface receives the reply, it displays the reply to the user through the web interface.


April 7th, 2010

Figure 35: Client Process


April 7th, 2010

8.0 User InterfaceUser 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.


April 7th, 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.

8.1 Software 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.


April 7th, 2010

8.1.1 Operating System

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 [33].

8.1.2 XAMPP

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 [34].

XAMPP for Linux with version 1.7.3a was installed.

The XAMPP 1.7.3a package contains:

Apache Web Service

PHP Service


April 7th, 2010

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 [34].

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 [35].

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 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


April 7th, 2010

website even more cost effective. During development phase, PHP service was enabled

on the client computer [36].

During development and testing phase of the project only the following services

were enabled while using XAMPP:

Apache Web Service

PHP Service

PHP extensions

8.2 Challenges 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 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,


April 7th, 2010

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 [37].

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 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 [38].


April 7th, 2010

9.0 Software IntegrationThis 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 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.


April 7th, 2010

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 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.


April 7th, 2010

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

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 implemented

with apparent success and the two microcontrollers communicated as expected.


April 7th, 2010

10.0 Production Expenses

10.1 Material Costs

ITEM # Unit Price Total NOTE

Tower Pro 2410-09 6 US $6.39

US $187.90

Brushless Motors

Tower Pro Brushless Speed Controller

6 US $9.99 Brushless Speed Controller

TowerPro Alloy Stick Mount for Motors

4 US $2.00Mount for the motors that also

act as heat sinks

Carbon Fibre Tubing 4 US $2.62 750x6mm

Prop Saver with 3mm Bands 1 US $3.99Propeller saver that prevents propeller from breaking free

Rhino 2150mAh Lipoly Pack 2 US $9.69 Rechargeable Battery Pack

Turnigy 2-3 Cell Lipoly Balance/Charger

1 US $5.95 Battery Charger

Arduino MEGA Module 2 $70.40

CAD $309.23

Microcontroller Module

AsyncLabs WiFI Shield 1 $59.78 WiFi Module

Low cost Ultrasonic Range Finder

3 $26.33 Ultrasonic Sensor

EPP1045 Propellors 3 $6.95 CAD $33.50 Counter Rotating Pair Propellers

Gyro Breakout Board - IDG500 Dual 500 degree/sec

1 US $39.95US $133.90

Gyroscope Board

IMU 5 Degrees of Freedom 1 US $74.95Gyroscope Chip to control

stability of UAV

AeroQuad Shield v1.5 1 US $24.95

CAD $62.95

Interface for Gyroscope to microcontroller

Stackable Headers 2 US $ 7.90

Necessary male and female headers to mount the Gyroscope

and microcontroller

Right Angle Headers 1 US $ 1.95

Straight Male Header (9 Pin) 4 US $ 3.00

Female Header (5 Pin) 2 US $ 1.50

Female Header (9 Pin) 2 US $1.90

Arduino Microcontroller Basic Kit

1 $49.99

CAD $66.84

Used in order concurrently develop wireless communication

code

6 Foot USB cable 1 $2.99 Used with the basic kit

Mini Breadborad 1 $4.29 For custom circuit design

18A DC Power Supply 1 $139.99CAD $203.38 Used for preliminary testing of

UAV 3-cell 2200mAh Battery

Pack1 $39.99 Stronger than Rhino 2150mAh.

Used for final testing and


April 7th, 2010

presentation

Total CAD $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).


April 7th, 2010

11.0 Conclusion and Recommendations

11.1 Conclusion

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.

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


April 7th, 2010

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.

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.


April 7th, 2010

11.2 Recommendations

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 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.


April 7th, 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.]

[14] Complementary Filter. Integrated Publishing. [Online] [Cited: March 28, 2010.] http://www.tpub.com/content/nasa1995/NASA-95-tp3525/NASA-95-tp35250026.htm.


April 7th, 2010

[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/connectportxgateways.jsp#overview.

[26] Wi-Fi - Wikipedia. Wikipedia. [Online] [Cited: 10 20, 2009.] http://en.wikipedia.org/wiki/Wi-Fi.

[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.


April 7th, 2010

[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.


internet mobile robot - the quad copter

Documents

project contributions

startup project

project management

robot design

engineering professionalism

different quadcopter

different designs