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.
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.
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.
. . . . not to mention re-programming scripts to accommodate the different platform!
====================
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.
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.
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?”
Motor Drivers:
by speed, by power, by motor individually
PID drive straight built in
Encoders
Great accuracy in the straight, less than 1 deg error in the turns
API handles common motion requests
drive distance
turn angle
Battery Voltage Readings
Buffered I2C ports
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.
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.
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.
An ASR-33 teletype)/paper-tape punch.
This is similar to the IBM-370/158 as installed at my college (VPI&SU) in the 70’s.
An IBM-1442 high-speed card reader that could scatter a thousand+ cards all over a room in less than 30 seconds!
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.
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!
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.
