rlk@telesoft.com (Bob Kitzberger @sation) (03/30/91)
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?
2. Laser detection. Admittedly high-cost/complexity, this approach would
use a laser pointed down at the box, with stepper motors to deflect
X/Y mirrors, and hence deflect the laser position. As the laser
bounces off of the ball bearing, it would be sensed by a sensor mounted
next to the laser's 'head'.
Problems: incident angle of laser light on a round ball bearing; source
for inexpensive (<$100) laser setup, including relatively accurate
positioning mechanism. Fun, though ;-)
3. Matrix of 'energized' wires, detecting a magnetized ball in a manner
similar to core memory devices. These wires would be equally spaced,
under the surface that the ball rolls on, parllel to both X and Y axis.
This seems like it would work, but nobody here has a strong enough
electrical background to tell me how to detect when the ball rolls
over one of these wires.
4. Hundreds of Hall-effect switches under the surface that the (magnetized)
ball rolls on. Distasteful soluution, in my mind, due to the cost of
hundreds of Hall-effect switches, and the drudgery of soldering them
all onto a PC board 1x1 feet. Anybody have a source for _cheap_
hall effect switches?
5. Video camera mounted above. Perform pattern recognition for a ball bearing.
Just kidding! I know this option is silly.
That's it. Thanks for any help!!
.Bob.
--
Bob Kitzberger Internet : rlk@telesoft.com
TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk
5959 Cornerstone Court West, San Diego, CA 92121-9891 (619) 457-2700 x163
------------------------------------------------------------------------------
"Wretches, utter wretches, keep your hands from beans!" -- Empedocleswhit@milton.u.washington.edu (John Whitmore) (03/31/91)
In article <1225@telesoft.com> rlk@telesoft.com (Bob Kitzberger @sation) writes: >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. This is similar to the magnetic-suspension problem (solved by Jesse W. Beams, in the era of vacuum tubes) for an ultracentrifuge. The rotor is held up by a magnet, and it is necessary to sense the distance to the rotor so the magnetic field can be adjusted (by a feedback loop). Though I don't know how relevant the solution is to your situation, it was done by measuring the capacitance change of a pair of plates near the rotor; a conductor inserted into a capacitor raises the capacity (and lowers the frequency of the attached oscillator). The position detector was an FM detector. To make a 2-dimensional version, you will need to make at least two oscillators (at very different frequencies, so the one doesn't affect the other), attaching one to the N and W sides of your box, the other to the S and E sides. Calibrating the thing will be a task. If you know someone with good skills at conformal mapping, you can probably find some electrode shapes/placements that simplify the problem. Parenthetically, I didn't like the Hall sensor approach; the Hall sensors are polarity-dependent, and a rolling ball will swap poles a LOT. Descrambling the resulting info will not be easy. John Whitmore
ahill@hpdmd48.boi.hp.com (Andy Hill) (04/01/91)
As stated, the problem is a bit too fuzzy still. Could you give us more
details? (such as):
1) How big is the ball bearing? (i.e., weight & diameter).
2) What kind of resolution are you looking for?
3) How "real time" do you want it? (i.e., what is the maximum velocity of
this ball?)
Andymurray@sun13.scri.fsu.edu (John Murray) (04/01/91)
In article <1225@telesoft.com> 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? Standard solution: put the phototransistors down an inch or two of tube. Depending on how professional you want it to look, you could probably use black-painted soda straw... You don't *have* to put the leds down tubes, but you might want to, to even up the acreage chewed up around the box. Anyway, this is your cheapest solution. |5. Video camera mounted above. Perform pattern recognition for a ball bearing. | Just kidding! I know this option is silly. Silly? What's so silly about it? ;-) (paint the floor black and the ball white, and it's a piece of cake.. with a fast enough computer..) |That's it. Thanks for any help!! | | .Bob. |-- |Bob Kitzberger Internet : rlk@telesoft.com |TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk |"Wretches, utter wretches, keep your hands from beans!" -- Empedocles -- *Standard Disclaimers Apply*| ---Get Out Of HELL Free!--- John R. Murray |The bearer of this card is entitled to forgive murray@vsjrm.scri.fsu.edu |Himself of all Sins, Errors and Transgressions. Supercomputer Research Inst.| -- D. Owen Rowley
rainer@boulder.Colorado.EDU (Rainer Malzbender) (04/01/91)
I missed the original post, but I think I understood the question. I
have done an experiment which solved a similar problem. For
my thesis I did an experiment in 2D melting with lots of little steel
spheres rolling around in a hexagonal arena (~1000 particles). I used
a video camera and image processing system (Imaging Technology, Sun)
to capture sequential video frames (oh yeah, I left out the nice
optical video disk recorder) which were later analyzed. One of the
things I did was track all the particles from frame to frame. Thus, I
can verify that the suggested video solution in fact works, at least
for motions which are relatively slow compared to a video frame time.
The criterion is that the particles not move enough during a frame
time to cause confusion with neighboring particles. I just did a
local search around the previous frame's position of each particle to
find where it had moved to, and it worked. More sophisticated ideas
include minimizing the sum of the squares of all possible interparticle
distances, but this is considerably more computationally intensive.
The experiment had light sources at an angle, like this:
Light
\ /
\ /
\/ o o o (balls)
-------------------------------------
(substrate = mirror)
which meant that a video camera located directly overhead only saw
light reflected from the spheres, not the lower mirror surface (we used
a mirror for flatness); the specular reflections went off to the side.
We were interested in obtaining accurate velocities, and hence looked
into doing better than video rate resolution. Our idea was to use a
laser bouncing off two piezo-controlled mirrors (x and y) which would
bounce off the sphere and be detected with a photodiode. Using
feedback one should be able to keep the beam on the sphere, and the
control signals going to the piezo mirrors give a direct readout of
position. Unfortunately we never actually got around to implementing
this, and I think the optics of the spherical reflection would be
pretty tricky, but it ought to work.
--
Rainer Malzbender Save a dinosaur - buy DEC.
Dept. of Physics (303)492-6829
U. of Colorado, Boulder rainer@boulder.colorado.edu 128.138.240.246jbm@eos.arc.nasa.gov (Jeffrey Mulligan) (04/02/91)
rlk@telesoft.com (Bob Kitzberger @sation) writes: [ statement of problem deleted ] > 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? It is not clear whether the problem with dispersion is the absolute sensitivity of the detectors, or crosstalk between emmitter-detector pairs. If the latter is the case, you can solve it by modulating the emitters at non-harmonically related (high) frequencies, and decoding all of the frequencies at each detector. (You could reduce the number of detectors also.) This would probably be a fair amount of circuitry; you haven't said what your budget is, or what accuracy is required. I don't think the video camera solution is so ridiculous, especially if you are allowed to paint the surface flat black and the ball flat white. There are video-based pupillometers and pupil-based eye trackers that work simply by thresholding the video signal and comparing with a timer. You don't have to digitize and number crunch pixels to use video. -- Jeff Mulligan (jbm@eos.arc.nasa.gov) NASA/Ames Research Ctr., Mail Stop 262-2, Moffett Field CA, 94035 (415) 604-3745
nagle@well.sf.ca.us (John Nagle) (04/02/91)
Your first solution, LEDs and photosensors, will work if you modify it
slightly. Touchscreens often use such a setup, and you may even be able to
buy a touchscreen frame for a big monitor adn use it directly. But they
don't work by using collimated beams. They work by having only one LED on
at a time, and ignoring all but one photosensor at a time. Cycle times
can be in the kilohertz range; LEDs turn on and off fast.
Some commercial manufacturers of touchscreens are
Mantex Corp (Rep: Westech sales, 415-961-1422)
Tektronix (Rep: Ross Markeging, 408-988-8111)
Transparent Devices Inc (Rep: Richards Assoc, 408-297-3010)
They may not use beam-interruption technology, but the reps will probably
know who does.
The TV camera approach is of course feasible. If you don't want to
bother with a computer and frame grabber, you could probably do the image
processing by building suitable circuits out of a sync extractor chip,
some comparators, and a few op-amps. The National Semiconductor
LM1881 is a cheap sync extractor. You could also use the LM1880
no-holds vertical/horizontal TV sync processor to generate H and
V ramps, and then use a comparator on the video signal to detect
the object. When the object goes by, feed the appropriate ramps
to V and H sample-and-holds and thence (assuming the desired
output is digital) to A/Ds. See the National special-purpose
linear databook for specs on these parts. For the op-amps and
comparators, I use MC34002 op-amps, LM311N comparators, and
LM733CN video amps; one can do better, but these are easily
available jellybeans.
Now tell us what you're building.
John Naglejwatts@hpihoah.cup.hp.com (Jon Watts) (04/03/91)
/ hpihoah:sci.electronics / rlk@telesoft.com (Bob Kitzberger @sation) / 9:48 pm Mar 29, 1991 / >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? Don't use so many LEDs. Just use one in the northwest corner and one in the Northeast corner and photo transistors on the west, south and east sides. The LED can be lighted alternately. The NW LED should illuminate S and E sides. The NE LED should illuminate S and W sides. Set the LED frequency and phototransistor sample rate to met your time resolution requirements, set the spacing of the photo transistors to met your spatial resolution requirements. If the accuracy degradation when the ball approaches the LEDs is unacceptable use four LEDs one in each corner and double your frequency. All the position decoding can be done in software unless you need to be very fast. Jon Watts Hewlett-Packard jwatts@mothra.rose.hp.com
rlk@telesoft.com (Bob Kitzberger @sation) (04/04/91)
Thanks for everyone's help on this! USEnet comes through once again... Many have responded via e-mail, and I'm still wading through it all (this project is done in my 'copious' spare time ;-) so if I neglect to send my thanks individually... THANKS. The 'best fit' to budgetary and time constraints seems to be to go with the LED and phototransistor pairings, but, as several folks have pointed out, STROBE the LEDs one at a time to remove the dispersion problem. Thanks much for that idea (looks obvious in hindsight ;-) If I can't get this to work (can't see why not) then I'll try a video approach (gulp). Andy Hill writes: > > As stated, the problem is a bit too fuzzy still. Could you give us more > details? (such as): > > 1) How big is the ball bearing? (i.e., weight & diameter). This is flexible, though I'd like to keep it in the 1/4" to 3/4" diameter. > 2) What kind of resolution are you looking for? 1/4 the width of the ball, approximately. This really depends on the velocity and acceleration of the ball, and hence resolution of the velocity vector. I haven't figured out the physics of this application yet. > 3) How "real time" do you want it? (i.e., what is the maximum velocity of > this ball?) Not very fast... maybe 1-10 inches per second. Rainer Malzbender writes: > [whizzy video camera controller setup. neat] I should have mentioned that I don't want to spend more than $100 total for this portion of the project. > We were interested in obtaining accurate velocities, and hence looked > into doing better than video rate resolution. Our idea was to use a > laser bouncing off two piezo-controlled mirrors (x and y) which would > bounce off the sphere and be detected with a photodiode. Using > feedback one should be able to keep the beam on the sphere, and the > control signals going to the piezo mirrors give a direct readout of > position. Unfortunately we never actually got around to implementing > this, and I think the optics of the spherical reflection would be > pretty tricky, but it ought to work. I spent a little time experimenting with a laser (from R&D Electronics) that had a stepper-motor controlled mirror on the x axis, and a fixed mirror on the y. $79 (the Right Price). Not nearly accurate/steady enough, and the stepper motor moved the laser much too far at each step (piezo is probably a must here). But the idea was quite exciting, more so than any other idea. I was also concerned, as you point out, about the spherical reflections... the incident angle would have to be very close to zero to deflect the laser properly, no? This means a very small laser step rate. Again, thanks for all of the help. Several of you were interested in the results, so I'll post a follow up. .Bob. -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Court West, San Diego, CA 92121-9891 (619) 457-2700 x163 ------------------------------------------------------------------------------ "Wretches, utter wretches, keep your hands from beans!" -- Empedocles
rlk@telesoft.com (Bob Kitzberger @sation) (04/05/91)
nagle@well.sf.ca.us (John Nagle) writes: > > Now tell us what you're building. Remember those 'labyrinth' games of your/my/our childhood? One knob to control the tilt along one axis, another knob for the other. One metal ball rolling through this tilting maze, falling into holes and causing much grief. Replace the knobs with stepper motors, replace your visual system with LEDs and phototranistors, a device to pick up the ball and place it at the beginning of the maze, and write some magic software to control it all ;-) The system starts out without any knowledge of the holes or walls, and learns over time what the layout is. Step one is getting the hardware hooked up and controllable by a parallel port, all the while keeping step 2 in the back of my mind. Step two is, um, a 'rather ambitious' software task, I'm afraid. Thankfully, this doesn't really _have_ to work. It's for 'fun' ;-) Thanks for your help & addresses/part numbers, .Bob. -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Court West, San Diego, CA 92121-9891 (619) 457-2700 x163 ------------------------------------------------------------------------------ "Wretches, utter wretches, keep your hands from beans!" -- Empedocles
davet@tsdiag.ccur.com (Dave Tiller N2KAU) (04/05/91)
In article <1225@telesoft.com> 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.
Instead of looking across the box, try looking up through the bottom.
Affix phototransistors on the bottom of the box (made of plexiglas) so
that when the ball rolls over the sensor, it temporarily blocks the light.
This eliminates several of the problems associated with the side-looking
method, such as multiple signals when the ball is near the side opposite the
sensors.
--
David E. Tiller davet@tsdiag.ccur.com | Concurrent Computer Corp.
FAX: 201-870-5952 Ph: (201) 870-4119 (w) | 2 Crescent Place, M/S 117
UUCP: ucbvax!rutgers!petsd!tsdiag!davet | Oceanport NJ, 07757
ICBM: 40 16' 52" N 73 59' 00" W | N2KAU @ NN2Zdeanr@sco.COM (Dean Reece) (04/06/91)
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
jimwy@amtfocus.amt.gss.mot.com (Jim Wygralak) (04/08/91)
nagle@well.sf.ca.us (John Nagle) writes: > Now tell us what you're building. > John Nagle If I were to venture a guess, I'd say he's trying to build a machine that will play 'Labrynth'. You know the game with the table that tilts on 2 axis and you have to guide a marble around obstacles by controlling the tilt of the table. ---------------- Jim Wygralak KA9LTY
hp@vmars.tuwien.ac.at (Peter Holzer) (04/12/91)
hbg6@citek.mcdphx.mot.com writes: >In article <11206@scolex.sco.COM> deanr@sco.COM (Dean Reece) writes: >> >>rlk@telesoft.com (Bob Kitzberger @sation) writes: >>>5. Video camera mounted above. Perform pattern recognition for a ball bearing. >>> Just kidding! I know this option is silly. >It's not silly and it's not really THAT complicated. Take the video signal >from the camera. A simple circuit will give you horz. and vert. sync >signals. Attach a counter to the H. Sync that resets to zero on V. Sync. >Also attach a timer ( counter + timebase ) that is reset by the H. Sync. >pulse. The last piece is a comparitor watching the video signal, set to >trigger when the sillouete of the ball is encountered, and enabled by the ^^^^^^^^^ Don't see how you can recognize the silhouette of a ball with a comparator. You can find the first pixel that is lighter or darker than a certain threshold that way. If you want the computer to play labyrinth you would need a black labyrinth (so that the black holes won't show) and you have to make sure that the camera sees only the labyrinth (so your comparator doesn't take the light table for the ball). I am working on a similar project, and the setup we have now (12MHz AT with frame grabber card) is much too slow to do serious pattern recognition in real-time. I can't do much more than find the nearest dark spot to the last ball position and check if it doesn't exceed a certain size. If there are lines or holes on the plane it will eventually find these instead of the ball. I am now looking for signal processors to get the necessary performance. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
whit@milton.u.washington.edu (John Whitmore) (04/13/91)
In article <2404@tuvie.UUCP> hp@vmars.tuwien.ac.at (Peter Holzer) writes: >hbg6@citek.mcdphx.mot.com writes: > >>In article <11206@scolex.sco.COM> deanr@sco.COM (Dean Reece) writes: >>> >>>rlk@telesoft.com (Bob Kitzberger @sation) writes: >>>>5. Video camera mounted above. Perform pattern recognition for a ball bearing. >>>> Just kidding! I know this option is silly. > >>It's not silly and it's not really THAT complicated. ... >>trigger when the sillouete of the ball is encountered, and enabled by the > ^^^^^^^^^ Don't see how you can recognize the >silhouette of a ball with a comparator. You can find the first pixel >that is lighter or darker than a certain threshold It should be a LOT easier than pattern recognition; remembering that a convex mirror produces a virtual image, just use a point source illuminator and put the polished ball in a black environment. The image of the light source will be a tiny point inside the ball. John Whitmore
alex@vmars.tuwien.ac.at (Alexander Vrchoticky) (04/17/91)
whit@milton.u.washington.edu (John Whitmore) writes: >>silhouette of a ball with a comparator. You can find the first pixel >>that is lighter or darker than a certain threshold > It should be a LOT easier than pattern recognition; remembering >that a convex mirror produces a virtual image, just use a point source >illuminator and put the polished ball in a black environment. The >image of the light source will be a tiny point inside the ball. > it sure is easier. but it does not solve the problem. not unless you are willing to turn an entire lab into a dark-room. -- Alexander Vrchoticky | alex@vmars.tuwien.ac.at TU Vienna, CS/Real-Time Systems | +43/222/58801-8168 "at the end of the day i guess you are what you eat" (monie love)
mike@ymt.com (Michael Czeiszperger) (04/23/91)
hp@vmars.tuwien.ac.at (Peter Holzer) writes: >I am working on a similar project, and the setup we have now (12MHz AT >with frame grabber card) is much too slow to do serious pattern >recognition in real-time. I can't do much more than find the nearest >dark spot to the last ball position and check if it doesn't exceed a >certain size. If there are lines or holes on the plane it will >eventually find these instead of the ball. I am now looking for signal >processors to get the necessary performance. There's an interesting book out called A Robot Ping Pong Player which describes a real time vision system that can detect a ping pong ball and hit it back. It is suprisingly capable, able to accurately judge not only trajectory, but spin as well. They used a four camera (Hitachi KP-231A) depth perception system coupled with a custom VLSI moment generator chip to track the ball. The book is by Russell L. Anderson of the Robotics Systems Research Department of AT&T Bell Labs, and available from the MIT press ISBN 0-262-01101-8. -- Michael Czeiszperger | "I'm trying to teach a caveman to play scrabble mike@ymt.com | but the only word he is knows is 'uugh', and he Greenbrae, CA | doesn't know how to spell it!"