All, I’d like to explore the options to run our GoPiGo3 fleet with Fedora (or RHEL or CentOS). Reason is we (as in “Red Hat”) would like to showcase our edge and container application product portfolio in our robot hackathons. I’ve opened an issue, too: https://github.com/DexterInd/GoPiGo3/issues/320
I’m happy to start finddling with this but something stopped me before starting:
From what I understand there is an „old-style“ sysfs interface to GPIO that is deprecated since Kernel 4.8 or so and the new /dev/gpiochip* interface. Most modern distros are starting to use the new interface, notably Fedora-based ones. Linux kernel GPIO user space interface - #embeddedbits
On Fedora and derived the old sysfs-style interface is not enabled in the kernel and pigpiod (@cleoqc mentioned pigpiod is used now) is not available.
I’m not a Python expert and don’t now too much about the Gopigo Python bits… I would be greatful if somebody in the know could give some advise if my endeavour is feasible in the first place. Or if the gopigo software is going to use the new GPIO interface at some point.
At the heart of the GoPiGo3 is the python package pigpio and the related pigpiod daemon waiting for pin twiddling requests.
The person that wrote pigpio/pigpiod appears to have a similar more generic client/server package with a different name, so perhaps they would be of assistance:
It appears you or they would need to create a special pigpio to lgpio interface package, or you will need to create a custom gopigo3.py that imports and uses the lgpio interface instead of pigpio.
Is the GPIO available from docker running on Fedora? Perhaps you could install the Legacy PiOS and curl the GoPiGo3 code onto that all in a container. It won’t be optimal, but perhaps something would work.
I started to play around with this (Fedora on RPi 4 with the Gopigo3 Python-bits). I realized I’d need a 64-bit OS anyway for Microshift, so arm64 Fedora, sigh. To make it short I got nowhere… tried to build pigpiod on Fedora but it won’t start because of some memory protection in the 64 bit Fedora kernel… and so on and on.
So it looks like my last chance, while not optimal, is 64-bit Ubuntu 20.04 which should be able to run Microshift.
@cyclicalobsessive you did a post on this: Is this something I should get to work? I really only need the Gopigo3 Python libs/API to control the little guy, no tools more highlevel.
Right. That was my goal also - just the API and only the API dependencies.
The posts, methodology were for Ubuntu 20.04 64-bit and was totally successful.
This is the procedure:
Separate from the GoPiGo3 API though is the current state of flux in the PiCamera on 64-bit OSs. A lot of my 32-bit vision code used the picamera module with hardware drivers. There is a new picamera2 module for BullsEye 32-bit which uses video 4 Linux, but 64-bit operating systems have to solve the video handling on their own still, I believe.
My “ROSbot Dave does a 1k run” was on U20.04 64-bit and the video error’d out sometime before the end of the run. That was the only issue I ran into, No GoPiGo3 issues.
Oh - there was one issue - I created a “safe” imu package if you will plan on using the DI IMU:
I’m happy for anybody giving this a try! To briefly summarize what I’m after:
Main goal: Run Microshift (Kubernetes distro for Edge devices, www.microshift.io, needs 64-bit) on our Gopigo3 fleet to enable us (Red Hat) to do all sorts of demos/hackathons.
E.g. preparing ML models on a main OpenShift (our Kubernetes platfom) cluster and then deploying and running object detection containerized on the robots. Before Covid we used the Gopigo3’s with a Rest API as “dumb” end devices.
It would be great to use Fedora / Fedora IoT as base OS as our Red Hat Enterprise Linux for Edge is derived from it.
Fedora is pretty modern so e.g. the GPIO interface did change with Kernel 4.18 (or so). I build pigpiod fine on the Gopigo3 w/ Fedora but it fails to start with some error that stems from some memory protection on 64-bit.
I would go with Ubuntu 20.04 64-bit running Microshift if I can’t make Fedora work. But running a modern IoT distro like Fedora IoT would be a lot better for our case.
I didn’t get to this last weekend, sorry. I ended up doing some React stuff. Guess which project I would have preferred? Oh well.
I’m downloading the Fedora image now.