/public/

Gate Reviews

Table of Contents 1 MSD I: Readiness to move to Build & Test 1.1 Action Items 1.1.1 Software 1.1.2 Mechanical 1.1.3 Electrical 1.2 Completed Action Items 1.2.1 Software 1.2.2 Mechanical 1.2.3 Electrical 1.3 MSDII Milestones 1.4 Team Vision For Imagine 1.4.1 Interactive Demo 1.4.2 Supporting Informational Poster 1.5 Team Vision for Week 5 Test Demo 1.5.1 Software 1.5.2 Mechanical 1.5.3 Electrical 1.6 Post Mortem 1.6.1 Positives 1.6.2 Negatives 1.6.3 Team Critique 1.7 Status Review 2 MSD II: Project close-out 2.1 Status Review 2.1.1 Summary 2.1.2 Requirements and Comments 2.1.3 Risks

MSD I: Readiness to move to Build & Test

Action Items

Software

• Determining if we will use an Android application or a web based application
• Establishing connections from raspberry pi to the amazon database
• Determining if the amazon database is the best solution for our project
• Establishing connection from amazon database to web application
• Creating layout for web application
• Populate web application with database data

Mechanical

• Mounting location and method
• More detailed test bed drawings and explanations

Electrical

• Choose parts for PCB circuitry to power and allow for the device to be rechargeable.
• Create a schematic showing the chosen parts and the necessary circuitry for application. Also show interaction of board with other sensor through the inputs or outputs used.
• Choose rechargeable batteries with an adequate capacity to satisfy the customer requirements.
• Draft a PCB layout schematic.
• Finalize the design the power management PCB and put it on order.

Completed Action Items

Software

• From talking with our customer, we decided to use the Web application instead of the android application.
• We established communications from the raspberry pi to the amazon database and are able to modify data in the amazon database
• Established communications from the web application to the amazon database and are able to retrieve data from the database and display the data to the users.
• Researched Different DB applications and determined Amazon was the largest, most stable solution for the smallest cost

Mechanical

• Mounting location - Top of helmet
• Mounting method - screws and epoxy - boards housed in 3D printed casing
• CAD of test bed with more detail
  • More thought out piston and head frame mounting and maneuverability

Electrical

• Chosen parts to regulate the output voltage to 3.6V so meet the maximum voltage requirements of the sensor and processor, charge the batteries used at a rate maximum rate of 500mAh through micro-USB, and batteries with integrated ICs to handle safety functions.
• Created a schematic showing the ICs and their application, along with the connections possible with the sensor and accelerator for relaying data.

• Choose a battery set-up using 3x 1200mAh li-poly batteries. Connecting in parallel gives a total capacity of 3600mAh.
• Created a draft of the PCB layout schematic.

MSDII Milestones

• Mechanical
  • Build test bed - phase 1
  • Test Bed functioning and demo - phase 2
  • Implement software side with mechanical testing - phase 3
  • Complete testing of helmet impacts - phase 4

• Electrical
  • Have a fully functional prototype PCB to power the sensor and processor for systems level testing - Phase 2
  • Physical testing/proof of battery life - phase 2/3

• Software
  • Implement connectivity from sensor to raspberry pi’s sqlite3 buffer - Phase 1
  • Implement web application to retrieve data from db phase 1
  • Implement connectivity from raspberry pi sqlite3 buffer to database - Phase 2
  • Make user interface clean and easy to use Phase 2
  • Implement Software Connectivity from sensor to DB through raspberry pi - Phase 3

Team Vision For Imagine

Interactive Demo

• Display where we will see if people can give the helmet a concussive blow.
• This display will use the base plate, head fixture, and helmet from our Testing rig.
• We will provide hardware to allow people to hit the helmet safely, such as a rubber mallet, boxing gloves, or another material that can strike the helmet and not cause damage to the casing itself.
• A laptop running the web application will allow users to view the force that they hit the helmet and to see if it causes a concussive blow.
• A secondary board not enclosed and attached to helmet will be displayed to crowd. We can explain the inner workings of the board.

Supporting Informational Poster

• On poster, we will show test results as well as an image of workflow to show how the pieces connect together. We also will have an image of the testing rig with description of it.
• Testing results showing the accuracy of the sensor and the theory/calculations proving the results.

Team Vision for Week 5 Test Demo

Software

• Want to have a laptop running the web application to show the user interface
• Want to have raspberry pi able to send data it retrieves from the sensor to the database
• Want to have web application able to retrieve this information and show that there was an impact on the player.

Mechanical

• Adjustable base/helmet to show all areas of helmet we can hit
• Fires and hits correctly
• Show and demonstrate that our sensor matches known sensors (sensors from packaging science?)

Electrical

• Have a prototype board to show and demo basic functions
• Present data showing the charge and discharge rates of the batteries.
• Long term run time data to show expected life time in a practical use scenario

Post Mortem

Positives

• Communication
• Meetings
  • Organization
  • Team Members contributing to all discussions
• Engineering standstills were able to be resolved with the help of teammates
• Interpersonal communication during in-person meetings was smooth

Negatives

• Need to add engineering discussions to our overall meetings more
• Have a stronger balance of this project and other classes
• Ensure all members have a strong idea on all aspects of work being done.
  • Misinterpretation of other group members led to discussing the same problem many times.
• Close communications with guide and customer on their current vision of project
  • Possible solution - progress reports more often to evaluate how we are doing on par with each phase

Team Critique

For our review, each of us individually completed the self critique, which can be viewed here

Status Review

After the Detailed Design Review, several aspects of the project were to be revisited and solutions were to be found. For the software side, possible alternatives to both a UI as well as which database would be used was revisited. After comparing multiple database alternatives and speaking with the customer, we have decided to continue moving forward with the Amazon Database, and change our UI. Instead of an android application, a C# web application will provide the user interface. On the mechanical section, the design of the testing rig was revisited as a team and a more in depth design was to be created to ensure tests could cover multiple locations of the helmet. The design created now is one we feel is more universal and will be the one to be built. Finally for the electrical, the PCB design was to be optimized and shrunk for a more cost effective and space efficient layout. Our PCB layout is now being finalized and prepped for purchase.

MSD II: Project close-out

Status Review

Current state of the project

Summary

• We never got to put on the 200 G accelerometer because we did not have the test time. The mechanical team did not realize the 200g accelerometer hadn't been calibrated like the 50g had been. Because of this, the CE team couldn't create the formulas/code for the accelerometer. This miscommunication led to us not giving priority to testing the 200G accelerometer earlier, and instead giving a larger amount of time to the overall survivability and general location and mounting methods.
• Wiring could definitely be improved. We had a hard time placing all the components because there was not enough wire to place them as far apart as we wanted. In other cases, we had too much wire and the extra wire looked ugly.
• Aesthetics need to be improved. We were so focuses on just trying to get everything up and running we didn’t attempt to make it look nice for the final product, especially since we figured that all the electronics would be under the foam and hidden from general view.
• We stayed well within the design budget, but individual production costs were $100 over what the customer wanted. It would have been very difficult to get the helmet under $20/device, but with some more electronic redesign and bulk purchasing we believe the production, material cost would be closer to $20.

Requirements and Comments

• A link to our original customer requirements to back-check everything can be found here
• Battery life – 300 to 400 hours which is greater than the marginal value and about the ideal value since I would last about one season.
• RF Range
• Max G force capability – did not prove over 100 Gs repeatably. Since the 200G accelerometer was not placed on the device. We do know we can survive a great number of hit (almost 2500 hundred at imagine alone). During testing we do know we exceeded 50G’s several times.
• FormFactor – Did not exceed normal helmet size and weight is still relatively normal
• Cost – previously discussed. Stayed within budget, but bulk purchasing and some efficiency will need to happen to reduce production cost to $20/device.
• Latency from detection to notification – 1 second from our test results which is within our 200sec requirement.
• Temperature Requirements – testing will have to be completed by customer. Lack of time to do a test that our customer did not feel was a priority.
• data storage - customer requirement was 2 years worth of data could be stored. Testing began in March and has been going well. More long term testing would need to happen to prove that it will continue to work long term.
• Time to pull historical data – requirement was 15 seconds, we can do it in 0.2 seconds from testing.
• Database insertion time for single data – requirement was less than 1 second, testing showed 0.1 seconds.
• database retrieval time for single player data – requirement was less than 1 second, testing showed 0.037 seconds.
• number of collectors that can communicate to a single raspberry pi – wanted at least 10 units, but testing showed we can handle at least 100 units. Enough for an entire football team.
• Time to alert of concussion – app is meant to display a concussion hit in 5 seconds, in reality it depends on internet and computer speed. On average the data can be seen within 5 seconds, as proved during Imagine.

Risks

• A link to our final risk asessment page can be found here.
• Improper use of device – more warnings in a user manual could be helpful. We noticed at imagine that hard hits were able to displace the helmet. Granted this was on a rubber dummy, and displacement depends on the helmet, not our device.
• Humidity and water-resistant tests must still be conducted.
• We believe we had a wire dislocated during Imagine. A focus on wire placement and securement will need to be added to the final product.
• Human testing still needs to be completed.

• Changes to Project
• In the future, customer requirements must be understood in more detail. Asking the customer what they want is not enough to get the full picture. We need to find what they expect to see for each system.
• Because of delays, we were forced to forego some tests to complete the primary deliverables on time.

Lessons learned, etc.

• Wiring and aesthetics should be its own task with someone responsible for it.
• Plan around sharing testing space with another team. The other team that was sharing our cubical took up a lot of space so it was hard for both teams to test at the same time
• Find out who in ITS you should talk to in order to get ethernet. We could only get it in one cubical and since both teams needed ethernet access. Chris tried to get it set up but ITS never answered. Sometimes going to someone’s office and asking nicely solves things faster.
• Always plan to be behind schedule and have a week or two worth of flexibility in your schedule
• Go over customer requirements at every review to avoid miscommunication.

---

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation