Long Range Aerial Drones

A Major Qualifying Project Report Submitted toWORCESTER POLYTECHNIC INSTITUTE

in partial fulfillment of the requirements for the degree of Bachelor of Science in Electrical and Computer Engineering

by

_______________________ Robert Hall

_______________________ Grzegorz Klos

This report represents work of WPI undergraduate students submitted to the faculty as evidence of a degree requirement. WPI routinely publishes these reports on its web site without editorial or peer review. For more information about the projects program at

WPI, see http://www.wpi.edu/Academics/Projects

_______________________ Professor Alexander Wyglinski, Advisor

April 30, 2015

I Abstract

In the past years, aerial drones have been making significant progress in performing

tasks that would normally be considered too dangerous or precise for a person to execute. With

recent improvements in technology, aerial drones are becoming more autonomous than ever.

From military and safety applications to commercial delivery systems and recreational use,

drone automation is changing the way we look at the future of common everyday services. The

purpose of this project is to examine current drone automation techniques, investigate how they

work, and design a do­it­yourself solution with a small budget using only off­the­shelf

components.

Page 1

II Executive Summary

Due to recent advancements in technology, people constantly look towards developing

systems that can be fully automated in order to perform different tasks. Some systems are

widely known and used in everyday life, such as a coffee maker or a washing machine. These

systems have been widely accepted by public and have been in use for decades. New

technologies allow for better and more efficient products that are currently under development. In

the near future the world will experience many changes due to automated systems. A lot of

everyday jobs may be replaced by automation which in return will create more jobs for people

that are responsible for maintaining these systems.

One of the automated systems that have been gaining a lot of exposure and interest from

developers as well as investors all over the world are the automated drone systems. These

systems are very flexible and can be adapted to perform a variety of different tasks. While the

general public is still unsure if drone automation is ready to be used safely in residential areas,

there is one main issue that needs to be addressed. The big question that everybody seems to

be asking is, is automation actually worth it. While cost of development and implementation of

these systems continues to be high, big companies such as Amazon are pushing forward to

make the first major steps in the direction of automation breakthrough in order to make these

systems more acceptable in today’s society.

The purpose of this project was to research and examine current drone automation

systems, design a reliable system from off­the­shelf components, and build a functional

prototype that would satisfy most current automated drone system requirements while keeping

the cost of components to minimum. Parts of this report were meant to be written as a

Page 2

do­it­yourself manual for future readers in order to inspire further ideas and development of

automation systems.

The first step in the overall system design was to agree on a top level system schematic

which followed by carefully picking components that could be used and put together with minimal

physical modification. The team agreed to make the system user friendly by using mostly plug

and play components such as USB Wi­Fi and Bluetooth modules as well as known personal

mini computers called Raspberry Pi. All communication protocols were kept intact in order to

provide system flexibility and allow future expansion.

Once all components were chosen, the team started work on development of individual

subsystems that would eventually be combined into one working autonomous drone system.

The individual subsystems included bluetooth communication and high speed wireless file

transfer, sending Wi­Fi signals through a wired connection to increase system security,

developing various software scripts that would allow for drone control without user interaction,

and development of a GPS based algorithm for automatic flight pattern calculation. These

subsystems were developed, tested and verified individually after which they were combined

together to form the main system. The subsystems were then tested by putting them through

multiple different scenarios in order to make sure that the automation could handle some of the

most common problems faced with current drones such as loss of communication or malicious

attacks by third parties.

The final results of the system testing were positive and provided a lot of insight and

useful information on how automation can be achieved with minimum costs. Knowing how these

Page 3

self developed systems behave in real world applications opened many doors for future

expansion and additional features. The system was made to be very flexible by adding

modularity into all software scripts that were developed in the process. It is important to note that

the projects goal was to serve as a proof of concept and some additional work would be required

in the future in order to meet all standards that would allow for operation in public places. One of

the features that still need development included a kill switch which would allow for the user to

disable the drone in case of an emergency situation. Implementing this functionality would

improve the safety of the system making the idea of drone automation more attractive to the

general public.

Page 4

III Table of Contents

I Abstract Page 01 II Executive Summary Page 02 III Table of Contents Page 05 IV List of Figures Page 07 1.0 Introduction Page 08

1.1 Motivation Page 08 1.2 Current State of the Art Page 09 1.3 Issues Page 10 1.4 Project Contributions Page 11 1.5 Project Report Organization Page 13

2.0 Background Page 16

2.1 Raspberry Pi and Linux Page 16 2.2 Parrot AR.Drone 2.0 Page 17 2.3 Bluetooth Page 18 2.4 Wi­Fi Page 20 2.5 Chapter Summary Page 21

3.0 Proposed Approach Page 23

3.1 High Level Description Page 23 3.2 System Layout Page 23 3.3 Overall Design Page 25 3.4 Project Management Page 26 3.5 Chapter Summary Page 26

4.0 Bluetooth File Transfer Page 27

4.1 Bluetooth Protocol Overview Page 27 4.2 Wireless Bluetooth Connection Page 28

4.2.1 Initialization Page 29 4.2.2 Device Verification Page 29 4.2.3 Wireless File Transfer Page 30

4.5 Testing and Verification Page 30 4.6 Chapter Summary Page 31

5.0 Drone Automation Page 32

5.1 Python ARDrone Library Overview Page 32 5.2 Plain Text Instruction Translation Page 32 5.3 Wi­Fi Connectivity Page 33 5.4 GPS Data Page 34 5.5 Testing and Verification Page 36 5.6 Chapter Summary Page 37

Page 5

6.0 Communication Hardware Page 38

6.1 Disabling the Onboard Antenna Page 38 6.2 Installation of Wired Wi­Fi Connection Page 42 6.3 Signal Attenuation Page 45 6.4 Attenuator Circuit Page 50 6.5 Testing and Verification Page 51 6.6 Chapter Summary Page 52

7.0 Systems Integration Page 53

7.1 Integration Overview Page 53 7.2 Automatic Script Execution Page 53 7.3 Main Drone Program Page 56

7.3.1 Initialization Stage Page 56 7.3.2 Connecting to Drone’s Network Page 57 7.3.3 Transmitter Pad Bluetooth Detection Page 57 7.3.4 Translating and Execution of Text Commands Page 58 7.3.5 Finalizing Instruction Set Execution Page 59

7.4 Testing and Verification Page 60 7.5 Chapter Summary Page 60

8.0 Conclusions and Future Improvements Page 61

8.1 System Conclusions Page 61 8.1.1 Bluetooth Conclusion Page 61 8.1.2 GPS Conclusion Page 62 8.1.3 Drone Automation Conclusion Page 62 8.1.4 Hardware Conclusion Page 63

8.2 Future Improvements Page 64 8.2.1 GPS Algorithm Page 64 8.2.2 Kill Switch Page 65

9.0 Appendices Page 66

9.1 Bluetooth Pad Server Python Script Page 66 9.2 Bluetooth Drone Client Python Script Page 67 9.3 Text Reader Object Python Script Page 68 9.4 Auto Wi­Fi Object Python Script Page 69 9.5 GPS Read Object Python Script Page 70 9.6 Main Drone Program Initialization Stage Page 71 9.7 Main Drone Program System Loop Page 72

10.0 References Page 73

Page 6

IV List of Figures

1.0 Introduction 1.2a The DJI Innovations Spreading Wings S800 EVO Page 09 1.2b The AirDog Page 10

2.0 Background

2.1a The Raspberry Pi Model B+ Page 16 2.2a The Parrot AR.Drone 2.0 Page 17 2.2b Drone Feature Breakdown Page 18 2.3a Bluetooth power and range requirements Page 19

4.0 Bluetooth File Transfer

4.1a L2CAP bluetooth data transfer diagram Page 28 5.0 Drone Automation

5.2a AR.Drone sample instruction file Page 33 5.4a Adafruit Ultimate GPS Breakout Page 35 5.4b USB to TTL Serial Cable Adapter Page 35

6.0 Communication Hardware

6.1a AR.Drone with the plastic shield Page 38 6.1b AR.Drone with shield removed Page 38 6.1c AR.Drone board with wire connectors disconnected Page 39 6.1d Top side of the board Page 40 6.1e Bottom side of the board Page 40 6.1f RF test point on the main board Page 41 6.1g On board antenna trace and inductor Page 41 6.1h Drone antenna trace removed Page 42 6.1i Drone antenna inductor removed Page 42 6.2a Drone’s unaltered RF test point Page 43 6.2b Exposed metal surface Page 43 6.2c The MMCX RF connector before mounting… Page 44 6.2d The MMCX RF connector mounted on the drone’s… Page 45 6.3a Unmodified drone signal strength Page 47 6.3b Modified drone signal strength Page 48 6.3c Variable Distance Signal Strength Testing Page 50 6.4a Components of the attenuator circuit Page 51 6.4b Attenuator circuit attached to drone Page 51 6.5a Network testing Page 52

7.0 Systems Integration

7.2a Steps required to remove login requirement... Page 54 7.2b Drone’s launcher shell script Page 55 7.2c Pad’s launcher shell script Page 55

Page 7

1.0 Introduction

This project is intended to bring cheap drone automation to consumers, in lieu of current,

high priced alternatives.

1.1 Motivation

Drone automation is becoming a desirable feature for many delivery oriented companies.

Programming a drone with GPS coordinates to deliver small packages will cut delivery times

and take the human error out of the equation. Delivering with automated systems will also

become cheaper than the conventional delivery methods. Currently there are few companies

that are already working on drone delivery systems. Such companies include Amazon [ref1.1a]

and QuiQui [ref1.1b]. Amazon is working on medium sized drones to deliver all types of

packages to their customers. QuiQui is a company based in San Francisco that is getting ready

to roll out a drone delivery system that will allow for delivery of drug store items in certain areas

of the city. As the FAA is finalizing rules and regulations on automated aerial vehicles, we could

be seeing these systems in action as early as 2015. [ref1.1c]

The AR Parrot 2 drone is a smaller drone that would not be fit for delivery purposes. With

a maximum payload of approximately 600 grams, almost any type of package would be too

heavy. While the AR Parrot 2 is not the most powerful drone, it is however very good for other

purposes such as data collection and video surveillance due to its small size and various

onboard sensors. The only downside to the AR Parrot drone is that its range is very limited. In

order to solve this problem, the drone’s software will be modified to perform tasks automatically

which will allow for operation outside of its range.

Page 8

1.2 Current State of the Art

Current commercially available automated drones come at high cost. DJI Innovations

Spreading Wings S800 EVO, an automated bot for photography and videography, comes in at

$1,900. The Spreading Wings S800 EVO has carbon fiber propellers and high performance

motors, giving it a 2.5 Kg payload. This eclipses the Parrot AR.Drone’s meager 0.6 Kg payload.

For its high price, this hexarotor aircraft does NOT include a camera or gimbal to mount it on.

[ref1.2a]

Another automated drone, the AirDog, comes in at $1,495. The AirDog is can carry a

GoPro, a popular extreme sports camera, and will accurately track its user. This is

accomplished using a wristband called an “AirLeash” that the AirDog is able to follow. [ref1.2b]

Page 9

1.3 Issues

The unfortunate major problem with the current state of the art is the price. Current

automated drones go for well over a thousand dollars, and most require additional equipment.

The Parrot AR.Drone is a cheap alternative to these drones, but required extra hardware to

become a true drone, not simply a remote controlled quadcopter. Using and modifying the Parrot

AR.Drone was the best possible solution to the price dilemma, but this brought on even more

issues than it solved.

The largest glaring problem was the battery. In preliminary tests, flight time could be as

high as 10­12 minutes. Takeoff and landing were the largest current sinks, with multiple takeoffs

and landings cutting the flight time clean in half. It took entirely too much power to impart

momentum into the quadcopter, though once airborne or even mobile, the required energy to

sustain the height and speed was comparably minimal.

Page 10

Another problem with the Parrot AR.Drone is the low security. The Parrot’s unsecured

wireless hotspot and open port structure make it a hacker’s dream. It is possible to Telnet or

FTP into the drone from its wireless hotspot, or even eavesdrop on the video feed using the

unsecured wireless SSID. [ref1.3a] Additionally, open source code such as Skyjack is freely

available. Skyjack is a free utility that can be compiled and will create a Parrot AR.Drone that will

automatically seek out, hack, and hijack other Parrot drones in the nearby vicinity. [ref1.3b]

These vulnerabilities make the Wi­Fi on the Parrot a cause for concern, as automated drones

present more cause for alarm.

The last problem the Parrot AR.Drone faces is its very limited control range. The range

was only approximately 200 feet, due to the limitations imposed by the low power of the wireless

radio on mobile devices. Using mobile devices to control the Parrot AR.Drone was simply not a

viable option. In addition to this, even without mobile devices to hold it back, the Parrot can only

fly as far as the battery permits. Running out of battery while thousands of feet from the launch

point would be an issue.

1.4 Project Contributions

Commercial applications for automated drones are purpose­built machines with

advanced hardware and enormous research and development teams to justify their astronomical

price tag. In order to take on these giants, cheap, off­the­shelf solutions would be needed.

Battery was a serious issue with the Parrot AR.Drone. With that in mind, we scoured the

internet for drop­in battery replacements. The largest that could be found was a 2500 mAh

model, which is a 250% improvement on the stock 1000 mAh battery. But simply replacing the

Page 11

battery was not enough ­ the problems with takeoff and landing draining goliath amounts of

current were cutting into flight time. We needed a more clever solution. The team reasoned that

with quick enough instruction downloads, we could shed the need to land entirely, saving tons of

time and energy with the takeoff and landing phases. By programming the drone to download

instructions during flight, the drone is capable of handling multiple instruction sets in a row

without ever landing. This, combined with the enhanced battery life, added thousands of feet to

our range.

Security was also a huge concern with the Parrot AR.Drone. Due to an open port

structure and totally unsecured hotspot, the AR.Drone is a target for even the lowest skilled

hacker. As extensively modifying or replacing the AR.Drone’s ASICs was not within the

intended scope of the project, the best solution would be to remove the Wi­Fi capability

altogether. By utilizing a Raspberry Pi connected directly to the drone via RF cable and some

simple, minor modifications to the traces on the Parrot AR.Drone’s ASIC, it was possible to

completely replace the wireless control and mobile device with an RF cable and a Raspberry Pi.

By doing this, the AR.Drone no longer had wireless broadcast capability. In order to hack into

the drone’s wireless, the malicious individual would need extended physical access to the drone

­ a difficult feat while it is flying.

The last major solution that was implemented was extending the range. Solving this

problem required a solution that targeted two fronts. As mentioned earlier, increasing the Parrot

AR.Drone’s battery capacity from 1000mAh to 2500mAh resulted in increased flight time, even

with all the extra weight from the Raspberry Pi, Bluetooth, and Wi­Fi hardware. The other front

involved removing the mobile device range limitations. Using your iPhone to control the drone

Page 12

gives little to no automation, and requires the device to be within range. Connecting the Parrot

AR.Drone directly to the Raspberry Pi and feeding it a list of instructions to interpret gives the

drone a limitation of only its battery life, since the device controlling it is flying with it.

1.5 Project Report Organization

This report is a comprehensive look at the research and development that lead to the

completion of the modified LRAD AR.Drone. It explains the motivation for our project, what we

hoped to accomplish, and what we did accomplish. It also touches on uses for automated

drones in commercial and civilian applications. Lastly, it gives a cursory explanation for how

each problem was approached and solved.

In the Background section, the report details the necessary knowledge to understand the

rest of the report. The Raspberry Pi and its Linux operating system, the Parrot AR.Drone, Wi­Fi,

and Bluetooth are all explained. The nuances of each system are fleshed out, and a brief history

of their respective invention and development are also explored.

The Proposed Approach section describes the project from a high level, explaining how

the system is intended to work and the basic steps of its operation. This section also details the

topography of the drone system in its entirety, including individual components. Additionally, it

explains the software cycle, its inner workings, and how all software interacts with each other

within the scope of the project. Lastly, the Proposed Approach section also details the course of

the project and how task assignment was handled.

Page 13

The Bluetooth File Transfer section takes an in­depth look at the Bluetooth system and

how our project was structured around it. This section details the L2CAP protocol for Bluetooth

devices, and the modes of operation is brings. It also explains the details of establishing a

Bluetooth connection between the client and its server, everything from names, addressing, and

port selection. As it is integral to the project, file transfers using L2CAP are also explained at

length. Lastly, the Bluetooth File Transfer section also iterates the testing and verification

processes used to ensure accurate and full file transfers.

The Drone Automation section goes into detail regarding the Python ARDrone open

source library and its use in the project. Examples for the plain text instruction file reception and

translation are given and explained. Automatic Wi­Fi connection capability and Python solutions

for the automatic connection are shown, as well as a look at the underutilized GPS module.

Once again, testing and verification procedures are explored with regards to instruction

translation, wireless connectivity, and GPS testing.

The Communication Hardware section explains the steps taken to convert the drone’s

Wi­Fi to a wired setup using an MMCX RF connector. This section details the trace removal

process, soldering of the MMCX RF connector, and stability concerns. It also provides a step by

step analysis of the signal attenuator fitment process and the testing that required. Lastly, the

testing and verification subsection explains the processes used to validate the Wi­Fi to wired

capability.

The Systems Integration section outlines the way each subsystem is integrated into the

whole. The section covers the removal of the manual login process and execution of automatic

Page 14

Python scripts on bootup. The creation of a main drone script to run the entire process is

detailed here. Additionally, the creation of Wi­Fi profiles and pad detection is also explored.

Example test setups are explained in the Testing and Verification section.

Page 15

2.0 Background

2.1 Raspberry Pi and Linux

The Raspberry Pi is a small single­board computer originally created in the United

Kingdom with the purpose of having a cheap, small computer to teach programming to children.

[ref2.1a] The Raspberry Pi is offered in multiple models A, A+, B (revision 1 and 2), B+ and

Compute Module. All models are based on the Broadcom BCM2835 System on Chip [ref2.1b],

utilizing a 700 MHz ARM1176JZF­S processor and VideoCore IV GPU.

The Model A, A+, and B revision 1 shipped with 256 MB of memory, while the B revision

2, B+, and Compute Module ship with 512 MB. Models A and B support SD cards, while Models

A+ and B+ utilize MicroSD card slots. [ref2.1c] The Compute Module is a special case. Having

been designed for embedded purposes, the Compute Module utilizes an eMMC flash chip

[ref2.1d] to store the operating system and the associated files. The Model A and Model A+ do

not have an ethernet port, but can be connected using a USB ethernet adapter. The Model A and

A+ only contain one USB port. The Model B has a two port USB hub, whereas the Model B+

carries two of the two port. [ref2.1e]

Page 16

The Raspberry Pi runs using Linux­kernel operating systems. The Raspberry Pi’s

recommended operating system is Raspbian [ref2.1f], but the Raspberry Pi also supports

Archlinux ARM, Pidora, OpenELEC, Puppy Linux [ref2.1g], Raspbmc [ref2.1h], and RISC OS

[ref2.1i]. The Linux kernel used in the Raspberry Pi operating systems operates on the ARM v6

instruction set. The Raspberry Pi also comes preloaded with Python, Java [ref2.1j] and C++/C#

compilers, Mathematica[ref2.1k], Ruby[ref2.1l], and even a stripped down version of Minecraft

[ref2.1m].

2.2 Parrot AR.Drone 2.0

The Parrot AR.Drone 2.0 is a remote controlled quadcopter created by the French

company Parrot. The Parrot AR.Drone is controlled by iOS or Android devices through a

wireless connection to the drone, utilizing the AR.FreeFlight 2.0 mobile application.

The drone has an 802.11n wireless capability with a Parrot­claimed range of

approximately 200 feet. The Parrot drone carries multiple onboard sensors for a variety of

purposes. The Parrot drone carries a 720p camera on the front which records with 30 FPS and

Page 17

a 93 degree field of view, while carrying a bottom­facing camera at QVGA (320x240) resolution,

64 degree field of view, and 60 FPS. The quadcopter comes equipped with a 3­axis gyroscope,

accelerometer, and magnetometer. Altimetry is handled by an air pressure sensor and a pair of

ultrasound transceivers. In addition to this, the Parrot AR.Drone 2.0 can have an optional USB

flight recorder installed which adds GPS capability, flight path definition, and 4 GB of storage.

[ref2.2a]

2.3 Bluetooth

Bluetooth is a wireless communication standard for transferring data over short

distances. Bluetooth is named after the tenth­century Scandinavian king, Harald Bluetooth, who

was famous for uniting multiple Danish tribes. The name was proposed by a man named Jim

Kardach who reasoned that this standard, originally intended to connect mobile phones and

personal computers, would unite communication protocols to one single standard. [ref2.3a]

Page 18

Bluetooth uses short­wavelength UHF radio waves in the 2.400­2.485 GHz ISM band.

Bluetooth is standardized by the Institute of Electrical and Electronics Engineers with IEEE

802.15.1. [ref2.3b] Bluetooth was designed a short range, low power standard for

communication. Bluetooth comes in three classes, whose specifications are shown in the table

below.

Bluetooth’s 2.400­2.485 GHz band is globally unlicensed, but regulated, for Industrial,

Science and Medicine (ISM) purposes. Bluetooth operates in a master­slave configuration,

where one master device can communicate with up to 7 more devices. [ref2.3c] This master

Bluetooth device and its seven ad­hoc networked slaves is collectively labeled a “piconet”.

[ref2.3d] Bluetooth allows for two way transfer between the master and one slave at any given

time. Because of this, Bluetooth master devices often operate in “round­robin” fashion, meaning

they quickly switch between devices with which they exchange data. A device can play a

master role in one piconet while playing the slave role in at least one other. The joining of multiple

Page 19

piconets creates a “scatternet”. In the Bluetooth master­slave structure, all slaves follow a clock

signal from the master device.

Today, Bluetooth connectivity is used in everything from hands­free mobile phone

headsets, laptops, computer peripherals, mobile phone speakers, medical equipment, consumer

automobile stereo systems, and health sensors. Game consoles such as the Nintendo Wii and

Playstation 3 use Bluetooth for controller connectivity. For industrial purposes, machines and

their respective sensors use Bluetooth communication to send and receive data to their

embedded computers. Devices without Bluetooth connectivity can easily adapt using a USB

Bluetooth dongle to add the functionality.

2.4 Wi‐Fi

Wi­Fi is a technology which allows a local area network to be created wirelessly. Wi­Fi

uses radio waves in order to provide high speed connectivity between devices and the internet.

The Wi­Fi Alliance, who owns the trademark for the term “Wi­Fi”, defines Wi­Fi as any “wireless

local area network products that are based on the Institute of Electrical and Electronics

Engineers’ (IEEE) 802.11 standards.” [ref2.4a]

Wi­Fi requires no physical connection, since it uses radio frequency waves sent and

received from an antenna to communicate. Wi­Fi radios use either the 2.4 GHz range, consisting

of 802.11b, 802.11g, and 802.11n, or the 5 GHz range, consisting of 802.11a, 802.11n, and

802.11ac. The 2.4 GHz channels are spaced throughout the 2.4000­2.4835 GHz range, spaced

5 MHz apart. [ref2.4b]

Page 20

Wi­Fi has the advantage of allowing anyone to create a Local Area Network (LAN)

without excessive expense or the need to run cables where cables would be undesirable, such

as conservation buildings or outdoor areas. Laptops, tablets, mobile phones, game consoles,

and other electronic devices have built in wireless capability. The Wi­Fi Alliance designates

products as “Wi­Fi Certified”, indicating their backwards­capable abilities to communicate, at

least on a basic level, with all other Wi­Fi products worldwide.

Wi­Fi inherently has many security risks, and as such many features have been

developed to combat these risks. Because Wi­Fi is broadcast in a radius, attackers often require

no physical security access to snoop a Wi­Fi network. In response, Wired Equivalent Privacy

(WEP) encryption was developed. Eventually, WEP was shown to be easily broken via packet

sniffing. In 2003, Wi­Fi Protected Access (WPA) encryption was developed and deployed to

wireless devices. One year later, in 2004, WPA2 was created using Advanced Encryption

Standard (AES). WPA2 is backwards compatible with WPA. Another security solution is to hide

the broadcast of Service Set Identifiers (SSIDs), allowing only those who know the SSID of the

network to gain access. This is not effective, as simply querying for an SSID broadcast can gain

one access if this is the only security implemented. It is possible to restrict Wi­Fi devices from

only communicating with a specific list of MAC addresses, but MAC addresses can be spoofed,

meaning an attacker can try thousands of MAC addresses per second until one is accepted.

[ref2.4c]

2.5 Chapter Summary

This section outlines the background of the products, functions, and protocols used in

the project. The Raspberry Pi is a cheap, single­board Linux­based computer with a small form

Page 21

factor and big potential, and it made this project possible. The Parrot AR.Drone is a highly

advanced piece of French quadcopter hardware providing myriad sensor equipment and lift

capability with good battery life, it is the best bang for the buck with respect to the amount of

technology contained within it. Bluetooth is an effective short range protocol standard that allows

quick data transmission and low power usage. Wi­Fi is a go­to wireless communication standard

that allows effective communication of all distances, short and long, and is the standard the

AR.Drone runs on.

Page 22

3.0 Proposed Approach

3.1 High Level Description

The LRAD Automated AR.Drone should be capable of executing automated flight

instructions without human intervention. The drone should be able to obtain instructions from one

of an approved list of landing pads, execute the instructions independent of an operator, and,

assuming another pad is within range, download more instructions to execute. Should the drone

encounter any obstacles or errors, it should land as soon as possible. In the event of a collision

or drone inversion, the motors must immediately cut to prevent damage to humans, the drone, or

property. Battery consumption is also a concern, and in the event of low battery the drone must

refuse to lift off and, if in flight, land as soon as possible. This functionality should be added while

keeping additional weight on the AR.Drone to a minimum. Instructions are to be coded using

simple plaintext in a text file, while the drone must be capable of interpreting these instructions

and translating them to in­flight commands.If the drone is mid­flight and enters the range of a

landing pad, it is expected to download new instructions quickly and efficiently, then to begin

executing them in short order.

3.2 System Layout

The modified LRAD AR.Drone system has two major components, the drone itself and

the landing pad. The drone is capable of connecting to and receiving instructions from the

landing pad. The landing pad is, inversely, capable of accepting a connection from and sending

instructions to the drone.

Page 23

The modified LRAD AR.Drone itself has many systems and subsystems which make its

operation possible. The LRAD AR.Drone still retains all the onboard ASICs and sensory

equipment. The drone is still capable of receiving Wi­Fi instructions as it normally would, if a

connection to an external antenna were provided. The AR.Drone carries a Raspberry Pi which

runs a distribution of Debian Linux known as Raspbian. This distribution of Raspbian comes with

Python 2.7 and its development environments. Running a custom Python script, the Raspberry

Pi is able to handle operation of its additional subsystems. In addition to the Raspberry Pi, the

LRAD AR.Drone is equipped with a Bluetooth dongle to enable communication with the landing

pad. As Raspbian has integrated Bluetooth drivers, the Python libraries contained much of the

functionality needed to code Bluetooth capability into the Raspberry Pi. A Bluetooth dongle for

which the Raspberry Pi already has driver capability had to be selected. This Bluetooth dongle

will assist the drone in detecting nearby pads and receiving instructions. The LRAD AR.Drone’s

Raspberry Pi is also equipped with a wireless communication (Wi­Fi) dongle. This dongle was a

ModMyPi Ultra Long Range High Gain 5dBi USB Wi­Fi dongle. The Wi­Fi dongle is capable of

802.11 b, g and n standards, as is the stock Parrot AR.Drone. In order to connect the Wi­Fi

dongle, by wire, to the AR.Drone’s modified MMCX port, an RF cable was necessary. Because

the Wi­Fi dongle had a 5dBi gain [ref3.2a], significant attenuation was necessary to prevent

damage to the Parrot AR.Drone’s internal ASIC hardware. All of this was mounted via lightweight

zip ties onto the underbelly of the Parrot AR.Drone. In order to prevent contact with the ground,

suspended landing feed were created using large zip ties on the corners of the drone, below

each motor. In addition to all of this, an upgraded battery was installed on the drone. This

upgraded battery pack allows the drone more than double its usual air­time before it must land,

and adds less than fifty grams of weight.

Page 24

The LRAD AR.Drone is nothing without a landing pad and base station to send it

instructions. The landing pad also contains a Raspberry Pi which runs Python 2.7 and its

respective Integrated Development Environment. The Python 2.7 script running on the landing

pad allows the Raspberry Pi to act as a base of operations for any properly­equipped drone

which enters its airspace. In order to do this, the Raspberry Pi on the landing pad also needed to

be equipped with Bluetooth capability. Using the same Bluetooth adapter as the drone, the

included Python Bluetooth libraries made it possible to create a script which forged a solid

connection with the AR.Drone over which files could be sent. The Raspberry Pi, coupled with

the Bluetooth dongle, made it possible to facilitate expedient file transfers from ranges of up to

100 meters.

3.3 Overall Design

In order for the LRAD AR.Drone to function, software was key. First, control of the drone

using Wi­Fi over RF was needed. To do this, a Python AR.Drone library was utilized in order to

create a secure, simple channel through which the drone could be commanded. The commands

are usually executed in real time, but a program was created to interpret and execute, for the

proper time periods, commands contained in an instruction file. Software for both the LRAD

AR.Drone and the landing pad are continuous loops. The AR.Drone defaults to waiting for

instructions at the initial software runtime. The drone is also looking for connections to a certified

landing pad, secured by a whitelisted Bluetooth address. The landing pad will create a Bluetooth

connection between itself and the drone, ensuring the AR.Drone is an accepted address as well.

Upon connection, the AR.Drone will prepare to accept an instruction file of any length. At this

point, the landing pad will send the instruction set to the drone. Once the file transfer is verified

and complete on both ends, the landing pad will sever the connection. After severance, the

Page 25

LRAD AR.Drone will execute the entirety of its instruction set for the duration each step was

ordered for. The landing pad will now prepare the next instruction set for transmission. When all

instructions are completed successfully, the LRAD AR.Drone will erase its instruction file and

return to the “awaiting instructions” phase.

3.4 Project Management

Dynamic project management was used throughout the course of this project in order to

make sure that each team member had a fair amount of tasks to accomplish at any given time.

Since some features took a lot longer to implement than others, flexible scheduling was also

used in order to provide maximum amount of resources for development of subsystems that

could potentially slow down the entire project if not completed on time. Selecting and ordering

components was done as a team, however research and development of individual subsystems

was split between each member of the group.

3.5 Chapter Summary

The modified LRAD AR.Drone is a capable machine that can execute complicated

instructions without human intervention. Utilizing clever scripting and simple, off­the­shelf

hardware, the drone is capable of complex instruction sets. The drone is able to download and

execute multiple sets of instructions in a row without ever touching the ground, restricted only by

battery life. With an upgraded battery under its belt, the LRAD AR.Drone is able to spend large

amounts of time in the air before it has no choice but to land.

Page 26

4.0 Bluetooth File Transfer

4.1 Bluetooth Protocol Overview

The Bluetooth file transfer between the Raspberry Pi on the drone and the transmitter

pad was handled by using a logical link control and adaptation protocol, also called L2CAP.

L2CAP allows for transmission of data with up to 64 kilobytes in size, which was more than

enough for sending a plain text instruction file between two Bluetooth devices. L2CAP provides

multiple operational modes such as flow control mode and retransmission mode, however the

basic mode of operation was the most fitting in this application. The L2CAP is a channel based

transmission system which allowed for quick connectivity and very fast file transfer speeds

[ref4.1a]. Figure 4.1a below represents data flow using L2CAP. Note that the figure

demonstrates connectivity with different devices in different modes. This application of the

protocol used connectionless data channel for data transfer in order to provide extra security.

This required the two Bluetooth devices to establish a new connection each time data transfer

direction was changed. This type of connection is shown in device #3.

Page 27

4.2 Wireless Bluetooth Connection

Establishing a Bluetooth connection between two devices was fairly simple. In this

section of the report the transmitter pad’s Raspberry Pi will be referred to as the “server” since it

will be providing the instruction file, and the drone’s Raspberry Pi will be referred to as the

“client” because it will be on the receiving end of the system. Note that the full content of the

Python scripts running on both devices can be found in the appendices 9.1 and 9.2.

Page 28

4.2.1 Initialization

The first step in establishing a Bluetooth connection was to set some basic parameters

on the server. The first parameter was the target name. This property represented the device

name that the server was going to try connecting to. In order to simplify testing of the system

later in the process, this property was set to the public Bluetooth name of the client. The next

property was the port number. As mentioned in the previous section, L2CAP is a channel based

system. Setting a port number tells the protocol which channel to use during data transfer. This

property was set to 0x1001 in hexadecimal form [ref4.2.1a]. The next two properties are the file

address and the file size limit. Those two properties specified where the file would be read from

and/or written to, as well as the maximum size of the file that could be sent over the wireless

Bluetooth connection. For testing purposes the file size limit was set to 2 kilobytes, however it

could be increased up to 64 kilobytes.

4.2.2 Device Verification

Once all initial parameters are set up the server starts scanning for all available Bluetooth

devices within its range. Since both the server and the client are using class 1 Bluetooth

devices, this allows for connections up to 100 meters apart [ref4.2.2a]. After the initial scan is

done, the server checks all device names and compares it to the target name property set in the

initialization stage. If the server finds a match it continues to the next step. If a match is not found

then the server continues to scan for devices.

Once a match is found the the server opens a connection socket and requests a

passcode. Opening a connection socket allows the server to receive data in a one way

connection. The client then sends a passcode to the server and the server checks if it matches

Page 29

the passcode stored in its memory. If the passcode is correct the server continues to the next

step. If the passcode does not match the predefined value, the server goes back to scanning for

new devices and the cycle starts over.

Once the passcode is verified the server closes its connection socket and waits for the

client to open a new connection socket. This reverses the direction of data transfer so that the

server can send the instruction file to the client. As soon as the client opens a new socket, the

file transfer is ready to begin. Note that the new socket is always opened on the same channel

so that the verification process needs to happen only once for each file transmission.

4.2.3 Wireless File Transfer

After the verification process is complete the server can start sending the requested file

to the client. Since the instruction file is a plain text file it is very small in size and can be sent

over almost instantly. The L2CAP Bluetooth protocol allows for transfers of up to 64 kilobytes at

a time which means that the instruction file can be sent as one continuous data stream. Once

the file transfer is complete, the client closes its connection socket and the process is complete.

4.5 Testing and Verification

Testing and verification of the Bluetooth file transfer system was done by transmitting

multiple different files from the server to the client. A message was written onto the file located

on the server which was then sent wirelessly to the client. Opening the text file that was saved

in the client’s memory resulted in the same message which confirmed that the transfer was

successful. In order to test the rest of the system’s capabilities, the process was repeated under

Page 30

different conditions such as incorrect passcodes, different device names, empty files and using

different port numbers. The system performed correctly and handled all of the different scenarios

as described in the previous sections. This concluded the development of the Bluetooth file

transfer system.

4.6 Chapter Summary

This section outlines the development process of the Bluetooth file transfer system. The

team was able to develop a working file transfer system with some basic security features to

ensure that the drone receives proper instruction files. The system was tested with multiple

independent variables which resulted in proper operation and error handling. The system was

lightweight and fast which was desirable for its application.

Page 31

5.0 Drone Automation

5.1 Python ARDrone Library Overview

The core of the automation system for the drone is the Python ARDrone library. The

library is an open source project that is free to use and distribute under the MIT license [ref5.1a].

The library is a python wrapper of the existing ARDrone library created by Parrot. The original

library was written entirely in C and since the drone’s Raspberry Pi runs a Linux­based

operating system, having a fully functional library that was compatible with python made writing

the automation software a lot easier.

The library has access to most of the drone’s functionality such as movement controls,

camera feed, accelerometer data, altitude data, battery status, and many more. Since the main

goal of the automation system was controlling the drone’s movement and flight path, most of the

functionality provided by the Python ARDrone library was not used in the final program.

5.2 Plain Text Instruction Translation

In order to be able to provide the drone with simple text commands, the team developed

a instruction format that would be read by the drone and then translated into an automated

movement sequence. The team agreed on a format similar to the assembly language which

consisted of a three letter instruction type followed by a number which represented the amount

of time in seconds that the command would be executed for. A sample instruction file is shown in

figure 5.2a below. The following instruction file would make the drone hover for one second, fly

forward for two seconds, hover for one second, fly backwards for two seconds, and then hover

Page 32

for one second again. The instruction file could be edited by any text editor which made the

system very accessible and easy to use.

The next step was to write a python script that would take the contents of the text file and

translate them into useful data that could be understood by the drone. In order to keep the main

drone program clean and organized, this functionality was moved to a separate object called

textRead which will be referred to as the text reader. The main job of the text reader was to

download the context of the file and place it two separate arrays so that one contained the

instruction types and the other contained instruction execution times. The text reader object

could also erase the text file, check is the file is empty and print the file’s content. These features

were used in the final implementation of the drone program and will be discussed in the Systems

Integration section of the report. The python script used by the text reader object is shown in full

in the appendix 9.3.

5.3 Wi‐Fi Connectivity

The AR Parrot drone operates based on instructions received through Wi­Fi. The

Raspberry Pi in its most basic form requires user input in order to connect to any of the available

Page 33

Wi­Fi networks. Since one of the main goals of this project was full automation, the team had to

come up with a way of connecting the Raspberry Pi to the drone’s network without any user

interaction. In order to achieve that, a python object called autowifi was created.

The main job of the autowifi object was to scan for any available networks in the area,

check the SSIDs of these networks against a list of known networks, and then attempt

connecting to that know network. A known network was any network that was successfully

connected in the past. For example, if the Raspberry Pi was manually connected to WPI

Wireless at least once, it was automatically added to an internal list of known networks. After a

network has been added to the list, the autowifi object could connect to it if it became available at

the time of scanning for networks.

The autowifi object allowed the Raspberry Pi to connect to the drone’s network without

any user interaction. It was done by simply calling the object’s functions every time the main

drone program was started. The python script of the autowifi object is shown in full in appendix

9.4. Section 7 of this report provides more detailed information about how the script is launched

upon start up.

5.4 GPS Data

Another goal of the automation process was to implement a system that would allow the

drone to find the next transmitter pad based on its GPS coordinates. The AR Parrot drone has

an on board GPS module, however the data it provides was not available through the Python

ARDrone library used in this project. In order to get real time GPS data a separate module was

tested. This section of the report outlines the work done with the GPS system. Note that the

Page 34

GPS system was not used in the final drone program due to lack of testing and development of

the GPS algorithm due to inclimate weather.

The GPS module tested for this application was the Adafruit Ultimate GPS Breakout. The

GPS module was small, lightweight, required very little current, and provided 10Hz GPS updates

[ref5.4a], which was ideal for this application. The module was also very simple to assemble.

Figure 5.4a below shows the GPS module and Figure 5.4b shows the USB to TTL Serial Cable

adapter which was required in order to make the module compatible with the Raspberry Pi

[ref5.4b]. Note that the input output pins had to be soldered onto the module’s printed circuit

board. The battery cover shown in figure 5.4a was not used since the power to the module was

supplied by the USB connector.

In order to get data from the GPS module, another python object was created. The new

python object was called GPSread and will be referred to as the GPS reader. The main goal of

the GPS reader was to fetch new data from the GPS module. This was done by calling the

object’s methods from the main drone program. Each method was able to return different type of

Page 35

data such as speed, latitude, longitude, and heading. The python script of the GPS reader is

shown in appendix 9.5.

5.5 Testing and Verification

Each of the systems described in the previous sections were tested individually before

integrating them together. The Python ARDrone library was tested on an unmodified drone by a

test program that would pass simple commands to the drone. The drone responded

appropriately and executed commands as told. During the tests the team has found out that if

the drone was in an emergency mode, meaning it had previously shut down due to hitting

something, executing the test program would not work. The drone had to be manually reset by

unplugging the battery in order for the python script to work again.

The text reader was tested with multiple instruction files in order to make sure that the

script would still work with files of different size and with different number of instructions. Cases

with invalid instructions were also tested to make sure that the script would not crash and

continue to work by skipping the invalid instruction. The system turned out to be working as

expected with no issues.

The autowifi object was tested by simply having it connect the Raspberry Pi to different

wireless networks. The team was able to confirm that only networks on the known networks

lists were able to connect automatically by the script. Once the network was removed from the

list, the script could no longer connect to it. This was an unplanned feature, however it provided

additional security to the system so it was left in place. The search for networks was also much

faster since the script had to check only for networks that were on the known networks list.

Page 36

The GPS module was difficult to test due to weather conditions. In order to test the GPS

signal the unit had to be outdoors, however the only way to troubleshoot it was by having it

connected to a Raspberry Pi with a monitor, mouse and keyboard. The team was able to test the

GPS signal by placing the module outside a window and monitoring the data on the rest of the

system that remained indoors. The module worked as expected by providing live GPS data.

5.6 Chapter Summary

This section outlines the process of developing systems that would allow for full

automation without any user input. Drone control through the Python ARDrone library, reading

text commands from a text file, autodetecting and connecting to wireless networks, and fetching

GPS data from a GPS module were tested and verified. These systems will be combined

together to create a main drone program. The process will be outlined and described in detail in

the Systems Integration section of this report.

Page 37

6.0 Communication Hardware

6.1 Disabling the Onboard Antenna

The initial step to hardware modification was to install a wired Wi­Fi connector. Installing

a wired connection between the Raspberry Pi and the drone would allow for a stable connection

over a short distance. For this purpose an MMCX RF connector can be installed on the drone’s

motherboard which would then connect to a USB dongle on the Raspberry Pi through a coaxial

cable. In order to get a closer look at the board and where the connection can be installed, the

motherboard was removed from the main body.

In order to remove the motherboard first the plastic bottom shield was removed. Note that

the shield is simply glued to the drone’s styrofoam body and it had to be removed with caution so

that the drone’s body is not damaged. The shield can be removed by inserting a knife between

the shield and the body and slowly lifting the shield around the outer edges of the drone. Figure

6.1a and 6.1b below show the drone with the shield on and off respectively.

Page 38

Once the board was exposed, it could be removed from the body by removing four Torx

screws. To remove the screws, a size T6 Torx screwdriver was used. Once the screws were

removed the board was still held in place by three wire connectors on top of the board and two

wire connectors on the other side of the board. The top three wire connectors include a bottom

camera connector, ultrasonic sensors connector and the front camera connector. The two

connectors on the other side are used to supply the power to the system and interface with the

motors. The wire connectors are shown in figure 6.1c below.

Page 39

Once all wire connections were disconnected the board was easily removed from the

drone body. Note that the battery connection as well as the USB connection is attached to the

board permanently and needs to be removed with the board through the hole in the battery tray.

Figures 6.1d and 6.1e below show both sides of the board.

Once the board was removed it was easy to see where the MMCX connector can be

soldered to the RF test point on the board. It is also easy to identify the single trace that needs to

be cut in order to disable the stock drone antenna. A single inductor below the Atheros chip will

also be removed since it is a part of the stock antenna circuit. The areas of interest are shown in

figures 6.1f and 6.1g below.

Page 40

The next step was to disable the antenna by cutting the antenna trace on the drone’s

board. This was simply done by cutting and scraping off a segment of the trace with a knife.

Note that the cut had to be as shallow as possible in order to avoid damaging the board. The

result of cutting the trace is shown in figure 6.1h below. The antenna inductor was also removed

since the stock antenna would not be used anymore. The inductor was located right below the

bottom left corner of the Atheros chip. Note that the inductor is both soldered onto the board as

well as surrounded by black plastic/rubber that helps with securing the Atheros chip onto the

board. Since the solder joints on this component are very small, it was the easiest to cut them

with a small knife instead of using a hot soldering iron to remove the component. Figure 6.1i

below shows the board with both the antenna trace and the inductor removed. Once both

components were removed the board was ready for installation of a wired connection.

Page 41

6.2 Installation of Wired Wi‐Fi Connection

With the inductor and antenna trace removed from the drone’s main board, it was time to

install the wired connector that would then be used to communicate with the drone. In order to

properly mount the MMCX RF connector on the board, some of the plastic covering near the RF

test point had to be removed. This was done by carefully scraping off the top layer with a small

knife. Exposing this area ensured that the solder would have more surface to attach to resulting

in a solid and strong connection. The unaltered test point is shown in figure 6.2a below. Figure

6.2b shows the RF test point with exposed metal surface for better stability of the connector.

Page 42

Installation of the MMCX RF connector required patience and precision due to the small

size of the connector. The connector itself is only few millimeters in diameter and the distance

between ground pins and the signal pin is even smaller. Additionally, the procedure had to be

done quickly in order to avoid heating up surrounding components with the hot soldering iron.

Unnecessary heat could damage these components resulting in a faulty board. Since our team

had no experience with soldering such small components, we decided to contact Robert Boisse

from the ECE shop and ask for assistance. The detailed picture of the MMCX RF connector is

shown in figure 6.2c below.

Page 43

Installation of the connector took a couple attempts even in hands of the person with

years of experience in soldering small parts. Note that typically, these types of connectors are

mounted during the fabrication process by specialized machines. With the connector in place the

continuity of the solder joints were tested with a digital multimeter. The signal pin and the ground

pins were successfully attached to the board with no connection between the two. The MMCX

RF connector mounted on the drone’s board is shown in figure 6.2d below. Note that the area

that was exposed for better support is now filled with solder providing additional stability to the

connector.

Page 44

6.3 Signal Attenuation

With the MMCX connector in place, it was time to determine the maximum signal strength

that would be safe for the drone to receive over the wired connection. Wi­Fi signals require a

significant amount of power to travel through the air and any obstacles that they might

encounter. Since the drone was now modified to receive these signals over a coaxial cable, an

attenuator would have to be used in order to prevent any damage to the components due to

receiving a signal that is too strong.

Page 45

The first step was to measure how strong the Wi­Fi signal is when using the modified

connection and compare it with another drone that was completely unaltered. Note that in order

to get comparable data, an external antenna was attached to the coaxial cable on the modified

drone so that both signals are measured in the same conditions.

The unmodified drone was tested first. The testing was done by measuring the Wi­Fi

signal strength with a laptop and its onboard Wi­Fi module. The drone was placed at a fixed

distance of approximately 3 meters away from the laptop and was then turned on. Once the

drone booted up the measurements were taken with a simple application that measures the

Wi­Fi signal strength and compares it to the RF noise in the surrounding area. Figure 6.3a below

shows the result of this test. It is clearly seen that the noise floor was in the ­90db to ­80db range

and the signal was measured between ­40db and ­50db. This resulted in signal quality of

approximately 44%.

Page 46

The next test was performed on the drone with a modified MMCX connector and an

external antenna connected to the coaxial cable. The drone was turned on and placed at the

same distance as in the previous experiment. Figure 6.3b below shows the result of this test.

The figure shows that the signal measurements were almost identical as in the previous test.

The noise floor was still in the ­90db to ­80 range and the signal strength was measured between

­40db and ­50db resulting in an overall signal quality of 45%.

Page 47

The next step was to test the amount of attenuation that the signal can experience

without losing connectivity with the drone. This was accomplished by a simple experiment which

consisted of measuring signal strength with a laptop at different distances from the drone. The

experiment began with measuring the signal strength at approximately 15 meters away and then

slowly closing the gap until the laptop was placed right next to the drone, approximately 0.5

Page 48

meters from the drone. The resulting graph is shown in figure 6.3c below. Note that the signal

strength was at approximately ­55db at 15 meters and then slowly increased to ­16db at 0.5

meters. The drone did not lose connectivity during this test. Based on these results a ­15db

attenuator was selected in order to provide a signal with a safe amplitude over the wired coaxial

connection. Since the maximum signal strength measured at ­16db, the wired connection with a

­15db attenuator would result in a signal of approximately ­31db. The previous tests confirm that

this would be enough signal strength for our application without risking any component damage.

Page 49

6.4 Attenuator Circuit

The next step in the implementation process was to test the wired connection with a USB

Wi­Fi dongle that would be later used on the Raspberry Pi. Since the attenuator selected for this

purpose had to be ordered, a temporary solution was put in place which consisted of linking

multiple smaller attenuators in series in order to achieve ­15db of signal attenuation. The

Page 50

components the team had access to were not ideal and some custom connectors had to be

made. Figure 6.4a below show the individual components that were required to construct a

series circuit that would provide the desired attenuation. Figure 6.4b below shows the attenuator

circuit attached to the drone through the coaxial cable ready to be tested with a USB Wi­Fi

dongle.

6.5 Testing and Verification

The next step was to verify that the attenuator circuit works and that the drone was still

able to send and receive information to and from the USB Wi­Fi dongle. In order to test this

functionality the USB Wi­Fi dongle was simply connected to a computer with a wireless adapter

software installed in order to identify any networks available. Figure 6.5a below shows the result

of this test. Note that the drone’s network name is shown as “Anikan” and that the signal quality

is at 100% due to the low noise floor in the wired connection. In order to confirm that the signal

was not being transmitted wirelessly, the coaxial cable was disconnected after which the

network “Anikan” became unavailable.

Page 51

6.6 Chapter Summary

This section outlines the process of installation and testing of the wired Wi­Fi connection

on the AR.Drone. The team was able to remove the drone’s main board in order to identify the

RF test point and to disable the onboard antenna, install a new MMCX RF connector onto the

drone’s RF test point in order to achieve a strong wired connection through a coaxial cable, and

to construct an attenuator circuit in order to provide a signal that is strong enough to

communicate with the drone but not too strong in order to prevent any component damage. After

all physical modification was done, a series of tests were performed in order to verify the

connectivity over the coaxial cable.

Page 52

7.0 Systems Integration

7.1 Integration Overview

This section of the report outlines the process of integration of each subsystem

described in previous sections into a fully automated drone system. Since each subsystem was

previously tested and verified for functionality, the main goal of the system integration phase was

to develop a main python script that would run on the drone’s Raspberry Pi in order to monitor all

processes to make sure that the drone has all of the necessary information in order to perform

specific tasks. This section of the report will describe how automatic script execution and the

drone’s main program was developed in order to finalize the project.

7.2 Automatic Script Execution

Up until this point in the project, all of the python scripts written to control individual

subsystems were launched manually by the user either from command line or from the desktop

of each of the Raspberry Pis. In order to achieve full automation these processes needed to be

launched automatically without any user interaction. In order to achieve that there were a few

minor changes that needed to be made to the startup process of the Linux operating system on

both Raspberry Pis.

The first change that was done to both devices was removing the user login

requirements. When any operating system is installed on the Raspberry Pi the default setting

forces the user to login with a login and password. The Raspberry Pi cannot execute any

additional code until the user provides valid login information. Figure 7.2s below shows the steps

Page 53

that were taken in order to remove the login requirement on boot up of the device. Note that this

process was the same for both devices, the drone and the transmitter pad.

With the login requirement removed it was time to implement a way to execute the python

scripts as soon as the device finished booting up. For the transmitter pad the script that would

execute on startup was already written. Since the only purpose of the transmitter pad was to

send over an instruction file over a Bluetooth connection, the script that would run on startup

was the Bluetooth server script from appendix 9.1. Note that the script runs inside an infinite

while loop so that the device constantly tries to connect to the drone. This helps in case of a

Page 54

missed connection or if the drone is out of range. However, for the drone Raspberry Pi, a new

script had to be written because the drone’s Raspberry Pi would handle more than just one type

of work. This script was called the main drone program and will be discussed in detail in the

following section of this report.

Unfortunately the Raspberry Pi is unable to launch python scripts on startup, however it

can launch shell files. In order to launch a python file as soon as the system finished booting, a

shell file had to be written in order to tell the operating system which files to launch. This was

simply done by telling the operating system where the file is and making a few adjustments to

the startup procedure. First, the launcher shell script was written. Both launcher files for the

drone and the transmitter pad are shown in figures 7.2b and 7.2c below. Note that the scripts

simply change the directory to locate the files and after launching the files they return to the root

directory.

The next step was to execute both shell scripts on startup. The Raspberry Pi uses a file

called crontab when performing its startup procedure. The crontab file is read every time the

Page 55

system is restarted so all that needed to be done was to put a simple command inside the

crontab file to execute the shell script [ref7.2b]. After the modification was done, the crontab file

was saved and the Raspberry Pi was restarted. Note that once the file launches it does not

provide any visual feedback to notify the user that it is being executed. The file is executed in the

background and printing to console is not available.

7.3 Main Drone Program

The next step in the system integration process was to develop a main drone program

that would combine all of the subsystems described earlier in the report. The main program

consists of two parts, the initialization and the main system loop. The initialization stage is

responsible for setting any parameters what will be used later in the program as well as

connecting to the drone’s network. The main system loop performs multiple tasks, such as

finding the Bluetooth transmitter pad, translating of text instructions into actual drone flight

operations, finalizing instruction execution as well as monitoring other properties in order to keep

the system efficient. Each individual section will be explained in detail in the sections below. The

full implementation of the main drone program is shown in appendices 9.6 and 9.7.

7.3.1 Initialization Stage

The first stage in the main drone program is the initialization stage. This stage prepares

all parameters and objects that will be used in the rest of the program. The initialization stage

creates and initializes objects that will be responsible for connecting to the drone’s wireless

network, connecting to Bluetooth devices, reading the instruction set file, as well as controlling

the drone’s movements. This stage also defines a couple of functions that handle text instruction

execution and emergency landing. Note that the objects created in this stage are the same

Page 56

objects that were explained in the earlier sections of this report. These objects include autowifi,

BluetoothDroneClient, textRead and ARDrone from the Python ARDrone library.

7.3.2 Connecting to Drone’s Network

The first object used in the main drone program was the autowifi object. This object was

responsible for successfully connecting to the drone’s network. Once the object was created, its

functions were called in order to start scanning for available networks. If a network name was

found that matched any of the previously connected networks, the program would attempt

connecting to that network. If the connection failed, the program would continue scanning until a

successful connection was made. In order to make this process faster, the team has removed

all networks from the known network list and left only the one required by the drone. This made

sure that the drone program would attempt connecting only to the drone’s network and not any

other wireless networks that could be picked up by an accident. Once a network connection

was established, the drone program would move on to the next stage.

7.3.3 Transmitter Pad Bluetooth Detection

Detecting a transmitter pad was the first function performed by the main drone program

that was included in the main system loop. The main system loop included all of the functions

that needed to be performed each time the drone would start it is operational cycle from

connecting to Bluetooth to finishing executing instructions. This allowed for a continuous cycle

without any user interaction. The Bluetooth object would return true if the transmitter pad was

detected or false if it was not found. The drone would attempt connecting to the pad three times

and if it failed once again the drone would land to preserve battery life, after which it would

continue to attempt connecting while on the ground. Note that if the drone was attempting to

Page 57

connect after previously executing instruction it would attempt connecting to the next pad while

hovering. If the pad was present and the drone connected to it while hovering, it actually saved

battery life since taking off requires the most current because of the motors starting up and

working full speed in order to get the drone off the ground. The main drone program would not

continue until a successful connection was made. The instruction file would start sending shortly

after the connection was made.

7.3.4 Translating and Execution of Text Commands

The next step in the main system loop was executing flight control commands based on

the instruction file received in the previous stage. The first function performed by the text reader

object would check if the file actually contained instructions. If the function returned false,

meaning that the file was not empty, the program would continue. If the function detected that the

file was empty, it would return true and the program would skip over the rest of the loop and go

back to connecting to the transmitter pad in order to receive a new instruction file.

If the the instruction file was not empty, the program would move on to the next stage of

interpreting the text instructions into commands that would be understood by the drone object.

Note that for this part of the program it is assumed that the instruction file was written in the

correct format which is, as described earlier in the report, a three letter code followed by an

integer. The program is able to detect and handle an invalid three letter instruction code,

however placing codes and integers out of order would cause the program to fail.

The next job of the text reader object is to parse the contents of the text file into two

separate arrays. After the parsing functions complete, the first array would include all three letter

Page 58

instruction codes in order from first to last, and the second array would include all execution

times for each of the operations. This allowed the main drone program to access both the

instruction type and execution time quickly by calling both arrays’ content of the same index.

Once the two array were loaded, the program moved on to the next step, which was

another loop that would handle executing the instructions. The loop would iterate through the

length of both arrays in order to execute each instruction stored in the instructions array. For

each instruction there was another loop that would perform that instruction as many times as

specified by the execution time of that instruction. Note that at the end of each loop the system

would wait a second resulting in each instruction being executed for exactly the same amount of

seconds as specified by the execution time matching that instruction. Note that each time the

instruction is performed, the system loop also checks for the kill switch signal. If the drone were

to fly out of the signal’s range, the program would execute an emergency landing procedure.

This part of the system was not finished due to time constraints.

7.3.5 Finalizing Instruction Set Execution

Once the drone is done executing all of the instructions stored in the instructions array,

the instruction loop exits and the program continues to the next stage. In the next stage of the

program the drone erases the previous instruction file and the whole main system loop starts

over again by the drone looking for a signal from a transmitter pad. This step concludes the main

program loop. As stated earlier in the report, the drone will then wait for more instructions, and if

none are received within three attempts the drone will land.

Page 59

7.4 Testing and Verification

Testing the whole system was fairly simple since each of the subsystems were

previously tested and verified individually. Knowing that each subsystem was fully functional,

putting them together was simply a matter of making sure that the program written to combine all

subsystems was working properly. The system was first tested by manually launching the main

drone program in order to be able to troubleshoot it. As mentioned before, printing messages to

the console was not available while auto executing files on startup. Running the scripts manually

allowed for detailed information to be printed in each step of the main program. After the program

was troubleshooted and tweaked it was tested while running in the background on startup. The

program worked as expected and the system was fully functional. The system was again tested

with multiple different instruction files and everything worked as planned. This concluded the

testing and verification stage of the project.

7.5 Chapter Summary

In this chapter the team went through multiple stages of system integration and testing.

The previously developed subsystems were combined into a working product which was then

configured to perform tasks with full automation and no user input. With minor changes to the

main drone program, the team was able to test and verify the system and all of its features from

transmitting instruction files to execution of flight commands. The system integration was

successful and the main goal of automation was achieved.

Page 60

8.0 Conclusions and Future Improvements

8.1 System Conclusions

This section of the report outlines and explains in detail the results achieved throughout

the development process and how they compare to the initial goals and objectives stated at the

beginning of the project. The following sections will discuss results from the Bluetooth, GPS

navigation, and drone automation subsystems. Additionally, results from the hardware

modification will also be explained.

8.1.1 Bluetooth Conclusion

One of the main goals concerning the Bluetooth subsystem was to achieve fast

communication between the drone and the transmitter pad. This was needed in order for the

drone to be able to receive instructions while flying over the transmitter pad without stopping.

The reason for this goal was to conserve as much battery life as possible and since frequent

stops cause more battery usage, being able to download instructions while flying was a

desirable feature.

Class 1 Bluetooth devices used in this project have a range of approximately 100

meters. This means that the signal should be available in a circle of 200 meters in diameter.

Since the drone’s maximum speed of travel is 11 meters/second, this results to approximately

18 seconds allowed for file transmission at full speed. Note that this is a very extreme scenario

and was only used as a base measurement. Realistically, anything close to 18 seconds would

be a great result.

Page 61

Due to weather conditions, the team was unable to test the file transfer at full speed.

However, measuring the total time from the moment the drone started searching for the

Bluetooth signal of the transmitter pad to the moment that the instruction file was done

transferring could be done with the entire system placed indoors. The resulting execution times

varied anywhere from 15 to 25 seconds depending on the location of the devices and the

amount of other wireless devices in the area. Note that this result would probably be negatively

affected by the drone moving at high speeds and greater distances between the two devices.

Further testing would have to be done in order to make the system faster and more efficient.

Given the fact that only off­the­shelf components were used in this project, 15 to 25 seconds of

execution time from initial connection to completing a file transmission is a very good result.

8.1.2 GPS Conclusion

The main goal of the GPS system was to allow the drone to locate another transmitter

pad by using pre programmed GPS coordinates. Note that this part of the project was unfinished

due to weather conditions. The GPS module would have to be mounted on the drone and remain

outdoors in order to receive satellite data. Testing of the GPS subsystem simply did not work

indoors due to weak or no satellite signal. The functionality of the GPS will be expanded on in the

future improvements section below.

8.1.3 Drone Automation Conclusion

The main goal of the drone automation subsystem was to achieve full automation of the

drone’s flight path without any input from the user. The goal also included that the system would

have to be fully independent of any wireless signals in order to allow for greater operating

Page 62

ranges. The Python ARDrone library was ideal for this application since it allowed for full control

of the drone’s functions through software. Full automation was achieved by writing a python

script to control the drone’s movements based on instructions received from the instructions file.

Testing of the system resulted in the drone being able to perform movements such as hover,

land, turn left, turn right, move up, move down, move forward and move backward all by itself

without any user interaction. The results satisfied the main automation goal of this project.

8.1.4 Hardware Conclusion

Establishing Wi­Fi communication through a wired connection was one of the main goals

of this project in order to provide security to the system. Since the drone flight path was fully

automated, security was an important aspect. Wireless drones are very easy to take over with

third party devices resulting in total control of the drone. Providing a wired connection to handle

all communication protocols ensured that the signal quality was strong at all times as well as that

the drone could not be controlled sources other than the Raspberry Pi unit attached to the drone.

The results achieved by installing the MMCX RF connector and disabling the onboard

Wi­Fi antenna were better than expected. The wired connection provided a very low noise floor

and the signal strength was stable. There were still some wireless signals being picked up,

however their signal quality was very low and the amplitude was close to the noise floor levels.

This provided good security since an external signal of such low quality would not be able to

connect properly to the drone. This was simply tested by trying to connect to the drone with a

cellphone while the drone was already connected to the Raspberry Pi through a wired

connection. All connection attempts with a cellphone failed.

Page 63

8.2 Future Improvements

Due to a very broad application list for automated drones, this project could be easily

expanded with additional features. This section of the report outlines some of the possible future

improvements to the current automated drone system. Some features include finalizing and

verifying of the GPS algorithm as well as implementing a kill switch. These features would

provide additional functionality to the system making it more complete. Note that these are only

some of the suggested improvements. The system is very modular and could be expanded in

many different ways not described in this report.

8.2.1 GPS Algorithm

The GPS system implementation was already started during the development process of

the project. However, the GPS algorithm was not finished since the system had to be tested

multiple times in an outdoor environment. A working GPS algorithm would allow for the drone to

navigate itself from the first transmitter pad to any other transmitter pads in the system by using

predefined GPS coordinates. This would allow for much simpler instruction sets that would then

only require a set of coordinates instead of step by step instructions. Note that implementing

such system would require some modification to the way the instruction files are read as well as

the way the drone’s main system loop executes instructions. The nature of the drone’s flight

pattern would have to be calculated in real time by constantly checking its position relative to the

destination coordinates instead of performing a predefined set of instructions.

Page 64

8.2.2 Kill Switch

Another important future improvement is a kill switch. Kill switch is a subsystem that

would allow the user to instantly disable the drone in case of emergency. Current laws prohibit

fully automated drones to operate without any human interaction. This is strictly due to

unexpected situations that the drone may run in to. For example, if the drone was performing

some tasks in a residential area and the user provided a faulty instruction set, the drone could

easily travel in the wrong direction which could put people or property at risk of collision with the

drone. In these types of scenarios a kill switch would be activated by the user and the drone

would be instantly disabled in order to prevent any risky situations.

Page 65

9.0 Appendices

9.1 Bluetooth Pad Server Python Script

Page 66

9.2 Bluetooth Drone Client Python Script

Page 67

9.3 Text Reader Object Python Script

Page 68

9.4 Auto Wi‐Fi Object Python Script

Page 69

9.5 GPS Read Object Python Script

Page 70

9.6 Main Drone Program Initialization Stage

Page 71

9.7 Main Drone Program System Loop

Page 72

10.0 References

[ref1.1a] Amazon.com, 'Amazon Prime Air', 2015. [Online]. Available:

http://www.amazon.com/b?node=8037720011. [Accessed: 30­ Apr­ 2015].

[ref1.1b] Quiqui.me, 'QuiQui ­ Automated Drone Delivery Of Pharmacy Items', 2015. [Online].

Available: http://quiqui.me/. [Accessed: 30­ Apr­ 2015].

[ref1.1c] U. Bart Jansen, 'FAA unveils drone rules; Obama orders policy for agencies', USA

TODAY, 2015. [Online]. Available:

http://www.usatoday.com/story/news/2015/02/15/faa­drone­rule/23440469/. [Accessed: 30­ Apr­

2015].

[ref1.2a] CreateDJI, 'Spreading Wings S800 EVO ­ Unprecedented Stability | DJI', 2015.

[Online]. Available: http://www.dji.com/product/spreading­wings­s800­evo. [Accessed: 30­ Apr­

2015].

[ref1.2b] Airdog.com, 'AirDog ­ Auto­Follow drone for GoPro camera', 2015. [Online]. Available:

https://www.airdog.com/. [Accessed: 30­ Apr­ 2015].

[ref1.3a] J. Pleban, R. Band and R. Creutzburg, Hacking and securing the AR.Drone 2.0

quadcopter ­Investigations for improving the security of a toy, 1st ed. Brandenburg, Germany:

Department of Informatics and Media, 2015.

Page 73

[ref1.3b] GitHub, 'samyk/skyjack', 2013. [Online]. Available: https://github.com/samyk/skyjack.

[Accessed: 30­ Apr­ 2015].

[ref2.1a] Bbc.co.uk, 'BBC ­ dot.Rory: A 15 pound computer to inspire young programmers',

2015. [Online]. Available:

http://www.bbc.co.uk/blogs/legacy/thereporters/rorycellanjones/2011/05/a_15_computer_to_ins

pire_young.html. [Accessed: 30­ Apr­ 2015].

[ref2.1b] Broadcom.com, 'High Definition 1080p Embedded Multimedia Applications Processor ­

BCM2835 | Broadcom', 2015. [Online]. Available: http://www.broadcom.com/products/BCM2835.

[Accessed: 30­ Apr­ 2015].

[ref2.1c] Raspberrypi.org, 'New product launch! Introducing Raspberry Pi Model B+ | Raspberry

Pi', 2014. [Online]. Available:

https://www.raspberrypi.org/introducing­raspberry­pi­model­b­plus/. [Accessed: 30­ Apr­ 2015].

[ref2.1d] Raspberrypi.org, 'Raspberry Pi Compute Module: new product! | Raspberry Pi', 2014.

[Online]. Available: http://www.raspberrypi.org/raspberry­pi­compute­module­new­product/.

[Accessed: 30­ Apr­ 2015].

[ref2.1e] 'SMSC USB2.0 Hub and 10/100 Ethernet Controller Spec Sheet', 2015. [Online].

Available: http://ww1.microchip.com/downloads/en/DeviceDoc/9514.pdf. [Accessed: 30­ Apr­

2015].

Page 74

[ref2.1f] Raspbian.org, 'FrontPage ­ Raspbian', 2015. [Online]. Available:

http://www.raspbian.org/. [Accessed: 30­ Apr­ 2015].

[ref2.1g] Puppylinux.org, 'PuppyLinux: Puppi', 2015. [Online]. Available:

http://puppylinux.org/wikka/Puppi. [Accessed: 30­ Apr­ 2015].

[ref2.1h] Raspbmc.com, 'Raspbmc has evolved', 2015. [Online]. Available:

http://www.raspbmc.com/index.html. [Accessed: 30­ Apr­ 2015].

[ref2.1i] O. Staff, 'Raspberry Pi To Embrace RISC OS', Osnews.com, 2015. [Online]. Available:

http://www.osnews.com/story/25276/Raspberry_Pi_To_Embrace_RISC_OS. [Accessed: 30­

Apr­ 2015].

[ref2.1j] Raspberrypi.org, 'Oracle Java on Raspberry Pi | Raspberry Pi', 2013. [Online].

Available: https://www.raspberrypi.org/oracle­java­on­raspberry­pi/. [Accessed: 30­ Apr­ 2015].

[ref2.1k] Raspberrypi.org, 'Mathematica 10 – now available for your Pi! | Raspberry Pi', 2014.

[Online]. Available: https://www.raspberrypi.org/mathematica­10/. [Accessed: 30­ Apr­ 2015].

[ref2.1l] GitHub, 'jwhitehorn/pi_piper', 2015. [Online]. Available:

https://github.com/jwhitehorn/pi_piper. [Accessed: 30­ Apr­ 2015].

[ref2.1m] Pi.minecraft.net, 'Minecraft: Pi Edition Minecraft: Pi Edition updates and downloads',

2012. [Online]. Available: http://pi.minecraft.net/. [Accessed: 30­ Apr­ 2015].

Page 75

[ref2.2a] Ardrone2.parrot.com, 'AR.Drone 2.0. Parrot new wi­fi quadricopter­ Specifications',

2015. [Online]. Available: http://ardrone2.parrot.com/ardrone­2/specifications/. [Accessed: 30­

Apr­ 2015].

[ref2.3a] Bluetooth.com, 'Fast Facts Bluetooth Technology Website', 2015. [Online]. Available:

http://www.bluetooth.com/Pages/Fast­Facts.aspx. [Accessed: 30­ Apr­ 2015].

[ref2.3b] Bluetooth.com, 'Basics Bluetooth Technology Website', 2015. [Online]. Available:

http://www.bluetooth.com/Pages/Basics.aspx. [Accessed: 30­ Apr­ 2015].

[ref2.3c] Kioskea, 'Bluetooth ­ How it works', 2015. [Online]. Available:

http://en.kioskea.net/contents/69­bluetooth­how­it­works. [Accessed: 30­ Apr­ 2015].

[ref2.3d] [9]W. Stallings, 'Piconets and Scatternets Introduction to Bluetooth | InformIT',

Informit.com, 2015. [Online]. Available:

http://www.informit.com/articles/article.aspx?p=23760&seqNum=4. [Accessed: 30­ Apr­ 2015].

[ref2.4a] Webopedia.com, 'What is Wi­Fi (IEEE 802.11x)? Webopedia', 2015. [Online]. Available:

http://www.webopedia.com/TERM/W/Wi_Fi.html. [Accessed: 30­ Apr­ 2015].

[ref2.4b] Standards.ieee.org, 'IEEE­SA ­IEEE Get 802 Program ­ 802.11: Wireless LANs', 2015.

[Online]. Available: http://standards.ieee.org/about/get/802/802.11.html. [Accessed: 30­ Apr­

2015].

Page 76

[ref2.4c] Cecs.wright.edu, 'Hacking Techniques in Wireless Networks', 2015. [Online]. Available:

http://cecs.wright.edu/~pmateti/InternetSecurity/Lectures/WirelessHacks/Mateti­WirelessHacks.

htm. [Accessed: 30­ Apr­ 2015].

[ref3.2a] W. Antenna, 'ModMyPi | WiFi Dongle ­ Ultra Long Range High Gain w/ 5dBi Antenna',

Modmypi.com, 2015. [Online]. Available:

http://www.modmypi.com/raspberry­pi/accessories/wifi­dongles/wifi­dongle­ultra­long­range­high

­gain­w­5dbi­antenna. [Accessed: 30­ Apr­ 2015].

[ref4.1a] Developer.bluetooth.org, 'Logical Link Control and Adaptation Protocol | Bluetooth

Development Portal', 2015. [Online]. Available:

https://developer.bluetooth.org/TechnologyOverview/Pages/L2CAP.aspx. [Accessed: 30­ Apr­

2015].

[ref4.2.1a] People.csail.mit.edu, 'Communicating with L2CAP', 2015. [Online]. Available:

http://people.csail.mit.edu/albert/bluez­intro/x264.html. [Accessed: 30­ Apr­ 2015].

[ref4.2.2a] Bluetoothinsight.blogspot.com, 'Bluetooth Power Classes: Class 1, 2 and 3', 2008.

[Online]. Available: http://bluetoothinsight.blogspot.com/2008/01/bluetooth­power­classes.html.

[Accessed: 30­ Apr­ 2015].

[ref5.1a] GitHub, 'venthur/python­ardrone', 2014. [Online]. Available:

https://github.com/venthur/python­ardrone. [Accessed: 30­ Apr­ 2015].

Page 77

[ref5.4a] T. others, 'Adafruit Ultimate GPS Breakout ­ 66 channel w/10 Hz updates [Version 3]

ID: 746 ­ $39.95 : Adafruit Industries, Unique & fun DIY electronics and kits', Adafruit.com, 2015.

[Online]. Available: https://www.adafruit.com/products/746. [Accessed: 30­ Apr­ 2015].

[ref5.4b] T. others, 'USB to TTL Serial Cable ­ Debug / Console Cable for Raspberry Pi ID: 954 ­

$9.95 : Adafruit Industries, Unique & fun DIY electronics and kits', Adafruit.com, 2015. [Online].

Available: https://www.adafruit.com/products/954. [Accessed: 30­ Apr­ 2015].

[ref7.2a] Elinux.org, 'RPi Debian Auto Login ­ eLinux.org', 2015. [Online]. Available:

http://elinux.org/RPi_Debian_Auto_Login. [Accessed: 30­ Apr­ 2015].

[ref7.2b] Instructables.com, 'Raspberry Pi: Launch Python script on startup', 2015. [Online].

Available: http://www.instructables.com/id/Raspberry­Pi­Launch­Python­script­on­startup.

[Accessed: 30­ Apr­ 2015].

Page 78

Enhanced Data Rate Bluetooh USB Adapter (GBU321)Class 1 Bluetooth 2.0 USB Adapter

Model # GBU321

Description

IOGEAR's Bluetooth USB Adapter with EDR (Enhanced Data Rate) technology deliver faster wireless data transfer speed, improved bandwidth and draw less power than ever before. Now when you add Bluetooth wireless technology to your desktop or notebook PC or Mac, you'll be able to wirelessly transfer photos from your Bluetooth camera phone to your computer. You can also use your Bluetooth headset to make wireless Internet calls (Skype, MSN messenger, etc.)

You'll also be able to wirelessly connect up to seven Bluetooth devices together and transfer even the largest files quickly and easily due to greater bandwidth. And our new adapters' lower power consumption means longer battery life on your notebook computer. Just plug in an IOGEAR USB adapter with Bluetooth wireless technology and get your computer wirelessly sharing data with your Bluetooth-enabled mobile phone, PDA, stereo headphones, printer and more!

This Bluetooth Class 1 adapter is compatible with both Mac and PC computers, and offers a wireless range of 330 feet (100 meter). It is easy to install and use, and very portable. It's great for both home and mobile networking needs.

Features

Bluetooth specification 2.0 compliant to reduce interference with Wi-Fi devices Faster data transfer rates - up to 2.1Mbps USB specification 1.1 compliant Allows any computer with USB connections to become a Bluetooth-enabled computer Eliminates cables between your computers Wirelessly communicate with Bluetooth-enabled computers, printers, PDAs mobile phones, headsets and more Supports the following services: Serial Port, Network Access, Dial Up Networking, headset, AV, File Transfer,

Audio Gateway, HID Enables wireless Personal Area Network (PAN) connectivity Up to 330 feet (100 meters) wireless working distance Also compatible with Bluetooth Class 1 and 3 devices Small form factor makes it easy to carry and use Easy, fast, and intuitive installation and setup Built-in security to assure the privacy of your communication pairing, encryption, and authentication Mac and PC compatible

Function Diagram

Requirements

Hardware Requirement:

Available USB port

Operating System:

For PCs: Windows 2000/XP/Vista For Macs: MAC OS X v10.3.9 or later

Package Content

1 x Enhanced Data Rate Wireless USB Adapter 1 x USB extension cable 1 x Installation CD 1 x Installation Guide 1 x Warranty / Registration Card

Warranty 3-YEAR

Specifications

Function GBU321

Operating Temperature 0 C - 50 C

Humidity 10% - 100% non-condensing

Transmission Power 20 dBm max with power control (Class 1)

Frequency Band 2.402 GHz - 2.4835 GHz Unlicensed ISM band

Modulation GFSK (Gaussian Frequency Shift Keying)

Data Rate Up to 2.1Mbps

Interface USB

Sensitivity Minimum -76dBm

Security Pairing, Encryption, Authentication

Profiles SupportedGeneric Access, Serial Port, Dial-Up Networking, Fax, LAN, Object

Push, File Transfer, Synchronizati

Dimensions GBU321

Unit Dimensions

Width 1 in. (2 cm.)

Height 2.25 in. (5.5 cm.)

Depth 0.375 in. (1 cm.)

Unit Package Dimensions

Width 6.25 in. (15.88 cm.)

Height 2 in. (5.08 cm.)

Depth 8.125 in.

Master Carton

Width 10 in. (25.4 cm.)

Height 8 in. (20.32 cm.)

Depth 11 in. (27.94 cm.)

Master Carton Qty. 6

Weight

Master Carton Wt. 2.60 lbs. (1.18 kg.)

Unit Pack Wt. 0.24 lbs. (0.11 kg.)

© 2008 IOGEAR, Inc. All other trademarks belong to the respective owners.

This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior

permission of GlobalTop Tech Inc. Specifications subject to change without prior notice.

Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. No.16 Nan-ke 9

th Rd, Science-Based Industrial Park, Tainan, 741, Taiwan, R.O.C.

Tel: +886-6-5051268 / Fax: +886-6-5053381 / Email: sales@gtop-tech.com / Web: www.gtop-tech.com

Da

ta S

he

et

The FGPMMOPA6H is a 4th generation stand-alone GPS module with lightning fast TTFF, ultra high

sensitivity (-165dBm), and low power consumption in a small form factor (16*16*4.7mm)

GlobalTop Technology Inc.

FGPMMOPA6H

GPS Standalone Module

Data Sheet Revision: V0A

44

This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without

prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice.

Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved.

FGPMMOPA6H Data Sheet

GlobalTop Technology

Ver. V0A

Document #

1. Functional Description

1.1 Overview

The FGPMMOPA6H utilizes the MediaTek new generation GPS Chipset MT3339 that achieves the

industry’s highest level of sensitivity (-165dBm ) and instant Time-to-First Fix (TTFF) with lowest

power consumption for precise GPS signal processing to give the ultra-precise positioning under

low receptive, high velocity conditions.

The module a revision of POT (Patch On Top) GPS Module with an extra embedded function for

external antenna I/O and comes with automatic antenna switching function and short circuit

protection, also features a antenna system called “Antenna Advisor” that helps with the detections

and notifications of different antenna statuses, including active antenna connection, antenna open

circuit and antenna shortage.

Up to 12 multi-tone active interference canceller (ISSCC2011 award), customer can have more

flexibility in system design. Supports up to 210 PRN channels with 66 search channels and 22

simultaneous tracking channels, Module supports various location and navigation applications,

including autonomous GPS,QZSS, SBAS(note) ranging (WAAS, EGNO, GAGAN, MSAS), AGPS.

FGPMMOPA6H is excellent low power consumption characteristic (acquisition 82mW, tracking

66mW), power sensitive devices, especially portable applications, need not worry about operating

time anymore and user can get more fun.

Note: SBAS can only be enabled when update rate is less than or equal to 5Hz.

Application:

Handheld Device

Tablet PC/PLB/MID

M2M application

Asset management

Surveillance

55

This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without

prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice.

Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved.

FGPMMOPA6H Data Sheet

GlobalTop Technology

Ver. V0A

Document #

1.2 Highlights and Features

Built-in 15X15X2.5mm ceramic patch antenna on the top of module

Ultra-High Sensitivity: -165dBm (w/o patch antenna), up to 45dB C/N of SVs in open sky

reception.

High Update Rate: up to 10Hz(note1)

12 multi-tone active interference canceller(note2) [ISSCC 2011 Award -Section 26.5]

(http://isscc.org/doc/2011/isscc2011.advanceprogrambooklet_abstracts.pdf )

High accuracy 1-PPS timing support for Timing Applications (10ns jitter)

AGPS Support for Fast TTFF (EPO™ Enable 7 days/14 days )

EASY™(note2): Self-Generated Orbit Prediction for instant positioning fix

AlwaysLocate™(note2) Intelligent Algorithm (Advance Power Periodic Mode) for power saving

Logger function Embedded(note2)

Automatic antenna switching function

Antenna Advisor function

Gtop Firmware Customization Services

Consumption current(@3.3V):

• Acquisition: 25mA Typical

• Tracking: 20mA Typical

E911, RoHS, REACH compliant

note 1: SBAS can only be enabled when update rate is less than or equal to 5Hz.

note2: Some features need special firmware or command programmed by customer, please

refer to G-top “GPS command List”

66

This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without

prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice.

Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved.

FGPMMOPA6H Data Sheet

GlobalTop Technology

Ver. V0A

Document #

1.3 System Block Diagram

Product Name Raspberry Pi Model B+

Product Description The Raspberry Pi Model B+ incorporates a number of enhancements and new features. Improved power consumption, increased connectivity and greater IO are among the improvements to this powerful, small and lightweight ARM based computer.

Specifications

Chip Broadcom BCM2835 SoC

Core architecture ARM11

CPU 700 MHz Low Power ARM1176JZFS Applications Processor

GPU Dual Core VideoCore IV® Multimedia Co-Processor

Provides Open GL ES 2.0, hardware-accelerated OpenVG, and 1080p30 H.264 high-profile decode

Capable of 1Gpixel/s, 1.5Gtexel/s or 24GFLOPs with texture filtering and DMA infrastructure

Memory 512MB SDRAM

Operating System Boots from Micro SD card, running a version of the Linux operating system

Dimensions 85 x 56 x 17mm

Power Micro USB socket 5V, 2A

Connectors:

Ethernet 10/100 BaseT Ethernet socket

Video Output HDMI (rev 1.3 & 1.4)

Composite RCA (PAL and NTSC)

Audio Output 3.5mm jack, HDMI

USB 4 x USB 2.0 Connector

GPIO Connector 40-pin 2.54 mm (100 mil) expansion header: 2x20 strip

Providing 27 GPIO pins as well as +3.3 V, +5 V and GND supply lines

Camera Connector 15-pin MIPI Camera Serial Interface (CSI-2)

JTAG Not populated

Display Connector Display Serial Interface (DSI) 15 way flat flex cable connector with two data lanes and a clock lane

Memory Card Slot SDIO

MODEL B+