PDA

View Full Version : Unsolved Sorter using Processor and color camera or Line scanner?



wilsone
03-08-2012, 08:51 AM
Hi All

Google indicated that people have used Parallax components to build sorters in the past

Has anyone built a working color or line scanner sorter that has potential to be fast and flexible

I would like to have a flexible soter that can sort small objects on colour and possibly texture

Thanks for any leads

Ian

Martin_H
03-08-2012, 10:51 AM
I've seen both done. Watch Mike Davey's Turing machine video to see the line scan camera in action:

http://www.parallax.com/tabid/854/Default.aspx

I've seen robot arms sort blocks using the color sensor, but I donít have a video link yet. My gut feel is sorting by color would be simpler than by texture.

Duane Degn
03-08-2012, 10:47 PM
You could also use Phil's NTSC color capture method, though I don't think It's very fast.

Parallax also sells several color sensors.

I have a machine vision section in my index (I think it's post #3). Maybe you'll see some other ideas there.

Tubular
03-08-2012, 11:52 PM
Welcome, Wilsone

"Fast and flexible" needs to be traded against colour accuracy etc. There are some neat sensors from Parallax mostly thanks to Phil Pilgrim - colorpal, or tsl1401 line scan that could be used with coloured filters on the front, and a couple of others too.

You mention a small product, is it moving? Fruit? How big approximately are the objects and what kind of speeds are involved?

wilsone
03-27-2012, 10:26 AM
Welcome, Wilsone

"Fast and flexible" needs to be traded against colour accuracy etc. There are some neat sensors from Parallax mostly thanks to Phil Pilgrim - colorpal, or tsl1401 line scan that could be used with coloured filters on the front, and a couple of others too.

You mention a small product, is it moving? Fruit? How big approximately are the objects and what kind of speeds are involved?

Hi Tubular, thanks for your interest.

What I was thinking of is a detector/sensor that connects to a processor/(accept/reject mechamism) and the unit could be adapted via different programming to be used on different tasks, e.g

one might be to separate spherical green nut from brown nut;

one might be to separate nut kernel(cream) from shell(brown);

another might be to separate green leaf from twigs.

The objects are from 1/2inch to 1 1/2 in size and would be on a moving black belt. If the system was fast enough it might be employed on objects falling from the end of a belt.

Is this too much to ask. Do you know anyone who might be interested?

Thanks

Kye
03-27-2012, 01:41 PM
I think I have what you need:

www.cmucam.org (http://www.cmucam.org)

We are still getting up info for the fourth version. But, it can find colored shapes easily and tell you their location.

Here are some videos of what previous versions could do http://www.cmucam.org/projects/cmucam1/wiki/Gallery.

Phil Pilgrim (PhiPi)
03-28-2012, 10:24 PM
Some things to keep in mind when selecting a sensor for sorting:
When objects being sorted are in motion, you do not need to sense two dimensions to get a two-dimensional view. A linescan sensor coupled with an encoder allows 2D images to be reconstructed from multiple slices, and it eliminates parallax distortions along one of those dimensions (the direction of travel).

Fast-moving objects require rapid data acquisition. This rules out sensors like the TCS3200 color sensor for all but uniformly-colored subjects, since it must sample the individual color channels in sequence, rather than all at once. It's better to select a color sensor that can sample and output all three color channels at once, so that the three channels all refer to the same part of the subject when the subjects are variegated.

Moving objects play havoc with video sensors that have a "rolling shutter", since the pixels are exposed in sequence, rather than all at the same time. Most CMOS array sensors, including the one in the CMUCAM, employ this technique. If you use a 2D sensor, be sure to get one that exposes the entire frame at once.
These comments are not meant to impugn either the TCS3200 or the CMUCAM4, which are both excellent choices in the arenas to which they're best adapted. But when the product being sorted for size, shape, or color is in rapid motion on a conveyor, the choice of sensors becomes more limited.

-Phil

Kye
03-29-2012, 01:41 AM
Very true, the low FPS of the CMUcam4 causes fast moving objects to blur.

That said, it still will tell you if a color blob of a certain kind passed by if the object is not moving to fast.

Tubular
03-29-2012, 02:38 AM
What I was thinking of is a detector/sensor that connects to a processor/(accept/reject mechamism) and the unit could be adapted via different programming to be used on different tasks, e.g
one might be to separate spherical green nut from brown nut;

one might be to separate nut kernel(cream) from shell(brown);
another might be to separate green leaf from twigs.

The objects are from 1/2inch to 1 1/2 in size and would be on a moving black belt. If the system was fast enough it might be employed on objects falling from the end of a belt.
Is this too much to ask. Do you know anyone who might be interested?


Always plenty of people interesting in sorting things, but it has to be very reliable before they will part with significant $$$. And it has to keep working even when lighting and/or product varies.

However the propeller and Parallax sensors are a great and cheap way to start playing to see what is possible.

RS_Jim
03-29-2012, 01:42 PM
Very true, the low FPS of the CMUcam4 causes fast moving objects to blur.

That said, it still will tell you if a color blob of a certain kind passed by if the object is not moving to fast.
Kye,
What is the frame rate? Could the motion be stopped with a flash of an led? At 15 fps one frame is 66.7 ms in duration. Depending upon the speed of the belt and how long the imager saves the image might make the cucam an excellent choice.
Jim

Phil Pilgrim (PhiPi)
03-29-2012, 03:53 PM
Jim,

There's more than just the frame rate involved. Sensors with a rolling shutter (http://en.wikipedia.org/wiki/Rolling_shutter) do not expose all of their pixels at the same time; rather, the integration time for each row of pixels begins somewhere ahead of readout and ends when the row is read out. What this means for objects moving quickly is that the slice of the scene that each row of pixels "sees" occurs not only at a different place, but also at a different time. This can cause artifacts to appear. A strobe will not help, because it will illuminate only part of the field of view, i.e. only for those pixels which are being exposed when the flash occurs.

Most inspection cameras use either a global shutter or, for moving subjects, a one-dimensional array of pixels. Cameras with 2D global-shutter image sensors do tend to be more expensive than the rolling-shutter kind, however.That's why you seldom see them in the hobbyist and consumer markets.

-Phil

Kye
03-29-2012, 09:28 PM
The frame rate is 8 FPS right now. Higher FPS can be achieved though... It's targeted for the Arduino so its a low power device.