confusing between red and orange

[apurvakalia]

The cube scanning seems to be confusing between red and orange for me. I have tried Pi Camera v1.3 as well as v2.0. I have also tried multiple cubes and played around with many settings (AWB gains, contrast, mode etc), but it still gets confused between red and orange on alternate squares. See the attached file - which is the output from the color-resolver program.

rubiks-color-resolver.html.zip

[dwalton76]

Red vs. Orange is always a beast :( I am able to reproduce the problem with the output from the html file you attached (thanks)...let me see what I can do

[apurvakalia]

Thanks for responding so quickly. A couple of other things that may be important:

• I am actually implementing this on BuildHat (and not on BrickPi3). So my solution is a combination of your code and the original PrimeCuber code
• However, I am using your scanning code pretty much as is since PrimeCuber scans using the color sensor
• Could the problem be related to the direction of spin in between scanning? I dont think so, but thought I would put it out there
• I tried looking into the init.py file to see if there are any tolerances etc that I could tweak but could not see anything obvious Very interested to see what you find out. So please do let me know

[dwalton76]

question...is square 23 Orange and square 41 Red or is it the other way around?

[apurvakalia]

I think that is the problem. The actual cube looks like this:

So by that 23 should be Red, right? The dictionary of returned RGB values shows: '23': (230, 61, 33) ... '41': (180, 0, 7)

If 41 is orange as per the actual cube pictures, then the RGB values seem good (230 is "more" red than 180).

So am I spinning the cube the wrong way in between scans? Or is it some other problem?

[dwalton76]

yeah so 23 is Red and 41 is Orange...so we are getting the centers and corners correct but the orange vs red edges are all reversed.

You are not doing anything wrong...I suspect this is a bug:

[apurvakalia]

Yes, the edges seem to be getting flipped. The RGB values of the edges look good (e.g. '20': (224, 54, 29) vs '38': (172, 0, 5)). So it does look like a bug.....

[dwalton76]

I see what was wrong and pushed a fix, do sudo python3 -m pip install git+https://github.com/dwalton76/rubiks-color-resolver.git to install the latest code from the repo with the fix and let me know if it works

[apurvakalia]

wow! that was quick. Unfortunately, I wont get to testing this later today, but I will try and match your alacrity and let you know as soon as I test it out :) Do I need to uninstall the current install before pulling in the fix? Also, just out of curiosity, what was the bug?

[dwalton76]

In a nutshell we were looking at all of the corner squares and classifying them as one of the six colors and we used that to define a baseline RGB for each of the six colors. For an odd cube though we can do a little better by only using the square in the dead center of each side for defining a baseline RGB for each of the six colors. For odd cubes we know that:

• yellow must always be opposite white
• red must always be opposite orange
• green must always be opposite blue

so that makes it much easier to get them classified as one of the size colors correctly.

[apurvakalia]

Your fix worked! I can now successfully scan the cube 4 times out of 5. Every once in a while the cube becomes a little skewed while turning and then the scanner complains about not finding the black border, but that is a mechanical issue. I need to adjust my flipper so that the cube does not get skewed. Thanks a lot - I am now moving to the next part. Hopefully I can get this working for BuildHat soon....