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
145
Embed
Internet Mobile Robot - 123seminarsonly.com · Web viewThe Internet Mobile Robot (IMR) constructed is an Unmanned Aerial Vehicle (UAV) that will be controlled wirelessly via a web
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Internet Mobile RobotThe Quadcopter
Group 13Rahul Bura
Mohamed ChandeVinayak Goge
Hue Vo
Supervisor: Professor Peter X. Liu
A report submitted in partial fulfillment of the requirements of SYSC-4907 Engineering Project
Department of Systems and Computer EngineeringFaculty of Engineering
Carleton University
April 7, 2010
Internet Mobile Robot April 7th, 2010
AbstractGroup 13 consisting of Rahul Bura, Mohamed Chande, Vinayak Goge and Hue Vo have
developed a start-up project as a partial fulfillment for SYSC 4907 Engineering Project: Internet
Mobile Robot: The Quadcopter. The objective of the project was to design and implement a
Quadcopter (helicopter with four propellers) that can take flight and be controlled using a
remote client application over the internet.
Currently, different Quadcopter designs have been implemented. However, most of
them have used handheld Radio Control implementations. With the design implemented in this
project, different applications can be developed to control the Quadcopter over the internet
from a remote location. This opens up different possibilities with the design being applied in
different areas ranging from Surveillance to Virtual Gaming Technologies to Military
Applications.
Different designs were explored and from these designs, it was determined that we
would need a microcontroller to run control algorithms, a Wi-Fi chip to facilitate wireless
communication and a webpage to for user interaction. Any command received from the WI-Fi
chip is processed by the microcontroller and executed by all the components including motors,
speed controllers and inertial measurement units that are used to stabilize the Quadcopter.
The communication system implemented a server/client architecture with the Wi-Fi
chip behaving as a server that acts to reply to requests from a remote client webpage. For the
data transfer mechanism, TCP protocol was used over the Internet to send traffic from the
client to the server and bidirectionally. The webpage, implemented as a simple Graphical User
Department of Systems and Computer Engineering |Carleton University 1
Internet Mobile Robot April 7th, 2010
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 2
Internet Mobile Robot April 7th, 2010
AcknowledgementsWe would like to formally thank Professor Peter X. Liu for supervising and for his
guidance throughout the Internet Mobile Robot project as well as giving us the opportunity to
explore and experiment with our creativity.
We would also like to thank the Technical Support Staff, Danny Lemay, Jerry Buburuz
and Daren Russ, for their support throughout the project. Their prompt actions, experience
and knowledge allowed us to surpass various milestones throughout the duration of the
project.
Department of Systems and Computer Engineering |Carleton University 3
Internet Mobile Robot April 7th, 2010
Table of Contents
Abstract.................................................................................................................................... i
Acknowledgements................................................................................................................ iii
List of Figures..........................................................................................................................vi
List of Tables.........................................................................................................................viii
1.0 Introduction.....................................................................................................................11.1 Background.................................................................................................................11.2 Motivation..................................................................................................................31.3 Problem Statement.....................................................................................................31.4 Proposed Solution and Accomplishments..................................................................31.5 Overview of the Remainder of the Report..................................................................6
2.0 The Engineering Project...................................................................................................82.1 Health and Safety.......................................................................................................82.2 Engineering Professionalism.......................................................................................92.3 Project Management................................................................................................102.4 Individual Contributions...........................................................................................11
3.1.1 Number of Motors............................................................................................133.1.2 Frame................................................................................................................15
3.2 Communications.......................................................................................................153.3 Flight and Stability....................................................................................................163.4 Flight Control............................................................................................................183.5 Power.......................................................................................................................20
4.0 Hardware Components and Construction.....................................................................224.1 Frame and Structure.................................................................................................224.2 Microcontroller.........................................................................................................244.3 Flight and Stability....................................................................................................25
4.3.1 Propeller and Motor Combination Configuration.............................................254.3.2 Electronic Speed Controller (ESC).....................................................................264.3.3 Six Degrees of Freedom (DOF)..........................................................................27
4.5.1 Flight Time and Battery Power Dependancy.....................................................294.6 Design Implementation and Final Structure.............................................................30
5.0 Stability and Manoeuvre................................................................................................335.1 Filtering Noise...........................................................................................................33
Department of Systems and Computer Engineering |Carleton University 4
Internet Mobile Robot April 7th, 2010
5.1.2 Second Order Complementary Filter................................................................345.2 Feedback Control......................................................................................................35
5.2.1 Six Degrees of Freedom (DOF)..........................................................................365.2.2 System Control Theory......................................................................................375.2.3 Proportional, Integral, Derivative Controller.....................................................405.2.4 Feedback Control Mechanism: Inertial Measurement Units.............................425.2.5 Feedback Control Loop.....................................................................................435.2.6 Flight Tuning Using Ziegler-Nichols Rules..........................................................45
5.3 Flight Configuration and Simulation.........................................................................465.3.1 Flight Configuration Methods and Tools...........................................................465.3.2 Pre-Flight Tests..................................................................................................495.3.3 Flight Control and Results.................................................................................50
6.0 Wireless Communication (Server).................................................................................546.1 Communication System Overview............................................................................546.2 Wireless Standards...................................................................................................55
6.3 WiShield Configurations...........................................................................................586.3.1 Network Type....................................................................................................586.3.2 TCP vs UDP........................................................................................................59
6.4 WiShield Functionality..............................................................................................646.5 Serial Peripheral Interface........................................................................................666.6 Challenges and Solutions..........................................................................................69
7.0 Wireless Communication (Client)..................................................................................737.1 Client Design.............................................................................................................737.2 Client Process...........................................................................................................77
8.0 User Interface................................................................................................................798.1 Software Requirements............................................................................................80
10.0 Production Expenses......................................................................................................8810.1 Material Costs...........................................................................................................88
11.0 Conclusion and Recommendations................................................................................9011.1 Conclusion................................................................................................................9011.2 Recommendations....................................................................................................92
output value and a set desired input value and use it to calculate and control the gain of
the system and maximize the response time. The Proportional Controller determines
the reaction to the current error, the Integral Controller sums the recent errors and
provides a better steady state response, the Derivative Controller enhances transient
response but uses the rate at which the error has been changing and therefore can be
unpredictable and cause a lot of jitters. Together, the three terms are used to control
the gain and response time of the system. The tradeoff for speed is how much the
system will oscillate. For a system like the Quadcopter, too much oscillation is
undesirable so the gains will be set accordingly.
The time domain transfer function can be seen and derived fromFigure 17. The
S-Domain transfer function of a PID is: H(s) = KP + KI/s + KDs = KDs2 + KPs+ KI. Using the S-
domain transfer function, one can determine where the poles and zeros of the system
are. The poles are at the denominator factors and the zeros are at the numerator
factors for a fully factored transfer function. For a system to be stable, all poles must be
in the open left half plane (OLHP). If there are any poles in the open right half plane
(OLHP), the system is considered unstable. Any poles on the imaginary axis is
considered marginally stable (or pure oscillatory). The closer the poles are to the
imaginary axis, the quicker the response, but at the same time the system can become
more oscillatory which is undesirable for a Quadcopter. Over time, it is expected that
the error in the feedback loop approach zero: the steady state of the system with the
current input. [17]
Department of Systems and Computer Engineering |Carleton University 43
Internet Mobile Robot 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
Department of Systems and Computer Engineering |Carleton University 44
Internet Mobile Robot April 7th, 2010
Quadcopter is currently at. With three accelerometers placed perpendicular to each
other, one can determine the angle for each of the axes.
The gyroscope maintains the direction by detecting the change in orientation.
Gyroscopes maintain the orientation using the concepts of conservation of momentum.
The gyroscope continuously spins about an axis. Once the spin is axis is skewed, the
output will tell us how the gyroscope is moved and what must be done in order to
balance it out again. As with the accelerometer, the gyroscope also has to the zeroed to
determine the rate of change at the desired constant value (usually at rest). The
gyroscope would then output a certain voltage level when a change in orientation is
detected and this value can then be used to adjust the orientation accordingly.
Using the one device without the other is simply not sufficient. Both devices
must be used in tandem in order to control both the orientation and direction of
movement of the Quadcopter. PIDs will determine how fast it will reach that steady
state while accelerometers and gyroscopes determine the direction and magnitude of
adjustment required to reach steady state due to the inputs. Both the gyroscopes and
accelerometers can be found in compact forms in an integrated chip the size of a
quarter.
5.2.5 Feedback Control Loop
Now that we have generally described all the desired components that will help
stabilize and manoeuvre the Quadcopter, we can put the components together. A
generic form for a feedback control loop with the controller and sensors is:
Department of Systems and Computer Engineering |Carleton University 45
Internet Mobile Robot April 7th, 2010
Figure 18: Feedback loop including system, controller and sensor configuration [21]
We can replace the generic controller with our controller of choice: the PID
controller. Similarly, the System is our Quadcopter (consisting of the structure, motors,
propellers, etc.) and our output sensors for the feedback loop are the three
accelerometers and three gyroscopes. Our feedback control loop design for the
Quadcopter can be represented by the block diagram below.
Figure 19: Feedback Control Loop with control components
From Figure 19, one can follow the feedback loop to determine the sequential
output of each component. The difference between the sensor outputs and the
reference signal is determined which is then used by the PID to determine the optimal
input to the Quadcoptor so that the output of the system is as desired (the system
output being the flight orientation and direction). The accelerometer and gyroscope
outputs will then be fed through the filter and the measured command error will be
again calculated. The filter was added after the sensor data and before calculation of
the measured command error so that it can remove the noise from the sensors before
using the signal in any component of the system.
Department of Systems and Computer Engineering |Carleton University 46
Internet Mobile Robot April 7th, 2010
It should be understood that each control component uses a different controller.
The Quadcopter system as a whole can be split into different subsystems. The PID
values for the Roll control may be different than that of the Pitch, Yaw or Throttle. In
addition to those PID controllers, there are also different PID controllers for the auto-
levelling (or stabilization) of the Quadcopter to try to optimize the response to a
disturbance to the system.
5.2.6 Flight Tuning Using Ziegler-Nichols Rules
Many systems can be easily modelled mathematically and an analytical approach
to determining the values for the PID controller can be used. For systems that are
difficult to model mathematically other approaches such as the Ziegler-Nichols Rule can
be used to obtain an educated estimation for the PID which can later be fine tuned
further. [17]
Type of Controller KP KI KD
P 0.5KCR 0 0
PI 0.45KCR 1.2/PCR 0
PID 0.6 KCR 2/PCR 0.125PCR
Table 5: PID gain using Ziegler-Nichols Tuning Rule [17]
To use the Ziegler-Nichols Rule, one must find the critical gain, KCR, and critical
period, PCR, of the system. To find those two values, one must set KD = 0 and KI = 0 for
the PID Controller transfer function: H(s) = KP + KI/s + KDs. Adjusting only KP, one must
find the value that causes the system to exhibit sustained oscillations. The gain at which
the system exhibits sustained oscillations, is known as the critical gain. Using the
frequency at which the system oscillates, one can find the critical period. Then Department of Systems and Computer Engineering |Carleton University 47
Internet Mobile Robot April 7th, 2010
according to Table 1, one can choose the desired values for the PID controller.
According to the Ziegler-Nichols Rules, this PID should exhibit close to optimal response
for the system, with perhaps minor fine tuning around these gain values.
5.3 Flight Configuration and Simulation
5.3.1 Flight Configuration Methods and Tools
There are many variables that must be configured in order to control the
Quadcopter in flight. These variables are stored in EEPROM and read before and
throughout operation. There are two methods of setting these variables: Using the
Serial Monitor or with the aid of AeroQuad Configurator v1.2.
The Serial Monitor is built into the Arduino development environment. It allows
for serial communication between the Arduino board and the user computer via USB.
This communication medium is used to upload programs as well as to debug via print
statements and send and request flight configuration parameters.
Department of Systems and Computer Engineering |Carleton University 48
Internet Mobile Robot April 7th, 2010
Figure 20: Motor Command outputs (S) during simulation of flight with Serial Monitor
The commands to send and request flight parameters can be found in
SerialTelemetry.pde and SerialCommand.pde, respectively. The commands need to be
entered in the command line of the serial monitor. To send or request a command,
enter the letter corresponding to the command, select send and the values will appear
in the Serial Monitor output screen below it. Refer to Figure 20 for the outputs using
the command ‘S’ which requests the motor commands and various other flight
parameters separated by a comma. In the same manner, one can simulate flight
(without propellers attached for safety reasons) by tilting the Quadcopter and sending
the ‘Q’ command to receive continuous sensor data to monitor the change as the
Quadcopter is being moved Figure 21.
Department of Systems and Computer Engineering |Carleton University 49
Internet Mobile Robot April 7th, 2010
Figure 21: Sensor Data output (Q) during simulation of flight with Serial Monitor
Alternatively, AeroQuad Configurator is an open source software developed by
AeroQuad to test and adjust flight parameters of the Aeroquad before flight. This
software can also be used to set various parameters that control the flight of the
Quadcopter such as the PIDs, filter time constant, transmitter/receiver sensitivity,
levelling limits, etc. Its Graphical User Interface (GUI) is very straight forward and easy
to understand and use (refer to Figure 22). The values can be entered into the
corresponding box and updated by selecting the Update button at the bottom right
corner.
Department of Systems and Computer Engineering |Carleton University 50
Internet Mobile Robot April 7th, 2010
Figure 22: AeroQuad Configurator GUI with updatable flight parameters
In a similar manner, values such as the PID outputs, motor speeds, sensor values,
etc. can be plotted and seen in graphical form with the AeroQuad Configurator Figure
23. The continuous time line graph helps one to visually see the oscillations occurring
and the sizes of the oscillations.
Department of Systems and Computer Engineering |Carleton University 51
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 52
Internet Mobile Robot 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
Department of Systems and Computer Engineering |Carleton University 53
Internet Mobile Robot 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
Department of Systems and Computer Engineering |Carleton University 54
Internet Mobile Robot April 7th, 2010
can still affect the flight of the Quadcopter lie in the software implementation and
stability modelling.
As seen in video Video\PID_underdamped, the roll and pitch of the Quadcopter
will readjust when it is forced off its equilibrium position. It can also be seen that this
levelling PID combination causes the system to oscillate many times before it reaches its
equilibrium point again. This is a sign that the system is very underdamped.
Similarly, Video\PID_overdamped, it can be seen that the system takes some
time to readjust as it relatively slowly moves back to the equilibrium point. As
previously stated, it is desirable to attain a critically damped system. In practice, it is
very difficult to attain and a 5% overshoot is considered desirable. In Video\
PID_closeToCriticallyDamped, it can be seen that the rate at which it readjusts relative
to the overdamped has visibly increased and the number of oscillations and magnitude
of oscillations has significantly decreased.
The above videos and oscillations were obtained with the following KP values and
KI = 0 and KD = 0 for the Roll and Pitch:
KP Observations3.75 Underdamped
3-4 oscillations before it stabilizes4.75 Close to critically Damped
1-2 small oscillations5.75 Overdamped
Difficult to tip off axis. Resistant to change6.75 Overdamped
Very difficult to tip off axis. Highly resistant to changeTable 6: Values of KP and corresponding qualitative observations for Ziegler-Nichols Rule
Department of Systems and Computer Engineering |Carleton University 55
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 56
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 57
Internet Mobile Robot 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
Department of Systems and Computer Engineering |Carleton University 58
TCP: Control Commands
UDP: Feedback
Internet Mobile Robot April 7th, 2010
Quadcopter. Several RF modules were investigated for different wireless standards, and
some have been detailed in the following sub sections. The solution for the project is
also identified and discussed in the subsequent sub sections.
6.2.1 ZigBee
ZigBee is a wireless mesh networking standard that is based on the IEEE 802.15.4
specification for WPANs. The technology behind ZigBee is simpler and less expensive.
Due to its low cost, the technology can be widely deployed in wireless control and
monitoring applications, for instance home automation. ZigBee is targeted at radio-
frequency (RF) applications that require a low data rate, long battery life, and secure
networking. The low power-usage allows longer life with smaller batteries, and the
mesh networking provides high reliability and larger range [23].
XBee RF transceiver modules are embedded solutions providing wireless end-
point connectivity to devices. These modules use ZigBee networking protocol for fast
point-to-multipoint or peer-to-peer networking. They are designed for high-throughput
applications requiring low latency and predictable communication timing [24].
The XBee chip is ideal for our quad-copter communication purposes and is
designed to work with the Arduino Microcontroller. However, since the client
application accesses the internet, there needs to be a device that connects the XBee
module to a wireless local area network (WLAN), simply because the standards used for
WLANs and XBee’s are different and hence translation is needed [25].
ConnectPort X4 gateway is a router that is capable of connecting an XBee
module with a WLAN; it provides IP Network connectivity to WPANs. This Gateway
Department of Systems and Computer Engineering |Carleton University 59
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 60
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 61
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 62
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 63
Internet Mobile Robot 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
Department of Systems and Computer Engineering |Carleton University 64
Internet Mobile Robot April 7th, 2010
disadvantages of UDP and TCP. Based on the comparison, the appropriate transport
protocol was selected for the Quadcopter operations.
Category TCP UDP
Reliability Reliable Unreliable
Connection States Has states Stateless
Congestion control Yes No
Overhead More Less
Table 7: Relevant differences between TCP and UDP
From Table 7, it can be concluded that TCP is best where reliable communication
is needed; in this case for the Quadcopter control commands. UDP is best for real-time
applications that can tolerate packet loss; in this case if video feedback is implemented.
Thus, the ideal way of implementing the design is to use TCP for control commands in
uplink and UDP for feedback in the downlink as shown in Figure 24Figure 24: Original
Communication System Design of section 6.1.
The project goals were re-defined earlier in the course of development of the
project to exclude video feedback. Hence the feedback connection was implemented
using TCP, as seen in Figure 26. Moreover, as discussed in section 6.3.2, the WiShield
only implements one application at a time, either UDP or TCP; this is consistent with the
re-defined project goals.
As a note, for future groups that may undertake a similar project, a separate Wi-
Fi chip will be needed to take care of video feedback; if video feedback is a priority.
Department of Systems and Computer Engineering |Carleton University 65
Internet Mobile Robot April 7th, 2010
Department of Systems and Computer Engineering |Carleton University 66
TCP: Control Commands
TCP: Feedback
Figure 26: Re-designed Communication System
Internet Mobile Robot 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
Department of Systems and Computer Engineering |Carleton University 67
Start
WiShield Network
Configuration
Connect to Network
Handle Connection
Connected ?
Update Connection
Status
YES
NO
Internet Mobile Robot April 7th, 2010
implementation proceeds to invoke a function that handles the connection based on the
Transport protocol selected.
Figure 28: Handling TCP connection
The function Handlle Connection described in Figure 28, begins by opening up a
TCP socket at port 1000; port dedicated for TCP communication on the WiShield. From
there, the TCP connection state enters a wait state, listening on this port for data to be Department of Systems and Computer Engineering |Carleton University 68
Data Valid
?Write to a digital Pin
Send Reply
Update Connection State
NAKACK
Empty buffer
Open TCP Socket
Initialize Connection State
Listen on Port
Data Received? Store data in buffer
Parse data
YESNO
Internet Mobile Robot April 7th, 2010
transmitted from the Client Application to its socket buffer. If the data is received, it
stores this data in the socket buffer. The data was then parsed to determine if it is valid
or corrupted from the wireless transfer. The routine then continues to invoke a function
that runs the motors accordingly. These control functions were implemented in the
code that runs on the Arduino microcontroller. The WiShield communicates with the
Arduino microcontroller through a serial to parallel interface whose operation is
described further in section 6.5. Once the commands have been executed, the WiShield
was programmed to reply to the client application with the previous command
executed. Furthermore, the socket buffer was emptied to allow for new data to be
stored. The connection state was also changed to wait state to indicate that the
WiShield is waiting for a new command from the client application.
6.5 Serial Peripheral Interface
Serial Peripheral Interface also known as SPI bus is a synchronous serial data link
standard that operates in full duplex mode. A full duplex mode is a system in which
parties can communicate bi-directionally simultaneously.
In SPI, devices communicate in master/slave mode where the master device
initiates the data frame and the slave device is the recipient of this data frame. For
communication between the Microcontroller and WiShield, this approach is used [31].
The SPI bus specifies four logic signals:
SCLK — Serial Clock (output from master)
MOSI/SIMO — Master Output, Slave Input (output from master)
MISO/SOMI — Master Input, Slave Output (output from slave)Department of Systems and Computer Engineering |Carleton University 69
Internet Mobile Robot April 7th, 2010
SS — Slave Select (active low; output from master)
Figure 29, shows these signals in a single-slave configuration, as in the case of
the Microcontroller-WiShield communication. SCLK is generated by the master and is an
input to all slaves; this case only one slave. MOSI carries data from master to slave.
MISO carries data from slave back to master. A slave device is selected when the master
asserts its SS signal [31].
For example, if the WiShield sends control commands to the microcontroller,
then the WiShield becomes the master which then asserts the SS signal to select the
microcontroller as the slave and the communication proceeds.
Figure 29: SPI bus, single-master single-slave
For the WiShield, Digital pins 10 to 13 are allocated for SPI purposes;
communication with the Arduino microcontroller. These pins are highlighted in Figure
30, which is the schematic of the WiShield RF transceiver module.
Department of Systems and Computer Engineering |Carleton University 70
Master Slave
SCLK
MOSI
MISO
SS
Internet Mobile Robot April 7th, 2010
Figure 30: WiShield Schematic [27]
During each SPI clock cycle, a full duplex data transmission occurs in which:
master sends a bit on the MOSI line; slave reads it from the same line
slave sends a bit on the MISO line; master reads it from the same line
Transmissions normally involve two shift registers of some given word size, such
as eight bits, one in the master and one in the slave; they are connected in a ring. Data is
usually shifted out with the most significant bit first, while shifting a new least significant
Department of Systems and Computer Engineering |Carleton University 71
Internet Mobile Robot April 7th, 2010
bit into the same register. After that register has been shifted out, the master and slave
have exchanged register values [32].
Then each device takes that value and invokes appropriate functions with it,
such as running motor functions in the case of Arduino microcontroller. If there is more
data to exchange, the shift registers are loaded with new data and the process repeats.
With this serial communication process, if the SPI pins are in use, then they
cannot be used for any other purpose. As such, a challenge arose in that digital pins 10
to 13 are also Pulse Width Modulation (PWM) pins required for motor functionality. This
challenge, along with others is described in section 6.6. Solutions to these challenges are
justified in the same section as well.
6.6 Challenges and Solutions
The following section describes the different challenges faced in the duration of
the project, in terms of design and implementation of the wireless communication
interface. The following challenges came up and their respective solutions are outlined
as well.
6.6.1 Debugging
The software development is done using two languages, Arduino language and
Embedded C. Arduino language is used to initialize and run the WiShield where as C
language is used to program the server implementation of the WiShield. The WiShield
presents a major problem when it comes to debugging a program implementation, as
there is no integrated development environment (IDE) that comes with the product. The
Department of Systems and Computer Engineering |Carleton University 72
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 73
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 74
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 75
Internet Mobile Robot April 7th, 2010
7.0 Wireless Communication (Client)A client is an application or a system which requires remote service from another
system, usually a server. The following section describes how the client system
developed satisfies the project’s objectives.
The objective of the client system was to control the quad-copter through a
graphical user interface. The client system is developed in order to provide service to
the user. In the overall communication system the user is referred to as the client since
the user is one that sends requests to Wi-Shield mounted on the Arduino
microcontroller.
7.1 Client Design
Earlier in the winter term, a client script was written in Arduino language and
embedded C. This script was developed concurrently with the server script to establish a
wireless communication between Wi-Shield and a user, in this case a user running on
Fedora 10 operating system. This communication was achieved through an ad-hoc
network between a laptop running Fedora 10 environment and Wi-Shield.
Initially, UDP protocol was implemented in the wireless communication between
the client and the server script. UDP protocol was chosen since live video feedback was
one of the user interface objectives. However, after re-definition of the project goals
mid-way through the year, live video feedback was excluded. Therefore, this exclusion
of live video feedback influenced the change in transport protocol. The client and server
Department of Systems and Computer Engineering |Carleton University 76
Internet Mobile Robot April 7th, 2010
script which were implemented using UDP needed to be redesigned to employ TCP
protocol.
The following figure illustrates the ideal behaviour of how the client system
should interact with Wi-Shield.
Figure 32: Ideal Layout of Client System in relation with WiShield
User, who is also the client, utilizes the user interface to select which command
the quad-copter should execute. This command is formed into an IP packet and then
sent over the internet to the server which is running the XAMPP services. The server
executes the PHP code and sends the appropriate manoeuvre command to the Wi-
Shield; in turn the Wi-Shield calls the C subroutine which turns the motors accordingly.
After receiving the manoeuvre command, Wi-Shield sends a reply back to the server, in
turn sends the reply back to the client which is displayed through the user interface.
Figure 33: Actual Implementation of Client System in relation with Wi-Shield illustrates
implementation of communication between Wi-Shield and a user, and how the client
system actually interacts with Wi-Shield.
Department of Systems and Computer Engineering |Carleton University 77
Internet Mobile Robot April 7th, 2010
Figure 33: Actual Implementation of Client System in relation with Wi-Shield
In contrast with the ideal behaviour of the client system described above, user,
in this case, is a system which is running on Fedora 10 platform; and in addition the
system also has locally installed and running XAMPP services. The locally running XAMPP
services on the user system is necessary since during the development phase the web
browser, which embodies the user interface, was not hosted on a server in order to
keep the project cost down and moreover, was not essential to the development phase.
User selects which command the quad-copter should execute through the user
interface. This command is embodied into a packet along with the PHP and HTML code.
The locally running XAMPP services execute the PHP code in the packet and forward the
embedded manoeuvre command to the Wi-Shield over the Ad-Hoc network. Once Wi-
Shield receives the command, it calls respective C subroutine which turns the motors
accordingly. Subsequent to the receiving of the command, Wi-Shield sends a reply back
to the user. The XAMPP services encase the reply with appropriate PHP and HTML code
and display it on the web browser.
Department of Systems and Computer Engineering |Carleton University 78
Internet Mobile Robot 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
Department of Systems and Computer Engineering |Carleton University 79
Reply Received?
Setup Socket and Connection
Bind to port in computer
Ask user for the next move
Verify the input
Send user input to Wi-Shield
Wait for Reply
True
False
False
True
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 80
Internet Mobile Robot April 7th, 2010
Figure 35: Client Process
Department of Systems and Computer Engineering |Carleton University 81
Internet Mobile Robot April 7th, 2010
8.0 User InterfaceUser interface was developed using HTML coding with embedded PHP scripting.
HTML was used to develop the basic structure of the user interface, such as the titles,
buttons and etc. PHP was used to implement the client code developed earlier in the
term.
Figure 36: User Interface
As seen in the following figure, using PHP the layout of the user interface was
successfully divided into menu, header and frame partitions.
Department of Systems and Computer Engineering |Carleton University 82
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 83
Internet Mobile Robot 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
Department of Systems and Computer Engineering |Carleton University 84
Internet Mobile Robot April 7th, 2010
PHP extensions
MYSQL Database
Perl
Server Side Includes (SSI) and etc.
Due to various scripting services, Apache Web service, SQL Database support and
many more functionalities, XAMPP package offers great varieties of functionalities which
will be useful for future scalability of the wireless communication between Wi-Shield
and user interface [34].
Apache Web Server is used as a host server for
websites with static and dynamic content. A locally
installed version of Apache is useful when developing
web applications since the programmer can preview
and debug the code during development phase.
Moreover, Apache also provides server-side programming language support for scripts
including but not limited to Perl and PHP [35].
PHP is a scripting language designed for web
development in order to produce dynamic web pages. This is
achieved by integrating PHP code with HTML code.
Moreover, a server which hosts a website with embedded PHP scripting needs a PHP
processor module in order to execute the PHP code. However, most of the web host
services offer free PHP support on their servers, thus making use of PHP to develop
Department of Systems and Computer Engineering |Carleton University 85
Internet Mobile Robot April 7th, 2010
website even more cost effective. During development phase, PHP service was enabled
on the client computer [36].
During development and testing phase of the project only the following services
were enabled while using XAMPP:
Apache Web Service
PHP Service
PHP extensions
8.2 Challenges and Solutions
Various challenges were dealt with during the research, development and testing
phase of the client system.
One of the issues stumbled upon was the Wi-Shield connectivity problem. While
developing the primary server and client communication earlier in the development
phase, there seem to be no response from the Wi-Shield to the client even though all
the code seemed to be accurate and properly thought out. There was no network setup
phase that even occurred as intended. The Arduino Programming environment did not
come with any debugger tools which could be used to fix the code. This obstacle was
overcome by the use of Wireshark, which is an open-source network protocol analyzer.
It is used to troubleshoot networks, communications protocol development. Wireshark
achieves this by analyzing the packet traffic through the system, which it is installed on.
With the help of Wireshark, it came to attention that the client was sending “Gratuitous
ARP request”, which is an Address Resolution Protocol request packet where the source
and destination IP are the same. This pointed out the error in the Wi-Shield header file, Department of Systems and Computer Engineering |Carleton University 86
Internet Mobile Robot April 7th, 2010
which asked for the wrong IP address as an input. It should have asked for the client IP
address rather than its own IP address [37].
Moreover, another issue developed when integrating User Interface code and
client code developed earlier in the term. Proper manoeuvre code in client code needed
to be called when a specific button was clicked. For example, the client code that sends
the Left command must be called when user clicks on the Left button. Therefore, PHP
code must call the client code, written in C language, each time a direction button is
clicked. However, a C function call made in PHP doesn’t execute when the button is
clicked; it executes when the page loads. This behaviour occurs due to the fact that PHP
is a server side script; in other words, PHP is executed on a server which hosts the
website. In order to get around this problem, PHP form method can be employed. After
clicking on a button, the PHP code fills out a “form” with the C code embedded within
the PHP code and sends it to the server; which executes the PHP code and forwards the
appropriate manoeuvre command to Wi-Shield. For example, if Right button was
clicked, the PHP code for that button with the embedded C code will be sent to the
server as a form entry. Afterwards, the server would execute the PHP code and send
turn Right command to Wi-Shield [38].
Department of Systems and Computer Engineering |Carleton University 87
Internet Mobile Robot April 7th, 2010
9.0 Software IntegrationThis section discusses the software integration of the Wi-Fi communication
module with the embedded system module that was responsible with stability and
manoeuvring of the Quadcopter.
As discussed in chapter 6.6.2, the solution chosen was to introduce an
independent Secondary Microcontroller (SM). A Primary Microcontroller (PM) was used
solely to run motors and control the motion of the Quadcopter. The SM was used with
the WiShield for Wi-Fi communications purposes only. The WIShield thus does not have
to communicate with the SM through the SPI interface, as the Quadcopter control
software was uploaded onto the PM.
With this configuration, an interface between the two microcontrollers was
needed so that they can communicate and exchange control commands. To do this,
wires were used to physically connect the microcontrollers on some digital pins. Control
commands were sent from the SM to the PM, which then consequently ran the motors
appropriately.
Each wired connection was used to indicate a control command sent from the
client application. With this process, every control command from the client process
requires usage of two pins, one on each microcontroller. Some of the commands used
to run the Quadcopter include start, stop, increase revolutions and decrease
revolutions. An example is provided below to show how the two microcontrollers
communicate when a start command is issued from the client application.
Department of Systems and Computer Engineering |Carleton University 88
Internet Mobile Robot 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.
Department of Systems and Computer Engineering |Carleton University 89
Internet Mobile Robot April 7th, 2010
Figure 38: Pin 5 of SM (with WiShield) connected to digital pin 32 of PM using a wire [39]
The addition of the secondary microcontroller however adds to the overall
weight of the Quadcopter. The overall weight of the copter becomes 1Kg. This does not
present a problem as the motors chosen are capable of lifting up to 2 Kg of weight.
Furthermore, the batteries used, can power both the microcontrollers and provide up to
5 minutes of flight time before they drain. The integration process was implemented
with apparent success and the two microcontrollers communicated as expected.
Department of Systems and Computer Engineering |Carleton University 90
Internet Mobile Robot April 7th, 2010
10.0 Production Expenses
10.1 Material Costs
ITEM # Unit Price Total NOTE
Tower Pro 2410-09 6 US $6.39
US $187.90
Brushless Motors
Tower Pro Brushless Speed Controller
6 US $9.99 Brushless Speed Controller
TowerPro Alloy Stick Mount for Motors
4 US $2.00Mount for the motors that also
act as heat sinks
Carbon Fibre Tubing 4 US $2.62 750x6mm
Prop Saver with 3mm Bands 1 US $3.99Propeller saver that prevents propeller from breaking free
Rhino 2150mAh Lipoly Pack 2 US $9.69 Rechargeable Battery Pack
[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.
[11] Brushless DC Electric Motor - Wikipedia. Wikipedia. [Online] [Cited: September 23, 2009.] http://en.wikipedia.org/wiki/Brushless_DC_electric_motor.
Department of Systems and Computer Engineering |Carleton University 96
Internet Mobile Robot April 7th, 2010
[15] 2nd Order Comp Filter. Quaduino. [Online] [Cited: March 28, 2010.] http://www.rcgroups.com/forums/showpost.php?p=12082524&postcount=1286.
[16] Stone, B.J., Degrees of Freedom. THe University of Western Australia. [Online] [Cited: January 16, 2010.] http://school.mech.uwa.edu.au/~bjs/Vibration/OneDOF/DOF6.gif.
[17] Ogata, Katsuhiko., Modern Control Engineering Fifth Edition. Upper Sadle River : Prentice Hall, 2010.
[18] , Control Systems. Wikipedia. [Online] [Cited: March 28, 2010.] http://en.wikipedia.org/wiki/File:Control_Systems.png.
[19] 2nd Order Damping Ratios. Wikipedia. [Online] [Cited: March 28, 2010.] http://en.wikipedia.org/wiki/File:2nd_Order_Damping_Ratios.svg.
[20] File:Pid-feedback-nct-int-correct.png. Wikipedia. [Online] October 26, 2006. [Cited: January 23, 2010.] http://en.wikipedia.org/wiki/File:Pid-feedback-nct-int-correct.png.
[21] File:Feedback Loop with descriptions. Wikipedia. [Online] [Cited: March 28, 2010.] http://en.wikipedia.org/wiki/File:Feedback_loop_with_descriptions.svg.
[22] Pre-flight Checkout. Aeroquad. [Online] [Cited: March 28, 2010.] http://aeroquad.com/content.php?118.