Multidisciplinary Senior Design ConferenceKate Gleason College of Engineering

Rochester Institute of TechnologyRochester, New York 14623

Project Number: P18071Wireless Concussion Detection Helmet

Brittany LacyMechanical Engineering

Josh MetzgerComputer Engineering

Max ReitzMechanical Engineering

Robert FrumusaComputer Engineering

James CummingsMechanical Engineering

Isaac GarlandElectrical Engineering

AbstractIn nearly all contact sports the player runs the risk of receiving a concussion. This can seriously impact the player’s health for the rest of their life, as damage increases so too does the chance of subsequent concussions. Sports such as football and hockey have been under intense scrutiny in recent years regarding the mental health of their players. While modern day precautions like advanced helmets aid in mitigating the risk of a concussion, there is no real time safety precaution to assist the diagnosis of a player’s concussion. The wireless concussion detection helmet is meant to solve just that issue. The device will monitor the player during the game and track all high impacts he/she feels during an event. If the impact is hard enough the coaching staff can be warned, and the player can be immediately removed from the game and begin treatment. With full confidence, the player can know that they should not continue or face the risk of permanently doing damage to themselves.

BackgroundConcussion HistoryConcussion diagnosis has been difficult, especially within sports communities. Pressure on players from coaches and teammates to continue playing, as well as a player’s own desire to stay in the game, can lead to potentially damaging head impacts to being ignored to going unnoticed. The idea of “the concussion threshold” is popular among helmet designers and professionals in sports medicine. The premise of this is that if a blow to the head is above a certain force then it will cause a concussion and otherwise will not. While this idea is useful, it is not exactly accurate. It has been shown that concussions can occur (or not occur) at a wide range of forces (Markham et al 2016). Also, the force necessary to cause a concussion varies depending on the individual’s anatomy, as well as the position and direction of the blow to the head (Guskiewicz et al, 2011).

The idea of the “concussion threshold” is an elusive concept. Many sports organizations have attempted to measure the forces associated with concussive impacts to their players. According to Davenport et al, concussion thresholds have been identified from 50 g’s to 200 g’s, with sub concussive impacts occurring as low as 40 g’s. To set conservative limits for concussion detection within our helmet system we allowed for a lower sub-concussive threshold of 40 g’s and a high-level concussion limit of 90 g’s.

As mental health decline and concussions continue to be linked to contact sports, several institutions have been collecting data about what minimum force is required to cause a concussion. These studies, namely Markham and Guskiewic, will be used to set conservative thresholds for concussion detection related to our prototype helmet which

Copyright © 2018 Rochester Institute of Technology

Page 2

will have the functionality to alert coaches and trainers if the minimum concussion threshold has been exceeded so that they may further evaluate players.

BenchmarkingSimilar DevicesSome similar devices currently exist either as an entire helmet system or a sensor that can be attached to a helmet. Riddell InSite is the closest comparable device. Released in 2014 the device flashed after impact level hits. Today the system has an alert monitor and player management system to alert personnel on the sidelines. The device sells for $240. Other devices are a sensor that can be attached to any helmet and usually run through a web application (Riddell.com).

MechanicalMounting of the sensor can significantly affect readings. Other devices mounted their sensors in various locations, such as the helmet shell, on top of the head, or on the chin strap. The accelerometer we are using on our device is a sensitive to small vibrations and is used for mining equipment. It works best if directly attached to what it is reading, so we had to attach it to the helmet itself to get the most accurate readings. We experimented to find the best method of helmet attachment, as the attachment used in the sensor’s original purpose could not be used inside the helmet. We found that mounting the board with screws and epoxy at the crown of the helmet gave the most consistent results. Our experiments are detailed in Testing.

SoftwareThe software portion of the project has several nodes that are connected together to transfer data between each other. These nodes are as follows: the accelerometer in the helmet, a collector unit, a Raspberry Pi, a database, and a user interface. The sensor would send information to the collector over a subset of the 2.4GHz Zigbee Protocol, which would transfer the data to a Raspberry Pi Via an ethernet connection, which would then push the information to a database, which would then be pulled by the user interface when needed. A nice flow of data can be seen below in Figure 1.

The sensor and collector were based off the Guardrail technology materials, although modifications to the sensor and power configurations were made. The sensor Code was changed so that it will only transmit data when the sensor reads a GForce that is greater than 20 G’s. Transmitting data is the most power-hungry operation. Lowering the number of times, the sensor sends data results in an increase in battery life of the system. Additionally, the sensor keeps track of how long it has been since the last data packet was sent. If the sensor has not sent a data packet in 90 seconds, it will send a heartbeat message so that the system knows that the sensor is still active. If the system does not receive a message from a sensor every 2 minutes, it will flag the user that the sensor is inactive.

The database chosen for use was an Amazon MySQL database. This choice allowed easy connectivity to both the raspberry pi as well as the end web users, additionally the hardware running the server is managed by amazon and

Project P18071

Figure 1: Data Flow

Page 3

rarely has any downtime. The database was constructed and for a fee could have its storage amount increased if the need ever arose. This database would have numerous stored procedures that would be used within the web application

Finally, the user interface was designed using an ASPX web application. This was chosen as it could be used either on a laptop device or a mobile one and had various helpful functions for the implementation that was required. The web application was designed to work for three different types of users: A player, a coach, and an observer. A player would be able to register a single sensor ID, track the player’s impact data, as well as flag the player when the sensor detects a concussive force. A coach would be able to create teams, in which they could add numerous players to and perform the same tracking methods for the numerous players. Finally, an observer was designed to work for users such as a parent. They would be able to view both player and team data but would not have the admin privileges of editing teams. All the data would be transferred to and from the database. Users will be able to see the most recent impact that a player feels as well as a historical view showing all impacts over any specified time. This view can be used to determine if a player has received multiple sub concussive impacts.

ElectricalThe minimum battery life goal for the controller board and sensor was to be able to last an entire day on one charge. The ideal battery life goal was to be able to last an entire season on one charge. Given this, the power source would need to be high in capacity and rechargeable for ease of use and longevity. The source would also need to be lightweight to not cause any discomfort when the helmet is being worn, and small enough to be fitted inside without contacting the athlete’s head.

To address the bulk of these concerns at once, Li-Polymer batteries were chosen for the power source. Being rechargeable, small and lightweight, these batteries offered the flexibility needed for implementing a non-intrusive power source into a helmet. To balance battery size and capacity to meet the remaining requirements regarding the operation time, three batteries with a capacity of 1200mAh were chosen and connected in parallel to create a 3600mAh battery pack.

To accommodate for the use of rechargeable batteries, a printed circuit board (PCB) needed to be built to allow the batteries to charge from an easily accessible source and route power to the controller. This board would also need to step down the voltage to 3.6V as this was the maximum value that the controller could receive. To satisfy both needs, the two ICs were chosen shown below in Table 1 in the appendix, along with their functionalities.

Design RequirementsThe design requirements for the system are aimed around making the helmet feel as close to the original helmet and to make the user experience as seamless as possible. To make the helmet wearable, all the electrical components must be placed inside the helmet and be balanced to keep the center of weight in the same location. The components also need to be able to survive an impact of 150 G’s so that they are not damaged by extreme impacts.

The software that the users interact with needs to be user-friendly so that they can focus on the data they are viewing instead of how to use the application. In addition, the application needs to be able to update the impact that a player feels in under 5 seconds. This allows for coaches and parents to know immediately when a serious impact has occurred to start treatment on the player. The system should also be able to store 2 years of impact data for every player so that medical teams can look back and see if there were additional concussions that the player may have received. Pulling the historical data should also not take more than 15 seconds to enhance the user experience. To enhance the user experience more, the battery powering the sensor inside of the helmet should have a 30 day to four month battery life.

Project P18071

Page 4

This allows the users to not have to constantly work with the sensors inside the helmet so the system is more of a set and forget type of system that just runs in the background. Apart from the accelerometer, collection board, and helmet, the system should be as low cost as possible, preferably not exceeding $20 per unit to allow for lower pricing to compete in the market.

MethodologyThe system has a battery life of 200 to 300 hours, which approximates to 10 to 15 weeks if the user follows NCAA guidelines of a maximum of 20 hours per week of athletically related activities for a student. The batteries can be recharged using any micro-USB charger and will reach their full charge after 8 – 10 hours.

The database tables were created with a priority on performance and minimal data redundancy. After the stored procedures were created, the table structure was evaluated again to create indexes. Indexes allow for faster retrieval time at a cost of slower insertion time. Adding indexes allowed for the retrieval times of single impacts to be less than one second and retrieval time of historical data to be less than 10 seconds.

The Raspberry pi application that is responsible for pushing the data from the collector to the database was designed with robustness in mind. The application was designed to never lose a data packet that needs to be communicated to the Database. The application utilized threads to allow for processing of multiple data packets at one time additionally the application has a local database on the raspberry pi where data is temporarily stored if there is a connection issue to the Amazon DB. Once connection is restored to the Amazon DB, the local Database then takes all of the data and pushes it to the Amazon DB.

The sensor application was designed with battery life in mind. The transmitting operation of the sensor draws the most current from the batteries so the goal was to reduce the amount of times the sensor transmits data without missing important information. This was done by setting a threshold of 20G’s, whenever the sensor reads a G higher than 20 it will transmit data. Since the sensor is transmitting a little as possible and it is possible that the sensor will not reach the 20G threshold during the entirety of a game, there needed to be another method set up to tell if the sensor was still active. This was done by setting up a heartbeat message that will be sent every 90 seconds. This message does not update any G forces felt, it simply send to ensure the system that the sensor is still active. If the system does not receive a message from a sensor in 2 minutes (120 seconds) it will notify the user.

TestingMechanicalThe system was tested using a drop test rig where the helmet was dropped from 5.4cm to 62cm with an accelerometer with limit of 50Gs for initial testing. This height was determined based on the material available with the ability to increase height if the physical sensor limit could not be reached within 62cm. Test plans and rig design were based on ASTM helmet tests and ASTM requirements for a hockey helmet. Tests were done to ensure product survivability from repeated high-level impacts and to test the consistency of the device. Accelerometers were placed in the three potential locations: the crown, the forehead, and the left ear.

Impact TestThe test rig had a minimum drop height of 5.4 cm and a maximum of 62 cm. The device will be dropped via a quick release to avoid a

Project P18071

Page 5

difference in the operator’s release. A string with a ratcheting system was used to raise and lower the mounting platform. A mount for a laser was directly attached to the platform allowing the laser to indicate height on measuring tape affixed to a vertical support. Guide rails were made of cable and tensioners were used to keep them in a state of constant tension. PVC pipes were attached to the platform to guide it down along the cables. The head rested directly in a cake pan with the bottom removed. This design allowed for easy mounting and angle adjustment and allowed the helmet to freely move after impact with the goal of more closely simulating a hit. The helmet struck against three hockey pucks vertically mounted to provide a raised area for the helmet to strike above the metal plate. This ensured the helmet would impact before the platform, allowing free movement.

Ability to Survive ImpactThe forehead mounted accelerometer failed to pass survivability as it broke off early on in testing. The ear and crown mounting locations continued to hold their mount throughout testing. Accelerometers that were mounting with four additional screws to secure them held up better than the others. From this the optimal mounting method was a combination of fast acting epoxy and four small screws. For the final product, smaller screws are recommended as to not exceed outer helmet dimensions.

The controller board was initially dropped without the protective casing, only a portion of the device was covered by the foam in the helmet. This was fine when the helmet was dropped without a head form, but the compression between the head form and device, coupled with the repeated number of drops, deteriorated the device until a pin was bent causing an electrical short in the controller board and potentially the battery board.

Mounting LocationThe system was dropped from various heights to record impact data as the impact force increased. The ear mounted and crown mounted accelerometers were tested while the forehead mounted accelerometer was not. This last one failed its survivability test before it could be tested, detaching from the helmet while the Crown mounted board was being tested. Both remaining accelerometers were dropped directly on the crown and right side. Additional graphs and data can be found in the appendix.

Project P18071

5 10 15 20 25 30 35 40 45 50 5505

101520253035404550

Physical Sensor Limit

f(x) = 0.322886634435609 x + 30.4300354653202R² = 0.868180322465671

Accelerometer: Crown| Impact: Crown

Drop Distance (cm)

Impa

ct (g

)

0 10 20 30 40 50 6005

1015202530354045

f(x) = 0.306233176289196 x + 27.0063189606148R² = 0.923926176198369

Accelerometer: Crown| Impact: Right Ear

Drop Distance (cm)

Impa

ct (g

)

Figure 3: Impact testing data provided a steady upward curve with increased drop height. For these reasons, this configuration was chosen for our helmet. This is specifically for the final accelerometer placed on the crown and mounted using screws and epoxy

Page 6

SoftwareThe software portion of this project encompassed all the interconnection of components for the project, from the sensor within the helmet, all the way to the user interface to display the information. This section was broken up into three major portions each with their own tests: Database testing, Web application testing, and raspberry pi testing.

Web ApplicationMost of the testing for the web application that was performed was testing functionality and timing of the web application when the database was loaded with information. Example users were created for each user type (Player, Coach, Observer) and dummy information was added to them to simulate a real-world scenario. The other type of testing to be done was to ensure the tables of information was being updated properly and signaling a concussive force.

DatabaseFor testing the database functionality, stress tests for reading and writing were performed. To maximize test verification, the database was first loaded with around 300 data points of history for the first 200 sensors. Two Python scripts were then created for read testing. The first script would run a varying number of threads which would request every entry from a sensor, with the sole purpose of putting a load on the database. The second script would request all the history data from a separate sensor and return the time it took to obtain the data.

Project P18071

Figure 4: Player Home page from web app

Figure 5:Database stress test for read times

Page 7

Write testing for the database would work in a similar fashion. The same history points for the first 200 sensors were used, and the same python script to put a load on the database was used. The difference for the write testing is that now the second script would be writing data to sensor 101 with random data, and timing results were taken.

The tests show that while an increase in users did increase the read and write times of the database, it was not by a large margin and was still well below the customer and engineering requirements. These stress tests were also done on the lowest hardware configuration that amazon’s Relational Database service has to offer. This hardware configuration is 1 CPU core, 1GB of Ram and 5GB of storage. The tests that were run had to stop at 50 simulated users because there is a limitation to how many users can be logged into a SQL server based on the number of CPU Cores. for 1 Core that would be 62 users which made it, so the test could not be executed past 50. If the hardware is upgraded to 4 cores, then SQL will be able to handle 512 users.

Raspberry PiThe Raspberry Pi was to be connected via Ethernet for this project, so its capabilities and potential for failure via Ethernet was to be tested. To complete these tests, a Python script was written that would send UDP packets to the Pi while it is also receiving packets from the collector. The database would then keep track of the packets received from the collector to determine the number of packets lost due to high usage with the Pi. The stress was gradually increased on the Pi’s Ethernet adapter. Each thread running simulated an average of 5 players on the field worth of data. After 10 threads were started, a second computer was used to transmit data over UDP to the raspberry pi to ensure that the testing PC’s ethernet driver was not being over worked. The test results can be found in the appendix.

From the tests, the amount of stress did not lead to any dropped packets from the Pi. This is primarily due to how the Ethernet interface is configured on the Raspberry Pi. The information is designed to be stored until the device it is sending to is ready to receive.

ElectricalBattery testing was done by measuring the current used by both the power management board and controller board. It was then compared to the characteristics of the battery drainage rate from 4.15V to 2.8V when drawing 100mA using a set of LEDs. Knowing the time, it takes to drain the battery using 100mA, the time it would take when using far less amps could be calculated.

DischargingTo create a testing set-up that would yield consistent and repeatable results, a set of LEDs were used as shown in Figure 11. This allowed the amp rate of the draining to be set by increasing or decreasing the number of LEDs and measuring their current draw with an ammeter to find a desirable rate. For this test, the set-up, shown in the appendix was configured to pull 100mA from the battery.

During the draining process, data points were created to measure the battery voltage every 30 minutes starting at 4.25V and up to when the voltage fell below 2.75V as shown in Figure 12. From this, the life time of the battery at 100mAh was estimated to be around 15 hours.

Project P18071

Figure 6:Database Stress Test for Write Times

Figure 7: Battery Discharge Test Results

Page 8

ConclusionsResultsSensor ReliabilityThe sensor is reliable and consistent within 5 G’s as demonstrated by the repeated impact test when the accelerometer was mounted with a combination of screws and epoxy on the inner crown of the helmet. When dropped directly on the crown the average standard deviation was 2.39 G’s with a minimum of 1.496 G’s and a maximum of 3.12 G’s as shown in Fig. 4. Impacts to the right ear had a higher standard deviation average of 2.938 G’s with a minimum of 1.156 G’s and a maximum of 4.93 G’s as shown in Fig. 5.

Database CapabilityThe Amazon database that is being used currently only has 1 CPU core and was able to handle extreme loads up to the maximum number of users that its current configuration will allow. Even under these worst-case conditions, the database was able to handle reading from the tables in under half a second, as well as writing to a table in 0.1 seconds.

Raspberry Pi CapabilityThe Raspberry pi application was proven to be very robust to the point where using two desktop computers sending as many packets as possible on 10 threads was not able to cause it to lose/drop a packet. Additionally, the applications ability to buffer data up to 8 GB of data makes it so the application is extremely robust and losing DB connectivity does not stop the storage of data.

Maximum Impact CapabilityThe accelerometer had no issues with repeated impacts when attached via epoxy. The maximum known drop acceleration was 50G’s. The sensor was dropped above the physical sensor limit several times and still had no negative reactions. The initial controller board was damaged in a drop test after the head form was added to the testing procedures. The solution was to 3D print a casing for the controller board and battery charge board to prevent future incidents. No further damage has been discovered. The charge board was covered in epoxy in a 3D printed case to prevent any possible movement of the electronics to avoid the chance of frying the board.

Mounting Locations and MethodsThe accelerometer was attached to the shell of the helmet using four screws and epoxy. As shown in the testing section this combination method, along with the crown placement, resulted in the best calculated results and ability to survive impact. The cases for the charge board and control board are attached the helmet with Velcro to allow for easy removal if either board is damaged. The batteries were attached with a simple glue, but Velcro could be used for future iterations.

Battery Life EstimationKnowing the current draw from power management board and the controller board, the minimum operating duration could be calculated, which is shown in Table 2. This would be assuming the device is running full time with the controller constantly transmitting.

Calculated Current Draw (mA)

Project P18071

0:001:00

2:003:00

4:005:00

6:007:00

8:009:00

10:0011:00

12:0013:00

14:002.602.803.003.203.403.603.804.004.20

Battery Discharging: Voltage vs. Time

Voltage (V)Time (hr)

Volta

ge (V

)

Page 9

Controller Power Management Board

Total Current

5.5 2.8 8.3Table 2: Calculated Current Draw

Based on this calculation and the estimated battery life with a current draw of 100mA, the minimum run time was calculated to be 180 hours. This was done by taking the ratio of the 100mA and the total calculated current draw to determine how much longer the device could run on a lower current, as shown in Eq. 1 in the appendix, then multiplying it by the estimated run time from the 100mA to get the minimum run time as done in Eq. 2.

Given that this is the duration under the assumption that the device is constantly transmitting, the practical operating duration can reach up to 300 to 500 hours.

Future HopesMechanicalA more versatile mounting method for the accelerometer would be preferable. The current attachment methods allow for no movement as it is attached with epoxy, allowing the accelerometer to feel a majority of the force the helmet feels. The downside of this method is that the accelerometers cannot be replaced if there is a quality error or malfunction after placement of the device.

More testing of the helmet to get a proper statistical analysis of the standard deviation which would require at least 30 test points for every height drop. The final 200 G accelerometer was not added to the prototype because the formulations and code required to implement the device could not be derived in the time required. Future iterations should use the final accelerometer. Additional simulation and uncertainty analysis would be useful for any future designs, iterations, and tests.

SoftwareSince there are always things that could be improved on, a more elegant layout with customized CSS for the web application would have been ideal, as well as simple pop ups being implemented for smaller screens such as adding a player or editing a team.

ElectricalThere is a lot that could have been changed and improved on with the electrical subsystem for this project. The board could have been made smaller and several improvements to the design could have been made given the issues encountered that required extensive trouble shooting early on. Having the chance to redesign the board to account for such issues would have lowered the overall current draw of the system, giving the device a much longer operating time.

Project P18071

Page 10

AppendixReferences: (Update format by Tuesday)Source: http://www.radiocontrolinfo.com/lipochargers/lipo-batteries/

Additional Graphs and Tables:

0 10 20 30 40 50 600

10

20

30

40

50

60

Ear With Screws | Crown

Drop Distance (cm)

Impa

ct (g

)

Figure 6: Ear Accelerometer with Screws. This configuration quickly maxed out our accelerometer, even at low heights. The most likely cause of this is the flexibility of the ear cover of the helmet allowing vibrations, which would increase the impact readings. We determined that the ear was not a

good mounting location because of this.

Figure 81: Battery Drainage Set-Up

Project P18071

Page 11

100 mA8.3mA

=12 , the device runs 12 times longer on 8.3mA (1)

12×15 hours=180 hours, the minimum run time (2)

IC Part Number BQ24025 TPS74701

Manufacturer Texas Instruments

FunctionAllows charging at a

rate of 500mAh from a micro-usb source.

Caps the output voltage from the

board at 3.6VTable 1: IC Part Descriptions

Project P18071

Figure 9: Raspberry Pi Ethernet Test