hi anybody,
Thanks
cleaned
Moderators: pilkguns, m1963, David Levene, Spencer, Richard H
-
David Levene
- Posts: 5617
- Joined: Mon Mar 01, 2004 12:49 pm
- Location: Ruislip, UK
Re: picture 2
Out of interest, is the offset of the actual hole from calculated position consistent from shot to shot or does it vary.richard wrote:the Time counter on 3.00000 Mhz returned this position but is false.
Distance from hit to sensor:
D(x1,y1,x2,y2) = sqrt((x1-x0)^2 + (y1-y2)^2).
t0 - exact time of the shot (unknown)
k - shock wave speed
x,y - coordinates we want to find
ta, tb, tc, and td - times registered by the sensors (one of them will be 0, others will be offset to that).
xa,ya,xb,yb... - coordinates of the sensors
Distance between hit to the sensor A is the time of the shock wave travel (ta - t0) multiplied by the shock wave speed k, and also can be calculated by the formula above.
D(xa, ya, x, y) = k*(ta - t0)
...and similar equations for other three sensors.
Now you have four equations and four unknowns (x, y, t0, k), so you can solve for x and y (you get t0 and k as a bonus)
The exact formula is several pages long (which naturally makes me suspicious convergence and roundoff errors).
I would recommend using generic implementation of a multivariate numeric solver to converge on the answer using equations directly instead of dealing with gigantic formulas.
You can go further and have the algorithm compute and keep the values of k over series of shots (self-calibration of a sort), keeping mean and standard deviation.
Then when calculating position you have the historical value of k and its precision, along with the timings of the sensors along with their precisions, so you essentially get a virtual input "for free" so you can boost your accuracy and have an estimate on precision of your result (which, of course, you would verify experimentally by hitting a target with a nail at known coordinates and comparing experimental values with the calculated ones).
It would be beneficial for a commercial system, but if its some sort of a lab I wouldn't worry about it.
PM me if you need more help
D(x1,y1,x2,y2) = sqrt((x1-x0)^2 + (y1-y2)^2).
t0 - exact time of the shot (unknown)
k - shock wave speed
x,y - coordinates we want to find
ta, tb, tc, and td - times registered by the sensors (one of them will be 0, others will be offset to that).
xa,ya,xb,yb... - coordinates of the sensors
Distance between hit to the sensor A is the time of the shock wave travel (ta - t0) multiplied by the shock wave speed k, and also can be calculated by the formula above.
D(xa, ya, x, y) = k*(ta - t0)
...and similar equations for other three sensors.
Now you have four equations and four unknowns (x, y, t0, k), so you can solve for x and y (you get t0 and k as a bonus)
The exact formula is several pages long (which naturally makes me suspicious convergence and roundoff errors).
I would recommend using generic implementation of a multivariate numeric solver to converge on the answer using equations directly instead of dealing with gigantic formulas.
You can go further and have the algorithm compute and keep the values of k over series of shots (self-calibration of a sort), keeping mean and standard deviation.
Then when calculating position you have the historical value of k and its precision, along with the timings of the sensors along with their precisions, so you essentially get a virtual input "for free" so you can boost your accuracy and have an estimate on precision of your result (which, of course, you would verify experimentally by hitting a target with a nail at known coordinates and comparing experimental values with the calculated ones).
It would be beneficial for a commercial system, but if its some sort of a lab I wouldn't worry about it.
PM me if you need more help
Also, I don't care about the clock speed and the material properties, but what is the order of magnitude of the tick counts of the timings?
For example, if you have just 10 ticks between two sensor readings when a hit is twice as close to one than another, your accuracy will be +/- an inch (eyballing to an order of magnitude).
So make sure your tick differentials are in thousands or more.
For example, if you have just 10 ticks between two sensor readings when a hit is twice as close to one than another, your accuracy will be +/- an inch (eyballing to an order of magnitude).
So make sure your tick differentials are in thousands or more.
[quote="AAlex"]...The exact formula is several pages long (which naturally makes me suspicious convergence and roundoff errors).../quote]
If you try to solve all 4 at the same time it can get quite 'extensive' - but to solve for three of the four microphone should come down to one line of code.
Then you can solve for each set of three microphones (three more lines of code) and a check routine comparing all four results (another line) - not pages of calculations.
I think you will find that this is the way most 4-sensor systems work. The 3-sensor sytem for 300M even includes a check routine for the spped of sound at the time of the shot registering at the target.
Spencer
If you try to solve all 4 at the same time it can get quite 'extensive' - but to solve for three of the four microphone should come down to one line of code.
Then you can solve for each set of three microphones (three more lines of code) and a check routine comparing all four results (another line) - not pages of calculations.
I think you will find that this is the way most 4-sensor systems work. The 3-sensor sytem for 300M even includes a check routine for the spped of sound at the time of the shot registering at the target.
Spencer
-
Tim Conrad
- Posts: 44
- Joined: Sun May 06, 2007 10:04 pm
- Location: Colorado Springs
Why the formula is several pages long
It gets a little bit worse, because you should consider bullet diameter as well. Sound travels out from the edges of the hole, not the center. For a dead center 10.9, it doesn't matter, anywhere else it makes a differrence. Most electronic target systems measure the temperature in the sound chamber, as that has a direct effect on the speed of sound. Humidity has far less effect.
3 microphones work, 4 gives a bit better accuracy. Clock speed is an issue as well, the 'tic' time determines the position resolution. Sound travels about 330 meters/second, or 1/3 mm per microsecond. With a 3 MHz clock, you get 1/10 mm resolution at best. The microphone and amplifier response ahead of the counter circuits can only make this worse.
For 10m air rifle, 1/10 ring is about 0.25 mm, so a properly designed target should be better than 1/10 ring. The USA-50 ft. is similar.
3 microphones work, 4 gives a bit better accuracy. Clock speed is an issue as well, the 'tic' time determines the position resolution. Sound travels about 330 meters/second, or 1/3 mm per microsecond. With a 3 MHz clock, you get 1/10 mm resolution at best. The microphone and amplifier response ahead of the counter circuits can only make this worse.
For 10m air rifle, 1/10 ring is about 0.25 mm, so a properly designed target should be better than 1/10 ring. The USA-50 ft. is similar.
-
Steve Swartz
Apropos of what is trying to be accomplished- as long as the timing circuits are picking up the signal properly, you are capturing differential delay data. You don't need to convert this delay to a distance measurement per se- the 2 dimensional field you are trying to caputer is pretty much "absolute" (fixed and of known dimensionality).
This is a much easier problem than that faced by "security types" in trying to pinpoint the location of a gunshot (for example) in an urban warfare setting, where triangulation and actual distance measurement is crucial.
All you need to do for a target system is to capture the delay ratios (use the earliest signal detected as the reference point) and then calculate the "centroid" of the delays.
Graphically, the earliest signal places the shot on top of that sensor, and the delays give the relative "delays" away from that corner. Draw delay arcs across the target face, and solve for the point that satisfies the intersection of each relative delay away from each microphone.
Maybe I'm oversimplifying this- but aren't we pretty sure that a shot that registers fell somewhere inside the 4 sensors? Given that the shot is inside the square described by the 4 sensor "cornerpoints," the speed of sound and all that is irrelevant. All we need are the relative delays to each sensor (with the earliest signal as a "0").
The biggest problem is making sure you have a suitably precise timing mechanism, suitably sensitive microphones, suitably discreet filtering and do not induce error in the wiring delays . . . ?
Steve Swartz
This is a much easier problem than that faced by "security types" in trying to pinpoint the location of a gunshot (for example) in an urban warfare setting, where triangulation and actual distance measurement is crucial.
All you need to do for a target system is to capture the delay ratios (use the earliest signal detected as the reference point) and then calculate the "centroid" of the delays.
Graphically, the earliest signal places the shot on top of that sensor, and the delays give the relative "delays" away from that corner. Draw delay arcs across the target face, and solve for the point that satisfies the intersection of each relative delay away from each microphone.
Maybe I'm oversimplifying this- but aren't we pretty sure that a shot that registers fell somewhere inside the 4 sensors? Given that the shot is inside the square described by the 4 sensor "cornerpoints," the speed of sound and all that is irrelevant. All we need are the relative delays to each sensor (with the earliest signal as a "0").
The biggest problem is making sure you have a suitably precise timing mechanism, suitably sensitive microphones, suitably discreet filtering and do not induce error in the wiring delays . . . ?
Steve Swartz
I agree Steve. The accuracy of this technique depends on, among others, the type and attachment method of the microphones. A mounted mic creates an output from sound as well as the sound hitting its supporting structure. Where, and more important, when will the detector trigger? Also, is there compensation for crosswinds?
Higher accuracy would come from detection of impact on a consistent solid backing plate, using a shock sensor rather than sound detection. The shock velocity of propagation would be far more repeatable than sound velocity, albeit much faster. Just some thoughts! :)
Higher accuracy would come from detection of impact on a consistent solid backing plate, using a shock sensor rather than sound detection. The shock velocity of propagation would be far more repeatable than sound velocity, albeit much faster. Just some thoughts! :)
Hyperbolic Navigation and Fixing
I am not sure that I really want to get into this as it was all a very long time ago! The principle involved is the same as that employed by a number of radio navigation aids, some going back to WW2. GEE, LORAN, OMEGA and Decca. All worked on the principle of measuring signal Time of Arrival (ToA) [Phase difference in the case of Decca] and used the readings to plot the result on a chart with a hyperbolic lattice overprint. The lattice plotted lines of equal time difference, achieved by one station being selected as the "Master" and the remaining ones as "Slaves".
Some years later I went on to employ the same method in the Anti-Submarine Warfare field. The same sonic event received by a number of sonobouys could be used to generate a hyperbolic fix or "Hyfix". We used to do the calculations using a simple calculator and subsequently a HP programmable.
In this case we are looking at a micro version of the above problem. There are additional variables and the accuracy requirement is much higher, but the principles are the same and have been employed for about 65 years.
Rutty
Some years later I went on to employ the same method in the Anti-Submarine Warfare field. The same sonic event received by a number of sonobouys could be used to generate a hyperbolic fix or "Hyfix". We used to do the calculations using a simple calculator and subsequently a HP programmable.
In this case we are looking at a micro version of the above problem. There are additional variables and the accuracy requirement is much higher, but the principles are the same and have been employed for about 65 years.
Rutty
-
Steve Swartz
If I may humbly offer the scenarios are indeed similar (as I noted for the urban shot location problem) but in practice are different problems.
The problem is greatly simplified by the fact that we don't have to determine a location relative to "absolute" landmarks. The shot falls *always* inside a box of known dimensions, with fixed sensors.
The location problem is greatly simplified, and no speed/distance calculation is required at all.
The first detection event becomes the "reference" point, and the remaining delay ratios is all that is needed. Speed of sound etc. is entirely irrelevant for the target box problem.
Atmospheric effects can be practically ignored- as the same point inside the box will have the same *relative delay ratio coordinates* regardless of what the *actual delay times* are.
As long as the speed of sound/shock wave is the same (regardless of what it is) for all four sensors, we are o.k.
Steve
The problem is greatly simplified by the fact that we don't have to determine a location relative to "absolute" landmarks. The shot falls *always* inside a box of known dimensions, with fixed sensors.
The location problem is greatly simplified, and no speed/distance calculation is required at all.
The first detection event becomes the "reference" point, and the remaining delay ratios is all that is needed. Speed of sound etc. is entirely irrelevant for the target box problem.
Atmospheric effects can be practically ignored- as the same point inside the box will have the same *relative delay ratio coordinates* regardless of what the *actual delay times* are.
As long as the speed of sound/shock wave is the same (regardless of what it is) for all four sensors, we are o.k.
Steve
Hi Richard,
Here's my 2 cents:
1. Draw a straight line between 2 sensors.
2. Place a point in the middle and move it towards the sensor with the earlier return, so the path difference = the clock differential (if the difference is larger than the distance between the two sensors, you're in trouble!).
3. Add a small delta time to both distances and solve the triangle (sensor 1 to sensor 2 to the impact point. This will give 2 points on either side of the 1st point.
4. Repeat 3 until you have defined the locus of possible locations of the shot from the two sensors.
5. Pick another combination of sensors, and repeat 1 to 4.
6. Find where the lines cross, or the minimum separation of points from multiple combinations of 4 sensors, and you've got it.
This is pretty much what GPS does. Although you only need 3 sensors for a planar solution, the 4th will give you depth as well. Note that you are also solving for impact time, because you don't know when the actual impact took place.
I'd look up the solution used in modern GPS receivers, you might find just what you need. Here's a page I found that has a solution: http://www.teli.us/GPS_PosSol2.htm.
Good luck!
Steve.
Here's my 2 cents:
1. Draw a straight line between 2 sensors.
2. Place a point in the middle and move it towards the sensor with the earlier return, so the path difference = the clock differential (if the difference is larger than the distance between the two sensors, you're in trouble!).
3. Add a small delta time to both distances and solve the triangle (sensor 1 to sensor 2 to the impact point. This will give 2 points on either side of the 1st point.
4. Repeat 3 until you have defined the locus of possible locations of the shot from the two sensors.
5. Pick another combination of sensors, and repeat 1 to 4.
6. Find where the lines cross, or the minimum separation of points from multiple combinations of 4 sensors, and you've got it.
This is pretty much what GPS does. Although you only need 3 sensors for a planar solution, the 4th will give you depth as well. Note that you are also solving for impact time, because you don't know when the actual impact took place.
I'd look up the solution used in modern GPS receivers, you might find just what you need. Here's a page I found that has a solution: http://www.teli.us/GPS_PosSol2.htm.
Good luck!
Steve.
-
Steve Swartz
Tenex:
Great idea to think of the problem in terms of a "graphical solution." Consider: if there is no time delay between sensors (simultaneous event) the shot obviously fell in the exact center of the box.
Now assume that three sensors recorded simultaneous events, and the fourth experienced a delay. Obviously, the shot fell somewhere equidistant from the three sensors, and closer to (signal early) or further away from (signal late) the fourth one. ["Equidistant from three points" suggests something important]
The third scenario is the case where the event occured simultaneously at two sensors, with some offset from the other two. Again, the shot fell on a line equidistant from the two sensors, and at a point along the line that satisfies the ratio of offset between the other two sensors. This also suggests something important about the only feasible solution.
In any case, you could plug in any arbitrary (but reasonable) value for the speed of sound/shock wave, and any arbitrary (but reasonable) value for a "earliest reference event" and the true value of where the shot landed would simply be the center of the box formed by the four arc-distance intersection points.
Steve
Great idea to think of the problem in terms of a "graphical solution." Consider: if there is no time delay between sensors (simultaneous event) the shot obviously fell in the exact center of the box.
Now assume that three sensors recorded simultaneous events, and the fourth experienced a delay. Obviously, the shot fell somewhere equidistant from the three sensors, and closer to (signal early) or further away from (signal late) the fourth one. ["Equidistant from three points" suggests something important]
The third scenario is the case where the event occured simultaneously at two sensors, with some offset from the other two. Again, the shot fell on a line equidistant from the two sensors, and at a point along the line that satisfies the ratio of offset between the other two sensors. This also suggests something important about the only feasible solution.
In any case, you could plug in any arbitrary (but reasonable) value for the speed of sound/shock wave, and any arbitrary (but reasonable) value for a "earliest reference event" and the true value of where the shot landed would simply be the center of the box formed by the four arc-distance intersection points.
Steve
Hey Steve,
I'm much better at geometry than algebra, so I like to visualize the geometry before I write any equations.
I'd like to claim credit, but this is the way GPS works, more or less. All the satellites transmit a reference signal at the same time (from known positions encoded in their data messages), and the receiver measures the differential time of arrival and solves for the distance to all the satellites (and the resultant geometric nav solution).
At roughly a nanosecond per foot, no GPS receiver (that most people can afford) has the timing accuracy to do anything other than differential time measurements between data received from the various satellites. As a result, you can't measure range (time) directly, you have to solve for it. Since you don't know when the shot went off, you're in the same boat. That's why you need 4 measurements to solve a 3 dimensional problem, because you're solving for time as well.
The upside is that a GPS receiver is the most accurate clock you can buy (because you not only solve for the time, you correct for propagation delay from the satellites), and you could also figure out to the accuracy of your clock what time you actually fired the shot (we could use this in our timed and rapid fire bullseye matches!).
Steve.
P.S. The GPS solutions are in 3d space, so the locus of possible locations from two sensors is a surface, not a line. Where 3 surfaces cross is your nav solution. This is where I really start to get a headache...
I'm much better at geometry than algebra, so I like to visualize the geometry before I write any equations.
I'd like to claim credit, but this is the way GPS works, more or less. All the satellites transmit a reference signal at the same time (from known positions encoded in their data messages), and the receiver measures the differential time of arrival and solves for the distance to all the satellites (and the resultant geometric nav solution).
At roughly a nanosecond per foot, no GPS receiver (that most people can afford) has the timing accuracy to do anything other than differential time measurements between data received from the various satellites. As a result, you can't measure range (time) directly, you have to solve for it. Since you don't know when the shot went off, you're in the same boat. That's why you need 4 measurements to solve a 3 dimensional problem, because you're solving for time as well.
The upside is that a GPS receiver is the most accurate clock you can buy (because you not only solve for the time, you correct for propagation delay from the satellites), and you could also figure out to the accuracy of your clock what time you actually fired the shot (we could use this in our timed and rapid fire bullseye matches!).
Steve.
P.S. The GPS solutions are in 3d space, so the locus of possible locations from two sensors is a surface, not a line. Where 3 surfaces cross is your nav solution. This is where I really start to get a headache...
tenex wrote:
"That's why you need 4 measurements to solve a 3 dimensional problem, because you're solving for time as well."
This will come as a nasty shock to those using 300m EST with only three detectors (microphones) - it's a 2 dimensional problem with shot locations with x.y coordinates.
Spencer
"That's why you need 4 measurements to solve a 3 dimensional problem, because you're solving for time as well."
This will come as a nasty shock to those using 300m EST with only three detectors (microphones) - it's a 2 dimensional problem with shot locations with x.y coordinates.
Spencer
-
Steve Swartz
Rutty, I think what Spencer and I are saying is that you don't really need the d + 1 because you don't need to solve for time on a fixed location, fixed size, sensors at known, exterior points.
The four-sensor design is actually "overspecified" but potentially adds some precision, if not reliability.
I wonder what the software does if the four sensors return an infeasible result . . . issue some kind of error code, I hope!
Or perhaps (as I alluded to earlier) the software just calculates the centroid value, in which case the errant sensor has just as much to say about it as the other three . . .
Steve
The four-sensor design is actually "overspecified" but potentially adds some precision, if not reliability.
I wonder what the software does if the four sensors return an infeasible result . . . issue some kind of error code, I hope!
Or perhaps (as I alluded to earlier) the software just calculates the centroid value, in which case the errant sensor has just as much to say about it as the other three . . .
Steve
Argh! Steve and I agreeing?
(sorry Steve - gets back to the sights/triggering/follow-through process!)
four sensors allows the 'system' to resolve ambient speed of sound, an error correction routine (yes, the SA system will return an error result - even if in the very rare occurence), and/or bullet diameter.
Three sensors as in the SA 300m EST targets also gives an ambient speed of sound result.
Spencer
(sorry Steve - gets back to the sights/triggering/follow-through process!)
four sensors allows the 'system' to resolve ambient speed of sound, an error correction routine (yes, the SA system will return an error result - even if in the very rare occurence), and/or bullet diameter.
Three sensors as in the SA 300m EST targets also gives an ambient speed of sound result.
Spencer