Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!sco!deanr
From: deanr@sco.COM (Dean Reece)
Newsgroups: sci.electronics
Subject: Re: X-Y detection of moving metal ball?
Message-ID: <11206@scolex.sco.COM>
Date: 5 Apr 91 19:47:56 GMT
References: <1225@telesoft.com>
Sender: news@sco.COM
Lines: 100


rlk@telesoft.com (Bob Kitzberger @sation) writes:


>Hi All,

>I've got a 'pet project' problem that is generating a lot of ideas among
>colleagues at work, but NO concrete solutions.  (concrete solution ==
>part numbers and source for parts ;-)  

>And no, this isn't a school project ;-)

>Problem: I want to detect the X and Y coordinates of a metal ball bearing
>(magnetized or not) in motion within a box.  The data collection must
>occur in a fashion that allows me to derive the velocity vector of the ball
>bearing in the X-Y plane.  The size of the box is approximately one foot by one
>foot.  Also, I should mention that the detection must occur in real-time.

>We have a few ideas so far, but all of them use parts which are, to me,
>hypothetically available.  I would appreciate any other ideas, or even
>more importantly, sources for these 'hypothetical' parts.

>1. Array of LEDs and corresponding phototransistors, one array for the
>   X direction and one for Y:

>        +-L-L-L-L-L-L-L-+
>        |               |
>        L               P
>        |    B          |               L = LED
>        L               P               P = phototransistor
>        |               |               B = Ball
>        L               P
>        |               |
>        +-P-P-P-P-P-P-P-+

>    The idea is to detect when the ball bearing breaks the light path for
>    a L/P combination.  The timing between light path breaks allows
>    determination of the velocity vector.

>    This is my cleanest solution, but I haven't been able to find a source
>    for the LED/phototransistor pairs that won't disperse over the 
>    distance involved (one foot).  Ideas/sources?

I've thought about doing the same type of thing, but putting the
detectors in a picture frame around a CRT for el-cheapo touch screen.

After a little experimentation, I found that regular IR LEDs and
Phototransistors (or Photodiodes).  The trick is to scan the LEDs
so that only one is on at a time.  Then check the Photodevice
directly across from the LED you've turned on.  All you need is a
go/no-go indication, so perhaps a linear threshold detector would
be good enough (though ambient IR could cause it to false trigger)

To increase reliability (reduce false triggering) you should modulate
the scanning LEDs at some frequence (say 40khz, like remotes).  To
save wiring (though increase cost) you could then use the Radio Shack
IR detector Module.

The only other enhancement I could think of would be to add some
logic (probably a MicroProc) to look at the output of not only the
adjacent photodetector, but the outputs of the ones to either side.
If one was on, but not the other, then you could say the ball was
'between' two detectors and double your resolution without adding
much complexity to the optical rig.

If you wanted to minimize the number of detectors and have lots-o-LEDs
(perhaps cheaper), then try putting 1 detector in each corner (do they
have a 90 degree acceptance angle?) and line all 4 sides with LEDs.  Run
around the perimeter flashing 1 LED at a time and see which Detectors
can see it.  With a little Triangulation Software you should have
pretty good resolution (though perhaps not uniform enough to derive
good velocity & acceleration data from)

>2. Laser detection.  Admittedly high-cost/complexity, this approach would
yep, I agree

>3. Matrix of 'energized' wires, detecting a magnetized ball in a manner
Making a PC board as a sensor array could work pretty well (perhaps your
best chance at getting good resolution pretty cheaply)

>4. Hundreds of Hall-effect switches under the surface that the (magnetized)
Nope, too much stuff to mount...

>5. Video camera mounted above.  Perform pattern recognition for a ball bearing.
>   Just kidding!  I know this option is silly.
Not really silly.  Think about using back-lit frosted plexiglass as the table
and have some simple software doing diff's (xors) on subsequent frames.  The 
number of pixels remaining would be a relatively good indication of the
velocity (the area of the difference from frame to frame).  You could also
find the 'center of mass' of the remaining pixels and use this as your ball
location.  Given the X-Y coordinates, the rest is fairly easy.  If you used
a chrome ball bearing, then you would want to do this in a dark room, though.

>That's it.  Thanks for any help!!

In any event, if you get a good working solution, please post as I
think the solution could apply to a large range problems.

Good luck
-deanr@sco.com