I've implemented an algorithm for colour classification that seems to work ok:

1. detect brightness changes from below to above threshold, i.e. a piece arrives at the sensor
2. each sample is matched to nearest colour in a library of about 30, using 'redmean' distance
3. wait until M out of the last N samples are the same (because the detected colour can change significantly as the piece arrives and as it leaves the sensor, where it's only partly in the field of view)
4. determine output bin and move diverter
5. wait small fixed delay for piece to fall down diverter
6. repeat.

This seems to work ok for big bricks, but small pieces will be a problem because they are moving too quickly to get more than 2 or 3 samples total, so the "M out of N" consistency check will fail. This is exacerbated by using a fixed (non-vibrating) section of feeder which needs to be at a fairly steep angle to ensure pieces don't stop, but means they're moving pretty fast by the time they reach the sensor:

• smallest piece/dimension: 8mm
• max. speed of travel along feeder: 0.8m/s
• min. time passing sensor: 8mm / 800mm/s = 10ms.
• sensor rate: 5ms/sample (including processing)
• min. number of samples: 10 / 5 = 2

But it works well enough as a starting point:

An alternative plan I'll try next is to position a second light sensor above the feeder, trained to detect the light from the illuminating LED. When the light dims sufficiently, we can be pretty sure there's a piece in just the right place, so should be able to exactly time a single colour measurement (taking only 5msec) rather than needing a whole string of them. [Update: yes this approach works very well! More to follow in next log.]