Installing GpPiGo3 libraries on Jetson Nano O/S JetPack 4.6

Maybe I’m wrong, but it’s been my experience that every little API, function, feature, or whatever is like a little stone in your backpack.  Each stone may only way a few ounces, but if you accumulate enough of them, the pack becomes quite heavy.

Or, as Warren Buffett said:

1 Like

I notice that within the main GoPiGo repository on GitHub, there is an “install_on_ubuntu” branch that (superficially) appears to be a copy of the regular GoPiGo branch.

@cleoqc   @cyclicalobsessive
Aside from diffing the branch to main, (which I am not sure how to do), is there any way to determine what the specific differences are between the two brances.

2 Likes

No actually the have a micro-ROS that runs on the ZW and even the RP240. ROS itself is just the communication protocol, and the robot only needs a single “robot node” that reads the sensors and sends off the readings per the protocol.

You can’t make a “serious” autonomous mobile ROS robot, but then for that level of “serious” you don’t need ROS either. Having a micro-ROS mobile sensor platform is really the soul of ROS, putting all the analysis and decisions off-board where you can easily throw more compute power if “the robot” needs.

But my robots are restricted to self contained, self-aware with autonomous analysis and decision/reasoning. My challenge that has driven greater and greater on-board computing is to expand the robot’s “environment awareness”. The Nano or the Pi5 appear to be up to that challenge.

2 Likes

click on 5 branches

click on All

Screenshot 2024-03-03 at 2.11.52 PM

click on three dots for install_on_ubuntu

Click compare

Lists the changes:

2 Likes

Here is the install GoPiGo on Ubuntu that I developed originally for 20.04 and worked for 22.04 as well.

ps. this reply was formed from our “safe room” (on floor of very small closet in the center of our small house) during a tornado warning that scared the bejeebers out of us.

2 Likes

I am rapidly coming to the conclusion that I have no idea what I am talking about.

First of all, I get the following error:

Installed /usr/local/lib/python2.7/dist-packages/smbus_cffi-0.5.1-py2.7-linux-aarch64.egg
Searching for cffi>=1.1.0
Reading https://pypi.org/simple/cffi/
Downloading https://files.pythonhosted.org/packages/68/ce/95b0bae7968c65473e1298efb042e10cafc7bafc14d9e4f154008241c91d/cffi-1.16.0.tar.gz#sha256=bcb3ef43e58665bbda2fb198698fcae6776483e0c4a631aa5647806c25e02cc0
Best match: cffi 1.16.0
Processing cffi-1.16.0.tar.gz
Writing /tmp/easy_install-C7_GjL/cffi-1.16.0/setup.cfg
Running cffi-1.16.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-C7_GjL/cffi-1.16.0/egg-dist-tmp-BkYiPY
  File "build/bdist.linux-aarch64/egg/cffi/_shimmed_dist_utils.py", line 16
    raise Exception("This CFFI feature requires setuptools on Python >= 3.12. The setuptools module is missing or non-functional.") from ex
                                                                                                                                       ^
SyntaxError: invalid syntax

creating /usr/local/lib/python2.7/dist-packages/cffi-1.16.0-py2.7-linux-aarch64.egg
Extracting cffi-1.16.0-py2.7-linux-aarch64.egg to /usr/local/lib/python2.7/dist-packages
  File "/usr/local/lib/python2.7/dist-packages/cffi-1.16.0-py2.7-linux-aarch64.egg/cffi/_shimmed_dist_utils.py", line 16
    raise Exception("This CFFI feature requires setuptools on Python >= 3.12. The setuptools module is missing or non-functional.") from ex
                                                                                                                                       ^
SyntaxError: invalid syntax

Adding cffi 1.16.0 to easy-install.pth file

and I have no idea where to even try to find:
File "/usr/local/lib/python2.7/dist-packages/cffi-1.16.0-py2.7-linux-aarch64.egg/cffi/_shimmed_dist_utils.py"
so that i can try to find line 16.  The one thing that DOES jump out at me is that the CFFI utiity expects python-3 and apparently is being run on Python 2.7.

The CFFI website mentions that with the latest version of CFFI, (1.16), they “[Dropped] support for end-of-life Python versions (2.7, 3.6, 3.7).”
https://cffi.readthedocs.io/en/stable/whatsnew.html#v1-16-0

However:
The current python versions on the Nano’s 18.04 Ubuntu are within those bands:

pi@Jetson-Nano:~$ python3
Python 3.6.9 (default, Mar 10 2023, 16:46:00) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
pi@Jetson-Nano:~$ python
Python 2.7.17 (default, Mar  8 2023, 18:40:28) 
[GCC 7.5.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
pi@Jetson-Nano:~$ 

However, when seeing if there’s an update. . .

pi@Jetson-Nano:~$ sudo apt-get install python3
[sudo] password for pi: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
python3 is already the newest version (3.6.7-1~18.04).
python3 set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
pi@Jetson-Nano:~$ 

. . .the latest version available from the repositories is 3.6.n

So, it appears that I will have to download an earlier version of CFFI and install that.

1 Like

Update:

Nice try, no cigar, but I think I’m at least orbiting the correct planet.

First of all, I uninstalled CFFI 1.16.0. . .

sudo pip uninstall cffi
sudo pip3 uninstall cffi

. . .then install the 1.15.1 version, which is the latest version that supports the versions of Python we have. . .

pip install cffi==1.15.1
pip3 install cffi==1.15.1

. . .then reinstalled smbus-cffi so that it binds to the correct version of cffi. . .

pip install smbus-cffi
pip3 install smbus-cffi

. . .then rerun the installer. . . .

git clone http://www.github.com/DexterInd/GoPiGo3.git /home/pi/Dexter/GoPiGo3
curl -kL dexterindustries.com/update_tools | bash -s -- --install-python-package --system-wide
bash /home/pi/Dexter/GoPiGo3/Install/update_gopigo3.sh

(I re-run the “git clone” because the prior, crashed, installs leave the Dexter directory wiped clean.)

Results:

  1. It mostly ran correctly, without the pesky errors about syntax and smbus-cffi.
  2. The only errors I found were:
Installing pigpio
Failed to enable unit: Unit file pigpiod.service does not exist.
Failed to start pigpiod.service: Unit pigpiod.service not found.
  1. Attempting to run any of the desktop tools returns this:
pi@Jetson-Nano:~/Desktop$ python2 /home/pi/Dexter/GoPiGo3/Software/Python/Examples/Control_Panel/control_panel_gui_3.py
Traceback (most recent call last):
  File "/home/pi/Dexter/GoPiGo3/Software/Python/Examples/Control_Panel/control_panel_gui_3.py", line 18, in <module>
    import easygopigo3 as easy
  File "build/bdist.linux-aarch64/egg/easygopigo3.py", line 13, in <module>
  File "build/bdist.linux-aarch64/egg/easysensors.py", line 5, in <module>
  File "build/bdist.linux-aarch64/egg/gopigo3.py", line 34, in <module>
IOError: [Errno 2] No such file or directory
pi@Jetson-Nano:~/Desktop$ 

. . .and when I search for these files, I get empty directories.  So, apparently, there is a step where these egg files get installed that’s not happening.

Egg files appear to be located at /home/pi/Dexter/GoPiGo3/Software/Python/dist
/usr/local/lib/python2.7/dist-packages
/usr/local/lib/python3.6/dist-packages

and the associated gopigo class libraries are located at
/home/pi/Dexter/GoPiGo3/Software/Python
/home/pi/Dexter/GoPiGo3/Software/Python/build/lib
/home/pi/Dexter/GoPiGo3/Software/Python/build/lib.linux-aarch64-2.7

So the question becomes “Why aren’t they where the system thinks they should be?” and “How do I get them there?” as, (apparently) the installation scripts don’t handle this.

More research follows. . . .

2 Likes

I sent the following message to Modular Robotics support:

@cleoqc
Any ideas on how this is done?  Is it just manually “plop-and-play” into the requisite locations or is there a formal installation process that I seemed to miss?

What say ye?

Update:
Since pigpio/pigpiod doesn’t exist on the Nano, (and won’t run if manually installed), I will have to modify the scripts to reference the Nano versions of these libraries.

Update 2:
Other functions/libraries within the scripts either don’t exist, or are called something else, so I am probably going to have to create a separate “GoNanoGo” repository for the “Nanofied” versions of everything.

Ideally, what I would like to accomplish is a way of making some kind of adaptation to the way libraries are represented so that Pi software for the GoPiGo can simply drop in and work - but that might not be possible.  It might not be possible because the basic structure of the support libraries may be different.

This may be a bigger project than I imagined.
:man_facepalming:  [man_taking_migraine_medicine :wink: ]

1 Like

Update:

I have temporarily paused the porting process to figure out how to get it to boot from an external USB SSD and how to flash updates to the internal boot eeprom bootloader.

I have been lurking the Nvidia developer’s Nano forums trying to soak up as much information as possible.  The big problem being that they seem to have dumped all the various documents into a big pot and stirred well - making looking for a specific nugget of information a labyrinthine quest remarkably like Collosal Cave:
You are in a room with a bunch of hallways all alike|different:man_facepalming:

2 Likes

I actually wore my Colossal Cave T-shirt yesterday! Fond memories of the first year of my career, (1976) getting to work early so we could all play it on Hewlett-Packard’s fastest 3MHz “24-bit instruction” 128MB (virtual) memory mini-computer.

2 Likes

I managed to update the nano to 4.6.4, the latest version and reverted back to using a very large, (512 gig), SD card just to avoid the issues with booting from a SSD via USB.

Just to refresh my memory, I tried another clean install and it was a mess from A to Z, the big problem being the inexplicable absence of essential dependencies - things like the characters in Scratch.  They’re supposed to be in /usr/share/scratch - and there isn’t even the scratch directory, let alone the character and graphic assets!

Scratch itself didn’t seem to work at all until I manually installed it from pip - it would launch but failed because important graphical assets were missing.

Pigpiod and the associated service files don’t exist.1

Egg files that are expected to be found in the appropriate system directories don’t exist.

It can’t bind to the alsa mixer amixer - and I don’t know why.  It’s installed and the Nano uses it, (AFAIK), but the GPG scripts can’t find it.

Looking at the situation with Scratch, I’m thinking that there are dependencies (like pigpiod), that just don’t exist on a Nano - and will have to be created. :man_facepalming:

. . . . not to mention re-programming scripts to accommodate the different platform!

====================

  1. Progress is being made to port things from the Raspberry Pi to the Nano.  There is a new release called Jetson.GPIO which is, supposedly, a drop-in replacement for the Raspberry Pi’s Python GPIO libraries.
    • Caveat:  It apparently only works with Python-3 and a lot of the GoPiGo stuff is still at Python-2.
       
      Now, all I have to find is a replacement for the pigpiod daemon.
2 Likes

Update:  (and an idea!)

The folks at Waveshare have displays that plug into both Raspberry Pi boards and the Jetson Nano - and they have two sets of libraries for them.

Comparing them should be instructive to see how they adapt the libraries for each platform. . . .

2 Likes

I have decided to attack this problem from another angle - installing these libraries on a virgin Ubuntu installation on a Pi-4, and then a Pi-5 so I have an idea of what is expected and what should be happening.

The Pi-4 installation should give me a good “baseline” installation and the Pi-5 should provide valuable installation porting experience that I can then transfer to the Nano.

P.S.
All of this will stop for the next week or two while I compile and reconcile my tax data.  Then I will build-out Charline again as a conversion test-bed.

2 Likes

Ah yes - exactly my folly.

  • Pi4 Bookworm: Only thing I had to get rid of was software I2C
  • Pi5 Bookworm: I’m going to have to get rid of the GPIO totally, meaning no software I2C and no AD1/AD2 functionality. I think the GoPiGo3 uses pigpiod for the servos, so those are going to probably be lost also.

Thus the question “Why GoPiGo3 with Pi5/Nano if you lose so much?”

  1. Motor Drivers:
  • by speed, by power, by motor individually
  • PID drive straight built in
  1. Encoders
  • Great accuracy in the straight, less than 1 deg error in the turns
  1. API handles common motion requests
  • drive distance
  • turn angle
  1. Battery Voltage Readings
  2. Buffered I2C ports
  3. Future expansion for servos, A2D, D2A, “Grove system”

I think I’m going to switch to trying to bring up the GoPiGo3 C++ API rather than the Python API.

1 Like

It’s likely that the Pigpio libraries don’t recognize the Pi-5 as a Pi. That should be an easy edit.

Also, you will need to remove the current Cffi python libraries via pip/pip3 and install the 1.15.1 version, because starting with version 1.16.n they dropped support for Python < 3.8.

Viz.:
https://cffi.readthedocs.io/en/latest/whatsnew.html#v1-16-0rc1

2 Likes

Ahh!  Fond memories!

  • The GE 4020 mainframe in the EE lab at college that programmed using front-panel switches - in octal!

  • Learning Basic on a DEC PDP-10 as a highschool student at Stony Brook University on an ASR-33 (?) teletype.

  • The CDC 6600/7600 mainframes at Brookhaven National Laboratory that had an unprecedented ONE MEGABYTE of shared core and a mind-blowing 64k of internal core memory each.
     
    ASR 33 Teletype w/ a 20ma current-loop serial at 300 baud.
    An ASR-33 teletype)/paper-tape punch.
     
    What an IBM-370/158 installation looked like at my college (VPI&SU)
    This is similar to the IBM-370/158 as installed at my college (VPI&SU) in the 70’s.
     
    IBM1442 high-speed card reader.
    An IBM-1442 high-speed card reader that could scatter a thousand+ cards all over a room in less than 30 seconds!
     
    IBM 029 keypunch.  Bleeding edge at the time.
    An IBM-029 keypunch with a modified Selectric keyboard.  This was absolute heaven compared to the other keypunches of the day, and was considered the absolute pinnacle of technology.
     
    Punched card used for programming
    What the keypunch did.  80 columns.  One line at a time.  God Himself help you if you dropped your deck of cards because you’d NEVER get them back in the correct order ever again w/o re-punching the whole dam thing. . .
     

Them was the days!

P.S.
I shared these pictures with my eldest granddaughter and she was totally gobsmacked!  I suspect that her opinion was that we were computing by rubbing sticks together, while we worked on inventing the wheel!

2 Likes

What is cffi and why did I need it?

From the what’s changed it seems it is the source of my ROS warnings that setup tools has been deprecated and I should stop bang my head against the wall that way, and start banging it on a fresh side.

I thought it was a plot by the ROS community to make Python go away and leave all the smug C++ coders to reign.

I love when I read:

The price of keeping up with Python changes hit my bottom line when I turned 70.

2 Likes
  1. It’s a hard dependency for the GPG libraries.

  2. CFFI documentation — CFFI 1.17.0.dev0 documentation
    It allows Python to call C/C++ code.

A lot of the stuff needs to be back-rev’d to Python 3.6 or so and also install Python 2 for the dialogs.

2 Likes

The GPG Python eggs, which became non-standard 12 years ago.

Everything about this “still best in its class robot” is deprecated. It’s contagious you know; I’m feeling more deprecated every day.

2 Likes

Then maybe we need to start a refactoring project to bring it up to date?

I just don’t know how to update the ancient egg files.

2 Likes