Suggestions for updates to GoPiGo O/S 3.0.1

jimrh · December 22, 2021, 2:12pm

Greetings:

(Inviting @cleoqc and @mitch.kremm to snoop this thread out.)

As you all know, I have taken it upon myself to work on the current GoPiGo O/S release with the view of making it work after an update:

Viz.:

As a result of this, I have learned a LOT about what makes the GoPiGo O/S “tick” from the point-of-view of being a GoPiGo operating system.

Going with the idea that @cyclicalobsessive and I have mentioned before that, (IMHO), instead of chasing Bullseye to create a new operating system, Modular Robotics should concentrate on fixing what they have. . .

. . . And - I received a recent “support” e-mail from Mitch telling me that, among other things, Cleoqc, (Nicole), has been moved to a different project but will be getting back to the GoPiGo O/S (hopefully soon!), and will work with all the suggestions we’ve made up to this point.

What I want to do at this point is:

Accumulate, all in one place, the various suggestions on how to improve the existing GoPiGo O/S 3.0.1.
Examine each suggestion and see what I can do about implementing them.
Since I am absolutely sure that this will disclose yet other issues, they would go on the list for resolution.
Continue what I am doing with the current rev GoPiGo O/S.

At the present time, I would appreciate any and all suggestions, (including prior suggestions mentioned in other threads), be re-posted here. Later on, I will ask for volunteers to test the revisions I create.

What I have currently implemented:

Repackage the current GoPiGo release as an intact - non-truncated - image with filesystem irregularities eliminated.
Completely disable IPv6 in this image.
(Possibly) Make the GoPiGo 3.0.1 release work after a soup-to-nuts update.
The corrected “V3” image can be found here:
https://www.mediafire.com/file/dm2tdlwaem4ivs7/GoPiGoOS3.0.1_V3.img.zip/file

Any help and suggestions are - as always - gratefully appreciated.

cleoqc · December 23, 2021, 3:48pm

This is correct, but the GoPiGo is definitely not dead!
We have a history of lagging behind the official Pi OS version by at least a year, to let the dust settle in. Any new OS from Pi Tradings tends to get a quick series of very important updates early on, and then stabilizes. We’ve learned in the past that this led us on wild geese chases for very little return.

A 3.0.2 will be coming soon-ish (I might find time during my Christmas time off)

@jimrh
All tickets that you send us are getting saved, and I will go through them when I get around to 3.0.2

That said, don’t spend too much time on re-creating a new image, as we would not be able to distribute that one. If it amuses you, then sure go ahead! But it will not become the official image for legal reasons.

Happy Holidays!

KeithW · December 23, 2021, 9:56pm

I hope you actually take TIME OFF for Christmas . I’m sure @jimrh won’t mind waiting a little bit longer

Happy holidays to all.
/K

jimrh · December 24, 2021, 12:47am

My thoughts are like this:

I am learning a lot about what makes Raspbian, and especially the GPGOS, tick.
Even if you CAN’T use my images per-se, they provide a bunch of pre-reasearched fixes and ideas. That is, I’ve tried things and discarded what doesn’t work. Hopefully this will help you with your eventual release cycle once you get back to it.

In any event, have a nice holiday!

jimrh · December 24, 2021, 2:17pm

As much as I would like to see a 3.0.2 soon, you might want to wait for me to figure out a couple more problems - like garbled sound.

Nicole,
As you may have guessed, there has been a wailing and gnashing of teeth here, both publicly and privately about what goes on behind the scenes. As much as I’d like to have a better view into what’s going on, it’s probably none of my business.

I also am very confident that you’re as busy as a cat with two tails.

This leaves me two choices: Complain or do something about it.

I’ve decided to “do something about it” instead of complaining - and since I happen to be as close as anyone else here to being a “subject matter expert” on the GoPiGo O/S, I figured I’d take a stab at it.

And it’s not “amusement” per-se, but rather it’s something that needs to be done, and since I can help do it, I do. It’s a part of what makes FOSS/Open Source great, we all pitch in and try to make a difference.

I build on what you and others have done. You and others build on what I have done. This way we get more done, hopefully better, than one person can do himself.

Kinda’ like tag-team wrestling - you hold 'em while I hit 'em!

The payoff to me is that I am learning a lot about what makes things tick in a better way than I would have before.

The corresponding payoff to everyone else is that I can make something available for others to try while you’re busy with other things.

And please don’t rush into this. Take your time, relax, and let’s work together to make this the best release so far.

What say ye?

jimrh · December 24, 2021, 2:40pm

One gripe I am researching:

GoPiGo O/S absolutely INSISTS on using the headphone jack for output!

The desired and optimum behavior should be:

If a headphone is NOT plugged in, audio out = HDMI
If a headphone IS plugged in, audio out = 3.5mm headphone jack.

Every computer system I have ever used since the time computers ran off of wood fires and steam, distinguished between monitor based sound and headphone jack based sound, and automatically switched between them.

My laptop does this.
My Android based smartphone does this.
Every other electronic device with sound output, speakers, and an audio jack does this.

Question:
How do we make GPGOS do this?

Second question:
How do we switch from that absolutely horrid British voice? It sounds like he’s got a sock up his nose - or the sinus infection from hell!

cyclicalobsessive · December 24, 2021, 3:23pm

My opinion - for robots assuming the headphone out is the correct default.

That said, you would need to learn all you can about what status the HDMI port can give you.

Can you tell if something is plugged into [one or two of] the HDMI port?
Can you tell if one, or both of the HDMI devices offer sound?

Again my opinion, the default voice is the most intelligible of all the standard voices espeak-ng ships with.

$ espeak-ng --voices=en
Pty Language       Age/Gender VoiceName          File                 Other Languages
 2  en-gb           --/M      English_(Great_Britain) gmw/en               (en 2)
 3  en-gb           --/M      english-mb-en1     mb/mb-en1            (en 2)
 2  en-us           --/M      English_(America)  gmw/en-US            (en 3)
 5  en-gb-scotland  --/M      English_(Scotland) gmw/en-GB-scotland   (en 4)
 5  en-gb-x-gbclan  --/M      English_(Lancaster) gmw/en-GB-x-gbclan   (en-gb 3)(en 5)
 5  en-gb-x-rp      --/M      English_(Received_Pronunciation) gmw/en-GB-x-rp       (en-gb 4)(en 5)
 5  en-us           --/M      us-mbrola-2        mb/mb-us2            (en 7)
 5  en-us           --/F      us-mbrola-1        mb/mb-us1            (en 8)
 5  en-us           --/M      us-mbrola-3        mb/mb-us3            (en 8)
 5  en-gb-x-gbcwmd  --/M      English_(West_Midlands) gmw/en-GB-x-gbcwmd   (en-gb 9)(en 9)
 9  en              --/F      en-german-1        mb/mb-de1-en         
 9  en              --/M      en-german-2        mb/mb-de2-en         
 9  en              --/F      en-german-3        mb/mb-de3-en         
 9  en              --/M      en-german-4        mb/mb-de4-en         
 9  en              --/F      en-german-5        mb/mb-de5-en         
 9  en              --/M      en-german-6        mb/mb-de6-en         
 9  en              --/M      en-greek           mb/mb-gr2-en         
 9  en              --/M      en-romanian        mb/mb-ro1-en         
 5  en-029          --/M      English_(Caribbean) gmw/en-029           (en 10)
10  en              --/M      en-dutch           mb/mb-nl2-en         
10  en              --/M      en-french          mb/mb-fr1-en         
10  en              --/F      en-french          mb/mb-fr4-en         
10  en              --/F      en-hungarian       mb/mb-hu1-en         
10  en              --/F      en-swedish-f       mb/mb-sw2-en         
11  en              --/M      en-afrikaans       mb/mb-af1-en         
11  en              --/F      en-polish          mb/mb-pl1-en         
11  en              --/M      en-swedish         mb/mb-sw1-en         
 5  variant         --/M      Storm              !v/Storm             (en-us 5)

and here is everything I know about Espeak Text To Speech - OLD! Some may be wrong:

Espeak TTS

(Using espeak-ng now) 

espeak-ng "Hello there"

espeak-ng -a 7 "this is a whisper"

espeak-ng 2>/dev/null "with no error messages"

espeak-ng -ven-us+f3 -s 130 "female US English"

espeak-ng -ven-german-1 "german female voice 1"

languages: en-us, en-sc(ottish), 

variants: +f2 f3 f4 f5 whisperf m2-m7, whisper f1(old), m1(old)

(https://www.dexterindustries.com/howto/make-your-raspberry-pi-speak/)

==== Fix TTS on Raspbian For Robots (a long time ago)
sudo apt-get remove -y espeak
sudo apt install -y espeak espeak-ng python3-espeak speech-dispatcher-espeak

pip3 install espeakng



========= Loading TTS ========

dpkg -s espeak-ng  (to check if installed)
sudo apt-get install espeak-ng

test:  espeak-ng “hello”
to not see all the error msgs:  espeak-ng 2>/dev/null

Fix error msgs:  If you get the following error message:

ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.front
Edit the file /usr/share/alsa/alsa.conf:

sudo nano /usr/share/alsa/alsa.conf
change the line “pcm.front cards.pcm.front” to “pcm.front cards.pcm.default”

---
# Alan: change to get rid of espeak errors
# pcm.front cards.pcm.front
pcm.front cards.pcm.default

pcm.rear cards.pcm.default
pcm.center_lfe cards.pcm.default
pcm.side cards.pcm.default
pcm.surround40 cards.pcm.default
pcm.surround41 cards.pcm.default
pcm.surround50 cards.pcm.default
pcm.surround51 cards.pcm.default
pcm.surround71 cards.pcm.default
pcm.iec958 cards.pcm.default
pcm.spdif iec958
pcm.hdmi cards.pcm.default
pcm.dmix cards.pcm.default
pcm.dsnoop cards.pcm.dsnoop
pcm.modem cards.pcm.default
pcm.phoneline cards.pcm.default


now restart alsa utils
sudo alsactl init  - to reset alsa something
sudo alsa force-reload

(There will still be some errors like bluealsa)

==== add tts alias
.bash_aliases:
alias tts='espeak-ng 2>/dev/null '

then:
. .bashrc


==== using espeak in python

#!/usr/bin/python
#
# speak.py   Speaker utilities
#
#  say(phrase)  do not include apostrophes in phrase

import subprocess

def say_espeak(phrase):
    subprocess.check_output(['espeak-ng',phrase], stderr=subprocess.STDOUT)

def say(phrase):
    say_espeak(phrase)

# ##### MAIN ####
def main():
    say("hello from speak dot p y test main")

if __name__ == "__main__":
    main()


==== espeak broken after OS update/upgrade  Sept 2019

tried 
sudo apt-get remove libpulse0

  This removed:
  espeak ffmpeg gstreamer1.0-plugins-bad libav-tools libavdevice57 libespeak-dev libespeak1 libfluidsynth1 libmikmod3 libpulse0 libsdl-image1.2 libsdl-mixer1.2 libsdl-ttf2.0-0 libsdl1.2debian
  libsdl2-2.0-0 libsmpeg0 libsox-fmt-all libsox-fmt-pulse mplayer python-pygame python3-pgzero python3-pygame

sudo apt-get install espeak
  The following NEW packages will be installed:
  espeak libespeak1 libpulse0




nano /home/pi/.bashrc
PA_ALSA_PLUGHW=1
export PA_ALSA_PLUGHW

source .bashrc


===== python tts example

sudo apt-get install espeak-ng python-espeak-ng python-pyaudio
pip install pyttsx3

import pyttsx3

engine = pyttsx3.init()
voices = engine.getProperty('voices')
engine.say('Hello from Python')
engine.runAndWait()

jimrh · December 24, 2021, 3:49pm

. . . and as far as that goes, you are absolutely correct - especially since a large percentage of robots will use something plugged into the headphone jack.

But, not unlike wanting headless network configuration, this may not always be true. The suggestion I made solves both problems.

Now, as far as I can see, espeak-ng does not have any kind of configuration file. If I want to set a default voice, gap, word-rate, etc to make things most intelligible, I have not discovered how to do it. There are some defaults in /etc/pulse and /usr/share/alsa, but none of these seem to affect espeak-ng.

Oh, by the way, I have found that, on my system and using my headphones, an amplitude of 30 gives the clearest voice at a reasonable volume. Anything higher than that causes clipping. Of course, YMMV.

Another data-point:
There is anecdotal evidence that using a three-contact headphone plug into the four-contact Raspberry Pi headphone jack, can cause garbled sound, (especially at startup), as video information is being mixed with the audio information. Note that I have not tested this as I do not have a three-contact to four-contact adapter. If I can find a smartphone headset with microphone, (which has the four-contacts), I will try it.

There is also anecdotal evidence that a kernel back-rev solves the issue.
@cyclicalobsessive, what kernel do you use?

cyclicalobsessive · December 24, 2021, 4:18pm

BTW, amixer on my “GoPiGo3 over Legacy PiOS” shows HDMI,0 even after I change audio to headphones with raspi-config… I’ll never understand ALSA. Sound is good on Legacy.

pi@Carl:~/Carl $ uname -a
Linux Carl 5.4.72-v7+ #1356 SMP Thu Oct 22 13:56:54 BST 2020 armv7l GNU/Linux


pi@PIOSLGCY:~ $ uname -a
Linux PIOSLGCY 5.10.63-v7+ #1496 SMP Wed Dec 1 15:58:11 GMT 2021 armv7l GNU/Linux

jimrh · December 24, 2021, 5:02pm

Absolutely true.
@cleoqc, can you tell us where the voice defaults are and what sets up which output will be the default? I am especially interested in the command-string as part of the problem may be the amplitude setting is too high and it’s clipping and going nuts.

I discovered wandering around on the Internet, a site that mentioned a couple of locations:

/etc/speech-dispatcher/modules/espeak.conf
/usr/lib/speech-dispatcher-modules/sd_espeak
[was ./lib64/... but we do not have that]

There are also interesting files in /etc/alsa and /etc/pulse

(P.S. Does anyone know how to turn off syntax highlighting within code blocks?)

Unfortunately, none of these seem to do anything to help.

Also, I tried a four-contact headset and there is no change.

@cyclicalobsessive,
You mention that the startup barker that repeats the IP address is “incessant” until disabled. This is interesting. Is this true for Carl or is it just for Dave as, on my system, it repeats twice and stops.

Do you know what the barker routine is or where it’s located? I’m going to snoop, especially in the rcX.d scripts, but the way my luck is going, I’m not holding my breath.

P.P.S.
Anyone who wants to punt this for a few days, get some eggnog, (and put a shot of The Old Bushmills in it), is perfectly welcome - it IS Christmas Eve for Christ’s sake! (Pun absolutely intended.)

Update:
/etc/pulse/default.pa has as (the last line on my system) the line set-default-sink 1. The default value is “0” which is the headphones. Setting this to “1” makes the HDMI output sticky for everything EXCEPT espeak-ng.

cyclicalobsessive · December 24, 2021, 6:27pm

No, I didn’t. The accessibility wav file is the nag - only on Legacy PiOS and Bullseye PiOS.

I explained the IP announcer (my version which is based exactly on MR’s) in the ubuntu setup script. It is a run once service called ip_feedback. You could add an espeak-ng volume option there if you want to try lowering the ip feedback.

cyclicalobsessive · December 24, 2021, 7:13pm

This has been in flux. I found out why my old method of setting for headphone out no longer works for Legacy and Bullseye.

jimrh · December 25, 2021, 9:58am

I snooped that file out and it’s a revelation!

I suspect that Nicole sneaked in a -d hw:headphones parameter as there’s a specific comment that this forces headphone output for the IP barker come Hell or High Water.

Additional research disclosed that many sites on the web that deal with Linux audio start with the disclaimer: “Linux audio is a formidable challenge.” In other words, it’s easier to design a multi-kilowatt class D audio amplifier with zero distortion from 20 Hz to 20 KHz, ( ), than to make sense out of Linux’s audio processing.

/etc/pulse seems to have a lot of the defaults - but it appears that many applications, (VLC is a good example) simply ignore the usual paths - the task-bar audio levels don’t apply and the pulse-audio/alsa settings are also ignored.

I tried reducing the volume on the command line in ip_feedback, but that doesn’t work either.

Next step is to try your kernel revision.

. . . and why was that? What changed and what did you have to do?

jimrh · December 25, 2021, 2:44pm

Update:

Audio is solved!

I have a totally working solution for the “garbled IP barker” that is a trivial fix, and does not require messing with the kernel.

Summary:
To eliminate the audio garbling on the IP address barker:

Remove the -d hw:CARD=Headphones from each of the four lines in /opt/Sam_Dev/install/ip_feedback.sh.
Edit the set-default-sink value in /etc/pulse/default.pa and /etc/pulse/system.pa to direct the default audio output to either HDMI or the audio jack.

Issue:
When the IP address is read through the headphone jack at initial startup, the sound is garbled as if it were being modulated with a 20Hz interfering signal, however normal espeak-ng output works fine.

Problem:
In the file /opt/Sam_Dev/install/ip_feedback.sh there are three lines:

 su -c "espeak-ng -d hw:CARD=Headphones 'WiFi IP'" pi
 su -c "espeak-ng -d hw:CARD=Headphones $IP_NUMBER" pi
 su -c "espeak-ng -d hw:CARD=Headphones repeating "  pi
 su -c "espeak-ng -d hw:CARD=Headphones $IP_NUMBER" pi

at lines 40-43 in this file.

The particular part of these lines is the -d hw:CARD=Headphones part. This was deliberately placed to force output through the audio jack regardless of what the normal system settings might be.

Solution / Workaround:

Remove the -d hw:CARD=Headphones part of those three lines.
Viz.:

su -c "espeak-ng 'f'" pi
su -c "espeak-ng 'WiFi IP'" pi
su -c "espeak-ng $IP_NUMBER" pi
su -c "espeak-ng repeating "  pi
su -c "espeak-ng $IP_NUMBER" pi

Note that the first line, (“f”), is not heard, but produces enough of a pause so that the entire second line’s phrase is spoken.

Removing the hard-coded redirection to the headphones resolves the garbled audio.

It has the unfortunate, (depending on the use-case), side effect of allowing the IP-address barker to use the system specified audio device, either HDMI or the audio jack.

Workaround:
In /etc/pulse there are two configuration files: default.pa and system.pa. The very last line in each of the two files is set-default-sink x where “x” is the device to use.

“set-default-sink 0” supposedly means “automatic”, which I am assuming is set by the presence or absence of the particular audio setup line in /boot/config.txt - either HDMI or the audio jack.

“set-default-sink 1” sets the default system audio output to the headphone jack.

~~“set-default-sink 2” sets the default system audio output to HDMI audio output.~~

Update:
It appears that the documentation lags behind the current functionality just a bit.
The correct mapping, (as best as I can figure out), is:

“set-default-sink 0” sets the default system audio output to HDMI.
“set-default-sink 1” sets the default system audio output to the headphone jack.

/Update

Note that, when set this way, any device that produces audio and does not specify a different audio output device will use whatever is set here.

Since the “default.pa” is, (supposedly) used for userland audio processes and system.pa is used for audio calls from the system itself, I set both to the same value. I have NOT tried setting them differently.

What I suspect is happening is that setting any “-d” value for espeak-ng writes directly to the output hardware device bypassing audio buffering and stream handling as setting it to either an HDMI device or the audio jack produces garbled sound.

Please experiment with this and tell me what you find.

cyclicalobsessive · December 25, 2021, 2:59pm

I don’t know exactly. The readme stated they were introducing pulseaudio to be more consistent with other Linux distros, but I don’t know exactly. It is my impression that the developers of espeak, and the currently supported version espeak-ng (“espeak next generation”), designed it to work under the multitude of Linux configs.

I ran “sudo raspi-config, SystemOptions->Audio->Headphones”

To get the microphone to work with arecord, I modified two ALSA config files but I don’t know why or which one does what.

This is my /etc/asound.conf:

pcm.!default {
  type asym
  playback.pcm {
    type plug
    slave.pcm "output"
  }
  capture.pcm {
    type plug
    slave.pcm "mic"
  }
}

pcm.output {
	type hw
	card 1
}

ctl.!default {
	type hw
	card 1
}

pcm.mic {
  type plug
  slave {
    pcm "hw:2,0"
  }
}

and this is my /home/pi/.asoundrc:

pcm.!default {
  type asym
  playback.pcm {
    type plug
    slave.pcm "output"
  }
  capture.pcm {
    type plug
    slave.pcm "mic"
  }
}

pcm.output {
	type hw
	card 1
}

ctl.!default {
	type hw
	card 1
}

pcm.mic {
  type plug
  slave {
    pcm "hw:2,0"
  }
}

defaults.pcm.card 1
defaults.ctl.card 1

cyclicalobsessive · December 25, 2021, 3:03pm

This is the command line I use to adjust the volume for espeak-ng:

subprocess.check_output(['espeak-ng -s150 -ven-us+f5 -a'+str(vol)+' "%s"' % phrase], stderr=subprocess.STDOUT, shell=True)

jimrh · December 25, 2021, 3:06pm

Maybe modifying /etc/pulse/default.pa and system.pa would work and be less complicated?

Viz.:
The last four lines in each config file:

### Make some devices default
#set-default-sink output
#set-default-source input
set-default-sink 1

Maybe setting default source input would work?

jimrh · December 25, 2021, 3:09pm

Is this a global setting, as opposed to a per-command “-a [value]” setting?

It turns out that the actual problem was trying to drive the hardware device directly instead of using the alsa/pulse buffering and streaming.

cyclicalobsessive · December 25, 2021, 3:19pm

Next time I try setting up GoPiGo over a new Legacy OS or Ubuntu card, I’ll give your fix a try. Perhaps I won’t have to remove pulseaudio, but while it appears you have solved the audio out issue, getting the audio in to work has always been the more significant challenge for me.

jimrh · December 25, 2021, 4:25pm

And that is perfectly OK. That’s all I ask anyway.