Internet Mobile Robot The Quad Copter

Internet Mobile Robot
The Quadcopter
Group 13 Rahul Bura Mohamed Chande Vinayak Goge Hue Vo
Supervisor: Professor Peter X. Liu
A report submitted in partial fulfillment of the requirements of SYSC-4907 Engineering Project
Department of Systems and Computer Engineering Faculty of Engineering Carleton University
April 7, 2010
April 7th, 2010
Abstract
Group 13 consisting of Rahul Bura, Mohamed Chande, Vinayak Goge and Hue Vo have developed a start-up project as a partial fulfillment for SYSC 4907 Engineering Project: Internet Mobile Robot: The Quadcopter. The 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
Department of Systems and Computer Engineering |Carleton University i
April 7th, 2010
as a simple Graphical User Interface (GUI), is a good replacement for the RC handheld devices and allows for easy portability from one client to another.
Department of Systems and Computer Engineering |Carleton University
ii
April 7th, 2010
Acknowledgements
We would like to formally thank Professor Peter X. Liu for supervising and for his guidance throughout the Internet Mobile Robot project as well as giving us the opportunity to explore and experiment with our creativity. We would also like to thank the Technical Support Staff, Danny Lemay, Jerry Buburuz and Daren Russ, for their support throughout the project. Their prompt actions, experience and knowledge allowed us to surpass various milestones throughout the duration of the project.
iii
April 7th, 2010
Table of Contents
Abstract...................................................................................................................................... i Acknowledgements ................................................................................................................. iii List of Figures ........................................................................................................................... vi List of Tables .......................................................................................................................... viii 1.0 Introduction ...................................................................................................................... 1 1.1 Background .................................................................................................................. 1 1.2 Motivation ................................................................................................................... 3 1.3 Problem Statement...................................................................................................... 3 1.4 Proposed Solution and Accomplishments ................................................................... 3 1.5 Overview of the Remainder of the Report .................................................................. 6 2.0 The Engineering Project .................................................................................................... 8 2.1 Health and Safety......................................................................................................... 8 2.2 Engineering Professionalism ........................................................................................ 9 2.3 Project Management ................................................................................................. 10 2.4 Individual Contributions ............................................................................................ 11 2.4.1 Project Contributions ......................................................................................... 11 2.4.2 Report Contributions ......................................................................................... 12 3.0 Robot Design ................................................................................................................... 13 3.1 Structure .................................................................................................................... 13 3.1.1 Number of Motors ............................................................................................. 13 3.1.2 Frame ................................................................................................................. 15 3.2 Communications ........................................................................................................ 15 3.3 Flight and Stability ..................................................................................................... 16 3.4 Flight Control ............................................................................................................. 18 3.5 Power ......................................................................................................................... 20 4.0 Hardware Components and Construction ...................................................................... 22 4.1 Frame and Structure .................................................................................................. 22 4.2 Microcontroller .......................................................................................................... 24 4.3 Flight and Stability ..................................................................................................... 25 4.3.1 Propeller and Motor Combination Configuration.............................................. 25 4.3.2 Electronic Speed Controller (ESC) ...................................................................... 26 4.3.3 Six Degrees of Freedom (DOF) ........................................................................... 27 4.4 Communications ........................................................................................................ 28 4.5 Battery ....................................................................................................................... 28 4.5.1 Flight Time and Battery Power Dependancy ..................................................... 29 4.6 Design Implementation and Final Structure .............................................................. 30 5.0 Stability and Manoeuvre ................................................................................................. 33 5.1 Filtering Noise ............................................................................................................ 33 5.1.1 Noise Reduction ................................................................................................. 33 Department of Systems and Computer Engineering |Carleton University iv
April 7th, 2010
5.1.2 Second Order Complementary Filter ................................................................. 34 5.2 Feedback Control ....................................................................................................... 35 5.2.1 Six Degrees of Freedom (DOF) ........................................................................... 36 5.2.2 System Control Theory ....................................................................................... 37 5.2.3 Proportional, Integral, Derivative Controller ..................................................... 40 5.2.4 Feedback Control Mechanism: Inertial Measurement Units ............................. 42 5.2.5 Feedback Control Loop ...................................................................................... 43 5.2.6 Flight Tuning Using Ziegler-Nichols Rules .......................................................... 45 5.3 Flight Configuration and Simulation .......................................................................... 46 5.3.1 Flight Configuration Methods and Tools............................................................ 46 5.3.2 Pre-Flight Tests................................................................................................... 49 5.3.3 Flight Control and Results .................................................................................. 50 6.0 Wireless Communication (Server) .................................................................................. 54 6.1 Communication System Overview ............................................................................. 54 6.2 Wireless Standards .................................................................................................... 55 6.2.1 ZigBee ................................................................................................................. 56 6.2.2 Wi-Fi ................................................................................................................... 57 6.3 WiShield Configurations ............................................................................................ 58 6.3.1 Network Type ..................................................................................................... 58 6.3.2 TCP vs UDP ......................................................................................................... 59 6.4 WiShield Functionality ............................................................................................... 64 6.5 Serial Peripheral Interface ......................................................................................... 66 6.6 Challenges and Solutions ........................................................................................... 69 6.6.1 Debugging .......................................................................................................... 69 6.6.2 Pin Conflict ......................................................................................................... 71 7.0 Wireless Communication (Client) ................................................................................... 73 7.1 Client Design .............................................................................................................. 73 7.2 Client Process............................................................................................................. 77 8.0 User Interface ................................................................................................................. 79 8.1 Software Requirements ............................................................................................. 80 8.1.1 Operating System ............................................................................................... 81 8.1.2 XAMPP................................................................................................................ 81 8.2 Challenges and Solutions ........................................................................................... 83 9.0 Software Integration ....................................................................................................... 85 10.0 Production Expenses ....................................................................................................... 88 10.1 Material Costs ............................................................................................................ 88 11.0 Conclusion and Recommendations ................................................................................ 90 11.1 Conclusion.................................................................................................................. 90 11.2 Recommendations ..................................................................................................... 92 References .............................................................................................................................. 93 Department of Systems and Computer Engineering |Carleton University v
April 7th, 2010
List of Figures
Figure 1: Rotating pairs of rotors [3]................................................................................................ 1 Figure 2: First Generation Design of De Bothezat Quadrotor [3] .................................................... 2 Figure 3: Wound Rotor [10] ........................................................................................................... 16 Figure 4: Brushless Motor Design [11] ........................................................................................... 17 Figure 5: Typical Microcontroller ................................................................................................... 19 Figure 6: Sketch of Proposed Structure ......................................................................................... 23 Figure 7: Initial Frame .................................................................................................................... 23 Figure 8 : Aeroquad Shield ............................................................................................................. 28 Figure 9: Graph of Flight Time versus Battery Life......................................................................... 30 Figure 10: Wiring Diagram for IMR ................................................................................................ 31 Figure 11: Final Design ................................................................................................................... 32 Figure 12: Second Order Complementary Filter [15]..................................................................... 34 Figure 13: Second Order Complementary Filter [15]..................................................................... 35 Figure 14: Possible independent movements in 3D space [16]..................................................... 37 Figure 15: Types of Control Systems: (a) Open Loop (b) Feed-Forward (c) Closed Loop [18] ....... 38 Figure 16: How the damping constant affects the time it takes to reach steady state [19] ......... 40 Figure 17: PID Controller loop [20] ................................................................................................ 42 Figure 18: Feedback loop including system, controller and sensor configuration [21]................. 43 Figure 19: Feedback Control Loop with control components ....................................................... 44 Figure 20: Motor Command outputs (S) during simulation of flight with Serial Monitor ............. 46 Figure 21: Sensor Data output (Q) during simulation of flight with Serial Monitor ...................... 47 Figure 22: AeroQuad Configurator GUI with updatable flight parameters ................................... 48 Figure 23: Various sensor outputs with AeroQuad Configurator GUI ........................................... 49 Figure 24: Original Communication System Design ....................................................................... 55
vi
April 7th, 2010
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
vii
April 7th, 2010
List of Tables
Table 1: Report Contributions........................................................................................................ 12 Table 2: Flight Times for 2 Different Designs ................................................................................. 14 Table 3: Matching Motors for EPP1045 Propeller ......................................................................... 25 Table 4: Total Weight Calculation .................................................................................................. 29 Table 5: PID gain using Ziegler-Nichols Tuning Rule [17] ............................................................... 45 Table 6: Values of KP and corresponding qualitative observations for Ziegler-Nichols Rule ......... 52 Table 7: Relevant differences between TCP and UDP ................................................................... 62 Table 8: List of Materials and Respective Cost .............................................................................. 89
viii
April 7th, 2010
1.0 Introduction
With the recent developments in wireless communications technology and its increased accessibility and affordability, network-based applications are now able to expand into new areas. One of these areas is the domain of Internet Robots. Internet robots have numerous applications and they can be programmed to perform multiple functions. The Internet Mobile Robot (IMR) constructed is an Unmanned Aerial Vehicle (UAV) that will be controlled wirelessly via a web browser.
1.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
Figure 1: Rotating pairs of rotors [3]
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].
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 helicopters 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 robots frame as well as the robots 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 were able to achieve Wi-Fi controllability as the WiShield is one of the first modules of
Department of Systems and Computer Engineering |Carleton University 4
April 7th, 2010
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. 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
April 7th, 2010
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 its 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 vi and viii respectively can be referred to as well. Section 3.0 will expound on the process of designing the IMR. It will outline the research and calculations done to come to the final design of the IMR as well as the component parts. Section 4.0 is complementary to Section 3.0 and it will outline the
April 7th, 2010
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 weve 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 ones 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.
10
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
2.4.1
Individual Contributions
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) 4. User Interface and Webpage Design (Vinayak Goge) Department of Systems and Computer Engineering |Carleton University 11
April 7th, 2010
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 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 Author Rahul Bura Hue Vo Rahul Bura Rahul Bura Hue Vo Mohamed Chande Vinayak Goge Vinayak Goge Mohamed Chande, Hue Vo Rahul Bura, Vinayak Goge Rahul Bura, Mohamed Chande, Vinayak Goge, Hue Vo Editing and Proof Reading Mohamed Chande Vinayak Goge Hue Vo Mohamed Chande Rahul Bura Vinayak Goge Mohamed Chande Hue Vo Rahul Bura Mohamed Chande Rahul Bura, Mohamed Chande, Vinayak Goge, Hue Vo
Table 1: Report Contributions
12
April 7th, 2010
3.0 Robot Design

Robot design is one of the key components of the project. The IMR consists of the structure and logic elements. The structure designs were considered based on manoeuvrability, aerodynamics, and cost of component parts and feasibility of the design. The logic elements were chosen on the design decisions made to address the problem statement. The design process took into consideration key 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 weightweight 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.
13
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.
4 Motors Design Pay Load(oz) (Quadcopter)
8 Motors Design (Octocopter)
0 8 16 24 32 40
19.9 12.6 9.2 7.3 -
11.7 Flight Time (Mins) 9.2 7.5 6.3 5.3 4.6
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 Octocopters 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 of 16oz, the Quadcopter offers a better performance and we settled on the four-motor design for our IMR.
April 7th, 2010
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. Its 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 well 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 the specifications and capabilities of each technology, we decided on implementing WiFi for our robot design.
15
April 7th, 2010
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 magnet stator. [10] An electrical power source is connected to the rotor through the commutator and its brushes providing current flow
Figure 3: Wound Rotor [10]
16
April 7th, 2010
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 motors 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
Figure 4: Brushless Motor Design [11]
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, about the centre. This design differentiation provides several advantages over the brushed motors.
17
April 7th, 2010
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 threedimensional 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. 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.
April 7th, 2010
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.
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.
April 7th, 2010
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 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 dont 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
20
April 7th, 2010
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.
21
April 7th, 2010
4.0 Hardware Components and Construction

Hardware components were chosen from the alternatives presented in Section 3.0. It was important to bear in mind the weight of each component. There were other decisions that needed to be made in the process of choosing an individual component. These decisions were made to ensure compatibility with other component parts. This will be discussed in each of the sections.
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-toweight ratio when compared pound- for-pound with the other alternatives. Carbon fibre also has high tensile strength, low thermal expansion. However, it is relatively expensive when compared to the other alternatives but the small price discrepancy was almost negligible looking at the advantages Carbon Fibre provided, especially since it is significantly lighter and durable compared to the alternatives mentioned in Section 3.1.2. The sketch in Figure 6 shows the proposed basic frame of the IMR. Aluminum was chosen for the square base initially as can be seen in Figure 7. The figure shows the initial structure with the Carbon Fibre rods and aluminum square base. The total weight of the fibre rods, the aluminum base and the miscellaneous screws and nuts used to secure the components is 3.2oz.
22
April 7th, 2010
Figure 6: Sketch of Proposed Structure
Figure 7: Initial Frame
23
April 7th, 2010
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 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.
April 7th, 2010
4.3
4.3.1
Flight and Stability

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.
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
25
April 7th, 2010
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 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
26
April 7th, 2010
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 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
April 7th, 2010
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
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 doesnt 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.
April 7th, 2010
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 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 Base/Frame Microcontroller EE1045 Propellers and Prop Savers 2410-09 Motors Motor Mounts ESCs Bindings and Miscellaneous Parts Battery Total Weight
Weight(oz) 4.2 1.5 1.1 8.2 0.6 2.8 0.4 5.2 24.0
Table 4: Total Weight Calculation
29
April 7th, 2010
Flying weight vs Battery Life

25 20 Battery Life ( Mins) 15 10 5 0 0 10 20 30 40 50 60 70 Flying Weight in Ounces (oz) 12.6 10.5 2100mAh 7.5 7.3 6.4 5.5 4.6 19.9 17.1
9.2
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. Minor electrical skills were also required to solder the component parts and wire them. Figure 10 shows the top level wiring diagram and
April 7th, 2010
Figure 11 shows the final design.
31
April 7th, 2010
Figure 10: Wiring Diagram for IMR
32
April 7th, 2010
Figure 11: Final Design
33
April 7th, 2010
5.0 Stability and Manoeuvre

There are obviously many factors that affect the flight of the Quadcopter. The collaboration of components as previously described is a core factor that determines whether the Quadcopter can take flight or not; the sections to follow describe ways to stabilize the Quadcopter when it is in the air as well as the constraints on the system that will allow us to steer the Quadcopter.
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.
Figure 12: Second Order Complementary Filter [15]
35
April 7th, 2010
Theoretically and through experiments, it can be seen that the Second Order Complementary Filter performs drastically better than a First Order Complementary Filter and without wasting too much more computation time. It can be seen that a Second Order Complementary Filter removes the noise from the sensors quite well and leaves a relatively clean signal as compared to the signal received (refer to Figure 13).
Figure 13: Second Order Complementary Filter [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
36
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. considerations will be discussed in Section 6.0 Wireless Communication.
5.2.1 Six Degrees of Freedom (DOF)
Further
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.
37
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
39
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
40
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
41
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 Sdomain 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]
42
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 Quadcopter is currently at. With three accelerometers placed perpendicular to each other, one can determine the angle for each of the axes.
April 7th, 2010
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:
Figure 18: Feedback loop including system, controller and sensor configuration [21]
44
April 7th, 2010
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. 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 autoDepartment of Systems and Computer Engineering |Carleton University 45
April 7th, 2010
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 P PI PID 0.5KCR KI 0 KD 0
0.45KCR 1.2/PCR 0 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 K D = 0 and KI = 0 for the PID Controller transfer function: H(s) = KP + KI/s + KDs. Adjusting only KP, one must find the value that causes the system to exhibit sustained oscillations. The gain at which the system exhibits sustained oscillations, is known as the critical gain. Using the frequency at which the system oscillates, one can find the critical period. Then
according to Table 1, one can choose the desired values for the PID controller. According to the Ziegler-Nichols Rules, this PID should exhibit close to optimal response for the system, with perhaps minor fine tuning around these gain values.
46
April 7th, 2010
5.3
5.3.1
Flight Configuration and Simulation

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.
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
47
April 7th, 2010
entered in the command line of the serial monitor. To send or request a command, enter the letter corresponding to the command, select send and the values will appear in the Serial Monitor output screen below it. Refer to Figure 20 for the outputs using the command S which requests the motor commands and various other flight parameters separated by a comma. In the same manner, one can simulate flight (without propellers attached for safety reasons) by tilting the Quadcopter and sending the Q command to receive continuous sensor data to monitor the change as the Quadcopter is being moved Figure 21.
Figure 21: Sensor Data output (Q) during simulation of flight with Serial Monitor
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,
April 7th, 2010
levelling limits, etc. Its Graphical User Interface (GUI) is very straight forward and easy to understand and use (refer to Figure 22). The values can be entered into the corresponding box and updated by selecting the Update button at the bottom right corner.
Figure 22: AeroQuad Configurator GUI with updatable flight parameters
In a similar manner, values such as the PID outputs, motor speeds, sensor values, etc. can be plotted and seen in graphical form with the AeroQuad Configurator Figure 23. The continuous time line graph helps one to visually see the oscillations occurring and the sizes of the oscillations.
49
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.
50
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
51
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
52
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 Observations 3.75 Underdamped 3-4 oscillations before it stabilizes 4.75 Close to critically Damped 1-2 small oscillations 5.75 Overdamped Difficult to tip off axis. Resistant to change 6.75 Overdamped Very difficult to tip off axis. Highly resistant to change
Table 6: Values of KP and corresponding qualitative observations for Ziegler-Nichols Rule
53
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.
54
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.
55
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 Quadcopter. Several RF modules were investigated for different wireless standards, and
56
April 7th, 2010
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 radiofrequency (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 endpoint 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 XBees 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
57
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.
58
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.
59
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.
60
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.
61
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 Reliability Connection States Congestion control Overhead TCP Reliable Has states Yes More
Table 7: Relevant differences between TCP and UDP
UDP Unreliable Stateless No Less
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 WiFi chip will be needed to take care of video feedback; if video feedback is a priority.
63
April 7th, 2010
Figure 26: Re-designed Communication System
64
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 implementation proceeds to invoke a function that handles the connection based on the Transport protocol selected.
April 7th, 2010
Figure 28: Handling TCP connection
The function Handlle Connection described in Figure 28, begins by opening up a TCP socket at port 1000; port dedicated for TCP communication on the WiShield. From there, the TCP connection state enters a wait state, listening on this port for data to be transmitted from the Client Application to its socket buffer. If the data is received, it stores this data in the socket buffer. The data was then parsed to determine if it is valid
April 7th, 2010
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) SS Slave Select (active low; output from master)
67
April 7th, 2010
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.
68
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
69
April 7th, 2010
significant 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
70
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.
71
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.
73
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 projects 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 script which were implemented using UDP needed to be redesigned to employ TCP protocol.
April 7th, 2010
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 WiShield; 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.
75
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 WiShield 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.
76
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
77
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.
78
April 7th, 2010
Figure 35: Client Process
79
April 7th, 2010
8.0 User Interface

User interface was developed using HTML coding with embedded PHP scripting. HTML was used to develop the basic structure of the user interface, such as the titles, buttons and etc. PHP was used to implement the client code developed earlier in the term.
Figure 36: User Interface
As seen in the following figure, using PHP the layout of the user interface was successfully divided into menu, header and frame partitions.
80
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.
81
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 PHP extensions
82
April 7th, 2010
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 WiShield 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 website even more cost effective. During development phase, PHP service was enabled on the client computer [36].
April 7th, 2010
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, 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].
April 7th, 2010
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 doesnt 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].
85
April 7th, 2010
9.0 Software Integration

This section discusses the software integration of the Wi-Fi communication module with the embedded system module that was responsible with stability and manoeuvring of the Quadcopter. As discussed in chapter 6.6.2, the solution chosen was to introduce an independent Secondary Microcontroller (SM). A Primary Microcontroller (PM) was used solely to run motors and control the motion of the Quadcopter. The SM was used with the WiShield for Wi-Fi communications purposes only. The WIShield thus does not have to communicate with the SM through the SPI interface, as the Quadcopter control software was uploaded onto the PM. With this configuration, an interface between the two microcontrollers was needed so that they can communicate and exchange control commands. To do this, wires were used to physically connect the microcontrollers on some digital pins. Control commands 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.
86
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.
87
April 7th, 2010
WiShield
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.
88
April 7th, 2010
10.0
Production Expenses
ITEM # 6 6 4 4 1 2 1 2 1 3 3 1 1 1 2 1 4 2 2 1 1 1 1 1 Unit Price US $6.39 US $9.99 US $2.00 US $2.62 US $3.99 US $9.69 US $5.95 $70.40 $59.78 $26.33 $6.95 US $39.95 US $133.90 US $74.95 US $24.95 US $ 7.90 US $ 1.95 US $ 3.00 US $ 1.50 US $1.90 $49.99 $2.99 $4.29 $139.99 CAD $203.38 $39.99 CAD $66.84 Used in order concurrently develop wireless communication code Used with the basic kit For custom circuit design Used for preliminary testing of UAV Stronger than Rhino 2150mAh. Used for final testing and CAD $62.95 Necessary male and female headers to mount the Gyroscope and microcontroller CAD $33.50 CAD $309.23 US $187.90 Total NOTE Brushless Motors Brushless Speed Controller Mount for the motors that also act as heat sinks 750x6mm Propeller saver that prevents propeller from breaking free Rechargeable Battery Pack Battery Charger Microcontroller Module WiFi Module Ultrasonic Sensor Counter Rotating Pair Propellers Gyroscope Board Gyroscope Chip to control stability of UAV Interface for Gyroscope to microcontroller
10.1 Material Costs

Tower Pro 2410-09 Tower Pro Brushless Speed Controller TowerPro Alloy Stick Mount for Motors Carbon Fibre Tubing Prop Saver with 3mm Bands Rhino 2150mAh Lipoly Pack Turnigy 2-3 Cell Lipoly Balance/Charger Arduino MEGA Module AsyncLabs WiFI Shield Low cost Ultrasonic Range Finder EPP1045 Propellors Gyro Breakout Board IDG500 Dual 500 degree/sec IMU 5 Degrees of Freedom AeroQuad Shield v1.5 Stackable Headers Right Angle Headers Straight Male Header (9 Pin) Female Header (5 Pin) Female Header (9 Pin) Arduino Microcontroller Basic Kit 6 Foot USB cable Mini Breadborad 18A DC Power Supply 3-cell 2200mAh Battery Pack
89
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).
90
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 remotecontrolled 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
91
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.
92
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.
93
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. [15] 2nd Order Comp Filter. Quaduino. [Online] [Cited: March 28, 2010.] http://www.rcgroups.com/forums/showpost.php?p=12082524&postcount=1286. Department of Systems and Computer Engineering |Carleton University 94
April 7th, 2010
[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/WiFi. [27] WiShield 1.0 - Asynclabs Documents. asynclabs. [Online] [Cited: 10 23, 2009.] http://asynclabs.com/wiki/index.php?title=WiShield_1.0. [28] Transmission Control Protocol - Wikipedia. Wikipedia. [Online] [Cited: 03 25, 2010.] http://en.wikipedia.org/wiki/Transmission_Control_Protocol. [29] ch2_2010 notes. Instructor:. [Online] 03 25, 2010. http://www.sce.carleton.ca/courses/sysc-4502/w10/ch2_2010.pdf. [30] User DEatagram Protocol - Wikipedia. Wikipedia. [Online] [Cited: 03 27, 2010.] http://en.wikipedia.org/wiki/User_Datagram_Protocol. [31] Understanding the SPI bus with NI LabVIEW. Developer Zone. [Online] [Cited: 03 27, 2010.] http://zone.ni.com/devzone/cda/tut/p/id/9119. Department of Systems and Computer Engineering |Carleton University 95
April 7th, 2010
[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-arduinomega_inline.png. [40] What Is PID. Expertune. [Online] [Cited: March 28, 2010.] http://www.expertune.com/tutor.html.
96

Internet Mobile Robot The Quad Copter

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Internet Mobile Robot The Quad Copter

Загружено:

Авторское право:

Доступные форматы

Internet Mobile Robot

Supervisor: Professor Peter X. Liu

A report submitted in partial fulfillment of the requirements of SYSC-4907 Engineering Project

Department of Systems and Computer Engineering Faculty of Engineering Carleton University