No announcement yet.

How does the color sensor differentiate between "no color" and black?

  • Filter
  • Time
  • Show
Clear All
new posts

  • How does the color sensor differentiate between "no color" and black?

    I was looking at the programming for the color sensor and I noticed something interesting. The color sensor can detect seven "colors", as well as "no color". I assume that means that if there isn't anything close enough to reflect any color, then the "no color" condition is triggered? But black also doesn't reflect any light, so wouldn't it be the same? I suppose a shiny black technic beam does reflect some light, but I feel like the little that is reflected back would be very hard to distinguish from the "no color" condition. I guess if the sensor can distinguish between brown and black, two colors that are pretty close together, then it does have the sensitivity to distinguish between black and no color. Anyway, I was wondering if there was anyone here that had some knowledge of how the color sensor works internally and if it was a challenge to build $50 sensor that could tell the difference between these two conditions.

    I guess a follow-on question would be if anyone had any experience on the FLL table where they needed the robot to differentiate between the "no color" condition and black, and how reliable was the robot at doing that? I have not had the need to do that in the last seven years, nor am I aware of any teams trying to do that.
    Norfolk, Virginia, USA
    FLL Coach and Regional Tournament Head judge since 2014

  • #2
    The color sensor reports No Color (0) when the RGB values do not match any of the defined color patterns in the color algorithm. It does not indicate there is not enough color.

    Brown is an interesting choice to use as an example. Brown is not a primary or secondary or even tertiary color. Brown is a dark orange. If I only have Red, Green and Blue information, how the heck am I supposed to identify Brown? Right now I have my EV3 color sensor plugged in and am looking at an orange LEGO part. The color sensor says the part is red (there is no color number for orange). However if I place the orange part next to a black part and kind of hover the sensor over both colors the color sensor reports brown. Orange is red and yellow mixed together, what happens if the sensor is looking at yellow next to black? Hmmm, it reports brown. How about red next to black? That is a bit picky, but I can get that combo to also say it is brown. Can I do the same with blue and black? Nope. Blue next to black is either blue or black. How about green and black? I cannot get green and black to make the sensor think it is seeing brown, but I can get it to report No Color (0). The color sensor is really picky about greens. I have some teal LEGO parts and the color sensor says they are white. Blue next to green is a crapshoot. I can get the sensor to report blue, green. white, black and no color. Getting two colors that are neither black or white confusing the color sensor into thinking they are both is a neat trick.

    Scanning for a color is unreliable as my orange/black, yellow/black, and especially green/blue transition explorations have demonstrated. The color sensor cannot say "Half of what I see is red and half of what I see is black". Instead it has to take a stab at picking a color that best fits the colors it knows. Sometimes that color is going to be No Color. I am surprised by how seldom that is No Color. I would go so far as to say that the color sensor is more likely to report the wrong color than throwing up it's hands and saying "No Color". This happens a lot with greens, but I see it for all colors. While experimenting with using the color sensor to find lines we drove over colorful adds from the Sunday paper. Stop when the sensor sees blue, run over random images and record what color was under the sensor when the robot stops. Quite often the sensor was over a transition (not surprising), but a significant number of times the image under the sensor did not contain blue. This happened with all colors, even black and white.

    Color is extremely complicated. It depends on light sources and color absorption and reflectivity. It also depends upon context. You can find perception puzzles that show a block of color apparently changing color when the surrounding color changes. The color doesn't really change, but how we see it, or at least how we perceive it depends on the context. This is kinda how brown works. It looks brown or orange or yellow or red depending not only on the hue, saturation and value, but also on the darkness and color of the surroundings. If your mind has a hard time figuring out the color of something it is not surprising a $45 color sensor sometimes gets confused.
    Last edited by Dean Hystad; 03-05-2020, 06:38 PM.


    • #3
      Electronically, it's not particularly hard to build a sensor that can read reflected light with a high level of sensitivity. Converting the readings into a color is rather more tricky, as it is a subjective matter that even humans can't always agree on.

      I don't have the design documents of the EV3 color sensor, but from experiments I am guessing the following...

      On the electronics end, the EV3 color sensor contains a tri-color LED, which it turns on one at a time. A sensor (...maybe a Light Dependent Resistor, but there are other options) makes 3 measurements to determine how much light gets reflected back when each LED is turned on, and one more measurement with all LEDs turned off to determine the ambient light. The last measurement is then subtracted from the rest to cancel out the effects of the ambient light.

      On the software end, a common way of recognizing color is to first convert the RGB values into HSV. The colors can then be determined using...

      1) If V is very low, then it is black. S and H don't matter.
      2) If V is high, but S is low, then it is white. H don't matter.
      3) if V and S are middling, and S is close to 0 or 360, then it is brown.
      4) If V is high and S is high, then H will determine the color. These are the approximate values...
      0 : Red
      64 : Yellow
      128 : Green
      etc. (this is a 360 degrees mapping, so 360 and 0 are the same)

      If you get a value that doesn't match these exactly (eg. 67), you'll take the closest color (Yellow). You can play around with any HSV color picker to understand this better. Since the EV3 is typically used with Lego, the color values are likely selected based on the specific hues of the Lego bricks. The values will also be affected by the choice of LED and sensor. "No color" is probably an extremely low V value, lower than with black, as even with a black block, the amount of reflected light is significant if the sensor is close.

      You can test this out using the mindcuber RGB blocks (you'll need to convert to HSV yourself) or using EV3Dev (...provides both RGB and HSV).

      I've had teams try to differentiate between black and no color in WRO last year using the built-in color blocks in EV3-G; It works, but is too unreliable for competition use.


      • #4
        I'm curious - do FLL teams find it useful to look for specific colors on the mat? It's been a number of years since I've coached, so my team only used a color sensor one season, and relied mainly on the old NXT light sensor. Even in that one season, the team had problems where the sensor would report green as black. Following lines and looking for sharp line edges seemed much more reliable.
        Last edited by timdavid; 03-12-2020, 10:06 AM.


        • #5
          For FLL, no. Never had the need. As well, the colors on the mat are not "Lego colors" making them hard to use reliably. There are some situations where it could potentially be useful (eg. For "Into Orbit", there's a sharp color contrast in the North-East corner that may be useful for alignment), but there other ways of accomplishing the mission.

          If your team ever take part in WRO, you may find it necessary in some years.

          It seems to me that the EV3 sensor is particularly fickle in detecting green. When necessary to do so (eg. for Robocup), I would teach my teams about RGB to HSV conversion and show them how they can choose their own HSV values to identify a color.


          • #6
            Some teams have attachments that are color coded. When the attachment is placed on the base robot, the EV3 figures out what mission it is for and runs that mission (probably after pressing a button on the EV3). Prevents accidentally running the wrong mission.
            Norfolk, Virginia, USA
            FLL Coach and Regional Tournament Head judge since 2014


            • #7
              Wonder where they got that idea? Coding like this does not require a color sensor, or any sensor for that matter. I saw color coding used way back in the RCX days (guess that was RLI coding). I've also seen multiple generations of touch sensor coding. I even saw a team use button coding. Each of their attachments had a little arm that hovered over the buttons on the
              EV3 controller. Pushing the arm down pressed a different button for each attachment. I don't know why I am still surprised with what teams come up with. There are so many FLL teams now that I should see new and novel ideas all the time. And I do and I love it.

              My girls never practiced running missions and it showed at tournaments. Instead of practicing they wrote the missions to be idiot proof. The first step was keeping the number of missions less than five. The second step was keeping the number of attachment changes less than 3. The third step was starting every mission in the same place and pointing the same direction. The fourth step was starting with every attachment in the down position. Using color coding to automatically select the correct mission for an attachment would have been a really good step 5. Unfortunately they would still forget what order the missions are run.


              • #8
                My team does a lot of those same things. We don't necessarily have all attachments start in the "down" position, but we usually have our first step block to reset all attachments against some hard stop if possible.

                Last season we lost one precision token. At the state tournament they accidentally hit the wrong button in one match. We practice our choreography for a solid week before tournaments, and it pays off, but mistakes still happen. I was pretty happy when they said they wanted to come up with a system that was even more human-proof. Even though it only happened one time that was enough for them.
                Norfolk, Virginia, USA
                FLL Coach and Regional Tournament Head judge since 2014