quadcopter - walter scott, jr. college of...
TRANSCRIPT
Quadcopter
Final Report
Spring Semester 2012
- Full report –
by
Matt Parker
Gerad Bottorff
Prepared to partially fulfill the requirements for
ECE402
Department of Electrical and Computer Engineering
Colorado State University
Fort Collins, Colorado 80523
Project advisor: Bill Eads
ii
Abstract:
The military use of unmanned aerial vehicles (UAVs) has grown because of their ability
to operate in dangerous locations while keeping their human operators at a safe distance. The
larger UAVs also provide a reliable long duration, cost effective, platform for reconnaissance as
well as weapons. They have grown to become an indispensable tool for the military. The
question we posed for our project was whether small UAVs also had utility in military and
commercial/industrial applications. We postulated that smaller UAVs can serve more tactical
operations such as searching a village or a building for enemy positions. Smaller UAVs, on the
order of a couple feet to a meter in size, should be able to handle military tactical operations as
well as the emerging commercial and industrial applications and our project is attempting to
validate this assumption.
To validate this assumption, my team considered many different UAV designs before we
settled on creating a Quadcopter. The payload of our Quadcopter design includes a camera and
telemetry that will allow us to watch live video from the Quadcopter on a laptop that is located
up to 2 miles away. We have just finished the project in terms of getting a grade for my senior
design but we will continue to work on the Quadcopter to improve performance and
controllability.
Our project has verified that it is possible to build a small-scale Quadcopter that could be
used for both military and commercial use. Our most significant problems to date have been an
ambitious development schedule coupled with very limited funds. These constraints have forced
compromise in components selected and methods used for prototype development. Our team’s
Quadcopter prototype is a very limited version of what could be created in a production facility
using more advanced technology. Currently our Quadcopter has achieved stable untethered flight
as well as autonomous altitude hold. We are continuing to work on our software so that we can
achieve better controllable untethered flight. Although there are many enhancements that we
could do to the design, we have proven that it is possible to produce a small scale UAV that
performs functions of interest to the military as well as commercial/industrial applications.
iii
Table of Contents Quadcopter ..................................................................................................................................................... i
Abstract: .................................................................................................................................................... ii
List of Figures: ......................................................................................................................................... iv
List of Tables: .......................................................................................................................................... iv
Chapter 1: Introduction ............................................................................................................................. 1
Chapter 2: UAV Background and Project Motivation .............................................................................. 2
Chapter 3: Quadcopter Technology .......................................................................................................... 3
3.1 Concept exploration: ....................................................................................................................... 3
3.2 Flight Platform: ............................................................................................................................... 4
3.3 Payload Components: ..................................................................................................................... 6
3.4 First Semester Graphical User Interface (GUI): ............................................................................. 9
3.4.1 Sensors Tab: ............................................................................................................................. 9
3.4.2 Mission Tab: .......................................................................................................................... 10
3.4.3 Navigation Tab: ..................................................................................................................... 10
3.4.4 Log Tab: ................................................................................................................................. 10
3.4.5 Manual Control Tab: .............................................................................................................. 10
3.5 Second Semester GUI ................................................................................................................... 11
3.5.1 Third Party Libraries ............................................................................................................... 11
3.5.2 Toolbar ................................................................................................................................... 11
3.5.3 Tabs ........................................................................................................................................ 12
3.5.4 Log Tab ................................................................................................................................... 12
3.5.5 Mission Tab ............................................................................................................................ 12
3.5.6 Manual Control Tab ............................................................................................................... 13
3.5.7 Future Work ........................................................................................................................... 13
Chapter 4: First Semester Work: ............................................................................................................. 14
4.1 First Semester Progress: ................................................................................................................ 14
4.2 Development Challenges: ............................................................................................................. 17
Chapter 5: Second Semester Work: ........................................................................................................ 19
5.1 Second Semester Progress: ........................................................................................................... 19
5.2 Second Semester major problems: ............................................................................................... 22
Chapter 6: Markets and Ethics ................................................................................................................ 24
6.1 Target Markets: ............................................................................................................................. 24
iv
6.2 Ethics: ........................................................................................................................................... 25
Chapter 7: Conclusions and Future Work ............................................................................................... 26
7.1 Future work ................................................................................................................................... 26
7.2 Future risks: .................................................................................................................................. 27
7.3 Conclusion: ................................................................................................................................... 27
Appendix: ................................................................................................................................................ 29
UAVforge: .......................................................................................................................................... 29
Appendix A: ............................................................................................................................................ 30
Appendix B: ............................................................................................................................................ 30
Appendix C: ............................................................................................................................................ 31
First Semester Letter to Dan Ferguson, Agilent: ................................................................................ 31
Second Semester Letter to Dan Ferguson, Agilent ............................................................................. 33
Acknowledgements: ................................................................................................................................ 36
References: .............................................................................................................................................. 37
List of Figures: Figure 1: Global Hawk ................................................................................................................................... 2 Figure 2: Micro Air Vehicle ............................................................................................................................ 2 Figure 3: IMU Shield and AdruPilot Mega Board .......................................................................................... 4 Figure 4: Quadcopter .................................................................................................................................... 5 Figure 5: Remote Control .............................................................................................................................. 6 Figure 6: Linksprite JPEG color camera ......................................................................................................... 7 Figure 7: XBee-PRO ....................................................................................................................................... 8 Figure 8: transmitter ..................................................................................................................................... 9 Figure 9: First Semester GUI ...................................................................................................................... 10 Figure 10: Graphical Interface as of 4/29/2012 .......................................................................................... 12 Figure 11: Early Flight Test .......................................................................................................................... 16 Figure 12: Indoor Tethered Flight ............................................................................................................... 16 Figure 13: Outdoor Tethered Flight ............................................................................................................ 17 Figure 14: First Test ..................................................................................................................................... 18 Figure 15: Tethered Outdoor Flight ............................................................................................................ 20 Figure 16: Outdoor Untethered Flight ........................................................................................................ 21 Figure 17: DARPA Competition ................................................................................................................ 29
List of Tables: Table 1: Budget ........................................................................................................................................... 30
1
Chapter 1: Introduction
UAVs for military use were reduced to practice in the mid-1990s when the Global Hawk
[1] and the Predator [2] were developed. These were very large fixed wing aircraft with
wingspans in the 50 – 100 foot range. Payloads for these large UAVs included radar, laser
designators, cameras, and missile systems. The introduction of these aircraft removed the pilots
from harm’s way plus added the ability to remain in the target area for many hours at a time.
These very successful UAVs represent a fundamental change in the way conflict is managed by
the U.S. However, these UAVs are large and very expensive and they beg the question of
whether smaller UAVs could also play a role in military applications. Likewise, on the other
extreme, there is considerable work in micro UAVs some of which are bio-inspired designs.
There are designs modeled after insects and birds, but just as the large military UAVs are too
expensive, we felt that these micro-UAVs were too small to be practical and required technology that was
not readily available to a senior design project group. It was therefore a vehicle in the one foot to one
meter class size that caught our team’s interest and is the basis for our project. Specifically, our
team is very interested in whether these smaller UAVs can be used not only for military
applications but also for commercial and industrial use.
Although most of the large military UAVs are fixed wing aircraft, we felt that a small
UAV should have greater maneuverability and versatility since it was likely to be useful for a
broader range of applications than the larger or smaller versions. We were also motivated by the
DARPA UAVforge [4] challenge which required a vertical takeoff UAV design. We selected
the Quadcopter design because of its maneuverability, stability, and large payload capacity. The
UAV that we are building is a prototype unit that could be used for commercial use but is not
rugged or robust enough for military use. Although we will meet the goal of producing a small
UAV that could perform useful missions in both military and commercial arenas, time and
funding constraints forced us to design a UAV to meet our functional requirements but not to
meet harsh environmental conditions such as those encountered during military missions.
However, our UAV design certainly could be re-implemented with newer and more robust
technology which would allow it to be used for military functions.
Our final goal of our Quadcopter configuration UAV was capability of being remotely
controlled to fly specific pre-determined missions. My plan was to select a few mission
scenarios, in conjunction with my faculty advisor, to show the range of control and monitoring
capabilities of such a platform. Such missions might include inspection of a difficult to reach
location, rapid deployment video from the location of a fictitious campus incident, or
surveillance video from a pre-planned route around campus. We were unable to reach this goal
due to time constraints, but we were able to demonstrate the Quadcopter holding altitude on its
own. As a stretch goal for my project, I wanted autonomous flight where the UAV must, for
example, avoid objects or sustain a flight path in the face of side winds. A scenario requiring
autonomous flight would be a search and rescue situation where a building has collapsed and the
search route is blocked by unknown objects that must be avoided during the search. I will
continue to work towards this goal on my own time.
This report is organized into chapters. Chapter 2 contains background on UAVs and
motivation for our project. Chapter 3 contains the technical description of the system and
subsystems with a discussion of design decisions. Chapter 4 provides a description of the work
on this project to date with a discussion of progress, and problems encountered. Chapter 5
2
presents the target markets that we envision for the UAV, issues related to production for these
markets, as well as the ethical issues involved with developing military platforms. Chapter 6
includes the conclusions and future work.
Chapter 2: UAV Background and Project Motivation
UAVs for military use were reduced to practice in the mid-1990s with the High-Altitude
Endurance Unmanned Aerial Vehicle Advanced Concept Technology Demonstrator (HAE UAV
ACTD) program managed by the Defense Advanced Research Projects Agency (DARPA) and
Defense Airborne Reconnaissance Office (DARO). [1]
This ACTD laid the groundwork for the development
of the Global Hawk shown in Figure (1). The Global
Hawk flies at altitudes up to 65,000 feet for up to 35
hours at speeds approaching 340 knots while costing
approximately 200 million dollars. The wingspan is
116 feet and it can fly 12,000 nautical miles which is
considerably greater than the distance from the U.S. to
Australia. Global Hawk is designed to meet domestic
needs including homeland security and has been
demonstrated in drug interdiction. Global Hawks are
also approved by the FAA to fly in U.S. airspace.
Another very successful UAV is the Predator
which was also created in the mid-1990s but has since been enhanced with Hellfire missiles.
“Named by Smithsonian’s Air & Space magazine as one of the top ten aircraft that changed the
world, Predator is the most combat-proven Unmanned Aircraft System (UAS) in the world”. [2]
The original version of the Predator, built by General Atomics, can fly at 25,000 feet for 40
hours at a maximum airspeed of 120 knots. In addition to missiles, the Predator can carry
cameras, high resolution all weather radar and laser designators. The Predator is a little smaller
than the Global Hawk but still has a wingspan of 55 feet.
At the very other extreme of size are the Micro Air Vehicles (MAVs) which are an
interesting research focus area. There are many designs, some of which are bio-inspired such as
the flapping wing version shown in Figure (2). [3] This design is being developed in Germany at
the Biomimetic-Innovation-Centre and is inspired by a bird called the swift. Micro air vehicles
are also modeled after various insects and generally use exotic
designs and materials and are physically small. Additionally,
although this design claims to be able to glide, the erratic motion
caused by flapping wings could make this a difficult platform to
operate a camera from. Although the designs in this class of UAV
are fascinating, our interest was in attempting to produce a small
UAV which could support a broad mission capability and these
MAVs were dismissed as being too small.
In addition to reviewing very large and very small UAVs,
we were also intrigued by the requirements of DARPA’s
UAVforge [4] competition which was posted around the time we
started our project. The UAVforge challenge uses crowd sourcing
techniques to design and build a micro-UAV that can take off
Figure 1: Global Hawk
Figure 2: Micro Air Vehicle
3
vertically, go to a designated distant location, monitor the location for up to three hours, identify
specific objects and then return home. We found this challenge interesting because, since it was a
DARPA research project, it represented pushing beyond the limits of what a small UAV had ever
achieved. The requirement for vertical liftoff also aligned with our thinking about the optimum
form factor for a small UAV. Many of the deployed UAVs are fixed wing aircraft; however, we
were looking for something more versatile that we believed could be built in small scale. The
Quadcopter, like other helicopter designs, is able to take off without a runway, take video from a
fixed hovering position, and finally maneuver through tight spaces as required. The Quadcopter
also provides a superior payload capacity when compared to the helicopter and is a more stable
platform. Since the Quadcopter was a vertical liftoff design, it aligned well with both our team
goals as well as the DARPA UAVforge goals and therefore it became our baseline form factor.
In addition to the military uses of the small UAV, we were interested in evaluating
applications in the commercial and industrial sector. Our premise was that if smaller and cheaper
UAVs become readily available, new markets and uses will emerge. Potential new markets in
commercial and industrial applications include inspecting pipelines or even inspecting dangerous
areas like a meltdown site at a nuclear power plant. Disaster relief or crop assessment seems also
to be likely areas where small UAVs could be useful. We were also motivated by on-campus
uses such as monitoring parking or quick-look video of an incident, or monitoring hard to reach
locations, or exploration of a collapsed building or other dangerous location.
The state of the art in small UAVs seems to be a few hand launched vehicles used by the
military which are far too expensive to be of interest to our project and the amateur community
represented by the DIYdrones [5] website. This community is dedicated to open source
development and distribution of information and technology related to UAVs. They have
developed control modules, software, and various sensors that can be mixed-and-matched to
build a low cost UAV. They also produce a low cost rudimentary Quadcopter system that is
available for purchase. The existence of this resource makes a Quadcopter senior project
feasible because some of the component parts can be reused instead of reinvented. It would not
be feasible for a small two person team to create all the technology required for a Quadcopter for
a very limited budget and compressed time schedule. From the perspective of our senior
project, DIYdrones provides components for a quick baseline implementation that will allow us
to focus on the problems of flight stability, payload management, and mission applications with
more resources than if we had to reinvent the base technology. The DIYdrones components are
also most importantly very low cost when compared to military alternatives and they are well
documented and understood. For all these reasons, we decided to take the DARPA UAVforge as
the starting point for performance metrics and the DIYdrones components as the baseline design
and then test our hypothesis from that starting point.
Chapter 3: Quadcopter Technology
3.1 Concept exploration:
After deciding to create the Quadcopter, we had to decide what electronics to use and
which sensors we would incorporate into it. After a lot of research on the web, we found a couple
forums that discussed open source electronic and software components suitable for making a
Quadcopter. Also, very basic but highly customizable Quadcopter bodies were available that
were suitable for us to use to create our baseline system. The DIYdrones forum provided good
4
information on what was being done in the amateur drone community and provided important
information on what would be possible for us to use for our project. Motivated by the UAVforge
challenge, we believed that the Quadcopter would be a good design starting point since it could
lift off vertically, travel some distance to a specific location, record video of an object, hover if
necessary, and return home upon completion. This scenario led us to the conclusion that we
would need sensors including gyroscope, accelerometer, compass, GPS, and a battery monitor.
We would also need payload components including a camera and a telemetry system to send
imagery back to the liftoff site. Furthermore, we would need a control mechanism that would
allow flight beyond the line of sight since that was also a requirement. We thought of two
approaches for control beyond the line of sight. One was to use the camera and video to allow us
to view the flight path from the Quadcopter point of view while guiding it with an RC controller.
Second, a more ambitious approach would be to use onboard GPS and guidance and a waypoint
system to send commands to the Quadcopter via the telemetry link which the Quadcopter would
execute autonomously. We were unable to achieve the second goal in the allotted time, but we
continue to make strides towards completing it. In the beginning of the design process, we
believed that it would be possible to perform most of the maneuvers and tasks required by the
UAVforge challenge but we had no idea if the components we would be able to assemble would
meet the performance requirements. We also had to realistically scope our project given a very
small budget, a small team, and a limited amount of time to complete. We therefore decided to
leverage as many commercial components as possible, get a baseline system working as quickly
as possible and then focus on problems we encountered in the areas of payload design, body
design, system integration, and mission evaluation.
3.2 Flight Platform:
At the start of the summer, Gerad and I began to build the Quadcopter. We started by
researching many different types of Quadcopter platforms and looking at current frames in use.
We decided that we would use a commercial frame and then build around it with the electronics
that we wanted. With the frame, we also got the motors and propellers. These components
determined how much room I had for the electronics as well as how much weight I could put on
the helicopter and still have lift. The next thing we chose was the microcontroller which was an
open source Arduino board which
allowed us to put our own
software on it. In addition to a
microcontroller, we chose a sensor
board called the IMU Shield which
is shown in figure (3). This board
included all of the major sensors
that we would need to achieve
flight. On the IMU Shield board
there is a gyroscope, barometer,
compass, and accelerometer which
all need to work together to make
sure the Quadcopter maintains
stable flight while moving or
hovering. Finally we purchased a Figure 3: IMU Shield and AdruPilot Mega Board
5
Lithium-ion polymer (Lipo) battery because they have the best ratio of weight to power. The
particular battery we chose has been sufficient to complete the design, assembly, and testing of
the Quadcopter systems and our experiments have shown that since we have plenty of thrust we
can chose a larger battery for our mission flights to improve the flight time. Figure (4) shows the
final product of our Quadcopter system.
We also had to provide a way to control the Quadcopter from the ground. We decided to
use an RC controller which is displayed in Figure (5) below. We bought the Futaba 6EX series
which has 6 channels and runs at 2.4 GHz. Currently we are using all 6 channels for up/down
movement, pivot, left/right, forward/backwards, channel 5 is used as a switch to control the
camera (either on or off). The last channel is used for automatic functions. Currently it is set to
do an altitude hold.
Figure 4: Quadcopter
6
As part of our final goal we also wanted to be able to control the Quadcopter from our
laptop computer using the onboard Xbee to simulate receiving radio signals. We were able to get
manual control with the GUI by mapping the (w,a,s,d and arrow keys) for manual flight. With
these keys we were able to control all of the actions that we would normally get when using the
radio including strafe, throttle, rotate, and yaw. The problem we had with the manual keyboard
control through the Xbee radio was that it was not as sensitive as the joysticks on the RC radio.
During flight, the Quadcopter requires continuous changes to both the throttle and the pitch and
roll in order to maintain copter position a reasonably constrained area. With the manual control
through the laptop, we wouldn’t be able to react to the Quadcopters movements fast enough to
maintain a level flight. Since the manual flight with the laptop was completed at the very end of
the semester, right before Engineering days, we were unable to work out all the bugs. Flights
with the keyboard control were more erratic and prone to crashing. For the demonstrations
during Engineering Days, we continued using the radio but we look forward to getting the laptop
manual control working better.
3.3 Payload Components:
The camera which provides surveillance capability for the Quadcopter is a Linksprite
JPEG color camera that employs a transistor-transistor-level (TTL) logic signal. The camera has
the ability to display a series of images through a serial communication output as well as 30
frames per second (fps) National Television System Committee (NTSC) formatted output. All of
the sensors and electronic hardware used in this project communicate over a TTL serial
Figure 5: Remote Control
7
connection, including the wireless telemetry module we are using. The ability to integrate the
video over the serial connection seamlessly was the main reason that we chose this camera.
Other reasons included the fact that it operated from a 5 V power supply, just like the rest of our
sensors, and that the power consumption was low at less than 100 mA. The camera has the
ability to capture VGA, QVGA, and QQVGA picture formats as well as allow the image to be
compressed with various degrees of compression. This allowed us to compress the image
enough to send a steady image over the transmitter. We were able to obtain 29 frames per second
at 720x480 pixels. This frame rate should be sufficient to guide navigation or to perform
surveillance. An image of the camera can be seen in Figure (6). [7] The camera sends its video
serially straight to the transmitter which is then picked up by the receiver attached to a laptop.
The video then goes through our GUI which allows us to either view or record this video for
viewing it later. The XBee-PRO telemetry module is the second payload function on the
Quadcopter today. A telemetry module was needed In order to control the Quadcopter from a
distance without the use of an RC transmitter. It was also needed to communicate payload
camera images back to the ground control computer. The module we chose for the project is a
900Mhz XBee-PRO XBP09. The XBee-PRO modules are capable of deploying point-to-point,
peer-to-peer and point-to-multipoint networks. Designed for maximum range, the XBee-PRO is
ideal for solutions where RF penetration and absolute transmission distance are paramount to the
application. [8] In our setup we use two of the modules. One is connected to the Arduino
processor board on the Quadcopter while the other one is connected to a computer on the ground
and together they allow communication between the GUI that we are developing on the
computer and the Arduino board. The XBee-PRO communicates with the computer serially,
through a virtual com port at a baud rate of 57600. An image of the XBee-PRO module can be
seen in Figure (7). [9]
Figure 6: Linksprite JPEG color camera
8
Finally, we added a transmitter to send the camera video to the ground as well as the
circuitry that would allow us to control the camera and the transmitter from the ground-based
GUI. We used a2.4 Ghz 500mW miniature transmitter that supported a live video stream from
the onboard camera. The transmitter is shown in figure (8). The first thing we did when
integrating this feature was hook up both the camera and the transmitter to our main circuit
board which was using one of the ESC’s as a voltage regulator but attaching all three loads was
drawing too much power from the ESC and it was too hot. Our next step was to move the camera
and the transmitter each to their own ESC to spread out the load and prevent overheating. We
were able to get this working but realized that by having the camera on all the time our battery
life time was very limited and we were not getting as much flight time performance as we would
have liked. Our final step was to design and build a circuit that would allow us to turn the camera
and the transmitter on and off through the GUI to save battery power. The circuit was comprised
of two N-channel MOSFET power transistors whose gates were connected to the relay switch on
our circuit board which we were able to control with the GUI that we had created. This switch
circuit allowed us to either complete the circuit which powered the camera and the transmitter or
open the circuit where no power was drawn. This approach was an inexpensive, simple and very
effective method for powering the camera and transmitter only when they were required to
operate. The only problem that we had with the video transmitter on our Quadcopter was that it
operates at the same frequency as the RC radio receiver. This overlap means that when both are
on and running the image quality from the video receiver is not great. We attempted to mitigate
this problem by moving the antennas around to minimize cross coupling. This approach did help
alleviate the problem. Also, we were not too worried about this problem because our final goal of
running the Quadcopter from our laptop meant that we could turn the RC radio off and would be
able to receive perfect images.
Figure 7: XBee-PRO
9
3.4 First Semester Graphical User Interface (GUI): The GUI is still under development. We were unable to complete what we wanted the
GUI to achieve in the time constraints that we had. The first idea was to have it comprised of
different tabs all having a specific purpose for the project. It was decided by the team to create a
custom GUI so that we could tailor it to our specific environment and needs.
The GUI, shown in figure (9), is comprised of two areas which are the toolbar at the top
which will not change and the tab bar which will allow the operator to switch which information
he will be viewing. The tool bar at the top of the program will have various status indicators such
as a battery level, distance from the base station, signal strength of the XBee system and GPS
Lock. As all of these indicators are highly important, so this toolbar will be available at all times
during execution time of the GUI. The tabs each have a specific purpose for the project. The
tabs were designed to be independent from one another and with different purposes in mind.
3.4.1 Sensors Tab:
This tab was the first to be designed and plays a key role in the setup process of the
Quadcopter in that it will be used to upload firmware to the Arduino and calibrate the sensors to
set “zero”. Also in this tab we will be able to see the current status of the sensors in near real
time and determine if any one part is not working properly.
Figure 8: transmitter
10
Figure 9: First Semester GUI
3.4.2 Mission Tab:
The mission tab is one of the most important parts of this program. It is here a user will
be able to see the current position of the Quadcopter on a map and also plan out a mission. The
user will accomplish this by using waypoints which will be translated into GPS coordinates
which will be sent to the Arduino. Upon the start of the mission, the Quadcopter will go to the
desired waypoint and complete a task that has been scheduled for that particular point. When
complete, if there are more waypoints, the UAV will move on to those or finally come back to
the base station.
3.4.3 Navigation Tab:
The navigation tab will play a key role in watching the Quadcopter as it completes
missions. In the navigation tab we will be able to see the current position of the copter on top of
a map, a live camera feed and the current pitch, yaw, and roll of the Quadcopter.
3.4.4 Log Tab:
The log tab will have the important job of displaying the after-flight logs. It will be able
to show the data that was obtained by the onboard logs collected during the flight as well as the
flight course on a map.
3.4.5 Manual Control Tab:
In the manual control tab, the operator will be able to take control of the Quadcopter
remotely and use the keyboard to control the elevation and position of the copter. This will be
the most functional tab for watching the copter in flight as it will have the ability to show video
as well as give various commands to the copter including takeoff and land.
11
3.5 Second Semester GUI
The GUI that we developed for use with the Quadcopter was made using the C#
programming language. This language was chosen not only because it is easy to design and
implement a GUI but also because it has a lot of 3rd
party libraries that were able to be leveraged
in the construction of our program. Using C# and visual studio we were able to implement a drag
and drop GUI that we would have to program all the functions that were dropped into the frame.
This made it very easy to organize our GUI and would prewrite all the code for the actual look
and feel of the GUI.
3.5.1 Third Party Libraries
Our GUI uses many different open source projects that allowed us to worry about
integration of components and not the implementation at the lower level. The biggest open
source project incorporated into our GUI is the MAVLink, Micro Air Vehicle Communication
Protocol, which is a protocol designed to marshal (pack) data on the Quadcopter transmit it over
the XBee connection and at our ground station unmarshal (unpack) and interpret the data. The
MAVLink protocol is how we are able to get data from the many sensors on the Quadcopter and
how we are able to take control of the Quadcopter through our GUI. Another big open source
project that we used in our program was the GMap .NET project. This particular project allowed
us to project an image on top of Google Maps to pinoint the location and heading of the
Quadcopter based on its GPS location.
In conjunction with the bigger projects we used other smaller open source projects to
interface with other parts of our program. One of the more important projects is a C# wrapper
for the AviFile class created by John Corinna. This wrapper made it a simple task to save the
live camera video to a movie file that could be played at a later time. Another small project used
was Application and Global Mouse and Keyboard Hooks .NET Library. This project allowed us
to capture keystrokes inside our program and make decisions based on which key(s) were
pressed. The last small open source project that we included in our GUI was DirectShow .NET
which allowed us to open up a connection to the camera situated on the Quadcopter and show the
video in the designated video area.
3.5.2 Toolbar
At the top of the program we have a toolbar that has various status indicators including:
battery level, estimated battery life left, signal strength of the XBee system, status of the ESC’s,
status of the GPS system, status of camera, our current mode, altitude, and distance from the
base station,. As all of these indicators are highly important, this toolbar is available at all times
during execution of the GUI and the status of each element is updated 10 times each second.
Most of the information in the tool bar was just reading the onboard information from the
Quadcopter, but some of the status indicators like the battery we had to program in manual to
know when the battery was actually full and empty from the information given from the
Quadcopter. On the Toolbar we also had the ability to connect or disconnect to the board via
XBee or even directly connected.
12
3.5.3 Tabs
In our original design we had planned for the GUI to have 5 different tabs for operation.
It was soon decided that this amount was superfluous and we were able to condense it down to 3
different tabs: Log, Mission, and Manual Control. We decided to do this because it would
prevent a lot of switching between tabs. Our current GUI only accepts manual control if we are
actually on that tab so we wouldn’t be able to fly if we were on any other tab. With all the
information on the single tab it makes it easier to monitor all the information that we need for
flight.
3.5.4 Log Tab
The log tab is one of the more important features of the GUI that we designed. It has a
textbox that will display current values from the Quadcopter at a maximum of 10 lines a second.
This allowed us to find the voltages of our battery at both maximum and minimum values so that
we could tailor our battery level indicator to reflect these. It also helped in determining which
motors were spinning slower than others (indicating that the Quadcopter was not level). We also
used this log to help us determine that our sonar sensor randomly have spikes in altitude from
interference. This is the cause that none of our automatic functions work because most of them
require a height input. From this tab, or by closing the program, you can also write these lines to
a text file for more careful examination later on.
3.5.5 Mission Tab
After some refactoring the Mission tab was redesigned and is now being used to show the
direction, or heading, of the Quadcopter and also to show the status of all of the components on
the Quadcopter. This is useful when a component you need to get data from is not included in
the Log tab mentioned above.
Figure 10: Graphical Interface as of 4/29/2012
13
3.5.6 Manual Control Tab
The manual control tab is the most important and feature rich tab in the GUI. After the
original design of the GUI was found to be inefficient in that the critical information that was
needed for flight was too spread out thought our program we decided to redesign the Manual
Control tab to include most of the program’s functionality.
In this tab the operator of the software has control of the Quadcopter through use of the
W, A, S, D, Up arrow, Down arrow, Left arrow, and Right arrow keys. This is done by
capturing all of the keystrokes of the program, passing them through a custom filter to only
capture the important keys, and then taking the proper actions based on the input (see table
below). The operator will be able to see how the Quadcopter is interpreting the key strokes
because in the lower right hand corner there are percentage bars indicating the amount of thrust,
strafe left/right, the rotation of the copter, and the forward/backward motion of the copter.
Along with control the operator will be able to see where in the world the Quadcopter is
in the bottom left corner, provided the connection to the XBee is still active and the GPS
mechanism has a lock on its location. This location tracking is done by overlaying an image of a
Quadcopter over Google Maps. The copter image will rotate to the current direction the copter is
pointing in at that moment.
Another feature of this tab is pre-programmed flight maneuvers located in the top left of
the GUI. These maneuvers include altitude hold, land, takeoff, and rotate. These functions each
have an algorithm, based on data obtained through the XBee connection and MAVLink protocol,
to determine if the Quadcopter needs to throttle up, throttle down, or perform some other defined
maneuver.
The last feature of this tab is the ability to see live video streamed from the Quadcopter’s
attached camera. Through the GUI the operator can turn off and on the video camera and
wireless video transmitter, thus saving power when not in use, and view the video in an image
container. If the operator so chooses, the video can be saved to an AVI file by right clicking on
the video stream and selecting “Save Video to AVI”. The video will automatically be stored in
the directory with the logs with the file format {yyyy-mm-dd_hh-mm-ss-AM/PM}.avi. This
naming scheme allows the operator to have multiple video files without overwriting one of them
on accident. To stop recording and save the video file the operator simply has to right click on
the image once more and select “Stop Recording”.
3.5.7 Future Work
Our GUI can always be improved upon to keep up with the latest advancements in the
open source projects we have utilized. For example there is a newer version of DirectShow
.NET that could be used in our project.
Along with keeping up to date with the projects used there are some minor bug fixes that
need to be worked out. For example, after a little bit of runtime the Google Maps area will come
14
up with an area. This is because an array used to indicate the location of where the icon should
be drawn on the map is being used to determine where to draw but at the same time it is being
emptied (to keep the size down). The authors of GMap .NET say that this data source should be
threadsafe meaning that only one thread should be able to operate on it at any given time, but for
some reason two threads are able to operate on it at once. (It should be noted that this is only a
problem on the laptop we used. This problem was not seen on the development machine.) This
could be fixed through using software locks so that a call must obtain a lock before it can modify
the data. Another known bug that could be fixed is the camera area can only be started once
during the program’s runtime. If the operator turns the camera on and then off when he/she tries
to turn it on again SecurityAccessViolationException is thrown by the program causing it to stop
responding and crash.
As with any piece of software the code for the GUI could be restructured into more
classes to help improve object oriented design and make it more like production software. There
is also the possibility to make the GUI more user friendly and add a touch more functionality
such as adding a HUD that tells the operator the yaw, pitch, and roll of the Quadcopter. This
would require the use of OpenTK, an open source project that deals with graphics programming,
and some cleaver programming.
Chapter 4: First Semester Work:
4.1 First Semester Progress:
Our needs analysis determined that we had to design a UAV that had a battery that lasted
for an extended period of time, could fly up to two miles, and was able to take surveillance for
extended periods of time. After we began the design phase and factored in the constraints of time
and budget however, we realized that we would not be able to afford the right technology to
achieve the goals of this competition. Although the individual tasks of the competition like
vertical take-off and flying two miles seemed feasible with the technology that was within out
project constraints, the combined mission was not practical. The endurance was the limiting
factor because available battery power compared to the rate of consumption of our motors and
electronics limited the expected duration to something on the order of 15 minutes. So, at this
point in the project we decided to drop out of the competition but decided to keep the same types
of goals at a reduced scale. Our revised goals became a small UAV that would operate for up to a
half hour, fly up to two miles, and include a camera payload so we could capture video of
targets.
With our new and more realistic project goals we began the project last summer before
the fall semester to get a head start on the baseline platform. Gerad a teammate, and I did all the
background research for what type of UAV we would develop then we found the parts we
needed to build the baseline. We ordered parts from many different companies, physically built
the Quadcopter frame and put together main electronics that contained the sensors that the
Quadcopter would need to fly. We had to solder all the electronics together as well as produce a
power distribution board that would power the entire Quadcopter. We explored forums on the
Internet where other groups were using similar components of other projects. With the help of
15
this information we were able to get our basic systems including the distribution of power
working correctly. Since our team ordered parts from many different companies, one of our main
challenges was integrating all the parts to work together. Our first challenge was figuring out
where to fit everything on the frame we had bought. The frame came with generic mounting
shelves in the central body which allowed us enough room to mount all of our electronics.
However, since the shelves were not designed to mount our specific components, mounting and
cable management were a significant problem. We have approached this problem by zip tying
all the electronics down as well as their wires to make it a little cleaner.
At the end of the summer we did not have all electronics working on the Quadcopter
perfectly, but we were able to get some basic software loaded onto our main control board. With
this basic software on the board, we were able to communicate with the Quadcopter through a
command prompt interface. This allowed us to calibrate sensors, motors, and Electronic Speed
Controls (ESCs). The summer ended with a test flight of the Quadcopter with not all of the
electronics working correctly. The Quadcopter never left the ground and immediately flipped
over and snapped the protective case around the GPS. This event is shown in Figure (14).
At the start of this fall semester, we therefore began with a long list of problems with the
Quadcopter from the summer. Our problems included broken blades, gyroscope not working,
battery monitor not working, telemetry not working, and compass not working. Broken blades
meant I would have to order new ones from a company in Thailand which would take three
weeks to receive. The sensors including gyroscope, battery monitor, and compass were all not
working at the beginning of the semester so we had to figure out why those weren’t working.
Finally the telemetry was not installed because it was not ordered during the summer with the
other electronics. We had just ordered the telemetry at the end of the summer so when we got it,
it needed to be built and integrated into the Quadcopter.
After the many problems that we had, we wanted to begin testing under more controlled
environments. The first test we did was far from controlled as you could see in Figure (14). We
had to come up with a better way to test the individual components including sensors and then
move on to test flight. For the sensor testing we removed both the control board and the sensor
we wanted to work with and hooked them into a computer to make sure the output data was
correct. When we were sure that the data was correct, we placed each sensor back on the
Quadcopter and hooked that up to the computer. Finally, with the individual components
functioning we moved on to flight tests. Our first test required Gerad to hold the Quadcopter
over his head while I ran the throttle up for liftoff. By moving the copter around we were able to
monitor sensor data and make sure that it had sufficient thrust and level flight so that when
released it would actually fly. This method of testing can be seen below in figure (11)
16
Although our flight is now more stable than before, we are still in the phase of tethered
flight as we continue to work flight stability issues. However, we have replaced Gerad by tying
the Quadcopter to a table inside so that it is not being affected by outside weather. The
Quadcopter flying while tethered can be seen in Figure (12).
Figure 11: Early Flight Test
Figure 12: Indoor Tethered Flight
17
We allow the Quadcopter to lift a couple of inches off the ground but without enough slack to
tip enough to break the blades. We continue to do testing this way to make sure that all the
sensors will work during flight. We currently are seeing that one of the wings is dipped which
will cause the copter to drift in that direction instead of hovering. We have also attempted an
outdoor tethered flight where we provided a 5 foot slack line. This outdoor tethered flight can be
seen in Figure (13). This test was successful but again it drifted to one side so we will have to
fix that before we can do untethered flights.
In addition to flight testing, payload integration also began this fall semester with the delivery of
the telemetry component and the camera. Each of these electronics components had to be
connected into the main board so that the program contained there could use them. Our Arduino
board had a few extra serial connections which allowed us to connect the sensors. We just got the
telemetry and sonar to work correctly through two of the serial connections on the board.
Currently we are working on getting the camera to work through another one of the serial
connections. The biggest problems we encountered are discussed in the next section.
4.2 Development Challenges:
Although we have encountered many difficulties during this project, we have fixed most
of them. The big difficulties we have had include the gyroscope not responding, telemetry not
working, random power failures, and finally radio control not working correctly.
The gyroscope was probably our biggest problem; the helicopter would not receive data
from the gyroscope fast enough for it to compensate for the slight differences in motor speeds
that resulted in non-level flight. During takeoff there is always one motor that spins faster than
the others which causes the Quadcopter to tilt. When the Quadcopter tilts, the gyroscope is
Figure 13: Outdoor Tethered Flight
18
supposed to sense the tilt and signal the computer to slow down that motor while speeding up the
opposite side motor to make the Quadcopter level. This tilt problem is apparent in Figure (14)
shown below. We discovered that the Gyroscope was getting powered incorrectly and would not
work if power cables were connected in a certain sequence. We remedy this by plugging in the
battery monitor first and then plugging in the battery itself.
Earlier in the development process, when we had just finished putting together all the
basic electronics, we were having random power failures throughout the entire Quadcopter. This
was worrying us because it could have meant that one of the components on the main boards had
failed which would be very expensive to fix. We finally discovered it was a loose connection on
a power distribution board that just needed to be re-soldered. We were delighted to discover this
simple fix and fortunate that there were no damaged components.
With the power distribution problem solved, we began to try to communicate with the
Quadcopter from an RC controller radio. Initially, we had trouble getting our radio to
communicate with the Quadcopter correctly. First, our throttle was set in the reverse direction so
pushing up on the throttle would mean that the motors would power down. This problem was
easy to fix because the radio provided a polarity switch for this purpose. We also had problems
with the motors not spinning up until the throttle was advanced 2/3 of the way. This offset meant
that only a tiny movement in the throttle would have a big effect on the motor speed. This also
meant that when the motors started, they started very fast and the helicopter would jump into the
air without any control. We were able to remedy this problem also through control settings on
the radio where we were able to scale the throttle. We had to set the minimum throttle to about
45% and the max throttle to 100%. This gave us a lot larger range of throttle which allowed for a
more controlled take off and better control of the Quadcopter.
Figure 14: First Test
19
Near the end of the first semester, our biggest problem was the telemetry not working at
all. We attempted to test the individual components to make sure the right software was loaded
on the modules, but we could not communicate with the boards. We figured out that I had
soldered the Xbee module incorrectly which caused it not to work. We had to strip the module
connector, order new pins, and re-solder the chip. After the re-soldering, we were able to
communicate with each board. We then hooked up one Xbee to a computer and the other to the
Quadcopter and were able to receive data wirelessly.
We had many problems with the Quadcopter in the first semester but that is to be
expected during a project like this.
Chapter 5: Second Semester Work:
5.1 Second Semester Progress:
At the beginning of the second semester, we were faced with several remaining issues.
We had to complete the coding and integration of the GUI so that we could achieve full control
of the copter from the computer rather than an RC control. We also worked on optimizing power
consumption as well as looking at alternatives to the current battery system. One of the biggest
issues was achieving completely stabilized flight to allow the Quadcopter to hover untethered in
a single location. With the stabilized flight, we also worked on getting untethered flight around a
local area like the park nearby. The next step after untethered flight in a local area was to give it
remote way points where it will have to go on its own to a location and come back. Once we had
achieved the ability of the Quadcopter to reach a target location and then return home, we would
have been almost completely done with this project. We also planned to complete research on
alternative bodies that could be used to protect our Quadcopter as the possibility of upgraded
hardware if we received donations from outside sources. Of all these remaining issues, the main
problem was that the Quadcopter would not liftoff in level flight. We had several theories about
why this problem existed and a ton of experimental evidence that was inconclusive. For example,
we determined that non-level liftoff seemed to occur when the throttle was not advanced to the
maximum. The liftoff seemed to be more level when the throttle was set to maximum but with
maximum throttle the Quadcopter leaped into the air so quickly that it was difficult to control.
We considered the possibility that the feedback loop between the gyro and the motors, that is,
the communication between the motors, the ESCs, and the board might be faulty. It was also
possible that the software algorithm might also be a factor in this instability problem, so we
looked into software solutions as well. Finally, we were experiencing this instability while
tethered to a table and it was possible that the prop wash might be increasing the instability
problems. We figured it was the back draft from the motors because when we were tethered
outdoors we were not experiencing the same problems. We also realized that while tethered the
Quadcopter’s motors and ESCs were working harder than they should have been and getting hot.
We did not experience this problem when we did our outdoor flights.
One of the major tasks this semester was to get the camera operational. We had Chris
Robbiano working on the camera system last semester but he was using the camera grabbing
digital frames at a very slow rate and trying to transfer them over the XBee system. We
determined that transferring the data through the XBee was not good enough and that we would
20
have to get a completely new system to transfer video. I decided to buy a separate transmitter and
receiver for the camera. I also decided to use the analog pin on the camera to get up to 30 frames
per second of live video. As explained before once we had all the parts of the camera system all
we had to do is power it and make sure it was mounted firmly to the frame. After building the on
and off circuit and powering all the electronics from different ESCs we were able to finally get
the entire system working for the demonstration on engineering days.
This semester we also were able to switch out the main frame of the Quadcopter to a
more durable and sturdy one. With the new frame we had more protection for the electronics that
were mounted in the center. The motors were attached directly to the frame which was more
secure and would prevent the motors from breaking off after a hard landing. The frame also had
a new landing gear that was made of carbon fiber and contained struts to increase their
durability. This frame also had more room to mount the ESC’s and the other electronics that we
were using. The frame was a good choice for us to go with because of how well it worked for us.
The success we had for flight didn’t start happening till the very end of the semester. Like
before we were able to get tethered indoor flight that wasn’t level but would still fly. We would
try this at different lengths of string but we could not figure out why it was always tilted. By the
end of the semester we determined that it was the back draft from the Quadcopters blades that
was causing it to tilt. At the end of the semester we took it out side for a tethered flight with a 5
foot string. We had done this before but we didn’t have all the electronics working on it and we
didn’t have the new frame that we got. The tethered flight was very stable and was easy to
control with the radio control. Shown in Figure (15) is a tethered out door flight that we had.
After we did a couple of tethered flights that worked out well we did a single untethered flight. I
was able to get the Quadcopter to stay in a 3 foot by 3 foot area and land it safely to the ground.
During this untethered flight I got the Quadcopter up to 2 meters into the air. The only difficulty
I had during this flight was there was a lot of cross wind that would pick up the Quadcopter and
move it around more.
Figure 15: Tethered Outdoor Flight
21
After the first untethered flight we started taking the Quadcopter out for longer flights
that would achieve higher altitudes and go further away from the base station. We were able to
get a continuous flight of about 15 minutes during this flight it would get up to 20 meters in
altitude and go about 100 yards away from the base station. An untethered flight is shown in
Figure (16). These longer flights posed more difficulties because while the Quadcopter was in
the air it tended to spin due to the wind. When the Quadcopter would spin I would lose
orientation of which way was forward and I would not be able to control the Quadcopter as well.
This problem was due to lack of training with the Quadcopter’s controls. With more time I am
sure I would be able to control the Quadcopter and spin it around. Finally taking the Quadcopter
to higher altitudes it made it more susceptible to the wind. At one point we were about 20 meters
in the air and an updraft shot the Quadcopter up to 70 meters into the air. I was able to recover
the Quadcopter but it was a difficult endeavor. In the end of the project we were able to achieve
controlled untethered flight.
Figure 16: Outdoor Untethered Flight
The last thing we were able to achieve with flight was an automatic altitude hold. I
programmed channel five on our Quadcopter to switch between manual mode and automatic
mode. Automatic mode reads what commands it needs to do from the internal EPROM. I had
programmed the Quadcopter to maintain altitude for 90 seconds and then attempt to land. During
an untethered test flight I believed the Quadcopter was in a good position, so I flipped the switch
to automatic. I did not realize it at first but the Quadcopter had taken control of its own throttle
but I still had control over the movement controls. After a little time of me trying to make it
change altitude I determined it was automatically holding its own altitude. Out of confusion I
lowered throttle to 0 and eventually hit the switch to go back into manual mode. It
instantaneously cut all motor speeds and crashed. This is the first step in getting automatic flight
working and I counted this flight as a positive experience because of the automatic altitude hold
22
but a negative experience for my lack of readiness to keep it in the air after going back into
manual mode.
To conclude we were able to achieve most of our flight ambitions for this project by
stepping up with scale incrementally. We started out with indoor tethered flight, moved to
outdoor tethered flight, then tried outdoor untethered flight, and finally we were able to achieve
an automatic altitude hold which was part of what we wanted to demonstrate at our demo.
The other main project this semester was to get our GUI to work and interacting with the
Quadcopter. This was mainly Gerad’s domain but near the middle of the semester I also began
working on the GUI in order to try to achieve as much as we could in the limited time we had.
We started out with getting the Quacopter and the GUI communicating over the XBee. We were
able to receive all the information we would want from the Quadcopter and display it in a
continuously updating window. The next step we did was get keyboard capturing and manual
control working. Once we had all of that working we wanted to make the program do more for
us. We were able to integrate Google maps that would always set our Quadcopter as the center
point of the image. This was good for us because when we would fly we would be able to watch
the Google maps to know exactly where it was. We also added automatic functions to the GUI.
We were unable to get any of these to work correctly due to some of the sensors giving false
information but once we fix the sensors we believe the would do what they need to. The buttons
we had on our GUI were takeoff, land, spin, hover, and come home. We also had buttons to give
us more information like set home location, arm/disarm, and set home altitude. The last thing we
added was the live video feed. We were able to get video to stream from the Quadcopter to our
receiver attached to a video capturing device for our computer. We also programmed a button
that would allow us to turn on and off the video as well as record the video. For our demo we
were able to get the video, manual control and the Google maps to all work so we could
demonstrate them. We did have some kinks in the software that we are continuing to work out
and make it a more stable program.
5.2 Second Semester major problems:
During this semester we had to fix many problems that we had with the Quadcopter. The
main things we needed to fix were the frame of the Quadcopter, the sonar, camera system, GUI,
and flight issues. Each one of these things is major topics that include many different parts that
did go wrong during development. We also had many more problems than we will discuss here,
we will just mention the major ones that gave us the most trouble.
Throughout this semester we had many crashes with the Quadcopter. Most of the major
crashes happened at the end of the semester when I was attempting more things with the
Quadcopter. With untethered flights there were many different cases where it would be up in the
air and start to spin. The spin was due to wind and then with the momentum it would just
continue to spin. This made it very difficult to control and most times the Quadcopter would land
with a crash. Most of the time they were not too bad of crashes but we did have a couple that
would break legs. Most of our crashes came from the manual control through the computer.
Because the computer wasn’t as sensitive as the radio, I wasn’t able to control the location of the
Quadcopter as much. One of our major crashes was due to a large guest of wind that pushed the
Quadcopter towards an active street. Because I didn’t have enough control to bring it back or
land it Gerad hit the kill switch. The Quadcopter crashed breaking a leg, the transmitter, and one
of the blades. The main problem was the transmitter because we had to open up the components
23
to try to solder it back together. Each crash would cause a set back because it would take me
time to fix everything that had gone wrong. If a flight dependent component like the motors,
ESCs, or propellers I would have to recalibrate everything to make sure everything was spinning
at the same rate and it would fly level.
Our second major problem was our sonar. At the start of the semester it would not read
correct information even though when I manually watched voltage over the output it was correct.
I was able to get it mounted to the frame away from the blades and the other electronics for fear
of interference but it would still act like the sonar was not receiving data. The puzzling part was
that I would touch random parts on the Quadcopter and it would be steady at the correct value.
On the last week of the project we determined that it was interference and the cable from the
sonar to the main board needed to be shielding in order to receive the right data. We had a lot of
difficulty with this but were able to twist the wires as well as wrap it in electrical tape. We
continue to get random spikes in the sonar (which prevents us from achieving autonomous flight)
but we are able to get good enough readings to know where in space the Quadcopter is.
One of the main additions this semester was the camera system. At the start of the
semester I was attempting to use what our teammate Chris Robbiano did for the camera system
but I was unable to reproduce a working system. I determined to scrap what he did and use the
analog side of the camera instead and feed that directly into a dedicated transmitter. I was able to
get video working right away, but the main problem was that the video system was drawing too
much power from the rest of the Quadcopter that its flight time was almost decreased by half. I
worked around this by designing an onboard on and off circuit so we would be able to get around
the power issues. In the grand scheme of things this was not a major problem but it was a nice
feature.
One of the major obstacles that we had to get over this semester was getting our GUI to
actually send commands to the Quadcopter. This posed a problem because it was not designed to
be controlled by a computer. The first thing we did with the GUI was made sure it was able to
receive all the information that was needed for flight so that we were able to log the information
if something were to go wrong. The next step was determining how we were control the flight.
We were able to easily set up the GUI to take all the commands and register a change which
would be used to move the Quadcopter. Our idea was to emulate the RC controller by overriding
the received RC commands with the information from our computer. Once we looked at the
problem in this way we were able to achieve it. The only down side is when connected to our
GUI, our GUI will always override the Radio Control so it was not possible to have our GUI
running and be able to control the Quadcopter from the radio. This posed a problem during E
days because we wanted to show the information from our GUI but we also wanted to show
controlled flight which was only achievable from the radio. The next problem we have with the
GUI is the sensitivity and control. We were able to tune it a ways to make it better than what it
was but it still is difficult to control. Our next step would to see if it were even practical to use a
keyboard, we may find it would be better to just integrate a joystick into the computer program
so we have better control.
Our final and most troubling problem was trying to get stable untethered flight. This
problem was with us this entire year since our first flight the weekend before school begun we
were unable to get a stable flight that would actually fly the way it was supposed to. We started
with our GYRO not working which caused the Quadcopter to just tip over at launch. We then
moved to a more controlled environment where it was tethered inside until we were confident in
its ability to fly. We were never to get a very good controlled in door tethered flight unless we
24
pushed the motors to the max at which point it would just use the tether as a hold to appear to be
flying correctly. We were always obtaining a tilt while it was flying and we could not figure it
out. I searched on some forums to see if I could find someone that would have a similar problem.
I was able to finally find someone after a substantial amount of time. They had the idea that the
blades were not the same shape which caused some of the blades to have more thrust than the
others. When I read this I went to check out our blades, I took each of them off and tested them
against each other. I found that one blade did not have as much twist as the other blades which
would cause this problem. We switched this blade out when we broke it on the very first test
flight and we were using these blades for about 5 months. I took down all the blades and traded
them out for ones that I found online. All these blades didn’t have as much twist as the first. I did
not know it at the time but these blades would not work because they ultimately wouldn’t
produce enough thrust to lift the Quadcopter off the ground. Our team spent 1 month with bad
blades thinking there was another fault with the Quadcopter. I had to purchase new blades
because I finally decided to test to see if our blades were the problem and we were able to get
flight. After we figured out the blade problems we were able to achieve better out door tether
flights but the indoor flights were still uncontrolled. We determined that it was the back draft of
the motors that caused the Quadcopter not to stay level. In the end we were able to get stable
flight but this problem was the biggest we had all year, but we are glad that we could overcome
it.
Though mainly this semester was trying to fix problems, we were able to accomplish a lot
with the limited man power and time that we were given. Each problem that came went through
the same process. We would run a test to replicate the problem to make sure that it wasn’t a
fluke. After we knew that it was a consistent problem then we would start gathering as much
information as possible. I would get voltage read outs of all connections to the part if it was
accessible. Some of the components like the on board sensors were not in a position where I
could read the voltage across them. While I would read voltages and check connections Gerad
would look at the software side of things to make sure that it wasn’t on his side. He would have
read outs of every sensor which would give him an idea if there information is actually being
passed correctly. We would try many different things to try to make things work and on each
main problem we came across we were able to get a solution for.
Chapter 6: Markets and Ethics
6.1 Target Markets:
The Quadcopter is proving to be a versatile tool that appears likely to support a number
of markets and missions. Military missions, of course, are beyond the scope of our current
project so we evaluated potential missions in the commercial and industrial sector that would be
appropriate for the Quadcopter that we are building. For example, we were thinking that the local
police here on campus that have to spend many hours looking at parking permits on cars could
send the helicopter out to fly down the car line and allow an operator to watch the onboard
camera to see the permits. This would cut down on man hours as well as not wasting gas by
driving around to inspect cars. Additionally, the Quadcopter could be used during a campus
incident to assess a dangerous situation without putting officers or first responders in harm’s
way.
25
Other ideas include inspecting a pipeline. Our Quadcopter would easily fly down a
pipeline and allow an operator to watch the onboard camera and check for problems in the
pipeline. Pipelines often pass through rugged terrain with very poor roads and using a
Quadcopter would mean they wouldn’t have to drive the entire route. They should be able to fly
down the pipeline a lot faster and also they would be able to maneuver the Quadcopter when
they needed to inspect a certain area in closer detail or even from other angles. It might also be
possible to fly an infrared imager on the Quadcopter to look for areas of different temperature
which might indicate a spill or a weakness in the pipeline.
During the recent week of presentations, we were also approached by someone who
worked with Xcel Energy. He had seen us demonstrate the Quadcopter and he had mentioned
that the Quadcopter would be very helpful for the company. We learned that they have to inspect
the power transmission lines on a regular basis which takes a lot of man hours. They would use
our technology by flying the Quadcopter down the power line while video recording the flight so
an operator can go over the footage to make sure there are no problems. This was a neat idea
because there are many power lines all over the United States and it must cost a lot of money just
to inspect them. Also, this is a great application because the lines are difficult to access and they
are dangerous for humans to approach.
So, even though we did not get to compete in the UAVforge competition with DARPA,
we still know that there are many interesting uses for this technology.
6.2 Ethics:
Ethics is becoming a more important aspect of engineering as research moves closer to
impacting humans in fundamentally new ways, such as genetic engineering of crops or human
organs. The National Academy of Engineering maintains a website [10] for the discussion of
ethics issues related to engineering. Topics like energy, climate, and synthetic biology all receive
significant attention since they are topics where ethics guidelines are being formulated. There
are also codes of ethics for performing research which apply to all engineering projects and
disciplines.
Our specific project on UAV design is not at the center of any of the current ethics
controversies but two potential issues come to mind. Both cases involve the use of UAVs and not
the design itself.
The first issue is a privacy issue. As the number of sensors and sensor platforms
increases, citizens are concerned about their privacy rights. UAVs, including the ones we are
constructing, could certainly be used to invade the privacy of individuals by tapping into phone
conversations or video recording. We are specifically building a platform that can be used for
many applications and as such we believe that any ethical concerns lie with those who might
apply a UAV in such a way that it violates privacy. There is nothing specific in the design that
either enables or inhibits that use.
The second issue relates to the use of a UAV as a weapons platform. There are certainly
legitimate ethical discussions about this topic. The UAV we are building could not be used for
such a purpose although it might be conceivable that a small UAV could be designed to carry a
small weapon. Again, this ethical issue rests with others who might try to create such a weapons
platform.
26
Chapter 7: Conclusions and Future Work
7.1 Future work
Our project demonstrated extensive tethered and untethered flight using either our custom
GUI or an RC control system. Additionally, we demonstrated limited autonomous flight as well
as remote camera control. Future work could include more focus on longer flight times, robust
operation, autonomy, or mission scenarios.
Longer flight time is a matter of tradeoff between two variables, the efficiency of the
thrust developed by the motors and the battery capacity (weight). The efficiency of the thrust has
two factors, the propeller design and the efficiency of the motor itself. We used higher twist
propellers for this project which provided more lift at lower motor RPM and afforded some
increased efficiency of battery life. The motors are brushless motors which are designed for this
purpose and are relatively efficient. Battery capacity relates directly to weight and there are
many different capacity batteries available. The LiPo battery is also designed for this application
and is very efficient. However, it would be possible to run an experiment to determine maximum
flight time for a fixed maximum thrust by changing motors, propellers, and batteries. Unless one
of these variables is non-linear however, I do not expect this experiment will yield significant
results.
While we were able to demonstrate most of the goals we set out at the beginning of the
project, there were issues of robustness that plagued us throughout the project. For example, we
experienced sudden motor failures that resulted in crashes, “glitches” in flight where control was
momentarily lost, occasional instabilities, occasional failure to arm properly, and intermittent
sonar glitches. Future work will have to address these issues before reliable missions can be
flown with this design. In addition to these stability issues, if the copter were to be moved to
production there are additional concerns. Our prototype is an evolving project consisting of
components and subsystems from many different sources tied together in a manner sufficient for
demonstration of concept mission support. Basic electronics subsystems could be built and
delivered in large quantity but the Quadcopter would have to be redesigned to accommodate
rapid assembly and test, and better sensor payload interfaces would have to be created to make
customization easier. Also, the UAV technology base is rapidly changing because of the
significant interest in this field. This rate of change results in rapid component obsolescence and
makes technology freezes difficult.
Our plan for the Quadcopter is to be able to program a complete mission on the on board
EPROM. This would mean that we would have no physical control of the Quadcopter unless we
wanted to take over manual control. The mission would a string of commands for the Quadcopter
to systematically go through. The Quadcopter will first set its home location and altitude so that
it knows where is home and if that is the landing spot it will know the relative altitude. From
there it will take off, achieve a safe predetermined altitude and then move to designated way
points. Once it is done flying to each way point which will be a specific GPS location it will
return home and land its self. As an operator the only thing I will have to do is watch the flight
live to make sure nothing is going wrong and can watch the on board camera to survey what we
are flying over. We don’t think this will be a hard thing to achieve because we already on our
way getting autonomous flight. Basically the onboard sensors and interfaces are already included
for autonomous flight but they would have to be tested and integrated into the control GUI
before testing. GPS guided flight, waypoint flying, hovering, autonomous landing are all
27
possible. Also, would be interesting to fly the copter using the onboard camera to locate landing
spots or avoid obstacles.
With these capabilities working then complete autonomous missions could be developed and
demonstrated. Completion of these efforts would require a more stable platform and a
significant amount of engineering effort but would be a very interesting follow-on activity.
7.2 Future risks:
Our biggest risk factor for this project was the limited amount of time available to
complete a very ambitious project. The project had to be completed by the end of the spring
semester. It became apparent as we worked through this project that it would not be possible to
complete all of the initial goals. The trick was to figure out what compromises to make at what
times to ensure that we had the best possible demonstration for Engineering Days. We also had
to plan for possible last minute surprises such as parts failure or crashes. We have to anticipate
problems and dedicate time in the schedule to make sure we could resolve unanticipated
problems. One area that we identified as a risk was the integration between the GUI and the
Quadcopter. The GUI was designed to run everything from sensor calibration and logs of flight
data to manual control of the helicopter and it was essential that the integration of this capability
was completed. In the end, we were able to complete this effort by hard work and carefully
compromising features for schedule as the development progressed. The other risk that we were
concerned about was pushing the Quadcopter beyond its limits without having a failsafe
function. An example of this risk would be failing to notice that there is insufficient battery life
to safely complete a mission, resulting in the Quadcopter being in the air when all systems shut
down. The Quadcopter would then fall to the ground, and most likely break. Other
considerations included watching for weather conditions as well as altitude ceiling to prevent
similar destructive results. We mitigated this risk by incorporating a real-time battery monitor
into the GUI and by considering as many potential risk factors as we could think of in the
procedures for flight. These included fail safes that forced the copter to auto respond
appropriately, such as make a decision to land safely to the ground.
More generally, there is the risk with any UAV of losing the control link to the aircraft.
Witness the recent problem of the U.S. stealth drone losing communication and crashing in Iran.
Our approach to this particular risk is to monitor the control link and cause the copter either land
or return home if the link is broken
7.3 Conclusion:
Our project to design and build a quadcopter has been a significant learning experience.
We have spent over 800 hours on this project between hardware and software. We have made
remarkable progress in demonstrating extensive tethered and untethered flight as well as limited
autonomous flight. We were too ambitious in our stretch goal for this effort as we had hoped to
demonstrate autonomous mission capability but we simply ran out of time. We believe that the
elemental hardware capabilities exist on our copter to complete this final step but system stability
issues as well as software limitations would have to be further addressed. We solved many
28
problems during our project including frame design issues, motor failures, stable flight, GUI
integration, sonar glitches, camera and transmitter control, thrust issues, thermal overloading,
and radio interference. For a small team of two students we completed an extremely difficult
project. The most significant thing we learned in this project is how hard it is to build a flying
machine. Precise control must be maintained in real time over yaw, pitch, roll and altitude. This
is far more complex than any ground-based vehicle.
We believe that our Quadcopter is ready for experimental missions and with a little more
work ready for autonomous missions. At this point the project could go in a variety of directions
since the platform seems to be as flexible as we initially intended. This flexibility allows
changing the functions it performs and also allows integration of any technology that would
prove to be useful. This project has clearly demonstrated the goals of proving that small scale
UAVs are useful across a broad range of applications.
29
Appendix:
UAVforge:
Details of the UAVforge provided below are copied from the UAVforge website. The two
figures below shown a concept drawing of the proposed challenge course as well as a summary
of the performance requirements for the competition.
Figure 17: DARPA Competition
30
Appendix A: 1. UAV (Unmanned Ariel Vehicle)
2. GUI (Graphical User Interface)
3. HAE UAV ACTD ( High altitude Endurance Unmanned Ariel Vehicle Advance Concept
Technology Demonstrator)
4. DARPA (Defense Advanced Research Projects Agency)
5. DARO (Defense Airborne Reconnaissance Office)
6. UAS (Unmanned Ariel System)
7. DIY (Do It Yourself)
8. GPS (Global Positioning System)
9. IMU(Inertial Measurement Unit)
10. TTL (Transistor – Transistor – Level)
11. NTSC (National Television System Committee)
12. FPS (Frames Per Second)
13. BPS (Bits Per Second)
14. ESC (Electronic Speed Controller)
15. Lipo (Lithium ion Polimer)
Appendix B:
Table 1: Budget
object cost reason
futaba 6 channel 2.4GHz
transmitter and reciever 199.99 to control the heli
battery charger and balancing
board 89.99
this charges the battery and makes sure the cells are charged
at the same rate (battery last longer)
5.95 connector for the battery to the power distribution board
Double sided tape (vibration) 2.89
this was put on the bottom of the board to help prevent
vibration
Soldering tip (1/64) 6.45
needed a lot finer tip in order to do the soldering on the
board
solder 2.89 needed solder
electrical tape 2.19 for wires that the rubber could not cover
x 10 header female 08POS
.1" 12
1x20 right Angle Pin headers 1
3x8 right angle pin headers 1.99
2x arms for the body 9
2x propeller set 12
4x motor 72
ESC (power the motors) 72
Xbee Telemetry kit 150
Full ArduPilot Mega kit 250
31
Lipo battery 2200 MAH 22.88
2x4 wood 6.06 needed wood to solder the button connectors correctly
Dean connectors (male) 3.75
gps 29.99
soldering iron 149.99
servo leads (longer cables) 5.9 spare parts
2S-3S 5.39 to get battery level prediction working
camera 54.96 to have a camera.....
1x motor 18
1x ESC 18
2X propeller 12
6X propeller 45
sonar / propellers 80
cables 7
new batteries 73.75 the current battery now dies ( getting 5000 watt one)
spare parts 10.77 the caps for the props
camera transmitter 50
camera reciever 50
new frame 220
Total cost 1753.78
This was the final cost after everything was purchased. The problem was that we kept breaking our frame
and we destroyed some of the batteries. The complete cost of the working Quadcopter would be closer to
1200.00 but with all the broken parts it has pushed up into the 1753.78. Most funding has been private but
we did receive some money from Agilent Technologies both semesters and we also got money from the
department that was helpful.
Appendix C:
First Semester Letter to Dan Ferguson, Agilent: Dan Ferguson
Agilent Technologies
QuadCopter
Team: Matt Parker, Gerad Bottorff, Christopher Robbiano
Supervisor: Bill Eads
http://www.engr.colostate.edu/ece-sr-design/AY11/quadcopter/index.shtml
We are a senior design team at Colorado State University in the Electrical Engineering department. We
are under the tutelage of Professor Bill Eads for the development and construction of an Unmanned Aerial
Quadcopter (UAQ). Our team is comprised of three members. Matt Parker, a senior in Electrical
Engineering is the team leader and responsible for all of the physical hardware that resides on the UAQ.
Gerad Bottorff, a junior in Computer Science is in charge programming the firmware for the UAQ.
32
Christopher Robbiano, a senior double majoring in Electrical Engineering and Physics is in charge of the
wireless video and communications systems.
The final goals of the UAQ are autonomous flight, waypoint missions and video surveillance up to two
miles. A practical application for our UAQ would be the inspection of remote locations, such as a tall
rooftop or pipeline, to prevent human endangerment. There are a number of components/sensors that
send signals to the UAQ’s onboard microcontroller, which processes these signals and controls the motors
appropriately. The sensors include two accelerometers, two gyroscopes, a barometer, a 35compass and
the electronic speed controllers (ESC). The UAQ has attained tethered level flight that lasts for a
maximum of five minutes.
Each week the team spends a minimum of 18 hours on the project. This includes performing test flights,
writing software to integrate all of the hardware together as well as testing the wireless communications
system.
We have spent $1300 on this project from personal funding but to achieve our end goals we need
additional funding of $800. This would include the following:
Carbon fiber shell $200
Sonar $150
Spare parts (props, motors, screws, servos, etc) $100
Battery $100
Foam for body $100
Camera mount $50
IR Camera $100
Total: $800
This money would be used to purchase the items listed above and used in the following manner. The
carbon fiber will be shaped around the foam to create a rigid, but light weight body that will allow us to
keep all of the electronics contained. Sonar will assist with obstacle avoidance during autonomous flight.
Spare parts will be used in testing and as replacements for broken parts. A larger battery will provide the
UAQ with a longer sustained flight time and additional power for the video surveillance system. We will
use servos to control a camera mount which will provide us with the ability to change the camera viewing
angle and direction, allowing focus to maintain on target while the UAQ moves.
We appreciate that you have considered us for a donation, and would like to thank you for spending the
time reading our inquiry. We look forward to hearing from you.
33
Regards,
Matt Parker
Gerad Bottorf
Christopher Robbiano
Second Semester Letter to Dan Ferguson, Agilent
We are a senior design team at Colorado State University in the Electrical Engineering department. We are under the supervision of Bill Eads, an Instructor at the University, and a retired HP R&D Manager. Our team is comprised of two members. Matt Parker, a senior / graduate student in Electrical Engineering is the team leader and responsible for all of the physical hardware that resides on the Unmanned Arial Quadcopter (UAQ) as well as the system engineering. Gerad Bottorff, a junior in Computer Science, is in charge of programming the GUI interface with the Quadcopter. Each week the team spends a minimum of 18 hours on the project. This includes performing test flights, writing software to integrate all of the hardware together as well as testing the wireless communication systems.
34
The UAQ is a complex system with hundreds of components, including sensors that send signals to the UAQ’s onboard microcontroller which processes these signals and controls the motors appropriately. The sensors include two accelerometers, two gyroscopes, a barometer, a compass and the electronic speed controllers. While we have all the basic components integrated into the Quadcopter, we are working to make them all work together. The UAQ has attained tethered level flight that lasts for a maximum of five minutes. A practical application for our UAQ would be the inspection of remote locations, such as a tall rooftop or pipeline, to prevent human endangerment. To demonstrate these applications, the final goals of the UAQ project are autonomous flight, waypoint missions, video surveillance at a distance of up to one mile, using a new GUI system to interact with the Quadcopter Our Current Schedule is outlined below and presented in detail in Figure 1:
February:
a. Coding GUI
b. wireless video (with new transmitter and receiver) integration
March
a. Non tethered stabilized flight
April
a. Mission planning (auto take off, way point flying, and landing)
b. Engineering Day (demonstrate automatic flight from preplanned directions)
35
Figure 1: Project Schedule To date, we have spent $1533.78 on this project mostly from personal funding. Below shows a table showing all funding we have received. We have purchased almost all components that we will be using in our final demonstration. If we receive funds it would go towards offsetting the cost of the recently purchased video wireless communication system that will allow us to send live video up to a mile. The money will also go towards repairing the frame of the UAQ and making it more durable.
Funding from: Amount:
ECE department $200
Agilent $100
Personal funding $1200
We appreciate your support last fall, we used the funds we received from you to purchase sonar which allows us to have more precise altitude hold. Thank you for considering us for a donation this spring.
36
Acknowledgements: We would like to thank Bob Parker for most of the funding.
We would like to thank Dan Ferguson for donating some money towards our project.
We would like to thank the ECE department for their contributions.
We would like to thank Bill Eads for accepting to advisor our project.
We would like to thank Dylan Roscover for supplying the title design for our poster.
We would like to thank Rob Meyer for a CAD mockup of our Quadcopter.
We would like to thank those who have shown support for our project.
37
References:
1. http://www.as.northropgrumman.com/products/ghrq4a/index.html
2. http://www.ga-asi.com/products/aircraft/predator.php
3. http://www.sciencedaily.com/releases/2011/07/110701203725.htm
4. http://www.uavforge.net/
5. http://diydrones.com/
6. http://www.helikraft-rchelicopters.com/store/1909/futaba/6ex-2-4g-airp-heli-radio-set-no-servo-
with-r617fs-6ex-ss.html (picture of RC controller)
7. http://dlnmh9ip6v2uc.cloudfront.net/images/products/10061-01b_i_ma.jpg
8. http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/point-
multipoint-rfmodules/xbee-pro-xsc#overview
9. http://www.iflyrc.com.au/images/xbee%20900.jpg
10. http://www.onlineethics.org