Yes indeed, it does enable Pi5 support although we don’t recommend it unless you have a massive need for it.
The Pi5 generates heat and there isn’t enough room for a good heatsink, and definitely not for a fan.
Also the power button on the Pi5 interferes with the one on GoPiGo (but that can be worked around, just don’t use the power button on the Pi5).
I see I had forgotten to mention that this now all works on Trixie (and Bookworm but not older versions).
No wonder you couldn’t follow It’s all on me. Too tired after pushing this massive update.
it’s been tested for 3B+ and up, but I do believe the 2 would work too. However, it will not work on older versions of the OS. You do need to go with Trixie
And, yes, massive amount of work.
For anyone still troubleshooting, it can also help to verify the software versions on both the Raspberry Pi and GoPiGo, since a mismatch there can sometimes cause odd behavior. A clean update and reboot solved a similar issue for me.
If you have not already run the Option A install, you can use Option B:
If you have already done Option A, then:
The new install does not require /home/pi anymore so you can clone the old /home/pi/Dexter anywhere like “~/Dexter/” (or if you are user “pi” it will end up in /home/pi/Dexter/ just like always was)
cd ~
mkdir Dexter
cd Dexter
git clone https://github.com/DexterInd/GoPiGo3.git
Note:
gpg_config.json is no longer in /home/pi/Dexter/ and is now (note dot and 3) ~/.gpg3_config.json under “~” whoever that is - /home/pi or /home/myweirdusername/
same with the list of serials pickle file: now ~/.gpg3_list_of_serial_numbers.pkl
What’s the difference between mr-gogigo3 and what happens when I run git clone https://github.com/DexterInd/GoPiGo3.git?
Is the ~/Dexter directory, or a rsync from an older installation necessary?
I am assuming that this will install the easySensors libraries too, right?
I tried a test-install and noticed it creates a virtual environment. How does that affect the use of the robot compared to the way we used it before in a non-virtualized environment? Do I have to “enter” the virtual environment first?
doing a pip install (Option A) puts EVERYTHING in the virtual environment
even the examples are there, but they are deep-deep in a Python package - did I say DEEP? Yeah it is all there but totally not convenient the way I need it.
When you run just the git clone - it brings down all the source, examples, that used to be under /Dexter/GoPiGo3, to your machine - but that is it, no install, no virt env creation
Option B takes that git clone a step further and explains how to perform the same install that the pip install (Option A) does using the cloned code.
is /Dexter necessary?
NO, BUT… I want to make copies of things, and sometimes run things without making a copy. Like I mentioned it is all deep in the virtual environment, but the copy command is a nightmare to navigate and I sort of know where to look under ~/Dexter/GoPiGo3
NO - you can always open a browser to Github/DexterInd/GoPiGo3 if you want to review the API or some example
No, but I like it local.
It is not sufficient - never was - the R4R repo and the Sensors repo have never been on the machine and I find I have to go to the Github/DexterInd site for those anyway.
4a) How does that affect the use of the robot compared to the way we used it before in a non-virtualized environment?
Simple or traditional usage - no diff
From inside ROS or other programs not running inside the virt env, you cannot just type python3 xyz.py because it will run /usr/bin/python3 which does not have the GoPiGo3 packages. You must use the path to the python3 interpreter inside the virtual environment if you are not in the virtual environment:
python3
>>> import easygopigo3
package easygopigo3 not found
you are not in the virtual environment, and should be.
4b) Do I have to “enter” the virtual environment first?
Yes - but if when you do the install you answer the question to startup in the virtualenv the install will append the command into your ~/.bashrc
# >>> GoPiGo3 virtual environment >>>
if [ -f "/home/ubuntu/.venv/gopigo3/bin/activate" ] && [ "$VIRTUAL_ENV" != "/home/ubuntu/.venv/gopigo3" ]; then
. "/home/ubuntu/.venv/gopigo3/bin/activate"
fi
Note I named my virtual environment gopigo3, I hate the default (venv).
I want to know what virtual environment I am in - virtual environments have been “Pythonic” forever and we GoPiGo3 folk have been the Python luddites. @cleoqc has done an amazing thing here with the Trixie install and Python install. So many hoops to jump through (for us) so just let the install autostart in the venv and you will never know the difference.
Oh and is or was something that moved down a level in the dist packaging - I can’t find it right now. There were “compatibility” packages that imported the new location - I don’t see it when I roll through the source on git right now. maybe that is no longer.
I installed the GoPiGo system onto Raspberry Pi O/S Trixie, (as opposed to Ubuntu, etc.), and I have some interesting results.
I discovered a fault with the Waveshare epdconfig.py driver, which is the driver that handles the hardware abstraction for the rest of the Waveshare drivers. It turns out that when the Waveshare driver grabs and releases the CE0 SPI chip-enable pin, it doesn’t drive the pin high, (inactive), and since CE0 is stuck low, CE1, (the robot’s SPI control pin), cannot do anything and the robot appears to “hang”.
I have been working on a mutual SPI mutex for both the robot and whatever else wants to use it using the dexter mutex class as the base for a SPI mutex.
I made a minor edit to the easyGoPiGo class library to change the default eye color/brightness from (0, 255, 255) to (0, 10, 10) which is the same color, but much less bright which will both save battery power and increase the lifetime of the eye neopixels, as it produces about 20% of the brightness using only 4% of the power.
I tweaked the antenna service to change the WiFi antenna beacon color from purple to yellow to make it consistent with the colors used by the GoPiGo O/S software when it is in its external WiFi connection mode.
I am going to publish my “easyEPaper” library files for the three Waveshare displays I have and will produce more when I get additional displays.
P.S.
I still think all of this “venv” stuff is Much Ado About Nothing.
P.P.S.
I still have a lot of backed-up reading to do. . . .
Update:
I have discovered an interesting power issue with GPG3 installed on Raspi-Trixie - the power button isn’t being handled correctly causing it to shut down too quickly, cutting the shutdown process off at the knees.
On Buster, (and I presume earlier versions), the “running” pin was held high by the Raspberry Pi until it finished shutting down - then the “dead” Pi released the pin and the robot powered down. Trixie’s power script specifically releases it - very early - which causes a potential for a crashed system.