Issue:
The optical sensor pickup the wrong color?
Senser:
Optical sensor(2nd generation competition kit)
Vexcode IQ (iPad)
Testing:
Yellow object: Yellow at most times, sometimes Red.
Green object: Red
Blue object: Red most of the time, sometimes Purple.
Red object: Red
Others: Red
We have 2 optical sensors. We have observed that both optical sensors exhibit similar behavior— functional object detection but poor color detection. Could this be a Block software issue?
For color detection the object should be fairly close to the optical sensor, perhaps < 25mm. The “object detected” event can trigger when it detects an object much further away, around 100mm. This threshold can be adjusted when using C++ or Python, but not using blocks. So how well that code will work really depends on what you are trying to detect and how the object passes by the sensor.
The object detection distance in Block is around 3.5 inches.
The result was not correct for color detection, no matter how close the object was. (less than 1 inch or not)
I suggest you make sure the optical sensor is working correctly using the brain devices screen (turn on the led using the “left” button). These are the values you might expect to see for blue, green and yellow objects.
Yes. We repeated the Blue and green with very close Hue numbers. However, the “color name” is still incorrect.
Can we conclude that the Block color detection logic is wrong?
It’s not necessarily that the color name logic is wrong in any sort of fundamental way, it’s just that the thresholds it’s using for converting a hue value to a color name don’t match your environment.
We ran into this last year playing around with identifying Full Volume blocks by color. Green blocks were most often read as Yellow by default, and Purple could be Purple or Blue.
To customize that in blocks you could build a myBlock (function) that took in the hue value and output a color name based on values that you determine experimentally in your environment (but that you’ll want to be prepared to tune in other environments).
The fundamental problem is that it’s not just the color of the object that matters, but the brightness/color/temperature of the light that’s illuminating it, which is why having things close and lit by the sensors LEDs makes things the most consistent, but even then, I wouldn’t expect it to read 100% the same as you move through different ambient environments.
The raw data collected by the optical sensor is the amount of reflected light in three different wavelength bands. ie. the light pases through three color filters, red, green and blue and the amplitude of each measured. The raw RGB data is then converted into a hue value. The accuracy of the hue value increases when more light can be captured which is why object distance and/or lighting is important when using the sensor. The hue value is then compared to known hue ranges to decide which is the closest named color, for example, green would have a hue value of between 80 and 140 degrees. When a color has a hue near the edge of these ranges often the adjacent color can be returned instead. As we have 10 different named colors, some with narrow ranges of hue, this is not uncommon.
Thanks!
The team is an elementary school team, and I suggest they use Block instead of Python or C++ for automation control. I will explain the problem to them and let them make the decision. They can either use a “fake” color name or the raw data for detection.
Thanks!
This is very helpful!
Was it two optical sensors on one robot, would that still work?
