It appears that the official release date - according to the first link - was March 14, and they released the March 5th beta as the production release.
Note that there are some significant “restrictions” with the GoPiGo O/S:
You may not be able to attach more than one USB mass storage device at a time - and there is the potential for data corruption if you do.
Since M/R only officially supports one mass storage device at a time, this is not high on their list. Nicole said she will research this and it might get into the next release.
Note that there is the possibility of data corruption, it’s not certain, but it’s not guaranteed to not happen either.
The viewport for the “Drive” feature is hard coded to 320x280, (or is it 480x320?), so it will appear very small on larger monitors. Since it is hard-coded you can’t change it.
There are some quirky things that happen with Bloxter that apparently have been true since day-one on the original original Bloxter.
There are a few other quirks, but no more than any other Linux release.
The good news:
The image is now not a truncated image.
You can now mount the entire image with Image Mounter and browse it.
A lot of stuff that isn’t being used, (like the original Edu-Blocks, which was an optional replacement for Jupyter in initial versions of Dexter), have been removed to make room for other, newer, features.
Because of the way the initial expansion logic works, if you plan to make a multi-boot image out of it, you should burn it to a SD card, (and boot it twice), to trigger the expansion logic so that it re-expands, then rsync the file system to the target media. Don’t forget the “H” flag to preserve hard links when you do.
I heard about it, but was waiting to give Nicole and M/R the courtesy of announcing it here first.
At the present time, the M/R policy appears to be that if an issue does not significantly impact the educational capabilities of the product, it gets a low to “won’t fix” priority. IMHO this is short-sighted, but I don’t make the rules, and I don’t know what Nicole’s time constraints for fixing stuff are. It could very well be that she’d really like to clean this up into a first-class release, but The Powers That Be limit the amount of time she can spend on a per-release basis.
Right now, (again AFAIK), educational complaints and requests get top priority and hobbyists like us - well, maybe we aren’t a lower life-form, but what we want isn’t so high on the fix-list unless it’s awful.
Again, as I said before, this is entirely up to MR to fix. Nicole has mentioned to me, (and others), that the “advanced user” can/should download an operating system release like Legacy Buster and “curl” the Dexter libraries over it.
This has the advantage of side-stepping a lot of the issues caused by the basic, web-based GoPiGo interface.
This has the disadvantage of missing out on all the Bloxter stuff - which requires the GoPiGo web interface to function properly.
We do have the privilege of cloning the repo and recommending fixes - which is the recommended pathway and they’re more likely to get included.
AFAIK, that’s a “won’t fix” because of the way Nicole forces audio out through the audio jack at boot. You may have to use raspi-config to get it to work universally.
AFAIK, the ultrasonic sensor is (at least somewhat) depreciated.
There is a known issue for the TOF distance sensor on either of the two AD ports, if there is something else on the i2c chain with it - like a line-follower. If there is, the TOF sensor doesn’t work. (I don’t know about the line follower, it may not work either but I didn’t test it.)
That’s an error in the gopigo/easygopigo library, (I forget which one).
In one of those there is a table of serial numbers that are known “16-tick”. Either it never got there or it was inadvertently removed in a recent update as Nicole pushed an update for those robots that had been converted back to 6-tick motors. Apparently some 'bots with 16-tick motors were retrofitted with the 6-tick motor and Nicole updated the “16-tick” table to reflect that.
You can fix this by adding your bot’s serial number back to whatever library has the list of 16-tick 'bots and submitting a pull request.
The list is present in ~/Dexter/.list_of_serial_numbers.pkl
pi@GoPiGo:~ $ ls ~/Dexter/.list*
and my bot is in the .pkl:
pi@GoPiGo:~ $ grep "56ECD67E515" ~/Dexter/.list_of_serial_numbers.pkl
Binary file /home/pi/Dexter/.list_of_serial_numbers.pkl matches
And making sure grep works on .pkl files by searching for something not in the file:
pi@GoPiGo:~ $ grep "56ECD67E51X" ~/Dexter/.list_of_serial_numbers.pkl
The interesting thing about the gpg_config.json file and the serial number checking is that it is supposed to happen and be created the first time a GoPiGo3 class object is instantiated, which should have occurred the first time I ran the Bloxter code that @hionhifi posted.
I don’t know much about what python gopigo3 egg the Bloxter environment uses. It is curious that there are two python3.7 eggs in GoPiGo OS 3.0.2:
pi@GoPiGo:~ $ ls /usr/local/lib/python3.7/dist-packages/gopigo3-1.3.*
Python2 only has version 1.3.0:
pi@GoPiGo:~ $ sudo find /usr/local/lib gopigo3-*.egg | grep gopigo3
find: ‘gopigo3-*.egg’: No such file or directory
That seems unusual, but what do I know?
Another thing that is weird - this morning I tried the did-not-work-yesterday code: