Installing GpPiGo3 libraries on Jetson Nano O/S JetPack 4.6

Just for the Grins and Giggles, (:man_facepalming:), I want to see what happens when I try to install the GoPiGo-3 Libraries on the Jetson Nano’s operating system and I want to dotouch /lib/modules/4.9.253-tegracument what happens here while I do it.

What I am working with right out of the gate:

  1. A first-generation 4 gig Jetson Nano.

    • Supposedly the second-generation boards are spec-compatible, but there are a couple of “gotchas!” that might, but probably don’t, affect anything.
  2. The latest version of the Jetson Nano’s O/S - JetPack 4.6.1 - which is based on Ubuntu 18.4.  (I believe the latest version of Ubuntu for the PC is somewhere around 22 or 24-dot-something.)

    • Note that the username is set to “pi”, (a hard requirement), and the password is set to “robots1234”, (which may not be a requirement), just to keep things simple.
  3. the M.2 WiFi module that you could buy as an accessory back in 2019 when I bought the beastie.

  4. A surface mount battery clip that fits a CR1220 battery, (and the battery itself), to enable persistence for the on-board RTC.  There are solder-pads and silk-screen markings for it, it’s just not populated.  I added one and the corresponding battery.

What I’m doing step-by-step.  Note that I don’t know if this will even work when I’m done, or it might install itself into a corner.

As root run the following:

  1. touch /lib/modules/4.9.253-tegra to create a missing file that apt-get upgrade complains about.

  2. apt-get update

  3. apt-get install apt-utils which is a missing dependency for many updates.

  4. apt-get upgrade to get everything else to current rev.

  5. apt-get install python-pip python3-pip
    (Both python2 and python3 are reqired for the install script.)

  6. apt-get install libqt5scripttools5 Apparently these are needed for the scripts to run.

  7. apt-get install curl is needed to install setup_tools later on.

  8. (optional, but I find them useful)
    apt-get install gparted gddrescue
    gparted is a graphical front-end for parted and ddrescue is a very useful tool for moving device images and recovering data - like dd on steroids.

  9. If you want the man pages, (which are deliberately missing to save space):
    . . .which has a pretty large footprint.  This might be a good idea for initial experimentation, especially if you have a large drive/card for the O/S, but you may want to omit them, (not run the script), for a “production”, (think “space constrained” or “embedded”), system where you want the max space for your stuff, instead of a bunch of text.
    Note that when I tried it, it took a very long time and eventually went all pear-shaped so I ended up reflashing the SD card and starting from scratch again.

  10. git clone /home/pi/Dexter/GoPiGo3
    This brings down all the files needed for the install.

As a non-privileged user (“pi”):

  1. curl -kL | bash -s -- --install-python-package --system-wide

  2. bash /home/pi/Dexter/GoPiGo3/Install/


Output of the “successful” run on the Jetson Nano with JetPack 4.6.1, (Ubuntu 18.4)


Pretty impressive - the cffi error is the same the GrovePi guy just gave a fix for - did you try that yet?

It says espeak-ng is installed - did you hook up a speaker/headphones and try espeak-ng "Hello Nano"

Really super, Jim!

  1. No.  What guy?  What fix?

  2. There are a few “syntax errors” in some of the scripts that I have to chase down.

  3. The Ubuntu 18.4 version (Bionic Beaver) that JetPack 4.6.1 uses is a very custom respin with certain things conspicuous by their absence - “curl” for example along with “apt-tools” and other things that you’d think were “standard equipment” like an engine, a steering wheel, tires and rims, along with seats in a car.

  4. Things aren’t happy in Mudville yet as the major functionality, (at least for the desktop icons items), isn’t there yet.  Note that I haven’t tried connecting the Nano to a GPG-3 board yet because if the main packages won’t work, (like Scratch, or the control panel), the rest is meaningless.

To check things, I reflashed the OS and I am going to try installing things a bit differently to see if it works better.  I am also going to try to edit the installation script so that script_tools is installed BEFORE the original attempt to install RFR_Tools, as RFR_Tools needs script_tools to run.

I will be updating the original posting with corrected steps as I proceed.  Hopefully it won’t age beyond the edit interval while I do it.

1 Like

I have established a GitHub repo for this project:


This is turning out to be one of @cyclicalobsessive’s “unicorns” as the Nano appears to have gone EOL as of the beginning of 2024. . . .


But for a measly 2W more (7W) you get 40x performance with the Orin Nano with EOL out to 2030, but it also looks like the GoPiGo3 would need a trailer behind to haul it around…


5/7 watts?  That’s in the severely throttled low power mode and the spec’s are much less impressive.  To get the fancy performance, you run it at something like 20-30 watts.


Jim, nothing in the GoPiGo3 API needs even the PiZero2W performance. The Nano (and Orin Nano at 40x Nano performance) is all about the AI someone will want to enable above the GoPiGo3, and wanting to put that power on the robot is so counter-culture to distributed computing and cloud computing that whatever you can achieve will be a successful technology demonstration.



However the main reason for my doing this, aside from pig-headed stubbornness, is the desire to figure out how to do it.


And you make that sound like a bad thing!  I think it makes more sense to have a robot - especially a so-called “autonomous” robot - be more self-contained.

Personally, (and IMHO), the whole “distributed” and “cloud” computing paradigm is way over-blown for all but a few specialized use-cases.  Note that I am distinguishing between cases where you can access a resource remotely, (i.e. online banking, accessing these forums, or accessing Charlie remotely), and a distributed computing environment where the resources are shared among several systems, (i.e. Dave needing a laptop to off-load processing he can’t handle).

Though there are appropriate uses for it, I think a lot of it is just overblown marketing hype like “everything has to be a Docker container”, Agile, Ruby, and “we can solve all the Internet’s problems by throwing HTTPS at it.”"


As a broad generalization, I agree.  However, once you start building up larger and more complex programs while running a remote desktop with RealVNC or doing active video streaming while controlling a robot, (etc.), you may well end up needing a better platform if you want to achieve acceptable performance.

In the same way you could, (theoretically), run ROS-2 on a Pi-ZW, but the performance would be absolutely unacceptable.

1 Like

Oh yeah, forgot about that one. I don’t use it as oft as I could to make life simpler.


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.


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.


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:


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.


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
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/ -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/", 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/", 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/"
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).”

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.

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.

. . .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


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 /home/pi/Dexter/GoPiGo3
curl -kL | bash -s -- --install-python-package --system-wide
bash /home/pi/Dexter/GoPiGo3/Install/

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


  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/
Traceback (most recent call last):
  File "/home/pi/Dexter/GoPiGo3/Software/Python/Examples/Control_Panel/", line 18, in <module>
    import easygopigo3 as easy
  File "build/bdist.linux-aarch64/egg/", line 13, in <module>
  File "build/bdist.linux-aarch64/egg/", line 5, in <module>
  File "build/bdist.linux-aarch64/egg/", line 34, in <module>
IOError: [Errno 2] No such file or directory

. . .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

and the associated gopigo class libraries are located at

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. . . .


I sent the following message to Modular Robotics support:

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?

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