GoPiGo Onboard Display Test - Progress is being made!

GoPiGo
,
1

I have been working on attaching a small display to my two robots so that they can report important information while they’re running.  Sort of like @cyclicalobsessive’s talking robots where they speak important information - I want mine to display it on an on-board display.

The challenge is:

  • What’s the best O/S to continue my development work on?  Buster?  Bullseye?  Bookworm?

  • What’s the best display to use?

    • The Waveshare e-Paper displays have a (relatively) easy interface and consume minimal amounts of power, but they use the SPI buss and I’ve been having conflicts with that causing the robot to go brain-dead.  They’re also incredibly slow to update so they’d be useless for dynamically changing data.
    • I have two Adafruit displays that use i2c, so there’s no conflict, but they’re active displays so they consume more power and the API is more difficult to use.  Because they’'re LED-type displays, updates are blazingly fast, but the power consumption is a factor.

Additionally, there’s the question of what operating system the various libraries support.  As I have discovered while trying to install the GoPiGo libraries, things don’t always fit the way you would expect them to fit - especially with bookworm, it being the Windows-11 of Raspberry Pi software as there’s such a large paradigm shift, seemingly breaking everything.

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

Today I completed the preliminary setup for the display testing.

  1. I created a 6 operating system multi-boot environment with a “Project_Files” partition common to all of them mounted on /home/pi/Project_Files, selectable with a 5-position dip-switch
    In order they are, (from 0 to 5.  “0” is no dip switch selected and 1 - 5 are individually selected dip-switch positions):

    • Buster downloaded from Raspberry Pi.
    • GoPiGo O/S configured for the Waveshare e-Paper display.
    • GoPiGo O/S configured for the Adafruit 16x2 LED display with buttons.
    • GoPiGo O/S configured for the Adafruit 128x32 OLED display.
    • Bullseye 32 bit downloaded from Raspberry Pi.
    • Bookworm 64 bit downloaded from Raspberry Pi.

  2. Buster, Bullseye, and Bookworm have the GoPiGo libraries installed, including the graphical libraries, (wxPython, which was a pain), and they’re working.

  3. All are configured to use the attached Adafruit real-time clock, an attached +5 power boost circuit, and a DC voltmeter that can be switched to monitor either the +12v or +5v rails.

  4. All are configured to mount a shared “Project Files” partition for shared/common data.

What with everything going on here, this has been going on for about a month or so, a little bit at a time as I encountered problems, found solutions, and implemented them.

Today it is complete.  I FINALLY have all the test environments set so that they’re ready to test.

All I need to do now is figure out a way to backup everything so that I can restore stuff if things go all pear-shaped.  I’m thinking of creating a series of 14 compressed rsync images of the 14 partitions on the 500 gig SSD.

  • There are six operating systems.

  • Each operating system has two dedicated partitions, one for the boot partition and the second for it’s companion root partition.  Therefore all of the six bootable operating systems occupy 12 partitions.

    • Previous multi-boot experiments demonstrated that each operating system had, (and needed), a unique and individual boot partition - they could not share one - so I had to duplicate this in my multi-boot environment.  Ergo, the need for twelve partitions.
       

  • There is a large “Project Files” partition at the very end of the drive.  (Partition 13)

  • And finally, as the first partition on the drive, there is a special “OS_BOOT” partition that reads the dip-switch and decides which of the six operating systems to transfer the boot process to.  (Partition 14 - actually partition 1, but who’s counting?)

I should be able to create a rsync image of each of the partition’s contents and I will need to include a text file containing a description of the partition structure and metadata.

Next Steps:

  1. Back everything up.

    • Where?  I’ll have to find somewhere to put all this data.

  2. Begin testing the various displays and their configurations.

  3. Figure out how to gather the data to be displayed, extract what’s important, and format it for the display being used.

Extra Credit:

  1. Determine if it’s possible to automatically detect the display being used and switch to the correct drivers and modules.
1 Like
2

Like WOW! - That is cool.

  • Buster - I sort of understand - that is the “official” non-GoPiGo OS alternative
  • Bookworm - I sort of understand - that is the “official” Raspberry Pi OS
  • Bullseye? From my readme “Not Recommended, but if you must”

The GoPiGo3 is a surviving dinosaur. Visit it in the Buster Zoo, or chase it down in the Bookworm wilderness.

1 Like
3

wxPython was a royal pain.  Each installation target needed a different set of prerequisites, and nobody tells you which you need until you try it and it splatters itself over half the known universe.  In my case, I probably installed more than I needed - annoying!

Not to mention that after you get all the prerequisites installed and actually start creating the wheel, you then go do your exercises, bike in the 90° heat, visit the squirrels, and do some bird-watching while you wait for it to complete.

And THEN, when you try to run something like the control panel, you discover that the graphical API’s have changed and you throw more exceptions than. . . . Well, I’ll leave that up to your imagination!

1 Like
4

I’m going to try all of them as much as it’s available to do so - with the GoPiGo O/S being the primary target.  I included the others so that after I get things the way I like 'em running on the GoPiGo O/S, I can try exporting it to the other operating systems, just in case.  And!  There’s still the Jetson Nano to convert!  Challenges abound!

So are birds and reptiles for that matter, but they’re still a thing, 'eh?  :wink:

1 Like
5

Update:

The Adafruit 128x32 OLED display appears to both work and not crash the robot.

20241005_204700
20241005_2047001920×865 110 KB

 

This is the Adafruit “Stats.py” test script.

Using both the servos and the test script at the same time causes the test script to pause a bit.

1 Like
6

Congrats!

Now how is your “CPU Load: 1.56”? Do you have a crypto miner running in the background?

1 Like
7

I don’t even know what that figure represents or its unit of measurement.  I had assumed that it was a percentage of total processor use.  (i.e. 1.56%)

What can you tell me about that number?

The script I used.

stats.py (2.9 KB)

8 
cmd = "top -bn1 | grep load | awk '{printf \"CPU Load: %.2f\", $(NF-2)}'"

Runs “top” in batch mode with one iteration, sending the result to grep which pulls out the line containing “load”, and processes that line with awk, which pulls out the 1 minute load average and calls that “CPU Load”.

Officially the “load average” is the number of processes in queue to be run, which just doesn’t speak to me at all.

Now my definition: The average number of CPU cores actually processing code - (and does not include any i/o activity).

I am not going to claim this is a valid definition - it is my definition that helps me evaluate what is going on inside that bugger.

My definition is also a bit cloudy until we think about the number “1.56” on your display and your CPU that has 4 cores.

An average load of “1.56” in my definition says computing is using an average of 1.56 cores of the four available cores - thus dividing the value by 4 yields the actual Raspberry Pi 4’s four core “Average CPU Load”. So 1.56 / 4 = 39% of your Raspberry Pi 4 is busy working. (Again ignoring I/O.)

To understand why I asked why your “1.56” is so high, I offer GoPi5Go-Dave’s 15 minute average load value of 0.27 (the values are 1, 5, and 15 minute averages) which is 6.75% of his Raspberry Pi 5 CPU:

GoPi5Go-Dave_top
GoPi5Go-Dave_top1484×576 98.8 KB

Dave at idle is:

  • reading the INA217 voltage, current, power
  • reading the GoPiGo3 Left and Right encoder and motor status values
  • converting the encoder values and the encoder value change into position and velocity estimates
  • computing battery power added or consumed since last docking change
  • estimating percent battery remaining
  • watching for a voltage or current value that requires action be initiated
  • publishing ROS 2 topics
pi@GoPi5Go:DOCKER:~/GoPi5Go/ros2ws $ ros2 topic list
/battery_state
/battery_voltage
/cmd_vel
/dock_status
/joint_states
/joy
/led/blinker/left
/led/blinker/right
/led/eye/left
/led/eye/right
/led/wifi
/motor/dps/both
/motor/dps/left
/motor/dps/right
/motor/encoder/left
/motor/encoder/right
/motor/position/both
/motor/position/left
/motor/position/right
/motor/pwm/both
/motor/pwm/left
/motor/pwm/right
/motor/status
/odom
/parameter_events
/robot_description
/rosout
/servo/position/S1
/servo/position/S2
/servo/pulse_width/S1
/servo/pulse_width/S2
/tf
/tf_static
  • the subscription call back for many of those published topics are being activated
  • AND the top program which is collecting the stats

All that is only loading Dave at 7%, while your program is using 39% of your Pi. So I asked “Do you have a crypto miner running in the background?”

p.s. My definition is only valid for an average load less than the number of cores - after that it doesn’t matter because your computer will never listen to you or talk to you again.

p.s.s. Today’s crypto miners are too smart to let you see them running. They shut down when you log in, so “just jokin’”.

ps.ps. The stats.py app loops 10 times per second. It would be interesting to see what the CPU Load value is if you change the sleep to 1 second:

time.sleep(1)   # was (0.1)
1 Like
9

It is possible that prior attempts were still running in the background.

I will have to try it next week as we’re visiting Uzbekistan right now.

I will look at the “stats” program and compare it to top/htop.

P.S.
How do you do the screenshot? The Pi O/S doesn’t include a screenshot utility.

P.p.s.

Maybe it’s the active RealVNC connection running that’s cranking it up?

1 Like
10

It is from the remote shell running on my Mac. I do not use (Tiger)VNC for a Remote Desktop into my Raspberry Pi computers very much.

1 Like