NXT 2.0 Colour Sensor and orange colour

[s.frings]

Hello,

I like to build my own version of the rubics cube solver. First I reproduced the Tilted Twister which has two obvious problems:

1) The cube falls sometime out - I build my own hardware which does not have this problem.

2) The color detection fails often, it cannot properly distinguish between orange and red - I did not find a solution for that.

The color sensor return red for both. So I tried to distinguish between red and orange by inspecting the brightness (raw R+G+B). But that did not help because the difference is less than 5% and depends on the distance of the sensor, stray light, temperature, luck and horoscope Those factors change during operation because the cube gets tilted and twisted mutliple times during scanning the colors.

I am not able to place any hardcoded threshold value into my source code which can be used to say whether the colour is red or orange.

Also calculating the quotient of R/B or R/G (which produce the same result because G=B for both colors) does not help. AGain, the difference is less than 5%.

Has somebody an idea how I could technically distinguish between red and orange, as the eyes of each human can do easily?

[gloomyandy]

Hi,
Yes but your eyes have not been deigned and optimized to identify the standard Lego colors. This sensor has! Still you may be able to get it to work...

Have you tried looking at the RAW RGB (and background) values rather than the processed ones (you may need to subtract the RAW background color from them).

Also the algorithm used for Lego colors was changed in newer versions of the Lego firmware. I've updated the leJOS version of this code in the developers snapshot. You can see this code here:
http://lejos.svn.sourceforge.net/viewvc ... iew=markup
The code starts around line 670.... Perhaps you could use a variant of this code to help you?

Good luck and please post back here if you get this to work...

Andy

[s.frings]

Hello,
I used the latest devel snapshot and I subtracted the background light from the raw r g and b values.

Currently I got the best result using this (pseudo-code) formula:

q=64*(rawG-ambientLight)/(rawB-ambientLight);

Looking at average values, there is a noticeable difference between red and orange.

Orange fields produce values from 50-70 while red fields produce values from 40-60. So there is much overlapping where I could only guess.

I think I need to modify my Rubics Cube, replacing orange by cyan. Or use the Hitechnics Sensor, but this one is a little expensive.

[mtbradle]

I thought the creator of the Tilted Twister already solved the red/orange problem?

Even if the LEGO Mindstorms color sensor is very accurate, it is hard to distinguish between the red and the orange colors. The corners are no problem, there is redundancy in that it is possible to use the colors of two sides to determine the color of the third. The center cubies have even more redundancy. The only thing I had to consider was the Rubik's logo on the white center cubie, which gives undefined color readings. The edge pieces are hardest to resolve. For example to determine whether an instance of a cubie is red/blue or orange/blue. By converting RGB values to hue and saturation and comparing them (orange has a somewhat higher hue/saturation compared to red) it is possible to resolve even these.

http://tiltedtwister.com/

I'm not sure if that's what you're doing already or have tried(the bold in the above quote), so sorry if this is entirely unhelpful. Please post if this works or you find a solution. I'm probably going to attempt the tilted twister soon myself and would like to know.

[s.frings]

The color detection of tilted twister did not satisfy me. Whenever I run the program, I had to adjust the position of the robot, ambient light and position of the sensor to get correct color detection. In 50% of all cases, the detecten failed even under best possible conditions.

I am trying to make it better - if that is possible. But I still did not find a btter solution.

[s.frings]

I gave it up. It seems that Legos Sensor is simply not capable to detect orange reliably. That might explain, why most cube solvers use a Webcam to scan the cube.

Has anyone tried the Hitechnics color sensor? They write that it detects more colours, orange is one of them. Does it work reliably?

[kaczor]

q=64*(rawG-ambientLight)/(rawB-ambientLight)

Hello,

s.frings, I had the same problem as yours with the orange detection for the rubik cube. I've made several attempts, tried your solution and I'm pretty satisifed with it. Except that I've increased the factor to 512.

Now the colour detection for my rubik cube is pretty simple:
1. get color ID from the sensor. If it points to non red - that's it,
2. if it points to red (0) - use your equation to calculate "s.frings" factor,
3. with multiplier set to 512, every colour readings below 675 stands for "red" and above is "orange".

I've checked it for several ambient light conditions (from complete dark to 50W halogen pointing 50cm from my cube, a 120W above the table from the standard bulb) or 10x50W of halogen light from the ceiling. I must confess it works like a charm. Of course for some lighting conditions (direct light beams) it detects only "red", but I've checked with standard firmware it cannot detect blue or green balls either...

I've also implemented a ColorSensorRubik subclass tuned for original Rubik Cube from http://www.rubiks.com, which adds a support for ORANGE color. I've not tested it for other "orange" things , but I can share it, maybe it would be usefull. In my environment and for a cube visible on the screens it gives me 10/10 accuracy.

PS. I've also attached a shot of my config, first with Red detection and second with Orange.

and


PS. I've just tested it in a daylight - it still works!

[ryor]

I was trying to find a solution to this problem and stumbled across this tread, if anyone has implimented this into the tilted twister 2.0 code it would be appreciated to know where/how to insert it

[s.frings]

I'm pretty sure that the tilted twist contains already a similar solution + plus it adds a plausibility check (e.g. three fields on an edge cannot have the same color more than once) to reduce errors.