T&L Publications

For those who saw my earlier post "Senior Design Project Ideas". I think the search is over
One of the college professors has an idea to build a robot that would gather tennis balls on a court. It sounds simple at 1st. The easiest would be to just make it travel in random directions until it hits something (like a pool cleaning robot). From that point on I can think of multiple level of improvement.
I am starting some basic research now.
I would like to find out how hard would it be to incorporate simple image recognition (see a tennis ball on the ground).
Do any of you know any links that explain the basics of image recognition?
What kind of output would a digital camera provide? how can that be interfaced to a microcontroller for analysis?

Do a google search for cmucam. Then, go hear and scroll way down and check out the videos:
http://www.cs.cmu.edu/~cmucam/gallery.html<p>Pretty slick stuff. Good at detecting colorful objects on neutral backgrounds. It would be interesting to see how it picks up (visually) ping pong balls.<p>I think you'll find lots of information. If you're not a programmer, I highly recomend Python. It has the PIL (Python Imaging Library) which is an *excellent* imaging library. Python is very easy to learn as well.

You can also use sonic recognition. <p>If soft objects are the issue, ultrasound can detect open space VS soft objects quite well.<p> Same goes for optics, there was a light detector many years back that watched TV screens, and solid objects as opposed to a blank screen had a contrast ratio that was different, and that set off the sensors, bells and whistles. <p>And it didn’t use any soft ware?

In the Microsoft DirectX 8.0 and later SDK there is sample source code for AMCAP.EXE that will capture and display live video from USB cameras. You can get a pointer to its buffer and snag a bitmap copy to compare with your sample or look for a cluster of yellow etc.

If you can control the lighting level and the selection of colors, color tracking with the CMU Cam will work quite well.<p>As a matter of fact, the Sumo11 version of the MiniSumo Mark III robot uses Interactive C and there is a library for handling the camera including the chasing of blue or orange balls.<p>The Sumo11 is based on the Freescale 68HC11 processor which is not one of the high end processors. Nevertheless, borrow the library source and stuff it into a faster processor like the Atmel ATmega128. See www.1sorc.com and follow some of the links for more info on Interactive C.<p>I have one of these bots and it is quite nice.

Tennis balls are yellow aren't they? And the background of a tennis court is clay that's either brown, gray, or green. Yellow is a peculiar color of high intensity second only to white.<p>I see a lot of high-tech sequential mousetraps where simpler ones or no sequential mousetrap is needed at all. This is what could be done...
(even without a PC)<p>Drive a CCD camera chip with your program, at below-normal speed if necessary, copying the image into RAM. <p>Or if you can, devise a way of examining pixels directly from a live color video camera.<p>I can think of more ways.<p>Program the robot to "focus on one ball at a time", being aware of other balls, but in one moment, move so that a ball remains in the center of the image. If it's yellow, it's a ball. If it's yellow and not a ball, figure that out later. SO the robot looks around until there are yellow pixels in it's field (high R+G, low B) and goes after the one closest to the middle by advancing and adjusting so that the ball remains in the center of the video image. Eventually it's Eye will be on the Ball. Then it takes it. Then it resets and looks around for more balls. If it doesn't find more it shuts down.

Does your school have MatLab? Right now I am using MatLab for my own image recognition purposes. Mine uses a stationery camera though. I don't know how it will work mounted to a moving robot, but it is probably still feasible. (or perhaps use a camera mounted above the court that sends a signal where the robot should go). Anyway, if you are interested, and its available, look in the help file under Image Acquitition Toolbox and the Image Processing Toolbox. Also in the help is something about Embedded Target for MotorolaHC12 and other processors, which would be useful. <p>The way mine works is that first a blank image is taken (for you it would be the tennis court without any tennis balls). Then, you take the image with the tennis balls. The colors are then subtracted from the two images so that all it then sees is the tennis balls. This is then converted to a binary image and each tennis ball would then be recognized as a different numbered object. By painting the top of your machine with a different color you could have MatLab, (or a processor I assume) keep going to the closest object.<p>All this said, I agree with Chris Smith about using sonic methods along with programming a back and forth motion across the court rather than completely random as in the Roomba case. That seems more practical.