Hey CD community. There have a been a lot of threads out and about with regard to the color sensor. I wanted to start a thread to see if we could collect wisdom on the color sensing prototyping we’ve all done so far. Hopefully in the eye toward mentoring lower resource teams, or teams new to this particular sensor (or style of sensor), we can see what teams are doing in this arena. Github links, examples, whatever may help teams would be great.
Specifically what I have seen a need for is helping teams understand the calibration of the sensor for a given environment, and even more specifically, if you have figured out a good calibration routine to setup the sensor what does that look like?
In our current tests, we are testing on paper printed to the right hue, using the default values from Rev’s example code works from 1-2 inches away from the wheel we are spinning without the LED on.
We haven’t started tuning the color matching values to see if we can dial it in better yet. So, if you’re willing, please share your expertise learned up to this point to (hopefully) help those that are just getting started with it.
For example, the color stickers that came with the KoP. I looked at the manual, which shows the colors in terms of various combinations of 100% CMYK values. The blue in the manual is clearly bright 100% Cyan. The sticker clearly is not. If anyone has access to an actual field element, can you report what’s going on here? Are the stickers accurate and the manual wishful thinking?
I bring this up because the blue and green stickers are shockingly close to the same color values as reported by the sensor. Our first step was to show the detected colors on Shuffleboard as R/G/B number bars from 0-1 and then moving the sensor around. Several things we discovered:
The three values always add up to 1.0 because it normalizes for value. We turned off most of the light in the room and actually got more obvious color difference readings on the four stickers!
Different light produces different values, by quite a bit. The built-in light on the sensor glares and leans everything toward yellow.
We took the approach of not using the color matcher! We don’t want to “match” the color, we want to know which one (of only four) colors we’re sensing, so we used extremely coarse direct comparisons of the RGB values, such as if the R value is larger than both of the others, it’s red. Done. There’s such a thing as too much precision. Radical, I know, but we really, really don’t want to miss.
The green and blue are so close that we had to fudge a but. If the green is larger than the other values, it’s probably green, but first we compare the red vs. blue. If the blue is a certain percentage larger than the red, it’s blue, otherwise it’s green. It may be possible to achieve similar results by using the color matcher and setting the confidence threshold to be extremely generous. I’ll be looking forward to hearing what other teams have done.
We’ve tested this in a bunch of different lighting conditions, with the stickers, and with approximate color-match paint on our wheel, and we’re hitting every time. My guess is that requiring a high confidence close match from the color matcher is going to malfunction at some point during games when there are lighting condition variations. (It makes me wonder if it would be within the rules to play defense on the wheel by shining a bright colored light at the wheel when the opponent was trying to spin it to make all the colors read as red, for example!)