Let's Bang GoPiGo3 OS v3.0.1

GoPiGo OS, DexterOS and Bloxter
1

I believe we “old timers around here” need to get with the ModRobotics program and use their latest GoPiGo3 OS unless we are focusing on ROS/ROS2 which have specific OS requirements.

(Reference this note from ModRob to an educator)

In that vein, I’m investing some time in figuring out how to use GoPiGo3 OS instead of “old R4R” images going forward.

Ref: GoPiGo OS v 3.0.1 · GoPiGo.io

Issues so far with GoPiGo3 OS v3.0.1 downloaded from https://gopigo.io/downloads/gopigo_os:

  • Garbled Audio - intelligible but very garbled
  • I don’t like to have to use the browser WiFi setup plus Jupyter Python Terminal systemctl disable step to permanently setup my desired WiFi connection.
    I would like to figure out a “headless first boot” method similar to the PiOS wifi_supplicant.conf file on the /boot partition without starting with PiOS and adding “Dexter”, but disabling the access point service before booting seems impossible or requires mounting and removing the /etc/systemd/system link to the service.
  • I plan to stick with GoPiGo3 OS, but always keep the underlying OS packages up to date.
    sudo apt-get update gives error
$ sudo apt-get update
Hit:1 http://deb.nodesource.com/node_9.x buster InRelease
Hit:2 http://archive.raspberrypi.org/debian buster InRelease                                        
Get:4 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]                           
Hit:3 https://www.linux-projects.org/listing/uv4l_repo/raspbian/stretch stretch InRelease
Reading package lists... Error!                      
E: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
E: Unable to parse package file /var/lib/apt/lists/raspbian.raspberrypi.org_raspbian_dists_buster_main_binary-armhf_Packages (1)
W: You may want to run apt-get update to correct these problems
E: The package cache file is corrupted

I deleted the offending file:

sudo rm /var/lib/apt/lists/raspbian.raspberrypi.org_raspbian_dists_buster_main_binary-armhf_Packages

and then ran (note not “apt-get”, maybe that running apt-get twice would act the same):

$ sudo apt update
Do you want to accept these changes and continue updating from this repository? [y/N] y
...
$ sudo apt upgrade   (did not use full-upgrade)
y
midway a readme window will pop, enter "q"
2 Likes
2

Quick answer:
the sudo apt issues are due to changes that the Raspberry Pi group implemented right after the release of GoPiGo OS 3.0.1
Sigh…

3 Likes
3

@cleoqc

The upgrade needs a choice about the video4linux config file:

Setting up uv4l-raspicam-extras (1.53) ...

Configuration file '/etc/uv4l/uv4l-raspicam.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** uv4l-raspicam.conf (Y/I/N/O/D/Z) [default=N] ? D
--- /etc/uv4l/uv4l-raspicam.conf        2020-06-01 13:46:31.813047179 -0400
+++ /etc/uv4l/uv4l-raspicam.conf.dpkg-new       2021-04-09 17:57:00.000000000 -0400
@@ -49,15 +49,16 @@
 # drop-bad-frames = yes
 # relaxed-ownership = yes
 # extension-presence = no
+# unload-kernel-module = ""
 
 ##################################
 # raspicam driver options
 ##################################
 
 encoding = mjpeg
-width = 320
-height = 240
-framerate = 15
+# width = 640
+# height = 480
+framerate = 30
 #custom-sensor-config = 2
 
 ### dual camera options:
@@ -67,7 +68,7 @@
 # swap-eyes = yes
 
 ### still and/or video options:
-quality = 10
+# quality = 85
 # stills-denoise = yes
 video-denoise = no
 # raw = no
@@ -82,7 +83,8 @@
 # sps-timing = no
 # quantisation-parameter #arg
 
-### video overlay options:
+### video preview/overlay options:
+# display-num = #num
 nopreview = no
 fullscreen = no
 # osd-layer = 2
@@ -93,7 +95,10 @@
 preview = 320
 preview = 240
 
-### post-processing options:
+### some post-processing options:
+### - text overlay
+### - object detection with cascade classifiers (do not confuse with TFlite)
+### - etc...
 # text-overlay = yes
 # text-filename = /usr/share/uv4l/raspicam/text.json
 # object-detection = yes
@@ -149,6 +154,38 @@
 # recording-dir = /usr/share/uv4l/recordings
 # recording-bitrate = 800000
 
+### TensorFlow model options (the EdgeTPU accelerator is optional)
+# tflite-model-file = /path/to/ssd_mobilenet_v2_face_quant_postprocess_edgetpu.tflite # example
+# tflite-model-output-topk = 5
+# tflite-model-output-threshold = 0.25
+# tflite-overlay-model-output = no # to draw boundary boxes, scores, on the image (might slow down the framerate)
+### only consider the following object class ids among the top-k predictions:
+### zero or more object class ids (one per line) can be specified, e.g.:
+# tflite-detection-classids = 0
+# tflite-detection-classids = 43
+# tflite-detection-classids = 45
+### optional path to a file of classId labels pairs (one per line)
+# tflite-labels-file = #path
+
+### Options for pan/tilt object tracking with PID controller
+# tracking-pan-tilt = yes
+# tracking-strategy = maxarea # maxarea, all, ...
+# tracking-pan-pid-kp = 0.0055
+# tracking-pan-pid-ki = 0.00045
+# tracking-pan-pid-kd = 0.0
+# tracking-tilt-pid-kp = 0.003
+# tracking-tilt-pid-ki = 0.0005
+# tracking-tilt-pid-kd = 0.0
+# tracking-pid-p-on-m = yes
+# tracking-pan-home-position = 0
+# tracking-tilt-home-position = 0
+# tracking-home-init = yes
+# tracking-home-timeout = 15000 # in ms, 0 for no timeout
+### if pan is servo channel 1 & tilt is servo channel 2, then specify "yes" below,
+### otherwise "no" if channels are swapped
+# tracking-pan-servo-channel1 = yes
+# tracking-hat-i2c-dev = "/dev/i2c-1"
+
 ### advanced options:
 # statistics = yes
 # output-buffers = 3
@@ -271,8 +308,10 @@
 # server-option = --janus-gateway-url=https://janus.conf.meetecho.com
 # server-option = --janus-gateway-root=/janus
 # server-option = --janus-room=1234
+# server-option = --janus-admin-key=#key
 # server-option = --janus-room-pin=#pin
 # server-option = --janus-username=test
+# server-option = --janus-create-room=yes
 # server-option = --janus-token=#token
 # server-option = --janus-proxy-host=#host
 # server-option = --janus-proxy-port=80
lines 39-103/103 (END)

Should we reject or accept the new config? (I rejected for this first test)

2 Likes
4

I guess that is an oxymoron - GoPiGo3 OS is designed for “without Internet”, but updating requires Internet.

@mitch.kremm , @cleoqc Perhaps the PiOS + /Dexter is the better route? I really don’t want to be a “special case user”.

2 Likes
5

Not entirely true.

The GoPiGo OS is designed to operate in one of two possible modes:

  • GoPiGo OS is designed to be an autonomous system in its simplest form, but can still be attached to a local network temporarily for updates, (if needed), by the instructor.  It then automatically switches back to autonomous mode at the next reboot.

  • For more advanced work, the entire system can be switched to a fully networked mode where it connects to a local Wifi connection, and the changeover can be made permanent.

The only suggestions I would make are:

  • Agree with @cyclicalobsessive that there should be a way to set fully networked mode prior to boot and have it changeable at boot.  This way a jumper can be set, and then read by config.txt, to set network mode at startup.
  • There should be a way, from the switchover screen, to make the change permanent without having to jump through the command line.
     

Unfortunately, that’s the way it is, and also unfortunately, none of us knows enough about the changes to even hazard a guess.

  • It could be that accepting the changes are essential to the updated package - but they may well break existing functionality.
  • However, not accepting the changes may break the update, or other packages that depend on this update.

It’s like “Heads I win, tails yer’ hozed” and I’ll be damned if I know the correct answer.

2 Likes
6

No, the documented update method is to flash the SDcard when MR releases an update. See “Update instructions for GoPiGo OS”

2 Likes
7

Perhaps “we R4R folk” need to bang on the Pi OS + /Dexter route as @cleoqc suggests in

2 Likes
8

@jimrh Any chance we can get you “off the pot typing on your phone” to plug some earphones into Charlie, and boot v3.0.1 to verify if only I have garbled audio, or it really is a problem? (Or Maybe it only happens on Pi3B+ and not Pi4s)

2 Likes
9

True.

I haven’t been able to get a 64bit “Raspbian for Robots” working yet.

1 Like
10

You gotta talk to “the boss” about that one.

She has a “honey-do” list where each item “only takes a few minutes” - but these are what I call “metric minutes”, where one metric minute is something like 15 to 30 times the length of an “imperial” minute.

I type on the phone while I am waiting when I chauffeur her around.

I usually only get to work on things after everyone else goes to bed.  And then I catch hell about why I don’t go to bed at a reasonable hour!

Go figure.

I will try to do that but I won’t guarantee the results are valid as it not a “plain-vanilla” install, being twisted and munged to allow for multiple operating systems booting.

2 Likes
11

I am going to try both routes for my students. They are currently using R4R, which is working fine after the 16 motor tick adjustment. I am not going to change horses on them in mid-gallop.
With the overhead of GoPiGo3 OS, I am probably going to go with Raspberry Pi OS + GoPiGo code installs. For my students, I would rather they worked with the PiOS, as that is what they will see going forward. Much more standards based pedagogical approach.

2 Likes
12

I’m convinced that is the best approach for “post R4R” uses.

I need to be able to install/update the latest OpenCV or update to the latest TensorFlow-lite without worrying about breaking the GoPiGo3 OS features.

I’m going to continue to always try new GoPiGo3 OS versions “as is” to function as an unofficial beta tester, and also test a constantly updated PiOS with Dexter/ModRobotics approved install/update scripts since this is the other approved use.

2 Likes
13

AFAIK. . .

That applies to situations where the basic GoPiGo OS features are being used and the instructor may not know his way around a Linux clone.

For more advanced instructors, or more advanced situations, updating in situ has been recommended by Nicole.  (Unless I am loosing my mind, which isn’t that far-fetched.)

2 Likes
14

@cleoqc:

Latest_GoPiGo3_OS
Latest_GoPiGo3_OS1557×903 126 KB

2 Likes
15

3.01???
July 9th, 2021??

I wonder if I am a back number?  I should check.

Oh, and BTW, @cyclicalobsessive has a good point.

  1. I think characterizing GoPiGo OS as “having guardrails” and/or training wheels gives the wrong impression, as GoPiGo OS is a fully capable and worthy successor to Raspbian for Robots.

    • It can have training wheels, but, unlike Dexter OS, they’re not mandatory.

  2. Advertising an update over Raspberry Pi OS as a supported option for more advanced users is also a good idea.

  3. As I have said elsewhere, I believe that the ability to specify the GoPiGo operating mode at startup, (Blockly as an access point or Raspbian as a network connected robot), would be a beneficial improvement - not to mention making my like easier!

2 Likes
16

Your point, not mine

2 Likes
17

Confirm the strange sounding audio on a Pi-4.

  1. Sounds like it’s been modulated with a 20hz ripple.

  2. Could they have found a more British sound for the voice?  Jolly good show, old boy!

I remember there being a problem with pulse audio in the past, but I am not sure that this is the problem as other audio sources, like videos, play OK.

Maybe it’s the audio source itself?

2 Likes
18

No, it might be some sort of kernel mismatch thing. I’ve solved it before by “back dating” the kernel after taking all the updates for buster. I thought maybe updating GoPiGo OS would fix it, but no cigars.

Then again there is the introduction of pulseaudio over ALSA in the recent PiOS and perhaps GoPiGo OS needs to remove that. Linux audio is a real can of worms.

MR will need to solve this time. @mitch.kremm

2 Likes
19

@cleoqc,

Up until now, my major development efforts have been confined to Raspbian for Robots, with the occasional side-trip to GoPiGo OS to check things out and/or confirm something.

I am now preparing to restart my test and development efforts, now that the major power supply project has ended.  (I still need to calibrate the current ranges, but that’s piddle once I get some standardized load resistors.)

My big question for you, (Nicole), is:

  • Where should I place the bulk and brunt of my development efforts?

I can:

  • Abandon Raspbian for Robots and “transfer my flag” (so to speak) entirely to GoPiGo OS?

    • This will involve “picking up” my entire development environment and configuration(s), transferring them in toto to GPGOS, re-verifying everything, chase down any issues, and then continue from that point.
       

  • Continue my development on R4R as I have done before?

    • Due to the length of time I have been away, I will also need to “re-verify” things, (but possibly not as extensively), just to remind myself where I was at. :wink:

My gut feeling is to place the majority of my effort within GPGOS, and save R4R for the occasional verification issue.

However, I am not totally convinced that GPGOS is functionally equivalent to R4R and I am concerned about variations in the overall development environment.

For example:  Yesterday, while I was experimenting with GPGOS’s audio and the startup “barker” for the IP address, I played a few videos from a NAS (SMB) server I have, using both R4R and GPGOS, using VNC’s player.

  • Video playback on R4R was smooth and flawless.

  • Video playback on GPGOS was choppy.  The audio was fine but every thirty seconds or so, the video would freeze momentarily.

Is this caused by other background processes running within GPGOS that aren’t running in R4R?  If that’s so, how do I isolate them to determine what processes, if any, are the culprit?

This both puzzles and concerns me, and makes me wonder if GPGOS is truly equivalent to R4R as a development environment.

I want to help, and I want to “get with the program” per se, but I’d really rather not waste valuable development time chasing red herrings caused by a non-standard environment.

One other thought:

A third option might be to transfer my flag to GPGOS and begin work there, not so much to finish my projects, (though that would be nice), but for the specific purpose of deliberately testing to disclose, and (hopefully) isolate discrepancies between the two operating systems so that GPGOS and R4R become truly equivalent.

What say ye?

2 Likes
20

Sorry I missed this thread… Very interesting thread though!

In theory GoPiGo OS and VNC viewer should give you almost the same experience than straight Raspberry Pi OS. There are two limitations.

  1. the network icon in the desktop top right corner won’t work. You need to go through the browser interface to disable the access point.
  2. the way usb drives are detected is slightly different.
    In Raspberry Pi OS, only the pi user can write to a usb drive, while GoPiGo OS also has a jupyter user.

I have no idea why audio would be garbled.

3 Likes