Announcement

Collapse
No announcement yet.

New adafruit color sensor driver: Seeking opinions on RGB/HSV, scaling, gain

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • New adafruit color sensor driver: Seeking opinions on RGB/HSV, scaling, gain

    For a variety of reasons, I’m writing a new driver for the Adafruit RGB TCS43725 color sensor (https://www.adafruit.com/products/1334). I plan on making this available via github. I’m seeking opinions from those knowledgeable about RGB / HSV color representation and/or this sensor. I’ve done a bit of research on this topic but am not an expert so I would value other opinions and corrections to my work.

    RGB Scaling
    The max possible color values returned from the sensor are a function of the integration time selected by the user. The actual color values returned from the sensor are a function of the gain selected and the environment the sensor is operating in. Standard RGB values range from 0 to 255, at least in many models of color. The returned values from the sensor are not standard and their range is dependent on the integration time. That makes them hard to use in any absolute sense. You can only do relative comparisons.

    Standard RGB values have advantages:
    • Converting standard RGB values to HSV will result in standard HSV values. (I believe HSV to be more useful than RGB. See below)
    • Using standard values gives the ability to interface to color libraries that expect standard values.


    Question: Is it worthwhile to provide methods to return standard RGB values to the user of the class? The methods will scale the color values appropriately given the integration time selected.

    Gain selection
    In order to get maximum resolution of the returned values, the gain of the sensor has to be set properly. You want it as high as possible without bumping over the max possible color value given the integration time (ie saturating the value). The ideal gain is highly dependent on the specific situation in which the sensor is being used. If there is bright lighting with no shadows you have to use lower gain in order to avoid saturating the color values. Dim lighting or shadows require higher gain to get the best resolution.

    The variables involved in selecting the proper gain are somewhat complex. I suspect most teams are not even considering them and are just using what other drivers provide as a default.

    Question: Is it worthwhile to provide a method that can be run and will suggest the proper gain to be used? The user would put the sensor into its anticipated environment and call the method. They could then use the suggested gain in their robot run time code.

    Question: Is it worthwhile to provide an optional mode that automatically adjusts the gain on the fly, increasing gain until the values saturate and then backing off a notch? Running periodically in real time, this method would have to steal color sensor update cycles every so often, adjust gain and then start returning values again to the user. So there would be some periodic variation in the refresh rate for the color values should the user choose to run in this mode.

    HSV values
    Based on my research, I believe that HSV color representation is much more useful to teams:
    • Hue is much less dependent on lighting conditions than RGB values making color detection more reliable.
    • Value seems to be useful for black / white / grey detection. A good use case would be line following a white line against a black floor or vice versa. I have not worked with this yet but I think this is the case.


    Question: Is it worthwhile to provide methods to return standard HSV values?

    Thank you for your opinions.

  • #2
    Standard RGB values: yes. Being able to do this assumes some level consistency from sensor to sensor. How repeatable across manufacturing batches could be problematic, but probably worth a try.

    Test and suggest proper gain: Probably yes.

    Adjust gain on the fly: Probably yes but --- we already know there are sample rate issues with I2C devices in this environment. I'm not sure we can afford losing too many sample intervals. There could be value in attempting to use interpolation between gain levels and moving averages to sneak a peek at adjacent gain values while still returning useful data 'on time' albeit with some added level of uncertainly. In real time systems, returning data that is almost-right but on time is often more useful than data that is right but late.

    Returning standard HSV values: worth a try but --- I'm not sure how much things have improved, but some years ago I did quite a bit of work manipulating and converting RGB, HSV, HSL and CMYK values. The practical results were not particularly satisfying compared to what the theory said the results should be. This was back when we still had to dither, so perhaps things are much better now.

    Comment


    • #3
      I have written an initial cut at the driver. Integration time and gain are fully adjustable. It returns both standard RGB and standard HSV. It does not yet include any suggested gain or auto gain functionality yet.

      In playing with the driver and sensor, I have found that Hue and Saturation are quite independent of lighting conditions and integration time. When gain is too low I see some variation in both due to loss of resolution in the RGB values. Value is another story. It seems to be very dependent on integration time.

      I'll continue to test and will consider adding suggested gain and auto gain functionality.

      Comment


      • #4
        Hi! Does anyone knows the HSV values for recognition of the red and blue colors in the beacon with the Adafruit Color Sensor?

        Comment


        • #5
          We used this resource to define the colors and then experimentally refined them: http://www.tech-faq.com/hsv.html

          Comment

          Working...
          X