Let's Bang GoPiGo3 OS v3.0.1

cleoqc · October 12, 2021, 5:34pm

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…

cyclicalobsessive · October 12, 2021, 5:50pm

@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)

cyclicalobsessive · October 12, 2021, 7:14pm

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

jimrh · October 13, 2021, 8:45am

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.

cyclicalobsessive · October 13, 2021, 2:54pm

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

cyclicalobsessive · October 13, 2021, 3:04pm

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

New GoPiGo Pi B+ Dexter Raspbian Speed Difference with Older GoPiGo Pi B

We are slowly moving away from Raspbian for Robots, favouring instead direct installs on Raspberry Pi OS, or using GoPiGo OS. Raspbian for Robots was created years ago because the official os at the time was sorely lacking. However this is no longer the case. Raspberry Pi OS now comes with a VNC server, a method to boot up the Pi completely headless, including on the first boot and an easy method to change the hostname.
You can install the full suite of GoPiGo libraries and tools on Raspberry Pi OS using the following commands:
curl -kL dexterindustries.com/update_gopigo3 | bash
curl -kL dexterindustries.com/update_sensors | bash

cyclicalobsessive · October 13, 2021, 3:15pm

@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)

jimrh · October 13, 2021, 3:16pm

True.

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

jimrh · October 13, 2021, 3:24pm

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.

loringw · October 13, 2021, 3:27pm

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.

cyclicalobsessive · October 13, 2021, 3:33pm

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.

jimrh · October 13, 2021, 3:50pm

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

cyclicalobsessive · October 13, 2021, 3:54pm

@cleoqc:

The “Don’t like guardrails? Explore Raspbian For Robots” link needs to be changed to “Install GoPiGo3 Software Over PiOS” with the two update commands (and a reminder to reboot?).

jimrh · October 13, 2021, 4:13pm

3.01???
July 9th, 2021??

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

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

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.
Advertising an update over Raspberry Pi OS as a supported option for more advanced users is also a good idea.
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!

cyclicalobsessive · October 13, 2021, 4:59pm

Your point, not mine

jimrh · October 14, 2021, 10:46pm

Confirm the strange sounding audio on a Pi-4.

Sounds like it’s been modulated with a 20hz ripple.
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?

cyclicalobsessive · October 14, 2021, 11:02pm

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

jimrh · October 15, 2021, 11:58am

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

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?

cleoqc · October 21, 2021, 6:50pm

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.

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

jimrh · October 21, 2021, 7:10pm

In theory, bees can’t fly.

More importantly, we should understand that “equivalent” is not the same as “identical”.

I do not expect R4R and GPGOS to be identical, but they do need to be essentially equivalent from a development standpoint, so that work done on R4R will transfer cleanly to GPGOS. THAT is the standard I hope to achieve.

@cyclicalobsessive’s theory is that there’s a post-build kernel update that causes the distortion as, according to his reports, back-revving the kernel solves the problem.

Viz.:

His theory suggests a possibility that, at the time the GoPiGo OS was built, the “feature” that the IP address barker depends on was “built” (dkm?) against a specific kernel. For whatever reason, later kernel updates didn’t trigger either a rebuild or an update of that feature to correspond to the new kernel version.

Can you tell us what that “feature/module/package” is? This will help us help you chase this down.