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.
I tried fedora as well, I was able to patch the device tree to get the /dev/spi* device. Which is important to communicate with the dexter board. But, I have one problem, I can not start the motors?!
I can switch on all LED’s via SPI, I can get firmware versions, get information from the Motors. BUT I can not start the motors to drive the robot.
Has anyone some information for me how to debug?
I used the Software/Python/hardware_test.py to test everything.
You don’t call the doctor without a good reason, do you?
(Laughing! Originally I misread “Microshift” and thought it was hysterical, especially coming from a RedHat crowd.)
I’m afraid that I don’t know anyone around here who would know a Kubernetes container if it bit them. Especially since the latest Python versions seem to like Docker.
I don’t mean to rain on your ideas, they sound interesting. Maybe @cyclicalobsessive@cleoqc or @KeithW know something about Kubernetes?
I strongly suspect that you are going to be in uncharted territory, “Boldly Going Where No GoPiGo Robot Has Gone Before!”, doing original research on this topic. (Does anyone there need a University term project? This could be it.)
The only thing I ask of you is to contribute your efforts to threads on this forum as this will be valuable knowledge for everyone. Open as many threads/topics as you wish.
Notes:
I’m working on porting the GoPiGo environment to a first-generation Jetson Nano running Ubuntu 18.4. This could be extremely useful.
I used to be a big fan of RedHat, (back in the pre-Fedora days), and I migrated to Fedora when it first came out. I ended up moving to Ubuntu, (and then to Mint), because its software RAID stank back then, and Ubuntu/Mint had support for the hardware RAID on a Dell 2800, (28000? It was awhile ago), server I was working with.)
Let us know what you all are doing - keep us in the loop - because that will be very important to the rest of us.
If you are using a GoPiGo robot, there’s a 12v connector on the back of the robot that you connect the supplied 12 rechargeable battery pack, or a battery container with 8 NiMH AA batteries. (Alkaline cells don’t have enough power)
For experimental purposes, (on the benchtop, when it’s not moving), you can use a 12v computer power supply. It should supply several amps of power, (at least 3), and be as clean as possible. That’s why I use a 12v computer supply instead of some 12v wall cube.
If you need to test “do the motors work?”, you can put it up on a short piece of 2x4 wood.
Be careful! It’s easy to accidentally knock the robot off of the table and the acrylic chassis isn’t happy being knocked off.