team08 final design report

8/9/2019 Team08 Final Design Report

1/221

Drew Brandsen

Robert Hoff

Spencer Olson

Jared Zoodsma

Engineering 339/340 Senior Design Project

Calvin College

May 15, 2014


2/221

2014, Drew Brandsen, Robert Hoff, Spencer Olson, Jared Zoodsma & Calvin College


3/221

EXECUTIVE SUMMARYSecurity is paramount for presidential motorcades, military convoys, and other safety critical

transport. Visibility is often impaired for those inside the vehicles, making it difficult to see allpossible threats ahead, behind, and to the sides. Lack of visibility creates a significant danger from

insurgents, rocket propelled grenades (RPGs), improvised explosive devices (IEDs), and otherthreats. Moreover, travel routes can span hundreds of miles. Covering these routes with explosivedetectors, bomb-sniffing dogs, and law enforcement is very costly and requires extra labor.Improving visibility for individuals in the vehicles can help mitigate these external risks

The solution our team of four electrical and computer engineers has chosen consists of twosubsystems: one to fly above the vehicle and a second installed inside the vehicle. We consideredvarious options for the first subsystem and chose a quadcopter because of its high expandability,maneuverability, and stability. The quadcopter is equipped with video capture equipment, as well asa global positioning system (GPS) receiver. Second, a base station located in the vehicle includes acomputer, Wi-Fi router, GPS receiver, radio controlled (RC) transmitter, and RC interfacemodule. The base station also contains a graphical user interface (GUI) that receives the video

streamed from the quadcopter and provides a way for the user to interact with the system.The design process entailed building a quadcopter and expanding it to fit the project

specifications. Some of the key specifications were providing a video stream of the vehicle and itssurroundings, being small enough to fit the entire system in the vehicle, and being able to track thevehicle autonomously. This involved adding both a camera and a Raspberry Pi development boardto the quadcopter in order to capture and send the quadcopters GPS location and video stream overWi-Fi to the base station below. The base station computer, with the assistance of an Arduinomicrocontroller, used the GPS data in order to autonomously control the quadcopter via RC.

The Eagleye team showed the feasibility of this solution through first semester research andpreliminary designs. Following this, the team designed a working prototype in the second semester.The team operated under a budget of $1455 in order to complete this work. The team hopes that the

work done on this project will increase awareness of unmanned aerial vehicles (UAVs) and theirbeneficial applications.


4/221

ii

TABLE OF CONTENTS1 INTRODUCTION ................................................................................................................................. 1

1.1 CALVIN COLLEGE ENGINEERING DEPARTMENT ............................................................................... 11.2 TEAM MEMBER BIOGRAPHIES ......................................................................................................... 1

1.2.1 Jared Zoodsma ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... .......... ........ 21.2.2 Robert Hoff .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... .... 21.2.3 Drew Brandsen............. .......... ........... .......... ........... .......... .......... ........... .......... .......... ........... ...... 21.2.4 Spencer Olson ............................................................................................................................ 2

1.3 REPORT FORMAT ............................................................................................................................. 21.4 DESIGNNORMS................................................................................................................................ 3

1.4.1 Transparency ............................................................................................................................. 31.4.2 Justice........... ........... .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... .......... . 31.4.3 Trust ........................................................................................................................................... 3

1.5 ACKNOWLEDGEMENTS .................................................................................................................... 3

2 PROJECT REQUIREMENTS ............................................................................................................. 5

2.1 PROBLEM STATEMENT ..................................................................................................................... 5

2.1.1 Solution ...................................................................................................................................... 52.1.2 Target Customers ....................................................................................................................... 5

2.2 CUSTOMER REQUIREMENTS ............................................................................................................. 52.2.1 Performance ......... ........... ........... .......... ........... .......... .......... ........... .......... ........... .......... ........... .. 52.2.2 Physical .......... ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... ........... ....... 92.2.3 Customer ................................................................................................................................... 9

2.3 DELIVERABLES .............................................................................................................................. 11

3 SYSTEM DESIGN ............................................................................................................................... 12

3.1 DECISION MATRIX ......................................................................................................................... 123.1.1 Possible Solutions ............... .......... ........... .......... ........... .......... .......... ........... .......... ........... ....... 123.1.2 Decision Criteria and Justification .................. ........... .......... ........... .......... ........... .......... ......... 153.1.3 Justification .......... ........... ........... .......... ........... .......... .......... ........... .......... ........... .......... ........... 16

3.1.4 Best Solution ........ ........... ........... .......... ........... .......... .......... ........... .......... ........... .......... ........... 213.2 OVERALL SYSTEM BLOCK DIAGRAM ............................................................................................. 21

3.2.1 Hardware ............ ........... ........... .......... ........... .......... .......... ........... .......... ........... .......... ........... 213.2.2 Software ................................................................................................................................... 23

3.3 FEATURE MATRIX .......................................................................................................................... 253.3.1 Feature Descriptions ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... ....... 26

3.4 FEATURE RESULTS ......................................................................................................................... 293.4.1 Feature Descriptions ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... ....... 29

4 QUADCOPTER DESIGN ................................................................................................................... 31

4.1 QUADCOPTER ARCHITECTURE ....................................................................................................... 314.2 QUADCOPTER COMPONENTS .......................................................................................................... 34

4.2.1 Flight Controller .......... .......... ........... .......... ........... .......... .......... ........... .......... .......... ........... .... 35

4.2.2 GPS Module ............................................................................................................................. 394.2.3 Propellers .......... ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... .......... .... 404.2.4 Motors .......... ........... .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... ......... 414.2.5 ESCs .......... .......... ........... .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... .. 424.2.6 Battery .......... ........... .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... ......... 434.2.7 Power Distribution System .......... ........... .......... ........... .......... ........... .......... ........... .......... ......... 464.2.8 Frame and Landing Gear ........... .......... ........... .......... .......... ........... .......... ........... .......... ........... 474.2.9 VGPU ....................................................................................................................................... 494.2.10 Camera ................................................................................................................................... 57


5/221

iii

5 BASE STATION DESIGN .................................................................................................................. 59

5.1 BASE STATION ARCHITECTURE ..................................................................................................... 595.2 BASE STATION COMPONENTS ........................................................................................................ 62

5.2.1 Base Station Computer ......... ........... .......... ........... .......... ........... .......... ........... .......... .......... ...... 625.2.2 RC Interface Module ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... ....... 695.2.3 RC Transmitter ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... .......... ...... 82

5.2.4 GPS Module ............................................................................................................................. 835.2.5 Wireless Router ........................................................................................................................ 85

6 SYSTEM INTEGRATION AND TESTING ..................................................................................... 87

6.1 TELEMETRY STREAMING ............................................................................................................... 876.1.1 Test: Full System Communication ............................................................................................ 876.1.2 Test: Communication with Live Telemetry Coordinates .......................................................... 876.1.3 Communication Latency ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... .. 88

6.2 VIDEO STREAMING ........................................................................................................................ 896.2.1 Video Latency ........................................................................................................................... 896.2.2 Video Quality ........................................................................................................................... 90

6.3 GPSTRACKING ............................................................................................................................. 916.3.1 Stationary GPS Precision......................................................................................................... 91

6.3.2 Moving GPS Precision ......... ........... .......... ........... .......... ........... .......... ........... .......... .......... ...... 926.4 RCCONTROL VIA RCINTERFACE MODULE ................................................................................... 95

6.4.1 RC Pass Through ................. ........... .......... ........... .......... ........... .......... ........... .......... .......... ...... 956.4.2 Pitch and Roll Recording ........... .......... ........... .......... .......... ........... .......... ........... .......... ........... 956.4.3 Steps ......................................................................................................................................... 966.4.4 Autonomous Pitch and Roll Start .................... .......... .......... ........... .......... ........... .......... ........... 966.4.5 Autonomous Pitch Stop ............... ........... .......... ........... .......... ........... .......... ........... .......... ......... 97

6.5 TRACKING ALGORITHM ................................................................................................................. 976.5.1 RC Response Test .......... ........... .......... ........... .......... ........... .......... ........... .......... .......... ........... .. 976.5.2 Motor Response Test ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... ....... 986.5.3 North-Facing Flight Tracking ........... .......... ........... .......... .......... ........... .......... ........... .......... .... 996.5.4 Orientation Tracking ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... ..... 100

7 PROJECT MANAGEMENT ............................................................................................................ 103

7.1 DOCUMENTATION ORGANIZATION .............................................................................................. 1037.1.1 Code ....................................................................................................................................... 1037.1.2 Design Journals .............. ........... .......... ........... .......... .......... ........... .......... .......... ........... ......... 1037.1.3 Manuals .......... .......... ........... .......... ........... .......... .......... ........... .......... ........... .......... ........... ..... 1037.1.4 Media ............. .......... ........... .......... ........... .......... .......... ........... .......... ........... .......... ........... ..... 1037.1.5 Miscellaneous Notes .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... ....... 1037.1.6 Planning Documents ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... ..... 1037.1.7 Status Reports ........................................................................................................................ 1047.1.8 Team 08: Turn-in ................................................................................................................... 1047.1.9 Tests ....................................................................................................................................... 104

7.2 TEAM ORGANIZATION ................................................................................................................. 1047.2.1 Technical Assignments (Design Areas) .................................................................................. 1047.2.2 Management Assignments .......... .......... ........... .......... .......... ........... .......... ........... .......... ......... 1067.2.3 Working Guidelines ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... ....... 1067.2.4 Safety Guidelines .................................................................................................................... 1077.2.5 Team Communication and Accountability ............................................................................. 107

7.3 SCHEDULE AND WORK BREAKDOWN SCHEDULE ......................................................................... 1077.3.1 Hours Summary .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... .......... .... 1077.3.2 Milestones .............. ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... ....... 108

7.4 OPERATIONAL BUDGET ............................................................................................................... 1097.4.1 Project Costs .......... ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... ....... 109


6/221

iv

7.4.2 Summary................................................................................................................................. 1107.4.3 Sources of Funding ................................................................................................................ 110

7.5 METHOD OF APPROACH ............................................................................................................... 1107.5.1 Design Methodology .............. ........... .......... ........... .......... .......... ........... .......... .......... ........... .. 1107.5.2 Research Techniques ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... ..... 110

8 BUSINESS PLAN .............................................................................................................................. 111

8.1 OVERVIEW ................................................................................................................................... 1118.2 VISION AND MISSION STATEMENT ............................................................................................... 1118.3 VISION FOR THE COMPANY .......................................................................................................... 1118.4 VALUES AND PRINCIPLES ON WHICH THE BUSINESS STANDS ....................................................... 1118.5 MARKETING STUDY ..................................................................................................................... 111

8.5.1 How Large is the Market? .......... .......... ........... .......... .......... ........... .......... ........... .......... ......... 1118.5.2 Is it Growing or Shrinking? ........ ........... .......... ........... .......... ........... .......... ........... .......... ....... 1128.5.3 Regulatory Restrictions .......... ........... .......... .......... ........... .......... ........... .......... ........... .......... .. 1128.5.4 Barriers to Entry and Exit .......... .......... ........... .......... .......... ........... .......... ........... .......... ......... 1128.5.5 Key Success Factors in the Industry .......... ........... .......... ........... .......... ........... .......... .......... .... 112

8.6 COMPETITION .............................................................................................................................. 1128.6.1 Existing Competitors ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... ..... 1128.6.2 Potential Competitors .......... ........... .......... ........... .......... ........... .......... ........... .......... .......... .... 113

8.7 BUSINESS MODEL ........................................................................................................................ 1148.7.1 Desired Image and Position in the Market...... .......... ........... .......... .......... ........... .......... ......... 1148.7.2 Company Goals and Objectives ............................................................................................. 1148.7.3 SWOT Analysis ....................................................................................................................... 1148.7.4 Competitive Strategy .............................................................................................................. 115

8.8 FINANCIAL FORECASTS ................................................................................................................ 1168.8.1 Key Assumptions ................. .......... ........... .......... ........... .......... .......... ........... .......... ........... ..... 1168.8.2 Financial Statements ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... ..... 1178.8.3 Break-Even Analysis ................ .......... ........... .......... ........... .......... ........... .......... .......... ........... 1198.8.4 Ratio Analysis ........ ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... ....... 119

8.9 SUMMARY.................................................................................................................................... 120

9 CONCLUSION .................................................................................................................................. 121

9.1 PROJECT RESULTS ....................................................................................................................... 1219.1.1 Overall ................................................................................................................................... 1219.1.2 Final Costs .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... 1219.1.3 Time Spent .............................................................................................................................. 121

9.2 FUTURE WORK ............................................................................................................................ 1219.3 SUMMARY.................................................................................................................................... 122


7/221

v

TABLE OF FIGURES

FIGURE 1:TEAM PHOTO -JARED ZOODSMA,DREW BRANDSEN,ROBERT HOFF,AND SPENCER OLSON. ........................ 1FIGURE 2:2-DHORIZONTAL DISTANCE REQUIREMENT FOR PROTOTYPE 1.0 ................................................................. 6FIGURE 3:QUADCOPTER OUTFITTED WITH CAMERAS ................................................................................................. 12

FIGURE 4:RCHELICOPTER .......................................................................................................................................... 13FIGURE 5:RCAIRPLANE .............................................................................................................................................. 13FIGURE 6:RCBLIMP .................................................................................................................................................... 14FIGURE 7:PANORAMIC BALL CAMERA ........................................................................................................................ 14FIGURE 8:CONTROL OF A QUADCOPTER ..................................................................................................................... 18FIGURE 9:PLATFORM AREA OF A QUADCOPTER .......................................................................................................... 20FIGURE 10:OVERALL SYSTEM HARDWARE BLOCK DIAGRAM ..................................................................................... 22FIGURE 11:OVERALL SOFTWARE SYSTEM BLOCK DIAGRAM ...................................................................................... 24FIGURE 12:QUADCOPTER PROTOTYPE 1.0 ................................................................................................................... 31FIGURE 13:QUADCOPTER HARDWARE BLOCK DIAGRAM ............................................................................................ 32FIGURE 14:QUADCOPTER SOFTWARE BLOCK DIAGRAM.............................................................................................. 33FIGURE 15:CENTRAL QUADCOPTER COMPONENTS ...................................................................................................... 34FIGURE 16:COMPASS VALUES WITH HEADING-HOLD MODE ....................................................................................... 38FIGURE 17:PROTOTYPE 1.0MOTOR DIRECTION .......................................................................................................... 42FIGURE 18:PROTOTYPE 1.0FLIGHT TIMES WITH VARIOUS BATTERY SIZES ................................................................. 45FIGURE 19:BROKEN ARM ............................................................................................................................................ 48FIGURE 20:PROPELLER GUARDS WITH VIBRATION PROBLEMS (PROTOTYPE 0.2) ........................................................ 48FIGURE 21:FINAL PROPELLER GUARD IMPLEMENTATION (PROTOTYPE 1.0) ............................................................... 49FIGURE 22:CUSTOM VGPULAYOUT ........................................................................................................................... 50FIGURE 23:VGPUSOFTWARE BLOCK DIAGRAM ......................................................................................................... 52FIGURE 24:RASPBERRY PI DIGITAL I/OPINS ............................................................................................................... 56FIGURE 25:MULTIWII SERIAL PROTOCOL ................................................................................................................... 56FIGURE 26:MULTIWII PRO CONNECTION .................................................................................................................... 57FIGURE 27:FINAL BASE STATION IMPLEMENTATION ................................................................................................... 59FIGURE 28:BASE STATION HARDWARE BLOCK DIAGRAM ........................................................................................... 60FIGURE 29:BASE STATION SOFTWARE BLOCK DIAGRAM ............................................................................................ 61FIGURE 30:BASE STATION COMPUTER SOFTWARE BLOCK DIAGRAM ......................................................................... 63

FIGURE 31:FINAL GUI ................................................................................................................................................. 65FIGURE 32:RCINTERFACE MODULE HARDWARE BLOCK DIAGRAM ........................................................................... 69FIGURE 33:CUSTOM RCINTERFACE MODULE LAYOUT ............................................................................................... 71FIGURE 34:FILTER BOARD CIRCUIT ............................................................................................................................. 74FIGURE 35:RCINTERFACE MODULE OUTPUT DIAGRAM ............................................................................................. 75FIGURE 36:FILTER BOARD LAYOUT ............................................................................................................................ 76FIGURE 37:FILTER BOARD PHOTO ............................................................................................................................... 76FIGURE 38:RCINTERFACE MODULE SOFTWARE BLOCK DIAGRAM............................................................................. 77FIGURE 39:DISTANCE DEPENDENT SPEED METHOD .................................................................................................... 80FIGURE 40:ORIENTATION TRACKING ........................................................................................................................... 81FIGURE 41:RCINTERFACE MODULE EXTERNAL PHOTO .............................................................................................. 84FIGURE 42:RCINTERFACE MODULE INTERNALS ......................................................................................................... 84FIGURE 43:VIDEO LATENCY RESULTS ......................................................................................................................... 90

FIGURE 44:VIDEO PROTOCOL QUALITY SCORES ......................................................................................................... 91FIGURE 45:MOVING GPSPRECISION TEST (22.35M/S,10HZ) .................................................................................... 93FIGURE 46:MOVING GPSPRECISION TEST (16.9M/S,10HZ) ...................................................................................... 94FIGURE 47:ORIENTATION FLIGHT TEST ..................................................................................................................... 101FIGURE 48:GRAPH OF HOURS WORKED ON PROJECT ................................................................................................. 108


8/221

vi

TABLE OF TABLES

TABLE 1:PROJECT DELIVERABLES ............................................................................................................................... 11TABLE 2:DECISION MATRIX ........................................................................................................................................ 15TABLE 3:SYSTEM HARDWARE BLOCK DIAGRAM INTERFACE DESCRIPTIONS .............................................................. 22

TABLE 4:SYSTEM SOFTWARE BLOCK DIAGRAM INTERFACE DESCRIPTIONS ............................................................... 24TABLE 5:SYSTEM PROTOCOL DEFINITIONS ................................................................................................................. 25TABLE 6:FEATURE MATRIX ......................................................................................................................................... 25TABLE 7:FEATURE MATRIX IMPLEMENTATION ........................................................................................................... 29TABLE 8:QUADCOPTER HARDWARE BLOCK DIAGRAM INTERFACE DESCRIPTIONS ..................................................... 32TABLE 9:QUADCOPTER SOFTWARE BLOCK DIAGRAM INTERFACE DESCRIPTIONS ...................................................... 34TABLE 10:FLIGHT CONTROLLER ALTERNATIVES ........................................................................................................ 35TABLE 11:ALTITUDE-HOLD TESTS WITH CONTROL AND FOAM COVERS (METERS) ..................................................... 36TABLE 12:BATTERY COMPARISONS............................................................................................................................. 44TABLE 13:BATTERY CAPACITIES AND FLIGHT TIMES .................................................................................................. 45TABLE 14:COMPONENT POWERNEEDS ....................................................................................................................... 46TABLE 15:VGPUSOFTWARE BLOCK DIAGRAM INTERFACE DESCRIPTIONS ............................................................... 52TABLE 16:VGPUPROTOCOLS ..................................................................................................................................... 52TABLE 17:BASE STATION HARDWARE INTERFACE DESCRIPTIONS .............................................................................. 60TABLE 18:BASE STATION SOFTWARE BLOCK DIAGRAM INTERFACES ......................................................................... 62TABLE 19:BASE STATION SOFTWARE PROTOCOLS ...................................................................................................... 62TABLE 20:BASE STATION COMPUTER SOFTWARE BLOCK DIAGRAM INTERFACES ...................................................... 64TABLE 21:GUISOFTWARE PROTOCOLS ...................................................................................................................... 64TABLE 22:RCINTERFACE MODULE HARDWARE BLOCK DIAGRAM INTERFACES ........................................................ 69TABLE 23:RCINTERFACE MODULE DEVELOPMENT BOARD ALTERNATIVES .............................................................. 70TABLE 24:RCINTERFACE MODULE SOFTWARE BLOCK DIAGRAM INTERFACE DESCRIPTIONS................................... 78TABLE 25:ANOTHER GPSSTATIONARY RESULT (10HZ) ............................................................................................ 92TABLE 26:MOVING GPSPRECISION TEST (1HZ) ........................................................................................................ 93TABLE 27:MOVING GPSPRECISION TEST (22.35M/S,10HZ) ..................................................................................... 94TABLE 28:MOVING GPSPRECISION TEST (16.9M/S,10HZ) ....................................................................................... 94TABLE 29:EXPECTED REACTIONS TO POSITION CHANGES ........................................................................................... 98TABLE 30:DESIGN AREAS AND TEAM MEMBER ASSIGNMENTS ................................................................................. 105

TABLE 31:SUMMARY OF HOURS ................................................................................................................................ 107TABLE 32:TEAM 08:EAGLEYE BUDGET .................................................................................................................... 109TABLE 33:SUPPORTING CALCULATIONS .................................................................................................................... 117TABLE 34:INCOME STATEMENT ................................................................................................................................. 118TABLE 35:CASH FLOW STATEMENT .......................................................................................................................... 118TABLE 36:BREAK-EVEN ANALYSIS ........................................................................................................................... 119TABLE 37:RATIO ANALYSIS ...................................................................................................................................... 120


9/221

vii

TABLE OF ACRONYMS

ABET: Accreditation Board for Engineering and TechnologyAPI: Application programming interfaceAPM: ArduPilot Mega

BEC: Battery Eliminator CircuitESC: Electronic Speed Controller

FPS: Frames per SecondGPS: Global Positioning SystemGUI: Graphical User InterfaceHD: High DefinitionIED: Improvised Explosive DeviceI/O: Input/OutputIR: InfraredKv: Revolutions per Minute / VoltMSP: MultiWii Serial ProtocolMW: MultiWii

NMEA: National Marine Electronics AssociationPCB: Printed Circuit Board

PID: Proportional-Integral-DerivativePPFS: Project Proposal and Feasibility StudyPPS: Picture Parameter SetPWM: Pulse Width ModulationOS: Operating SystemQ&A: Question and AnswerRAM: Random Access MemoryRC: Radio ControlledRPG: Rocket Propelled GrenadeSD: Standard Definition

SPS: Sequence Parameter SetSSH: Secure Shell

SWOT: Internal Strengths and Weaknesses, External Opportunities and Threats.TCP/IP: Transmission Control Protocol/Internet ProtocolU.S.: United States of AmericaUAV: Unmanned Aerial VehicleUSB: Universal Serial BusVDC: Volts Direct CurrentVGPU: Video and Graphics Processing UnitWBS: Work Breakdown Structure


10/221

1

1 Introduction

The Calvin College Engineering Program concludes its four-year degree with a Senior DesignCapstone project. This project spans the entire senior year, giving students the opportunity to useknowledge and skills accumulated throughout their academic careers. It also allows students to work on aproject in their area of interest, from conception to final prototype. Teams of three or four students are

formed around a common project idea. These teams may contain students from similar or differentconcentrations, as the project allows. The Project Proposal and Feasibility Study explored the feasibilityof our chosen project, provided a structured plan for the design, and was a milestone for the project at theend of first semester. This Final Design Report discusses the design details of the project by displayingvarious decisions the team made throughout the design process. Lastly, it discusses future design workthe team would like to do in the next prototype stage.

1.1 Calvin College Engineering Department

Calvin Colleges Engineering Program is ABET (Accreditation Board for Engineering andTechnology) accredited and offers a Bachelor of Science in Engineering with concentrations in Chemical,Civil/Environmental, Electrical/Computer, and Mechanical engineering. The program also offers theoption of an international designation with any of the concentrations mentioned above. The program

combines the foundation of a world-class liberal arts curriculum and adds the cutting-edge knowledge oftechnology in engineering. The program also challenge[s] you to do all of [engineering] from areformed Christian worldview.1

1.2 Team Member Biographies

The Eagleye team is composed of four senior engineering students in the Electrical & Computerconcentration. The team learned about a safety application involving autonomous tracking from theirfaculty advisor, so they decided to pursue it due to their passion for autonomous vehicles andquadcopters. Figure 1 shows the team picture.

Figure 1: Team Photo - Jared Zoodsma, Drew Brandsen, Robert Hoff, and Spencer Olson.


11/221

2

Below is a brief biography of each team member:

1.2.1 Jared Zoodsma

Jared hails from Grandville, Michigan where he attended Calvin Christian High School. Jaredserved as the team financial manager and was in charge of researching and ordering components. Inaddition to his team role, Jared primarily focused on creating a graphical user interface. Work on the GUI

included streaming video, sending GPS coordinates from the quadcopter to the Arduino, and providing away for the user to interact with the system. Jared enjoys working on his car, following Michiganfootball, and playing sports such as soccer, ultimate, and golf. After graduation, Jared will begin hiscareer working at GE Aviation in Grand Rapids, Michigan.

1.2.2 Robert Hoff

Robert is from Bloomington, Illinois and served as team marketing manager. Robert was incharge of team media including posters, website updates, and all other graphical design. Robertstechnical design areas were the tracking algorithms and the RC control. The tracking algorithm comparesGPS locations between the vehicle and quadcopter and autonomously controls the quadcopter overRC. Robert enjoys tinkering with electronics, learning about technology, and is an amateur photographerin his free time. Robert has accepted a job at Northrop Grumman in Rolling Meadows, Illinois.

1.2.3 Drew Brandsen

Drew calls the great lakeside city of Holland, Michigan home. He served as the teamprofessional officer; assuring that all documents and materials were organized and of the utmostquality. On the technical side, Drew was responsible for identifying and integrating quadcopter hardwareand software. Specifically, he created the software to interface between the quadcopter telemetryinformation and the GUI. Drew enjoys spending time with friends, sailing, and playing intramural sports,and after graduation will begin work with Northrop Grumman in June.

1.2.4 Spencer Olson

Acting as Project Manager, Spencer was in charge of keeping the team on track for deadlines setby the faculty adviser, as well as setting intermediate deadlines. He was also in charge of the video

streaming and integration into the GUI, as well as the tracking algorithms and resulting flight controlsfrom the base station. In his free time, Spencer enjoys playing golf, camping, running, and watchingsports. Spencer will begin work this summer at Epic, in Madison, Wisconsin.

1.3 Report Format

This report details the design process of the project. Below are listed each of the chapters in thereport, along with a brief description. References are available at the end of this document.

Chapter2:Project Requirements- Covers the requirements of the project, both in terms of afinal product as well as the prototype that the team completed.

Chapter3:System Design- Evaluates different platforms for implementing a solution based on

design criteria and project requirements. This chapter shows how the team laid out their designgoals for the project.

Chapter4:Quadcopter Design- Discusses the quadcopter design and breaks down therequirements, alternatives, decision criteria, and final decision for each quadcopter component;hardware and software. This chapter also discusses implementation and tests for eachcomponent.


12/221

3

Chapter5:Base Station Design - Discusses the base station design. This chapter also breaksdown each component for its requirements, alternatives, decision criteria, and final decision forboth hardware and software. Each component also has implementation and test details.

Chapter6:System Integration and Testing- Discusses how the various subsystems wereintegrated, and how testing determined if each of those subsystems were performing their

respective tasks. The team also completed testing on the entire system to ensure its performancemet the requirements.

Chapter7:Project Management- This chapter explains the roles of each member of theproject. In addition, it outlines project organization, budget, and timeline.

Chapter8:Business Plan- The business plan discusses a potential startup company andevaluates how this company could make a profit by selling this product.

Chapter9:Conclusion - The final chapter reviews the design work completed and concludeswith potential future work for the project.

1.4

Design NormsDesign norms are virtues used to shape a design process in a way that aligns with our Biblical

teachings at Calvin College. During the course of the project, the team took to heart three main designnorms that shaped the project. Below are short descriptions of each of the design norms. The teamattempted to integrate these design norms into all of our decisions. There are sometimes conflictsattempting to satisfy these design norms, however. For example, providing a high level of justice mayresult in lowered transparency. If this project was used by the United States (U.S.) military, theinformation would become classified and no longer available to the public. This creates tension withinthese norms that necessitated a balancing act by the team as work proceeded on the project.

1.4.1 Transparency

Transparency means that the design should be open about the communication and be

understandable throughout the design process. Transparency came into play as video-taking UAVs arecommonly highlighted in privacy concerns. The team took all actions necessary to prove that the videotaken is for responsible uses and does not show disrespect toward another party.

1.4.2 Justice

The system should be a means of achieving justice, specifically by providing additional securityfor individuals who could be in life or death situations. The team made it a goal to protect those whoprotect and lead us.

1.4.3 Trust

The system must be dependable in all situations. This means that within the definedspecifications, the device will function reliably and effectively

1.5 Acknowledgements

The team would like to take this opportunity to thank those who have helped make this project asuccess. First, the team would like to thank DornerWorks for sponsoring the project through a donation.This donation from DornerWorks was been a tremendous step in helping fund this project. In addition,the team would like to thank their faculty advisor, Professor Steve VanderLeest, who was influential in


13/221

4

providing guidance and direction to the project. Next, the group would like to thank the Calvin CollegeEngineering program as a whole for supporting successful projects with finances and challenging studentsto strive toward stronger projects. The team would also like to thank Professor Yoon Kim for allowingthem to run tests on his quadcopter and use parts of it for their project. Professor Kim also donatedseveral quadcopter components, which helped the team stay under budget. Justin TeBrake is anotherindividual who donated a net to the team and deserves gratitude. The team is also thankful to Andrew Jo

for his significant contribution to the business plan. Lastly, the team would like to thank our families fortheir continued love and support in our education and personal development.


14/221

5

2 Project Requirements

This chapter identifies potential customers, defines customer requirements, and establishes a listof deliverables for the customer. Following the requirements, the next chapter will discuss in detail theteams solution to solving this problem.

2.1

Problem StatementSecurity is paramount for presidential motorcades, military convoys, and other safety critical

transports. Visibility is often impaired for those inside the vehicles, making it difficult to see all possiblethreats ahead, behind, and to the side. Lack of visibility creates a significant danger from insurgents,RPGs, IEDs, and other threats. Travel routes can span hundreds of miles and covering these routes withexplosive detectors, bomb-sniffing dogs, or law enforcement is costly, but still does not guaranteecomplete safety. Improved visibility for individuals in the vehicles can help mitigate these external risks

2.1.1 Solution

The solution that our team proposes provides a system that shadows a motorcade or convoy fromabove in order to provide a birds-eye view of their surroundings, enabling users to spot would-beattackers, IEDs and other threats. Providing this real time overhead vantage point will increase the

situational awareness of those in the vehicles. This additional information provides one more level ofsecurity that ultimately leads to justice and safety for those who need protection.

2.1.2 Target Customers

Our solution targets organizations or individuals with a need for security when traveling by land.Our customers will include diplomats, the Secret Service and the U.S. Military to name a few. The teamwill design the system to bolster security for those with this need, particularly those who serve ourcountry. The team considers it a just cause to protect our customer from malicious attack.

2.2 Customer Requirements

This section articulates customer-defined requirements by sub-sections such as performance,mechanical features, and customer use. The team also identified requirements used to build prototype

1.0, which was delivered on May 10, 2014. These requirements are defined generally here, and areapplied more specifically for the chosen solution in chapters four and five.

2.2.1 Performance

These requirements define the performance of the system such as flight time and maneuverability.

2.2.1.1 Flight time

REQ 2.2.1.1.A: The airborne component of the system shall stay aloft for a minimum time of thirtyminutes.

This time is viewed as the longest journey that our customer might take where they would expect theproduct to operate continuously without a recharge. Anything less and the customer would likelyconsider it difficult and cumbersome to use.

REQ 2.2.1.1.A.P1 Prototype 1.0 shall stay aloft for ten minutes.

Due to commercially available batteries for this application, one can achieve this standardtime. Ten minutes also proves that with more time and money, a custom battery could be built toincrease this flight time to thirty minutes.


15/221

6

2.2.1.2 Flight Performance

REQ 2.2.1.2.AThe airborne component of the system shall move from one point in three-dimensionalspace to another in a straight line.

This is necessary in order to provide a high degree of maneuverability.

REQ 2.2.1.2.B The airborne components airspeed shall be no less than 100 km/hr (62 MPH).

100 km/hr was determined to be the maximum speed at which vehicles would move through populated,urban areas where an attacker would be able to hide.

REQ 2.2.1.2.B.P1 Prototype 1.0 shall have a top airspeed of no less than 15 km/hr (9.3 MPH).

A speed of 15 km/hr will allow the team to produce a prototype that demonstrates the productspotential and provides a good platform for testingwithout purchasing larger, more expensivemotors to reach higher speeds.

REQ 2.2.1.2.C The solution shall have a 2-D tracking tolerance of 1.8 meters (6 ft) from a pointhorizontal from the source location to a point directly vertical of the destination location. Thisrequirement is applied for both a moving and stationary vehicle.

This tolerance was selected to be half the width of a standard road lane size.2 Thus, the system will staywithin the same lane as the vehicle it is following. This is required so that the system keeps a centeredview of the vehicle and its surroundings during flight.

REQ 2.2.1.2.C.P1 The solution shall have a 2-D tracking tolerance of 7.2 meters (23.6 ft) from apoint horizontal from the source location to a point directly vertical of the destination location.

This is the width of a standard two-land road.2 This was chosen for testing purposes to prove thesystem can track a moving vehicle on common traffic roadways. SeeFigure 2 for a visualdepiction.

Figure 2: 2-D Horizontal Distance Requirement for prototype 1.0


16/221

7

REQ 2.2.1.2.D The system shall have an altitude tracking tolerance no greater than one meter (3.28 ft).

Since the camera will view from horizon to horizon (REQ 2.2.1.4.C), a one meter tolerance ensuresaccurate tracking and stable video.

REQ 2.2.1.2.E The system shall fly as far as 200 meters (656 ft) from the vehicle without losingcommunication.

200 meters is the common size of a city block in the United States and elsewhere. This distance wouldallow the system to investigate the next intersection as the vehicle enters a new block.3

REQ 2.2.1.2.E.P1 The system shall fly as far as 100 meters (328 ft) from the vehicle withoutlosing communication.

100 meters (328 ft) is considered a good starting place for prototype 1.0.

2.2.1.3 Environment

REQ 2.2.1.3.A The system shall operate fully in the military temperature range of -55 to 125 degreesCelsius (-67 to 257 degrees Fahrenheit).

Since the system is designed for military applications, the typical operating temperature for military grade

equipment is expected.

REQ 2.2.1.3.A.P1 Prototype 1.0 shall operate fully in a temperature range of 0 to 70 degreesCelsius (32 to 158 degrees Fahrenheit).

In an effort to keep budget low, the team will use commercial grade parts. These parts are onlyqualified for the above temperature range.

REQ 2.2.1.3.B Humidity: the system shall fly at all humidity levels.

The humidity and condensation levels will not ground the device.

REQ 2.2.1.3.B.P1 Humidity: the system shall fly at any temperature at which the ambienttemperature is above the dew point.

The humidity tolerated by the project will be any level at which there is no condensation. Thismeans that the actual relative humidity will vary based on the temperature.

REQ 2.2.1.3.C The system shall fly in dusty environments.

This is particularly important, as military uses will expose the device to dust and small debris, which willlimit visibility and be potentially destructive to system components.

REQ 2.2.1.3.C.P1 Not required for prototype 1.0.

This is similar to the humidity requirement, and though possible, is not required for theprototype. Testing the effects of dust, even on individual components such as motors, potentiallyadds costs to replace any broken components. The team is unable to afford these additionalcomponents for testing given the budget constraints for prototype 1.0.

REQ 2.2.1.3.D The system shall fly in smoky environments.

This is particularly important, as military uses will expose the device to smoke, which will obstruct theview of the vehicle on the ground.


17/221

8

REQ 2.2.1.3.D.P1 There is no smoke requirement for prototype 1.0

In order to view video in a smoky environment, a second infrared (IR) camera would benecessary, which is outside the budgetary constraints of prototype 1.0.

REQ 2.2.1.3.E The system shall fly in winds up to 105 km/hr (65 MPH).

The device will be used outdoors, requiring that it work in many conditions. 105 km/hr is the lowestbound for a tornado.4 The system is expected to be useful in less than ideal weather conditions, but flyingat tornado-like wind speeds is not expected.

REQ 2.2.1.3.E.P1 Prototype 1.0 shall withstand wind speeds up to 27 km/hr (17 MPH).

Prototype 1.0 shall be able to withstand the average wind speed at its production site: GrandRapids, MI.5

REQ 2.2.1.3.F The system shall have the ability to avoid obstacles within the flight path.

This is essential as power lines, trees, and other obstacles will be inherent in the environment for whichthis system will be used. The system must avoid these obstacles without user intervention.

REQ 2.2.1.3.F.P1 There is no obstacle avoidance required for prototype 1.0

Due to cost and time constraints, obstacle avoidance is not explored in prototype 1.0. However,the team understands that this is essential for this system to meet its full utilization.

2.2.1.4 Video Performance

REQ 2.2.1.4.A The system shall stream video in 1080p quality.

Since the goal of the system is to provide a video stream for protection, this video shall be high definitionin order to identify threats.

REQ 2.2.1.4.A.P1 Prototype 1.0 shall stream video at a quality of 240p.

240p quality is a good starting point quality for the video feed, which will show a proof ofconcept.

REQ 2.2.1.4.B The system shall capture video at 30 frames per second.

At 30 fps, there is a 33.3 ms delay between frames. This is about 1/6 the reaction time of a typicalcollege-age student detecting a visual stimulus.6 As such, this is not the bottleneck in reacting to threatsand thus is sufficiently fast.

REQ 2.2.1.4.C The system shall have a 360 degree field of view in order to see threats from all directions;forward, behind, left, and right, and down.

This is essential, as the quadcopter must be able to see enough of the area in order to see all of thepotential threats.

REQ 2.2.1.4.C.P1 There is no minimum field of view requirement for prototype 1.0.

So long as the system is able to send video, proof of concept is achieved. A more expensivecamera could be purchased with a wider camera angle to reach the final requirement.

REQ 2.2.1.4.D The system shall have a video feed with a latency of under 810 ms (from the time thevideo is captured on the quadcopter, the video feed should display on the GUI within 810 ms seconds).

RPGs travel at about 300 m/s. The typical reaction time of a college-aged individual to detect a visualstimulus is 190 ms.6 In this time, the rocket will have already traveled 57 meters. This does not factor in


18/221

9

a response by the individual or any latency in the video stream. As such, it would be nearly impossible toprotect against an RPG fired at close range.

It takes an individual with a weapon about a second to jump around a corner and level the weapon. Sincereaction time is 190 ms as mentioned above, that means that the maximum video latency is 810 ms (1000ms jump190 ms reaction).

REQ 2.2.1.4.D.P1 The system shall have a video feed with a latency of under one second.

Since prototype 1.0 is a proof of concept, a video latency under one second will show theusefulness of a video stream.

2.2.2 Physical

These requirements deal with the mechanical size and durability of the solution.

2.2.2.1 Size

REQ 2.2.2.1.A The system shall fit into the back of a vehicle, taking up no more than a total space of 1.3x 1.3 x 0.4 meters (4.25 x 4.25 x 1.3 feet)

The device must be small enough to fit in existing military vehicles or else the system will not be

adopted. This conservative size ensures this is possible.

2.2.2.2 Weight

REQ 2.2.2.2.A The system shall weigh no more than 23 kg (51 lbs).

The device needs to be easily transported and be under the NIOSH lifting recommendation limit of 23kg.7

2.2.2.3 Reparability

REQ 2.2.2.3.A The system shall have a modular design such that all components, with the exception ofindividual components on a printed circuit board (PCB), are replaced with only the need of a screwdriver,a needle nose pliers, and an Allen wrench.

Due to the rugged application, simple reparability is essential.2.2.3 Customer

The following are requirements for how the system will interact with the customer.

2.2.3.1 Ease of Use

REQ 2.2.3.1.A The system as a whole shall autonomously track the intended vehicle.

Upon activating the system, it shall not require additional user interaction until the user is ready todeactivate the system. This allows the user to focus on the results of the system (the video stream fromabove) and not controlling the system. For security customers, this provides a level of justice in that thisproduct should never decrease the situational awareness of the user.

REQ 2.2.3.1.B Training for the device shall be minimal, requiring no more than one eight hour day.The device shall be intuitive to use and the training shall not require an engineering or technicalbackground.


19/221

10

2.2.3.2 Safety

REQ 2.2.3.2.A A loss of communication shall result in the system landing and having flight temporarilydisabled.

In the event that communication is lost, the system will perform an automatic landing that will minimizedamage to the system and the chance of injury to others. It will also temporarily disable flight until the

user is able to retrieve the system.

2.2.3.3 User-System Interaction

REQ 2.2.3.3.A The base station shall provide a video feed to the user within a GUI.

These statistics will provide valuable information to the user on the flight of the system, even when theycannot physically see the system themselves.

REQ 2.2.3.3.B The base station shall provide flight statistics including heading, altitude (in meters or infeet, selectable by user), and speed (in km/hr or MPH, selectable by user) on the GUI.

These statistics will provide valuable information to the user on the flight of the system even when theycannot physically see the system themselves.

REQ 2.2.3.3.B.P1 The prototype 1.0 GUI shall display video.Since prototype 1.0 is simply a proof of concept, video feed will be the only requirement for theGUI. Other flight statistics are deemed as stretch goals for proof of concept purposes.

REQ 2.2.3.3.C The user shall be able to override the autopilot from the GUI.

This will allow the user to fly the system outside of the normal tracking parameters, and allow uses suchas arriving at an intersection before the convoy or scanning a general area.

REQ 2.2.3.3.C.PI Prototype 1.0 shall only need the ability to toggle autopilot on and off.

Turning off autopilot will result in a deterministic action by the system, such as stationaryhovering.

REQ 2.2.3.3.D The user shall be able to enable and disable flight when the system is on the ground andthe throttle is turned down.

It is necessary for safety purposes to have a disarmed system that is still powered on. This will only beperformed once the device is no longer airborne.

REQ 2.2.3.3.E The user shall be able to power on and off the device when it is on the ground anddisarmed.

This important control must be available to the user.


20/221

11

2.3 Deliverables

The team provided a variety of deliverables throughout the project including reports, webmaterials, and prototypes. Table 1 showsa list of the major deliverables with this project.

Table 1: Project Deliverables

Deliverable Explanation

First Semester

Presentation 1Initial presentation of the project providing an initial overview; fiveminutes with one minute of question and answer (Q&A).

Presentation 2Second presentation of the project; including a project brief, feasibility,and current status; seven to nine minutes with one minute Q&A.

Team WebsiteTeam website that has team overview, project details, progress, anddocumentation. Resides on Calvin Engineering webpage; updatedregularly.

Team PosterTeam poster that describes the team and gives an overview of theproject; updated regularly.

PPFSDefines the project proposal and the feasibility of the project, includesrequirements, budget, management, and status to name a few.

Prototype 0.1Prototype completed by the end of first semester; includes a flyingquadcopter (provided by Professor Yoon Kim), video streaming overWi-Fi, some tracking and control research, and a basic GUI.

Second Semester

Presentation 3 The third presentation of the project.

Prototype 0.2Prototype completed by the end of interim; includes a flying quadcopterwith the MutliWii (MW) flight controller.

Presentation 4 The final in-class presentation of the project

Design NotebooksDesign notebooks that are completed individually documenting thedesign process of each team member.

Prototype 1.0Final prototype of the project; includes a complete quadcopter system,video streaming into a GUI, and accompanying base station for

tracking.

Final Presentation Final presentation of the project completed on Senior Design Night

Final Design ReportFinal design report of the project; includes many portions of the PPFSas well as additional design details and other updates.


21/221

12

3 System Design

This chapter begins to evaluate different solutions to the problem outlined above. The chapterevaluates several design alternatives and concludes with a final solution. The team determined that aquadcopter with a base station was the best approach to solve the problem. High-level system details areestablished in this section. Component-level requirements for the quadcopter and base station are

outlined in the following two chapters.

3.1 Decision Matrix

Before continuing on any further analysis of the problem, the team analyzed different solutionplatforms. The team evaluated five potential solutions that are detailed in the following sub-sections. This section concludes with a decision matrix that summarizes our decision along withjustifications for the corresponding scores.

3.1.1 Possible Solutions

The five possible solutions are detailed below, followed by the different decision criteria used toevaluate the solution.

3.1.1.1 Quadcopter

Quadcopters are increasing in popularity for applications ranging from search and rescue to aerialphotography. Quadcopters use four separate arms, each with a rotating propeller in order to achievestable flight. Recent technological developments in microprocessors have made possible the complex,dynamic control systems necessary to balance a quadcopter. Given an easily expandable platform and ahigh maneuverability in the air, quadcopters have proven effective for many common UAV applicationsas is highlighted in an article in Popular Mechanics Magazine.8 An example picture of a quadcopteroutfitted with cameras is shown inFigure 3.9

Figure 3: Quadcopter Outfitted With Cameras9

3.1.1.2 RC HelicopterRC helicopters (Figure 4)(either gas or electric powered) have been around for hobbyists for

decades. Sizes can range from hand size to the size of a car. RC helicopters give the ability to hover inthe air with relative stability (discussed later).


22/221

13

Figure 4: RC Helicopter10

3.1.1.3 RC Airplane

Like RC helicopters, RC airplanes (Figure 5)are not new to the hobby world. A downside to RCairplanes is the fact that they cannot hover in one place.

Figure 5: RC Airplane11

3.1.1.4 Balloon / Blimp

Another solution to the problem would be to use a balloon or blimp to stream the video, anexample is seen inFigure 6. The device would be either towed by a rope or controlled by RC. It is likelythat this type of solution would have a small motor for maneuverability purposes. A factor to consider isthe size (1 m12to 4.3 m13) of this type of device, making it a very easy target for enemies.


23/221

14

Figure 6: RC Blimp12

3.1.1.5 Panoramic Ball Camera

A new consumer product exists where a user throws a ball in the air and at the peak altitude, ittakes several pictures in each direction.14The pictures are then loaded onto a computer for viewing andstitched together to form a seamless overhead image of the surroundings. The panoramic ball camera isshown inFigure 7below. However, this solution was quickly abandoned as it became apparent this wasnot practical. Some of the reasons it was deemed impractical include the fact that constant video wouldnot be provided, users would be exposed when the ball needed to be thrown, and throwing and retrievinga ball from a moving vehicle is not feasible.

Figure 7: Panoramic Ball Camera14


24/221

15

3.1.2 Decision Criteria and Justification

Each of these solutions were compared against eight criteria that the team deemed important tothe problem. Table 2 displays the results of this decision matrix below. Criteria weights were chosenbetween one and ten, with ten being the highest weighted. Weight values can be repeated. Scores, on theother hand, are ranked between one and four with four being the best score. Scores are not repeated on

any category.Table 2: Decision Matrix

Categories: Weight 1-10 QuadcopterRC

Helicopter

RC

Airplane

Balloon /

Blimp

Battery / Fuel /

Time in Air5 2 1 3 4

Durability /

Replacement Parts6 4 3 2 1

Wind Resistance 7 4 3 2 1

Cost 4 1 3 2 4

Ease of Use 4 3 2 1 4

Maneuverability 9 4 3 2 1

Expandable

Platform8 4 3 1 2

Safety in Hostile

Environment10 4 3 2 1

Total: 186 145 99 100

3.1.2.1 Battery / Fuel / Time in Air

How well the system stays in the air and for how long. Time in the air was a middle ground at afive due to the customizability of each system. The team did not feel this was a major differentiatingcharacteristic because battery life and fuel capacity can be easily expanded in most systems.

3.1.2.2 Durability / Replacement Parts

How much abuse each system can take and how easy it is to replace broken parts. Durability andreplacement parts were moderately important at a six because the solution needs to be able to hold up

over time. Replacement parts deal with how easy it is to change parts (i.e. unplug and replace, tape, etc.).In addition, this accounts for the variety of parts that could be replaced. For example, a system that onlyhas 30 parts, but only three different variety of parts, will score better than a system with 15 parts that areall unique.


25/221

16

3.1.2.3 Wind Resistance

How well the system is able to counteract the effects of light to moderate winds, including windgusts. Wind resistance was rated moderately high at a seven due to the conditions in which the systemwill be used. Often times there will be opposing or cross winds that must not affect the stability of the

system.

3.1.2.4 Cost

Expense to design, build, implement, and maintain. Cost was weighted at a four because when itcomes to safety, compromising is not an option. The best parts must be used in order to mitigate failurewhenever possible.

3.1.2.5 Ease of Use

Ease of use was weighted at only a four because it was assumed that the user will have at leastsome training in implementation, and users will likely be knowledgeable in technical areas. In addition,nearly all of the solutions will get easier as the amount of design and development increases.

3.1.2.6 Maneuverability

This category includes acceleration, flexibility, hovering, agility, and obstacle avoidance. Thiscategory was weighted at nine out of ten because of the nature of the vehicle it will be following. Inmany situations, the convoy to follow will start and stop quickly as well as turn corners and changedirections suddenly. To ensure the vehicle remains in the video frame the solution must be highlymaneuverable.

3.1.2.7 Expendable Platform

How easy it is to add cameras, sensors, and tracking hardware to the system. This was weightedan eight out of ten because of the projects need to carry multiple components such as communicationdevices and cameras.

3.1.2.8 Safety

How dangerous is it for the user to interact with the system in a hostile environment. Interactionsthe user could be expected to perform are as follows: launch the device, retrieve the device, and view thevideo. This was weighted a ten out of ten because the primary goal of the project is to implement asolution that leads to increased safety.

3.1.3 Justification

The following sections describe how each solution was scored for each decision criterion.

3.1.3.1 Battery / Time in Air

Quadcopter- Average flight times for quadcopters with a 2200 mAh battery are about tenminutes.15

RC Helicopter- Average flight times for a RC helicopter with a 2200 mAh battery are aroundseven minutes.16

RC Airplane - Average flight times for a RC airplane with a 2200 mAh battery are around 20minutes.17


26/221

17

Balloon / Blimp - Balloons have a very long flight time when compared to the other solutions asit is only limited by the time it takes to drain the battery from accessories being powered.

Conclusion - Based on the following results, the RC helicopter came in last with the lowestscore, followed next by the quadcopter, and then the RC airplane. The best score was awarded tothe balloon/blimp for its ability to stay potentially airborne for days.

3.1.3.2 Durability / Replacement Parts

Quadcopter - Since a quadcopter uses several of the same components (i.e. four motors, fourarms, four electronic stability controllers (ESCs) etc.) this makes it easy to swap out brokencomponents. Similar internal electrical components would be used for a quadcopter, RChelicopter, and a RC airplane. Therefore, these components did not affect durability ratings.Quadcopters received the best score.

RC Helicopter - Similar to a quadcopter, except all components are unique. Therefore,"replacement parts" receives a slightly lower score.

RC Airplane - As discussed in the maneuverability section, RC airplanes have a lowmaneuverability. For this reason, it is more likely that a significant crash could happen.Therefore, it scored lower than the quadcopter and RC helicopter.

Balloon / Blimp - Balloons received the lowest score since a small tear in the balloon wouldrender the device useless. Repairs to a torn balloon would not be simple. It would requirepatching the hole and refilling the air. In order to refill with air, a user would be required to carrysuitable gasses in a compressed state.

Conclusion - Looking at all of these options, the quadcopter took the highest score, followed nextby the RC helicopter. The RC airplane scored second to last with its higher probability forcrashes, followed by the balloon/blimp because of its large and vulnerable balloon.

3.1.3.3 Wind Resistance

Quadcopter - Due to quadcopters robust control systems, they are able to adjust to changes intheir environment by rapidly adjusting rotor speed without needing to turn the whole system.

Quadcopter control systems are different from other air vehicles because they do not have aforward and backward direction, allowing them to move in all directions at any point.

RC Helicopter - A RC helicopter would not tolerate gusts as well as a quadcopter due to lowermaneuverability (SeeManeuverability section below).

RC Airplane - RC airplanes, though quite resistant to steady winds, are not able to quickly adaptto changing winds as quadcopters can, due to the lack of dynamic balancing available.

Balloon / Blimp - A balloon has little motor control and is completely vulnerable to the slightestchange in wind. Therefore, the blimp received the lowest score in this category.

Conclusion - The quadcopter came in first due to its small and dense nature. Closely behindwere the RC helicopter and the RC airplane. Lastly, again because of its size and limited

maneuverability, the blimp/balloon came in last.

3.1.3.4 Cost

Quadcopter - A stable quadcopter kit is about $600.18

RC Helicopter - A RC helicopter with a good flight controller is around $400.19


27/221

18

RC Airplane - A RC airplane option that includes the features needed for this project includingGPS and flight planning are roughly $600.20

Balloon / Blimp - The cost for a blimp that would cover the specifications is about close to$150.21

Conclusion - The costs are lowest for the blimp due to its non-complex nature. Next is the RC

helicopter. Following that is the RC airplane, and lastly the quadcopter.

3.1.3.5 Ease of Use

Quadcopter - Quadcopters include self-balancing software that keeps them flying without userinput. With easy to implement antennae technology, they can be controlled from inside anarmored vehicle and even programmed to fly specific routes without user input.

RC Helicopter - RC helicopters are similar to quadcopters in that they can be self-balancing aswell as include pre-programmed routes.

RC Airplane - While they include pre-determined route flying, it is hard to quickly changedirections in RC airplanes due to their need to maintain airspeed in order to stay aloft. Anotherdownside is that these require some sort of takeoff distance or a hand thrown start that exposes

the user.

Balloon / Blimp - Once the balloon is attached or takes off, it would require little effort to land orreplace batteries. Therefore, the balloon received the best score

Conclusion - Looking at all of the options, it was easy to see that the blimp is the easiest of thesystems to use, followed by the quadcopter. Next were the RC helicopter and the RC airplane,which requires the most attention of the powered solutions.

3.1.3.6 Maneuverability

Quadcopter - Since quadcopters by design do not have a front facing direction, they are capableof moving in any direction from any orientation. This allows them to change direction and speedvery quickly. A quadcopters ability to pitch and roll is modeled by the difference in thrusts of

two propellers multiplied by the length of an arm, as shown inFigure 8 and the two equationsbelow. These two factors give the quadcopter great maneuverability.22

Figure 8: Control of a Quadcopter22


28/221

19

= ( ) = ( ) RC Helicopter - While RC helicopters do have a front and back direction, they are still capable

of moving in any three dimensions at a given time. Since helicopters only have two propellers(one for thrust and one for stability). RC helicopters directional flight is determined by thetilting of a swash plate, which in turn tilts the primary rotor. Therefore, the directional force

available is modeled by cos()where is the force of the primary propeller and is theangle of the swash plate from the perpendicular.23 RC Airplane - RC airplanes are not capable of stopping, hovering, or taking off with no

speed. They are also unable to change directions quickly side to side. While the RC airplanecould go into a holding pattern, this would likely be unhelpful since constant video from the sameperspective would not be provided. A similar video perspective is desired to provide the userwith a simplistic design. If the video is constantly changing perspective, the user will need toreorient him/herself by finding north, south, east or west every time he/she views the video. Inaddition, RC airplanes were not deemed maneuverable enough to fly at low altitudes in urbanareas. Such flight patterns would almost certainly lead to a collision between the device and thesurroundings. Since RC airplanes only have one propeller, they can only travel forward. RCairplanes cannot move side to side without moving forward and cannot move backwards at all.

Balloon / Blimp - Balloons would likely be tethered to the vehicle, but in addition, they wouldlikely have small motors to allow some movement. This does not allow for greatmaneuverability. Small movements could be performed, but they would be by no means quick.

Conclusion - The quadcopter excelled in this category due to the fact that it can move in anydirection in 3-D space immediately, without turning first or building up speed. Next was the RCHelicopter, with its only limitation being that it must turn before executing some maneuvers. TheRC airplane came in third because it requires speed to move, and any increase in altitude cannotbe done instantly but instead requires routing. Following these, the balloon scored worst of thesolutions because it is slow and its large size makes it cumbersome.

3.1.3.7 Expandable Platform

Quadcopter - Quadcopters are designed with expansion in mind. The flat and symmetricalframe makes it easy to incorporate more hardware onto the design. They also have self-balancingabilities that allow for minor frame imbalance, which enables hardware to be added without theconcern for perfect balance. In addition, quadcopter arms are estimated to be 0.3 m long. Withhalf of the space estimated as usable for expansion (to prevent interference with propellers), theplatform size is 0.045 m2. SeeFigure 9 for a visualization.


29/221

20

Figure 9: Platform Area of a Quadcopter

RC Helicopter - RC helicopters have room for cameras and GPS modules, but not muchelse. Due to the hull, the only room to add additional components would be on the skids alongthe bottom of the RC helicopter. The skid area is estimated to be 15.25 cm by 10.16 cm giving anarea of 0.015 m2, just 33% of the estimated area available for a quadcopter. In addition to this,the volume available for an RC helicopter is limited by the landing gear on the bottom and therotor on the top, while quadcopters can outfitted with much taller components without conflictingwith the rotor and landing gear.

RC Airplane - RC airplanes are built inside a certain predefined frame. This makes it difficult toadd additional hardware, as there often is a space issue. Unlike RC helicopters, RC airplanes donot have skid like platforms to mount extra hardware on. Balance is also more of a concern, asRC airplanes do not have any way of dynamically counteracting balance. This would beproblematic because symmetrical weight needs to be added to balance the RC airplane,potentially leading to weight being added solely for balance.

Balloon / Blimp - The balloon/blimp scored quite low in this category, not because there is notspace to add accessories, but because the lift is heavily affected by small weight increases. Thewhole system may need to be enlarged in order to handle the weight of additional accessories.

Conclusion - The quadcopter scored best in this category because it is made with expansion inmind. The RC helicopter was second because it is similar in nature to the quadcopter, except thatthe hull limits space. A RC airplane is quite space limiting because of its specifically designedfuselage. Last are blimps, which are heavily affected by weight.


30/221

21

3.1.3.8 Safety

Quadcopter - Quadcopters can be remotely controlled by a RC transmitter inside avehicle. They can be programmed to take off and land from the top of a vehicle or a platform onthe back to ensure that no operators need to exit the vehicle.

RC Helicopter - RC helicopters have similar safety characteristics to quadcopters.

RCAirplane - RC airplanes either require a takeoff runway, or close user interaction (for a handthrown start). These options extend the time required for takeoff and put the user in more dangerby requiring them to be outside the vehicle. Any time that the operator is outside of the vehiclepresents a safety risk.

Balloon/ Blimp - RC balloons or blimps would not require an operator to exit the vehicle andexpose himself or herself. However, being an air-holding vessel, these options would bevulnerable to punctures from surrounding objects, such as trees, buildings, and bridges.

Conclusion - Quadcopters and RC helicopters are the best in this situation due to their verticallaunches and programmable flights. However, quadcopters edged out because of increase takeoffand landing maneuverability. The balloon/blimp scored next again because of its near-verticaltakeoffs. RC airplanes, because of their long takeoff and landing requirements, scored the lowest.

3.1.4 Best Solution

As one can see from theTable 2 above, the quadcopter scored the highest, and the team believesthat it solves the problem most efficiently due to its maneuverability, expandable platform, and safety.

3.1.4.1 Recognized Weaknesses

While the solution chosen for the problem provides many positive attributes, it is not without itsweaknesses. As is a problem with all RC vehicles, quadcopters have to constantly tradeoff betweenabilities and battery life. As soon as more features are added, the weight gain and processing powerneeded take a sizeable amount of battery life from the overall flight time. In addition to this problem,quadcopters are particularly vulnerable to crash damage. This could have been a major problem,especially during initial testing phases that will require iterative safety designs.

3.2 Overall System Block Diagram

The overall system block diagrams are in the following two sections. The first section looks atthe hardware aspects of the solution and how the two subsystems interact, while the second sectionfocuses on the software aspects of the solution and how the software on the two separate subsystemscommunicate.

3.2.1 Hardware

The overall system hardware block diagram is seen inFigure 10 and shows the two subsystems ofthe solution.

One part is the base station, which is located inside the vehicle. The base station includes two

major subsystems, the controls and communication system, and the base station computer. The controlsand communication system provides the network over which video streaming can occur, as well as theability to send controls from the base station computer to the quadcopter. The base station computerprovides an interface for the user to interact with the system. Refer to Chapter5 for the details of the basestation.


31/221

22

The second part of this solution is the quadcopter. This consists of a flight controller, a videographics processing unit (VGPU), a camera, GPS module, motors, and a power distribution system. TheGPS module receives data from the outside world while the motors provide thrust. The flight controllerand VGPU send/receive data and controls to/from the base station. All of the interface connections aredescribed inTable 3below. Refer to Chapter4 for details of the quadcopter.

Figure 10: Overall System Hardware Block Diagram

Table 3: System Hardware Block Diagram Interface Descriptions

Signal Name Description Protocol

User Inputs

The user inputs include the ability to turn the quadcopter on/off,toggle on/off the autopilot, toggle on/off the video stream, and

arm/disarm the system per REQ 2.2.3.3.C, REQ 2.2.3.3.D, REQ2.2.3.3.E. All inputs are done through the GUI on the base stationcomputer, using switches on the controller, or by physically pluggingin the battery on the quadcopter.

GUI Buttons,

ControllerSwitches,

Battery Plug

PowerThe power for the base station is provided through the battery of thecar where the base station is mounted. The car powers both the basestation computer and the controls and communication system.

15 V Car Outlet

GPS SatelliteSignal

The controls and communication system and the GPS module on thequadcopter receive a GPS signal from global orbiting satellites.

NMEA 018324

RC ControlSignal

A control signal to control the quadcopter is sent from the controls

and communication system to the flight controller on the quadcopter.This signal is a frequency-hopping spread spectrum signal sent over a2.4 GHz frequency.25

2.4 GHz


32/221

23

TelemetryData

The telemetry data is sent over an 802.11n Wi-Fi connection usingtransmission control protocol over internet protocol (TCP/IP). Thiscarries the GPS coordinates to the base station computer as well asother telemetry data such as the quadcopter altitude, heading, and RCinputs. The GPS position is refreshed at 10 Hz and data is sent each

time new GPS data is received. See section4.2.9.2.2 for details andnecessary bandwidth calculations.

802.11n/TCP/IP

Video Data

The video data is sent in an H.264 compressed format over an802.11n Wi-Fi connection. The latency is determined by REQ2.2.1.4.D and the data is sent over UDP/IP using GStreamer. Videodata is sent on a different port than the telemetry data to preventinterference. See section4.2.9.2.1 for bandwidth calculations.

H.264/GStreamer

Motor ThrustThe motors provide thrust to the outside world in order to lift thequadcopter.

N/A

Sensor DataThe flight controller has various sensors that read data of theenvironment and send it to the flight controller for analysis and flight.

EnvironmentData*

*The environment data received by the flight controller sensors varies for each sensor. The barometermeasures the atmospheric pressure, the magnetometer measures the earths magnetic field, theaccelerometer measures the acceleration of the quadcopter