GoPiGo O/S 3.0.2 released!

[cyclicalobsessive]

@jimrh

I guess the folks at Modular Robotics forgot to tell us, but GoPiGo O/S 3.0.2 was released on Valentine’s Day 2022.

The .img file has a March 5 date, the Release Notes say “GoPiGo OS 3.0.2 was released in March 2022.”, and the zip title is “GoPiGo_OS_3.0.2_March_2022_Modular_Robotics.zip”.

Perhaps as a beta tester you were given Valentine’s Day love?

But as it is today March 27 and I am hearing of it first from you, Thank you for the tip.

3.0.2 in RaspberryPi imager: …Verifying… 45%

Update:

• still has garbled audio - perfectly intelligible but Dave has marbles in the mouth.
• sudo passwd does not work to permanently change robots1234 password
• sudo raspi-config → SystemOptions->Change Password worked
• Bloxter Sensor Control Panel does not offer Ultrasonic Ranger on AD1 or AD2
• IMU (Airplane), “Distance Sensor”, and servo1 work great
• (Bloxter servo reference 0 degrees is right for control horn on top / Servo Kit on top of plate)
• (Drive does not have an method to invert the camera image, or it is not obvious at least.)
  
  
• Bloxter say “Hello” works but command-line espeak-ng “hello” produces no audio and no complaint

[jimrh]

@cyclicalobsessive

The .img file has a March 5 date, the Release Notes say “GoPiGo OS 3.0.2 was released in March 2022.”, and the zip title is “GoPiGo_OS_3.0.2_March_2022_Modular_Robotics.zip”.

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:

1. 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.

2. 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.

3. There are some quirky things that happen with Bloxter that apparently have been true since day-one on the original original Bloxter.

4. There are a few other quirks, but no more than any other Linux release.

The good news:

1. The image is now not a truncated image.
   • You can now mount the entire image with Image Mounter and browse it.
      
2. 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.

Note:
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.

But as it is today March 27 and I am hearing of it first from you, Thank you for the tip.

I heard about it, but was waiting to give Nicole and M/R the courtesy of announcing it here first.

Update:

• still has garbled audio - perfectly intelligible but Dave has marbles in the mouth.
• sudo passwd does not work to permanently change robots1234 password
• sudo raspi-config → SystemOptions->Change Password worked

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.

[jimrh]

Update:

Another issue that is currently being researched:

• If a USB mass storage device is plugged in at boot time - it isn’t recognized and mounted until removed and re-inserted.

[jimrh]

@cyclicalobsessive

Drive does not have an method to invert the camera image, or it is not obvious at least.

Does the ribbon cable enter your camera from the top or bottom?

[jimrh]

still has garbled audio - perfectly intelligible but Dave has marbles in the mouth.

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.

Bloxter Sensor Control Panel does not offer Ultrasonic Ranger on AD1 or AD2

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 i²c 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.)

[cyclicalobsessive]

@jimrh

Does the ribbon cable enter your camera from the top or bottom?

The top - that is the issue - I wonder if raspi-config has a invert camera that will work in this case. Have to try that later.

[cyclicalobsessive]

Another interesting “issue” - My bot is a “16 tick” bot but GoPiGo OS v 3.0.2 defaulted it to a 6 tick bot until I ran the Calibrate and Save off the main help screen.

pi@GoPiGo:~ $ more Dexter/gpg3_config.json 
{"wheel-diameter": 66.5, "wheel-base-width": 117, "ticks": 6, "motor_gear_ratio": 120}

after calibrate, “half or double” (half), save:

pi@GoPiGo:~ $ more Dexter/gpg3_config.json 
{"wheel-diameter": 66.5, "wheel-base-width": 117.0, "ticks": 16, "motor_gear_ratio": 120}
pi@GoPiGo:~ $

Also interesting is that the About panel still said Motor Ticks: 6 after performing the calibrate and save,

but if I went back and ran a new bloxter program and then returned to the main help - it then showed 16 ticks

@cleoqc

[jimrh]

@cyclicalobsessive

Another interesting “issue” - My bot is a “16 tick” bot but GoPiGo OS v 3.0.2 defaulted it to a 6 tick bot until I ran the Calibrate and Save off the main help screen.

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.

[cyclicalobsessive]

@jimrh

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.

I checked the .pkl in git; my bot is in there.

[jimrh]

But what about the actual library on the 'bot itself?  If it’s not there, no enchiladas for you Senior!

What’s in Git may not be the same as what’s in the release. . .

I checked the .pkl in git; my bot is in there.

I really hate things like “pickle” files, especially for data, as they’re obfuscated and if something goes wrong, it’s more difficult to fix.

IMHO, data like that should be JSONified and read as a JSON, (plain-text), file.

[cyclicalobsessive]

@jimrh

But what about the actual library on the 'bot itself?

The list is present in ~/Dexter/.list_of_serial_numbers.pkl

pi@GoPiGo:~ $ ls ~/Dexter/.list*
/home/pi/Dexter/.list_of_serial_numbers.pkl

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 
pi@GoPiGo:~ $

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.*
/usr/local/lib/python3.7/dist-packages/gopigo3-1.3.0-py3.7.egg  /usr/local/lib/python3.7/dist-packages/gopigo3-1.3.2-py3.7.egg

Python2 only has version 1.3.0:

pi@GoPiGo:~ $ sudo find /usr/local/lib gopigo3-*.egg | grep gopigo3
/usr/local/lib/python2.7/dist-packages/gopigo3-1.3.0-py2.7.egg
/usr/local/lib/python3.7/dist-packages/gopigo3-1.3.2-py3.7.egg
/usr/local/lib/python3.7/dist-packages/gopigo3-1.3.0-py3.7.egg
find: ‘gopigo3-*.egg’: No such file or directory
pi@GoPiGo:~ $

That seems unusual, but what do I know?

Another thing that is weird - this morning I tried the did-not-work-yesterday code:

test.py:

#!/usr/bin/python3
import easygopigo3 as easy
import time

sensor_readings = None
gpg = easy.EasyGoPiGo3()


# start
gpg.forward()
time.sleep(1)
gpg.stop()
gpg.backward()
time.sleep(1)
gpg.stop()

and it worked, but after I created and ran the Bloxter form, the python3 test.py form stopped backing up!

…BUT running python2.7 test.py still backs up!

[jimrh]

This sounds like a job for Superman!
(Or @cleoqc!)

[cyclicalobsessive]

@jimrh

This sounds like a job for Superman!
(Or @cleoqc!)

And the budget for a full regression test suite…

[jimrh]

@cyclicalobsessive

And the budget for a full regression test suite…

. . . that she can share with us to test fixes before we open the pull request!

[cleoqc]

@cyclicalobsessive

I wonder if raspi-config has a invert camera that will work in this case. Have to try that later

There is a rotate 180 degrees, but not an invert.

[cleoqc]

@cyclicalobsessive

My bot is a “16 tick” bot but GoPiGo OS v 3.0.2 defaulted it to a 6 tick bot until I ran the Calibrate and Save off the main help screen.

Argh, I’ve had reports of this happening but could never duplicate it! Can we work on this together ?

[cleoqc]

@cyclicalobsessive

And the budget for a full regression test suite…

oh the dream! For now we follow an in-house list of things to test, which we add to as needed

[cleoqc]

@jimrh

IMHO, data like that should be JSONified and read as a JSON, (plain-text), file.

That change almost made it in… Almost … Next actual release, I guess.

[cyclicalobsessive]

@cleoqc

https://dexteros.s3.us-west-1.amazonaws.com/GoPiGo+OS/GoPiGo_OS_3.0.2_29_March_2022_Modular_Robotics.zip

@cleoqc

[16 tick not set] reports of this happening but could never duplicate it!

• Reproducible on 29March 3.0.2.1: Not recognizing 16 tick encoders until calibrate
  • Boot->10.10.10.10 Welcome to GoPiGo OS->Help (?)->Check Vital Signs reports “6 tick” encoders:
    
    
  • Test precision->Drive 6 Feet: (only goes 3 feet and very slow)->Big auto-adjust->Drive 6 feet (goes 6 feet slowly)->Cancel or Save (either seems to have actually set ticks to 16)
  • Help(?)->Check Vital Signs: Proper 16 tick reported → Drive 6 feet (goes 6 feet quickly)
  • confirmed ~/Dexter/gpg3_config.json exists and has “ticks”: 16
    
    

[cyclicalobsessive]

@cleoqc

[16 tick not set] reports of this happening but could never duplicate it!

@cleoqc In the case of 3.0.2.1 could you check if the image posted already has a ~/Dexter/gpg3_config.json file? Either it does, or something writes it before my first access.

What I did:

• Wrote (Verification passed) 3.0.2.1 image to sd card with Raspberry Pi imager
• Installed card, powered on, waited for second boot and green LED return
• Connected iPad WiFi to “GoPiGo” (10.10.10.10)
• ssh pi@10.10.10.10 with pw: robots1234
• ls ~/Dexter shows gpg3_config.json already present
• more ~/Dexter/gpg3_config.json shows “ticks”: 6