Warning: The 2020-10-17 Raspbian for Robots image may have significant issues on the Pi-4 (and possibly other versions)

GoPiGo
, , , ,
1

Note:
This message has been significantly updated based on reports from other R4R users who have tried the 2020-10-17 image on their own systems.

The following information is primarily directed to people using a Pi-4 as their robotics platform.

Also note that there are reports on the Raspberry Pi forums that the release this is based off of can also affect earlier versions of the Raspberry Pi.

Your Mileage May, (and most certainly will), Vary.

With respect to variations in the software’s reported behavior:

  • My 'bot (Charlie) is currently using a Pi-4B, with 8 gigs (wishful thinking!) FOUR gigs of RAM.

  • @cyclicalobsessive is using a Pi-3B for his 'bot Carl. This can account for many of the differences in behavior noted in his following messages.

All of this should be taken with a large chunk of salt, noting that this particular Raspbian for Robots is very “experimental” and should not be used in “production” systems where unexpected behaviors might cause problems. (Like a classroom, or that super-important presentation for your company’s Big Boss.)

If, and that’s the key word here, IF you feel like experimenting with this version of Raspbian for Robots, go right ahead; but please:

  • Make sure you have a bare-metal backup image of your current system.
    (Ask if you don’t know how to make one.)

  • Report any strange behaviors or broken functionality here to this thread.

If you are using a Raspberry Pi-4, take note of the following potential issues/regressions:

  • WiFi doesn’t work. It fails with “no wireless interfaces found”.

  • The dhcpcd daemon crashes if IPv6 is enabled - and it is by default. You can eliminate this by sending
    sudo dhcpcd -4
    to the dhcpcd daemon, then you can disable IPv6 in the wireless setup, but wireless is still trashed.

  • VNC is flaky

  • SSH appears to be haunted.

  • The camera has significant visual artifacts, and does other flaky things.

  • Logs are spammed with dozens, maybe even hundreds, of bogus errors.

  • There are also reports that a “full-update” to that version from an earlier version of “Buster” may also bring these regressions/issues with it

  • I do not know if a normal, plain-vanilla update results in incorporating these broken features or not. Before trying ANY updates, bare-metal image your SD card/boot device first.

  • And so on, ad infinitum.
     

In my case, when I tried booting up Charlie with the new version, it appeared to be seriously haunted, (just in time for Halloween). Seriously, it was a real horror show.

It’s not a matter of “what features are broken”; it’s more like "try to find something that actually works.

There were really too many issues to list - it’s as if the whole distribution is trashed!

Since the release of the new version there are now roughly 18 PAGES of bug reports on the Raspberry Pi website - Buster Forums. And these aren’t the usual “You’re ugly and your mother dresses you funny” kind of new-version gripes you always get. These are more like "WHO LET THE DOGS OUT!  woof, woof-woof, woof-woof. . .)

I am shaking my head. I don’t know what happened, but it appears the distribution - or the cross-compiling of the distribution - is severely borked.

@cleoqc:
You may wish to withdraw that image until they get things cleaned up>

I moved Charlie back to the 2019-12-19 image and things are working well again.

1 Like
2

My Configuration:

  • Raspberry Pi 3B
  • SanDisk Ultra 32GB card
  • GoPiGo3 (red card) with V1.0.0 firmware
  • 8 NiMH AA cells in DI supplied holder

  1. I downloaded the 10-17-2020 R4R PiOS version and

  2. installed on a fresh SDcard with Raspberry PI Imager.

  3. I followed my prior setup steps (including disabling ipv6 based on your experience)

  4. Power On: The bot announced his onboard WiFi address

  5. I remoted in with ssh, and continued configuration
    a few minor changes - updated setup doc - will post later if all goes well

  6. git cloned Carl down to the bot

  7. ran my ./plib/status.py

**pi@Carl** : **~/Carl $** ./plib/status.py 
Starting status.py at 8.74v
********* CARL Basic STATUS *****
2020-10-22 12:36:55 up 11 min, 3 users, load average: 1.47, 0.87, 0.51
Battery Voltage: 9.61
5v Supply: 5.08
Estimated Life Remaining: 6 h 2 m
Processor Temp: 53.2'C
Clock Frequency: 800.084 MHz
throttled=0x0
Distance Sensor: 16.1 inches

and the Raspbian For Robots Desktop appears to be working:

Screen Shot 2020-10-22 at 12.49.02 PM
Screen Shot 2020-10-22 at 12.49.02 PM3804×1816 95.1 KB

All GoPiGo3 Control Panel functions worked correctly.

Servos, Distance Sensor, IMU, and Camera are all working.

Both onboard and USB dongle WiFi are working as expected.

USB Microphone is working (slightly different home/pi/.asoundrc than prior)

Text-To-Speech espeak-ng working

NoVNC/RealVNC in Web Browser and Mac Remote Desktop working well with 1920x1080 display configuration in raspi-config.

Completed the “Carl-ification” successfully:

  • setup cron for my docking and battery maintenance,
  • setup life.log function
  • setup encoder and imu logging

So far I do not detect any issues with moving from Stretch based R4R to the “PiOS” based R4R.

2 Likes
3

Maybe they’re more prevalent on the Pi-4 because it drove me bats! Though a there were a number of Pi-3 and lower “Me too!” comments.

When I started it up the desktop, updater, and control panel - both the stock one and my custom modified one - worked well. It’s only when I disconnected the hard-wired Ethernet that I started having problems.

I researched this and discovered that this latest version is generating a LOT of issues, none of which were trivial. Hence, the warning.

1 Like
4

Well, thank you for broaching the subject first.

I had been thinking that ipv6 issues were a thing of the past and thought disabling it was a bad practice now. Good tip, thanks.

One thing I tested for the first time was bringing “Carl” to a completely new card from GutHub, and that really worked amazingly. (I think. Time needed to confirm my pleasure is justified.)

1 Like
5

In theory, true.

In practice, especially if using an “older” router, IPv6 may be poorly implemented.

Back in 2009 I wrote a blog posting about this problem:

I suspect that a lot of the US internet backbone and providers do a poop-up job of implementing it too.

1 Like
6

Thanks Jim.
Most of the issues that are in the official Raspberry Pi OS release do not affect most users of our robots (some will, for sure, but not the majority).

Everyone:
the image that Jim is referring to is NOT an official release from Modular Robotics at the moment. It’s a test image. It was tested internally for Pi3B+ and Pi4.

1 Like
7

True.

As a consequence of the feedback I have received, I have significantly edited the original message and its subject title.

I may have been mistaken, but I remember it being placed where others could find it in the general run of things, and I wanted to caution against upgrading to this version simply because it’s the newest version.

Please accept my sincerest apologies for any unnecessary alarm or concerns I may have raised.

8

If the WiFi issue on Pi4 is connected to ipv6, suggest disabling it before the first boot:

=== disable ipv6

Browse the disk (boot)
Rt Click on System Volume Information->Open Terminal Here
cd ..

cp /boot/cmdline.txt /boot/cmdline.txt.bak
nano cmdline.txt
add to end of line/file:
ipv6.disable=1
save, exit editor

If you are using MS Windows use Notepad++ not regular notepad to edit Pi files!

1 Like
9

Sort-of.
IPv6 crashes the dhcpd daemon, causing DHCP autoconfig to fail regardless of the connection type. I was able to side-step that because I have static addressing configured for both WiFi and hard-wired Ethernet.

WiFi failing is a different problem that is not yet well characterized. Different people, all using Pi-4s, report differing behavior and differing solutions.

In my case, Ethernet worked fine, both static and DHCP. Wireless would not even try to work until I manually disabled IPv6. Then I could access the WiFi controls, but WiFi itself was still very brittle. Rebooting appears to reset / destroy all the changes made. Or at least most of them.

After rebooting my 'bot, the settings showed that IPv6 was already disabled, but I had to manually “disable” it again before I gained even a semblance of control over WiFi.

Sometimes WiFi would work for a few minutes before failing hard. Other times it would start dead and stay dead.

It’s a real Piece Of Work.

1 Like
10

You were correct. I learned a bunch moving Carl to a spanking new OS version, but I ended up getting spanked. Non-recoverable I2C failures are unacceptable.
At least now I know exactly how to fast forward Carl’s backup.

1 Like
11

Knowing how to revert to an earlier version of an image is always valuable.

You have accomplished much.