And PI Imager 1.7.5 automatically shows the new Bookworm Pi OS so if you are already on 1.7.5 don’t need to upgrade the Pi Imager to write any of the Bookworm Pi OS. There are both 32-bit and 64-bit versions of each Bookworm Pi OS.
No success for headless access for headless setup of two flavors so far. firstrun.sh is not succeeding.
Had to connect monitor and keyboard to setup user and WiFi to have remote access.
Starting with the “Recommended” 32-bit PiOS Desktop (Bookworm) to see what it takes to get my GoPiGo3 on it - should be pretty straight forward (without software I2C).
could not update due to wireless defaulted to ipv6
nothing worked to disable ipv6
don’t know how to configure wifi from commandline Gave Up
This is getting old, trying every PiOS Bookworm in hopes one of them will be usable. Raspberrypi forums say what I am seeing is not happening for others. Maybe I need to try a different sdCard.
Sounds reminiscent of my trying various Ubuntu and Ubuntu-MATE images that should work on a Raspi 3 B+ but don’t on any of mine. Which Raspi are you trying this with again?
Some observations of this relative to GoPiGo3 on Bookworm with a desktop on a 2GB Pi4:
base OS processor load (with pigpio daemon and gpg_power service alive) is very low
base OS physical memory usage (with pigpio/gpg_power) is about 1GB
base OS effective memory usage (with…) is about 340M leaving 1.5GB “available”
pigpiod at idle uses roughly 7% of one core or 2% of the Pi4 processor
GoPiGo3 LEDs Python example uses 2% of one core or 0.5% of the Pi4 processor
GoPiGo3 Servo Python example uses 10% of one core or 2.5% of the Pi4 processor
Grove Ultrasonic Ranger Python example uses 1% of one core or 0.2% of Pi4 processor
GoPiGo3 Distance Sensor Python example uses 28% of one core or 7% of the Pi4 !!!
(Single reading is not the best mode, but is the easiest to use with the sensor.)
Drive 1 meter test briefly used 30% of one core/8% of Pi4 to command GoPiGo3, then practically nothing waiting for the GoPiGo3 to announce drive complete.
Python3 wheelBaseRotateTest briefly uses 1% of one core of Pi4 to command a 360 deg rotation then nothing waiting for the GoPiGo3 to announce rotation complete
Reading the MPU9250 IMU at 10Hz in Python3 takes 1% of one core of Pi4
pi@PIOSB64D:~ $ uptime
10:23:02 up 12:16, 1 user, load average: 0.02, 0.05, 0.01
pi@PIOSB64D:~ $ free
total used free shared buff/cache available
Mem: 1892432 351548 996716 14872 628528 1540884
Swap: 102396 0 102396
ultrasonic.cpp !! programmer error - works just fine
Created a servos test program to match the Python Servo.py. The Python3 Servo.py takes 10% of one core, while the C++ servos.cpp takes 7% of one core making it 30% faster in this case.
Oh wow - the world of ROS is containerized. I’ve seen references to Docker and running ROS/ROS 2 in Docker but I never needed to grok what a beautiful thing this is!
Installed Docker on PiOS Bookworm
(Tried the pre-built ROS 2 Humble Desktop dockerfile - they didn’t build it for Pi4)
So built a ROS 2 Humble Desktop / Jammy Jellyfish 22.04 dockerfile
-rw-r--r-- 1 pi pi 709 Oct 19 21:25 1_setup_docker_apt_repo.sh
-rw-r--r-- 1 pi pi 146 Oct 19 21:26 2_install_docker_pkgs.sh
-rw-r--r-- 1 pi pi 65 Oct 19 21:35 3_clone_ros_docker_images.sh
-rw-r--r-- 1 pi pi 267 Oct 19 22:58 4_build_humble_desktop_container.sh
-rw-r--r-- 1 pi pi 131 Oct 19 23:11 5_run_ROS2_Humble_Docker_image.sh
Because ROS / ROS 2 allow distributed nodes - I can run the GoPiGo3 node on the bot, and all the processing of the sensor data on the Pi5 (when the hardware arrives). The first dual processor GoPiGo3 may be possible with ROS/ROS2 - (the battery may not be up to powering them).
Who needs Ubuntu anymore? Not me!
Well maybe - we haven’t run the performance tests …
That’s a great idea (if the battery can handle it).
Were you going to network them with WiFi? I wonder if the two boards will interfere in some way, reducing bandwidth?
I was thinking that the Pi-5 might have the chops to run the whole show itself?
WiFi interference won’t be a problem if:
The channels are exactly the same.
The channels are far enough apart so that there is no overlap at all.
Using the 2.5ghz band as an example, the only three channels that don’t interfere are 1, 6, and 11, and if you want to be absolutely sure you pick 1 and 11.
If the channels are the same, the protocol handles collisions. If they don’t overlap at all, it’s all good too.
The big problem is when a channel partially overlaps another, because WiFi channels aren’t cleanly separated groups of frequencies, and all the channels overlap except channels 01, 06, and 11. In that case, speed drops dramatically.