I didn’t want to do it (Break Dave apart), but I felt compelled to try.
Raspberry Pi5 first boot powered by the GoPiGo3 red board:
.
For want of shorter M2.5 screws and longer M2.5 standoffs, I still have to work out the physical mount to the GoPiGo3 platforms.
.
40 Pin Stacking Header
Just missing one cable I can’t find (from when Create3-Wali stole Dave’s Oak-D-Lite camera)
After installing GoPiGo3 software, the Pi5 boots up, thinks about something and decides to reboot.
Not a good sign.
Seems like my Bookworm on Pi4 success will not translate to Bookworm on Pi5 success. Major bit-banging mod ahead.
*** GoPi5Go Dave TOTAL LIFE STATISTICS ***
Total Awake: 0.45 hrs
Total Naps: 0.05 hrs
Total Life: .50 hrs (since Mar 17, 2024)
Sessions (boot): 3
Average Session: .1 hrs
Safety Shutdowns: 0
Total Travel: 0.0 meters 0 feet
Good luck. Looking forward to more adventures of Dave.
/K
Not surprising, given what I’ve seen with the Nano.
That’s actually a good sign. It’s trying to do something which is far and away from sitting there doing absolutely nothing.
Do you have a 3.3v logic serial to USB interface board? (Commonly called a FTDI because it uses the Future Technology’s serial to USB interface IC.)
If I remember correctly, the Raspberry Pi has a serial console that is available on the GPIO pins, (and I think the Pi-5 has it broken out to a separate header), that you can use to monitor the boot process.
This was invaluable to me when I was trying to troubleshoot boot issues with the Nano.
Maybe there’s something in the logs if you plug the SD card into your Mac?
I’m pretty sure it was the gpg power service which uses GPIO access to watch the GoPiGo3 “power button” to trigger a safe shutdown that caused it.
That’s another function for the “not required list” for my GoPi5Go port.
I’m going to start by commenting out GPIO and software I2C stuff in gopigo3.h/.cpp and leave all SPI and hardware I2C calls untouched, since the major Pi5 issue is likely the changed GPIO hardware interface.
WHAT?!!
What “changed” GPIO interface??? 
How to Control the Raspberry Pi 5 GPIO with Python 3 | Tom's Hardware.
The Raspberry Pi 5 has just been released and it introduced us to a more powerful Pi, but it also changed a few things and most notably it was the GPIO.
We still have the same 40-pin GPIO but it works a little differently now as it is connected to the new RP1 southbridge chip. Why does this matter? Well it all boils down to how we write code that interacts with the GPIO
… how the GPIO pins are memory mapped. This forces us to use an alternative, and libgpiod is the focus of this how to.
Libgpiod, specifically python3-gpiod is a pure Python module for interacting with the GPIO.
Ps. Additional changes in the window and display managers probably mean none of the GoPiGo3 desktop functions will work, but that is a Bookworm thing not specific to Pi5
Getting GPIO functions are not on my need to have list so I’m going to comment out anything having to do with it.
Thus the question “Why GoPiGo3 with Pi5/Nano if you lose so much?”
I think I’m going to switch to trying to bring up the GoPiGo3 C++ API rather than the Python API.
Guess I’m going to have to get deep into the GoPiGo3 theory of operation (that was never documented).
Maybe you should submit a pull request to update the GPG documentation?
This way everyone can benefit from your efforts.
Let’s not get ahead of ourselves…I have zero insight to the inside of the GoPiGo3 brain chip.
I see a command that goes into “the brain”, and do not see the arms or legs moving.
I see two lines in MY Test Code that are suspicious, so I am not predicting to advance any theories. I’m working in C++ which is 15 years or more rusty.
I think I know what is going on - my hypothesis: Perhaps without the gpg_power.service running, the red board thinks it should not put power to the motor and servo, like when the red board is powered from the processor, not from batteries through the barrel connector.
The only way to confirm this is to get GPIO working on the Pi5 using that tomshardware replacement for RPI.GPIO in gopigo3_power.py
import RPi.GPIO as GPIO
After executing gpioset 4 23=1 my robot.cpp drives GoPi5Go-Dave!
Now I just have to translate the gopigo3_power.py to gopi5go_power.py and set the service up to use it.
gpioinfo
...
line 22: "GPIO22" "gopi5go_power.py" input active-high [used pull-down]
line 23: "GPIO23" "gopi5go_power.py" output active-high [used]
The Green LED is solid, and the GoPiGo3 power button causes an immediate, nearly instantaneous total power off of the Raspberry Pi 5 and the red board.
Note - if using the nap feature of the Pi5, the GoPiGo3 power button should not be used because it removes power from the Pi5 which will prevent the Pi5 from waking up at the end of the nap.
#!/usr/bin/env python3
#
# This code is for power management on a Raspberry Pi 5 with GoPiGo3.
# (DI code for Pi3 and Pi4 is left in comments)
#
# GPIO 22 will be configured as input with pulldown. If pulled high, the RPi will shutdown immediately and halt.
#
# GPIO 23 needs to remain low impedance (output) set to a HIGH state. If GPIO 23 gets
# left floating (high impedance) the GoPiGo3 assumes the RPi has shut down fully.
# SW should never write GPIO 23 to LOW or set it as an INPUT.
# Use gpioinfo to view effect
# Before:
# line 22: "GPIO22" unused input active-high
# line 23: "GPIO23" unused input active-high
# After:
# line 22: "GPIO22" "gopi5go_power.py" input active-high [used pull-down]
# line 23: "GPIO23" "gopi5go_power.py" output active-high [used]
# import RPi.GPIO as GPIO
import gpiod
import time
import os
# GPIO.setmode(GPIO.BCM)
chip = gpiod.Chip('gpiochip4')
# rpi_alive is a reference to GPIO23
rpi_alive = chip.get_line(23)
# GPIO.setup(22, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
# create reference to GPIO22 and set input with a pull down
gpg_pwr_button = chip.get_line(22)
gpg_pwr_button.request(consumer="gopi5go_power.py", type=gpiod.LINE_REQ_DIR_IN, flags=gpiod.LINE_REQ_FLAG_BIAS_PULL_DOWN)
# set GPIO23 to output
# GPIO.setup(23, GPIO.OUT)
rpi_alive.request(consumer="gopi5go_power.py", type=gpiod.LINE_REQ_DIR_OUT)
# GPIO.output(23, True)
rpi_alive.set_value(1)
while True:
# if GPIO.input(22):
if gpg_pwr_button.get_value():
os.system("shutdown now -h")
time.sleep(0.1)
Since I now have confirmed the GoPiGo3 C++ API is fully functional on the Raspbery Pi5 with Bookworm PiOS 32-bit - the next test is to scrap this really nicely working image, and:
I’m not going to work on porting the Python GoPiGo3 API to work on the Pi5 since that would allow me to avoid transitioning to coding ROS 2 in C++, which I have been saying I would do for over three years now.
*** GoPi5Go Dave TOTAL LIFE STATISTICS ***
Total Awake: 27.2 hrs
Total Naps: 13.05 hrs
Total Life: 40.25 hrs (since Mar 17, 2024)
Sessions (boot): 9
Average Session: 3.0 hrs
Safety Shutdowns: 0
Total Travel: 0.0 meters 0 feet
(Total Travel in ROS 2: 0.0 meters – Total Travel via GoPiGo3 C++ native API: a room width of excitement!)
Woah, I never knew that! AFAIK gpg_power.service is strictly to control the power off button and generate a shutdown command to the Pi before cutting power.
!!!I’d look at that again, as it should not immediately dump power on the board, but instead should force execution of something like sudo shutdown -h now, forcing an immediate formal shutdown with the LED blinking red for about 30 seconds - not an instantaneous power dump.
If it’s doing a power dump, that’s bad because it can scramble your O/S, especially if you don’t have an mount-count and/or interval based forced fsck of your root filesystem.
P.S.
Anyone who wants to know how to program a periodic forced fsck, look up “tune2fs” - the “c”, “C”, and “i” options are your friend! I typically set up my Linux filesystems with -c 5 -C 6 -i 5 -e "remount-ro" which sets the mount count limit to five mounts before checking, the current mount count to “6”, (forcing a fsck at the next reboot and starting the clock, so to speak), set the maximum time interval to five days between fsck’s if the mount-count limit doesn’t catch it, and if there’s an error it remounts the filesystem R/O to prevent things from going to hell in a hand-basket.
In my case since I tend to reboot a lot and dink around with the filesystem, having a short fuse on my forced fsck is a good idea.
Yes, that is what it does - it just is faster than when I type the same command from the terminal.
Power Button:
Command Line: sudo shutdown -h now
I forget the name of the person that was trying to do the Hands On ROS of late, but they showed me a way to configure something that sped up the shutdown. Perhaps something with the network config, I don’t remember, but I see the most serious “what’s it doing?” delay with my Pi5 Dave when I use sudo reboot now.
sudo reboot now:
Awhile back I mentioned that there was a service that was, (sometimes), hanging for minutes at a time, and by changing a system config file somewhere, you could set the maximum amount of time it would wait for any service to quit - I set mine to 10-15 seconds.