FINAL PROJECT PRESENTATION R 10003 Wireless OpenSourceOpenArchitecture Command

FINAL PROJECT PRESENTATION R 10003 - Wireless Open-Source/Open-Architecture Command Control System (WOCCS) ERIC HETTLER MANUEL PARIS RYAN MILLER CHRISTIAN MORENO JAMES REEPMEYER

Agenda � Mission statement � Project relevance � Customer needs � Roadmap � Proposed projects � Additional Team values and norms � Required resources 2

Mission statement We will develop a new command control system that will introduce a reliable, intuitive, modular and secure system to benefit MSD teams and teach valuable skills and technology relevant to the needs of the Harris Corporation. 3

Mission statement � Primary Goals � Produce project readiness packages for 3 MSD teams � Define new WOCCS project family � Stakeholders � Harris Corporation � MSD Teams � RIT Educational Community 4

Project relevance � Partnership between Harris and RIT � Hire students already involved in RF technologies � Can be used by other Senior Design groups in future projects 5

Customer needs � Affinity diagram � Function tree � House of quality 6

Affinity Diagram MSD Students Promote RF Technology Interest Long Range Harris RIT Educational Low Power Inexpensive Modularity Reliable Secure Easy and Accessible Interface High visibility Ease of Integration Value-Added System Intuitive – Easy to Use, Easy to Teach MSD Customers Community 7

Few channels, high bandwidth Wireless Command Many channels, low bandwidth Sensor data Wireless Feedback Streaming real-time video Open source Scalability Long battery life Develop a modular wireless C&C system Use on a variety of vehicles Small footprint Sufficient range Battery life Reliability Range Minimal data loss User-friendly interface Shorter range Biomed applications Lightweight (to be carried by a user) Feedback-intensive Secure 8

Roadmap Description Dimensions of Progress RF Link 2 -way links, bandwidth, physical size, reliability, Radio link between base- security, power end (user) and device end consumption C&C Software Power consumption, Onboard controller physical size, processing between RF link and device power/speed, reliability, sensors/controls robustness Processing requirements, Software to control C&C robustness, control hardware efficiency API Software Data types, data quality, SW interface between UI processing power and RF hardware required, data speed C&C Hardware 9

Viable First Iteration Goals Unlikely 1 st Gen Roadmap 2 nd Gen 3 rd Gen 4 th Gen 5 th Gen Far out there Revised PCB COTS fully scalable hardware Custom PCB analog and digital Satellite and driver with HD video command Interconnected Communications RF Link development Scalable COTS capability feedback Modular PCBs (global coverage) desktop (base end) COTS FPGA revised desktop C&C Redundancy self-repairing Hardware (on board) and COTS FPGA Custom PCB management hardware Can navigate can fly (takeoff and RP-1/10 on a Control of land) airframe campus wide airframe flight A/C/D/. . . Can drive RP- autonomous control surfaces can auto-pilot autonomously 1/10 and C&C Can drive RPsearch and over WOOCS RF airframe control the mars 1/10 accessories Software rescue link A/C/D/. . . rover Basic API linking RF Supports scaling Plug and Play RF software and bi-directional technology C&C Support HD communication compatible with any software to Refined API video API on Analog and desktop / laptop / user with scalability bandwidth Software Digital channels netbook 10

Roadmap Description Dimensions of Progress Packaging Physical size; heat, Packaging for RF hardware, pressure, humidity, C&C hardware, and power vibration, impact, EMI supply resistance Power Supply Consumption, storage, Supplies power to device RF acquisition, quality, and C&C hardware connectivity, scalability UI Ease of use, robustness, Allow user to configure RF link data continuity/ and API data structure completeness Testbed Physical method for testing the system components Device types, data quality, ease of use 11

Roadmap Viable First Iteration Goals Unlikely Packaging Power Supply UI Testbed 1 st Gen 4 th Gen 5 th Gen Far out there Box passes EMI / on-board device on-board Temp / Alt / fits in a box device fits in a Humidity / Belt mountable Basic suitable for box suitable Vibration / (biomed single integrated RP 10 Packaging for Airframe A lightning tests application) chip (micro-E. . . GO!) Battery 2 nd Gen 3 rd Gen Smaller Energy Battery + Solar Management Alternate power (not batteries!) controller interface (Pistol Plug and Play + Simple User grip or RC plane Touchscreen Feedback remote style) Labview Basic performance confirmation w/ light Airframe sensors and RP RP instrumentation / flags instrumentation Implementation implementation Harvested/Regener Fuel Cell ative Power Glove with feedback (tactile / force body motion feedback) tracking VR goggles Subinterface dural implant Biomed Implementation (pager sized transmitter for spine position tracking) Mars Rover 12

Timeline Fall 2009 Winter 2009/2010 Project 1 Project 2 Spring 2010 Project 1 Project 2 Fall 2010 API 1, gen 1 Winter 2010/2011 API 2, gen 1 Spring 2011 Fall 2011 API 1, gen 2 RF link 1, gen 1 Winter 2011/2012 API 2, gen 2 RF link 2, gen 1 C&C 1, gen 1 Spring 2012 C&C 2, gen 2 Fall 2012 API 1, gen 3 RF link 1, gen 2 UI 1, gen 1 Winter 2012/2013 API 2, gen 3 RF link 2, gen 2 UI 2, gen 1 RP 1 Spring 2013 RP 2 13

Work distribution for next quarter 14

Staffing Risk Assessment Description of Possible Risk Consequences Failure to share data between teams Re-work, poor interoperability Team Member Loss of time, becomes work needs to be temporarily recovered indisposed of Team Poor work members lack quality, missed the required deadlines skillset Loss of time, Team work needs to be Member gone recovered, loss of indefinitely knowledge Probability of Risk (H/M/L) M H L L Severity of Risk (H/M/L) H M Overall Risk (H/M/L) Contingency Plan H Make sure all team members understand this requirement M Have more than one team member working on each aspect of the project M Ensure teams are balanced during week 1, outsourcing L Have more than one team member working on each aspect of the project 15

Proposed projects � P 10205 – WCCS Option A � P 10206 – WCCS Option B � P 11205 – WOCCS API Development 16

P 10205 – WCCS Option A � Mission Statement �The team will produce a low risk wireless command control system which will allow for software-defined entry of user commands and use COTS RF transmitters to wirelessly send these commands to the robotic platform device. The team will provide basic control of the robot and allow for sensor data transmission back to the base station. Once implemented, the team will be responsible for testing and characterizing the system as much as possible. 17

P 10205 – WCCS Option A � Staffing Requirements NAME Discipline Role/Skills TBD EE Faculty Guide, Will work closely with the team on an on-going basis to facilitate success. TBD CE Faculty Consultant, Will provide discipline technical support on an intermittent basis. TBD ME Teaching Assistant TBD – Student ME Team Lead / Land Vehicle Integration TBD – Student EE Lead Engineer/RF Specialty/Test plan development TBD – Student EE Land Vehicle Integration TBD – Student CE Interface development/Base station integration 18

WCCS Option A&B � Intellectual Property Considerations �All work to be completed by students in this track is expected to be released to the public domain. Students, Faculty, Staff, and other participants in the project will be expected to release rights to their designs, documents, drawings, etc. , to the public domain, so that others may freely build upon the results and findings without constraint. �Students, Faculty, and Staff associated with the project are encouraged to publish findings, data, and results openly. 19

P 10205 – WCCS Option A � Preliminary Work Breakdown Structure 20

P 10205 – WCCS Option A � Three Week Project Plan Person Week 0 -> 1 Tasks Week 1 -> 2 Tasks Week 2 -> 3 Tasks TBD – Student (ME) Requirements definition, Customer needs Market Assessment Begin packaging design TBD – Student (EE) Requirements definition, Customer needs Market Assessment Begin power supply development TBD – Student (EE) Requirements definition, Customer needs Market Assessment and Component Selection and Performance Test Plan development TBD – Student (CE) Requirements definition, Customer needs Market Assessment UI planning, Performance Test Plan development 21

P 10205 – WCCS Option A � Required Resources � Faculty ○ EE Faculty Guide – Available ○ Harris Corp – Customer - Available ○ CE Technical Consultant – Available � Environment ○ EE Lab ○ Manufacturing Facility � Equipment ○ RF Sniffer ○ RP-1 ○ LV-1 � Materials ○ PC Base Station 22

Technical Risk Assessment – Option A Technical Risk Assesment Description of Risk Possible Consequences Chosen Costs would component increase, loss of does not meet time specification Build time Chosen increases, delay in standard is commencing more difficult testing, project to impliment scope may not be than expected met Chosen RF Time delays, standard does increased cost, not meet ANY potential project requirements failure (if late) Probability of Risk (H/M/L) M L M Severity of Risk (H/M/L) M H H Overall Risk (H/M/L) Contingency Plan M Purchase component from different vendor M Call in assistance from Option B team, Spend quality time on market assessment H Plan for a backup option during market assessment

P 10206 – WCCS Option B � Mission Statement �The team will produce a high risk wireless command control system which will allow for software-defined entry of user commands and use COTS RF transmitters to wirelessly send these commands to the robotic platform device. The team will provide basic control of the robot and allow for sensor data transmission back to the base station. 24

P 10206 – WCCS Option B � Staffing Requirements NAME Discipline Role/Skills TBD EE Faculty Guide, Will work closely with the team on an on-going basis to facilitate success. TBD CE Faculty Consultant, Will provide discipline technical support on an intermittent basis. TBD ME Teaching Assistant TBD – Student ME Team Lead / Land Vehicle Integration TBD – Student EE Lead Engineer/RF Specialty/Test plan development TBD – Student EE Land Vehicle Integration TBD – Student CE Interface development/Base station integration 25

P 10206 – WCCS Option B � Preliminary Work Breakdown Structure 26

P 10206 – WCCS Option B � Three Week Project Plan Person Week 0 -> 1 Tasks Week 1 -> 2 Tasks Week 2 -> 3 Tasks TBD – Student (ME) Requirements definition, Customer needs Market Assessment Begin packaging design TBD – Student (EE) Requirements definition, Customer needs Market Assessment Begin power supply development TBD – Student (EE) Requirements definition, Customer needs Market Assessment Component Selection and Performance Test Plan development TBD – Student (CE) Requirements definition, Customer needs Market Assessment UI planning, Performance Test Plan development 27

P 10206 – WCCS Option B � Required Resources � Faculty ○ EE Faculty Guide – Available ○ Harris Corp – Customer - Available ○ CE Technical Consultant – Available � Environment ○ EE Lab ○ Manufacturing Facility � Equipment ○ RF Sniffer ○ RP-1 ○ LV-1 � Materials ○ PC Base Station 28

Option B Technical Risk Assessment Option B Technical Risk Assesment Description of Risk Possible Consequences Probability of Risk (H/M/L) Severity of Risk (H/M/L) Overall Risk (H/M/L) Contingency Plan Chosen component does not meet specification Costs would increase, loss of time M M M Purchase component from different vendor Chosen standard is much easier to Lack of things to do impliment than during MSD II expected L M L Assist Option A team, add more scope to performance assessment Chosen RF standard does not meet ANY requirements Time delays, increased cost, potential project failure (if late) M H H Plan for a backup option during market assessment Chosen RF standard is not understood by team members Project failure, feature imcompletion, delays H H H Faculty/industry consultations 29

P 11205 – API Developement � Mission Statement �The team will develop an Application Programming Interface (API) to handle user inputs and commands, data transfer, and interfacing with various RF link components. 30

P 11205 – API Development � Staffing Requirements NAME Discipline Role/Skills TBD SE Faculty Guide, Will work closely with the team on an on-going basis to facilitate success. TBD EE Faculty Consultant, Will provide discipline technical support on an intermittent basis. TBD SE Teaching Assistant TBD – Student SE Team Lead / API development TBD – Student SE Lead Engineer/API development TBD – Student SE UI development TBD – Student EE Test stand enhancement TBD – Student EE RF component development 31

P 11205 – API Development � Intellectual Property Considerations �All work to be completed by students in this track is expected to be released to the public domain. Students, Faculty, Staff, and other participants in the project will be expected to release rights to their designs, documents, drawings, etc. , to the public domain, so that others may freely build upon the results and findings without constraint. �Students, Faculty, and Staff associated with the project are encouraged to publish findings, data, and results openly. 32

P 11205 – API Development � Preliminary Work Breakdown Structure 33

P 11205 – API Development � Three Week Project Plan Person Week 0 -> 1 Tasks Week 1 -> 2 Tasks Week 2 -> 3 Tasks Become familiar with team members. Become familiar with project. Research past projects. Re access customer needs. Determine individual tasks. Begin individual tasks. TBD – Student (SE, Team Lead) TBD – Student (SE, Lead Engineer) TBD – Student (SE, API Development) TBD – Student (SE, UI Development) TBD – Student (EE, Test Stand Enhancement) TBD – Student (EE, RF Component Development) 34

P 11205 – API Development � Required Resources �Faculty ○ SE Faculty Guide – TBD ○ Harris Corp – Customer - Available ○ CE Technical Consultant – TBD �Environment ○ EE Lab �Materials ○ LV 1 ○ Base station & RF Hardware ○ Documentation 35

API Technical Risk Assessment Description Possible Probability of Risk Severity of Risk Consequences (H/M/L) Over. Incomplete scoping of project goals, project goals incomplete API M H Overall Risk (H/M/L) Contingency Plan H Check scope during week 1 with faculty guide Failure to Inabillity for produce an future teams to open system use the API M H H Failure to Inabillity for define future teams to interfaces use the API H M H Complete documentation during every step, adhere to all standards, regular faculty consultations 36

Additional Team values Open: Each team member will provide thorough documentation for all discussions, decisions, and deliverables. Each member will take adequate notes and logs. All team documentation will be hosted on EDGE, or some other open and publicly accessible location to ensure access by future project teams. Interface standards will be documented, posted publicly, and distributed to all applicable parties (team members, customers, team leads on projects using the interface, etc. ). 37

Accepted Norm Of Performance Value Open Unsatisfactory Needs Improvement The team member failed to pass on critical information The team member required for the documented some team (or a future decisions, with team) to succeed. critical omissions. The team member failed to take notes shared or post documentation on with some design or interface stakeholders but decisions. neglected others. Significant work Some work must be redone be repeated. from the beginning due to the failure. Meets Expectations Exceeds Expectations The team member provided thorough provided complete documentation and documentation of shared it with all technical relevant decisions and stakeholders. The made it available documentation publicly (EDGE). was made public All stakeholders and available to were adequately future teams. Any informed. No errors resulted in rework is minor rework and necessary. little loss of time. 38

Outstanding Items � Speak with Harris about projects �Budget �Advising? Contacts? � Staffing Requirements �Faculty Advisers and Guides �TAs 39

Questions? 40