I thought I did it before - I’ll do it again a little better.
Roughly two years ago, I managed to pull together
Ubuntu 20.04 Server on a RPi,
GoPiGo3 drivers and API
ROS2 Foxy
DI IMU, Grove Ultrasonic, DI Servo, DI Distance Sensor
LiDAR
ROS2 nodes for the GoPiGo3 and sensors
to create a working ROS2 GoPiGo3.
Now Ubuntu is sporting “Jammy Jellyfish” 22.04 and
ROS2 is up to “Humble Hawksbill”,
so I thought I would recreate my prior success and
while at it add a “light weight desktop” and VNC connectivity.
Three long days later, I have the second VNC I tried showing the second desktop I tried, but only working fully when VNC is started from the command line.
After more than 30 reboots with different configurations, I can get the desktop to show up on VNC, but only the terminal application works when VNC is started as a service.
I don’t have to put myself through all this “uncomfortable Linux wilderness exploration”, so I quit.
I thought maybe I could “contribute” to keeping the GoPiGo3 relevant in the ROS2 community, but considering how no one came asking about the prior ROS2 GoPiGo3 “how to”, it seems like just another trying to feed more than the calf wants to eat. It just goes to waste.
Couldn’t sleep as a quitter. Had to try “just this once more”.
Well, just that once more,
and the “just one more thing to try”,
and the “I’ve tried everything but this”,
and the “well that didn’t work, but what if I uninstall the offender”,
and the “what if I uninstall the next offender”,
and finally it is all working until I log out from the VNC session.
The Internet says just never log out of your VNC session.
SO… I continued on - installed all the GoPiGo drivers/API stuff and tested that is working…
GoPiGo3 on Ubuntu 22.04 LTS Server (64-bit) is alive… for user pi only…
BUT, now the VNC is back to failing as a system service - differently, but still failing.
I’ve been completely inactive with my GoPiGo3 since December, when I took a new job and moved. We’re now at the point where necessary work on the new house is almost done, and I should start to have some free time again.
I’d like to move on to ROS2, but based on your trials and travails I’m not sure the GoPiGo3 is the right platform for that. So I may keep Finmark ROS1 and look for a new option (that is reasonably priced). I may end up building one - seems like I’ve seen some folks who’ve done that, so there may be enough information on line to make that a viable option for a hobbyist.
But then again maybe I"ll give ROS2 a go - I haven’t used VNC, so I may not have the same issues.
Adding a desktop GUI with VNC access is clearly not advisable in a ROS2 bot.
I wanted to be able to measure the processing and memory usage penalty of having it available. I have the feeling that not many folks (maybe not any?) are running Ubuntu Server on Raspberry Pi4 adding all the various Ubuntu desktop GUI flavors.
I was encouraged by the fact the RaspberryPi foundation had thoroughly blessed Ubuntu 22.04 Desktop distribution with GNOME desktop, but found that distro did not allow headless network configuration. I guessed that I could just load up the Server version headless, add the GNOME desktop and I would arrive at the same point without hooking a display, keyboard, and mouse.
I seem to have found a “bleeding edge” for Ubuntu 22.04 on Raspberry Pi, so I’m going to proceed on to installing the latest ROS2 on the latest Ubuntu running on Raspberry Pi. What could go wrong?
Unless there’s a clearly defined conflict, (which should show up in the logs or during installation), it shouldn’t make a difference.
We know that we can install a desktop on Ubuntu, and we know we can install ROS on Ubuntu - therefore we should be able to install BOTH on Ubuntu.
Obviously there is more here than meets the eye as computer software doesn’t have personality conflicts with other software; therefore they should work or there should be a clearly defined and repeatable issue.
I think this is the reason Ubuntu is moving toward snaps, and away from individual apt packages with folks having to find and specify the dependencies for “mix and match” configurations.
There is a lot in flux when a new Ubuntu version gets released and Raspberry Pi is certainly down on the list of Ubuntu Server and perhaps even lower on the list Ubuntu Desktop.
I just hit a new one with that - the apt install process has been “improved” to check for “microcode needing update”. I strung together all the GoPiGo3 setup steps into one big shell script which appears to have resulted in a corruption of the boot firmware:
Sep 09 14:47:18 ROS2HH systemd-udevd[445]: mmcblk0: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/mmcblk0' failed with exit code 1.
Sep 09 14:47:18 ROS2HH kernel: vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
Sep 09 14:47:18 ROS2HH kernel: bcm2835_vc_sm_cma_probe: Videocore shared memory driver
Sep 09 14:47:18 ROS2HH kernel: [vc_sm_connected_init]: start
Sep 09 14:47:18 ROS2HH kernel: [vc_sm_connected_init]: installed successfully
Sep 09 14:47:18 ROS2HH kernel: mc: Linux media interface: v0.10
Sep 09 14:47:18 ROS2HH systemd-udevd[445]: mmcblk0p2: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/mmcblk0p2' failed with exit code 1.
Sep 09 14:47:18 ROS2HH kernel: gpiomem-bcm2835 fe200000.gpiomem: Initialised: Registers at 0xfe200000
Sep 09 14:47:18 ROS2HH kernel: videodev: Linux video capture interface: v2.00
Sep 09 14:47:18 ROS2HH systemd-udevd[433]: mmcblk0p1: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/mmcblk0p1' failed with exit code 1.
Sep 09 14:47:18 ROS2HH systemd[1]: Found device /dev/disk/by-label/system-boot.
Sep 09 14:47:18 ROS2HH kernel: snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
Sep 09 14:47:18 ROS2HH kernel: bcm2835_audio bcm2835_audio: card created with 8 channels
Sep 09 14:47:18 ROS2HH systemd[1]: Starting File System Check on /dev/disk/by-label/system-boot...
Sep 09 14:47:18 ROS2HH systemd[1]: Reached target Hardware activated USB gadget.
Sep 09 14:47:18 ROS2HH kernel: bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
Sep 09 14:47:18 ROS2HH kernel: bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
Sep 09 14:47:18 ROS2HH kernel: bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
Sep 09 14:47:18 ROS2HH kernel: bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13
Sep 09 14:47:18 ROS2HH kernel: bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14
Sep 09 14:47:18 ROS2HH kernel: bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15
Sep 09 14:47:18 ROS2HH kernel: bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16
Sep 09 14:47:18 ROS2HH kernel: bcm2835-isp bcm2835-isp: Register output node 0 with media controller
Sep 09 14:47:18 ROS2HH kernel: bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
Sep 09 14:47:18 ROS2HH kernel: bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
Sep 09 14:47:18 ROS2HH kernel: bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
Sep 09 14:47:18 ROS2HH kernel: bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
Sep 09 14:47:18 ROS2HH kernel: usbcore: registered new interface driver usbserial_generic
Sep 09 14:47:18 ROS2HH kernel: usbserial: USB Serial support registered for generic
Sep 09 14:47:18 ROS2HH systemd[1]: Started File System Check Daemon to report status.
Sep 09 14:47:18 ROS2HH kernel: bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
...
Sep 09 14:47:18 ROS2HH kernel: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
Sep 09 14:47:18 ROS2HH kernel: brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin failed with error -2
...
Ending at: Sep 09 14:47:19 ROS2HH systemd[1]: boot-firmware.mount: Directory /boot/firmware to mount over is not empty, mounting anyway.
I don’t know all the specific details, but if you are going to mess with boot folders, you need to use a redirect in config.txt instead of trying to mount over it at the O/S level - because the GPU (which is also the “motherboard bridge chipset”, I/O processor, and boot manager), needs to be in lock-step with the rest of the system. A boot-loop is a sure sign that these things are not in sync.
Another sign of boot folder sync issues is a system that goes all pear-shaped, seemingly at the drop of a hat, with no clear or definable reason.
You can research this using the copious notes I left in my multi-booting threads.
Once I finish my flight sim research, I am going to unpack Charlie, (or maybe assemble Charlene), and take a crack at it.
I may not be a programming wiz-kid, but I will pit my systems skills against your toughest problems - assuming I have the hardware.
I haven’t been beaten yet - but there may be a few things I haven’t quite finished succeeding.
The only things I need are:
A clear statement of the problem and the results you want to achieve.
A clear definition of “success”.
A way to verify that I have succeeded.
What say ye?
P.S.
Don’t rush with this, I am not going to be able to mess with this for a while yet. This is a good time to refine the goals you want to achieve.
Thinking about this a bit more, this is your “smoking gun”.
There should NEVER be anything in the boot folder at mount-time. If there is, you are already hozed before you go any further.
Your mission, (if you choose to accept it), is to figure out what’s going on with your boot directory and how whatever is there is getting there in the first place.
Absent any other obvious clues, an out-of-sync boot directory will cause strange things to happen in seemingly unrelated areas of the system.
I am guessing something in the DI GoPiGo3 scripts is, but I didn’t hit this when I executed everything one step at a time and proved that the DI scripts resulted in a working GoPiGo3 over 22.04. I decided this was the tenth time I was doing this manually so I put it all into one giant shell script and blew up my system.
the pigpiod.service was timing out and causing a system reboot.
because the pigpiod daemon was missing in action
because pigpiod failed to be created
because make and gcc were missing
(that also meant wiringPi had to have failed to build …)
The installation of the desktop GUIs must have installed make and gcc,
which is why the install was successful when I was doing the commands one at a time.
So - flashing the OS again, and will try my scripts again …
out of me - it shouldn’t be happening and you need to find out why.