brickuber_lib.py modified for RaspiOS Bullseye with libcamera-still

[CptDangerous]

Hi Daniel,

Not sure if anyone will be interested but I've modified brickuber_lib.py for use under RaspiOS Bullseye.

With the advent of Bullseye, raspistill was removed from the repository and the use of libcamera-still was mandated. It turned out to be not very difficult to implement this. There were a couple of gotchas but I had a new install of Bullseye with all the software up and running in a little under a day of my time (part-time).

Later: this issue is slightly complicated as, hidden in the small print in the documentation for the camera, it says that libcamera is only mandated if you’re using the 64-bit version of Bullseye. If using the 32-bit version, the revert to legacy camera stack is allowed and raspistill is available from the repo. I had opted for the 64-bit version so was constrained.

In the process I changed all the:

if(cmd.find("U") != -1):

instances to that recommended by the Python3 documentation i.e.

if("U" in cmd):

Python Standard Library states:

Note The find() method should be used only if you need to know the position of sub. 
To check if sub is a substring or not, use the in operator:
>>>
>>> 'Py' in 'Python'
True

There are a couple of additional lines to add to /boot/config.txt

dtoverlay=imx219 if you're using a Raspberry Pi Camera V2.x camera_autodetect=1 dtoverlay=vc4-kms-v3d

The latter 2 are added when you run raspi-config and configure for camera but the imx219 is needed for V2.x cameras.

The code to use the libcamera-still program is:

 subprocess.run(['libcamera-still', '--width=300', '--height=300', '-v', 
'0', '-n', '-t', '1', '--sharpness', '-100', '-o', filename])

which replaces the original line using raspistill.

I have also hacked together a cube randomiser. It is pretty crude and would certainly not satisfy the WCA competition rules but it saves me juggling with a cube. It uses the BricKuber robot and brickuber_lib.py to make the moves. Unlike the WCA code it disallows successive moves on the same face. A minor point but one which offended my OCD. :-)

I can upload the modified brickuber_lib.py and Scrambler.py if you're interested.

A slight niggle: running Bullseye on my Pi3B is unstable and the system sometimes hangs. The only way to recover is to cycle power. I hold my breath each time I'm forced to do that.

BTW I reinstated all the original motor speed values to those in the original code and the cube stays in the cradle. That speeded up the overall solve time somewhat too.

Another oddity: If you present the system with a solved cube, it still comes up with a few moves which do ultimately produce a solved cube. Seems like there is a test for solved missing somewhere in the code?