Flotilla Colour cannot see all three color components

I finally broke out my new Flotilla hardware and have been playing with Rockpool on my RaspPi 2 running Wheezy. My Colour sensor doesn’t show output on all three channels (R/G/B) at the same time, at least one channel will always be zero even if I point the sensor at a white surface. Which channel will be zero at any moment depends on the colour of the surface it sees. Do I need a replacement Colour unit?

This is perfectly normal, although possibly a confusing choice. I was looking over the code responsible for this last week.

In order to scale the colour values to something that makes sense in Rockpool the Minimum/Maximum colour values are worked out and then something like this is applied inside the Dock:

red = (red - minimum) * 255 / max
blue = (blue - minimum) * 255 / max

The upshot of this is that the least intense colour is clamped down to zero which is bad if you’re, for example, trying to match a colour from the colour sensor on the rainbow stick.

I’ll remove the colour fiddling from the Dock in Shipshape update so I can figure out something better.

Okay, as I understand it, the sensor devices (distinct from controls like Slider) have a fuzzy range. For example for temperature and pressure there are not good bottom ends (other than 0 degK and 0 mbar), I assume you have to normalize some set temperature and pressure (as yet unknown to me) as 0 in Rockpool, and some higher values as 1000 (also unknown).

For the light sensor, you do at least have a low end: 0 for complete darkness. If you want to normalize the RGB channels, you could do it based on the maximum of the three alone, and leave the minimum out of the equation. The hue and saturation should come out about right, and value (intensity) is subjective anyway if you’re not measuring actual lumens.

Just a suggestion.

There’s actually a 4th channel on this, and most RGB colour sensors, which is usually called something nonsensical like: “clear”.

It represents the unfiltered light level, so normally you can do something like: red/clear, green/clear and blue/clear to get each colour channel as a ratio against the total light level.

It works considerably better than the clamping method, although I’ve dropped that code from the dock now so Rockpool, or the API, can apply whatever scaling/logic they see fit.

Temperature is an interesting one- it outputs a value in degrees C, but to scale that into Rockpool-speak I need to set a low/high bound. It makes it possible to do an in-your-head conversion, but where possible/sensible Rockpool will show real-world values anyway.

It isn’t so much that the range is fuzzy, since it’s generally given as a 16bit signed or unsigned integer ( IE 0 to 65535 ), and thus has an absolute minimum and maximum bound, but quite often a great deal of the range is useless and unnecessary- you’d be hard pushed to measure something at 300 degrees C for example :D

Similarly, maxing out the light level involves shining an LED right into the sensor, and the range varies depending on ambient lighting conditions in the room- making Rockpool make sense is… tricky!