I’ve constructed the BricKuber Rubik’s cube solving robot but am having trouble with the quality of the pictures that the RPi camera (V1.3) is taking of the cube’s faces.
On the very rare occasion that the solver manages to take and analyse all 6 faces, the code always returns the message Error: Error. Probably cube string is invalid
I can see why that may be by looking in /tmp at the photos of the faces. The contrast changes radically between faces despite the illumination remaining the same throughout.
Can anyone suggest what I could try to correct this problem? Perhaps change the options to the rspistill command? The default settings in brickuber_lib.py are:
-w 300 -h 300 -t 1 --imgfx cartoon -o ...
My other thought is that maybe the V1.3 camera is not up to the job and I need a V2?
I’m using camera version 1.3 successfully, so that shouldn’t be an issue.
You didn’t specify which RPi camera you’re using, but I recommend using the standard camera rather than the NOIR camera, as infrared light would wash out the colors. You should use the RPi camera with green PCB, not the one with black PCB.
I think you are on the right track regarding the raspistill settings. Personally I find this most reliable:
I’ve tried with the default settings and it’s very rare that it runs for me, but the above works very well.
Even with the above settings, it still needs good light that isn’t glaring off the face of the cube. Looking at the photos in /tmp is a great way to determine if the lighting is reasonable. I find that the color detecting algorithms work best with lots of light (a lamp nearby), but it certainly can’t be glaring. The colors might look a little too bright (almost white) in the photos, but that’s when it works best in my experience.
OK, the camera I’m using is that with the green PCB, so hopefully that’s one stumbling block out of the way.
Removing the --imgfx cartoon option from the ‘raspistill’ command enabled the colour analyser to work. Excellent!
Then I hit a new problem: I need to slow down the grab arm during the solving process as the cube doesn’t have time to revolve before the grab arm intervenes. Result a cube which has staggered layers!!!
Different problem though, so i’ll try tuning the cradle and grab arm motor speeds - I already had to reduce the full travel aim point from -337 to -312.