Difference between revisions of "Headband Helper"

From ESE205 Wiki
Jump to navigation Jump to search
Line 56: Line 56:
 
=== Module 2: Filtering the Data ===
 
=== Module 2: Filtering the Data ===
 
Module 2 of our project involves filtering the data being read by the RPi0.  
 
Module 2 of our project involves filtering the data being read by the RPi0.  
To do so, we first conducted testing to examine what collision data looks like compared to noise and other potential accelerations read by the RPi0. We performed three different rounds of tests: one measuring the acceleration generated when Jarrod performed athletic movements (running, cutting, changes of direction, etc.), one measuring the acceleration generated from dropping the helmet from approximately 1.5 meters off the ground, and one measuring the acceleration generated from hitting the helmet with a hammer (to mimic an impulse). Below are our results from these tests:
+
To do so, we first conducted testing to examine what collision data looks like compared to noise and other potential accelerations read by the RPi0. We performed three different rounds of tests: one measuring the acceleration generated when Jarrod performed athletic movements (running, cutting, changes of direction, etc.), one measuring the acceleration generated from dropping the helmet from approximately 1.5 meters off the ground, and one measuring the acceleration generated from hitting the helmet with a hammer (to mimic an impulse). Below are our results from these tests (each value is measured in G's):
 
*Run/change direction:
 
*Run/change direction:
 
**15, 18, 17, 14, 15
 
**15, 18, 17, 14, 15

Revision as of 01:33, 28 April 2019

Links

Headband_Helper_Log

Presentation [1]

GitHub Repository [2]

Accelerometer code [3]

Final Poster [4]

Accelerometer Tutorial [5]

Project Proposal

Overview

We hope to construct an accelerometer-based concussion monitoring system using a Raspberry Pi OW that can be contained within a headband. In addition, we will create a web interface that allows users to track their impact history. These two pieces (software and hardware) will communicate using an ad hoc IP network run by another Raspberry Pi.

Team Members

  • Jarrod Huther
  • Katy Mockett
  • TA: Ethan Shry
  • Professor: James Feher

Objectives

  • Create an accelerometer-based concussion monitoring system that can be contained within a headband
  • Create an ad hoc IP network using a master Raspberry Pi to collect data from the headbands
  • Ensure that the master Pi and web interface can successfully communicate so the web interface can display collected data about collisions

Challenges

  • We both have limited experience with circuitry
  • We both are comfortable working in Java but have never really used any languages beyond Java
  • No experience with sensor networks; creating a fully debugged network will be difficult

Budget

  • 2 accelerometers ($11.95 each, $23.90 total)[6]
    • Shipping (~$8.00)
  • 1 Amp battery & charger (provided- free)
  • Raspberry Pi 0W- headband (provided- free)
  • Raspberry Pi- master (provided- free)
  • 3D box to contain tracking materials within headband (free)

Total Budget: $31.90

Gantt Chart

Gantt Chart

Design and Solutions

We set out to create our concussion monitoring system by dividing the process into a few different modules. The following are the modules we created, organized by relatedness of the task.

Module 1: Wiring Accelerometer to Pi 0

Module 1 of our project involves wiring the H3LIS331DL accelerometer to the Raspberry Pi 0, as well as implementing the code in python that executes the readings. This specific accelerometer is 3-axis, meaning it records data in the x, y, and z-planes, and can take readings up to +-400g's. We chose this board specifically because concussions occur at approximately 95g's, so we needed a sensor that was capable of sensing events of this magnitude and beyond. Once the sensor was wired to the pi, we had to code the pi to use the sensor, as well as transmit the data to the master pi, in order to read the data on another interface. We begin by following the tutorial linked above (which we created for the purposes of this project). The completed system is shown below.

  • Pi with acc.jpeg
  • Once the system was functioning properly, we used OnShape to design a case that could contain the pi, acceleromter, and power supply, to give it some protection from the more physical impacts it will likely record.
  • PiCase.jpeg
  • Once the pi case was created and the system was placed inside, we could then fit it to either a football helmet or headband, depending on the sport.

Module 2: Filtering the Data

Module 2 of our project involves filtering the data being read by the RPi0. To do so, we first conducted testing to examine what collision data looks like compared to noise and other potential accelerations read by the RPi0. We performed three different rounds of tests: one measuring the acceleration generated when Jarrod performed athletic movements (running, cutting, changes of direction, etc.), one measuring the acceleration generated from dropping the helmet from approximately 1.5 meters off the ground, and one measuring the acceleration generated from hitting the helmet with a hammer (to mimic an impulse). Below are our results from these tests (each value is measured in G's):

  • Run/change direction:
    • 15, 18, 17, 14, 15
    • 12, 36, 40, 25, 26, 11, 5
  • Drop
    • 14, 6, 16, 20
    • 3, 17, 20, 7
  • Hit with hammer
    • 3, 3, 114, 14, 4
    • 2, 2, 2, 148, 46, 22, 9 (helmet rolled away after hit)

From our testing results, we determined athletic movements generate accelerations far below the threshold for concussions, with the max value being 40G's, while dropping the helmet (with no additional mass) creates even smaller accelerations. However, hitting the empty (small mass) helmet with a hammer generated large spikes in the data which imitated an impulse function. We do not want to allow these low-G accelerations and impulses to register as collisions in our database, and we also wanted to ensure that each collision we reported was generated from a unique hit. As such, we determined that we should include three simple filtering functions: a peak detection algorithm, a minimum threshold for the peak point in the hit, and a minimum threshold for the average of the peak and the two adjacent data points on either side of the collision. We decided to use a peak detection algorithm to ensure each hit recorded in the database represented a unique collision rather than sending two (or more) hit events from the same collision. We included the minimum threshold for the peak point in the hit, which we set to 40G's, to avoid overcrowding the database with meaningless data, while we included the minimum threshold for the average to ensure the hit being recorded is not just noise/error read as impulses from the accelerometer.

To implement the simple peak detection algorithm, we created a simple algorithm that follows the logic the pseudocode below:

if(point > 40 && previouslyOverThreshold = false):
   previousOverThreshold = true
   belowFor = 0
if(point < 40 && previouslyOverThreshold = true):
   belowFor += 1
   if (belowFor = 2):
      previouslyOverThreshold = false
      belowFor = 0
      checkThresholds()

Then, if checkThresholds() is called, we calculate the average of the two adjacent data points on either side of the collision (five points total). If the average is greater than 30G's and the maximum is greater than 40G's, these values are sent to the RPi3 via the ad hoc IP network (described in Module 3).

Module 3: Building a Communication Network And Storing Data

Module 3 of our project involves building a communication network to allow the data to be transmitted from the RPi0 to the RPi3 and from the RPi3 to the MySQL database. To transmit data between the RPi0 and the RPi3, we configured an ad hoc IP network on the RPi3 following a tutorial we found online, linked here [7]. We then sent collision data from the RPi0 to the RPi3 using HTTP POST requests in the accelerometer code. These POST requests are processed by the RPi3 and the data is then inputted into the database using the following SQL Insert query:

async function sendToMySql(playerID, timestamp, avg, max) {
	let qString = 'INSERT INTO hits (player_id, marked_bad, timestamp, avg_force, max_force) values (?, false, ?, ?, ?)';
	await query(qString, [playerID, timestamp, avg, max]);
};

From here, the data is now stored in the database and ready to be accessed when users interacting with the web interface request it. The database features three tables: one that stores hit/collision data, one that stores player data, and one that stores team data. The following image outlines the database schema:

  • Database schema 2.JPG

Module 4: Displaying the Data

  • Once data is in the server, read results and draw conclusions. Will do this by testing the system in an experimental setting (lab first, then likely move to field to see how it responds in a practical application). Once data is collected and properly displayed on webpage, we can begin discussion on what certain outputs read, and what constitutes an "event" (possible concussion).

Hhmainpage.PNG Hhteampage.PNG Hhplayerpage.PNG

Results

  • Present all your results, including modules that only partially worked.
  • Discuss how the results compare to your original objectives.
  • Identify the critical decisions or factors in your project that stopped you from getting a better result (try to avoid obvious comments such as "we run out of time").
  • If the project had any ethical, privacy or safety issues related to it, discuss how you addressed them.
  • Include on the main wiki an image of the final project or short video of the working project.

Next Steps

  • Miniaturization: Further development would allow us to miniaturize the system for easier implementation in headbands, helmets, and potentially other carriers.
  • Multiple-Team Functionality: Design each accelerometer system to transmit unique ID to server to distinguish between players; Expanding off of this, potentially different servers/unique key requirements that allow for multiple teams to use the same system at once.
  • Security: Relating to Multi-Team Functionality, design credential-based login to prevent other teams from accessing information, for many different reasons. Primarily privacy, as technically this is medical data and should be restricted to the same securities provided to information such as physicals. Additionally, should have a way of preventing editing of information, to prevent unethical practices such as erasing positive concussion readings.
  • Refined Interface: Spend time improving aesthetic of displayed information, not only for obvious reason of looking nicer, but also to be more user-friendly and navigable.