Project: Inexpensive Rifle Accelerometer

[ammolytics]

Based on the feedback from my previous experiment, I wrote an in-depth article about the accelerometer unit I built. Some folks asked me to share it here on SnipersHide.

https://blog.ammolytics.com/2019-01-01/project-cheap-rifle-accelerometer.html

In this article, I describe how I built it, how it works, and how you can build your own for under $50! This DIY project is open-sourced and it uses off-the-shelf components -- anyone should be able to assemble one within an afternoon. Data analysis was done using Python, Pandas, and Plotly (I'm working on making this software available as a web application -- let me know if you're interested!)

I hope that this content is high quality enough to justify the time you spend reading it, and how much time it took me to create it!
I’d love to hear your feedback and answer any questions!

 

[ClangClang]

I enjoyed the writeup, thank you for sharing. I've half-seriously mulled a project like this, but have very little experience with electronics, so it would be an uphill battle, to say the least.

 

[ammolytics]

I enjoyed the writeup, thank you for sharing. I've half-seriously mulled a project like this, but have very little experience with electronics, so it would be an uphill battle, to say the least.

Thanks for taking the time to read it! I don't have a ton of experience building electronics either, which is why I worked with off-the-shelf components that are more plug-and-play. It really wasn't very hard and I think my instructions should provide enough detail that anyone can put one together fairly easily.

 

[loveha]

Cool project and write up. After you have decided on it's final components, I'm sure you could get a case 3D printed for it that would be fairly water resistant that would be held togther by screws with an O ring seal.

 

[Bayhawk21]

Did you look at the Raspberry Pi Zero as a possible base?

 

[ammolytics]

Did you look at the Raspberry Pi Zero as a possible base?

I did! There were three reasons why I choose the Feather board:

1. It was a bit smaller (2"x0.9"x0.28" VS 2.6"x1.2"x0.2")
2. I already had one on hand
3. There were more stackable wing/shield options that fit my needs at the time

That said, the Pi Zero is a totally feasible platform for this project. If you have one, you could easily make it work with the same sensor!

 

[JMcBurn]

@ammolytics why not use one of the 9dof boards with the built in microcontroller? pretty close to the same refresh rate on the accelerometer but would also export gyroscopic data and has a magnometer built in.

I have very little experience with arduinos (helped a friend's senior design team in college) and currently only coding VB for excel automation. That being said, I have been thinking about taking one of those complete systems to make a mountable digital level.

 

[ammolytics]

@ammolytics why not use one of the 9dof boards with the built in microcontroller? pretty close to the same refresh rate on the accelerometer but would also export gyroscopic data and has a magnometer built in.

I have very little experience with arduinos (helped a friend's senior design team in college) and currently only coding VB for excel automation. That being said, I have been thinking about taking one of those complete systems to make a mountable digital level.

The good news is that there's a HUGE variety of options available these days, making it very easy to solve most problems. The bad news is that it can take quite a bit of research and experimentation to determine which components work best.

I had good results working with the LIS3DH accelerometer that I used in this project, and rather disappointing results when I experimented with one 9-DOF sensor that I tried.

I'm sure more experienced folks than myself could probably make it work, but I didn't let that stop me from getting the data I needed.

I hope that this project provides you with the insight and inspiration you need to build you own! Even if it doesn't work out as well as you hope, I guarantee you'll learn a lot in the process.

 

[ken4570tc in WY]

Eric,
Great work and write up on this project. I have to admit that this is way over my head but I wholly support what you are doing and want to keep up on the updates. I'd be interested if you could run the unit while dry firing to see what can be expected by shooter induced trigger pull problems and the mechanics of the trigger/sear/firing pin. Also of interest would be if it could detect and record data on primer ignition variations.

 

[ammolytics]

Eric,
Great work and write up on this project. I have to admit that this is way over my head but I wholly support what you are doing and want to keep up on the updates. I'd be interested if you could run the unit while dry firing to see what can be expected by shooter induced trigger pull problems and the mechanics of the trigger/sear/firing pin. Also of interest would be if it could detect and record data on primer ignition variations.

Thanks for taking the time to read it, I really appreciate it! It can definitely be used while dry-firing -- I actually did that to determine that the firing pin was the cause of the forward acceleration (towards the muzzle)!

Great suggestions for other use-cases. I'll have to see if I can get it running faster before some of those are possible. Fortunately, I've already received some help from another reader, which might get it running twice as fast.

 

[JMcBurn]

The good news is that there's a HUGE variety of options available these days, making it very easy to solve most problems. The bad news is that it can take quite a bit of research and experimentation to determine which components work best.

I had good results working with the LIS3DH accelerometer that I used in this project, and rather disappointing results when I experimented with one 9-DOF sensor that I tried.

I'm sure more experienced folks than myself could probably make it work, but I didn't let that stop me from getting the data I needed.

I hope that this project provides you with the insight and inspiration you need to build you own! Even if it doesn't work out as well as you hope, I guarantee you'll learn a lot in the process.

Yeah I think I am ordering an All in one 9DOF version tomorrow. I was reading that with all that data they get bound by the processor so to speed it up you can disable certain features. If you disagree let me know, as I have a few days to order so I can get it for this weekend.

 

[TBACRAY]

B&K just sent me one to play with on our PULSE system. I'd like to check the data side by side.

 

[Bayhawk21]

PULSE system?

 

[TBACRAY]

PULSE system is the digital sound meter I use to measure suppressed gunshots. Its made by Bruel & Kjær (B&K). Very handy piece of kit when you own a suppressor company.
https://bksv.com/en/products/data-a...I-data-acquisition-hardware/modules/type-3052

I can run 3 mics or I'm told I can run a triaxial accelerometer. B&K just sent one for me to play with but it won't happen till after SHOT.

 

[TBACRAY]

It would be cool to see how the numbers look side by side.

Great post

 

[Bayhawk21]

@ammolytics any plans to have several people shoot one rifle? I'm curious if the numbers might be able to quantify differences in recoil management techniques.

I think this thread has managed to identify who are the geeks on this site.

 

[JMcBurn]

@ammolytics any plans to have several people shoot one rifle? I'm curious if the numbers might be able to quantify differences in recoil management techniques.

I think this thread has managed to identify who are the geeks on this site.

I'll volunteer for testing if I end up buying a sphur.

 

[ammolytics]

@ammolytics any plans to have several people shoot one rifle? I'm curious if the numbers might be able to quantify differences in recoil management techniques.

I think this thread has managed to identify who are the geeks on this site.

Sort of? My plan is to provide a place where people can share their data and compare it to others. Frankly, I'm bored by the siloed nature of most devices we see in the industry (chronographs, weather meters, etc), which people will copy to their computers to collect digital dust. I think there's a lot more to be learned by making it available and organizing it in ways that help to answer questions for both new and experienced marksmen.

... how'd I get on this soapbox? ...

Geek for life.

 

[ammolytics]

It would be cool to see how the numbers look side by side.

Great post

Thanks! I agree, it'd be great to see how the datasets compare. I'm sure the industrial-grade gear from B&K has a lot more capability than off the shelf components, though I don't want that to stop anyone from experimenting for themselves.

I'm not planning on going to SHOT this year, otherwise I'd drop by your booth to chat more about it. Feel free to reach out directly though!

 

[ammolytics]

I'll volunteer for testing if I end up buying a sphur.

The Spuhr mount isn't a requirement. I already had it so I designed my mount to fit. If you have a picatinny rail, you could make that work just as well!

 

[JMcBurn]

Thanks! I agree, it'd be great to see how the datasets compare. I'm sure the industrial-grade gear from B&K has a lot more capability than off the shelf components, though I don't want that to stop anyone from experimenting for themselves.

I'm not planning on going to SHOT this year, otherwise I'd drop by your booth to chat more about it. Feel free to reach out directly though!

I wonder what the sensors cost for that system. Then use a DIY capture system.

I honestly think you will start running into issues with data size if you go too far up with capture rates. I say that because I do a decent amount of data analysis of cab files at work and when data sets get large it starts to suck (at least in excel).

Anyone with a 3D printer wanna make me a few pieces if I go down this path?

 

[ammolytics]

I honestly think you will start running into issues with data size if you go too far up with capture rates. I say that because I do a decent amount of data analysis of cab files at work and when data sets get large it starts to suck (at least in excel).

If you're interested in following along, I've already received some excellent feedback from another reader who has helped to speed up the sensor by 3-times and significantly reduce the output filesizes (numbers not yet available). This discussion is happening over on the GitHub repo where I open-sourced the code.
https://github.com/ammolytics/projects/issues/1

The software I'm using for analysis (as described in the article) is more specialized and intended for much larger datasets than a few MB, or even GB. It's much more powerful than something like Excel, which is more of a general-purpose solution.

 

[Bayhawk21]

I may have missed it but what triggers the start of data collection?

 

[ammolytics]

I may have missed it but what triggers the start of data collection?

Plugging in the battery. I think I addressed this under the "Future Improvements" section?

 

[JMcBurn]

Just because I don’t wanna register on the other site because I am not particularly knowledgeable. Would it run faster if you just pull the integer data from the sensor and do the math to convert to m/s^2 in post process? That way you don’t have to worry about the float issues?

If you tried that and didn’t get what you wanted did you try going to SPI as I am reading it is like 2.5 times faster.

 

[ammolytics]

Just because I don’t wanna register on the other site because I am not particularly knowledgeable. Would it run faster if you just pull the integer data from the sensor and do the math to convert to m/s^2 in post process? That way you don’t have to worry about the float issues?

If you tried that and didn’t get what you wanted did you try going to SPI as I am reading it is like 2.5 times faster.

You should be able to read the comment thread on GitHub without creating an account, though you'd need to sign up if you want to chime in.

I did compare the timing difference between reading raw sensor values vs getting the converted values. The difference is only ~20 microseconds, which is negligible compared to other operations.

• lis.read(): ~1375 microseconds
• getEvent(): ~1395 microseconds

The creator of that GitHub issue also suggested SPI. As I said there, I'm not sure if SPI devices can be chained in the same way that I2C can. The FeatherWing I'm using adds an RTC & microSD and the latter uses the SPI interface.

SPI is definitely faster than I2C, but I'm not yet certain that's the actual bottleneck in my case. More likely some code optimizations within the Arduino libraries could make a huge impact. It does give another level to pull in the future, however.

 

[JMcBurn]

I did some reading on SPI, essentially you slave the breakout by setting a pin low that you designate and then connect the other 3 wires to the same 3 pins (think it is clock, master in slave out, master out slave in) the feather has dedicated pins for these 3. It shouldn't be an issue to use SPI for the accelerometer and the I2C for the rtc/sd. I think i am just going to order the same stuff you have that way I can also help.

 

[JMcBurn]

I am looking into the standard config file it appears that you can set the refresh rate.

Might need to change it. Should be able to do it the same way you change the change the range of output.

 

[ammolytics]

I am looking into the standard config file it appears that you can set the refresh rate.

Might need to change it. Should be able to do it the same way you change the change the range of output.

I believe you're viewing the code from Sparkfun. They sell the sensor on a breakout board too, but their code is different from the one I'm using which is from Adafruit.

 

[JMcBurn]

I believe you're viewing the code from Sparkfun. They sell the sensor on a breakout board too, but their code is different from the one I'm using which is from Adafruit.

I believe I am looking at the source code for the library that works in the back end to give you your sensor values based on the commands you are giving (read acceleration method call etc). Yes it is the sparkfun source but I would bet the code for the adafruit sensor is pretty close. I didn't find the library source for the adafruit sensor.

 

[ammolytics]

I believe I am looking at the source code for the library that works in the back end to give you your sensor values based on the commands you are giving (read acceleration method call etc). Yes it is the sparkfun source but I would bet the code for the adafruit sensor is pretty close. I didn't find the library source for the adafruit sensor.

The Adafruit LIS3DH source code is here:
https://github.com/adafruit/Adafruit_LIS3DH

There are similarities -- the data rate can be set with this function:
https://github.com/adafruit/Adafruit_LIS3DH/blob/master/Adafruit_LIS3DH.h#L128

I wish it were as simple as changing the settings though. As the GitHub commenter pointed out, this only changes the frequency at which the sensor updates its values. The current performance limitation I'm hitting is how quickly I can get the Arduino/Feather to run it's loop.

Running almost no code within the loop, the fastest I can get the Arduino to run is just under 3kHz.

Also, there may be a minor bug in the Adafruit code which is preventing it from running at 5kHz:
https://github.com/adafruit/Adafruit_LIS3DH/issues/14

Anyway, I highly recommend creating a GitHub account -- it's definitely a better place for this type of detailed technical discussion & for making contributions!

 

[JMcBurn]

The Adafruit LIS3DH source code is here:
https://github.com/adafruit/Adafruit_LIS3DH

There are similarities -- the data rate can be set with this function:
https://github.com/adafruit/Adafruit_LIS3DH/blob/master/Adafruit_LIS3DH.h#L128

I wish it were as simple as changing the settings though. As the GitHub commenter pointed out, this only changes the frequency at which the sensor updates its values. The current performance limitation I'm hitting is how quickly I can get the Arduino/Feather to run it's loop.

Running almost no code within the loop, the fastest I can get the Arduino to run is just under 3kHz.

Also, there may be a minor bug in the Adafruit code which is preventing it from running at 5kHz:
https://github.com/adafruit/Adafruit_LIS3DH/issues/14

Anyway, I highly recommend creating a GitHub account -- it's definitely a better place for this type of detailed technical discussion & for making contributions!

I suppose I'll make an account on github, but at 3khz you have to be able to get way more data than you were at the 100hz orignally, even if you have to post process the data.

 

[Bayhawk21]

Looks like hackaday picked up on this.

https://hackaday.com/2019/01/23/rifle-mounted-sensor-shows-what-happens-during-shot/

 

[LastShot300]

Very cool material! thanks a bunch for sharing it with us

 

[ammolytics]

Looks like hackaday picked up on this.

https://hackaday.com/2019/01/23/rifle-mounted-sensor-shows-what-happens-during-shot/

Thanks for sharing -- I'm really proud to have my work shared on Hackaday!

 

[CanPopper]

Hello, this is CanPopper here. I've already created a full firearm computer to collect this type of data and more (and got the US patent too...). Those of you who are curious can message me.

We've shown this new system at Shot Show 2019.

 

[thaflash_la]

I’d love to see what this can show about the effects of different muzzle devices. Especially since you can shoot from a position and still get real data (in theory).

 

[CanPopper]

Already have the data actually... I've done testing on my Win Mag before and after muzzle brakes and suppressors. My firearm computer does G ranges up to 200G's whereas the regular accelerometers only do 2 to 4G's.

One of the big challenges is a trigger analysis device like a MantisX needs to run the accelerometer at its most sensitive setting of 2G's. That saturates really easily.

My gun computer, I call it the IPhone of Guns, does both sensitive movements and high recoil at the same time. Yeah getting that kind of data is a real pain but that why my system is a full computer and not a microcontroller.

I can't link to my page since that would violate the Hide's TOS.

 

[elwarpo]

Have you considered adding the temperature sensor board? I figure it will give real time data for muzzle velocity measurements.Temp pressure board

My goal is to try different AR builds and see if a light bolt really has less recoil, and other such nonsense LOL

I also want to test different stances, holding and hand position techniques to see which controls recoil better. Being a geek and scientist, this is going to be fun. Thanks for the write-up. Sort of a myth busters of a lot of BS techniques out there...

I would also be curious if you can put in a data start button to make data files easier to manage.

 

[thaflash_la]

You could even just make that button a power switch if it’s starting collection when it receives power.

 

[elwarpo]

I picked up the boards you recommended, but will put in a push button inline before the boards for power, and also a rechargeable CR123 battery tray for power. Will post up pics when it is together. also plan on attaching a pic rail adapter to the box holding the electronics for easy removal and moving it between rifles.

 

[ammolytics]

I picked up the boards you recommended, but will put in a push button inline before the boards for power, and also a rechargeable CR123 battery tray for power. Will post up pics when it is together. also plan on attaching a pic rail adapter to the box holding the electronics for easy removal and moving it between rifles.

Awesome! Looking forward to seeing some photos!

 

[elwarpo]

Can you please post pictures of your wiring/connection setup, starting to assemble the system. from what I see the blue wire is 3v on the accelerometer and m0, green in ground on both, yellow is sda on both and brown is scl on both. I see the Adalogger is mounted on top of the M0, are the wires soldered to the boards, going from the same hole in the adalogger to the m0 below?

 

[ammolytics]

Can you please post pictures of your wiring/connection setup, starting to assemble the system.

I recommend the Adafruit guide, which includes very detailed wiring instructions. That's precisely what I followed.
https://learn.adafruit.com/adafruit-lis3dh-triple-axis-accelerometer-breakout?view=all

To use the project and code as-is, you'll need to follow the guide for I2C instead of SPI.

Hope this helps!

 

[ammolytics]

Hey everyone,

I just posted a new article giving an update about the latest changes to this project, including the huge performance boost!

https://blog.ammolytics.com/2019-02-23/rifle-accelerometer-update.html

 

[SDet]

Hey everyone,

I just posted a new article giving an update about the latest changes to this project, including the huge performance boost!

https://blog.ammolytics.com/2019-02-23/rifle-accelerometer-update.html

It looks like you're planning to do something like this?

https://www.bksv.com/en/about/waves/WavesArticles/2016/prone-to-excellence

 

[ammolytics]

It looks like you're planning to do something like this?

https://www.bksv.com/en/about/waves/WavesArticles/2016/prone-to-excellence

Thanks for sharing, I hadn't seen this article before! Yes, this was essentially the same idea I had when I first built it. I wanted to see if I could detect things like flinch or bad trigger pulls (left/right) during a shot that corresponded to a bad score. My local league is getting all electronic targets soon, so it should be easier to correlate the data.

 

[CharlieNC]

I'm interested in a similar application, measuring muzzle vibration as related to positive compensation (node). With barrel times typically in the 1.5ms range, a very high measurement/sampling rate is required. I acquired an Arduino which can fulfill this need, and still working to finalize the accel selection; Analog Devices has a wide selection. Need to study your protocol more, thanks.

 

[mikehill85]

Thanks for sharing, I hadn't seen this article before! Yes, this was essentially the same idea I had when I first built it. I wanted to see if I could detect things like flinch or bad trigger pulls (left/right) during a shot that corresponded to a bad score. My local league is getting all electronic targets soon, so it should be easier to correlate the data.

Cool project. I was thinking about doing something similar and it seems you already did it which is cool. One thing I don't understand when I look at your data, it seems the gun is accelerating for about 0.05 seconds (presumably after the shot breaks).
Doing some rough calculations, say we have a 24" barrel and we are accelerating a bullet to 2,700 fps, the time I would expect the bullet to be in the barrel would be about 0.0015 seconds. This sensor seems to be reading acceleration for about 30 times longer than is expected. Once the bullet has left the barrel, there should be no force on the gun pushing it backwards causing a backwards acceleration (there can (and should) be a backwards velocity of course but not a backwards acceleration).
You were saying your sensor reads at about 750 Hz. This means you should really only see acceleration on one data point since you have a resolution of ~0.0013 seconds.
Additionally, there are similar studies that came up with similar results to what I would expect to see. Please see below.

Case Study: enDAQ Sensor Firearms Testing

A three axis accelerometer is attached to the picatinny rail to conduct firearm recoil measurements. Potential uses include product development.

blog.endaq.com

Please don't take this the wrong way. I'm not trying to grill you. I think this is an extremely cool project. I am just trying to figure out why these results don't seem to line up with what is expected from Physics and what we see in other projects.
I suspect one or more of the following my be going on:

1. You sensor has a maximum range of +/- 16 g and according to my calculations you could see upwards of 160 g of acceleration of the rifle (under free recoil anyway). The sensor may not be giving good data.
2. It could also be possible that the propellent gasses are still burning and accelerating the rifle.
3. It could be that what you thought was the firing pin accelerating the rifle forward was actually just you catching a portion of the recoil spike accelerating the gun backwards (which makes sense given the resolution of your sensor). This would mean negative acceleration is in the forward direction and what you've identified as "recoil" on the graph is actually deceleration due to friction.
4. The acceleration we are seeing may actually be from the accelerometer whipping backwards. I'm not sure how it was mounted but it's possible.

I personally think number 3 is the most likely culprit. I'd love to hear your thoughts on this.