That’s a great sounding platitude, but “True [robot] enlightenment” will be neither simple nor elegantly simple.
Or in hardware terms, a computer is a totally fixed complex organization of a billion elegantly simple electron junctions that require an equally complex organization of the three elegantly simple atomic functions (set, test, jump) to be useful for any truly usable task.
Perhaps joy is found in elegant simplicity, but reality is complex, messy, and anything but simple.
True, but I still can’t shake the feeling that these things are overly complex.
“Inside every large program is a small program struggling to get out.”
Guess what!
I found something that actually works with the GoPiGo-3!
One of my long-time desires was to have some kind of “secondary” display for Charlie where I could send important messages that are important even if the 'bot is running headless.
The people at WaveShare, (www.waveshare.com), have a series of e-Ink displays.
I bought a 2.13" two color, (red and black), e-Ink hat for Charlie:
This display has three interesting properties:
It uses “4 wire” SPI, where there is also an additional chip-select pin.
it is addressed as device 0,0 instead of the red board’s address of 0,1.
Since it uses e-Ink technology, whatever is there remains there until it is explicitly removed - even when power is lost.
The result is that - apparently - the WaveShare e-Ink display does not interfere with the GoPiGo’s functionality.
The one BIG downside is that screen updates take like 3+ seconds each, so it can’t be used for real-time messaging or status.
Next steps:
Find a place for the SSD that’s not in the way of the display.
That is so cool! Congratulations on the success, and the exploration.
I doubt the information can be read and comprehended faster than that.
Perhaps put the display in a thread with a one message deep LIFO queue and Charlie will not have to wait for the display to update.
Actually, it’s so clumsy a display that I can only use it for static status at this point.
Viz.:
This allows me to post a “message to myself” about the configuration and other essential details.
Hopefully I will find out a way to make it more relevant.
One thing I do notice is that, occasionally, the display will update with a vertical-bar display artifact that I suspect is caused by contention on the SPI buss. There’s probably a mutex I have to invoke somewhere to keep east and west separate. 
P.S.
This message tells me:
This way, each operating system is self-describing on boot-up.
Here’s a small video of Charlie starting up.
https://www.mediafire.com/file/uscc58f88yxp83w/Charlie_e-Ink_Startup.mp4/file
Note:
The original display is the display from the prior session. e-Ink displays do not change unless explicitly commanded to change - even if power is lost.
The first event is the initial “initialize and clear the screen” event.
The second event puts the first part of the message on the screen.
The third event adds the last line.
Each message is like updating a graphical display - you build a buffer that gets rasterized and “blitted” to the display.
If you accidentally put something where something else is, they’re combined, overwriting each other.
I suspect that all the flashing and blinking is the controller resetting all the dot elements to a known state, then blitting in the buffer.
Very cool.
I’m a little bit familiar with a board from AdaFruit that also has an e-ink display. That board has a sleep state which is VERY low power - the board will wake on a signal, or after a certain amount of time has passed (and will run a specific program when it wakes). Does your board do something like that?
/K
This board also has a very-low-power sleep state, but for an e-ink display it borders on being an oxymoron - e-ink doesn’t draw power unless it’s being changed.
If I remember rightly, the quiescent current borders on microscopic and the sleep current is infinitesimal. I really didn’t see the reason to put it to sleep, as the steady-state current of everything else is so much larger by comparison, it seemed pointless. . . .
I know the display itself doesn’t, but wasn’t sure about the driver board.
/K
The driver board draws some current, but it’s really trivial when compared to the current draw of everything else.
For those of you who are interested, here is the entire startup sequence.
https://www.mediafire.com/file/1sb6jf873h7w8fp/Charlie%2527s_Startup_Script_-_timed.mp4/file
The audio, if you can hear it, has me “start!”(ing) the script at about four seconds into the video. The display script has ended when the pan-and-tilt servos begin moving, so I used that to indicate end-of-script.
Total time from clicking on the script to servo movement was about 30 seconds.
Here’s the script itself, if you’re curious.
check_os_bitness.sh.txt (4.5 KB)
I could put it in a code-block, but it would be a wall of words.
P.S.
It won’t run stand-alone. It needs a bunch of supporting libraries too.
