This page documents the process the team went through to accomplish a System Design. All sections on the EDGE were organized for ease of read. At the end of each section, a PDF version of each document is linked at the end.
In addition, links to the actual documents for each section can be found here Systems Level Design Documents
Team Vision for System-Level Design Phase
System Design Team Pre-Plan:
- Research and design amplifier for use with current prototype.
- Design w/ team “orientation” into current Prototype.
- Help finalize decisions on input sensor type.
- Develop a Functional Decomposition for the product.
- Develop Concept Development : Morph Chart, Pugh Chart, Selection Criteria.
- Determine Systems Architecture and develop relevant charts.
- Complete required prototypes (Dr. Hochgraf).
- Develop Concept Design (CAD model).
Team Plan For the System Design Phase:
Concept Selection Criteria:
- Less than 1 year (Imagine RIT)
- Budget : $500
- VIP must gain
- Not just a science experiment
- Simplistic in use
- Resources (intellectual)
- Cannot interfere with other health devices
Concept Selection Process:
Feasibility: Prototyping, Analysis, Simulation
Analysis : Individual Members' Feasibility Questions:1- What are we expecting from the device in terms of
- a. How fast the user is moving
- b. Location of device
- c. How long would it take for the sensor to detect an object
2- Can 3D audio be used to accurately pinpoint an angular offset to a point?
3- Is using bone conduction audio feasible if the root audio will be superimposed by surrounding sounds?
4- Is picture distance enough to compare reference points ?
5- Can the device store all reference points or have easy access to images of the reference points?
6- Is it comfortable for the user to control the device with buttons?
7- Would the device easily fall off the user’s face/head since VIP are known to move their head to gauge orientation position as a reactionary nature?
Assumptions:1- RaspberryPi Used
2- RaspberryPi Camera Used
3- Wearable Device
Means of Answering Feasibility Questions:1: Device expectations can be assessed for various applications through the following approaches:
- a: Done with distance measurement computation relative to the rate of response from the device.The device responds at an average of 2.3 seconds while user moves at 4.55ft/second so the device covers approximately 10 feet per every image capture response from the ML Algorithm.
- b: Feasibility of locating the device will have to be tested through prototyping. One reasonable way to approach this is to create a controlled environment and gather data on the location generated by subsystems such as the gyro and camera.
- c: This question is relative to the sensor being used. If the assumption is that we’re using a camera, based on the open source machine learning algorithm is approximately 2.3 seconds per image captured.
2: Prototyping a device that will output 3D audio (with a static reference point of “0 degrees”) to two earbuds / Stereo headphones will demonstrate how distinguishable and understandable 3D audio can be.
3: Prototyping bone conduction while testing superimposed surrounding audio will provide a good understanding of this function’s feasibility.
4: Picture distance question is best answered by analysis and prototyping. Look for studies where picture matching has been performed
5: To determine the answer to this question: one must know how big a picture is (typically in megapixels) and how much storage space that will consume. Then, it must be determined how much storage space is on the device after the final code and other necessary peripherals are loaded.
- a: Assume that we’re using raspberry pi
- b: Assume we’re using a pi cam
- c: Assume that the final program takes up 25% of available hard drive space ; thus 75% availability for reference points
6: Will be comfortable to use as long as button has sufficient structural integrity behind it. The volume-control slider will be as usable as a hearing aide..
7: One solution to test feasibility for stability on the user's body is to run multiple iterations of a brute force test on the user. Additionally, having an elastic rope to hold it in would solve the problem as well.
Customer and Engineering Requirements
System Architecture Mapping:
Designs and Flowcharts
System Architecture Input Stage:
System Architecture Processing Stage:
System Architecture Output Stage:
Design Review MaterialsInclude links to:
- Presentation and/or handouts
- Notes from review
- Action Items
It is appropriate for you to send your customer and guide a link to this page in preparation for the review. This will ensure that they know what you will be presenting and how to view all of your work. Any EDGE link should start with http://edge.rit.edu/edge/P1xxxx..... Using "http" instead of "https" will ensure that non-RIT stakeholders can view the content without being prompted for a DCE login and password.
Plans for next phase
Team Plan For Phase III:
Individual 3-week plan:
|Name||Role||Individual 3-Week Plan|
|Deepti Chintalapudi||Project Manager||Phase(I) Three-Week-Plan|
|Suhail Prasathong||Team Lead||Phase(I) Three-Week-Plan|
|AbdulAziz Alorifi||Team Facilitator||Phase(I) Three-Week-Plan|
|Josh Drezner||Purchasing||Phase(I) Three-Week-Plan|
|Stuart Burtner||Engineer||Phase(I) Three-Week-Plan|
|Eronmonsele Omiyi (EJ)||Engineer||Phase(I) Three-Week-Plan|
- As an individual on the team, what are you doing to help your team achieve this vision? (Use the individual 3-week plan template for this).