Customer Handoff & Final Project Documentation
Table of Contents
Team Vision for Final Demo and Handoff
Planned on Accomplishing
- Finish implementing coach and player details page
- Add cell coloring to data tables
- Implement Observer Page
- Perform testing with headform
- Attach 200G accelerometer
- Perform temperature testing
- Finalize attachment method
- Finish adding the necessary components to the board for full integration with the helmet.
- Test how long it would take to fully charge the battery from depletion
- Estimate the operation time range based test done to discharge the battery
- Modified Raspberry Pi to start the Python scripts on Power on
- Implemented coach page and can view a players details
- Tables of data are now colored by rows for emergency scenarios and battery column is colored
- Observer page was implemented
- Completed the necessary additions to the battery board to make it fully functional and ready integration
- Tested the time to discharge the batteries and used the data to estimate the operating time of the device
- Attached batteries with glue - would have preferred to use Velcro for future iterations
- Attached all components
- Additional ME testing
- Added 3D printed case for charge board
Test Results SummaryWhile testing our design, we had a document to track the results. while the major aspects of this will be talked about below, a link to our entire document can be found here
Range TestingTested the range capabilities of the controller and collector. The test was executed by setting up the collector and PC connected to the collector monitoring data packets collected. The Controller was then set 10 yards away and sent 20 packets. After the 20 packets were sent, if there were no packets dropped,the controller would be moved back 10 more yards and would send 20 more packets. This process was continued until the controller did not receive all 20 packets. Using the antenna on the collector and the controller board being in the line of sight from the collector, the controller board was able to be moved back 160 yards from the collector. At this range only 19 packets were received. The graph bellow shows how many packers were received for each distance.
DB Stress TestingTested the database read performance for singe read operation as opposed to multiple data points. the test was executed in a very similar fashion where a script put a load on the database and a second script was used get the read times. the results seem to show that it does not matter how much stress is on the DB but how fast the Ethernet connection the PC running the tests.
Operating TimeIn order to estimate the device's operating time, the time it took the batter to reach its fully depleted state from nearly full capacity was tested using a current draw of 100mA. Using a much larger current allowed time to be saved as the possible operating time of the device was known to be in the hundreds. Knowing the total current being draw from the device and how many hours it took for the battery to discharge with 100mA, the range of operating time could be estimated
Testing showed that a current of 2.8mA would be drawn from the battery board when connected to the battery pack, and the controller board would draw a max of 5.5mA when transmitting. The current testing for the control board was done under the worst case scenario, so it can be assumed that the current draw on average will be far lower. Based on the numbers obtained, the device would run for 180 minimum hours at minimum. When taking into account that transmissions will be done periodically, the practical run-time of the device will be far longer and estimated to run beyond 300 hours with a maximum of 500 hours.
- Batteries were mounted using adhesive glue – in the future we would prefer to use Velcro
- Charge Board was given a 3D printed case where the
board and components were fixed with epoxy to prevent any
potential movement of the components which could fry the
- An inline fuse has been purchased for Imagine RIT so that additional protections are in place to prevent the destruction of all electrical components because long term impact testing could not be completed due to how long it took to get the board manufactured.
- Charge board and controller board were fixed down
- Velcro allows for the parts to be removed and replaced incase of damage or manufacturing error
- Charge board can be charged by pulling back on the foam and placing the microUSB into the board.
The device was dropped from a height that exceeded what our 50 G accelerometer could calculate. Devices survived after 3D printed cases were used to protect them. Accelerometer survived best in the crown and ear locations. When placed on the forehead the accelerometer failed to withstand repeated impacts. Mounting method with screws and epoxy withstood impacts better than only epoxy. The final mounting method and location resulted in an average standard deviation of 2.39 and 2.94 for the crown and ear respectively.
Risk and Problem Tracking
- Repeated impacts caused damage to the controller
- Controller board casing was used for all future tests
- Issues with ethernet access
- Requested access several times ITS never set up more than one cubical. We have to fight for time with the other team in our cubical.
- Damage to wire once 3D printed controller board case
- Believe to be mitigated by completely securing devices down closer to one another and taping the wires down to prevent any movement or pull.
- Issues with using the charge board for charging the
batteries without the need of an external source
- Solved by making additions on the board to supply the necessary voltage to an unused pin
- Issue with charge board components being too close
together – caused fear that any damage would fry
that board and the controller board
- Created 3D printed case and secured components with epoxy to board to prevent damage
- Purchased inline fuse to add second layer of protection
- 200 G accelerometer could not be implemented
- Not enough time to collect the data needed in order to extrapolate the data required to create the formulas required for the 200 G accelerometer’s implementation. This was partially due to the reasons listed above.
- Our problem tracking can be found here here.
- All project risks can be found here.
Final Project Documentation
- Our technical paper can be found here.
- The final poster is here.
- Our final BOM list can be found here
- Our project had numerous CAD and other schematics throughout the course of this project. A link to the folder of schematics can be found here (credit for the test rig goes to group 18072)
- Manufacturing and Assembly Instructions can be found here
- Operator Manual can be found here
- Service Manual can be found here
- More versatile mounting method for accelerometer
- More testing of helmet to get proper statistical analysis of standard deviation
- More elegant layout for web application
- Implementing pop up windows instead of entire new pages
- Revision of board to make it smaller
- Revision to implement several improvements that could avoid the issues we ran into
Functional Demo MaterialsA link to the pre-read document can be found here.
Plans for Wrap-up
- Pre-Imagine Meeting Friday @ 5PM
- Imagine RIT
- Reading Day Take Down and Inventory Sorting
- Gate Review on Reading Day?
- Clean out cubical and return any borrowed equipment to proper owners
- Get test dummy from Equipment Management from Recreation
- Assist in cleaning out cubical
- Find out where materials that the customer does not want/need should go
- Go over code again to make sure that it is all properly commented for future developers to see
- Make sure there is documentation that is provided to the customer about how to set up the Collector and raspberry pi
- Grant the customer access to the Amazon database
- Final tweaks on web app
- Pass on app to customer