Jump to content
43oh

TCS230/TCS3200 Color Sensor


Recommended Posts

These sensors can be obtained on Amazon/Ebay, are fairly cheap, and work by converting current from photodiodes into a square wave output.  Don't expect much from them as they have a lot of limitations but can detect colors and match them to some degree.  I noticed an old posting on 43oh about this sensor but it wasn't apparent they were successful so I gave it a try.  The photo below shows the sensor and examples from the demonstration sketch I wrote in Energia V16 using the MSP432P401R LaunchPad.

 

post-45284-0-42194200-1439077015_thumb.jpg

 

I tried using pulseIn() and got it working quickly on the MSP432.  I tried the same code with the F5529 and it was somewhat less successful - it was flaky matching colors which I suspect was due to the limitations of pulseIn() on the F5529.  The sensor output is adjustable but I didn't find it worked well at the lowest frequency setting.  A better approach for the F5529 would be to use a timer and count pulses but I lost interest :-)

 

The sensor is sensitive to incidental light/shadows, material properties, distance from subject, and probably all sorts of other things.  It is more sensitive to red (and infrared) than other frequencies and the datasheet gives some help but in the end everyone seems to slap something together using the raw readings or just use the raw readings.  I didn't find the raw readings useful and developed empirical factors for the frequency response from some colored card stock and made up an algorithm based loosely on an approach I saw in some Arduino code.

 

The pin connections and code are here for those interested.

Link to post
Share on other sites

Hi,

I actually used this sensor a lot in a past contest.
I used with a Tiva and a STM32. I tested it a bit with a Arduino Uno because some peeps wanted help with it (robotics club so I go with Tiva or STM32 and I still have to teach Arduino to the rest...)

I found the pulseIn very limiting, in the Tiva and STM32 I had minimum divisions from 20 to 12,5ns (sometimes 1 microsecond when using 16bit timers on the STM32). Usually I used the 20% pulse length, even with the ARMs with timer inputs. I think in the arduino I used the same or the 2% one.
I didn't find at all using 2% or 20% limiting, actually it was even better so I could get better readings - although maybe with the timers I should have used full speed.

What I always did was with a "color checker" - if you search the web you should be able to find those little squares for testing colors (of course mine was flawed in the choice of paper and ink).
My code first required calibration. You needed to get the readings on white to balance it out (WhiteReading).

Then the math to convert the readings to 255 scale would be (note that the readings are in time, the period, hence why the order might seem strange):
 Calibrated_Value = WhiteReading / Reading * 255.

This was done in any of the platforms.


The sensor readings are really bad due to the LED being used as a source - very unbalanced colors distribution. So having the sun or not would not only affect the intensity but it would uncalibrate the sensor when using the method I use (the sun is much more balanced in color distribution)

But in general this never failed, in the contest, the sensor was on a robot. The robot started in white so perfect. It would calibrate itself in the beginning and distinguish White from any other color (it only needed to do that) but it seemed to distinguish Blue, Red and Green quite easily. But wait! In the contest day I had a problem. The starting white and the white in the arena was different, the starting white was much dimmer - so I noticed that it was much better to just calibrate it on the "whitest"/"brightest" white and save the values - I saved those values on the morning and they never failed all day (note that I had more algorithm to check the values and match them to a color)

Link to post
Share on other sites

@L.R.A Thanks for your insight, it sounds like you got it to do everything you needed it to.  I like your scaling approach, the conversion algorithm is simple, and simple is almost always better.  White calibration and calibration to the target material in the light condition that will be encountered are absolutely necessary also.

 

Playing around with this sensor will give an appreciation for what camera designers have accomplished with modern auto white balance.  With everyday materials and lighting there is complexity that can present interesting problems.  Figure 1 in the datasheet is instructive - note that incidental IR in the 800 nm range can throw everything off.  I am pretty sure I was seeing this in my experiment.  So another improvement might be to place an IR filter in front of the sensor element.

 

The curves in Figure 1 are anything but linear (or even smooth) which can complicate a simple approach depending on the objective.  For example, take orange in the 625 nm range.  The curves shows a very strong red response that can't really be differentiated from clear and equal weak responses from green and blue.   Since my goal was to match the color in a lit LED then what the algorithm really should do is to output red with a healthy dose of green.  I was doing OK with red, green, and blue with a simple Arduino program I found but not all the shades in between with real materials. That is what is behind my admittedly ugly approach.

 

A more satisfying way might be to tabulate the normalized data in Figure 1 and use that in an algorithm to better match shades.  I imagine there is someone out there who has done that and it would be interesting to see their results.

 

@@Rei Vilo - If the library you are using is a good one and in the public domain I'd be interested in seeing how it works.

Link to post
Share on other sites

I actually tried with a simple library for an LCD get the color data directly to the LCD. I also did the same to the computer, sent the data be serial and a processing program would show the color. Oh man the LCD way of the colors while the PC was pretty much spot on. Not only camera white auto balance, but talk about LCD color balancing.

I remember finding a TAOS (now AMS) application note for more advanced color measuring.

Actually where can you get a IR filter for this? 

Try to check out the TCS34725. There's a really cool board for it (level shif circuit and 3.3V voltage regulator). I think it has an IR filter, though it's much smaller and I found it hard to use it in a moving robot - slower reading speeds and it required a much smaller distance it seemed + I used a black tube around the TCS3200 to get only reflected light and no direct light from the LEDs - I think it's more suited for light color measuring instead of surface color measuring. 

Link to post
Share on other sites

 

Actually where can you get a IR filter for this?

 

@L.R.A Maybe hack something like this to fit over: http://www.adorama.com/FSV1303.html     Also, I have an old film camera filter that is supposed to block both UV and IR and you can still get them - could perhaps break a cheap camera filter into pieces and grind the edges smooth.

 

@@Rei Vilo - Your last example is mine :)  (amazing how fast stuff finds it way to Google) and the one from Geeetech served as inspiration and a starting place although I didn't use the code directly.  

Link to post
Share on other sites

@@Fmilburn I'm actually gonna use this one: http://www.ebay.com/itm/Pair-Camera-9-5MM-Optical-UV-IR-Cut-Filter-UV-IR-Blocking-Filter-/281437567116?hash=item4186fc788c

All this just because in the TCS34725 I can't very well isolate direct light and well... arduino/energia i2c is easy... not so much without it xD. I like my timers.
Actually in the TCS3200 I can get the readings so much faster, something like every 0,5mm or less, with a robot going 70cm a second XD. Gives room to make averages and increase the speed.

I might get into the TCS34725 more in the future but only with interrupts (I don't want readings blocking the code) - but I still have to keep the TCS3200 for the newbies at the club - i2c is hard.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...