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...

 

[Pommie]

This seems over complicated, you just need to know which beams were broken and let the processor do the rest. An ideal solution would be a latching 16 bit I/O expander. A quick google suggest a KTS1622 might meet your needs. You would need two - one for each axis. Once a ball goes through a read (Via I²C) will give 1/2 lines broken in each axis. You can then decide what to do with that information with the processor.

Are you conversant with I²C?

Mike.
Edit, the MCP23008 might be better as available in through hole.

 

[mbramble]

This seems over complicated, you just need to know which beams were broken and let the processor do the rest. An ideal solution would be a latching 16 bit I/O expander. A quick google suggest a KTS1622 might meet your needs. You would need two - one for each axis. Once a ball goes through a read (Via I²C) will give 1/2 lines broken in each axis. You can then decide what to do with that information with the processor.

Are you conversant with I²C?

Mike.
Edit, the MCP23008 might be better as available in through hole.

Thank you very much for your input!! Yes, my idea is 'simply over complicated' but it was the only way I could figure out to get 16 + 11 inputs to the Arduino. I was offloading a relatively simple decision for a microcontroller (which 1 or 2 lines went active on each axis) to logic circuits to compensate for my lack of knowledge about additional ways to get the 'raw' data into the Arduino. I had no idea about port expanders nor I²C!! Time for this old mind to learn some more!

For a little background, I attended the U.S. Navy's Basic Electricity and Electronics course back in 1974! I then spent the next 10-12 years troubleshooting mostly discreet component electronic circuits. As those years went by, more IC based equipment began to show up. Then, life was taken over by paperwork, management and leadership responsibilities... It has been a very long time since I dabbled in any electronics, and probably my first real attempt at designing something. I recently became interested in the Arduino and when the idea of a pitching target came up from my grandson, it seemed like a good chance to jump in!

Thank you again! The biggest purpose for my post was to see if my idea would work - and if there were suggestions for better ways.

 

[tumbleweed]

Edit, the MCP23008 might be better as available in through hole.

If you go down that route, since the 008 is eight-bit you'll need 4 of them for a 16x11 array (there's also an MCP23017 that's a 16-bit part). They're also available as SPI (MCP23S08/S17) in addition to I2C versions, which can be a bit easier to deal with sometimes.

In any case, the MCP23xxx have an INT interrupt pin output but watch out if you try to tie multiple INT pins together. They can be programmed as open-drain outputs, but for some dumb-a** reason they default to push-pull mode so it's possible for them to fight each other until you get them setup.

I've never used it, but that KTS1622 seems like a nice part. Thanks, Mike!

 

[Nigel Goodwin]

For a little background, I attended the U.S. Navy's Basic Electricity and Electronics course back in 1974!

Funnily enough back in 1972 or so, quite bizarrely at college (in the UK) we were given a U.S. Navy Electronics Service Book to work through. Essentially it was multiple choice, and depending on the answer you selected to each question it sent you to another question elsewhere - it was actually a very useful book.

I still recall on page 2 (I think it was 2?) it just said something like "what are you doing reading this page - no where in this book does it tell you to go to this page"

 

[Pommie]

If you're not familiar with I²C then there are lots of examples using the Arduino on the web.
Basically, if using an Arduino then most of the work has allready been done, just include wire.h and set up all the registers as shown in the datsheet of whichever expander you go with.

Good luck and if (when) you get stuck just ask here.

Mike.

 

[mbramble]

If you're not familiar with I²C then there are lots of examples using the Arduino on the web.
Basically, if using an Arduino then most of the work has allready been done, just include wire.h and set up all the registers as shown in the datsheet of whichever expander you go with.

Good luck and if (when) you get stuck just ask here.

Mike.

Thanks! I have spent a good part of the day reading and watching videos. I think I'm beginning to grasp the concepts.

 

[Tony Stewart]

I still recall on page 2 (I think it was 2?) it just said something like "what are you doing reading this page - no where in this book does it tell you to go to this page"

Right opposite the page that says, " This page is intentionally blank"?

 

[Pommie]

Note, you need an expander that has latched inputs. There are a lot available that only have momentary inputs.

Mike.

 

[mbramble]

Note, you need an expander that has latched inputs. There are a lot available that only have momentary inputs.

Mike.

My eyes can't take it anymore!! I have looked and looked and either a device doesn't have input latching or it's in some funky package....

 

[Pommie]

That's why I suggested the microchip part as that's through hole.

Mike.

 

[Nigel Goodwin]

Right opposite the page that says, " This page is intentionally blank"?

Probably it was a long time ago - and when you were already working as a service engineer, and familiar with the concepts in the book, then it didn't take long at all to complete it.

However, I was impressed by the way it worked, and it would obviously be very helpful to a beginner.

 

[mbramble]

That's why I suggested the microchip part as that's through hole.

Mike.

The MCP23008?? I couldn't get any indication from the data sheet that it had input latches available. Also, according to the data sheet, the I2C version has only 7 inputs (which would still be workable).

"GP7 17 16 19 I/O Bidirectional I/O pin. Can be enabled for interrupt-on-change and/or internal weak pull-up resistor.(MCP23S08)/ Output Only (MCP23008)"

 

[tumbleweed]

The MCP parts don't have an input latch per say, but they do have a few registers associated with input capture and interrupts...

Interrupt activity on the port will cause the port value to
be captured and copied into INTCAP. The interrupt will
remain active until the INTCAP or GPIO register is
read. Writing to these registers will not affect the
interrupt.
The first interrupt event will cause the port contents to
be copied into the INTCAP register. Subsequent
interrupt conditions on the port will not cause an
interrupt to occur as long as the interrupt is not cleared
by a read of INTCAP or GPIO.

If you're looking for through-hole parts the MCP23017 comes in a 28-pin DIP pkg.

 

[mbramble]

I just ordered a couple MCP23017s... Thanks guys. I appreciate the help and advice.

 

[tumbleweed]

Since the INTCAP register latches the state when an intr is generated,
you might want to consider alternating the matrix connections between the two eight-bit ports GPA and GPB.

For example, call the 16 horizontal lines A, B, C, D, E, thru P

GPA0 - A
GPA1 - C
GPA2 - E
GPA3 - G
GPA4 - I
GPA5 - K
GPA6 - M
GPA7 - O

GPB0 - B
GPB1 - D
GPB2 - F
GPB3 - H
GPB4 - J
GPB5 - L
GPB6 - N
GPB7 - P

That way, if two adjacent scan lines get triggered they'll be on different ports and get latched.
You can always untangle the connections in code.

 

[Pommie]

you might want to consider alternating the matrix connections between the two eight-bit ports GPA and GPB.

That's a good idea, I'd not considered the situation where one beam get's broken before the second. The second one causing a relatch and "loosing" the first break.

Actually, reading the datasheet it looks like this is the only way it will work as once latched the value remains until the interrupt is cleared - see 3.5.9 in the datasheet.

Note also, the MIRROR bit (register 3.6) enables the two INT pins to be combined.

Mike.

 

[tumbleweed]

Note also, the MIRROR bit (register 3.6) enables the two INT pins to be combined.

Good suggestion. That would allow you to use just two input pins on the arduino (one INTA for horizontal, one INTA for vertical) to signal when a change has been detected. That lets you get around the open-drain INT pin issue I raised back in #4 since there'd be no need to combine them.

 

[mbramble]

I'm back! And haven't given up! I was having issues trying to use a couple lasers and sensors on a breadboard to try and figure out interrupts on the Arduino and MCP23017s. So, decided to go ahead and concentrate on the actual target. I have the frame welded up, drilled for mounting holes, 3D printed mounts for the lasers and sensor modules (waiting on a roll of PETG to arrive tomorrow for one last batch of holders) and have begun putting it together - which is quite a slow process

I've been doing a lot of reading, and a little practical playing around with the interrupts. I've been concerned about trying to trap up to 4 interrupts for each tracked ball (could pass thru 1 OR 2 X beams AND 1 OR 2 Y beams) with all the timing that that entails. While working in the yard just now, it occurred to me that I might be able to just "tie" all the interrupts together and not worry about which of the possible 4 "channels" actually caused it. All the beams are on the same "plane" and it seems to me (haha) that it doesn't matter which interrupt I trap first, they are pretty much gonna interrupt at the same time, up to 4 interrupts.

Can I just tie the interrupts together, have one input routine tied to one Arduino interrupt pin. When it goes active, I could wait a short time and then check the registers on all 4 "channels" (A and B of each MCP23017) to see which inputs have gone active. Then with that information, determine where the ball passed through. Or is that just too easy??

 

[tumbleweed]

Look at posts 17 and 18 again. If you set the MIRROR bit you only need one int line for each MCP23017, so two lines total.

You don't need to use interrupts on the arduino side... just connect the two INT lines from the MCP23017's to two input port pins and poll them in software. If you see either INT asserted then you can read all four INTCAP registers and figure out what's going on.