Containerizing the GoPiGo?

On the Raspberry Pi forums, I raised a question:

Is it possible to containerize the GoPiGo libraries in such a way that they can be “plopped” into any version of any Raspberry Pi operating system software, and have a working robot that can be used and developed against.

Viz.:
https://forums.raspberrypi.com/viewtopic.php?t=376410

The more I think about it, the more I become convinced that the biggest problem is the fact that Python is a moving target and being tied to a particular version is what’s hurting us.

If I remember correctly, @cyclicalobsessive mentioned that most, if not all, of the robot’s primitives were already implemented in C/C++.

Idea:

  1. Scrap Python per se and leverage the non-Python libraries and interfaces.

  2. If possible, develop version agnostic Python “hooks” into the C(++) libraries.

  3. Develop a version of the gopigo and easy_ gopigo libraries, leveraging the existing low-level code so that existing code can use them.

This is a thought experiment at the present time, but I sincerely believe that we need to get outside chasing Python versions every time someone sneezes.

What say ye?

1 Like

No, that is not what hurt me at all. The move from Python2.7 to Python3.x for GoPiGo3 API was a “nothing to do”.

Not even close. The GoPiGo3 class is implemented in C++ and MR accepted my update to honor 16-tick encoders.

All the goodies for the GoPiGo3 that make the programming easy to learn are actually in the EasyGoPiGo3 class which was not implemented by DI/MR. When I thought Python on Pi5 was going to be a problem, I started building a C++ EasyGoPiGo3 class, but when the going got hard I discovered that Python worked fine on the Pi5 by commenting out some obsolete SPI GPIO hardware dependant lines. I abandoned my C++ EasyGoPiGo3 effort.

Not without adding a bunch of “what processor AND OS am I running on” tests and a Docker device configuration guru handy. Docker containers are very nice when all the software executes software actions inside the container. As soon as software wants to reach out of the container to real hardware on a variety of base operating systems - oh boy, uncharted chaos. (I’m talking audio, USB, GPIO, SPI, UART, and camera specifically. Network hardware is not configured by default but is a one-liner in most cases: “–net-host”. Oh, and user authentication on files and devices is serious PITA bread.)

1 Like

I have tried to create dedicated install scripts for each major “latest PiOS” flavor and three Ubuntu major releases. A universal “Works On Any Raspberry Pi model and any supported OS” would not be a small dev effort, and would not be a small test effort. Considering the number of folks that come asking “How do I install on ____”, I think we’re doing just fine.

1 Like

However, we don’t know how many requests are either bypassing us via the support e-mail or are lurking.

Right now, (if I remember correctly), installations on later systems is a non-trivial undertaking.

I agree that creating something that’s guaranteed to work anywhere on anything would be a Herculean task.

Maybe you can push your scripts up to the GoPiGo repo?

1 Like

There is no such thing as push to the GoPiGo repo. I and my scripts are always available for the inquisitive.

1 Like

Well, I’ve heard sending to a repo called “pushing” (which I’m assuming involves a pull request).

Your scripts are “available” in the sense that if someone knows about them, they’re available.

Someone who’s been directed to the GoPiGo repository will have no idea that other libraries are available.

1 Like

Deleted by author …

.

.

1 Like

Indeed. My apologies. Cleaned and restored.

1 Like