Drew Brandsen
Robert Hoff
Spencer Olson
Jared Zoodsma
Engineering 339/340 Senior Design Project
Calvin College
December 9, 2013
© 2013, Drew Brandsen, Robert Hoff, Spencer Olson, Jared Zoodsma and Calvin College
Executive Summary
Motorcades and military convoys often face potential danger from enemies they cannot see.
Personnel within the vehicles do not have a good vantage point from which to view dangerous threats.
The solution to this problem must be simple to use and effective in spotting any enemies in the area. It
must also be reliable, always providing real-time information to the user. Finally, the system must be
automated to minimize user interaction needed.
The solution a team of four electrical and computer engineers has chosen consists of two
subsystems. The team considered various options for the first subsystem and chose a quadcopter because
of its high expandability, maneuverability, and stability. The quadcopter will be equipped with video
capture equipment, as well as a global positioning system (GPS) receiver. Second, a base station, which
will be located in the vehicle, includes a computer, Wi-Fi router, and radio controlled transmitter. The
base station will have a graphical user interface (GUI) that will receive video, which is streamed from the
quadcopter, and provide a way to interact with the quadcopter. Currently, the team has a flying
quadcopter, basic video streaming over Wi-Fi, and a basic GUI.
Due to the large nature of this project, the team sought additional funding to cover the budget.
DornerWorks has generously agreed to donate $1000 to the project, which coupled with the contribution
from the Calvin Engineering Department, will help the team realize their financial needs of $1455. The
team has completed over 420 hours out of an expected maximum total of 1202 hours, and along with
completed research, feel that this project is feasible by May 10. The team hopes that this solution will
provide additional security for troops, diplomats, and individuals with security needs.
Table of Contents
1
Introduction......................................................................................................................... 1
1.1 Calvin College Engineering Department ............................................................................ 1
1.2 Team Member Biographies................................................................................................. 1
1.3 Report Format ..................................................................................................................... 2
1.4 Design Norms ..................................................................................................................... 3
1.4.1 Transparency ................................................................................................................ 3
1.4.2 Justice........................................................................................................................... 4
1.4.3 Trust ............................................................................................................................. 4
2
Acknowledgements ............................................................................................................. 5
3
Project Requirements .......................................................................................................... 6
3.1 Problem Statement .............................................................................................................. 6
3.1.1 Solution ........................................................................................................................ 6
3.1.2 Target Customers ......................................................................................................... 6
3.2 Customer Requirements ...................................................................................................... 6
3.2.1 Performance ................................................................................................................. 6
3.2.1.1 Flight time ............................................................................................................ 7
3.2.1.2 Flight Performance .............................................................................................. 7
3.2.1.3 Environment ......................................................................................................... 8
3.2.1.4 Video Performance ............................................................................................ 10
3.2.2 Physical ...................................................................................................................... 10
3.2.2.1 Platform ............................................................................................................. 10
3.2.2.2 Size ..................................................................................................................... 10
3.2.2.3 Weight ................................................................................................................ 11
3.2.2.4 Reparability ....................................................................................................... 11
3.2.3 Customer Use ............................................................................................................. 11
3.2.3.1 Ease of Use ........................................................................................................ 11
3.2.3.2 Safety.................................................................................................................. 11
3.2.4 User ............................................................................................................................ 11
3.2.4.1 User-System Interaction..................................................................................... 11
3.3 Deliverables ...................................................................................................................... 13
3.3.1 Fall Semester Deliverables......................................................................................... 14
3.3.2 Spring Semester Deliverables .................................................................................... 14
4
System Design .................................................................................................................. 15
4.1 Decision Matrix ................................................................................................................ 15
4.1.1 Possible Solutions ...................................................................................................... 15
4.1.1.1 Quadcopter ........................................................................................................ 15
4.1.1.2 RC Helicopter .................................................................................................... 15
4.1.1.3 RC Airplane ....................................................................................................... 16
4.1.1.4 Balloon / Blimp .................................................................................................. 16
4.1.1.5 Panoramic Ball Camera .................................................................................... 17
4.1.2 Decision Criterion ...................................................................................................... 18
4.1.2.1 Battery / Fuel / Time in Air ................................................................................ 18
4.1.2.2 Durability / Replacement Parts ......................................................................... 18
4.1.2.3 Wind Resistance ................................................................................................. 18
4.1.2.4 Cost .................................................................................................................... 18
4.1.2.5 Ease of Use ........................................................................................................ 18
4.1.2.6 Maneuverability ................................................................................................. 18
4.1.2.7 Expendable Platform ......................................................................................... 18
4.1.2.8 Safety.................................................................................................................. 19
ii
4.1.3 Justification ................................................................................................................ 19
4.1.3.1 Battery / Time in Air .......................................................................................... 19
4.1.3.2 Durability / Replacement Parts ......................................................................... 20
4.1.3.3 Wind Resistance ................................................................................................. 20
4.1.3.4 Cost .................................................................................................................... 21
4.1.3.5 Ease of Use ........................................................................................................ 21
4.1.3.6 Maneuverability ................................................................................................. 22
4.1.3.7 Expandable Platform ......................................................................................... 23
4.1.3.8 Safety.................................................................................................................. 24
4.1.4 Best Solution .............................................................................................................. 25
4.1.4.1 Recognized Weaknesses ..................................................................................... 25
4.2 Concept Art ....................................................................................................................... 25
4.3 Overall System Block Diagram ........................................................................................ 26
4.4 Feature Matrix................................................................................................................... 28
4.5 Feature Descriptions ......................................................................................................... 28
4.5.1 Mechanical ................................................................................................................. 28
4.5.1.1 Strong Frame ..................................................................................................... 28
4.5.1.2 Propeller Guards ............................................................................................... 28
4.5.1.3 Robust Landing Gear ......................................................................................... 28
4.5.1.4 Crash Protection ................................................................................................ 28
4.5.1.5 Reach an Air Speed of 50 km/hr ........................................................................ 29
4.5.1.6 Rainproof ........................................................................................................... 29
4.5.2 Control ....................................................................................................................... 29
4.5.2.1 Motor Control .................................................................................................... 29
4.5.2.2 Full Motion Control ........................................................................................... 29
4.5.2.3 Autonomous Following via GPS ........................................................................ 29
4.5.2.4 Full control via GUI .......................................................................................... 29
4.5.2.5 Altitude Control ................................................................................................. 29
4.5.2.6 Automatic Takeoff and Landing ......................................................................... 29
4.5.2.7 Autonomous Following via IR ........................................................................... 29
4.5.3 Communication .......................................................................................................... 29
4.5.3.1 RC for Control ................................................................................................... 30
4.5.3.2 Wi-Fi for Video/GPS .......................................................................................... 30
4.5.3.3 Redundant Communication................................................................................ 30
4.5.3.4 Emergency Communication-Loss Landing ........................................................ 30
4.5.3.5 Total Wi-Fi System............................................................................................. 30
4.5.4 Power System............................................................................................................. 30
4.5.4.1 Battery................................................................................................................ 30
4.5.4.2 Easily Accessible................................................................................................ 30
4.5.4.3 Base Battery Charging....................................................................................... 30
4.5.4.4 Battery Monitoring via GUI............................................................................... 30
4.5.4.5 Extra-Range Battery .......................................................................................... 30
4.5.4.6 Emergency Low-Battery Landing ...................................................................... 31
4.5.4.7 Laser Charging .................................................................................................. 31
4.5.5 Sensors ....................................................................................................................... 31
4.5.5.1 Hovering Sensors ............................................................................................... 31
4.5.5.2 GPS .................................................................................................................... 31
4.5.5.3 Altimeter............................................................................................................. 31
4.5.5.4 Obstacle Avoidance ........................................................................................... 31
4.5.5.5 Speedometer ....................................................................................................... 31
4.5.5.6 Computer Vision for IR Beacon ......................................................................... 31
iii
4.5.6 Video .......................................................................................................................... 31
4.5.6.1 Ability to Take Pictures ...................................................................................... 31
4.5.6.2 Stream Video ...................................................................................................... 32
4.5.6.3 Stream VGA Video to GUI ................................................................................. 32
4.5.6.4 Stream HD Video ............................................................................................... 32
4.5.6.5 Record Video while Streaming........................................................................... 32
4.5.6.6 Horizon to Horizon Field of View ...................................................................... 32
5
Quadcopter Design ........................................................................................................... 33
5.1 Quadcopter Architecture ................................................................................................... 33
5.2 Hardware........................................................................................................................... 34
5.2.1 Tether ......................................................................................................................... 34
5.2.1.1 Requirements ..................................................................................................... 34
5.2.1.2 Alternatives ........................................................................................................ 34
5.2.1.3 Decision Criterion ............................................................................................. 35
5.2.1.4 Decision ............................................................................................................. 35
5.2.1.5 Implementation .................................................................................................. 35
5.2.1.6 Unit Test ............................................................................................................. 35
5.2.2 Propellers ................................................................................................................... 35
5.2.2.1 Requirements ..................................................................................................... 35
5.2.2.2 Alternatives ........................................................................................................ 36
5.2.2.3 Decision Criterion ............................................................................................. 36
5.2.2.4 Decision ............................................................................................................. 36
5.2.2.5 Unit Test ............................................................................................................. 36
5.2.3 Flight Controller......................................................................................................... 36
5.2.3.1 Requirements ..................................................................................................... 36
5.2.3.2 Alternatives ........................................................................................................ 36
5.2.3.3 Decision Criterion ............................................................................................. 37
5.2.3.4 Decision ............................................................................................................. 37
5.2.3.5 Implementation .................................................................................................. 37
5.2.3.6 Unit Test ............................................................................................................. 37
5.2.4 Motors ........................................................................................................................ 38
5.2.4.1 Requirements ..................................................................................................... 38
5.2.4.2 Alternatives ........................................................................................................ 38
5.2.4.3 Decision Criterion ............................................................................................. 38
5.2.4.4 Decision ............................................................................................................. 38
5.2.4.5 Implementation .................................................................................................. 38
5.2.4.6 Unit Test ............................................................................................................. 38
5.2.5 ESCs........................................................................................................................... 39
5.2.5.1 Requirements ..................................................................................................... 39
5.2.5.2 Alternatives ........................................................................................................ 39
5.2.5.3 Decision Criterion ............................................................................................. 39
5.2.5.4 Decision ............................................................................................................. 39
5.2.5.5 Implementation .................................................................................................. 39
5.2.5.6 Unit Test ............................................................................................................. 39
5.2.6 Frame and Landing Gear............................................................................................ 39
5.2.6.1 Requirements ..................................................................................................... 40
5.2.6.2 Alternatives ........................................................................................................ 40
5.2.6.3 Decision Criterion ............................................................................................. 40
5.2.6.4 Decision ............................................................................................................. 40
5.2.6.5 Implementation .................................................................................................. 41
5.2.6.6 Unit Test ............................................................................................................. 41
iv
5.2.7 Battery ........................................................................................................................ 41
5.2.7.1 Requirements ..................................................................................................... 41
5.2.7.2 Alternatives ........................................................................................................ 41
5.2.7.3 Decision Criterion ............................................................................................. 42
5.2.7.4 Prototype Decision............................................................................................. 42
5.2.7.5 Production Decision .......................................................................................... 42
5.2.7.6 Unit Test ............................................................................................................. 42
5.2.8 Power Distribution System ........................................................................................ 42
5.2.8.1 Requirements ..................................................................................................... 42
5.2.8.2 Alternatives ........................................................................................................ 42
5.2.8.3 Decision Criteria ............................................................................................... 42
5.2.8.4 Decision ............................................................................................................. 43
5.2.8.5 Implementation .................................................................................................. 43
5.2.8.6 Unit test .............................................................................................................. 43
5.2.9 VGPU......................................................................................................................... 43
5.2.9.1 Requirements ..................................................................................................... 43
5.2.9.2 Alternatives ........................................................................................................ 43
5.2.9.3 Decision Criterion ............................................................................................. 44
5.2.9.4 Decision ............................................................................................................. 44
5.2.9.5 Implementation .................................................................................................. 44
5.2.9.6 Unit Test ............................................................................................................. 44
5.2.10 Camera ..................................................................................................................... 44
5.2.10.1 Requirements ................................................................................................... 44
5.2.10.2 Alternatives ...................................................................................................... 44
5.2.10.3 Decision Criterion ........................................................................................... 45
5.2.10.4 Decision ........................................................................................................... 45
5.2.10.5 Implementation ................................................................................................ 45
5.2.10.6 Unit Test ........................................................................................................... 45
5.3 Software ............................................................................................................................ 45
5.3.1 Flight Controller......................................................................................................... 45
5.3.2 Video Streaming ........................................................................................................ 45
6
Base Station Design .......................................................................................................... 47
6.1 Base Station Architecture ................................................................................................. 47
6.2 Hardware........................................................................................................................... 48
6.2.1 Base Station Computer............................................................................................... 48
6.2.1.1 Requirements ..................................................................................................... 48
6.2.1.2 Alternatives ........................................................................................................ 49
6.2.1.3 Decision Criterion ............................................................................................. 49
6.2.1.4 Decision ............................................................................................................. 49
6.2.1.5 Implementation .................................................................................................. 49
6.2.1.6 Unit Test ............................................................................................................. 49
6.2.2 Wireless Router .......................................................................................................... 49
6.2.2.1 Requirements ..................................................................................................... 49
6.2.2.2 Alternatives ........................................................................................................ 50
6.2.2.3 Decision Criterion ............................................................................................. 50
6.2.2.4 Decision ............................................................................................................. 50
6.2.2.5 Implementation .................................................................................................. 50
6.2.2.6 Unit Test ............................................................................................................. 50
6.2.3 GPS Module ............................................................................................................... 50
6.2.3.1 Requirements ..................................................................................................... 50
6.2.3.2 Alternatives ........................................................................................................ 51
v
6.2.3.3 Decision Criterion ............................................................................................. 51
6.2.3.4 Decision ............................................................................................................. 51
6.2.3.5 Implementation .................................................................................................. 51
6.2.3.6 Unit Test ............................................................................................................. 51
6.2.4 RC Transmitter........................................................................................................... 51
6.2.4.1 Requirements ..................................................................................................... 51
6.2.4.2 Alternatives ........................................................................................................ 51
6.2.4.3 Decision Criterion ............................................................................................. 52
6.2.4.4 Decision ............................................................................................................. 52
6.2.4.5 Implementation .................................................................................................. 52
6.2.4.6 Unit Test ............................................................................................................. 52
6.2.5 RC Interface Module.................................................................................................. 52
6.2.5.1 Requirements ..................................................................................................... 52
6.2.5.2 Alternatives ........................................................................................................ 52
6.2.5.3 Decision Criterion ............................................................................................. 53
6.2.5.4 Decision ............................................................................................................. 53
6.2.5.5 Implementation .................................................................................................. 53
6.2.5.6 Unit Test ............................................................................................................. 53
6.3 Software ............................................................................................................................ 54
6.3.1 Graphical User Interface ............................................................................................ 54
6.3.1.1 Requirements ..................................................................................................... 54
6.3.1.2 Alternatives ........................................................................................................ 54
6.3.1.3 Decision Criterion ............................................................................................. 54
6.3.1.4 Decision ............................................................................................................. 54
6.3.1.5 Implementation .................................................................................................. 54
6.3.1.6 Unit Test ............................................................................................................. 54
6.3.2 Autopilot Code ........................................................................................................... 55
6.3.2.1 Requirements ..................................................................................................... 55
6.3.2.2 Alternatives ........................................................................................................ 55
6.3.2.3 Decision Criterion ............................................................................................. 55
6.3.2.4 Decision ............................................................................................................. 56
6.3.2.5 Implementation and Unit Test ............................................................................ 56
7
System Integration and Testing ........................................................................................ 57
7.1 Video Streaming to GUI ................................................................................................... 57
7.1.1 Basic Video Test ........................................................................................................ 57
7.1.1.1 Equipment .......................................................................................................... 57
7.1.1.2 Setup................................................................................................................... 57
7.1.1.3 Steps ................................................................................................................... 57
7.1.1.4 Methods of Measurement ................................................................................... 57
7.1.1.5 Definition of Success .......................................................................................... 57
7.1.2 Latency Test ............................................................................................................... 57
7.1.2.1 Equipment .......................................................................................................... 57
7.1.2.2 Setup................................................................................................................... 57
7.1.2.3 Steps ................................................................................................................... 58
7.1.2.4 Methods of Measurement ................................................................................... 58
7.1.2.5 Definition of Success .......................................................................................... 58
7.1.3 Distance Test .............................................................................................................. 58
7.1.3.1 Equipment .......................................................................................................... 58
7.1.3.2 Setup................................................................................................................... 58
7.1.3.3 Steps ................................................................................................................... 58
7.1.3.4 Methods of Measurement ................................................................................... 58
vi
7.1.3.5 Definition of Success .......................................................................................... 58
7.2 Tracking Base Station ....................................................................................................... 58
7.2.1 Single Location Tracking ........................................................................................... 58
7.2.1.1 Equipment .......................................................................................................... 59
7.2.1.2 Setup................................................................................................................... 59
7.2.1.3 Steps ................................................................................................................... 59
7.2.1.4 Methods of Measurement ................................................................................... 59
7.2.1.5 Definition of Success .......................................................................................... 59
7.2.2 Slow Dynamic Location Tracking ............................................................................. 59
7.2.2.1 Equipment .......................................................................................................... 59
7.2.2.2 Setup................................................................................................................... 59
7.2.2.3 Steps ................................................................................................................... 59
7.2.2.4 Methods of Measurement ................................................................................... 59
7.2.2.5 Definition of Success .......................................................................................... 60
7.2.3 Full Maneuverability Test .......................................................................................... 60
7.2.3.1 Equipment .......................................................................................................... 60
7.2.3.2 Setup................................................................................................................... 60
7.2.3.3 Steps ................................................................................................................... 60
7.2.3.4 Methods of Measurement ................................................................................... 60
7.2.3.5 Definition of Success .......................................................................................... 60
7.3 Manual Control through Base Station............................................................................... 60
7.3.1 Control Via Base Station Computer........................................................................... 60
7.3.1.1 Equipment .......................................................................................................... 60
7.3.1.2 Setup................................................................................................................... 61
7.3.1.3 Steps ................................................................................................................... 61
7.3.1.4 Methods of Measurement ................................................................................... 61
7.3.1.5 Definition of Success .......................................................................................... 61
7.3.1.6 Control Via Base Station GUI ........................................................................... 61
7.3.1.7 Equipment .......................................................................................................... 61
7.3.1.8 Setup................................................................................................................... 61
7.3.1.9 Steps ................................................................................................................... 61
7.3.1.10 Methods of Measurement ................................................................................. 61
7.3.1.11 Definition of Success ........................................................................................ 61
7.4 Communication Redundancies ......................................................................................... 61
7.5 Complete System Testing ................................................................................................. 62
7.5.1 System Integration Test ............................................................................................. 62
7.5.1.1 Equipment .......................................................................................................... 62
7.5.1.2 Setup................................................................................................................... 62
7.5.1.3 Steps ................................................................................................................... 62
7.5.1.4 Methods of Measurement ................................................................................... 62
7.5.1.5 Definition of Success .......................................................................................... 62
8
Project Management ......................................................................................................... 63
8.1 Documentation Organization ............................................................................................ 63
8.1.1 Demos ........................................................................................................................ 63
8.1.2 Design Journals .......................................................................................................... 63
8.1.3 Manuals ...................................................................................................................... 63
8.1.4 Miscellaneous Notes .................................................................................................. 63
8.1.5 Planning Documents .................................................................................................. 63
8.1.6 Presentations .............................................................................................................. 64
8.1.7 Source ........................................................................................................................ 64
8.1.8 Status Reports ............................................................................................................ 64
vii
8.1.9 Tests ........................................................................................................................... 64
8.1.10 Team08: Turn-in ...................................................................................................... 64
8.2 Team Organization ........................................................................................................... 64
8.2.1 Technical Assignments (Design Areas) ..................................................................... 64
8.2.1.1 Quadcopter ........................................................................................................ 65
8.2.1.2 Power Management ........................................................................................... 65
8.2.1.3 GPS Sent From Quadcopter .............................................................................. 66
8.2.1.4 Tracking Algorithm ............................................................................................ 66
8.2.1.5 RC Commands ................................................................................................... 66
8.2.1.6 GUI .................................................................................................................... 66
8.2.1.7 Video Streaming ................................................................................................. 66
8.2.1.8 Alternate Tracking (Time Allowing) .................................................................. 66
8.2.2 Management Assignments ......................................................................................... 66
8.2.3 Working Guidelines ................................................................................................... 67
8.2.4 Safety Guidelines ....................................................................................................... 67
8.2.5 Team Communication and Accountability ................................................................ 67
8.3 Schedule and Work Breakdown Schedule ........................................................................ 68
8.3.1 Hours Summary ......................................................................................................... 68
8.3.2 Milestones .................................................................................................................. 69
8.3.2.1 Oct 14 - First Presentation ................................................................................ 69
8.3.2.2 Oct 31 - First Flight and Streaming Video ........................................................ 69
8.3.2.3 Dec 2 - Second presentation .............................................................................. 69
8.3.2.4 Dec 6 - Initial Prototype .................................................................................... 69
8.3.2.5 Dec 9 - PPFS ..................................................................................................... 69
8.3.2.6 Mar 5 - Third Presentation ................................................................................ 69
8.3.2.7 May 5 - Fourth Presentation.............................................................................. 69
8.3.2.8 April 11- Final Prototype................................................................................... 69
8.3.2.9 May 10 - Final Presentation .............................................................................. 69
8.3.2.10 May 14 - Final Report...................................................................................... 69
8.3.3 Feasibility of Schedule ............................................................................................... 69
8.4 Operational Budget ........................................................................................................... 69
8.4.1 Project Cost Projections ............................................................................................. 69
8.4.2 Sources of Funding .................................................................................................... 70
8.5 Method of Approach ......................................................................................................... 70
8.5.1 Design Methodology .................................................................................................. 70
8.5.2 Research Techniques.................................................................................................. 71
9
Business Plan .................................................................................................................... 72
9.1 Overview ........................................................................................................................... 72
9.2 Vision and Mission Statement .......................................................................................... 72
9.3 Vision for the Company .................................................................................................... 72
9.4 Values and Principles on which the Business Stands ....................................................... 72
9.5 Marketing Study ............................................................................................................... 72
9.5.1 How Large is the Market ........................................................................................... 73
9.5.2 Is it Growing or Shrinking? ....................................................................................... 73
9.5.3 Regulatory Restrictions .............................................................................................. 73
9.5.4 Barriers to Entry and Exit .......................................................................................... 73
9.5.5 Key Success Factors in the Industry .......................................................................... 73
9.6 Competition ...................................................................................................................... 74
9.6.1 Existing Competitors ................................................................................................. 74
9.6.1.1 Hex AirBot ......................................................................................................... 74
9.6.1.2 DJI ..................................................................................................................... 74
viii
9.6.1.3 FireBox .............................................................................................................. 74
9.6.1.4 Lockheed Martin ................................................................................................ 74
9.6.1.5 Walkera .............................................................................................................. 74
9.6.2 Potential Competitors................................................................................................. 75
9.6.2.1 Northrop Grumman ........................................................................................... 75
9.6.2.2 AII Corp ............................................................................................................. 75
9.6.2.3 SightLogix .......................................................................................................... 75
9.7 Business Model ................................................................................................................. 75
9.7.1 Desired Image and Position in the Market ................................................................. 75
9.7.2 Company Goals and Objectives ................................................................................. 75
9.7.2.1 Operational ........................................................................................................ 75
9.7.2.2 Financial ............................................................................................................ 76
9.7.2.3 Other .................................................................................................................. 76
9.7.3 SWOT Analysis ......................................................................................................... 76
9.7.3.1 Internal Strengths .............................................................................................. 76
9.7.3.2 Internal Weaknesses........................................................................................... 76
9.7.3.3 External Opportunities....................................................................................... 76
9.7.3.4 External Threats ................................................................................................ 76
9.7.4 Competitive Strategy ................................................................................................. 76
9.7.4.1 Differentiation .................................................................................................... 76
9.7.4.2 Focus.................................................................................................................. 77
9.8 Financial Forecasts ........................................................................................................... 77
9.8.1 Key Assumptions ....................................................................................................... 77
9.8.2 Financial Statements .................................................................................................. 78
9.8.2.1 Income Statement ............................................................................................... 78
9.8.2.2 Cash Flow Statement ......................................................................................... 79
9.8.3 Break-Even Analysis ................................................................................................. 80
9.8.4 Ratio Analysis ............................................................................................................ 80
9.9 Summary ........................................................................................................................... 81
10
Conclusion ........................................................................................................................ 82
10.1
Major Risks & Issues .................................................................................................. 82
10.2
Project Status............................................................................................................... 82
10.3
Project Feasibility ....................................................................................................... 82
10.3.1 Technical Aspects .................................................................................................... 82
10.3.2 Costs......................................................................................................................... 83
10.3.3 Time Spent ............................................................................................................... 83
10.4
Summary ..................................................................................................................... 83
ix
Table of Figures
Figure 1: Team Photo (left to right) - Jared Zoodsma, Robert Hoff, Drew Brandsen, Spencer Olson. ........ 1
Figure 2: 2-D Horizontal Distance Requirement .......................................................................................... 8
Figure 3: Quadcopter Outfitted With Cameras ........................................................................................... 15
Figure 4: RC Helicopter .............................................................................................................................. 16
Figure 5: RC Airplane ................................................................................................................................. 16
Figure 6: RC Blimp ..................................................................................................................................... 17
Figure 7: Panoramic Ball Camera ............................................................................................................... 17
Figure 8: Control of a Quadcopter .............................................................................................................. 22
Figure 9: Platform Area of a Quadcopter.................................................................................................... 23
Figure 10: Concept Art of Design Solution ................................................................................................ 25
Figure 11: Overall System Block Diagram ................................................................................................. 26
Figure 12: Quadcopter Architecture Block Diagram .................................................................................. 33
Figure 13: AutoCAD Representation of Tether (left) and Photo of Actual Implementation (right)........... 35
Figure 14: Broken Arm ............................................................................................................................... 41
Figure 15: Base Station Architecture Block Diagram................................................................................. 47
Table of Tables
Table 1: Project Deliverables ...................................................................................................................... 13
Table 2: Decision Matrix ............................................................................................................................ 19
Table 3: System Block Diagram Interface Descriptions ............................................................................. 27
Table 4: Feature Matrix .............................................................................................................................. 28
Table 5: Quadcopter Block Diagram Interface Descriptions ...................................................................... 34
Table 6: Flight Controller Alternatives ....................................................................................................... 37
Table 7: Component Power Needs.............................................................................................................. 42
Table 8: Base Station Architecture Interface Descriptions ......................................................................... 48
Table 9: RC Interface Module Alternatives ................................................................................................ 53
Table 10: Design Areas and Team Member Assignments .......................................................................... 65
Table 11: Summary of Hours ...................................................................................................................... 68
Table 12: Budget Request ........................................................................................................................... 70
Table 13: Supporting Calculations .............................................................................................................. 78
Table 14: Income Statement ....................................................................................................................... 79
Table 15: Cash Flow Statement .................................................................................................................. 79
Table 16: Break-Even Analysis .................................................................................................................. 80
Table 17: Ratio Analysis ............................................................................................................................. 81
x
Table of Acronyms
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
2-D: Two Dimensional
3-D: Three Dimensional
ABET: Accreditation Board for Engineering and Technology
APM: ArduPilot Mega
BEC: Battery Eliminator Circuit
ESC: Electronic Speed Controller
FPS: Frames Per Second
GPS: Global Positioning System
GUI: Graphical User Interface
HD: High Definition
IED: Improvised Explosive Device
I/O: Input/Output
IR: Infrared
Kv: Revolutions Per Minute / Volts
km/hr: Kilometer Per Hour
MPH: Miles Per Hour
NMEA: National Marine Electronics Association
PC: Personal Computer
PCB: Printed Circuit Board
PID: Proportional-Integral-Derivative
PPFS: Project Proposal and Feasibility Study
PWM: Pulse Width Modulation
Q&A: Question and Answer
RAM: Random Access Memory
RC: Radio Controlled
RPG: Rocket Propelled Grenade
SD: Standard Definition
SSH: Secure Shell
SWOT: Internal Strengths and Weaknesses, External Opportunities and Threats.
TBD: To Be Determined
TCP/IP: Transmission Control Protocol/Internet Protocol
U.S.: United States of America
UAV: Unmanned Aerial Vehicle
USB: Universal Serial Bus
VDC: Volts Direct Current
VGA: Video Graphics Array
VGPU: Video and GPS Processing Unit
WBS: Work Breakdown Structure
xi
1
Introduction
The Calvin College Engineering Program concludes its four-year degree with a Senior Design
Capstone project. This project spans the entire senior year, giving students the opportunity to use
knowledge and skills accumulated throughout their academic career. It also allows students to work on a
project in their area of interest, from conception to final prototype. Teams of three or four are formed
around a common project idea. These teams may contain students from the same or multiple
concentrations, as the project allows. This Project Proposal and Feasibility Study explores the feasibility
of our chosen project, provides a structured plan for the design, and is a milestone for the project to
continue into the design and implementation phase.
1.1
Calvin College Engineering Department
Calvin College’s Engineering Program is ABET accredited and offers a Bachelor of Science in
Engineering with concentrations in Chemical, Civil/Environmental, Electrical/Computer, and Mechanical
engineering. The program also offers the option 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 of technology in engineering.” The program also
“challenge[s] you to do all of [engineering] from a reformed Christian worldview”.1
1.2
Team Member Biographies
The Eagleye team is composed of four senior engineering students in the Electrical & Computer
concentration. The team learned about a safety application involving autonomous tracking from their
faculty advisor, deciding to pursue it due to their passion for autonomous vehicles and
quadcopters. Figure 1 shows the team picture.
Figure 1: Team Photo (left to right) - Jared Zoodsma, Robert Hoff, Drew Brandsen, Spencer Olson.
1
Below is a brief biography of each team member:
1. Jared Zoodsma
Jared hails from Grandville, Michigan where he attended Calvin Christian High School. Jared
serves as the team financial manager and is in charge of researching and ordering components. In addition
to his team role, Jared will primarily focus on creating a GUI for the user, video streaming to the GUI,
sending GPS from the quadcopter, and tracking algorithms. Jared enjoys working on his car, following
Michigan football, and playing sports such as soccer, frisbee, and golf.
2. Robert Hoff
Serving as Chief Marketing Manager, Robert is in charge of team media including posters,
website, and all other graphical design. Robert’s technical design areas are quadcopter flight, GPS
tracking algorithms, sending flight commands to the quadcopter, and power management. Robert enjoys
working and tinkering with electronics, learning about technology, and is an amateur photographer in his
free time.
3. Drew Brandsen
Drew Brandsen calls the great lakeside city of Holland, Michigan home. He is serving as the
Professional Officer; assuring that all documents and materials are organized and of the utmost
quality. On the technical side, Drew is responsible for quadcopter flight, GPS tracking algorithms, power
management, and communication from the quadcopter to the base station. He enjoys spending time with
friends, sailing, and playing intramural sports. Drew is excited for this project, its challenges, and its
future implications.
4. Spencer Olson
Acting as Project Manager, Spencer is in charge of keeping the team on track for deadlines set by
the faculty adviser, as well as setting intermediate deadlines. He is also working on the video streaming
and integration into the GUI, as well as the tracking algorithms and resulting flight controls from the base
station. In his free time, Spencer enjoys playing golf, camping, running, and watching sports (especially
Minnesota and Calvin teams).
1.3
Report Format
This report will detail the project proposal and feasibility of the project. Below are listed each of
the following chapters in the report, along with a brief description of each. At the end of the report, the
feasibility of the project is stated. References are available at the end of this document.

Chapter 2: Acknowledgements
This chapter acknowledges everyone who helped make this project a reality.

Chapter 3 Project Requirements
Chapter 3 covers the requirements of the project, both in terms of a final product and first
prototype that the team will complete.
2

Chapter 4: System Design
Chapter 4 evaluates different alternatives for implementing a solution based on design
criteria and project requirements. This chapter will show how the team reached their
final decisions.

Chapter 5: Quadcopter Design
Chapter 5 discusses the quadcopter design and breaks down the requirements,
alternatives, decision criterion, and final decision for each quadcopter component. This
Chapter also discusses implementation and tests for each component.

Chapter 6: Base System Design
Chapter 6 discusses the base system design. This section also breaks down each
component for its requirements, alternatives, decision criterion, and final decision. Each
component also has implementation and test details.

Chapter 7: System Integration and Testing
Chapter 7 discusses how the various subsystems will be integrated, and how testing will
determine if each of those subsystems are performing their respective tasks. The team
will also complete testing on the entire system to ensure its performance is meeting the
requirements.

Chapter 8: Project Management
This chapter explains the roles of each member of the project. In addition, it outlines
project organization and an anticipated timeline for the project.

Chapter 9: Business Plan
The business plan lays a potential startup company and evaluates how this company
could make a profit by selling this product.

Chapter 10: Conclusion
The final chapter will close out the PPFS. It discusses the risks and current issues in the
project, the current status, and lastly the feasibility of the project.
1.4
Design Norms
During the course of the project, the team has taken to heart four main design norms that have
shaped the project. Below are short descriptions of each of the design norms. The team has integrated
these design norms into all of our decisions. There are definitely conflicts with these design norms,
however. For example, providing a high level of justice may result in lowered transparency. If this
project was created for the U.S. military, the information would become classified and no longer available
to the general public. This creates tensions within these norms that necessitates a balancing act by the
team as work continues on this project.
1.4.1
Transparency
Transparency has also come into play as video taking drones are commonly highlighted in
privacy concerns. The team will take whatever action necessary to prove that the video taken is for
responsible uses and does not show any disrespect toward another party.
3
1.4.2
Justice
The system should be a means of achieving justice, particularly when those who are serving our
country are involved. The team has made it a goal to protect those who protect and lead us.
1.4.3
Trust
The quadcopter should be dependable in all situations. This means that within the defined flying
conditions and under the correct circumstances, the device will function stably and reliably.
4
2
Acknowledgements
The team would like to take this opportunity to thank those who have helped make this project a
success. First, the team would like to thank DornerWorks for sponsoring the project through a donation.
This donation from DornerWorks has been a tremendous step in helping the team fund their complete
budget. In addition, the team would like to thank their faculty advisor, Professor Steve VanderLeest, who
has been influential in providing guidance and direction to the project. Next, the group would like to
thank the Calvin College Engineering program as a whole for supporting successful projects with finances
and challenging students to strive toward stronger projects. The team would also like to thank Professor
Yoon Kim for allowing them to run tests on his quadcopter and use parts of it for the project. Jeff
Kloosterman also deserves a special thank you for allowing the team to use parts of his quadcopter while
parts were on order for our own, and for advice on ordering parts. Andrew Jo also deserves thanks for his
significant contribution to the business plan. Lastly, we would like to thank our families for their
continued love and support in our education and personal development.
5
3
Project Requirements
This chapter identifies potential customers, defines customer requirements, and establishes a list
of deliverables for the customer. Following the requirements, the next chapter will discuss the team’s
solution to this problem.
3.1
Problem Statement
In the United States, and in countries where our military is present, there is a constant need for
military convoys where supplies and troops move along large distances. In any situation where a large
distance must be traversed, there is a potential opportunity for attack by those who wish to do us
harm. Potential dangers can take the shape of snipers of buildings, insurgents with RPGs, or even
improvised explosive devices. Covering tens or even hundreds of miles with explosive detectors, bombsniffing dogs, or law enforcement is not only costly, but also impractical. In addition, times when a
convoy stops present the greatest threat to troops because they are a stationary target in unfamiliar
territory.2
Similarly, to military convoys, diplomatic motorcades must traverse a long area where would-be
attackers have plenty of opportunities to hide improvised explosive devices or human
attackers. Preparing a route for a motorcade to travel takes days and even weeks to prepare for, requiring
the use of bomb sniffing dogs, and other costly resources.3 Even when the entire route is planned and
secured, there is always the chance of using an unplanned route, creating an uncertainty that could lead to
danger.
3.1.1
Solution
The solution that our team proposes provides a birds-eye view of the surroundings of a motorcade
or convoy, enabling users to spot would-be attackers and IEDs. By providing this second viewpoint,
more information is collected about the surroundings. This information will lead to much better
awareness. While the solution proposed in this system is not meant for use in direct combat, it provides
one more piece of information that ultimately leads to justice and safety for those who need the
protection.
3.1.2
Target Customers
Our solution targets organizations or individuals with a need for security while traveling in a land
vehicle. Since the solution will be capable of following a vehicle at driving speeds under 50 km/hr (31
MPH), our customers will include diplomats, the Secret Service and the U.S. Military. The team will
design the system to bolster security for those with this need, particularly those who serve our
country. The team considers it a just cause to protect others from individuals with malicious intent.
3.2
Customer Requirements
This section articulates customer-defined requirements by sub-sections such as performance,
mechanical features, and customer use. These requirements are defined generally here, and are applied
more specifically for the chosen solution in chapters five and six.
3.2.1
Performance
These requirements define the performance of the system such as flight time and maneuverability.
6
3.2.1.1
Flight time
REQ 3.2.1.1.A: The system shall stay aloft for a minimum time of twenty minutes.
We chose this time as the shortest journey that our customer might take where they would expect the
product to operate continuously without a recharge. Anything less and the customer would likely
consider it difficult and cumbersome to use.
3.2.1.2
Flight Performance
REQ 3.2.1.2.A The system shall move from one point in three-dimensional space to another in a straight
line.
This is necessary in order to provide a high degree of maneuverability.
REQ 3.2.1.2.B The system shall hover within TBD of a position in the X and Y directions when the
vehicle is stopped.
The team will complete research pertaining this requirement during second semester.
REQ 3.2.1.2.C The airborne component’s airspeed shall be no less than 50 km/hr (31 MPH).
The system will give an aerial view of a vehicle’s surrounding. It is possible the vehicle will be traveling
too quickly for the video information to be useful. 50 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.4
REQ 3.2.1.2.C.P1 The delivered prototype shall have a top air speed of no less than 15 km/hr (9.3
MPH).
A speed of 15 km/hr (9.3 MPH) will allow the team to produce a prototype that demonstrates the
product’s potential and provides a good platform for testing – without purchasing larger, more expensive
motors to reach higher speeds.
REQ 3.2.1.2.D The solution shall have a 2-D tracking tolerance of 1.8 meters (6 ft) from a point
horizontal from the source location to a point directly vertical of the destination location.
This was chosen, as it is half the width of a standard road lane size.5 Thus, the system will stay within the
same lane as the vehicle it is following.
REQ 3.2.1.2.D.P1 The solution shall have a 2-D tracking tolerance of 3 meters (9.8 ft) from a
point horizontal from the source location to a point directly vertical of the destination location.
A 3 meter (9.8 ft) radius was chosen for the prototype to account for the precision of tracking
devices. See Figure 2 for a visual explanation.
7
Figure 2: 2-D Horizontal Distance Requirement
REQ 3.2.1.2.E The system shall have an altitude tolerance no greater than TBD in the Z direction.
The team will complete research pertaining to this requirement during second semester.
REQ 3.2.1.2.F The system shall fly as far as 200 meters (656 ft) from the vehicle without losing
communication.
200 meters (656 ft) is the common size of a city block in the United States and elsewhere. This distance
would allow the system to investigate the next intersection as the vehicle enters a new block.6
REQ 3.2.1.2.F.P1 The system shall fly as far as 100 meters (328 ft) from the vehicle without
losing communication.
100 meters (328 ft) is considered a good starting place for the first prototype.
3.2.1.3
Environment
REQ 3.2.1.3.A The system shall operate fully in the military temperature range of -55 to 125 degrees
Celsius (-67 to 257 degrees Fahrenheit).
Since the system is designed for military applications, the typical operating temperatures for military
grade equipment will be used.
REQ 3.2.1.3.A.P1 The delivered prototype shall operate fully in a temperature range of 0 to 70
degrees Celsius (32 to 158 degrees Fahrenheit).6
In an effort to keep budget low, the team will use commercial grade parts. These parts are only
qualified for the above temperature range.
REQ 3.2.1.3.B Humidity: the system shall fly at all humidity levels.
The humidity and condensation levels will not ground the device.
8
REQ 3.2.1.3.B.P1 Humidity: the system shall fly at any temperature at which the ambient
temperature is above the dew point.
The humidity tolerated by the project will be any level at which there is no condensation. This
means that the actual relative humidity will vary based on the temperature.
REQ 3.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 will
limit visibility and potentially be destructive to system components.
REQ 3.2.1.3.C.P1 Not required for the prototype.
This is similar to the humidity requirement, and though possible, is not required for the prototype.
Testing the effects of dust, even on individual components such as motors, potentially adds costs to
replace any broken components. The team is unable to afford these additional components for testing
given the tight budget constraints for the first prototype.
REQ 3.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 the
view of the vehicle on the ground.
REQ 3.2.1.3.D.P1 There is no smoke requirement for the first prototype
In order to view video in a smoky environment, a second IR camera would be necessary, which is
outside the budgetary constraints of the first prototype.
REQ 3.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 (65 MPH) is the
lowest bound for a tornado.7 The system is expected to be useful in less than ideal weather conditions,
but flying at tornado-like wind speeds is not expected.
REQ 3.2.1.3.E.P1 The first prototype shall be able to withstand wind speeds up to 27 km/hr (17
MPH).
The first prototype shall be able to withstand the average wind speed at its production site; Grand
Rapids, MI.8
REQ 3.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 which
this system will be used. The system must avoid these obstacles without user intervention.
REQ 3.2.1.3.F.P1 There is no obstacle avoidance required for the first prototype
Due to cost and time constraints, obstacle avoidance will not be explored in the first prototype.
However, the team understands that this is essential for this system to meet its full utilization.
9
3.2.1.4
Video Performance
REQ 3.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 of the highest
quality.
REQ 3.2.1.4.A.PI The first prototype 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 of
concept.
REQ 3.2.1.4.B The system shall capture video with at least TBD frames per second.
The team will determine the required fps second semester. This number will be based on the typical
reaction time of a human to a visual response, as well as the amount of time needed to react to various
threats.
REQ 3.2.1.4.C The system shall have a horizon to horizon 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 the
potential threats.
REQ 3.2.1.4.C.P1 There is no minimum field of view requirement for the first prototype.
So long as the system is able to send video, proof of concept will be achieved. A more expensive
camera can be purchased with a wider camera angle to reach the final requirement.
REQ 3.2.1.4.D The system shall have a video feed with a latency of under TBD seconds (from the time
the video is captured on the quadcopter, the video feed should display on the GUI within TBD seconds).
The team will determine the required maximum latency (TBD) next semester. This will be based on the
necessary reaction time required for various threats.
3.2.2
Physical
These requirements deal with the mechanical size and durability of the solution.
3.2.2.1
Platform
REQ 3.2.2.1.A The system shall have a mechanical platform to mount components such as cameras,
sensors, communications, and other features.
This is necessary in order to achieve video streaming and tracking.
3.2.2.2
Size
REQ 3.2.2.2.A The system shall fit into the back of a vehicle, taking up no more than a total space of 1.3
x 1.3 x 0.4 meters (4.25 x 4.25 x 1.3 feet)
10
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.
3.2.2.3
Weight
REQ 3.2.2.3.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 23 kg
(51 lbs).9
3.2.2.4
Reparability
REQ 3.2.2.4.A The system will have a modular design such that all components, with the exception of
individual components on a PCB, are replaced with only the need of a screwdriver and Allen wrench.
Due to the crash prone nature of the solution, the solution should be easily repairable.
3.2.3
Customer Use
The following are requirements for how the system will interact with the customer.
3.2.3.1
Ease of Use
REQ 3.2.3.1.A The system as a whole shall be simple.
This allows the user to focus on the results of the system (the video stream from above) and not
controlling the system. For security customers, this provides a level of justice in that this product should
never increase the danger of a situation.
REQ 3.2.3.1.B Training for the device shall be minimal.
The device shall be intuitive to use and the training shall not require an engineering background.
3.2.3.2
Safety
REQ 3.2.3.2.A The system shall not cause injury to the user.
Since the system is designed to be a safety solution, the system should not be a source of injury itself.
REQ 3.2.3.2.B A loss of communication shall result in a deterministic action by the system.
In the event that communication is lost, the system will perform a predetermined action that will
minimize damage to the system and injury to others.
3.2.4
User
The following requirements are for the interaction of the user with the system.
3.2.4.1
User-System Interaction
REQ 3.2.4.1.A The user shall view video feed within a GUI on the base station.
11
These statistics will provide valuable information to the user on the flight of the system, even when they
cannot physically see the system themselves.
REQ 3.2.4.1.B The user shall view flight statistics including at least battery life (remaining flight time in
minutes), altitude (in meters or in feet, 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 they
cannot physically see the system themselves.
REQ 3.2.4.B.1.P1 The first prototype GUI shall display video.
Since the first prototype is simply a proof of concept, video feed will be the only requirement for
the GUI. Other flight statistics are deemed as stretch goals for proof of concept purposes.
REQ 3.2.4.1.C The user shall be able to manually override the autopilot from the GUI.
This will allow the user to fly the system outside of the normal tracking parameters, and allow uses such
as arriving at an intersection before the convoy or scanning a general area.
REQ 3.2.4.1.C.PI The first prototype 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 stationary
hovering.
REQ 3.2.4.1.D The user shall be able to arm and disarm the system when it is on the ground and the
throttle is turned down.
It is necessary for safety purposes to have a disarmed system that is still powered on. This will only be
performed once the device is no longer airborne.
REQ 3.2.4.1.E The user shall be able to power on and off the device when it is on the ground and
disarmed.
This important control must be available to the user.
12
3.3
Deliverables
The team will provide a variety of deliverables throughout the project including reports, web
material, and prototypes. Table 1 below shows a list of the major deliverables with this project, along with
their estimated time to completion and cost.
Table 1: Project Deliverables
Deliverable
Time (hrs)*
Cost*
10
N/A
Presentation 2
Second presentation of the project; including a project brief,
feasibility, and current status; seven to nine minutes with one
minute Q&A.
10
N/A
Team Website
Team website that has team overview, project details,
progress, and documentation. Resides on Calvin Engineering
webpage; updated regularly.
30
N/A
Team Poster
Team poster that describes the team and gives an overview of
the project; updated regularly.
15
N/A
PPFS
Defines the project proposal and the feasibility of the project,
includes requirements, budget, management, and current
status to name a few.
90
N/A
Initial Prototype
Prototype completed by the end of first semester; includes a
flying quadcopter (provided by Professor Yoon Kim), video
streaming over Wi-Fi, some tracking and control research, and
a basic GUI.
170
$144.00
10
10
Included in
Prototype
time
N/A
N/A
Presentation 1
Presentation 3
Presentation 4
Explanation
Initial presentation of the project providing an initial overview;
five minutes with one minute Q&A.
The third presentation of the project.
The final in-class presentation of the project
Design
Notebooks
Design notebooks that are completed individually documenting
the design process of each team member.
Final Prototype
Final prototype of the project; includes a complete quadcopter
system with accompanying base station for tracking.
742
$1,311.00
Final Report
Final report of the project; includes many portions of the PPFS
as well as additional design details and other updates.
100
N/A
15
N/A
1202*
$1455.00*
Final
Presentation
Final presentation of the project to be done on Senior Design
Night
Total:
*Estimated Values from WBS and Budget (includes contingency factor of 1.5x)
13
N/A
3.3.1
Fall Semester Deliverables
The first deliverable is this PPFS, which is a description of the problem, the proposed solution,
and a study of whether the project is feasible or not. Also completed by the end of the first semester is an
initial prototype of the design. This prototype includes a quadcopter and some basic video streaming,
along with time spent on tracking and creating a basic GUI. The team webmaster developed a website
that is available for view online that will be updated periodically to track the team’s progress. A team
poster, updated throughout the semester, will highlight the project. The team will also make two project
presentations during the first semester
3.3.2
Spring Semester Deliverables
During second semester, the team will present two more presentations. The website will continue
to receive updates as progress is made. At the end of the year, the team will showcase both a final report
and a prototype to the public at the Calvin College Senior Design Night, with the final report made
available through the team’s website. In addition, each team member will keep an electronic design
notebook documenting what they have done over the year including research, test results, design
drawings, source code, etc. This will also be submitted for review at the end of the year
14
4
System Design
This chapter begins to evaluate different solutions to the problem outlined above. (The team will
continue working next semester with detailed design, further prototyping, and complete system testing,
documenting the results in a follow-up report, the Final Design Report.) The chapter evaluates several
design alternatives and concludes with a final solution. The team determined that a quadcopter and base
station is the best approach to solve the problem. High-level system details are established in this section.
Component-level requirements for the quadcopter and base station are outlined in the following two
chapters.
4.1
Decision Matrix
Before continuing on any further analysis of the problem, the team analyzed different solution
platforms. The team evaluated five potential solutions that are detailed in the following subsections. This section concludes with a decision matrix that summarizes our decision, along with
justifications for the corresponding scores.
4.1.1
Possible Solutions
The five possible solutions are detailed below, followed by the different decision criterion used to
evaluate the solution.
4.1.1.1
Quadcopter
Quadcopters are increasing in popularity for applications ranging from search and rescue to aerial
photography. Quadcopters use four separate arms, each with a rotating propeller in order to achieve
stable 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 a
high maneuverability in the air, quadcopters have proven effective for many common UAV applications
as is highlighted in an article in Popular Mechanics Magazine.10 An example picture of a quadcopter
outfitted with cameras is shown in Figure 3.11
Figure 3: Quadcopter Outfitted With Cameras11
4.1.1.2
RC Helicopter
RC 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 in
the air with relative stability (discussed later).
15
Figure 4: RC Helicopter12
4.1.1.3
RC Airplane
Like RC helicopters, RC airplanes (Figure 5) are not new to the hobby world. A downside to RC
airplanes is the fact that they cannot hover in one place.
Figure 5: RC Airplane13
4.1.1.4
Balloon / Blimp
Another solution to the problem would be to use a balloon or blimp to stream the video, an
example is seen in Figure 6. The device could be towed by a rope or controlled by RC. It is likely that
this type of solution would have a small motor for maneuverability purposes. A factor to consider is the
size (1 m14 to 4.3 m15) of this type of device, making it a very easy target for enemies.
16
Figure 6: RC Blimp14
4.1.1.5
Panoramic Ball Camera
There exists a new consumer product that, when thrown into the air, takes several pictures in each
direction at the maximum altitude.16 The pictures are then loaded onto a computer for viewing and
sometimes stitched together to form a seamless overhead image of the surroundings. The panoramic ball
camera is shown in Figure 7 below. However, this solution was quickly abandoned as it became apparent
this was not practical. Some of the reasons it was deemed impractical include the fact that constant video
would not be provided, users would be exposed when the ball needed to be thrown again, and throwing
and retrieving a ball from a moving vehicle is not feasible.
Figure 7: Panoramic Ball Camera16
17
4.1.2
Decision Criterion
Each of these solutions were compared against eight criteria that the team deemed important to
the problem. Table 2 displays the results of this decision matrix below. Criterion weights are chosen
between one and ten, with ten being the highest weighted. Weight values can be repeated. Scores, on the
other hand, are ranked between one and four with four being the best score. Scores cannot be repeated on
any category.
4.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 a
five due to the customizability of each system. The team did not feel this was a major differentiating
characteristic because battery life and fuel capacity can be easily expanded in most systems.
4.1.2.2
Durability / Replacement Parts
How much abuse each system can take and how easy it is to replace broken parts. Durability and
replacement parts are 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 only has
30 parts, but only three different variety of parts, will score better than a system with 30 unique parts.
4.1.2.3
Wind Resistance
How well the system is able to counteract the effects of light to moderate winds, including wind
gusts. Wind resistance was rated moderately high at a seven due to the conditions in which it will be
used. Often times there will be opposing or cross winds that must not affect the stability of the system.
4.1.2.4
Cost
Expense to design, build, implement, and maintain. Cost was weighted at a four because when it
comes to safety, compromising is not an option. The best parts must be used in order to mitigate failure
whenever possible.
4.1.2.5
Ease of Use
Simplicity, which directly determines the amount of training necessary. Ease of use was
weighted at only a four because it was assumed that the user will have at least some training in the
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.
4.1.2.6
Maneuverability
Stop-start speed, flexibility, hovering, agility, and obstacle avoidance. This category was
weighted at nine out of ten because of the nature of the vehicles it will be following. In many situations,
the convoy the solution will be following will start and stop quickly as well as turn corners and change
directions suddenly to ensure the vehicle remains in the picture frame.
4.1.2.7
Expendable Platform
How easy it is to add cameras, sensors, and tracking hardware to the system. This was weighted
an eight out of ten because of the project’s need to carry a multiple components such as communication
devices and cameras.
18
4.1.2.8
Safety
How dangerous is it for the user to interact with the system in a hostile environment. Interactions
the user could be expected to perform are as follows: launch the device, retrieve the device, and view the
video. This was weighted a ten out of ten because the primary goal of the project is to implement a
solution that leads to increased safety.
Table 2: Decision Matrix
Weight 1-10
Quadcopter
RC
Helicopter
RC
Airplane
Balloon /
Blimp
Battery / Fuel /
Time in Air
5
2
1
3
4
Durability /
Replacement Parts
6
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
Platform
8
4
3
1
2
Safety in Hostile
Environment
10
4
3
2
1
Total:
186
145
99
100
Categories:
4.1.3
Justification
The following sections describe how each solution was scored for each decision criterion.
4.1.3.1
Battery / Time in Air
4.1.3.1.1
Quadcopter
Average flight times for quadcopters with a 2200mAh battery are about 10 minutes.17
4.1.3.1.2
RC Helicopter
Average flight times for a RC helicopter with a 2200mAh battery are around seven minutes.18
4.1.3.1.3
RC Airplane
Average flight times for a RC airplane with a 2200mAh battery are around 20 minutes.19
19
4.1.3.1.4
Balloon / Blimp
Balloons have a very long flight time when compared to the other solutions as it is only limited
by the time it takes to drain the battery from accessories being powered.
4.1.3.1.5
Conclusion
Based on the following results, the RC helicopter came in last with the lowest score, followed
next by the quadcopter, and then the RC airplane. The best score was awarded to the balloon/blimp for its
ability to stay airborne for potentially days.
4.1.3.2
4.1.3.2.1
Durability / Replacement Parts
Quadcopter
Since a quadcopter uses several of the same components (i.e. four motors, four similar arms, etc.)
this makes it easy to swap out broken components. Similar internal electrical components would be used
for a quadcopter, RC helicopter, and a RC airplane. Therefore, these components did not affect durability
ratings. Quadcopters received the second best score.
4.1.3.2.2
RC Helicopter
Similar to a quadcopter, except all components are unique. Therefore, replacement parts receives
a slightly lower score.
4.1.3.2.3
RC Airplane
As discussed in the maneuverability section, RC airplanes have a low maneuverability. For this
reason, it is more likely that a significant crash could happen. Therefore, it scored lower than the
quadcopter and RC helicopter.
4.1.3.2.4
Balloon / Blimp
Balloons received the lowest score since a small tear in the balloon would render the device
useless. Repairs to a torn balloon would not be simple. It would require patching the hole and refilling
the air. In order to refill with air, a user would be required to carry suitable gasses in a compressed state.
4.1.3.2.5
Conclusion
Looking at all of these options, the quadcopter took the highest score, followed next by the RC
helicopter. The RC airplane scored second to last with its higher probability for collisions, followed by
the balloon/blimp because of its large and vulnerable balloon.
4.1.3.3
4.1.3.3.1
Wind Resistance
Quadcopter
Due to quadcopters’ robust control systems, they are able to adjust to changes in their
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 a forward and backward
direction, allowing them to move in all directions at any point.
4.1.3.3.2
RC Helicopter
A RC helicopter would not tolerate gusts as well as a quadcopter due to lower maneuverability
(See maneuverability section below).
20
4.1.3.3.3
RC Airplane
RC airplanes, though quite resistant to steady winds, are not able to quickly adapt to changing
winds as quadcopters can due to the lack of dynamic balancing available.
4.1.3.3.4
Balloon / Blimp
A balloon has little motor control and is completely vulnerable to the slightest change in wind.
Therefore, the blimp received the lowest score in this category.
4.1.3.3.5
Conclusion
The quadcopter came in first due to its small and dense nature. Closely behind was the RC
helicopter, and then the RC airplane. Lastly, again because of its size and limited maneuverability, the
blimp/balloon came in last.
4.1.3.4
Cost
4.1.3.4.1
Quadcopter
A good quadcopter kit can be purchased $599.99.20
4.1.3.4.2
RC Helicopter
A RC helicopter with good flight control is $429.99.21
4.1.3.4.3
RC Airplane
A RC airplane option that includes the features needed for this project including GPS and flight
planning can be found for $569.99.22
4.1.3.4.4
Balloon / Blimp
The cost for a blimp that would cover the specifications is about $130.00.23
4.1.3.4.5
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.
4.1.3.5
4.1.3.5.1
Ease of Use
Quadcopter
Quadcopters include self-balancing software that keeps them flying without user input. With
easy to implement antennae technology, they can be controlled from inside an armored vehicle and even
programmed to fly specific routes without user input.
4.1.3.5.2
RC Helicopter
RC helicopters are similar to quadcopters in that they can be self-balancing as well as include
preprogrammed routes.
21
4.1.3.5.3
RC Airplane
While they include pre-determined route flying, it is hard to quickly change directions in RC
airplanes due to their need to maintain airspeed in order to stay aloft. These also require some sort of
takeoff distance that exposes the user.
4.1.3.5.4
Balloon / Blimp
Once the balloon is attached or takes off, it would require little effort to land or replace batteries.
Therefore, the balloon received the best score
4.1.3.5.5
Conclusion
Looking at all of the options, it is easy to see that the blimp is the easiest of the systems to use,
followed by the quadcopter. Next is the RC helicopter, and then the RC airplane, which requires the most
attention of the powered solutions.
4.1.3.6
4.1.3.6.1
Maneuverability
Quadcopter
Since quadcopters by design do not have a front facing direction, they are capable of moving in
any direct at any time. This allows them to change direction and speed very quickly. 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 in Figure 8 and the two equations below. These two factors give the quadcopter great
maneuverability.24
Figure 8: Control of a Quadcopter24
𝜏𝜑 = 𝑙(𝑓2 − 𝑓4 ) 𝑎𝑛𝑑 𝜏𝜗 = 𝑙(𝑓1 − 𝑓3 )
4.1.3.6.2
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 helicopter’s directional flight is determined by the tilting 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 the angle of the swash plate from the perpendicular.25
22
4.1.3.6.3
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 airplane could go into a holding pattern,
this would likely be unhelpful since constant video from the same perspective would not be provided. A
similar video perspective is desired to provide the user with a simplistic design. If the video is constantly
changing perspective, the user will need to reorient him/herself by finding north, south, east or west every
time he/she views the video. In addition, RC airplanes were not deemed maneuverable enough to fly at
low altitudes in urban areas. Such flight patterns would almost certainly lead to a collision between the
device and surrounding. Since RC airplanes only have one propeller, they can only travel forward. RC
airplanes cannot move side to side without moving forward and cannot move backwards at all.
4.1.3.6.4
Balloon / Blimp
Balloons would likely be tethered to the vehicle, but in addition, they would likely have small
motors to allow some movement. This does not allow for great maneuverability. Small movements could
be performed, but they would be by no means quick.
4.1.3.6.5
Conclusion
The quadcopter excelled in this category due to the fact that it can move in any direction in 3-D
space immediately, without turning first or building up speed. Next was the RC Helicopter, with its only
limitation being that it must turn before executing some maneuvers. The RC airplane came in third
because it requires speed to move, and any increase in altitude cannot be done instantly but instead
requires routing. Following these, the balloon scored worst of the power solutions because it is slow and
its large size makes it cumbersome.
4.1.3.7
4.1.3.7.1
Expandable Platform
Quadcopter
Quadcopters are designed with expansion in mind. The flat and symmetrical frame that
quadcopters use make it easy to incorporate more hardware onto the design. They also have selfbalancing abilities that allow for minor frame imbalance, which enables hardware to be added without the
concern for balancing. In addition, quadcopter arms are estimated to be 0.3 m long each. With half of the
space estimated as usable for expansion (to prevent interference with propellers), the platform size is
0.045 m2. See Figure 9 for a visualization.
Figure 9: Platform Area of a Quadcopter
23
4.1.3.7.2
RC Helicopter
RC helicopters have room for cameras and GPS modules, but not much else. Due to the hull, the
only room to add additional components would be on the skids along the bottom of the RC helicopter.
The skid area is estimated to be 6 in by 4 in giving an area of 0.17 ft2, just 24% of the estimated area
available for a quadcopter.
4.1.3.7.3
RC Airplane
RC airplanes are built inside a certain predefined frame. This makes it difficult to add additional
hardware, as there often is a space issue. Unlike RC helicopters, RC airplanes do not have skid like
platforms to mount extra hardware on. Balance is also more of a concern, as RC airplanes do not have any
way of dynamically counteracting balance. This would be problematic because symmetrical weight needs
to be added to balance the RC airplane, potentially leading to weight being added solely for balance.
4.1.3.7.4
Balloon / Blimp
The balloon/blimp scored quite low in this category, not because there is not space to add
accessories, but because the lift is heavily affected by weight. The whole system may need to be enlarged
in order to handle the weight of additional accessories.
4.1.3.7.5
Conclusion
The quadcopter scored best in this category because it is made with expansion in mind. The RC
helicopter was second because it is similar in nature to the quadcopter, except that the hull limits
space. A RC airplane is quite space limiting because of its specifically designed fuselage. Last are
blimps, which are heavily affected by weight.
4.1.3.8
Safety
4.1.3.8.1
Quadcopter
Quadcopters can be remotely controlled by a RC transceiver inside a vehicle. They could be
programmed to take off and land from the top of a vehicle or a platform on the back end to ensure that no
operators need to exit the vehicle.
4.1.3.8.2
RC Helicopter
RC helicopters have similar safety characteristics to quadcopters.
4.1.3.8.3
RC Airplane
RC airplanes either require a takeoff runway, or close user interaction (for a hand thrown
start). These options extend the time required for takeoff and put the user in more danger by requiring
them to be outside the vehicle. Any time that the operator is outside of the vehicle presents a safety risk.
4.1.3.8.4
Balloon / Blimp
RC balloons or blimps would not require an operator to exit the vehicle and expose himself or
herself. However, being an air-holding vessel, these options would be vulnerable to punctures from
surrounding objects such trees, buildings, and bridges.
24
4.1.3.8.5
Conclusion
Quadcopters and RC helicopters are the best in this situation due to their vertical launches and
programmable flights. However, quadcopters edged out because of increase takeoff and landing
maneuverability. The balloon/blimp scored next again because of its near-vertical takeoffs. RC
airplanes, because of their long takeoff and landing requirements, scored the lowest.
4.1.4
Best Solution
As one can see from the Table 2, quadcopter scored the highest, and the team believes that it
solves the problem most efficiently due to its maneuverability, expandable platform, and safety.
4.1.4.1
Recognized Weaknesses
While the solution chosen for the problem provides many positive attributes, it is not without its
weaknesses. As is a problem with all RC vehicles, quadcopters have to constantly tradeoff between
abilities and battery life. As soon as more features are added, the weight gain and processing power
needed 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 will be a major problem, especially during
initial testing phases that will require iterative safety designs.
4.2
Concept Art
Figure 10 below depicts a military vehicle using our solution. The ground vehicle could be a
single car or large military convoy in need of situational awareness. A quadcopter is following the
ground vehicle using GPS, and a video stream is being taken and transmitted over Wi-Fi to that
vehicle. An enemy is depicted as seen hiding behind a small bush. The quadcopter is able to see this
threat and alert those in the vehicle via the video stream before they can see the threat themselves.
Figure 10: Concept Art of Design Solution
25
4.3
Overall System Block Diagram
The overall system block diagram is seen in Figure 11 and shows the two subsystems of the
solution. One part is the base station, which will be located inside the vehicle. The base station includes
two major subsystems, the controls, communication system, and the base station computer. The controls
and communication system will provide the network over which video streaming can occur, as well as the
ability to send controls from the base station computer to the quadcopter. The base station computer
serves as the autopilot for the quadcopter and provides an interface for the user to interact with the
system. Refer to chapter 6 for the details of the base station. The second part of this solution is the
quadcopter. This consists of two controllers, the flight controller and the VGPU as well as a camera, flight
controller sensors, GPS module, motors, and a power distribution system. The sensors and GPS receive
data from the outside world while the motors provide thrust. The controllers send/receive data and
controls to/from the base station. All of the interface connections are described in Table 3 below. Refer to
chapter 5 for details of the quadcopter.
Figure 11: Overall System Block Diagram
26
Table 3: System 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, and arm/disarm the system per REQ 3.2.4. All
inputs will be done through the GUI on the Base Station Computer.
GUI Button
Power
The power for the base station will be provided through the car battery
that the base station is to be mounted in. The car will power both the
Base Station Computer and the Controls and Communication System.
15V Car Outlet
GPS Satellite
Data
Both the Controls and Communication System and the GPS on the
quadcopter will receive a GPS signal from global orbiting satellites.
Control Signal
A control signal to autonomously control the quadcopter will be sent
from the Controls and Communication System to the Controllers on the
quadcopter. This signal will be a frequency-hopping spread spectrum
signal sent over a 2.4 GHz frequency.27
2.4 GHz
GPS to Base
Data
The GPS to base data will be sent over an 802.11n Wi-Fi connection
using the NMEA 1083 protocol.26 This will carry the GPS
coordinates to the laptop. It will be sent using a Netcat port and the port
chosen will be different from the one used for the video to base data to
prevent interference. The GPS position will be refreshed at 5 Hz as this
is less than or equal to the average refresh rate for both GPS modules
being considered. See section 6.2.3 for details and see section 5.3.2 for
necessary bandwidth calculations.
NMEA 108326
Video to Base
Data
The video to base data will be sent in an H.264 compressed format over
an 802.11n Wi-Fi connection. The latency will be determined by REQ
3.2.1.4.D and the data will be sent using a Netcat port.28 This will be
sent on a different port than the GPS to base data to prevent
interference. See section 5.3.2 for bandwidth calculations.
H.264
Motor Thrust
The motors will provide thrust to the outside world in order to lift the
quadcopter.
Sensor Data
The flight controller has various sensors that will be reading data of the
environment and sending it to the controller for analysis.
27
NMEA 018326
N/A
Varies
4.4
Feature Matrix
In Table 4 below, the team has identified different levels of features and their implementation
importance in the system. The following section goes into more detail for each of these features.
Table 4: Feature Matrix
4.5
Feature Descriptions
This section attempts to provide some clarity and definition for the features shown in the feature
matrix above.
4.5.1
Mechanical
Mechanical features are items that deal with the mechanical structure of the quadcopter. These
features are defined below.
4.5.1.1
Strong Frame
The strong frame will prevent the arms from flexing and give the quadcopter more stability. This
is essential because a flimsy frame will make it difficult to control the quadcopter as well as give the user
a sense of distrust. The strong frame will also provide a greater level of durability for crashes.
4.5.1.2
Propeller Guards
Propeller guards will prevent the propellers from being damaged by near-by objects. This is not
essential for flight, but it is a core feature to prevent damage during testing and to provide better safety to
the users during takeoff and landing.
4.5.1.3
Robust Landing Gear
Robust landing gear will help prevent takeoff and landing damage from occurring. This is a basic
feature since normal landing gear will perform adequately, but robust landing gear will aid in testing the
automatic takeoff and landing and increase system durability.
4.5.1.4
Crash Protection
Adding additional protection to the quadcopter in the event of a crash would be very useful to
protect the electrical and mechanical components of the quadcopter. However, it is not essential to
creating the system.
28
4.5.1.5
Reach an Air Speed of 50 km/hr
Quadcopters are known for their agility, but not their speed. Having a quadcopter reach 50 km/hr
(30 MPH), will help it keep pace with the convoy in most situations.4 For the purposes of this project, the
team will strive for 15 km/hr (9.3 MPH) and document how achieving 50km/hr would be done given
more sufficient resources.
4.5.1.6
Rainproof
A rainproof quadcopter will be one more step in creating a robust system that can operate in all
environments. This can be done by covering the electronics in a case or using commercial waterproofing
techniques like NeverWet.29
4.5.2
Control
Features that affect the movement, navigation, or overall control of the quadcopter are described
here.
4.5.2.1
Motor Control
Basic control of the motors on the quadcopter is essential to balancing and lifting the quadcopter.
4.5.2.2
Full Motion Control
Full Motion control is the ability to move the quadcopter any 3-D direction, which will result in a
more agile system.
4.5.2.3
Autonomous Following via GPS
Once full motion control has been established, autonomous GPS navigation is the next step in the
control process. This is a core feature to the project in order to make the project track autonomously.
4.5.2.4
Full control via GUI
It would be desirable to combine many of the quadcopter controls in the GUI. Control of the
quadcopter is a basic feature that would be added to the GUI.
4.5.2.5
Altitude Control
Altitude control would give the team the ability to tell the quadcopter to fly at a set height. This
is a basic step to move towards automation.
4.5.2.6
Automatic Takeoff and Landing
Automatic takeoff and landing would be a big step towards full automation. Without this feature,
a user could manually control take off and switch to automated flight once it is in the air.
4.5.2.7
Autonomous Following via IR
This redundant form of tracking will help the quadcopter stay in contact with the base station in
the event that the GPS signal is weak or lost.
4.5.3
Communication
This section describes features that could be used to provide means of communication between
the quadcopter and the base station.
29
4.5.3.1
RC for Control
Since RC is the current protocol used for most quadcopters, it is essential to have working in
order to achieve basic flight. In addition to basic manual control, RC could be used for automated
controls.
4.5.3.2
Wi-Fi for Video/GPS
Wi-Fi will be the primary way for the onboard computer to send information to the ground. A
wireless network will be set up to send GPS and video signals for processing on the control computer.
4.5.3.3
Redundant Communication
Redundant communication will protect against the event RC communication is lost. This will be
the first communication area investigated once basic communication is working.
4.5.3.4
Emergency Communication-Loss Landing
In the case that all communication fails with the vehicle, a default command will be given after
some time to land in order to not fly further out of range, or crash.
4.5.3.5
Total Wi-Fi System
In this system, Wi-Fi would be used in all modes of communication (video, GPS, and
controls). It could also be used as another redundant form of control.
4.5.4
Power System
This section describes the components, which deal with powering the quadcopter and base
station.
4.5.4.1
Battery
Using a battery to power the quadcopter is essential for basic flight.
4.5.4.2
Easily Accessible
A battery will need to be replaced and recharged often. Therefore, an accessible battery is
essential.
4.5.4.3
Base Battery Charging
Integrating the battery charger into the base station will help simplify the number of parts in the
system and increase convenience. It will also make the system more portable if a battery is able to charge
while in a moving vehicle.
4.5.4.4
Battery Monitoring via GUI
Battery monitoring is a core feature to prevent damaging the battery and making it available on
the GUI makes the system easier to use.
4.5.4.5
Extra-Range Battery
Because of the high performance nature of the vehicle and all the processes running on board,
power consumption will be relatively high, yielding a need for a high capacity battery.
30
4.5.4.6
Emergency Low-Battery Landing
A command will be needed to tell the quadcopter to land if the battery is under a certain
percentage. With sensitive equipment on board, a controlled landing is better than an uncontrolled
landing.
4.5.4.7
Laser Charging
Perhaps a science fiction feature, but could offer nearly unlimited flight time. Because of the
difficulty, it is a dream feature.
4.5.5
Sensors
The sensor section describes various sensors that could be used to collect system information
4.5.5.1
Hovering Sensors
Sensors on the quadcopter are essential to keep it hovering autonomously. These include
accelerometers, gyroscopes, a compass, and possibly an optical flow camera.30
4.5.5.2
GPS
GPS will be used to monitor the location of the quadcopter and the computer on the ground. The
GPS signals from both will be compared and used to calculate the necessary movement of the quadcopter.
4.5.5.3
Altimeter
An altimeter will be necessary to implement altitude control. Since an altimeter of some sort is
necessary for altitude control, this will need to be a core feature as well. This can be done by using a
barometer, sonar sensors, or GPS.31
4.5.5.4
Obstacle Avoidance
Obstacle avoidance will be explored in order to avoid trees, bridges, light posts, and other things
that could impede the flight of the quadcopter. This can be done by using infrared proximity sensors, or
an optical flow camera.30
4.5.5.5
Speedometer
A graphical speedometer would make it possible to monitor the speed of the quadcopter on the
GUI. This is not necessary to meet the requirements, but would be useful to users. The speed would be
calculated in software using GPS data.
4.5.5.6
Computer Vision for IR Beacon
One way of determining movement is to have an IR beacon on the car and use computer vision to
register the beacon and follow it. Similar project have used IR sensors from popular gaming consoles to
do tracking of a vehicle.32
4.5.6
Video
This section defines items relating to the video, which will be sent from the quadcopter to the
base station.
4.5.6.1
Ability to Take Pictures
The system should, at a minimum, provide still pictures of the area from the view of the
quadcopter.
31
4.5.6.2
Stream Video
Core to the system is streaming video provided from the quadcopter, which allows real-time view
of the area surrounding the convoy.
4.5.6.3
Stream VGA Video to GUI
The streaming video should be integrated into the GUI in order to simplify and minimize the
number of components in the system.
4.5.6.4
Stream HD Video
It will be important to have high quality video from the quadcopter in order to pick out threats
from above. However, it is not essential to the quadcopter system and is therefore not an essential
feature.
4.5.6.5
Record Video while Streaming
Being able to record the video while also streaming would give the user playback at another time.
This is not crucial for the system and is therefore a stretch feature.
4.5.6.6
Horizon to Horizon Field of View
Several cameras could be used to see all around the vehicle on the ground. Another option would
be to create a simple controllable gimbal to move the camera’s view. This component will be beyond the
scope of this project but will be needed in a production model.
32
5
Quadcopter Design
This chapter discusses the quadcopter design in detail by breaking the design down by
components. Requirements, alternatives, decision criterion, which alternative was chosen, implementation
details, and tests are given for each quadcopter component. The next chapter will discuss the details
needed for the base station.
5.1
Quadcopter Architecture
A block diagram of the quadcopter’s architecture can be seen in Figure 12 below. Table 5
accompanies the block diagram and lists all of the communication interfaces between the various
subsystems. Starting with the flight controller, it receives power through the power distribution board and
interfaces with the flight controller sensors as well as the four ESCs. The four ESCs drive each of the
four motors. The other main component is the VPGA, which interfaces with the camera as well as the
Wi-Fi dongle. A GPS module also receives data from global orbiting satellites, interacts with the VPGA
through its I/O pins, and that GPS information is sent over Wi-Fi with the video stream.
Figure 12: Quadcopter Architecture Block Diagram
33
Table 5: Quadcopter Block Diagram Interface Descriptions
Signal
Description
Flight Controller Power
The power distribution system on the quadcopter will
provide a 5-6 VDC power supply to the flight controller.
The typical current draw will be 200 mA with a max of
500 mA.33
ESC Control
The flight controller sends a pulse width modulated
signal between one millisecond and two milliseconds to
the ESC for each motor to control the movements of the
quadcopter.34
Motor Controls
VGPU Power
Video Stream
GPS Data
5.2
The ESCs send a three phase trapezoidal wave with
varying frequencies to their respective motors to drive
them.35 The voltage ranges from 1.15 V to 1.45 V.34
The battery will supply a 5VDC +/- 0.25V power supply
to the VGPU. The maximum current draw will be 700 mA
giving a maximum power consumption of 3.7 W.36
The camera will send a raw video feed to the VGPU for
processing and preparation to be sent to the base
station.
GPS data will be sent to the VGPU via its digital I/O pins.
The voltage supplied to the GPS module will be 3-5.5 V
with a maximum current draw of 25mA and a maximum
power consumption of 0.14 W. A transmit and receive
pin will send the NMEA 0183 data at a 9600 baud rate.38
Protocol
PWM
Three-Phase Power
Micro USB
H.264 video37
NMEA 108326
Hardware
This section discusses the thought process behind choosing quadcopter hardware components.
5.2.1
Tether
A tether will be used to perform initial testing of the quadcopter.
5.2.1.1
Requirements
The tether shall be secure enough to restrain the quadcopter to prevent crashes from occurring
and causing harm to the user. However, the security of the tether shall not inhibit the quadcopter from
flying.
5.2.1.2
Alternatives
A tether system with strings for each armature, a large net, and a padded room were all
considered as options to protect the quadcopter during testing.
34
5.2.1.3
Decision Criterion
The team will choose an alternative based on simplicity of design and ease of use. The desirable
system will be easy to set up, take down, and store.
5.2.1.4
Decision
The team decided to use a four-point tether system. A four-point tether was chosen because a
tether with less restraint would allow for potential crashes and a tether with more restraint would be too
restrictive to flight. Once built, the testing system could be used by a single individual for testing. The net
would require at least two other people to hold the net while testing took place. A room with padded
walls, floors, and ceiling was simply not feasible on the team’s budget. For these reasons, the tether was
used.
5.2.1.5
Implementation
A simple frame was constructed using wood. The four tethers are attached to vertical posts to
keep the quadcopter from contacting the ground during test flight. With this setup, the quadcopter should
not be able to hit anything during test flights. The final implementation of the tether can be seen in Figure
13 below.
Figure 13: AutoCAD Representation of Tether (left) and Photo of Actual Implementation (right)
5.2.1.6
Unit Test
The team tested the tether by performing a dry run with a semi-functional quadcopter. Weights
were added to the frame of the tether order to prevent it from folding in on itself. This was a concern
because the frame was built as two separate pieces for simpler storage. The weights, combined with
bracing it against the wall, prevent the frame from separating and collapsing during flight.
5.2.2
5.2.2.1
Propellers
Requirements
The propellers shall be robust enough to handle bumping into other objects. In addition, the
propellers shall be large enough to provide adequate lift for the quadcopter but small enough to fit on the
35
frame that is chosen. Propellers are also specific to the direction of rotation, making it necessary to match
propellers with motors. Finally, the propellers shall not inhibit the performance of the quadcopter due to
being unbalanced. The propellers used will aid in satisfying the following customer requirements: REQ
3.2.1.1.A, REQ 3.2.1.2.C.P1, REQ 3.2.1.3.C.P1, REQ 3.2.1.3.E.P1, REQ 3.2.2.2.A, REQ 3.2.2.3.A, REQ
3.2.2.4.A, and REQ 3.2.3.2.A.
5.2.2.2
Alternatives
Carbon fiber or plastic propellers could both fit project needs. There are propellers that range in
length from 4 to 22 inches and with a pitch ranging from 2 to 12 degrees.39
5.2.2.3
Decision Criterion
The choice between plastic or carbon fiber propellers will depend on multiple things. The blades
must be robust enough to handle moderate collisions, balanced enough to limit vibrations, and have
appropriate length and pitch values.
5.2.2.4
Decision
The choice was made to use carbon fiber propellers. Plastic propellers have more flexibility than
carbon fiber propellers. This means the propeller will bend when a load is applied and the propeller
performance will not be optimal. In addition to performance, carbon fiber propellers are harder than
plastic ones. This means carbon fiber propellers are less likely to be deformed after minor crashes.40
The team has not yet decided on the brand of propellers or on the pitch and length of propellers to
use, as there is a tradeoff between stability and maneuverability.
5.2.2.5
Unit Test
Propellers were not tested in a specific way other than during test flights of the quadcopter using
the provided propellers. The team observed that as the quadcopter experienced bumps and falls, the
propellers were durable and handled the abuse. Once the team has selected the propellers for the
prototype, they will be tested for balance and during flight tests.
5.2.3
Flight Controller
A flight controller will be used to interpret RC controls as well as provide dynamic control
feedback to keep the system stable.
5.2.3.1
Requirements
The flight controller shall support GPS navigation. The flight controller shall use software that
can be manipulated by the user. That is, the team shall have access to the flight controller code and
modify it per project needs. In addition, it will aid in satisfying the following customer requirements:
REQ 3.2.1.2.A, REQ 3.2.1.2.B, REQ 3.2.1.2.D.P1, REQ 3.2.1.2.E, REQ 3.2.1.2.F.P1, REQ 3.2.1.3.A.P1,
REQ 3.2.1.3.B.P1, REQ 3.2.1.3.C.P1, REQ 3.2.1.3.D.P1, REQ 3.2.1.3.E.P1, REQ 3.2.1.3.F.PI, REQ
3.2.2.3.A, REQ 3.2.2.4.A, REQ 3.2.3.2.B, REQ 3.2.4.B.P1, REQ 3.2.4.D, and REQ 3.2.4.E.
5.2.3.2
Alternatives
The team investigated using AeroQuad 32, APM 2.5, AutoQuad 6, MultiWii Lite, MultiWii Pro
2.0, PX4FMU Autopilot, and UAVX-ARM32 flight controllers. Not all flight controllers could be
considered because there so many different types that it would take too long to evaluate them all so these
seven were selected with their features laid out in Table 6.
36
Table 6: Flight Controller Alternatives
Controller
Cost
Gyroscope
Barometer
Magnetometer
AutoStability
Waypoint
Capabilities
Experience
AeroQuad
3241
$149.95
MPU6000
MS5611
HMC5983-TR
Yes
Add-on
None
APM 2.542
$159.99
MPU6000
MS5611
HMC5883L
Yes
Yes
Yes
AutoQuad
643
$406.25
IDG500/
ISZ500
MP3H6115A
HMC6042/
HMC1041Z
Yes
Yes
None
MultiWii
Lite44
$19.67
TG3205
None
None
None
None
None
MultiWii Pro
2.045
$85.00
MPU6050
MS5611
HMC5883L
Yes
Yes
None
PX4FMU
AutoPilot46
$149.00
MPU6000
MS5611
HMC5883L
Yes
Add-on
None
UAVXARM3247
$96.50
MPU6050
MS5611
HMC5883L
Yes
Add-on
None
5.2.3.3
Decision Criterion
The team will evaluate the flight controllers based on price of the flight controllers, sensors
included, ability to auto-stabilize the quadcopter, waypoint capabilities, and previous experience of team
members. The firmware that the flight controller runs is important but in order to test this the team would
have to individually purchase and test all of the alternatives, which would surpass our budget constraints.
5.2.3.4
Decision
The team has heard from colleagues that the MultiWii flight controller was difficult to work with
and for this reason, we have eliminated those two options. The AutoQuad 6 is out of our price range for a
flight controller. This left the AeroQuad 32, APM 2.5, PX4FMU, and the UAVX-ARM32, which all have
the same barometer and same family of gyroscope (the 6050 provides a software update over the 6000).48
The magnetometer of the AMP2.5, PX4FMU, and UAVX-ARM32 are the same, while the one for
AeroQuad 32 is very similar with the ability for SPI digital interface and maximum output rate of 220 Hz
compared to the 160 Hz of the APM 2.5 magnetometer.49 The decision was made to use the APM 2.5
flight controller. The $10, $60, and $11 increase in price and slightly inferior sensors were mitigated by
the team’s familiarity with the flight controller. Some members of the team have previous experience with
the APM flight controller, which will decrease the time to produce a controllable quadcopter.
5.2.3.5
Implementation
The flight controller will be purchased in January to begin the build of our prototype.
5.2.3.6
Unit Test
Team members used an existing version of the APM flight controller during the initial prototype
phase. Using this has provided evidence that the flight controller can be stabilized and has sufficient
sensors for this project. The flight controller also has open sourced software allowing the team to modify
it in later phases if deemed necessary. Testing will only be needed if problems arise with the new flight
37
controller or if it is significantly different from the existing version. In this case, tests will be discussed in
later reports.
5.2.4
Motors
Four motors will be used to drive the propellers.
5.2.4.1
Requirements
The motors shall be powerful enough to spin the propellers, lift the quadcopter and components,
and be powerful enough to move the quadcopter at the required speed of 50 km/hr for the final prototype,
and 15 km/hr for the delivered prototype. In addition, the motors will help aid in satisfying the following
customer requirements: REQ 3.2.1.1.A, REQ 3.2.1.2.C.P1, REQ 3.2.1.3.A.P1, REQ 3.2.1.3.B.P1, REQ
3.2.1.3.C.P1, REQ 3.2.1.3.E.P1, REQ 3.2.2.3.A, and REQ 3.2.2.4.A.
5.2.4.2
Alternatives
On the quadcopter the team is currently testing, the motors are 850 Kv brushless motors with a
3.17 mm diameter shaft. The weight of each motor is 62 grams. A different motor sold through the 3D
Robotics site is an 880 Kv brushless motor with a 4 mm shaft. The weight of this motor is 72 grams.50
5.2.4.3
Decision Criterion
The motors chosen for the final design will depend on weight, power (Kv), current draw, cost,
and whether or not there is an available ESC for the specific motor. The shaft diameter varies among
motors but does not change the behavior of the motors, so it will not be a considered design criteria.
Another consideration is the lead-time for purchased parts, as long shipping times could lead to project
delays.32
5.2.4.4
Decision
If the smaller motors are able to lift enough weight without giving up performance, they will be
selected as they are the less expensive option. If not, the bigger motors will be chosen. The team will
make this decision in January when calculations have been done to estimate the necessary kV for our
motors. The team has also chosen to buy motors through 3D Robotics instead of jDrones. 3D Robotics
ships from the United States, which will cut down shipping times from up to three weeks (jDrones)51
down to three to five days with a two day shipping option (3D Robotics).50 Lead-time became an issue
when parts were shipped from jDrones in Thailand during initial prototype building.
5.2.4.5
Implementation
One motor will be mounted on each arm with two screws and the mounting plate that is included
with the motor. They will then be connected to the ESCs with three wires to control them (see quadcopter
block diagram and accompanying table for details).
5.2.4.6
Unit Test
The team will assess performance by its ability to lift off, the speed of the quadcopter, and the
ability to stabilize from a disturbance in the system. A disturbance will be simulated by pushing up on the
arm of the quadcopter and letting it stabilize. The ability of the quadcopter to lift off will be tested by
adding weight to the quadcopter in order to simulate the weight of the components to be later added. This
exact weight is estimated at 3 kg at this time, but will be updated once components are decided on. With
this amount of weight on the quadcopter, the team will test if the quadcopter can reach an altitude of 10 ft
and hold it until symptoms of battery drain are shown. The speed of the quadcopter will be tested by
38
estimating the top speed the quadcopter can reach without losing altitude. A more specific test will be
designed for this during the final stages of the project.
5.2.5
ESCs
ESCs will be used to regulate power being sent to the motors.
5.2.5.1
Requirements
The ESC’s shall provide enough current to power the motors effectively. This means the ESC’s
must have a higher current rating than the motors they control. In addition, the ESC’s will help satisfy the
following customer requirements: REQ 3.2.1.1.A, REQ 3.2.1.2.C.P1, REQ 3.2.1.3.A.P1, REQ
3.2.1.3.B.P1, REQ 3.2.1.3.C.P1, REQ 3.2.1.3.E.P1, REQ 3.2.2.3.A, and REQ 3.2.2.4.A.
5.2.5.2
Alternatives
ESCs can be found with different current values and are made by several manufacturers. The
team will first explore the alternative that 3DRobotics has to offer because they have been chosen as the
supplier of choice. 3DRobotics only sells one ESC, a 20 A ESC with a BEC output of 5 V and 2 A for
$25.99.50 If this ESC is not sufficient for the prototype then more alternatives and vendors will be
considered.
5.2.5.3
Decision Criterion
The major criteria for ESCs are current output, cost, compatibility with the selected motors,
compatibility of the BEC with the selected battery, and lead-time. The BEC needs to be compatible with
the type of battery used in order to power the motors. The current output is a major criterion because the
ESC needs to be capable of providing as much or more current than the motor is rated. Cost will be a
major deciding factor for both device and shipping. Where the parts are shipped from is also a factor, as it
directly influences lead-time on the parts.
5.2.5.4
Decision
A final decision on whether the ESC from 3DRobotics will be used, or another ESC will be made
in January of next year.
5.2.5.5
Implementation
Four ESCs will be purchased, with each one being connected to a specific motor. These ESCs
will be powered from the power distribution board on the quadcopter, and controlled from the flight
controller. The power that the ESCs will draw from the power distribution system will depend on the
specific ESCs chosen.
5.2.5.6
Unit Test
The ESCs will be tested by verifying that they are able to power the motors. The power output
will be measured at full throttle to confirm that the expected amount of power is being drawn from the
battery.
5.2.6
Frame and Landing Gear
A frame and landing gear will provide a platform upon which all quadcopter components can be
mounted.
39
5.2.6.1
Requirements
The frame shall be strong enough to carry the components necessary to accomplish the project.
The weight of the quadcopter is estimated to be 3 kg at this time, however once final components are
selected, this number will be finalized. During a severe crash, it is estimated that the quadcopter would
be falling at 2 𝑚/𝑠 (and the landing gear would provide a deceleration distance of 4 𝑐𝑚 due to the give in
𝑣𝑓 +𝑣𝑖
1
the landing gear and frame. Using ∆𝑥 = 2 ∗ 𝑡 and solving for 𝑡 gives 25 𝑠. The quadcopter changing
1
from a velocity of 2 𝑚/𝑠 to 0 𝑚/𝑠 in 25 𝑠 leads to an acceleration of −50 𝑚/𝑠 2 . Provided this
acceleration, and mass of 3 𝑘𝑔, the force that the arms would need to endure would be 150 𝑁 due to
Newton’s second law of motion: 𝐹 = 𝑚𝑎.
In addition, it will be used to help satisfy the following customer requirements: REQ
3.2.1.2.C.P1, REQ 3.2.1.3.E.P1, REQ 3.2.2.1.A, REQ 3.2.2.2.A, REQ 3.2.2.3.A, REQ 3.2.2.4.A, REQ
3.2.3.2.A.
5.2.6.2
Alternatives
The team will choose between using a frame and landing gear that are designed and built in-house
or purchasing those components. Alternatives include aluminum and carbon fiber, as well a variety of
other materials that were not seriously considered due to low availability, weight, and cost. If purchasing
is elected, there are many options for the location on where to purchase.
5.2.6.3
Decision Criterion
Price, strength, weight, rigidity and expandability will all be factors that determine the frame to
be chosen. Expandability will be defined as how well the quadcopter can expand to accommodate new
components. Rigidity will be a goal, as the initial implementation of propeller guards involved arms that
extended beyond where the propellers could reach, and fishing wire was wound from each corner. This
design ensured against collisions with flat surfaces as well as corners but had a major flaw. During an
initial test, the fishing string came loose and was caught in a propeller, bending the arm.
The final decision must be one that a user can trust and depend upon. This follows one of our
design norms of trust.
5.2.6.4
Decision
The team has decided that we will purchase the frame because of the lack of a mechanical
engineer on the team. The team does not feel that the design, fabrication, and balance of a frame is time
efficient. The type of frame to be purchased is still to be determined. The landing gear and propeller
guards will depend on what type of frame is purchased and will likely be based off the landing gear and
propeller guards used on the quadcopter that was acquired for testing.
The quadcopter donated for testing will help with the decision as the team has experience with
problems that can arise in a frame. During initial stages of testing, the team flew the quadcopter for short
periods in order to verify that it was stable and controllable. During these tests, the landing gear was able
to handle small falls and minor hits without damaging the quadcopter. After major falls however, the
landing gear began bending and it was obvious that the quadcopter needed a better means of protection
(Figure 14). The propeller guards implemented are arms that extend past where the propeller spins,
ensuring safety in a collision with a flat surface. Fishing string will not be used due to the prior issues in
testing. The team also found it to be uncommon for the quadcopter to hit corners during flight,
eliminating the need for a propeller guard between the tips of the arms.
40
Figure 14: Broken Arm
5.2.6.5
Implementation
The frame chosen will be used as the base to build the quadcopter. It will be expended to house
extra components if necessary. Landing gear and propeller guards will be added to the frame for
protection.
5.2.6.6
Unit Test
The frame will be tested with weights to ensure that it can hold the estimated weight of the
quadcopter. The calculated force of 150 N from above will be evaluated by attaching 150 N of weights to
an arm to ensure that it can endure a severe crash.
5.2.7
Battery
The battery will provide reliable power to all of the components on the quadcopter.
5.2.7.1
Requirements
The battery powering the quadcopter shall provide power for all on-board sensors and computers,
as well as the ESCs and motors. The battery shall be able to provide power for the equipment for a
minimum of 20 minutes without overheating. The battery shall also have protective circuitry to prevent
overcharging and over-discharging which can cause batteries to catch fire and explode.
In addition, it will help satisfy the following customer requirements: REQ 3.2.1.1.A, REQ
3.2.1.2.C.P1, REQ 3.2.1.3.A.P1, REQ 3.2.1.3.B.P1, REQ 3.2.1.3.C.P1, REQ 3.2.2.2.A, REQ 3.2.2.3.A,
REQ 3.2.2.4.A, REQ 3.2.3.2.A, and REQ 3.2.4.B.P1.
5.2.7.2
Alternatives
Lithium polymer batteries are the standard power source for quadcopters so the team will limit
the selection to that.52 Lithium polymer batteries can be purchased with total power capacities ranging
from 1000 mAh to 8000 mAh.53 Protected batteries that are available in most power capacities in this
range.
41
5.2.7.3
Decision Criterion
Cost will be a portion of the decision for battery chosen, but voltage output, current output,
capacity, and weight will be major criteria as well. Batteries with larger capacities will weigh more,
creating a need for more power, and eventually diminishing the advantages of having a high power
battery.53
5.2.7.4
Prototype Decision
The decision made was to temporarily use a 3300 mAh battery, which was made available to the
team by Professor Kim. The battery was chosen because it was free, and provided a baseline the team
could run capacity tests on in order to make a more educated purchase in the future.
5.2.7.5
Production Decision
The team will decide on a suitable battery for production once the components to be powered are
selected and appropriate calculations are made to determine the necessary capacity, current and voltage
output needed to reliably power the system.
5.2.7.6
Unit Test
We will test the capacity of the current battery with the current quadcopter by running the
quadcopter from full battery life to empty. The performance results of this battery will help our
purchasing decision and decision for what battery will be needed for the production prototype.
5.2.8
Power Distribution System
The multiple electrical components on the quadcopter will need to be powered by a power
distribution system that is powered by the battery.
5.2.8.1
Requirements
The power distribution system shall provide adequate and stable current and voltage that is
required to all components on the quadcopter. See Table 7 for these specific requirements.
Table 7: Component Power Needs
5.2.8.2
Flight Controller54
RC Receiver55
VGPU56
ESCs50
Voltage (V)
4.5-5.5
4.5-9.6
4.75 - 5.25
12 V
Max Current (A)
0.2
< 0.030
0.7
20
Alternatives
There are three main alternatives for this section: a custom printed circuit board assembled in
house, a custom printed circuit board ordered from a professional company, and modification of an
existing board that the quadcopter currently uses. The modification option is not a simple fix because it is
not meant to power the extra hardware like the VGPU and camera.
5.2.8.3
Decision Criteria
The decision will be based on cost, size, weight, and ability to be adapted to the addition of more
components. As more design areas are finished and possible added, the power distribution system may
need to power additional hardware without extensive modification.
42
5.2.8.4
Decision
The team made the decision to first evaluate whether the existing board will be capable of
powering at least the VGPU. This will involve some simple calculations that will be looked at during
later parts of the project. If it is determined that the existing board is insufficient, a custom board will be
made in house in order to minimize costs.
5.2.8.5
Implementation
The finished board will be connected to all onboard equipment to power it.
5.2.8.6
Unit test
The board will be provided power, and the functions of each component on the quadcopter will
be run in order to ensure correct functionality. If all components function properly, the board will be
successful.
5.2.9
VGPU
The VGPU will be used to collect video and GPS data and send that data from the quadcopter to
the base station.
5.2.9.1
Requirements
The VGPU for this prototype shall be capable of sending 240p video and GPS coordinates to a
computer. In the production device, 1080p video will be necessary to provide adequate resolution for
viewing surroundings. The device should also be capable of getting GPS coordinates from satellites and
sending them to the base station in case the team decides to use it for tracking instead of the flight
controller (see section 6.3.2). The board must also be able to communicate over Wi-Fi, whether through
an attachment or built in module. If it is deemed necessary to use an attachment, a USB port will be
needed to accommodate this hardware.
In addition, it will help satisfy the following customer requirements: REQ 3.2.1.3.A.P1, REQ
3.2.1.3.B.P1, REQ 3.2.1.3.C.P1, REQ 3.2.1.4.A.PI, REQ 3.2.1.4.B, REQ 3.2.1.4.D, REQ 3.2.2.3.A, and
REQ 3.2.2.4.A.
5.2.9.2
Alternatives
Some options that could work for this are development boards such as Arduino, a BeagleBone, or
a Raspberry Pi. Development boards are ideal for this project because they limit the amount of board and
integration design needed. These three were selected for comparison due to their popularity in the
electronics industry, their relatively small sizes, and the design team’s prior experiences. None of these
modules include Wi-Fi modules built in, due to the cost and size associated with boards in that category.
Raspberry Pi computers are available with up to 512 MB of RAM and 20 usable I/O ports.56
Raspberry Pi and BeagleBone computers also run a version of Linux that provides a more versatile
environment for development.57 Arduino development boards are available with between twenty and
sixty I/O pins; however, they only provide small amounts of RAM less than 1 MB.58 BeagleBone
development boards are available with 512 MB of RAM, as well as 92 I/O pins. Both the Raspberry Pi
and BeagleBone have cameras that easily interface with the boards, with the Raspberry Pi Cam costing
$2559 and the BeagleBone $103.60
43
For a final implementation, there are hundreds of possible processors that could be applied for the
VGPU that are not development boards. These options will not be discussed in this version, but will be
looked into for the final report.
5.2.9.3
Decision Criterion
The major criteria for choosing a device are cost, hardware capabilities, development
environment, size, and I/O ports. There will have to be a tradeoff between these functions as different
options are considered.
5.2.9.4
Decision
The team has chosen to use a Raspberry Pi as it has a camera made for it and a team member has
some experience using one. Arduinos simply do not have enough RAM to process video streaming.
Although the team has not yet calculated the exact amount, the RAM needed for video streaming is more
than the 1 MB given on an Arduino board. The BeagleBone was ruled out because of its costly camera
and lack of a second USB port. The Raspberry Pi Model B was picked because of the increased RAM
and the extra USB port. Although BeagleBone boards provide similar features and development
environments, the cost of adding a camera to the board made it a harder option to justify. The second
USB port could also be essential if the team decides to pursue using GPS through the Raspberry PI as one
port is being used for the Wi-Fi dongle already.
5.2.9.5
Implementation
The Raspberry Pi will need to be mounted to the platform of the quadcopter and be powered by
the battery, which will need to provide 5 V and up to 700 mA to the board. The main battery will power
the Raspberry Pi through the power distribution board.
5.2.9.6
Unit Test
The Raspberry Pi will have to be tested to ensure that it can be safely powered by the battery
power distribution board and to see if a GPS unit can send the current coordinates at the same time as the
video is being sent without exceeding available power. To do this the team will wire the Raspberry Pi
into the circuit of the power distribution board while monitoring the supply voltage with a multimeter. If
the supply voltage stays constant between the required voltages for running a Raspberry Pi (4.75 - 5.24)
under load, the power to the Pi will be verified. Testing that the Pi fulfills its function will be a pass-fail
test, as it will stream video and will follow tracking programs, or it will not. The criterion used to assess
these two functions is discussed in section 3.2.1.2.D.P1 and 3.2.1.4.A of this report.
5.2.10
Camera
A camera will be used to record and stream video of the ground vehicle and its surroundings.
5.2.10.1
Requirements
The camera shall provide at least 240p quality for the prototype. In addition, the camera shall
provide an 80 x 80 degree angle of view. The camera will help satisfy the following customer
requirements: REQ 3.2.1.3.A.P1, REQ 3.2.1.3.B.P1, REQ 3.2.1.3.C.P1, REQ 3.2.1.4.A.PI, REQ
3.2.1.4.B, REQ 3.2.1.4.C.P1, REQ 3.2.2.3.A, and REQ 3.2.2.4.A.
5.2.10.2
Alternatives
Some possible camera solutions are the camera module for the Raspberry Pi, a GoPro camera, or
a USB webcam. USB webcams come in many shapes and sizes and range in price from $4.00 to $200.
44
5.2.10.3
Decision Criterion
The team will make the camera decision based on the cost of the camera, the angle of view, the
weight, picture quality, maximum FPS, and the ease of integration of the camera onto the quadcopter.
Ease of integration includes the mounting to the board as well as compatibility with the VGPU.
5.2.10.4
Decision
Right now, the team is using the Raspberry Pi camera but that could change based on the testing
of the camera. The Raspberry Pi camera is only $25 while the GoPro camera is approximately $200. The
biggest advantage of the GoPro camera is the wide field of view (170 degrees)61 compared to the 42degree field of view of the Raspberry Pi camera (see below for calculations). USB Webcams could be
purchased for as low as $4.00 but for one that can capture 1080p video costs $40.62 The Raspberry Pi
camera is also the lightest alternative, as it only weighs 0.13 ounces compared to the 7.1 ounces the
GoPro Hero weighs. A final decision will be made after testing is complete using the Raspberry Pi and
camera.
5.2.10.5
Implementation
The camera must be mounted to the quadcopter in a way that will make the video useable even as
the quadcopter is turning and moving. This is not required for the prototype but would be necessary for a
production model.
5.2.10.6
Unit Test
In order to test the angle of the Raspberry Pi camera angle, the team measured the width and
height of the field of view. The camera was set up 279 cm away from the wall and the field of view was
marked. The width was 212 cm and the height was 140 cm. Solving for the angle of view yields a view
of 42 x 28 degrees.
5.3
Software
This section discusses the thought process behind choosing quadcopter software components.
5.3.1
Flight Controller
The flight controller software is determined by the choice of hardware above. This is because
certain boards are designed with the software they intend to be used with in mind. However, the APM
controller was chosen in part because the software provides extensive features, and is open-source.
Having open sourced software in a growing area like quadcopters is beneficial because it is likely to be
updated and improved on a regular basis. Custom changes have not yet been made to the software;
however, it may be needed next semester as designs warrant. This portion will be detailed in the final
report.
The flight controller software will help satisfy the following customer requirements: REQ
3.2.1.2.A, REQ 3.2.1.2.B, REQ 3.2.1.2.D.P1, REQ 3.2.1.2.E, REQ 3.2.1.2.F.P1, REQ 3.2.1.3.F.PI, REQ
3.2.3.1.A, REQ 3.2.3.1.B, REQ 3.2.3.2.B, REQ 3.2.4.B.P1, REQ 3.2.4.D, and REQ 3.2.4.E.
5.3.2
Video Streaming
In order to stream the video from the VGPU to the base station computer over Wi-Fi, a
preliminary script was developed. The script connects to the Raspberry Pi via SSH and runs a command
to start recording video and sending it to a port using Netcat. Netcat is a networking utility that can
communicate across network connections using TCP/IP.28 This may not be the final system used for video
45
streaming but is being used for preliminary testing until a GUI is available to stream to. The base station
computer runs a command to find the stream at the same port and plays it using MPlayer.63
Currently there is too much latency (ranging from three to five seconds) in the video. The latency was
measured by moving in front of the camera and timing the time it took to show up on MPlayer. This is an
issue that will be addressed going forward by changing the FPS the video is captured, decreasing the
quality or looking into a different compression method than the default used by the Raspberry Pi
(H.264).64
H.264 is a video compression technique that reduces the size of the data to be sent using a lossy
compression. Without compression, it would take a bandwidth of 18 Mbps to stream 320x240 video at 30
fps and a bandwidth of 220 Mbps to stream high definition (1280x720) video at 30 fps. (See supporting
calculations below). H.264 can reduce the necessary bandwidth to approximately 700 kbps (320x240) and
14 Mbps (1280x720).65
320 ∗ 240 => 76,800
𝑝𝑖𝑥𝑒𝑙𝑠
𝑏𝑖𝑡𝑠
𝑓𝑟𝑎𝑚𝑒𝑠
∗8
∗ 30
= 18 𝑀𝑏𝑝𝑠
𝑓𝑟𝑎𝑚𝑒
𝑝𝑖𝑥𝑒𝑙
𝑠𝑒𝑐𝑜𝑛𝑑
1280 ∗ 720 => 921,600
𝑝𝑖𝑥𝑒𝑙𝑠
𝑏𝑖𝑡𝑠
𝑓𝑟𝑎𝑚𝑒𝑠
∗8
∗ 30
= 220 𝑀𝑏𝑝𝑠
𝑓𝑟𝑎𝑚𝑒
𝑝𝑖𝑥𝑒𝑙
𝑠𝑒𝑐𝑜𝑛𝑑
The team’s code will be available for analysis and transparency on the website
(http://www.calvin.edu/academic/engineering/2013-14-team8/Code.html). Transparency is especially
important in the video portion as many privacy concerns arise. To combat this, the group will notify
individuals if their faces appear in video recorded by the quadcopter. This way, video taken can be used
for demonstration purposes throughout the project. The team will brainstorm ideas during the next
semester on how to ensure that the video is used only for security purposes in the production model.
This helps satisfy the following customer requirements: REQ 3.2.1.4.A.PI, REQ 3.2.1.4.B, and
REQ 3.2.1.4.D.
46
6
Base Station Design
This chapter discusses the base station design, which controls the quadcopter and receives video
from it. It will go into detail about the hardware and software design decisions that have been and have
yet to be made for the base portion of the project.
6.1
Base Station Architecture
The base station block diagram seen in Figure 15 below is composed of several main
subsystems. Table 8 lists the signals and protocols between these subsystems and is seen beneath the
block diagram. A laptop is directly connected to an external microcontroller board via USB. Since there
are no easily implemented products to control RC vehicles with a laptop, this board passes along controls
to the RC controller. A GPS module interfaces with the microcontroller to indicate the position of the
base station. Lastly, a Wi-Fi Router provides the network over which streaming video is retrieved from
the quadcopter.
Figure 15: Base Station Architecture Block Diagram
47
Table 8: Base Station Architecture Interface Descriptions
6.2
Signal
Description
Protocol
GPS and
Video Data
This is the GPS and Video Data signal from the
quadcopter that is forwarded to the Base Station
Computer via the Wireless Router. For details on this
signal, see Figure 11 and Table 3.
802.11n
GPS Data_1
GPS data will be sent to the RC Interface Module via
its digital I/O pins. The voltage supplied to the GPS
module will be 3-5.5 V with a maximum current
draw of 25mA and a maximum power consumption
of 0.14 W. A transmit and receive pin will send the
NMEA 0183 data at a 9600 baud rate.
NMEA 018326
GPS Data_2
The GPS data received by the RC Interface Module
will be sent to the Base Station Computer through the
serial USB connection with the Base Station
Computer as the host.
Micro USB 2.0
Tracking
Controls
The tracking controls are the controls calculated by
the Base Station Computer and sent to the Arduino
for translation to RC controls. The Base Station
Computer send serial data over USB to the Arduino.
Micro USB 2.0
RC Controls
After the tracking controls have been translated by
the Arduino, the RC controls will be sent to the RC
Transmitter via the I/O pins on the Arduino. The
specific protocol and number of I/O pins to be used
will be determined after further research.
TBD
Hardware
This section discusses the design process for the base station hardware components.
6.2.1
Base Station Computer
The computer in the base station will be running the GUI as well as computing the next location
for the quadcopter to travel. The base station needed to be a computer in order to process video into a
GUI.
6.2.1.1
Requirements
The base station in this project shall be easily transportable in order to troubleshoot in and out of
the vehicle. For the final implementation, the computer, if not integrated into the vehicle and capable of
being removed, must be rugged enough to fall up to 1 meter without failures. In addition, this will help
satisfy the following customer requirements: REQ 3.2.1.3.A.P1, REQ 3.2.1.3.B.P1, REQ 3.2.1.3.C.P1,
REQ 3.2.1.4.A.PI, REQ 3.2.3.1.A, REQ 3.2.3.1.B, and REQ 3.2.4.A.
48
6.2.1.2
Alternatives
The team could use a laptop, desktop, smart phone, tablet, single board computer, or custom
computer built into the vehicle in some way. These options could run many operating systems including
but not limited to Windows, OS X, UNIX, Android, IOS, and Windows Mobile.
6.2.1.3
Decision Criterion
The criteria used to choose a computer for this project will be its ability to support a GUI,
portability in order to place in and remove from vehicle for development, cost, and relative computing
power, which is needed for the graphics processing involved in a GUI. The computer must also have a
display large enough to view the GUI, which the size of will be known later in the project.
6.2.1.4
Decision
The team has chosen to use a laptop computer owned by a team member for this project. A
desktop has almost no portability making it an easy alternative to eliminate. Buying a laptop, smartphone,
or tablet for the project would allow it to be more optimized for the system, but would drive the cost of
the project up significantly. The specific team member’s laptop to be used has not yet been determined
but any of the four would likely suffice.
For a final implementation, it will be determined if a custom computer should be permanently
integrated into the vehicle, or if a more portable version will be used. This has not yet been evaluated, but
will be discussed in the final report.
6.2.1.5
Implementation
The base station computer will be placed inside the vehicle for this project in order to maintain
portability, and it will be connect to the appropriate equipment as needed. The exact connections to the
computer are not known at this point in the project.
The final implementation could be mounted in the base station by using a custom computer built
into either the dash or back seat of the vehicle, or a permanent mount for laptops. A ruggedized laptop
could also be used in order to allow for other uses of the laptop when the system is not in use. These
decisions will be finalized in the final report of this project.
6.2.1.6
Unit Test
The existing GUI with only a push button has been tested on the laptops that may be used for the
project in order to ensure that they can run a GUI. The final GUI will be run once it is finished, however
it is not complete at this time.
6.2.2
Wireless Router
The wireless router will be used to receive the video and GPS coordinates from the quadcopter.
6.2.2.1
Requirements
The wireless router used in the system shall be capable of sending multiple types of information
at the same time. This includes sending video, coordinates from the quadcopter, and controls from the
base. The router must be able to provide the necessary bandwidth to stream HD video and GPS data. To
send 240p video the router must have a bandwidth of 700 kbps (see section 5.3.2 for calculations).
Continually sending GPS data takes a bandwidth of 1.0 Mbps. This gives a total bandwidth requirement
for the router of 1.7 Mbps. The router must have some ability to select communication channels to avoid
interference with the RC controller, since they both operate at 2.4 GHz. 802.11n, which operates at the
49
2.4 GHz bandwidth, and was chosen because it is the most common wireless standard on the market
today.
In addition, the router will help satisfy the following customer requirements: REQ 3.2.1.2.F.P1,
REQ 3.2.1.3.A.P1, REQ 3.2.1.3.B.P1, REQ 3.2.1.3.C.P1, REQ 3.2.1.4.A.PI, REQ 3.2.1.4.B, and REQ
3.2.1.4.D.
6.2.2.2
Alternatives
Router alternatives include an AT&T 2Wire router and an Apple Airport Express router. Router
options also come with various versions of the IEEE 802.11 standard. For a production model, the router
would likely be integrated into the base station computer if a custom computer was used. This would
eliminate this separate component and add it to the base station computer.
6.2.2.3
Decision Criterion
Since all commercial routers provide the necessary bandwidth and channel selection capabilities
outline above, the cost of the router and time necessary to get it running were the major criteria. The time
necessary to get the routers running was found by first looking at the AT&T 2Wire router and attempting
to set it up as a network, which a custom firmware that it runs does not allow. After two hours attempting
to hack the AT&T router, the Apple router was then set up in less than one hour in order to fulfill the
requirements.
6.2.2.4
Decision
Since the AT&T 2Wire router had a custom firmware that would have needed to be modified for
the project, the Apple Airport Express router was used since it was possible to set up for the needs of the
project.
6.2.2.5
Implementation
The router will be located in the vehicle for this project. For the production version, it will be
integrated into the vehicle, or, if the base station computer is custom built, it will be a part of the base
station computer. This will allow the base station to connect to the Raspberry Pi. Static IP addresses will
be set up for the VGPU and the laptop in order to make video communication simpler to implement.
Static IP addresses were chosen so that the VGPU knows what the base station computer’s IP address is
always going to be. This way, the VGPU can always send the GPS and video data to the same IP address.
6.2.2.6
Unit Test
The router will be tested to make sure that multiple devices can automatically connect to it and
that it has enough bandwidth to support video streaming as well as any other data that may need to be sent
over Wi-Fi at the same time.
6.2.3
GPS Module
The base station GPS module will be used to determine the geographical location of the base
station.
6.2.3.1
Requirements
The GPS module shall have the accuracy necessary to track the vehicle’s position within 10 feet.
The GPS shall refresh its location with a frequency of no more than once per second. It shall also be
capable of sending coordinates to the base station computer over Wi-Fi. In addition, the GPS module will
50
help satisfy the following customer requirements: REQ 3.2.1.2.D.P1, REQ 3.2.1.3.A.P1, REQ
3.2.1.3.B.P1, REQ 3.2.1.3.C.P1, and REQ 3.2.1.3.D.P1.
6.2.3.2
Alternatives
GPS modules can be found to be compatible with a computer via USB or a GPS module that uses
digital I/O pins to transmit and receive data. Specifically the team is considering a GlobalSat USB GPS
receiver, which costs $27.8966, and an Adafruit GPS breakout board, which costs $39.95.38 All
alternatives considered use the NMEA 1083 protocol. The Adafruit GPS board operates at between 3.05.5 V and has a typical current draw of 20 mA giving a typical power consumption of 0.11 W at 5.5 V.
The GlobalSat GPS module operates between 4.5-6.5 V with a typical current draw of 50 mA giving a
typical power consumption of 0.33 W.67 The Adafruit board claims an accuracy of 1.5 meters with an
average refresh rate of 5 Hz while the GlobalSat module claims an accuracy of five meters and an average
refresh rate of 10 Hz.
6.2.3.3
Decision Criterion
Cost, time required for implementation, accuracy, weight, and power will be factors affecting
which alternative is chosen. Time required for implementation will be determined by support forums and
documented projects that are detailed online. Since this decision has not yet been made, this information
will only be included in the final report for this project.
6.2.3.4
Decision
The team is currently exploring the option of using the Adafruit GPS module with digital transmit
and receive for reasons of simplicity and compatibility with the RC interface module. However, this work
has not yet been completed; future research will determine which alternative is chosen.
6.2.3.5
Implementation
Implementation will be completed in the spring semester.
6.2.3.6
Unit Test
The team will gather the GPS coordinates from the GPS module and check those coordinates
online to confirm that they are being received correctly and are updated when moving.
6.2.4
RC Transmitter
The RC transmitter will be used to send controls to the flight control computer aboard the
quadcopter.
6.2.4.1
Requirements
The RC transmitter shall be compatible with the RC receiver on the quadcopter or come with a
receiver that can be easily implemented on the quadcopter. It shall have the correct control features of
pitch, yaw, and roll to control the quadcopter. The RC transmitter shall have the bandwidth to send the
control signal to the quadcopter (specifics of this bandwidth requirement will be provided next semester).
In addition, the RC transmitter will help satisfy the following customer requirements: REQ 3.2.1.2.F.P1,
REQ 3.2.1.3.A.P1, REQ 3.2.1.3.B.P1, and REQ 3.2.1.3.C.P1.
6.2.4.2
Alternatives
A RC transmitter module and a RC controller could be used to send RC communication to the
quadcopter. The Turnigy 6X transmitter is one specific option that will be considered with more options
to be considered next semester.
51
6.2.4.3
Decision Criterion
The ability to communicate with the selected flight controller and the control features of the RC
transmitter will be considered to make a selection. Lead-time and bandwidth will also be compared.
Between controllers with similar functionality, lead-time, and bandwidth, cost will be the determining
factor.
6.2.4.4
Decision
A Turnigy 6X transmitter is currently being used with the test quadcopter and the team will
evaluate the performance of this controller next semester before a final decision is made.
6.2.4.5
Implementation
The new transmitter’s receiver will be incorporated into the quadcopter and the controller will be
connected to the RC interface module (see section 6.1 for details).
6.2.4.6
Unit Test
The team will test the transmitter by sending data to the RC receiver and verifying that it is
received without corruption. Once this is achieved, it will be integrated with the RC interface module in
order to control the quadcopter from the base station computer.
6.2.5
RC Interface Module
A RC interface module is needed to interface between the base station computer and the RC
transmitter and provide the correct signals to the RC transmitter. The module is needed to translate the
tracking controls being sent from the base station computer’s USB port into the RC controls used by the
RC transmitter.
6.2.5.1
Requirements
The module must be able to send the tracking controls to the RC transmitter and receive flight
commands serially from the base station computer. Unlike the VGPU on the quadcopter, this will not
need the processing power and memory to process video. In addition, it will help satisfy the following
customer requirements: REQ 3.2.1.3.A.P1, REQ 3.2.1.3.B.P1, and REQ 3.2.1.3.C.P1.
6.2.5.2
Alternatives
Five single-board computers, Raspberry Pi Model B, Arduino Uno, Arduino Due, Arduino Mega,
and BeagleBone Black have been looked at as viable options for the RC interface module. The decision
criterion for each of the five options are shown in Table 9 below.
52
Table 9: RC Interface Module Alternatives
Raspberry Pi B56
Arduino Uno58
Arduino Due58
Arduino Mega58
BeagleBone Black57
40
20
22
20
40
66
40
70
45
92
Yes
Yes
Yes
Yes
Yes
Pin Output
50mA at 3.3V
or 5V
50mA at 3.3V
800mA at
3.3V or 5V
50mA at 3.3V
3.3V, 5V
USB Type
2xA
B
Micro B
B
A
Price ($)
I/O (Pins)
Adafruit
Compatible
6.2.5.3
Decision Criterion
Price is a factor, as well as the number and capabilities of I/O pins to ensure that all
communications can be received from the laptop and sent to the controller. Although not a requirement,
it would be ideal for the user and designers if the flight controller and the RC interface could use the same
communication cable (USB micro Type B) for fast interchangeability with computers used for
programming. The I/O pins must also be capable of sending five Volts in order to power the Adafruit
GPS module. The compatibility with the selected GPS module will have to be considered if the Adafruit
module is chosen, as the GPS would then need to be connected to the RC interface module as well. The
weight and power consumption will not be considered for this section, as they are all reasonably small
(less than 10 Watts). It is assumed for this section that the base station has a source of power other than a
laptop battery. RAM will also not be a factor, as the processing done in this portion will be done on the
base station computer, and the RC interface module will only be relaying information.
6.2.5.4
Decision
The team has not made a decision yet but both a Raspberry Pi Model B and Arduino Due meet
the specifications needed. The Arduino Due has an advantage in using the same connection as the flight
controller chosen. A final decision will be made in January when tests are complete.
6.2.5.5
Implementation
The RC interface module will be implemented per the base station architecture block diagram
(Figure 15) and the accompanying table (Table 8).
6.2.5.6
Unit Test
The RC interface module will be tested by receiving GPS data through digital I/O pins and
sending it to the base station computer over USB and confirming that the base station computer is
receiving the correct coordinates. The controls will be tested by sending a control signal to control one
motor and verify that the motor turns as expected. These tests will likely be done for both the Raspberry
Pi and Arduino Due, which will ideally make it clear which should be used.
53
6.3
Software
This section discusses the design process behind choosing base station software components.
6.3.1
Graphical User Interface
The GUI will run on the base station computer and will display the video stream from the
quadcopter as well as any flight statistics available.
6.3.1.1
Requirements
The GUI shall be able to display the streaming video from the quadcopter. For the production
prototype, it must be able to show various statistics from the quadcopter such as speed, altitude, and
battery life (in flight time remaining). Also for the production prototype, the GUI shall provide an
interface to disable autopilot and control the quadcopter manually. In addition, the GUI will help satisfy
the following customer requirements: REQ 3.2.1.4.A.PI, REQ 3.2.1.4.B, REQ 3.2.1.4.D, REQ 3.2.3.1.A,
REQ 3.2.3.1.B, REQ 3.2.4.A, REQ 3.2.4.B.P1, REQ 3.2.4.C.PI, REQ 3.2.4.D, and REQ 3.2.4.E.
6.3.1.2
Alternatives
Both Python and C# were explored as the software to create the GUI. Specifically for Python, the
team looked into the pygame module to create the GUI and Python’s standard socket library to perform
the networking needs such as retrieving video packets. For C#, the team looked into using Visual Studio’s
default Windows Forms Application to create the GUI and C#’s standard System.Net.Sockets for the
networking.
6.3.1.3
Decision Criterion
Languages will be evaluated based on how difficult it is to implement the requirements as well as
how aesthetically pleasing the final implementation can be.
6.3.1.4
Decision
Initial prototypes will be made in the beginning weeks of next semester. Once these initial
prototypes are created, a final decision will be made based on the prototypes.
6.3.1.5
Implementation
The team will determine this in January. It should be noted, however that our team design norm
of transparency will come into play here. Being a video taking drone, our project presents possible
concerns with privacy, so the GUI must be clear on what the video is being used for. Any video that is
recorded from the GUI will be purely for project purposes and will not be done without permission of
those appearing in the video to promote trust and transparency. The manual override feature will be the
use of the arrow keys to control y and x directions, and ‘w’ and ‘s’ to increase and decrease altitude.
Later implementations may include the integration of a joystick or controller, but a keyboard will be the
initial implementation.
6.3.1.6
Unit Test
The GUI will be tested by checking to see if buttons can be used in a GUI dialogue box. Next, the
GUI will be tested by sending video over Wi-Fi to the base station computer running the GUI.
54
6.3.2
Autopilot Code
Autopilot code shall executed in the base station and control the quadcopter without the need for
human interaction. For the production prototype, obstacle avoidance needs to be included in the software,
but will not be implemented or discussed further in this project.
6.3.2.1
Requirements
Controls shall be given to the quadcopter in order to get it within 3 meters of the x, y position of
the vehicle (the z position or altitude will be different in order to get the second viewpoint). Figure 2 in
section 3.2.1.2.D.P1 demonstrates this requirement. The controls must also be able to control the altitude
of the quadcopter during the tracking period. The rate at which these will be checked will be determined
by future testing. Control methods shall also allow for manual flight mode, which will also allow for
programmed auto takeoff and landing functions. In addition, the autopilot code will help satisfy the
following customer requirements: REQ 3.2.1.3.F.PI, REQ 3.2.3.1.A, REQ 3.2.3.1.B, REQ 3.2.3.2.B,
REQ 3.2.4.C.PI, and REQ 3.2.4.D.
6.3.2.2
Alternatives
There are two ways the group proposed to have the quadcopter get directional controls. The first
way would be to have the quadcopter send its GPS coordinates from the flight controller or VGPU to the
computer base station. The computer would then compare its own GPS position to that of the quadcopter
and calculate the appropriate maneuver to send back to the quadcopter through a RC transmitter. This
technique would allow for more manual controls in the quadcopter as well as the option of programming
automatic landing and takeoff features. If this option were implemented, the flight control software
would need to still be used for quadcopter stability; however, it would not be used for tracking and
positioning.
The second way of controlling would be to only send the vehicle’s GPS location to the
quadcopter and then allow on-board software to compute the next flight path. This will require dynamic
modification of the waypoint software on the flight controller. This feature is included in the flight
control software, but in its natural form, it must be done directly by a user. The modification would be
for a piece of custom software to automate this process.
6.3.2.3
Decision Criterion
The criteria for making this decision are the bandwidth necessary for each option and the ease of
implementation. Calculated values for bandwidth requirements to stream video are shown in section
5.3.2 and show 700 kbps for this project, and up to 14 Mbps for a production version (using H.264
compression). The bandwidth to send the GPS signals have not yet been calculated because it depends on
the frequency chosen to send data. In any case, it is expected that this bandwidth will be less than 2
Mbps, which would make the total bandwidth for this project less than 3 Mbps and 16 Mbps for a
production version. The first option would require a slightly greater amount of data being sent back and
forth through Wi-Fi; however, it is quite small when compared to router bandwidths of greater than 100
Mbps. The second option is challenging because the scope of changing the flight software during flight is
not yet clear. One challenge for each option is scope of modifying the flight software in order to get GPS
positions out of it and into another program. This will be explored further during the remainder of the
project. Allowing for manual flight modes is also a major criterion that will be considered.
55
6.3.2.4
Decision
The decision has been made to implement the option of sending RC signals to the quadcopter.
This allows for manual flight modes and the possibility of automatic takeoff and landing programs to be
written. Since the two options proposed here are not mutually exclusive, it is still yet to be determined
whether the dynamic waypoint variation will be implemented as a source of added accuracy and
redundancy. This decision will be made later in the project as the scope is made more clear.
6.3.2.5
Implementation and Unit Test
Incremental development techniques will be used to implement this portion of the project.
Initially an algorithm will be programmed focusing on finding the correct action for the quadcopter to
take in order to follow. Once an algorithm is created, the RC signal will be transmitted through the RC
interface module to the quadcopter, controlling it to follow the vehicle. Testing for this design decision
will be thought out further as the project goes on.
56
7
System Integration and Testing
This chapter discusses how the team plans to perform integration testing on the system.
7.1
Video Streaming to GUI
This section talks about the tests that will be used to confirm video is being displayed in the GUI.
7.1.1
Basic Video Test
This test will be used to ensure basic video streaming works to the GUI.
7.1.1.1
Equipment
The tester will need a Raspberry Pi with a camera, a Wi-Fi router, and a laptop with the GUI
running.
7.1.1.2
Setup
Specific setup instructions will be determined once the video stream design work has been
completed.
7.1.1.3
Steps
Steps to complete this test will be as follows:
● Turn on all equipment
● Connect GUI to camera feed (TBD after development)
● Move camera to ensure the video in the GUI is the same video that is being sent by the camera.
7.1.1.4
Methods of Measurement
No units of measure will be used for this test.
7.1.1.5
Definition of Success
If the tester can view video that is being captured by the camera located on the Raspberry Pi in
the GUI, then the test has been successful.
7.1.2
Latency Test
This test will be used to measure the time between capturing video with the camera and the GUI
display being updated.
7.1.2.1
Equipment
The tester will need a stopwatch, a Raspberry Pi with a camera, a Wi-Fi router, and a laptop with
the GUI running.
7.1.2.2
Setup
Specific setup instructions will be determined once the video stream design work has been
completed.
57
7.1.2.3
Steps
Steps to complete this test will be as follows:
● Turn on all equipment
● Connect GUI to camera feed to establish video connection (TBD after development)
● Simultaneously wave an object in front of the camera and start the stopwatch
● Stop the stopwatch once this action begins in the GUI
7.1.2.4
Methods of Measurement
Seconds will be used to measure the latency.
7.1.2.5
Definition of Success
This test is defined a success if the latency time (recorded by the stopwatch) is no more than one
second.
7.1.3
Distance Test
This test will be used to ensure video streaming works at the maximum tracking distance.
7.1.3.1
Equipment
The tester will need a Raspberry Pi with a camera, a Wi-Fi router, and a laptop with the GUI
running.
7.1.3.2
Setup
Specific setup instructions will be determined once the video stream design work has been
completed.
7.1.3.3
Steps
Steps to complete this test will be as follows:
● Turn on all equipment
● Connect GUI to camera feed to establish video connection (TBD after development)
● Move the laptop away from the camera slowly until the video stream breaks
7.1.3.4
Methods of Measurement
Meters will be used to measure the distance between the camera and laptop.
7.1.3.5
Definition of Success
This test is defined a success if the distance where video fails is greater than the maximum
allowable distance requirement (TBD).
7.2
Tracking Base Station
This section discusses the test, which will be used to verify autonomous tracking has been
achieved.
7.2.1
Single Location Tracking
This test will be used to ensure the quadcopter can navigate to a single GPS coordinate.
58
7.2.1.1
Equipment
A full equipment list will be given once tracking design has been completed and the
implementation has been determined. However, it is known that the quadcopter and tracking components
of the base station will be needed.
7.2.1.2
Setup
Specific setup instructions will be determined once the tracking design work has been completed.
7.2.1.3
Steps
Steps to complete this test will be as follows:
● Turn on all equipment
● Place the base station in a single location
● Place the quadcopter no less than 6 meters away from the base station
● Enable autonomous following feature on the quadcopter (TBD after development)
● Wait for the quadcopter to navigate towards the base station
7.2.1.4
Methods of Measurement
Meters will be used to measure how close the final location of the quadcopter is to the base
station.
7.2.1.5
Definition of Success
This test will be successful if the quadcopter navigates within 3 meters of the base station.
7.2.2
Slow Dynamic Location Tracking
This test will be used to ensure the quadcopter can navigate to multiple GPS coordinates.
7.2.2.1
Equipment
A full equipment list will be given once tracking design has been completed and the
implementation has been determined. However, it is known that the quadcopter and tracking components
of the base station will be needed.
7.2.2.2
Setup
Specific setup instructions will be determined once the tracking design work has been completed.
7.2.2.3
Steps
Steps to complete this test will be as follows:
● Turn on all equipment
● Place the base station in a single location
● Place the quadcopter no less than 6 meters away from the base station
● Enable autonomous following feature on the quadcopter (TBD after development)
● Wait for the quadcopter to navigate towards the base station
● Pick up the components of the base station and begin walking
7.2.2.4
Methods of Measurement
Meters will be used to measure how close the final location of the quadcopter is to the base
station.
59
7.2.2.5
Definition of Success
This test will be successful if the quadcopter continually updates to new destination locations and
follows the tester.
7.2.3
Full Maneuverability Test
This test will be used to ensure the quadcopter can navigate to multiple GPS coordinates with full
mobility.
7.2.3.1
Equipment
A full equipment list will be given once tracking design has been completed and the
implementation has been determined. However, it is known that the quadcopter and tracking components
of the base station will be needed.
7.2.3.2
Setup
Specific setup instructions will be determined once the tracking design work has been completed.
7.2.3.3
Steps
Steps to complete this test will be as follows:
● Turn on all equipment
● Place the base station in a vehicle
● Place the quadcopter no less than 6 meters away from the base station
● Enable autonomous following feature on the quadcopter (TBD after development)
● Wait for the quadcopter to navigate towards the base station
● Begin driving
○ Start, stop
○ Turn left and right
7.2.3.4
Methods of Measurement
No units will be measured by this test.
7.2.3.5
Definition of Success
This test will be successful if the quadcopter continues to follow the vehicle throughout the test.
7.3
Manual Control through Base Station
This section describes the tests that will be performed to verify manual control via the base
station has been achieved.
7.3.1
Control via Base Station Computer
This test will be used to ensure the quadcopter can be controlled via the computer in the base
station.
7.3.1.1
Equipment
A full equipment list will be given once control design has been completed and the
implementation has been determined. However, it is known that the quadcopter and control components
of the base station will be needed.
60
7.3.1.2
Setup
Specific setup instructions will be determined once the tracking design work has been completed.
7.3.1.3
Steps
Steps to complete this test will be as follows:
● Turn on all equipment
● Connect the base station to the quadcopter (TBD after development)
● Take off, pitch, roll, yaw, and land via base station computer
7.3.1.4
Methods of Measurement
No units of measure will be used in this test.
7.3.1.5
Definition of Success
This test will be successful if the quadcopter can complete the functions performed in step three
via computer control.
7.3.1.6
Control via Base Station GUI
This test will be used to ensure the quadcopter can be controlled via the GUI running on the
computer in the base station.
7.3.1.7
Equipment
A full equipment list will be given once control design has been completed and the
implementation has been determined. However, it is known that the quadcopter and control components
of the base station will be needed.
7.3.1.8
Setup
Specific setup instructions will be determined once the control design work has been completed.
7.3.1.9
Steps
Steps to complete this test will be as follows:
● Turn on all equipment
● Connect the base station to the quadcopter via the GUI (TBD after development)
● Take off, pitch, roll, yaw, and land via GUI
7.3.1.10
Methods of Measurement
No units of measure will be used in this test.
7.3.1.11
Definition of Success
This test will be successful if the quadcopter can complete the functions performed in step three
via GUI control.
7.4
Communication Redundancies
Testing the communication redundancy implemented will involve disabling one form of
communication to see if the system is still able to function with each individual method of
communication. Specific tests will be written next semester.
61
7.5
Complete System Testing
This section outlines the tests to verify system components are working in unison.
7.5.1
System Integration Test
This test will be used to ensure the entire system works together.
7.5.1.1
Equipment
A full equipment list will be given next semester once more work has been done on the design.
However, all components that have been designed will be included.
7.5.1.2
Setup
Specific setup instructions will be determined once more design work has been completed.
7.5.1.3
Steps
Steps will be given after more design work has been completed.
7.5.1.4
Methods of Measurement
No units of measure will be used in this test.
7.5.1.5
Definition of Success
The test is a success if the quadcopter can follow the vehicle autonomously while providing video
to the base station. Note: passing this test does not mean the customer problem is satisfied, but rather all
system components are working together.
62
8
Project Management
This chapter describes how the organizational structure of the project will be broken down. This
chapter will describe how the team plans to organize project documents. In addition, it will describe
design areas, management assignments, conflict resolution, and individual safety protocol. In addition,
this chapter will outline an initial project schedule. Finally, this chapter will discuss the method of
approach used by the team.
8.1
Documentation Organization
The team has organized all of its documents into Google Drive. It is an online real-time
collaboration software that is entirely cloud-based. It allows the team to work on various documents
simultaneously, from any location. The documents are organized into several main categories; Demos,
Design Journals, Manuals, Misc Notes, Planning Documents, Source, Status Reports, Team08: Turn-in,
and Tests. Only one document resides outside of these categories, and that is the Time Tracking
document. This is accessed frequently by the team and is where each team member records
time. Because of the frequency of access, it was not placed into a sub-category. Below are each of the
main categories that the team is using for document organization:
8.1.1
Demos
Under this heading, the team has and will continue to place videos of live demos as various parts
of the project reach milestones. Currently, there are videos of the first few flights of the quadcopter.
8.1.2
Design Journals
Design Journals are the place where each team member can keep a design area as they work
through various portions of the project. Each team member is required to keep track of various sketches
and calculations as design work is done. There is a separate folder for each team member to keep this
information. It also provides a sort of design history that can be used for an audit trail to prove various
decisions along the way. The design journal folder is one of two sections that are shared with our faculty
advisor for occasional review.
8.1.3
Manuals
The manuals section contains manuals for different components relating to the project. This
could be a manual for the flight controller on the quadcopter, documentation on the Raspberry Pi, or
information on the RC controller.
8.1.4
Miscellaneous Notes
Miscellaneous notes is a place where team members can place anything that does not seem to fit
anywhere else. This section holds different brainstorming that the team has done on finding a solution. It
also has a shopping list of items that can be picked up from a local hardware store. This is also the area
where notes are kept on meetings with the team’s faculty advisor meetings and industrial consultant.
8.1.5
Planning Documents
The planning documents section holds the majority of documents the team has created. Version
control is implemented such that any modifications done to a reviewed document are done to a new
revision of the document name. This helps the team keep a baseline history of past revisions in the event
that they need to be revisited. This folder also holds the team budget, block diagrams, decision matrix,
63
and feature matrix. It is also, where various sub-sections of the final PPFS were created, and it is where
this document currently resides. Lastly, it holds the group’s work breakdown structure and Gantt chart.
8.1.6
Presentations
The Presentations folder is the location where team presentations are stored. This allows any
team member to access the presentation document, and it is a backup location for accessing presentation
materials in the event something goes wrong on the class computer. This is also where the team’s most
recent poster is stored.
8.1.7
Source
The source folder is the area where the team can place various source code. It will be used in a
way that provides version control in the sense that whenever a portion of code is working, it will be
placed into this folder along with a descriptive name. This also allows all members to see the various
source code for consistency and brainstorming purposes. As the project warrants more coding work, this
way of keeping source code may be replaced by other free programs like Git.
8.1.8
Status Reports
Weekly status reports are created in this area and emailed to our faculty advisor. These status
reports include hours for each person for the week, for the entire project, as well as the group’s running
total of hours. The reports also include tasks completed, goals for next week, along with any issues that
have hindered progress and may result in the need for outside help.
8.1.9
Tests
Tests is the location where the team can place various tests to be completed. This is source code
and tests that are written and need to be performed. This section will become more relevant when
integration of design components begin next semester.
8.1.10
Team08: Turn-in
The turn-in folder is the main folder shared with our faculty advisor. It is where documents are
placed by the team for official review. Any document placed in here will only return to the place it has
come as a new revision. This ensures that edits are not made on documents currently awaiting review; it
also is a critical part in implementing version control.
8.2
Team Organization
This section describes individual’s design areas and management tasks. In addition, this section
will establish guidelines for how the team plans to collaborate, design, and maintain safety. The team
organization is done in such a way that each member has specific tasks to perform. Each member has
specific roles for both management as well as technical design areas.
8.2.1
Technical Assignments (Design Areas)
The project has been split into eight different design areas. Each team member is assigned as the
primarily lead on two design areas, and as a secondary lead for at least two different areas. This allows
for better cohesion within the group. It also helps with task management and troubleshooting, as the
secondary person(s) can provide support, and help when a design area is behind or experiencing
difficulties. These design areas are seen in Table 10 below. Individual design areas will be expanded
upon below.
64
Table 10: Design Areas and Team Member Assignments
Design Area
Primary
Secondary
Quadcopter
Drew
Robert
Base Station
Components
Flight control SW
Power
Management
Robert
Drew
None
Power Distribution Board,
Flight Controller, VGPU,
Battery, ESCs
GPS Sent from
Quadcopter
Drew
Jared
Base Station
Computer, Router
GPS Module, VGPU,
Flight Controller
Tracking
Algorithm
Spencer,
Robert
Jared,
Drew
Software on Base
Station Computer,
GPS Module
None
RC commands
Spencer
Robert,
Drew
GUI
Jared
Spencer
Video
Streaming
Jared
Spencer
Alternate
tracking (Time
Allowing)
TBD
TBD
8.2.1.1
Quadcopter Components
All
Base Station
Computer, RC
Interface Module,
RC Transmitter
Base Station
Computer, GUI
Software
Base Station
Computer, Router
VGPU, Camera, Video
Streaming SW
TBD
TBD
RC receiver
None
Quadcopter
The quadcopter design area has included all flight aspects of the quadcopter. This includes
getting the quadcopter assembled and calibrating the flight controller in order to fly the quadcopter stable.
Future aspects of this design area will include crash repairs, physical modifications needed for any reason,
and the mounting of additional hardware. This section will require all components of the quadcopter to
be used, as well as the flight control software on the flight controller. This software in particular is what
is used to balance the quadcopter and keep it flying, as well as other functions outlined throughout this
report.
8.2.1.2
Power Management
This design area is added to make sure all electrical components on the quadcopter are supplied
the correct voltages and power. The components and their power needs are outline in section 5.2.8.1.
The power distribution needed will be achieved by fabricating a custom circuit board. This design
decision is discussed in section 5.2.8. The pieces of the quadcopter used in this area will be those listed in
the table above as well as the battery.
65
8.2.1.3
GPS Sent From Quadcopter
This section will include sending GPS coordinates from the quadcopter through the VGPU and
possibly the flight controller. This design decision has not been finalized and is highlighted in section
6.3.2. The GPS module on the quadcopter will send data to the VGPU, which will send it to the base
station computer through the router. The base station computer must also be used to convert the received
coordinates and convert or capture them into a usable form. Details on how this will be done have not yet
been explored.
8.2.1.4
Tracking Algorithm
Once the base station computer receives the GPS position of the quadcopter, the tracking
algorithm will be designed. This design area is quite large, so it was deemed necessary to have all team
members contributing to it. Breaking the area up into several sections is a possibility, but since this area
will be one program, the team decided to combine it into one design area. This is beneficial because the
tracking algorithm will use aspects from all other design areas, warranting the wide range of expertise.
This will use the base station computer, the software on the base station computer, and the GPS module
on the ground, as well as possibly the flight controller from the quadcopter. The design decision on
whether the flight controller is used is discussed in section 6.3.2. The tracking algorithm will output to
the RC commands design area.
8.2.1.5
RC Commands
The tracking algorithm output will tell the RC interface module what action is needed, and the
RC commands design area will handle the conversion of commands to a RC signal. This will include the
base station computer, the RC interface module, the RC transmitter, and the RC receiver. This section
includes two secondary members, as the expertise and troubleshooting required are expected to be higher
than other design areas. This area could include automatic takeoff and landing programs if time permits.
8.2.1.6
GUI
The GUI design area will include displaying video and flight statistics such as altitude and battery
level. It will also integrate manual and autopilot engage controls. It will use the base station computer.
8.2.1.7
Video Streaming
Ensuring the video streaming matches all previously defined requirements. This design area will
use the VGPU, camera, router, and base station computer.
8.2.1.8
Alternate Tracking (Time Allowing)
If team members conclude all other assigned design areas, levels of redundancy will be added to
the tracking of the vehicle. Optical tracking such as infrared tracking, optical flow tracking, computer
vision tracking, and any other means of optical tracking will be added to design decisions and pursued
further. At this time, it is not clear whether this design area will come to fruition. This section, while not
the only section will be a way of adding trust to the product to ensure that even if GPS is jammed or fails,
the vehicle will still be capable of following. This design area could use additional sensors, the VGPU,
router, and the base station computer.
8.2.2
Management Assignments
Jared Zoodsma: Financial Manager maintaining records of financial expenditures and budget
status. All part orders are made through Jared in order to avoid duplicate or incompatible components
being ordered.
66
Robert Hoff: Marketing Manager in charge of all media and public aspects of group work. Duties
included in marketing are posters, PowerPoint presentations, website, social media, and graphical
diagrams requiring graphics software.
Drew Brandsen: Professionalism Manager in charge of maintaining document formatting and
professional look. Drew proofreads team documents before turning them in so that a professional look is
maintained.
Spencer Olson: Team Manager in charge of keeping track of deadlines set by the faculty adviser,
as well as intermediate deadlines. He is also responsible for turning in completed assignments and aiding
overall team direction.
8.2.3
Working Guidelines
As seen above, the project has been broken into several design areas. Each member of the team
has been assigned to two primary design areas and other secondary design areas for assistance. If a
component or task falls into one of these design areas, it is the primary investigator’s responsibility to
ensure the task is completed. The primary investigator may ask for assistance from the secondary
investigator if need be, but the direct responsibility falls on the primary investigator.
Frequent meetings are held to ensure the team is up to date on member’s current tasks. In
addition, a spreadsheet is used to keep track of team hours. Every time a team member enters time, he
also includes what area he worked on, what was accomplished, and what will be worked on next. This is
another way the team can stay current on what other team members are working on.
In the event a team member does not meet a deadline, the team member will be reprimanded
proportionally to the priority of the deadline. If the deadline was a stretch goal that has little to no effect
on other components, the punishment will be minimal. If deadlines continue to be missed, a meeting will
be held with all team members and the importance of making deadlines will be stressed. In addition, the
team will review the workload for all team members to ensure all team members have reasonable
expectations.
8.2.4
Safety Guidelines
The team has a number of guidelines that provide limits on how work is done. When flying
without the tether, there must be two team members present. This is for both safety and debugging
reasons. If a team member gets hurt while flying the quadcopter it is important to have someone else there
to help. In the event of a crash, it helps to have more than one set of eyes to see the crash. Different
people have different opinions on what the crash can affect and this variety of viewpoints can make the
debugging of errors much smoother after crashes.
8.2.5
Team Communication and Accountability
The team meets weekly in order to discuss overall direction and scheduling. These meetings help
to foster communication between team members, ensuring that all team members meet expectations. An
hourly record of member project work is also recorded to ensure that it is obvious when a team member is
pulling too much, or not enough weight in the project. Team members hold each other accountable for
putting in considerable time every week in order to keep the project moving, but also understand when
personal circumstances arise.
67
8.3
Schedule and Work Breakdown Schedule
The following section details the schedule of the project, including a link to the WBS on the team
website. It also discusses major milestones both completed and coming up.
8.3.1
Hours Summary
During the course of the year, the team is keeping track of what time is spent on what areas of the
project. This is done using a spreadsheet online. The team also developed a WBS to estimate and guide
the schedule of designing. A list of the hour breakdowns, both with and without the contingency factor of
1.5 (to factor in unseen events), is seen in Table 11 below.
As you can see, the team has completed a total of 156 design hours out of 626 hours estimated, or
about 25%. Factoring in the contingency factor yields 17% completed. Though this percentage is low, it
is well accepted that first semester involves much more planning, and second semester much more design
work, so the team believes that they are able to complete this design work by May. Looking next towards
the total hours completed, you can see that 415 hours out of 801 predicted have been completed, or
roughly 52%. With the contingency factor of 1.5, this yields a percentage of 34.5%.
One may notice that design time takes up less than half of the total time completed this semester.
This is due to two reasons. First, the initial semester is inherently more planning and documenting, and
thus less time spent on designing. Secondly, this reflects some inaccuracies in the estimations for the
WBS. This will be reviewed before second semester to give the team a better idea of what needs to be
completed and how much time each item will take. A complete copy of the team’s WBS can be found on
the team website. It also shows what tasks are considered complete, as well as tasks that have yet to be
completed. (http://www.calvin.edu/academic/engineering/2013-14-team8/Documents.html)
Table 11: Summary of Hours
Design Time
Total Time
Completed
156 hours
420 hours
Total
626 hours
801 hours
25.0%
52.5%
934.5 hours
1202 hours
17.0%
34.9%
Percent Complete
Total x 1.5
Percent Complete
* As of December 7, 2013
68
8.3.2
Milestones
Major milestones observed in this project are seen below. Dates are either actual or predicted
dates based on given information.
8.3.2.1
Oct 14 - First Presentation
8.3.2.2
Oct 31 - First Flight and Streaming Video
8.3.2.3
Dec 2 - Second presentation
8.3.2.4
Dec 6 - Initial Prototype
8.3.2.5
Dec 9 - PPFS
8.3.2.6
Mar 5 - Third Presentation
8.3.2.7
May 5 - Fourth Presentation
8.3.2.8
April 11- Final Prototype
8.3.2.9
May 10 - Final Presentation
8.3.2.10
May 14 - Final Report
8.3.3
Feasibility of Schedule
The team believes the schedule proposed is feasible. We have completed over 420 hours or about
35 percent of the total projected hours, and we feel that with the extra time next semester, due to the
lighter class load, this amount of work can be achieved. The team believes that the time working so far is
representative of this 35 percent, as a working prototype and critical milestones have been reached in
quadcopter flight, video, and tracking, along with the administrative tasks.
8.4
Operational Budget
In order to manage funds and stay within a reasonable financial range, the group used a budget to
project costs and use funds appropriately. The budget estimation, which is shown in Table 12, shows that
the team factored in a contingency factor of 1.5 to account for unexpected repairs and part replacements.
8.4.1
Project Cost Projections
Below is the team’s operational budget for our project as seen in Table 12. It includes a
contingency factor of 1.5 to anticipate failures and crashes.
69
Table 12: Budget Request
Component
Flight
Unit Price
Controller68
Quantity
Total Price
$159.99
1
$40.00
2
$80.00
$20*
5
$100.00
$10*
3
$30.00
$25
1
$25.00
$35
1
$35.00
$50.00
1
$50.00
$15
1
$15.00
$20.00 *
2
$40.00
Brushless Motors
$15 *
5
$75.00
RC Transmitter55
$30
1
$30.00
Frame and Landing Gear
$80 *
1
$80.00
Connectors72
~$50.00
N/A
$50.00
Shipping Costs
~$100.00
N/A
$100.00
Expandable Features
~$100.00
N/A
$100.00
Subtotal:
$970.00
Contingency Scaling:
x1.5
Total:
$1,355.00
GPS Module
38
ESC
Set of Four Propellers
Raspberry Pi Camera
Raspberry
Arduino
59
Pi69
Due70
Wi-Fi Dongle for Raspberry
Pi71
XBee Antenna
Cables and
$160.00
* Exact seller TBD
8.4.2
Sources of Funding
The team is pursuing two main sources for funding the project. One source of funding will come
from the team’s corporate sponsor, DornerWorks. DornerWorks has graciously offered to donate $1,000
towards the team’s budget. The team is optimistic that Calvin Engineering Department’s Senior Design
Fund will be able to fund the remaining $455.00 outlined in the budget above. This value was originally
$726.50, however, the team was pushed towards cutting down on the budget in order to meet the wider
Senior Design budget for this academic year. With funds from both DornerWorks and Calvin, the team
will have sufficient funds to complete the project and present a successful prototype.
8.5
Method of Approach
The Method of Approach section describes how the design process will be executed. It also
discusses specific design norms that have influenced design decisions, as well as research techniques and
team communication.
8.5.1
Design Methodology
When deciding on how a design should come together, the team uses a strategy that combines
research and group brainstorming sessions. When a design decision is needed, the group records various
options and the effectiveness of each are subsequently researched and evaluated. Once the group has
70
ample time to research the topic, those who found the most pertinent material present it to the group in an
informal manner and a decision is ultimately made.
8.5.2
Research Techniques
In order to find information that is relevant to topics under question, the team uses a combination
of forums, informational websites, and scientific journals. Depending on the topic, the team chooses
which source will be most effective, which usually depends on the size of the design in question. For
more broad design questions, research databases and scientific journals are utilized, while smaller
technical questions are easily answered by forums. One of the major goals of this portion is to consider
all relevant options including options that research uncovers.
71
9
Business Plan
This chapter develops a comprehensive business plan around the project. Beginning with the
overview, the plan discusses the vision for the company, a current market study, competition, a business
model, and lastly the financial forecast. The next chapter will give a conclusion for the project by stating
major risks as well as analyzing the feasibility of the project.
9.1
Overview
Eagleye LLC is an engineering design firm that specializes in small, unmanned aerial vehicles
(UAVs). Eagleye was founded on the principles of trust, justice, and transparency. Eagleye LLC’s staple
product is a small autonomous quadcopter. This quadcopter is designed to capture aerial video and stream
the video to a remote location in real time. In addition, the quadcopter is capable of following a ground
vehicle autonomously. This product could be applied to various security situations such as aerial
reconnaissance over moving targets or highly maneuverable perimeter surveillance.
9.2
Vision and Mission Statement
The vision and principles of the company are listed below and describe the drive that is behind
the company
9.3
Vision for the Company
Eagleye LLC is a company that strives to improve the protection of military and diplomatic
personnel by using UAV systems. The team understands the sacrifice troops and leaders make for this
country and its freedom. Eagleye LLC’s mission is to give back by providing them with one more layer of
security as they travel in hostile environments. This gives Eagleye’s work on UAV systems a sense of
justice and purpose.
9.4
Values and Principles on which the Business Stands
The products created by Eagleye represent its employees personally. Poor products reflect poorly
on those who designed and built them. As such, Eagleye strives for the highest quality in each of its
products and operations. Above all, the products produced must convey a sense of trust. If those using
Eagleye’s products cannot trust the information they are being given, the entire purpose of the quadcopter
product is lost. The other major principle is transparency. It must be inherently clear what information
the users are receiving from the system. In other words, the product must never be so difficult or
complicated to use that it actually decreases the awareness of the user. These principles guide Eagleye
LLC as its team designs and produces next-generation UAVs.
9.5
Marketing Study
Eagleye’s target market consists primarily of military and security companies. Although military
services most likely have some form of UAV or satellite services already, Eagleye attempts to fill a need
that is not currently met by existing UAVs. This product would fall between an individual's first person
ground view and an existing UAV or satellite flying thousands of feet in the air. It would also fall into a
price range that is not currently filled by the UAV market. The following sub-sections detail the market
size and growth, along with regulator restrictions, barriers to entry and exit, and lastly key success factors.
72
9.5.1
How Large is the Market
The current market for military spending on UAVs is about 10.6 billion73 and for non-military
spending is near 6.6 billion74. This equates to a total market of around 17.2 billion dollars for both the
military and nonmilitary spending on UAVs.
9.5.2
Is it Growing or Shrinking?
The future of UAV technology looks bright, according to AIAA (American Institute of
Aeronautics and Astronautics), “non-military application of Unmanned Aerial Vehicle (UAV) technology
is the fastest growing manufacturing sector in the global aerospace industry and expected to grow by
700% between 2012 and 2018.”74 Furthermore, another article by Market Research Media continues to
say that it expects military UAV spending to be over $86.5 billion during the next five years.73 This
shows that both sides of the market (commercial and military) are rapidly growing and expected to
continue doing so.
9.5.3
Regulatory Restrictions
The UAV industry has been subject to significant regulation and restriction since military drone
strikes as well as privacy concerns have made it a fiercely debated topic. There is a perception among
Americans that UAVs represent a threat to citizen privacy and security; however, this is starting to
change. Increasingly more Americans are recognizing the vast potential uses for small UAVs in
nonmilitary markets such as farming.74 In fact, the United States Congress recently passed legislation, the
Federal Aviation Administration (FAA) Reauthorization Act, which will replace the ban on UAV use
with a set of commercial regulations by 2015.75 Because these regulations are not yet well established,
Eagleye LLC will carefully monitor the regulatory situation of the industry, but it is expected that the
predominantly untapped commercial small UAV market will quickly become both legal and profitable.73
There are two additional concerns related to regulatory restrictions, safety requirements, and military
standards. Due to the nature of the quadcopter product’s status as a small electronic vehicle with fastmoving parts, Eagleye LLC will be careful to comply with safety requirements as the FAA releases
them. It is expected that these requirements will be similar in nature to model plane, electronic device,
non-car vehicle, and privately owned airplane regulations. When considering products that are intended
for military use, Eagleye LLC will be sure to satisfy military requirements as they are stated in any
contracts secured; typically, military-grade products have very exact specifications and documentation
that is even more detailed on the design process.
9.5.4
Barriers to Entry and Exit
Several factors will create barriers to enter this market. First and most considerable is the large
upfront capital needed. Economies of scale will need to be utilized to amortize design costs over multiple
sales. In addition, Eagleye will need to work closely with the customers to achieve customer satisfaction
and eventually increase name recognition among potential customers.
9.5.5
Key Success Factors in the Industry
A key step towards success for the company will be exposing the overlooked niche this product
covers for security and military clients. Companies will not be willing to purchase new UAVs when they
do not see the need for them, so it is critical that companies are made aware of how this product can
bolster their security without requiring additional manpower.
73
9.6
Competition
Competition is an important factor to consider when entering a market. The competition section
looks at both existing competitors in this market, as well as other companies that could enter this market.
9.6.1
Existing Competitors
Existing Competitors are listed below and all compete on some level with Eagleye LLC.
9.6.1.1
Hex AirBot
Hex AirBot manufactures a competing quadcopter product for $160; however, this quadcopter is
designed and marketed towards enthusiasts as a toy.76 Eagleye LLC will respond to this competitor by
including features for and focusing on a customer basis of commercial security companies. One crucial
feature Eagleye will include that Hex AirBot does not is GPS and vehicle-following abilities.
9.6.1.2
DJI
DJI is an active competitor in the small UAV market, offering four different copters between
$110 and $15000.77 Their target customer base is primarily enthusiasts and those who require airborne
video streaming.77 Eagleye LLC will respond to this competitor in two main ways. First, the product will
include features not offered by DJI’s cheaper models, such as GPS navigation and vehicle
tracking. Second, Eagleye LLC plans on designing and marketing its product for commercial security
companies as opposed to exclusively enthusiasts and media professionals.
9.6.1.3
FireBox
Firebox designs and supplies various electronic products; one of these is the MicroDrone
quadcopter for $120.78 The MicroDrone quadcopter is marketed towards enthusiasts as a toy for
primarily indoor use.78 Eagleye LLC will respond to this competitor by focusing on the features that
Firebox failed to include, such as video capturing, outdoor flight optimization, and GPS navigation.
9.6.1.4
Lockheed Martin
Lockheed Martin is an active player in the larger military drone market with peripheral activity in
the commercial UAV market. They manufacture many unique models of UAVs of all sizes.79 They
could represent a significant threat to Eagleye’s market niche with some of their models, such as the
quad-vtol UAV; however, they too are more heavily focused on military contracts with very expensive
drones than they are on commercial or private security UAVs.79 Lockheed Martin appears to dedicate
much more of its resources to the R&D of new products than it does to the expansion and mass
production of its current ones.79 Eagleye LLC will respond to this competitor by focusing on commercial
and private security applications for its significantly cheaper quadcopter product.
9.6.1.5
Walkera
Walkera designs and supplies collectible RC helicopter and quadcopter products. These products
are focused on aesthetics and impressive flight patterns, ranging from $70 to $500.78 Eagleye LLC’s
quadcopter product is significantly different than Walkera’s models because of its video streaming, GPS
navigation, and vehicle tracking features. Eagleye’s product will also be designed for functionality and
robust operation, as opposed to solely aesthetics, which will help them target commercial security
companies instead of RC enthusiasts.
74
9.6.2
Potential Competitors
Potential competitors listed below all have the capability to enter this market and present
a viable threat to Eagleye LLC.
9.6.2.1
Northrop Grumman
Northrop Grumman is an active player in the larger UAV market; they manufacture several
different drone models. The smallest of Northrop Grumman’s UAVs has a 10-foot wingspan, which is
still significantly larger than Eagleye LLC’s staple product.80 It is also important to note that the majority
of their models are planes, not quadcopters, and that they focus almost exclusively on military
customers.80 If Northrop Grumman were to build smaller, cheaper, more locally useful products, they
could enter the same market niche as Eagleye LLC. This is unlikely because it would represent a very
significant change in their target customers and Northrop Grumman currently possesses military
contracts, which tend to be reliable source of business.
9.6.2.2
AII Corp
AII is another current competitor in the larger UAV market; they manufacture a few different
drones of varying sizes. All of their drones are plane, not quadcopter styled, and they focus nearly
exclusively on expensive military and defense applications for their UAV products.81 If AII were to begin
producing UAVs that were smaller and cheaper, they could enter Eagleye LLC’s market niche, but this is
unlikely, due to the stable nature of their current military customers.
9.6.2.3
SightLogix
SightLogix is a provider of perimeter security technology such as cameras and sensors.82 This
company is interesting because they could be either a potential customer or a potential competitor. If they
decide to offer aerial quadcopter surveillance products, they could outfit a quadcopter from Eagleye LLC
with their cameras and sensors, or instead develop a competing quadcopter product. Eagleye LLC will
ensure that its products are high quality enough to both encourage the purchase of their product by
commercial security companies and discourage the in-house development of competing products by those
companies.
9.7
Business Model
The business model shows how the company plans to operate. It includes the desired market
image, company goals, a SWOT analysis, as well as a competitive strategy.
9.7.1
Desired Image and Position in the Market
Eagleye desires to be a highly respected producer of small-scale UAVs for security and military
purposes. This market niche is nearly empty and ready for new innovative players.
9.7.2
Company Goals and Objectives
The company goals below briefly describe various objectives in both operations, finances, and in
other areas.
9.7.2.1
Operational
Eagleye LLC hopes to become a highly innovative company that uses latest technology to design
and build UAVs for military and other security customers.
75
9.7.2.2
Financial
Eagleye must be a profitable venture. Using the first prototype as a showcase, the company
hopes to gain further funds to create a robust final prototype that can be used to sell the idea of a
quadcopter with these features and abilities to interested customers.
9.7.2.3
Other
Eagleye hopes to inspire a company culture of transparency and collaboration to help spur
creativity and continuous improvement amongst employees.
9.7.3
SWOT Analysis
The SWOT Analysis for Eagleye LLC is described below. It discusses the internal
strengths and weaknesses of the company, along with external opportunities and threats.
9.7.3.1
Internal Strengths
A major strength of Eagleye is its leaders; they are people who strive for quality and understand
that the work they complete reflects on them. Another strength is the product itself. It has highly
expandable set of unique features that will set Eagleye apart from other producers of UAVs.
9.7.3.2
Internal Weaknesses
A weakness that is apparent with Eagleye LLC is a lack of market experience and low name
recognition. Since Eagleye is a startup, its sales representatives will need to have strong confidence in
their products and use extensive knowledge of both the market and customer in order to win additional
business. In addition, it is important to ensure Eagleye produces highly reliable products to gain customer
confidence.
9.7.3.3
External Opportunities
First and foremost, Eagleye LLC hopes to move into a market niche that is not highly
developed. Small-scale UAVs can exhibit high quality while being much more cost effective compared
to larger well-known UAVs, like the Predator Drone, which runs close to 4 million dollars per
vehicle.83 Eagleye LLC hopes to exploit these differences in building and marketing their products for
less money than the competition.
9.7.3.4
External Threats
One threat, which Eagleye LLC recognizes, is the presence of competing companies in similar
niches in the UAV manufacturing and design market. Unlike Eagleye LLC, the majority of these
companies, such as Northrop Grumman and Lockheed Martin, are well established with very expensive
products. These companies have been producing successful products for decades, developing trust
between them and their customers. Since Eagleye is a startup, the company will need to provide a
flawless product up front in order to begin building similar trust with customers.
9.7.4
Competitive Strategy
A brief competitive strategy is described below to show how Eagleye plans to address
competition.
9.7.4.1
Differentiation
Eagleye plans to compete using product differentiation. Because the systems designed are small
scale UAVs for security systems, they are much smaller than what is on the market today. This allows
76
Eagleye to operate at a significantly lower price point than most UAV manufacturers. Technology
improvements in the last decade have made this possible by integrating many features into a much smaller
package. By opening up this new market niche, Eagleye hopes to provide a new solution to customer
security needs.
9.7.4.2
Focus
The initial focus will be demonstrating the usefulness and possibilities of small-scale UAVs, as
well as encouraging the association of outstanding quality and trust with company products. It will be
imperative to build trust with customers right away in order to continue competing in this market. Once
brand name recognition and customer trust have been established, focus will shift to providing a greater
portfolio of UAVs to allow for even more applications, further increasing the market share and
diversifying the customer base.
9.8
Financial Forecasts
The financial forecasts for Eagleye LLC are detailed below. The forecasts include Pro-Forma
Income Statements and Cash Flow statements for the first three years. Also included are the Break-Even
Analysis and a Ratio Analysis. Each of these statements are derived from supporting calculations that are
seen in the next section.
9.8.1
Key Assumptions
This financial analysis rests on several key assumptions including operation without stockholder
investment, 10% annual interest rate on bank loans, even distribution of cash flows, no delayed purchases,
and capacity-demand assumptions. Operating Eagleye LLC without stockholder investment is an
assumption that should be very accurate, as the leadership does not wish to make Eagleye public. The
effects of operating without stockholder investment are a more limited initial capital with less
accountability and leverage. Assuming a 10% annual interest rate on bank loans is an assumption that is
as accurate as research allows. Realistically, this number will deviate from 10% but there is no
guaranteed prediction of future interest rates. The annual interest on bank loans affects the financial
situation of Eagleye LLC by defining how much money must be paid for each dollar
borrowed. Additionally, for this financial analysis it is assumed that all sales and costs are distributed
evenly throughout the year in which they are recorded. This assumption makes calculations far simpler
and should not significantly change final values. Finally, Eagleye LLC assumed that the company does
not have any accounts receivable or payable within their first three years.
The key assumptions that Eagleye LLC is making in regards to capacity and demand involve their
ability to produce quadcopters and their ability to sell those quadcopters. For the purposes of this
financial analysis, it is assumed that Eagleye LLC will successfully manufacture 10, 200, and 400
quadcopters in each of their first three years respectively. This assumption has a far lower manufacturing
quantity for the first year because that time will be spent primarily in product design and manufacturing
plant startup. Furthermore, this assumption shows increasing manufacturing quantity as time progresses
because of anticipated increase in customer relations and demand. A final assumption that Eagleye LLC
is making is that all of its produced quadcopters will be sold within the year in which they were
produced. This is intended to simplify calculations, and the assumption’s accuracy is dependent upon the
industry’s current competitive and customer situation. A complete view of supporting calculations for the
following financial statements are seen in Table 13 below. This table breaks down fixed and variable
costs for each of the first three years.
77
Table 13: Supporting Calculations
9.8.2
Financial Statements
Two financial statements were used to analyze the financial footing of Eagleye LLC. These are
the Pro-Forma Income Statement and Cash Flow Statement. They are described in the following sections
with the actual statement included.
9.8.2.1
Income Statement
The income statement shows the various revenues and costs for each of the first three years. This
statement can be seen in Table 14 below. The most important number in this statement is the net income
(or net loss) seen at the bottom of the table. As is seen, the first year results in a net loss of over half a
million dollars. This is anticipated, as there are a lot of startup costs and further design work to get the
product to production. By year two, the net income is over one million and year three results in a net
income of over 2.6 million dollars.
78
Table 14: Income Statement
9.8.2.2
Cash Flow Statement
The cash flow statement, which is shown in the Table 15, highlights the major areas where cash
will be spent and received. In this section the loan information, as well as the plan to pay it off are listed,
showing the three-year pay off period. In addition, it shows the current value of the loan at each
year. This section also highlights the purchase of and depreciation on equipment.
Table 15: Cash Flow Statement
79
9.8.3
Break-Even Analysis
Break-even analysis is detailed in Table 16 and shows a break-even point for sales of 55, 55, and
54 units in the first three years respectively. This break-even point was calculated for a unit cost of
$15,000. Although the anticipated production in year one is only ten units, Eagleye anticipates surpassing
the break-even point in years two and three, making up for lost ground.
Table 16: Break-Even Analysis
9.8.4
Ratio Analysis
The Ratios used can be seen at the bottom of this section in Table 17. Note that all ratio values
are negative for year one. This is because Eagleye LLC is operating at a loss while it incurs setup costs
and before it begins collecting revenue. The debts to assets ratio in years one, two, and three are -39.18%,
26.91%, and 0% respectively. The goal was to pay off debt as quickly as possible to decrease liabilities.
The total asset turnover is negative for year one, because Eagleye is not selling a significant number of
quadcopters. Eagleye starts selling in year two and this ratio goes up to 4.61 times. After year two
Eagleye pays off all debt and begin accumulating the extra cash (assets) that would go to paying interest
on debt. For this reason, the total asset turnover goes down to 1.92 times in year three. Again, the profit
margin is very poor in year one because the company does not have any sales; however, it gains nicely to
37.31% and 44.54% in years two and three respectively. The same is true for the gross margin of revenue
80
that goes from -7.37% in year one to 81.27% and 83.65% in year two and three. The reason this ratio is so
high once Eagleye starts selling units is because of a fairly large markup on the product.
Table 17: Ratio Analysis
9.9
Summary
In conclusion, Eagleye LLC plans to provide high quality and highly reliable UAVs for security
purposes. We feel there is a unique market niche for our product since existing UAV systems can cost
millions of dollars. Our low cost and unique product will distinguish us in the growing market of
autonomous surveillance. UAV surveillance is a multi-billion dollar market that is only expected to grow.
As can be seen in the cost estimation sections above, we believe this is a viable business venture and
worth pursuing.
81
10
Conclusion
This chapter will take into account all of the above ideas to identify risks and give an overview of
current project status. Using this information, project feasibility is discussed.
10.1
Major Risks & Issues
One major risk that the team has identified for this project is that crashes are inevitable in the test
stages of the quadcopter. Crashes can set the team back, especially when they require repairs on
components that have to be ordered. The tether is used to minimize crashes during initial testing, but tests
will take place off the tether. Robust landing gear will help prevent damage to the quadcopter. Because
some crashing will happen, the team has budgeted in for some replacement parts and extra parts that are
most likely to be damaged (i.e. motors and propellers). These are kept in stock in order to prevent long
part lead times after a crash. Going along with this issue is obstacle avoidance while flying. The team
will not be utilizing obstacle avoidance on the quadcopter because it is outside of the scope for this
project. However, whenever the quadcopter is flying, obstacles are a big concern and could lead to a
major crash.
Another major risk is the budget. The team recognizes that this is an expensive project, and even
with the additional funding provided by DornerWorks, budget overruns are a serious concern. Because of
the contingency factor built in, the team has some level of safety regarding budgetary concerns.
The last major risk is time. This ambitious project could require as much as 782 additional hours
by May, based on 420 hours completed, and 1202 hours expected with a 1.5 contingency factor. If
various design components take longer than anticipated, it could be detrimental to completing a
presentable prototype in May.
10.2
Project Status
As of December 7, 2013, the team has completed over 420 hours towards the project. The team is
performing preliminary testing on Professor Kim’s quadcopter, including a test of the designed tether,
battery life estimations, and robust flight control. A preliminary video stream from a Raspberry Pi to a
laptop over Wi-Fi is complete, and the first stages of a GUI are developed. The team plans to be done
testing Professor Kim’s quadcopter over interim, so that the team can purchase parts for the final
quadcopter. Other tasks include basic Arduino to GPS communication, and Raspberry Pi to GPS
communication. Using a GPS module, both boards were able to communicate with the module and
display the current location information. As a potential starting point for IR tracking, the team performed
tests on a basic IR sensor using a Raspberry Pi.
10.3
Project Feasibility
After looking at all of the pieces that need completing by May 2014, the team believes that this is
a feasible project. The current status of the project is encouraging as there has been significant progress
on multiple fronts as seen by the WBS. Each team member has put in a significant number of hours
showing a dedication to finish the project, and each member has made progress on individual design
components.
10.3.1
Technical Aspects
Design work has begun on several technical aspects of the project, which have been able to give
the team a reasonable estimate of what the team can complete during the course of the year. Video
streaming has been achieved from a Raspberry Pi over a Wi-Fi connection, and the only work needed is
82
to reduce latency to be within the design requirements. A GUI is under development to integrate the
video stream for easy viewing by the user. So far, a simple GUI has been created with several buttons
that show a dialogue box. The quadcopter is undergoing tests in order to make an informed buying
decision for the group’s main quadcopter in regards to battery, flight controller, frame, landing gear, and
others.
One major concern that the team has regarding the design of the quadcopter is battery life. If the
system relies on batteries that only last twenty to thirty minutes, it will require frequent changes that
translate to system downtime. If potential users of this system require constant video support, this project
is less useful without a way to continuously have a video stream. Using two or more quadcopters in this
system could allow one to fly while the other is recharging, providing constant aerial coverage. This is
outside of the scope of this project, but could be future work to complete.
Another concern is the design of tracking and control algorithms for the autopilot software. This
promises to take up a good portion of the design work next time, but based on the research and planning
done so far, the team believes that this is achievable
Although the project comes with various challenges and weak points, the team feels there are
enough pieces that can be completed within the time frame of this school year to make this project
feasible. Even if the project is not a completed product, the goal of Senior Design is to create a prototype,
which demonstrates proof of concept on many different levels. By breaking the project up into these
pieces, it is reasonable to say that given enough time and budget, the team could deliver a final product
that addresses weaknesses and fully solves the problem at hand.
10.3.2
Costs
With a budget laid out and a plan for which parts to purchase in order to have a successful
system, the team feels well poised for success. So far, the team has spent about $144 on development
boards (mainly a Raspberry Pi and Arduino) and a GPS module in order to develop tracking and
streaming systems. To cut down on testing costs, the team has been using a quadcopter that belongs to
Professor Kim in order to make knowledgeable buying decisions when the time comes. With these steps
completed, as well as a confirmed donation of $1000 from DornerWorks and potential funds from Calvin
Engineering, the team feels that the project will be successful with the given amount of funds.
10.3.3
Time Spent
A total of 34.9% of the total project hours have already been completed this semester. This sets
the team up for around 782 hours next semester, or 195.5 hours per team member at worst, as this
includes the contingency factor of 1.5. While the team has done a significant amount of work already, we
realize there is still a lot of work that needs to be done. However, given the track record, we are confident
the necessary work will be performed in order to complete the project on time.
10.4
Summary
Based on all of the information above, the team believes this project is feasible. Though there are
definite risks in both the specific nature of the project, the design areas, cost, and time, the team has been
planning hard and researching in order to mitigate these risks. With much of the planning completed this
semester, it sets the stage for design work on the system next semester. The team believes in this project
and see its potential benefit for those who need additional security. We are committed to this project and
seeing it through to completion.
83
References
1
(n.d.). In Calvin College Engineering. Retrieved December 8, 2013, from http://www.calvin.edu/academic/engineering
2
Army seeks military convoy warning solutions. (2008). In Defense Daily, 240(46). Retrieved December 8, 2013
from http://search.proquest.com/docview/234082991?accountid=9844
3
Dorin, R. (2012, April 20). Preparing for the President. In Mass Transit. Retrieved December 8, 2013, from ProQuest.
4
Speed limits in the United States. (2013, August 12). Wikipedia. Retrieved December 8, 2013, from
http://en.wikipedia.org/wiki/Speed_limits_in_the_United_States
5
Lane (2013, November 7). In Wikipedia. Retrieved December 9, 2013, from
http://en.wikipedia.org/wiki/Lane#Lane_width_and_capacity
6
Wikipedia. (2013, November 13). Wikimedia Foundation. In City Block. Retrieved December 6, 2013, from
http://en.wikipedia.org/wiki/City_block.
7
Enhanced F Scale for Tornado Damage. (2007, February 1). In Storm Prediction Center NOAA. Retrieved
December 6, 2013, from http://www.spc.noaa.gov/faq/tornado/ef-scale.html.
8
USA.com. (2013). In Grand Rapids, MI Weather. Retrieved December 6, 2013, from http://www.usa.com/grandrapids-mi-weather.htm#HistoricalWind%20Speed.
9
Ergonomics: Lifting limits for employees. (2006, September 2). In Michigan.gov. Retrieved December 6, 2013,
from www.michigan.gov/documents/cis/wsh_lifting_176907_7.doc
10
Whittle, R. (2013, 09). Drone skies. In Popular Mechanics, 190, 76. Retrieved from
http://search.proquest.com/docview/1440248096?accountid=9844
11
FPV Quadcopter Shot Down By Radar. (n.d.). In Finkbuilt. Retrieved December 8, 2013, from
http://www.finkbuilt.com/blog/fpv-quadcopter-shot-down-by-radar/
12
Hobby Lobby (2013, December 8). In RC Helicopters | Beginner Heli | Collective Pitch from Hobby Lobby.
Retrieved from http://www.hobby-lobby.com/rc_helicopters_197_ctg.htm
13
RC Helicopter Selector (2013, December 8). In Skyartec Cessna 182 2.4 Ghz 5 Channel RC Airplane RTF
Brushless Version. Retrieved from http://www.rchelicopterselect.com/skyartec-cessna-182-2.4-ghz-5-channel-rcairplane-rtf-brushless-version.html
14
Squidoo (n.d.). In Radio Controlled Blimps. Retrieved December 8, 2013, from
http://www.squidoo.com/RemoteControlledBlimp
15
Blimpworks Airships (n.d.). In Blimpworks Airships. Retrieved December 8, 2013, from
http://rcblimp.net/blimp_outdoor.htm
16
Throwable Panoramic Ball Camera Captures 360 Shots When Sent Skyward (2013). In Steves Digicams.
Retrieved from http://www.stevesdigicams.com/news/throwable_panoramic_ball_camera_captures_360_shots_when_sent_skyward.html#b
17
ArduCopter Introduction (2012, November 17). In Google Project Hosting. Retrieved December 8, 2013, from
https://code.google.com/p/arducopter/wiki/ArduCopter_QuadIntroduction
18
NEWBIE, looking for long flight time. (2010, November 27). In RC Groups. Retrieved December 8, 2013, from
http://www.rcgroups.com/forums/showthread.php?t=1345539
19
Remote Control Airplanes Review 2014. (n.d.). In TopTenREVIEWS. Retrieved December 8, 2013, from
http://remote-control-airplanes-review.toptenreviews.com/
20
3DR RTF Quad (n.d.). In 3DRobotics Inc. Retrieved December 8, 2013, from
https://store.3drobotics.com/products/apm-3dr-quad-rtf
21
Align RC 6 Channel Helicopter 600 (n.d.). In Xheli. Retrieved from http://www.xheli.com/15h-kx0160npa.html
22
3DR ARF APM:Plane (2013). In 3DRobotics Inc. Retrieved December 8, 2013, from
http://store.3drobotics.com/products/3DR-ARF-APM:Plane
23
RC Blimp: Introducing the MicroBlimp (n.d.). In Microflight. Retrieved December 8, 2013, from
http://www.microflight.com/MicroBlimp-RTF-Set
24
Vendittelli, M. (2012). In Quadrotor Modeling. Retrieved December 8, 2013, from
http://www.dis.uniroma1.it/~venditt/didattica/eir/01_Modeling.pdf
84
25
Brain, Marshall, and William Harris. (2000, April 01). How Helicopters Work. Retrieved December 8, 2013 from
http://science.howstuffworks.com/transport/flight/modern/helicopter.htm
26
NMEA 0183. (n.d.). In Wikipedia. Retrieved December 8, 2013, from http://en.wikipedia.org/wiki/NMEA_0183
27
Frequency-hopping spread spectrum. (n.d.). In Wikipedia. Retrieved December 8, 2013, from
http://en.wikipedia.org/wiki/Frequency-hopping_spread_spectrum
28
Netcat: the TCP/IP swiss army. (n.d.). Retrieved December 8, 2013, from http://nc110.sourceforge.net/
29
(n.d.). In NeverWet. Retrieved December 8, 2013, from http://www.neverwet.com/anti-wetting.php
30
Optical Flow Sensor. (n.d.).In ArduCopter. Retrieved December 8, 2013, from
http://copter.ardupilot.com/wiki/optical-flow-sensor/
31
Quandcopter control function layers. (n.d.). In HefnyCopter. Retrieved December 8, 2013, from
http://hefnycopter.net/index.php?option=com_content&view=article&id=22:quadcopter-control-functionlayers&catid=9&Itemid=103
32
Engelbert, Wenzel, K. E., Masselli, A., & Zell, A. (2011). Automatic Take Off, Tracking and Landing of a
Miniature UAV on a Moving Carrier Vehicle. Web: Journal of Intelligent & Robotic Systems.
33
The APM 2 Board. (n.d.). In DIYDrones. Retrieved December 8, 2013, from https://code.google.com/p/ardupilotmega/wiki/APM2board
34
Build a Miniature High-Rate Speed Control with Battery Eliminator Circuit (BEC). (n.d.). In Stefanv. Retrieved
December 8, 2013, from http://www.stefanv.com/rcstuff/escbec.htm
35
Explanation of the Brushless Motor / ESC System and Capacitor Function. (n.d.). In Traxxas. Retrieved
December 8, 2013, from http://traxxas.com/forums/showthread.php?8958604-Explanation-of-the-Brushless-MotorESC-System-and-Capacitor-Function
36
USB. (2013, July 12). Wikipedia. Retrieved December 7, 2013, from http://en.wikipedia.org/wiki/USB
37
Creating the camera board. (n.d.). In Raspberry Pi. Retrieved December 8, 2013, from
http://www.raspberrypi.org/archives/3525
38
Adafruit Ultimate GPS Breakout (n.d.). In Adafruit. Retrieved December 8, 2013, from
http://www.adafruit.com/products/746#Technical_Detail
39
Estimate Electric Motor and Prop Combo. (n.d.). In adamone . Retrieved December 8, 2013, from
http://adamone.rchomepage.com/calc_motor
40
Difference in Plastic versus Carbon Fiber RC Quad Copter Slow Fly Propellers. (2013, September 25). In
YouTube. Retrieved December 8, 2013, from http://www.youtube.com/watch?v=ykiG4i_XRlI
41
AeroQuad 32 Flight Control Board Version 2. (n.d.). In AeroQuadStore. Retrieved December 8, 2013, from
http://www.aeroquadstore.com/AeroQuad_32_Flight_Control_Board_Version_2_p/aq32-001.htm
42
APM 2.5+ Assembled (Cables enter from top). (n.d.). In 3DRobotics Inc. Retrieved December 8, 2013, from
http://store.3drobotics.com/products/apm-2-dot-5-plus-assembled-set-top-entry
43
AutoQuad 6 Autopilot Flight Controller (n.d.). In Viacopter - Multicopters & Multirotors. Retrieved December 8,
2013, from https://viacopter.eu/multirotor-shop/flight-controllers/autoquad-6-multicopter-store
44
MWC MultiWii Lite Lightweight Version 4-axis Flight Control Board QUADX. (n.d.). Retrieved December 8,
2013, from http://www.goodluckbuy.com/mwc-multiwii-lite-lightweight-version-4-axis-flight-control-boardquadx.html
45
MultiWii PRO 2.0 Flight Controller w/MTK GPS Module. (n.d.). In Flight Controllers. Retrieved December 8,
2013, from http://witespyquad.gostorego.com/flight-controllers/multiwii-pro-2-0-flight-controller-200.html
46
PX4FMU Autopilot / Flight Management Unit. (n.d.). In PX4 Autopilot Platform. Retrieved December 8, 2013,
from https://pixhawk.ethz.ch/px4/modules/px4f
47
UAVX-ARM32 Full Sensors. (n.d.). In QUADROUFO. Retrieved December 8, 2013, from
http://www.quadroufo.com/product_info.php?products_id=88&osCsid=d7lf5mikok4tplcs0lr1814qo3
48
MPU-6000/6050 Six-Axis (Gyro + Accelerometer) MEMS MotionTracking™ Devices for Smart Phones, Tablets,
and Wearable Sensors. (n.d.). In MEMS Gyro-Accel. Retrieved December 8, 2013, from
http://invensense.com/mems/gyro/mpu6050.html
85
49
3-Axis Digital Compass IC HMC5983 (2012, January). In Honeywell. Retrieved December 8, 2013, from
http://www51.honeywell.com/aero/common/documents/myaerospacecatalog-documents/Defense_Brochuresdocuments/HMC5983_3_Axis_Compass_IC.pdf
50
(2013). In 3D Robotics: UAV technology. Retrieved December 8, 2013, from http://3drobotics.com
51
Delivery Information (2013). In JDrones. Retrieved December 8, 2013, from
http://store.jdrones.com/articles.asp?ID=7
52
LiPoBatteries (2013). In Wikispaces. Retrieved December 8, 2013, from
http://quadcopter.wikispaces.com/LiPo+Batteries
53
Robotics beta (2012, November). In StackExchange. Retrieved December 8, 2013, from
http://robotics.stackexchange.com/questions/554/quadcopter-lipo-battery-weight-capacity-trade-off
54
The APM 2 Board (2012, November). In DIY Drones. Retrieved December 8, 2013, from
https://code.google.com/p/ardupilot-mega/wiki/APM2board
55
Turnigy 6X FHSS 2.4ghz Transmitter and Receiver (n.d.). In Hobby King. Retrieved December 8, 2013, from
http://www.hobbyking.com/hobbyking/store/__24969__turnigy_6x_fhss_2_4ghz_transmitter_and_reciever_mode_2
_.html
56
(n.d.). In Raspberry Pi. Retrieved December 8, 2013, from http://www.raspberrypi.org
57
BeagleBone (n.d.). In BeagleBone.org. Retrieved December 9, 2013, from http://beagleboard.org/Products/BeagleBone
58
Products (n.d.). In Arduino. Retrieved December 8, 2013, from http://arduino.cc/en/Main/Products
Raspberry Pi Camera Board (n.d.). In Adafruit. Retrieved December 8, 2013, from
http://www.adafruit.com/products/1367
60
(n.d.). In Mouser Electronics. Retrieved December 8, 2013, from
http://www.mouser.com/search/ProductDetail.aspx?qs=0vL%2F4pb51PS411bmEDc26g%3D%3D/dp/B00H2ABZ
MS/ref=sr_1_2?ie=UTF8&qid=1386298343&sr=8-2&keywords=beaglebone+camera
61
GoPro (2013, December). In Wikipedia. Retrieved December 8, 2013, from http://en.wikipedia.org/wiki/GoPro
62
Genius 3220032100 WideCam F100 USB 2.0 WebCam (n.d.). In Newegg. Retrieved December 8, 2013, from
http://www.newegg.com/Product/Product.aspx?Item=N82E16826179091
63
(n.d.). In MPlayer. Retrieved December 8, 2013, from http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html
64
Camera (n.d.). In Raspberry Pi. Retrieved December 8, 2013, from http://www.raspberrypi.org/camera
65
H.264/MPEG AVC. (n.d.). In Wikipedia. Retrieved December 8, 2013, from
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
66
GlobalSat BU-353 USB GPS Navigation Receiver (n.d.). In Amazon. Retrieved December 8, 2013, from
http://www.amazon.com/GlobalSat-BU-353-USB-Navigation-Receiver/dp/B000PKX2KA
67
BU-353 GPS Receiver (n.d.). In USGlobalSat. Retrieved December 8, 2013, from
http://www.usglobalsat.com/store/download/62/bu353_ds_ug.pdf
68
APM 2.6 Set (external compass) (n.d.). In 3DRobotics. Retrieved December 8, 2013, from
http://store.3drobotics.com/products/apm-2-6-kit-1
69
Raspberry Pi Model B 512MB RAM (n.d.). In Adafruit. Retrieved December 8, 2013, from
http://www.adafruit.com/products/998
70
Arduino Due - assembled - Due (n.d.). In Adafruit. Retrieved December 8, 2013, from
http://www.adafruit.com/products/1076
71
Raspberry Pi WIFI Adapter / Dongle - The Pi Hut (n.d.). In Amazon. Retrieved December 8, 2013, from
http://www.amazon.com/Raspberry-Pi-WIFI-AdapterDongle/dp/B009FA2UYK/ref=sr_1_6?ie=UTF8&qid=1386475850&sr=8-6&keywords=wifi+dongle
72
Cables (n.d.). In 3D Robotics: UAV technology. Retrieved December 8, 2013, from
https://store.3drobotics.com/t/parts/cables
73
Haldane, M. (2013, August 8). U.S. Slowly Opening up Commercial Drone Industry. In Reuters. Retrieved
December 8, 2013, from http://www.reuters.com/article/2013/08/08/us-usa-drones-commercialidUSBRE97715U20130808
59
86
74
Projected Growth for Non-Military Use of Drones Presents New Business Opportunities (n.d.). In Business
Opportunities Journal. Retrieved December 8, 2013, from http://www.boj.com/projected-growth-for-non-militaryuse-of-drones-presents-new-business-opportunities/
75
Smithson, S. (2012, February 7). Drones over U.S. Get OK by Congress. In Washington Times. Retrieved
December 8, 2013, from http://www.washingtontimes.com/news/2012/feb/7/coming-to-a-sky-near-you/?page=all
76
Hex Airbot. (n.d.). In Hex Airbot. Retrieved December 8, 2013, from http://hexairbot.com/
77
DJI | All Products. (n.d.). In DJI. Retrieved December 8, 2013, from http://www.dji.com/products/
78
Micro Drone (n.d.). In Firebox. Retrieved December 8, 2013, from http://www.firebox.com/product/5565/MicroDrone?aff=512
79
Five Lessons for a Successful STEM Career. (n.d.) In Lockheed Martin. Retrieved December 8, 2013, from
http://www.lockheedmartin.com/us/products/procerus/quad-vtol.html
80
Unmanned Systems. (n.d.). In Northrop Grumman. Retrieved December 8, 2013, from
http://www.northropgrumman.com/Capabilities/Unmannedsystems/Pages/default.aspx
81
Unmanned Systems. (n.d.). In AAI Corporation. Retrieved December 8, 2013, from
http://www.aaicorp.com/products/unmanned-systems
82
Thermal Cameras and Video Analytics for Perimeter Security. (n.d.). In SightLogix. Retrieved December 8, 2013,
from http://www.sightlogix.com/
83
Drew, C. (2009, March 16). Drones Are Weapons of Choice in Fighting Qaeda. In New York Times. Retrieved
December 8, 2013, from http://www.nytimes.com/2009/03/17/business/17uav.html?pagewanted=all&_r=0
87