Guns and Lasers

[reggio68]

Hi smart people,

I'm looking for some direction with an idea I had (born from laziness, as all good ideas are).
I like to have a plink with an air rifle every now and then, and have several paper based and knock down targets set up in my back garden. Unfortunately the paper based targets require my removal from the cosy warmth of my back door to the often wet and cold outside to retrieve the targets and check the hits (and the knock down targets don't show accuracy).

So I thought about an electronic target, did the google search, and it seems that type of target is stupidly expensive, and designed for ranges ... not the occasional sort of thing I'm looking for. I had a think about how to record a hit, and came up with a pressure pad type thing and a laser proximity thing (I use "thing" as I really don't know about this stuff). Kinda gave up on the pressure pad idea as there is not much that will stand constant abuse from a rifle and live to talk about it, so we're left with some sensor that can detect a pellet passing by at 850fps. I started looking at laser stuff, but am so out of my depth on this I really don't know what I'm looking at.

As a bit of background, my electronics experience is limited to soldering ... everything else is a black art to me, the programming side I'm more than comfortable with.

Anyone want to help me expand this idea (and save me from the awful English weather)?

Cheers all

Reg

 

[Laplace]

One avenue that would be worthy of investigation might be using an array of foil strain gauges to measure the dynamic deformation of a steel plate impacted by a lead pellet. For instance, a 3"x3"x1/8" square plate suspended from the corners as a target with four strain gauges on the backside located on radial lines out to each edge. When the pellet impacts there will be a sound impulse from the metal-to-metal contact transmitted through the bulk steel. But a pellet is about 1/4" long so there will be a sustained force pushing on the steel plate as the pellet is deformed from front to back. At 850 fps it should provide a force duration of 0.25/(850x12)= 25 usec. So if you get a strain gauge with at least 100 KHz response bandwidth and read it every 5 usec and compare all 4 readings every 5 usec, then it might tell you something like how close the pellet impacted to the center of the plate. Unless you are well versed in the solution of partial differential equations for dynamic displacement then it may take a lot of experimentation to determine exactly how to interpret the strain gauge readings. But be careful about doing the experiments in an enclosed lab since a lead pellet impacting a steel plate at 850 fps will essentially vaporize, and you don't want to be breathing that lead metal mist.

Another possibility would be a horizontal/vertical laser diode/detector array with beams on 1/10" centers. The electronics & software for this would be so much simpler than for the previous idea.

 

[reggio68]

Thanks Laplace, that was an awesome reply!
I looked into the foil strain gauges, but have some major concerns about measuring the inputs and working out the location, also resetting values as that steel will deform from the impact and environmental conditions. I think they would be great for working out the force of impact though, so may come back to that if I get the other stuff working.

Also looked a lot into the laser diode/detector array thing, after wasting a lot of time on google only finding industrial models ( £66 per laser/sensor ) and almost giving up due to the cost ... I saw some bits on ebay for the Arduino .... now I'm excited again!

My only concern is the reaction time of the sensors, will they be able to detect a pellet going past at that speed (insert your maths here for speed calculation ) you're spot on with the length of the pellet, the diameter is 4.5mm (11/64in I think).

I'm off to buy an Arduino .... there is a limited number of inputs though, so could I link the sensors in series using a different resistor on each and thereby calculate which one had been broken?

Thanks again for your help, if this works well enough to go commercial you're definitely in for a cut!

Cheers

Reg

 

[reggio68]

We're moving forward .... Arduino is on it's way, loads of photodiodes too ..... I had a concern over the cost of laser diodes ( I'd need 100 for a 14x14cm standard target), so am going to try something with perspex tell me if you think this is stupid.

I'm thinking of firing a single laser (per axis) via a fresnel lens ( to make a straight line ) to the edge of a piece of acrylic or polycarbonate (shaped somehow at the receiving end of the acrylic to collimate the spread beam, and turn through 90 degrees across the front of the target), to make something like a sheet of light so I can pick up any "shadow" on the photodiodes (that's how I visualise it).

I'm still working on the refraction stuff for the perspex/acrylic, and wont really be sure about it until the lasers and lenses arrive .... kinda worried that the laser will dissipate so much that it can't be detected by the photodiodes, I'll go for a hit and hope on that (anyone that is a genius on refraction can jump in here) .... I'll do a diagram over the next couple of days and post it so you can see what I'm trying to do.

Thanks to anyone who can help

Reg

 

[reggio68]

Stuck again

Hi all,

Anyone know how I can get an Arduino to read 96 photodiodes?

I was looking at shift registers to reduce the number of inputs, but how do I turn the photodiode output into on or off?

Cheers

Reg

 

[BobK]

First of all, photodiodes are probably a bad choice, there output is very small and will have to be amplified to read with an Arduino. You should use phototransistors, which can output a logic level signal. Then you could read then with the Arduino by multiplexing. 10 outputs and 10 inputs would allow you read 100 of them.

Bob

 

[reggio68]

I was concerned with the reaction time of phototransistors (and they are more expensive) I have to catch an event of max 20usec.

Reg

 

[(*steve*)]

Because of the short event time, multiplexing (or any method which doesn't result in the near continuous reading of the signal) is not going to work.

What you probably want is 100 circuits all looking for an event, and which latch when one is detected. Then you can read them at your leisure and reset them.

A similar option is to connect each to a pulse extender which extends the pulse to a length long enough to guarantee that it will be read. This is essentially the same as the above except it auto-resets.

For a 20uS event, you might be best sending 1uS pulses (essentially a 500kHz signal) to your light source(s) and detecting three or more missing pulses at the receiver. This would go a long way to eliminating false triggering from noise.

 

[reggio68]

Thanks Steve, took me a while to digest all that, as I'm pretty much guessing here, and every time I hear a new word I have to go google it

I'm going to try something like this ..... put the output from the photodiodes through a whole bunch of comparators, then pass the output of them into a few PISO shift registers which I should then be able to read from the arduino.

Sounds simple enough :/

Cheers

Reg

 

[(*steve*)]

Comparators are not enough.

Let's assume perfection. The comparator's output will change for just 20us as the pellet passes by. You need t read it during those 20us or the event has gone.

What you need is a pulse extender so that the 20us pulse becomes (say) a 50ms pulse. Then, if you read the outputs 100 times per second, you're guaranteed to get at least 1 read every time a bullet passes. Without the pulse extender you'd have to read them 100,000 times per second.

The problem which then arises is that noise can easily cause an output to trigger (they're going to be pretty sensitive). So you'll get false reads and it may be hard to tell what is a pellet and what is noise.

The answer to this is to have the input circuit seeing many, many transitions every second. This is done by flashing the light on and off (in my example 500,000 times every second). This will be more noise tolerant, but you may still miss a pulse or two. The next thing is to have a circuit that detects missing pulses, and requires a certain number (say 3) before it claims a "hit". False triggering would require an extended period of noise, and this is less likely.

All of this is happening at a speed sufficient that it's not going to be something you want to slap together.

Your light source needs to be small compared to the pellet, perhaps a laser module with a line generating optic. Having only a single source for each axis means your grid will not be square, but that might be OK.

The smaller the light source, the more accurate you need to be with aligning things. and the closer the spacing you need for the detectors (I would recommend no further apart than 1/2 the width of the pellet.

 

[reggio68]

Sorry, this is my first foray into electronics ....

I have the lasers and line generators coming soon ( and 500 KHz ceramic resonators due to your previous post )

About the squareness of the optics, I have thought about this ... mainly due to the cost of the laser diodes! .... so picture this, a single laser, with line optic presenting to the side of a sheet of acrylic ( cut so the refraction of the acrylic collimates the light ... still have to work this out ), then I should have the square sheet of light that you mention.

My worries are these ...
After refraction the light won't be strong enough to even register on the photodiodes.
The output from the photodiodes won't be enough for the comparator (if I have to amplify, the delay would kill it) though I think red tinted perspex and a red tinted cover over the diodes will help (it's not perfect, but 650nm fiters are way too expensive to even consider).

I mentioned my googleness before, the only thing that has confused me is "pulse extender", I have no idea what that is (I have no idea what most things in electronics are)

I can't even imagine how to do individual circuits to latch to only three events, at some point these triggers need to be reported surely? how is that information passed back to the arduino?

I'm still confused about a lot of this, though I think I'm getting better your help is very much appreciated, it's kind of a lot to get my head around

I checked the reaction speed of everything I ordered and it seems it can still be done within the time I need, I'm probably wrong but hey it's a learning process, and this is fun!

Thanks again

Reg