Not getting "real" RGB values

[shivshah]

We are currently using the REV Color Sensor V3. We were using the example code given on the Rev website for FRC and tested it on RED CARGO. What we found fascinating was that the RGB values we were getting were R: 140 G:80 B:27 or in decimal .56,.32,.10 respectively with an IR value of 296 ish. I was wondering if yall had any reasoning behind why that was the case?

Thanks

[mdurrani834]

Are you using the MXP I2c port?

[shivshah]

Yes

[mdurrani834]

The MXP I2C port outputs 5V while the normal rio I2C port outputs 3.3V. The extra power makes the white LED a lot brighter which can affect color readings. I reccomend just testing and then documenting the values you get from red and blue balls.

[shivshah]

We will be documenting those values however even when we turn the LED off we are getting the same numbers.

[ksquare]

In our tests of the color sensor, we got similar values: 0.4, 0.4, 0.2 for red, and 0.2, 0.45, 0.34 for the blue cargo. They were different enough to detect red cargo as red and blue cargo as blue, but when there’s no cargo, the background was also detected as “red”.
So we’re trying to put something like black felt into the “background” to also detect “no cargo”.

[Will_Toth]

Color, and the way computers interpret color is a fascinating topic that can go fairly in depth. Fortunately you don’t need anything complex, since we’re only comparing between red and blue. In this case even the most basic logic will work just fine.

if (red > blue) {
  ball = red
} else {
  ball = blue
}

Worried that it ‘sees’ red when there is no game piece present? Well, the color sensor V3 includes a proximity sensor. So you can use the proximity sensor to detect whether or not the game piece is there at all. If it is, then simply check if its more red or blue.

[ksquare]

V3 includes a proximity sensor

I knew that, but had forgotten about it … We were already contemplating a ‘presence’ sensor within the overall cargo handling scheme. Maybe we can skip a designated one because the color sensor gives us presence and color info at the same time. Thanks!

[shivshah]

@Will_Toth

Color, and the way computers interpret color is a fascinating topic that can go fairly in depth. Fortunately you don’t need anything complex, since we’re only comparing between red and blue. In this case even the most basic logic will work just fine.

I think it depends on the location you’re in and it could also be that your “buffer” for RGB is too high so i would try and shrink it.

[shivshah]

The issue with this logic is that its either red or blue and not neither. There is a scenario where you have no CARGO in the feeder.

[Will_Toth]

That’s what the proximity sensor that is built into the device is for, though if you are trying to get the color of the object from any kind of range (beyond like 3-6 inches) then you should use a camera instead.

[shivshah]

However if you’re trying to show this to the driver in the driver station it should display nothing if you don’t have any CARGO inside your robot. I think saying its red even though you have nothing is misleading. You could use a conditional in a proximity sensor to determine this as well but at that point there is no difference between red blue or nothing.