Baseball Pitching Target Project

[mbramble]

I am working on building an electronic baseball pitching target that will record the location the ball passes through an array of laser emitters/photo sensors (16 sensors high, 11 sensors wide). Sensors will be spaced at 2 13/16" (2.81") which is just smaller than a standard baseball so that a ball cannot pass through the matrix without tripping at least 1 horizontal AND 1 vertical sensor. Since the spacing is smaller than a baseball, it is possible that a ball may interrupt up to 4 beams (2 horiz and 2 vert). And with the quickly tested thickness of the beams, it is more than likely that more than one beam per axis will be interrupted per pitch. I need to do more testing there.

At this moment, I am only concerned about getting an X and Y "signal" to the Arduino to "let" it figure out balls, strikes, etc., and whatever outputs I decide to use. Once I feel confident about being able to detect and determine a pitch location, then I will move forward with what to do with that information.

I have designed a circuit which I THINK will ensure that only 1 "output" line goes high for each of the 2 matrix axes. It uses a NAND gate and 2 XOR gates for each "pair" of adjacent sensors. The possible outputs (ONLY 1 at a time) are: neither was tripped, sensor A was tripped, Sensor B was tripped OR they were BOTH tripped. B is then compared with C, C with D, etc., thru all the sensors, both horizontal and vertical (but separate circuits for each axis). With 16 horizontal sensors, there are 31 possible conditions - with only one being allowed to pass thru the logic for processing to input to the Arduino. With 11 vertical sensors, there are 21 possible conditions - with, again, only 1 being processed to make it to the Arduino inputs.

I could have used priority encoders and selected which would have priority if two adjacent beams are interrupted, but I wanted to try it without that which could display the pitch in the wrong spot. Though - it really needn't be this precise but that is my goal at the moment.

The attached file is what I have come up with to "ensure" that only one of the possible 21 vertical conditions goes active, and one of the 31 possible horizontal conditions goes active for each pitch. I did not show the comparison circuits for every sensor, it's all very repetetive. I also only showed a representation of the 16 horizontal sensors. The vertical sensors are connected exactly the same way but there are only 11 sensors.

The 31 horizontal outputs will be fed to a circuit to convert from those 31 lines to 5 binary lines to input to the Arduino.
The 21 vertical outputs will be converted to 5 binary lines for input to the Arduino. The program will determine the spot the pitch came though the target using those two coordinates.

Basically, each of the 31 (and separately, the 21) will be fed to the proper 8 input OR gates to end up with it's associated binary number (output #15 will encode to 01111, output #3 to 00011, etc.) I haven't drawn it up yet but I have completed a table to determine which binary digits each output needs to be wired to. With 31 possibilities, I think it worked out to requiring 2 8 input OR gates, each of which would be fed to a 2 input OR gate -- for each of the 5 binary digits.

What I'm looking for here - does the attached circuit seem like it will work to ensure that for any given pitch, only 1 data line goes HIGH out of the horizontal, and only one goes HIGH out of the vertical circuit?? Is what I described (but haven't drawn yet) sound like a reasonable way to encode from 31 lines to a 5 digit binary number (and from 21 lines to a 5 digit binary)??

Also, if any of this looks good on paper, I'm wondering if I should add a resettable latch to each of the photo sensor lines to lock the state of the pitch while everything has time to process. Just feed the photo sensor output to a latch and once the calculations for a pitch are done, let the Arduino reset the latches...

Any help, comments, etc., would be most appreciated...

 

[mbramble]

I knew about mirroring the A/B interrupts on each MCP23017. That's what I gad set up during my initial tests.

But, just monitoring the two mirrored interrupts sounds great!!. As soon as I get all my lasers/sensors mounted and aligned I'm going to start testing in earnest. Thank you for that great idea!!

 

[Tony Stewart]

I am suspicious this is a complete waste of time without design specs on the optic sensors.
Where are all your physical optical electrical specs? I doubt you have enough sensors to block the corners then I doubt you have the speed to track all the sensors in xxxx microseconds. It's a round ball with a round sensor so you may need > 2 sensors per ball diameter minimum using this method. Perhaps there is a better method.

I doubt you will need "pro" speed, v,= 100 MPH = 4470 cm/s and the MLB baseball diameter d = 2.87 to 2.94 inches (7.29 to 7.47 centimeters) The ball speed may travel its minimum center diameter in d/v=t= 7.29/4470 = 1.6 ms

At an offset of 50% of 2.81" spacing the round sensor laser block time is from zero to some small percent of the time duration. The transfer function of blocking a beam with 45 deg vector on a circular object is cosine-squared but with a thin beam detector in just one axis along the middle it is just the cosine law.

This shows you need twice as many sensors as you have computed to block more than 50% of the incident light assuming 100% is calibrated accurately.

It seems like everyone is assuming your optical design is OK.
which it is not.

I have successfully tested a design of mine which we chose to detect a case of beer in the bottom of any shopping cart using binary coded IR LEDs with a 1m aisle path without false detection of the cart or a skirt.. It could also sense a resistor lead crossing the path using IRDA2 detectors recessed in a narrow aperture with 100 mA IR emitters also recessed.

 

[mbramble]

I am suspicious this is a complete waste of time without design specs on the optic sensors.
Where are all your physical optical electrical specs? I doubt you have enough sensors to block the corners then I doubt you have the speed to track all the sensors in xxxx microseconds. It's a round ball with a round sensor so you may need > 2 sensors per ball diameter minimum using this method. Perhaps there is a better method.

I doubt you will need "pro" speed, v,= 100 MPH = 4470 cm/s and the MLB baseball diameter d = 2.87 to 2.94 inches (7.29 to 7.47 centimeters) The ball speed may travel its minimum center diameter in d/v=t= 7.29/4470 = 1.6 ms

At an offset of 50% of 2.81" spacing the round sensor laser block time is from zero to some small percent of the time duration. The transfer function of blocking a beam with 45 deg vector on a circular object is cosine-squared but with a thin beam detector in just one axis along the middle it is just the cosine law.

This shows you need twice as many sensors as you have computed to block more than 50% of the incident light assuming 100% is calibrated accurately.

View attachment 141678

View attachment 141679

It seems like everyone is assuming your optical design is OK.
which it is not.

I have successfully tested a design of mine which we chose to detect a case of beer in the bottom of any shopping cart using binary coded IR LEDs with a 1m aisle path without false detection of the cart or a skirt.. It could also sense a resistor lead crossing the path using IRDA2 detectors recessed in a narrow aperture with 100 mA IR emitters also recessed.

Firstly, even if it never works, I don't consider it a waste of time since I'm learning a lot. Old people need to use their brains to keep them functioning And the costs involved to this point are minimal.
I can throw a ball as hard as I can from 4-5 ft away and "most of the time" both the X anY coordinates will register. I would assume that those times where they don't are due to not having more sensors close enough together. It had not crossed my mind that the further from the center of the ball, the less time the sensor is cut off from the light and that a round ball through a square hole might slip through completely unnoticed. . That makes perfect sense and I can't believe I never thought of that.
I am currently using the 2 Arduino hardware interrupt pins to monitor the mirrored AB interrupts from two MCP23017s. The interrupt service routines do nothing but set a flag to indicate an interrupt has occurred on that particular MCP23017. The loop routine doesn't do much until/unless both those flags have been set. Doubling the sensors would mean adding 2 more MCP23017s and moving to my Mega to have the additional interrupt pins available. Will monitoring 4 interrupts bring everything to a screeching halt because there just isn't enough time as the ball travels through?? I don't know!! But I will certainly be giving it a try...
Thank you very much for your comment! It has given me something else to think about and probably answered why there are times when there isn't both an X and Y interrupt - or neither.
If you have a "better method" I am certainly interested in hearing it!

Thanks again!
Mike

 

[Tony Stewart]

I can't suggest a better method yet, but I used very narrow beam IR LED's that spanned many Sharp (now Vishay) IR Rx IC's But each LED was pulse encoded with a number then TDM multiplexed and sent sequentially to all targets but only read by the matching port. The Rx IC lens was recessed with narrow 5mm aperture to reduce the effective zone like a laser beam. Since the IR Rx uses AGC on the peak of these pulses, 50% calibration threshold was not required, it was built-in. Ofcourse daylight filters with black lens are part of the Rx IC.
You may need to check your Rx calibrated thresholds with load resistors and set for the most sensitive threshold. Also I was detecting bigger objects with fewer sensors (8) to detect a shopping cart and above or below the bottom bar for the basket. Also a shopping cart moves slower than a baseball, so your task uses much more bandwidth. Good luck.