Hello,
My son is working on a Grade 8 Science Fair project involving drop tests on various surfaces. He is trying to find the ones that will be best to prevent injury to falling children. To do this, he has built an arduino with an accelerometer and an onboard sd card. He is also accessing the linear accelerometer on his phone through Google Science Journal. After some practice drops, we are a bit confused.
When using the linear accelerometer on his phone, a drop on a soft pillow is giving a reading of approximately 50m/s^2 while the hard surface he gets a result of approximately 30m/s^2. This seems counterintuitive to us... We are not physicists...
Why does the soft surface seem to have a faster speed? We think it should slow down the phone at a slower rate...
Please ELI5. Please help!
Accelerometer Drop Test Data
Moderators: AmyCowen, kgudger, bfinio, MadelineB, Moderators
-
deleted-828182
- Posts: 5
- Joined: Mon Feb 03, 2020 12:59 pm
- Occupation: Parent
-
bfinio
- Expert
- Posts: 964
- Joined: Mon Aug 12, 2013 2:41 pm
- Occupation: Lead Staff Scientist, Science Buddies
- Project Question: Expert
- Project Due Date: n/a
- Project Status: Not applicable
Re: Accelerometer Drop Test Data
Hi augustusr,
I'm an author here at Science Buddies and I wrote most of our Science Journal projects that use the accelerometer. Your intuition that you would expect a higher acceleration with the hard surface is correct, so don't worry. I believe the problem you're running into is related to Science Journal's sampling rate, or how many times per second it collects data. Science Journal collects data fairly slowly - about 15 times per second*. This is not fast enough to accurately capture fast collisions. In other words, the phone is probably experiencing a higher acceleration when it hits the hard surface - but this peak happens very quickly, and Science Journal misses collecting that data point.
To the best of our knowledge, Google put in this limitation intentionally and there's no way to get around it manually (i.e. there's no setting to increase the sampling rate). However, there are many other apps available that will let you access the accelerometer data from your phone - just search for "accelerometer" in your app store (although we can't vouch for any of them specifically, since we've only written projects for Science Journal). Your son could try a few other apps to see if he gets better results. Based on your post I'm assuming he doesn't have data from the Arduino yet, but you can also test with that to see if the results are more in line with what you'd expect.
Ultimately, please make sure your son knows this shouldn't be considered a "failure" - it's actually a great real-world lesson about the limitations of scientific equipment! Please write back if you have more questions.
-Ben
* Side note on physics and units - the number of times bleep happens per second is measured in hertz, abbreviated Hz. So you might hear or read about a sensor that has "a frequency of 100 Hz" or a "sampling rate of 1,000 Hz" etc. In this case we would say Science Journal only samples at about 15 Hz.
I'm an author here at Science Buddies and I wrote most of our Science Journal projects that use the accelerometer. Your intuition that you would expect a higher acceleration with the hard surface is correct, so don't worry. I believe the problem you're running into is related to Science Journal's sampling rate, or how many times per second it collects data. Science Journal collects data fairly slowly - about 15 times per second*. This is not fast enough to accurately capture fast collisions. In other words, the phone is probably experiencing a higher acceleration when it hits the hard surface - but this peak happens very quickly, and Science Journal misses collecting that data point.
To the best of our knowledge, Google put in this limitation intentionally and there's no way to get around it manually (i.e. there's no setting to increase the sampling rate). However, there are many other apps available that will let you access the accelerometer data from your phone - just search for "accelerometer" in your app store (although we can't vouch for any of them specifically, since we've only written projects for Science Journal). Your son could try a few other apps to see if he gets better results. Based on your post I'm assuming he doesn't have data from the Arduino yet, but you can also test with that to see if the results are more in line with what you'd expect.
Ultimately, please make sure your son knows this shouldn't be considered a "failure" - it's actually a great real-world lesson about the limitations of scientific equipment! Please write back if you have more questions.
-Ben
* Side note on physics and units - the number of times bleep happens per second is measured in hertz, abbreviated Hz. So you might hear or read about a sensor that has "a frequency of 100 Hz" or a "sampling rate of 1,000 Hz" etc. In this case we would say Science Journal only samples at about 15 Hz.
-
deleted-828182
- Posts: 5
- Joined: Mon Feb 03, 2020 12:59 pm
- Occupation: Parent
Re: Accelerometer Drop Test Data
Hello Ben,
Thanks so much for the detailed response. We are making progress slowly here.
I just downloaded a new accelerometer with a sample rate of 419Hz. It also has a total G-force meter. This may be useful. We have also run trials with the arduino and collected the Y values. Lots of data....!
We are graphing it all with excel and hope to draw some conclusions
Rivht now we are thinking in terms of shock absorption for each surface: mulch, pebble rock, sand, rubber mulch, tapeta, and wood chips.
Hopefully things will become clear.
Thanks again!
Thanks so much for the detailed response. We are making progress slowly here.
I just downloaded a new accelerometer with a sample rate of 419Hz. It also has a total G-force meter. This may be useful. We have also run trials with the arduino and collected the Y values. Lots of data....!
We are graphing it all with excel and hope to draw some conclusions
Rivht now we are thinking in terms of shock absorption for each surface: mulch, pebble rock, sand, rubber mulch, tapeta, and wood chips.
Hopefully things will become clear.
Thanks again!
-
bfinio
- Expert
- Posts: 964
- Joined: Mon Aug 12, 2013 2:41 pm
- Occupation: Lead Staff Scientist, Science Buddies
- Project Question: Expert
- Project Due Date: n/a
- Project Status: Not applicable
Re: Accelerometer Drop Test Data
Hi augustusr,
Great! Glad you're making progress. A few more warnings about using accelerometers now that I think about it:
- Since you mentioned the y axis - be careful with the x, y, and z axes. Those directions are defined relative to the accelerometer - so depending on which way the phone or Arduino is oriented, they don't necessarily correspond to "up" in the physical world. For example, with Science Journal, the y axis is "up and down" relative to the phone's screen, so if you're holding the phone with the screen vertical then y is "up," but if the phone is sitting flat on a table then y is "sideways." So, if you are pretty sure that the orientation of the phone/Arduino is staying constant when you drop it (it doesn't tumble or spin at all), this can be OK. But if you're not sure what angle the phone lands at, then you can't just use the y value.
- This is one of the nice things about Science Journal - it has the "linear accelerometer" measurement which combines the X, Y, and Z readings to get the total acceleration. That lets you measure the peak value on impact no matter what angle the phone hits the floor at - but as we discussed, Science Journal's sampling rate isn't good enough for this experiment. I'm not sure if other apps offer this feature.
- Another thing you have to be careful about is whether or not the readings include gravity. Not sure if you've noticed that if you put a phone flat on the table and open the Z accelerometer in Science Journal, the reading isn't zero - it's about 9.8. If you hold the phone vertically it will read 9.8 in the y direction etc. That's true for the individual x, y, and z accelerometers, but the linear accelerometer subtracts out the gravity value. We have a much more detailed explanation about this here: https://www.sciencebuddies.org/science- ... elerometer, but the point is that when you are finding peak acceleration during impact, you DON'T want to include gravity. For example - say you can drop the phone vertically and take good measurements in the Y direction with Science Journal - if you measure a peak acceleration of 30 m/s^2 on impact, the actual linear acceleration is only 20.2 m/s^2 because you have to subtract out gravity. So again, you'll have to be careful when using other apps - you can do a quick check by seeing whether any of the axes read 9.8 instead of 0 when the phone is holding still.
Please keep us posted and let us know how the experiment goes!
Ben
Great! Glad you're making progress. A few more warnings about using accelerometers now that I think about it:
- Since you mentioned the y axis - be careful with the x, y, and z axes. Those directions are defined relative to the accelerometer - so depending on which way the phone or Arduino is oriented, they don't necessarily correspond to "up" in the physical world. For example, with Science Journal, the y axis is "up and down" relative to the phone's screen, so if you're holding the phone with the screen vertical then y is "up," but if the phone is sitting flat on a table then y is "sideways." So, if you are pretty sure that the orientation of the phone/Arduino is staying constant when you drop it (it doesn't tumble or spin at all), this can be OK. But if you're not sure what angle the phone lands at, then you can't just use the y value.
- This is one of the nice things about Science Journal - it has the "linear accelerometer" measurement which combines the X, Y, and Z readings to get the total acceleration. That lets you measure the peak value on impact no matter what angle the phone hits the floor at - but as we discussed, Science Journal's sampling rate isn't good enough for this experiment. I'm not sure if other apps offer this feature.
- Another thing you have to be careful about is whether or not the readings include gravity. Not sure if you've noticed that if you put a phone flat on the table and open the Z accelerometer in Science Journal, the reading isn't zero - it's about 9.8. If you hold the phone vertically it will read 9.8 in the y direction etc. That's true for the individual x, y, and z accelerometers, but the linear accelerometer subtracts out the gravity value. We have a much more detailed explanation about this here: https://www.sciencebuddies.org/science- ... elerometer, but the point is that when you are finding peak acceleration during impact, you DON'T want to include gravity. For example - say you can drop the phone vertically and take good measurements in the Y direction with Science Journal - if you measure a peak acceleration of 30 m/s^2 on impact, the actual linear acceleration is only 20.2 m/s^2 because you have to subtract out gravity. So again, you'll have to be careful when using other apps - you can do a quick check by seeing whether any of the axes read 9.8 instead of 0 when the phone is holding still.
Please keep us posted and let us know how the experiment goes!
Ben
-
deleted-828182
- Posts: 5
- Joined: Mon Feb 03, 2020 12:59 pm
- Occupation: Parent
Re: Accelerometer Drop Test Data
Hello Ben,
We were able to sort and graph the data we gathered. The arduino data was a bit unreliable as it tracked all the movements once the battery was attached. I tried to clean up as much noise as possible, but we decided to focus on the phone data. The arduino seemed to have a max limit of approximately +/- 31 000. This number came up over and over.
The cell phone drops were much cleaner and the data seems more true. Again, we cleaned up some of the "between drop" readings.
We are planning to use the 3 trials from the phone to calculate Jerk rate. (We understand this to be acc/time). Would the top of the highest peak to the bottom of the lowest valley be the range of "acceleration"? We are using the reading # as a time value. We are not scientists, so I apologize if this is WAY off!!
Any thoughts would be greatly appreciated.
Thanks again!
We were able to sort and graph the data we gathered. The arduino data was a bit unreliable as it tracked all the movements once the battery was attached. I tried to clean up as much noise as possible, but we decided to focus on the phone data. The arduino seemed to have a max limit of approximately +/- 31 000. This number came up over and over.
The cell phone drops were much cleaner and the data seems more true. Again, we cleaned up some of the "between drop" readings.
We are planning to use the 3 trials from the phone to calculate Jerk rate. (We understand this to be acc/time). Would the top of the highest peak to the bottom of the lowest valley be the range of "acceleration"? We are using the reading # as a time value. We are not scientists, so I apologize if this is WAY off!!
Any thoughts would be greatly appreciated.
Thanks again!
- Attachments
-
[The extension xlsx has been deactivated and can no longer be displayed.]
-
bfinio
- Expert
- Posts: 964
- Joined: Mon Aug 12, 2013 2:41 pm
- Occupation: Lead Staff Scientist, Science Buddies
- Project Question: Expert
- Project Due Date: n/a
- Project Status: Not applicable
Re: Accelerometer Drop Test Data
Hi augustusr,
Don't worry, you're doing well! Taking this one thing at a time:
1. I am not sure what the units are in your Arduino data. They definitely aren't meters per second squared, the typical units for acceleration (for reference gravity is 9.8 m/s^2). I would need to know more about your Arduino code and the accelerometer you're using. If you did want to use the Arduino data you'd need to figure out how to convert those values to meters per second squared.
2. Why do you want to calculate the jerk? You are correct that jerk is change in acceleration per unit time, so you can calculate it by finding the slope of the acceleration graph between any two adjacent points. The maximum jerk will be wherever you can find the steepest slope on the graph. However, jerk is used much less commonly in physics than acceleration (since it's acceleration that appears in Newton's second law, F=ma, and force is generally what determines when bleep - like a phone or phone case - will break), so I'm curious about your motivation for calculating it. Jerk is typically taken into account when humans are involved (e.g. riding in a car: https://en.wikipedia.org/wiki/Jerk_(phy ... perception).
3. One important point - you can NOT use the reading number as a time value if you want to calculate jerk. This is where sampling rate comes in again. For example, if your sampling rate is 100 Hz, then each reading is only 1/100th of a second apart, or 0.01s. So when calculating the slope between two adjacent data points, you would divide by 0.01, not 1. Does that make sense?
4. Did you use Google Science Journal for the phone data, or find another app? When you export data from Science Journal it should normally include a time column, so you don't need to worry about calculating the time based on the sampling rate (the sampling rate in Science Journal actually isn't perfectly constant anyway, it varies a bit, so the time between data points will fluctuate).
5. If you decide not to calculate jerk, and you just want the maximum acceleration values, then that's sort of a moot point because you don't really need the time values.
6. If you change your plots in Excel to scatter plots (right click -> Change chart type -> X Y (Scatter), then select the one that only shows dots with no lines connecting them), you will see what I mean about the sampling rate. Notice how you typically only get 2-3 data points for the "spikes" in the graph. This looks like it's true for both the Arduino and the phone, meaning they aren't really fast enough to accurately capture the peaks. However, if you do enough trials I think you should still be able to make relative comparisons between different surfaces.
Sorry if that's a lot, just trying to be thorough! I think the takeaway is that it will help to clarify what exactly you want to measure/calculate and why, and then we can narrow it down.
Thanks,
Ben
Don't worry, you're doing well! Taking this one thing at a time:
1. I am not sure what the units are in your Arduino data. They definitely aren't meters per second squared, the typical units for acceleration (for reference gravity is 9.8 m/s^2). I would need to know more about your Arduino code and the accelerometer you're using. If you did want to use the Arduino data you'd need to figure out how to convert those values to meters per second squared.
2. Why do you want to calculate the jerk? You are correct that jerk is change in acceleration per unit time, so you can calculate it by finding the slope of the acceleration graph between any two adjacent points. The maximum jerk will be wherever you can find the steepest slope on the graph. However, jerk is used much less commonly in physics than acceleration (since it's acceleration that appears in Newton's second law, F=ma, and force is generally what determines when bleep - like a phone or phone case - will break), so I'm curious about your motivation for calculating it. Jerk is typically taken into account when humans are involved (e.g. riding in a car: https://en.wikipedia.org/wiki/Jerk_(phy ... perception).
3. One important point - you can NOT use the reading number as a time value if you want to calculate jerk. This is where sampling rate comes in again. For example, if your sampling rate is 100 Hz, then each reading is only 1/100th of a second apart, or 0.01s. So when calculating the slope between two adjacent data points, you would divide by 0.01, not 1. Does that make sense?
4. Did you use Google Science Journal for the phone data, or find another app? When you export data from Science Journal it should normally include a time column, so you don't need to worry about calculating the time based on the sampling rate (the sampling rate in Science Journal actually isn't perfectly constant anyway, it varies a bit, so the time between data points will fluctuate).
5. If you decide not to calculate jerk, and you just want the maximum acceleration values, then that's sort of a moot point because you don't really need the time values.
6. If you change your plots in Excel to scatter plots (right click -> Change chart type -> X Y (Scatter), then select the one that only shows dots with no lines connecting them), you will see what I mean about the sampling rate. Notice how you typically only get 2-3 data points for the "spikes" in the graph. This looks like it's true for both the Arduino and the phone, meaning they aren't really fast enough to accurately capture the peaks. However, if you do enough trials I think you should still be able to make relative comparisons between different surfaces.
Sorry if that's a lot, just trying to be thorough! I think the takeaway is that it will help to clarify what exactly you want to measure/calculate and why, and then we can narrow it down.
Thanks,
Ben
-
deleted-828182
- Posts: 5
- Joined: Mon Feb 03, 2020 12:59 pm
- Occupation: Parent
Re: Accelerometer Drop Test Data
Hello Ben,
You are awesome for offering your time to this!
My son chose to do this project because, unfortunately, he had a very bad fall off a play structure last August. He suffered 3 compression fractures to his spinal column. Hence, injury prevention and ideas related to Jerk/jolt are at the forefront of his thinking.
Yes, the phone data does provide the time stamp, in actual and relative I think. I will do some graphing with this set as the x. I will produce line and scatter.
I will will keep you posted.
Thanks!
You are awesome for offering your time to this!
My son chose to do this project because, unfortunately, he had a very bad fall off a play structure last August. He suffered 3 compression fractures to his spinal column. Hence, injury prevention and ideas related to Jerk/jolt are at the forefront of his thinking.
Yes, the phone data does provide the time stamp, in actual and relative I think. I will do some graphing with this set as the x. I will produce line and scatter.
I will will keep you posted.
Thanks!
-
bfinio
- Expert
- Posts: 964
- Joined: Mon Aug 12, 2013 2:41 pm
- Occupation: Lead Staff Scientist, Science Buddies
- Project Question: Expert
- Project Due Date: n/a
- Project Status: Not applicable
Re: Accelerometer Drop Test Data
Hi augustusr,
I'm very sorry to hear that about your son, but that certainly explains the context and provides a good motivation for calculating jerk. You might have to take your results with a grain of salt because of the limited sampling rate, but hopefully it will still allow for a valid comparison between the different surfaces.
Keep me posted and let us know if you have more questions.
Thanks,
Ben
I'm very sorry to hear that about your son, but that certainly explains the context and provides a good motivation for calculating jerk. You might have to take your results with a grain of salt because of the limited sampling rate, but hopefully it will still allow for a valid comparison between the different surfaces.
Keep me posted and let us know if you have more questions.
Thanks,
Ben
-
deleted-828182
- Posts: 5
- Joined: Mon Feb 03, 2020 12:59 pm
- Occupation: Parent
Re: Accelerometer Drop Test Data
Will do Ben!
His recovery is coming along.
His recovery is coming along.

