Photographing a Speeding Bullet
I’d like to start with a big thanks going to Chris Callander. When he saw the Camera Axe project he shared his idea for a new sensor with me. I took his ideas and developed this new projectile sensor and updated the Camera Axe software to support it. I doubt I would have ever came up with this new sensor idea without Chris. The ideas that get shared in the open source community are great! The hardware and software for this project are shared under the Creative Commons Attribution 3.0 License.
You can purchase the Camera Axe and this projectile sensor at this store or built it yourself (parts list below).
This new projectile sensor is designed to help photograph speeding bullets on the Camera Axe platform, but since I used the Arduino development environment, anyone using an Arduino could easily adapt the this hardware and software to their purposes.
This new sensor has two IR sensors spaced exactly two inches apart. The user inputs the distance from the sensor to the desired position of the projectile when the picture is taken. Based on the time it takes the projectile to travel those two inches between the sensors, a velocity for the projectile can be determined. Since bullets and other projectiles basically travel at a constant velocity, it is easy for the microcontroller to calculate the delay in microseconds until the picture is taken.  I ran into a few gotchas in the software while I was writing it.
- Needed to use digitalRead() with the sensors and not analogRead() (analog read is too slow at 100 us)
- Used integer math because floating point math is very slow in Arduino
- Had to be careful with my order of operations or I would overflow 32 bit unsigned integers in certain cases
I’m very pleased with the results. I’ve tested it with an airgun that travels at a relatively slow 500 ft/sec (half the speed of sound), but my calculations show that the Camera Axe’s 16 MHz ATmega168 chip can easily predict the position of a high speed riffle (several times the speed of sound) to within a fraction of an inch. I had known that this should work, but it was still amazing to see it working perfectly in the real world, considering all the micro fluctuations that I didn’t account for in the calculations. In the end, things like gravity, air resistance, and quantum forces just didn’t matter 🙂
[Update: Alan Sailer correctly pointed out the IR transistor I’m using only works at 15us, this would limit photos to around 2x the speed of sound, see the comments for options on faster transistor options.]
Below is a schematic of this new projectile sensor sensor and here are the Eagle files.
If you’re planning to build your own, then this is my parts list
- Custom PCB using the Eagle file above
- (2) 3.5 mm male-male stereo cable
- (2) 3.5mm jacks
- (4) Vertical 3.5 mm Screw Terminal Blocks
- (2) IR Emitters
- (2) IR Transistors
- (2) 10K and (2) 220 Ohm resistors
Here is a list of updated files:
- Updated Camera Axe label. Nothing special here.
- Updated Camera Axe source code to support this new sensor. One nice feature of the projectile code is that I print out the feet/sec or the cm/sec that the bullet was traveling. While this wasn’t needed for photography; it is still fun to see the numbers.
- Updated user manual to include the software changes.
Using the Projectile Sensor with the Camera Axe
First, visually line up the IR LEDs to the IR transistors so that they are pointing at each other. Then just plug the 3.5mm cord from Sensor1 on the Camera Axe to Sensor1 on the projection board. Next do the same for sensor2. Plug a flash into Camera/Flash1 on the Camera Axe. Turn on the Camera Axe and go to the sensor menu. (Optional if you want to change from inches to centimeters press [Menu]+[Set]+[Left] while turning on the Camera Axe to enter the special menu to change from English units to Metric units.) In this menu you can set the distance from the sensor to where the projectile should be on the picture (0->999 cm/inch).
You can test your the projectile sensor’s set up by putting your finger in front of the first sensor. After one second a message will display saying that the “second trigger failed”. After this message goes away, put your hand in front of the second sensor and then your other hand in front of the first sensor. This will basically simulate an infinitely fast projectile and the Camera Axe will display the speed of a fast projectile (something more than 45 times the speed of sound).
This sensor should generally be placed at the end of the gun barrel so you don’t need to worry about the bullet hitting the circuit board or sensors. The bullet/projectile must pass through this sensor before it hits the target. In my setup I have everything firmly bolted to a table and trigger the gun with a string from a safe distance.
Pretty Pictures
Last but not least, here are a few of the pictures I took with this new sensor. Taking these pictures was possible with the Camera Axe before I had the projectile sensor using a microphone or a laser sensor, but it involved a lot of trial and error. With the projectile sensor, every picture is what I was shooting for (pun intended).
You can test your the projectile sensor’s set up by putting your finger in front of the first sensor. After one second a message will display saying that the “second trigger failed”. After this message goes away, put your hand in front of the second sensor and then your other hand in front of the first sensor. This will basically simulate an infinitely fast projectile and the Camera Axe will display the speed of a fast projectile (something more than 45 times the speed of sound).
mike said,
December 13, 2009 @ 12:04 pm
Great post. I’ve always wanted to try something like this.
emilio said,
December 13, 2009 @ 4:39 pm
awesome! i’ll definitely be trying this out once i get some general microcontroller experience under my belt. it should easily capture some fat, shiny 900FPS .45 bullets.
now this begs the question: can it measure bullet speed? the cheapest commercial chronometers are around US$90-120, and the prices shoot up for data storage, printing, etc. a great project would be an accurate chronometer with data display and output to an SD card. these can be tricky devices to engineer, though, as the cheaper models perform poorly under some lighting conditions.
Maurice Ribble said,
December 13, 2009 @ 4:53 pm
Emilio, I actually display the bullet’s speed (in ft/sec or cm/sec) to the LCD for two seconds after the shot so the answer is yes it can measure and report a bullet’s speed. I haven’t tested this thing in harsh lighting conditions (my photos are always in a dark room), but I think it should do decent in most lighting conditions. The IR transistor I choose is very directional. If nothing else you could always put up a little light shielding to protect the transistor from outside light sources. I don’t plan to turn this into a logging chronometer, but it should be pretty easy for someone to take this hardware/software and adapt it for that use. If this happens please post a link. I’d love to see other uses for this project. Open source is great.
Chris said,
December 13, 2009 @ 5:08 pm
where do you put the sensor in relation with the gun and the target?
Maurice Ribble said,
December 13, 2009 @ 5:21 pm
Chris, I should have explained this better. This sensor goes between the gun and the target.
Sean said,
December 13, 2009 @ 5:22 pm
Thumbs Up!
Chris said,
December 13, 2009 @ 6:22 pm
So the bullet has to pass between the two pairs of sensors, a couple of mm from the board?
polossatik said,
December 13, 2009 @ 6:24 pm
Please don’t kill strawberries…
Nicely done and a simple , but yet elegant solution.
frollard said,
December 13, 2009 @ 7:01 pm
Chris: Yes, the bullet passes millimeters from the board. It’s probably mounted directly to the gun – like any accessory mounting under the breach.
Maurice Ribble said,
December 13, 2009 @ 7:22 pm
Frollard is correct. Although the bullet passes more like an inch away from the sensor and not a few millimeters. Since this board is right next to the barrel I had no issues with hitting it. Your target can still be up to 999 inches (83 feet) away so you don’t have to worry about that being too close either. If being close to the board is really an issue then it would be trivial to add some wires to move the sensors farther away from the circuit board. The idea setup is having the gun, sensor and target all really close and firmly held in place. Then the gun could be triggered from a safe distance via a string. This is how I did my shots with the airgun.
Chris said,
December 14, 2009 @ 11:00 am
The reason I was asking was to determine if it was possible to launch objects that are bigger than a bullet and photograph the collision.
alan sailer said,
December 14, 2009 @ 3:34 pm
Nice work. I’ll have to mess with this someday.
By the way, in my own high speed work I found that the phototransistors were marginal. They are slow, about 15usec rise time. If your pellet is traveling at 800fps or greater, the resulting waveform looks like a triangle wave, not a clean pulse.
I found another Honeywell device, the SD5600 optoschmidt detector to be the cats meow. Rise and fall times are 10’s of nanoseconds, pulse is clean as a whistle. In fact, it was such a clean pulse that I can measure the pellet velocity with one detector. Length of pellet/pulse width.
Maurice Ribble said,
December 14, 2009 @ 6:06 pm
Alan, thanks for your input. I looked at the specs for the IR transistor I used and like you said it only works at 16us. This is going to be the limiting factor in this trigger. I agree the SD5600 looks much better for really high speed stuff. I’ve updated the article to point out this oversight I had. Thanks!
Strachan said,
December 15, 2009 @ 3:47 am
Why not make the distance between the sensors a power of two, so the division is done with a shift?
Anonymous said,
December 15, 2009 @ 10:16 am
http://en.wikipedia.org/wiki/Metric_system for the next project!
Maurice Ribble said,
December 15, 2009 @ 10:39 am
Strachan, I started with a nice simple 2 inches, but decided to make this 200 hundredth inches when I started supporting the metric system. I suspect with some clever thinking you could get rid of the divides, but I don’t see the point. These divides happen outside the critical timing loop so a few extra cycles don’t matter much. The comment about FP in my article isn’t that critical as long as the conversions are delayed. I probably shouldn’t have mentioned it, but I’ll leave it there so these comments don’t confuse people reading an updated article.
[Edit: I’m not changing the above, but I was having a stupid moment and what I said is wrong. See below for the correction.]
Anonymous, the software can switch between metric and English units.
gmg said,
December 15, 2009 @ 1:54 pm
Great stuff, and a nice design on the new Axe.
I’m curious about the kind of flash you’re using to get such crisp shots. When I use a Canon EZ430 in manual mode at the lowest setting (1/32) with my rig, I get blurring of the balloon edges as they peel back. Typical camera settings would be ASA 200-400, minimal aperture for best depth of field.
Any thoughts?
Strachan said,
December 15, 2009 @ 9:41 pm
Perhaps I am confused.
I assume there are two “critical timing loops”: the first measures the time between beam breaks and computes the projectile velocity; the second waits for the projectile to cover the specified distance. The math is being done while the projectile is in flight, making the time consumed by those operations relevant.
If the sensor spacing is a power of two (256 x .01in, say), the velocity calculation can be implemented using a shift, which should be substantially faster than integer division. Also, the remainder from the division can be determined using a bitmask, and used to improve the accuracy of the flight-distance timing.
You’re obviously in a better position to tell whether this makes any difference in the real world, but it wouldn’t cost anything to try.
Maurice Ribble said,
December 15, 2009 @ 9:57 pm
I’m sorry for confusing you Strachan. You are correct. I was having one of my stupid moments.
I did some calculations and if something is traveling the speed of sound it takes 70 us to travel 1 inch. Since the ATmel is clocked at 16 MHZ it can do approximately 110 cycles in 70 us. I think it’s more realistic that the target would be more than 10 inches away which should give more than enough cycles for the division. I don’t know off the top of my head how the Arduino library breaks up a 32 bit division so I can’t easily calculate the clocks it uses for this operation. If this ever is a real problem then I I agree with you that changing the software to use a shift would be a good improvement.
Maurice Ribble said,
December 15, 2009 @ 10:02 pm
gmg, I sometimes see a little bluring with my 580ex at 1/32nd power, but I can go to 1/128th power and that is almost always crisp. You can google for something like “flash duration 430ex” and find out how long the different flash exposures are. With a little math you can then calculate how how fast an object can move before it starts to blur.
Chris C said,
December 17, 2009 @ 2:15 am
Hi Maurice, still waiting on the postman!. Would the detectors Alan mentions be a straight swap? Or is more required?
Maurice Ribble said,
December 17, 2009 @ 10:14 am
The datasheet is here: http://datasheet.octopart.com/SD5600-001-Honeywell-datasheet-75178.pdf
This device has 3 pins and I’m not exactly sure without a little testing if it’s compatible with the boards I’ve done (if it is you’d just screw two of the pins into a single terminal). If someone knows for certain that’s how this would work it would be a great response. The IR frequency of these devices is not mentioned in the spec and they suggest using their IR emitters so you’d need to see if the IR emitters I suggested are compatible or if you need to use their emitters too.
Chris C said,
December 17, 2009 @ 12:57 pm
Thanks Maurice. Way beyond me though. Lets hope someone knows.
Chris
kyndal said,
December 22, 2009 @ 6:54 pm
shouldent take much to adapt the code to account for gravity.
and used for dropping things.. 😉
would be slightly better than my curent setup
which is time delay only, and highly depending on the initial speed and height of the target release..
/Rune Kyndal
Chris C said,
December 30, 2009 @ 6:41 am
Hi Maurice,
Kit arrived and built :-). Hoping for a test run in the next couple of days.
I have been getting used to the menu’s etc. But find that the technique you mention above for changing from inches to cm doesn’t work. Pressing those three keys and switching on just gets the Camera/Flash1 line up. Am I missing something?
Chris C
Maurice Ribble said,
December 30, 2009 @ 9:07 am
Hi Chris,
Are you sure you’re holding down the menu, set, and left buttons when you turn on the power? Make sure you are firmly holding these buttons down when you turn on the power and you should enter the special menu where you can select centimeters. [Edit: The correct buttons are menu, set, and RIGHT. A mental block must have had me saying left.]
Chris C said,
January 1, 2010 @ 5:59 am
Hi Maurice,
Got it. But by pressing menu, set and RIGHT.
I hope that isn’t an indication of a problem with my assembly!
Happy New Year everyone.
Chris C
Maurice Ribble said,
January 1, 2010 @ 7:22 am
Chris, I am sorry for the confusion. You are correct that it is [menu] + [set] + [right]. I don’t know why I kept saying left. I must have meant my other left 😉 I updated the user manual and my comment above so others hopefully don’t get confused like you did. Thanks for catching this bug in the documentation.
TBAr said,
January 9, 2010 @ 1:46 am
Thanks for posting this, including the parts list. Just to note, the last item in the list should be
* (2) 10K and (2) 220 Ohm resistors
instead of 20 of the 220’s.
Maurice Ribble said,
January 9, 2010 @ 6:27 am
Thanks TBAr! Fixed.
Chris C said,
January 23, 2010 @ 1:15 pm
Any experience of using this with airgun pellets? I have had no joy triggering with a .177 or even a .22. I only seem able to line up enough to trigger the first sensor. I haven’t had much time admittedly and need to try some other mounting/set up options but was just wondering if anyone had any tips.
I made an alternative sensor with plastic tubing that slid over the barrel. But while dropping a small coin through the tube to test it triggered the axe, no joy on the gun. I’m assuming it is an alignment thing on that basis.
Do the sensors need to have the source completely blocked or just partially? A .177 may be simply too small if it is completely.
Chris C
Maurice Ribble said,
January 23, 2010 @ 1:43 pm
Hi Chris,
It needs to be mostly blocked. You could try covering up part of the emitter or transistor with black tape to see if that helps for these small projectiles.
Chris C said,
January 23, 2010 @ 4:42 pm
Thanks Maurice,
I have another design in my head for a sensor set up. I’ll give it a go and feedback any positive results.
Chris C
Rune Kyndal said,
January 25, 2010 @ 5:38 pm
im working on a similar “ghetto” version,
based on IR LEDs and photo transistors from a couple of old logitech mice.
i have no specs on the transistors. so ill have to do some testing to figure
if they are up to the job.. (reaction speed, beam width, and projectile size tolerance.)
target range for this one. is an air-pellet gun 5mm projectiles
with exit velocity probably in the 300 – 400 m/sec range
/Rune Kyndal
Eric van Dee said,
March 10, 2010 @ 7:58 am
Tip for Chris about the projectile sensor:
to detect smaller objects you have to use multiple transmitters and receivers in parallel.
Since you have problems with the second detector you could use (for example) 4 transmitters and detectors with a slight vertical distance offset.
Eric.
James said,
March 22, 2010 @ 10:57 am
Wondering if this would work for triggering a camera shutter. It will go to 1/8000th and the aim is to catch airgun pellets.
Once i can confirm all this will have to buy though 🙂
Maurice Ribble said,
March 22, 2010 @ 6:02 pm
Hi James,
This setup could trigger a camera at 1/8000 a second, but since most cameras have about a 50 ms (1/20th of a second) shutter lag you will always miss the shot. It’s only practical to use this with a flash in a dark room like I described in the article above.
HB said,
December 7, 2012 @ 2:46 pm
I see this article is about 3 years old. I am just getting into Arduino myself and am hoping to measure the speed of a .22-250 which is about 4000ft/s. Would your code be fast enough for that? I have been looking around to squeeze as much speed into the trigger and this is what I came up with:
void engageTriggerWatch(){
delay(500);
Serial.println(“begin”);
//check pin 24 for a 0
while((PINA & B00000100) != 0 ){} //same as: while(digitalRead(24) != 0); (PINA & 1<<PA2) is the //address of pin24
trigger1 = micros();
//check pin 25
while((PINA & B00001000) != 0){} //while(digitalRead(25) != 0 );
finalTime = micros ()-trigger1;
}//engageTriggerWatch
And you could add into each of those while() loops a check to see if the button has been pressed if you want to cancel the loop. I believe this is
ChuckC said,
December 19, 2012 @ 1:11 pm
HB,
did you get this thing working?
I am very much interested.
Maurice Ribble said,
December 19, 2012 @ 2:39 pm
The sensor described here would not work for 4000 ft/sec. I have much improved code and hardware for this as part of my camera axe project. http://cameraaxe.com/
The biggest problem with the sensor I used here was the slow responce of the photo transistor. I suggest looked at the new schematic and photo diodes I’m using here: http://www.cameraaxe.com/wiki/index.php?title=Sensors#Projectile_Sensor
HB said,
December 26, 2012 @ 3:46 pm
No, but its in the back of my mind. I have the program ready and two push buttons as the “sensors”. If I hold the second “sensor” and then press the first sensor, the fastest possible read, I get around 40,000 fps for max. speed. But an actual circuit with the sensors as Maurice said might limit that. The circuit I used was part of a project totally unrelated but I used it just to see what speeds we are limited to.