Hands on ROS: Chapter 6 redo without GUI on the Pi

KeithW · August 9, 2020, 7:24pm

#handsonros #ros
I had a failure on my robot (which I call Finmark - after the company that made Robbie in the original version of Asimov’s I Robot stories) - it wasn’t connecting to the network (either wireless or wired). No idea what happened. After wasting an entire day googling and trouble shooting, I had to start from scratch. Now I’ve made a back-up image file of the robot so I don’t have to go through that again.

I had started to read chapter 7 (and I’ve done a little of this before), so this time I configured Ubuntu Mate to boot into the command line at startup (via raspi-config), and just set up ssh (p176. Note that it actually is necessary to remove then reinstall the openssh-server for SSH to work right; don’t be tempted to skip that step). Once that was done I could detach keyboard/mouse/monitor and just ssh in. I skipped adding the vnc serve, the IDE, and Terminator. I did install “screen” since I have a configuration file for that that I like and screen also ensures that commands running on the Raspberry Pi don’t die if the ssh terminal session is temporarily severed.

I installed everything as before up to the Case Study 2. You can just run those on a terminal session via SSH. For the graphics in Case Study 2 I configured my .bashrc files as indicated in the first part of Chapter 7 (pp 221 - 228) - I have a laptop running Ubuntu 18.04 with Melodic installed. If you start your ssh session with “ssh -X pi@{robot name.local or IP address}” the graphics windows for Case Study 2 will open on your linux computer, but the performance isn’t great (note that it’s supposed to be possible to do this on MS Windows with PuTTY and a Windows X-server as well, but I haven’t tried). If you have the robot and laptop configured correctly you can run roscore or the launch file from your robot, but then run the graphical programs from the laptop. MUCH better performance, since you’re offloading the graphics from the Pi to the laptop.

From there I just continued with Case Study 2 - everything worked fine with the programs distributed between the robot and the laptop.

Not sure how much overall performance benefit I’ll get from not running a GUI and an VNC server on the Pi, but there should be some.

One other note - from the “Files” app on my laptop, I can go to “Other location” and in the “Connect to Server” window enter “sftp pi@{robot name.local or IP address}”. I’m prompted for the password for my pi user on the robot. Now I have file system access to the robot. I can use the GUI file tools if needed. Even more handy - I can open the files on the robot with my programming editor on my laptop, so I don’t have to use “nano” for all file editing on the robot (I’m not a vi or emacs guy).

/K

cyclicalobsessive · August 9, 2020, 11:30pm

This really is the only reasonable use of ROS distributed feature. Minimizing the robot processing load to effectors and data collection, and using powerful platforms for processing, decision making, and graphical display for human consumption. The bot doesn’t consume the graphic so it needn’t waste effort on it.

A single board Computer is the wrong platform for a self contained ROS bot, any way you look at it. I am surprised than any ROS book would start out with everything on the bot.

KeithW · August 10, 2020, 1:05am

From a didactic point of view (building gradually) it makes some sense. Do think they should then have been clearer about offloading the Pi. Maybe Chapter 7 does - I’ve only just started, and got busy with other things today so haven’t gotten any further.
/K

cyclicalobsessive · August 10, 2020, 3:07pm

Possibly no benefit to not having the RPi Desktop GUI available and the VNC server not running, but I’m sure lots of benefit if you don’t use them when you want the robot to have all the processor power for it can.

As a test, I ran my GoPiGo3 without a vnc client attached all night, then connected (Mac Screen Connect App) at 8:40 am but did not do anything that used the display. Result - no visible load change:

I didn’t actually turn off the vnc server so there is some background cpu usage - 0.3%:

pi@Carl:~/Carl $ ./topcpu.sh
  PID  PPID %MEM %CPU CMD
 1800     1  2.4  3.4 python3 /home/pi/Carl/plib/imulog.py
 1706     1  2.4  1.1 python3 /home/pi/Carl/plib/wheellog.py
 1604     1  2.6  0.5 python3 /home/pi/Carl/Projects/Juicer/new_juicer.py
  943   693  3.7  0.3 lxpanel --profile LXDE-pi
 1062   873  3.7  0.3 lxpanel --profile LXDE-pi
19859 19776  3.1  0.3 lxpanel --profile LXDE-pi
    8     2  0.0  0.2 [rcu_sched]
  181     2  0.0  0.1 [spi0]
  320     1  0.3  0.1 avahi-daemon: running [Carl.local]

The robot’s three running processes, imu logger, wheel encoder logger, and" juicer" - ( the autonomous battery level maintenance, charging status monitor, and dock/undock program) consume about 5% of the CPU.

KeithW · August 11, 2020, 12:12am

Interesting - not as much as I thought just to run the VNC server. Still - why run something I don’t need.
Thanks,
/K

cyclicalobsessive · August 11, 2020, 2:53am

I often make use of the desktop GoPiGo3 Control Panel app to just drive the bot around, and the Update DI Software app is handy, and while you mention using ssh -X I haven’t figured that one out so I debug all my OpenCV programs from a shell on the desktop. (Once they work as desired, the bot runs them without needing to show me what it is “seeing”.)

If you don’t need, sounds like a good idea to not install.

KeithW · August 12, 2020, 1:31am

One other note:

on p224 it mentions “ifconfig” - this has been deprecated in Ubuntu. Use the “ip -a” command instead to find the ip address.

KeithW · August 12, 2020, 1:35am

I haven’t tried the GoPiGo3 Control Panel app or the Update DI Software app- I’ll have to see if they were added as part of the configuration of the robot for Ubuntu Mate.
/K

KeithW · September 4, 2020, 8:08pm

Once again had a failure where I couldn’t connect to the network. This time it was wifi only. And it occured after an update. Previous time when I had done a “sudo apt-get dist-upgrade” I got an error message:
Errors were encountered while processing:
/tmp/apt-dpkg-install-Rac3Q5/038-linux-firmware-raspi2_1.20200601+arm64-0ubuntu2~18.04.1_armhf.deb

After googling I found a way to force the update. And things continued to run fine the rest of that evening. It was after the next boot that I had the failure. Maybe it’s just a coincidence, but I’m not going to try again just in case. Just wanted to note it here for other’s reference.

I spent more time googling for a fix; the couple of things I found that looked promising didn’t work. Fortunately I’d made a copy of the micro-SD card up to Chapter 6, so I was able to restore. Now I need to work through what additions I had made after this checkpoint.

I need to be more diligent at saving checkpoints as I move along in case it happens again.

/K

cleoqc · September 12, 2020, 1:02am

Oh, I had no idea! I’m not a big Ubuntu user. I wonder if it will trickle down to Debian, and then RaspberryPi OS…

cyclicalobsessive · September 12, 2020, 3:24am

ip addr works on both R4R Stretch, and PiOS but not as clean as ifconfig:

(ip -a does not)

(Look for 10.0.0.XX below)
ifconfig:

wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.XX  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 2601:580:4480:63f0:175b:7b2c:7130:xxxx  prefixlen 64  scopeid 0x0<global>
        inet6 2601:580:4480:63f0::xxxx  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::fb7a:952:182:xxxx  prefixlen 64  scopeid 0x20<link>
        ether 74:da:38:db:45:xx  txqueuelen 1000  (Ethernet)
        RX packets 2021  bytes 468274 (457.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1116  bytes 156178 (152.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ip addr:

4: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 74:da:38:db:45:XX brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.XX/24 brd 10.0.0.255 scope global dynamic noprefixroute wlan1
       valid_lft 604229sec preferred_lft 528629sec
    inet6 2601:580:4480:63f0::XXXX/128 scope global dynamic noprefixroute 
       valid_lft 604225sec preferred_lft 604225sec
    inet6 2601:580:4480:63f0:175b:7b2c:7130:XXXX/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 232583sec preferred_lft 232583sec
    inet6 fe80::fb7a:952:182:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

este · October 10, 2023, 8:33pm

@KeithW I just wanted to share something I ran across while I am preparing to start handsonros Chapter 6. There is a nifty Raspberry Pi compatibility chart on this ubuntu-mate.org page. Specifically, it states “the experience with models with 1 GB of RAM may be hampered by memory pressure and increase wear on SD cards due to swapping.”

Of course, I am using a Pi 3 B+ which has 1 Gb RAM (and perhaps you did too?). At any rate, I am guessing it is possible to damage the uSD card with enough Unbuntu-Mate usage which could be what you were seeing (twice). In fact, the web page explicitly states one should use a quality uSD card. Of course, I only have some cheap ones so I guess I need to purchase some good uSD cards and keep frequent backups. Yes, I could get a Pi 4 which has more RAM but I already had the Pi 3 B+ and I am basically cheap.

KeithW · October 10, 2023, 10:51pm

Thanks. That’s interesting. I mostly use Micro Center store branded cards, so maybe that was the issue.
/K

jimrh · October 13, 2023, 9:23am

Good μSD cards are a MUST as a crappy, low-end, “ghost-shift” SD card is just an exercise in masochism.

I specifically avoid:

Kingston
PNY
Strange brands that nobody’s ever heard of.
“Store” brands.
- Micro Center branded storage is the exception. See below.

I specifically look for:

SanDisk
Samsung.
Toshiba

Also, (believe it or not), Micro Center branded storage is actually pretty good. (I believe it’s made by Toshiba?)

Make sure you get application rated SD cards - they should be rated “A1” or “A2” (or better.

I particularly like the SanDisk Extreme line of chips. They cost like a Lamborghini, but perform like one too.

If you’re going to do a lot of work, and want a noticable bump in performance, use a USB 3.n micro-SSD (I have three 500 gb micro-SSD’s that were marketed as miniature backup drives.)

I discovered that the difference in access times is sufficiently great that the system is much “snappier” - and I’m running a full GUI, have Visual Studio Code’s native “wedge” installed and running, and am using multiple screens.

I believe they’re by Seagate, but they’re put away right now. I’ll check and get back to you with an update.

Again, this is documented elsewhere within these forums.

este · October 13, 2023, 3:00pm

Thanks for those thoughts @jimrh. I have been looking into industrial uSD cards which are more expensive but have at least two advantages I am interested in.

One advantage is a higher endurance and the other is the ability to monitor the health of the SD card.

It is my understanding that the improved endurance arises from use of “SLC (single level cell) flash” rather than “MLC (multi level cell) flash” found in consumer grade uSD cards (see here and here)

The other advantage is the ability to monitor the health of the SD card via the “Health Status Register” (see here which contains a link to the SanDisk Industrial microSD card Datasheet Long Form where on p 8 of here is more info and this raspberrypi.com forum page here discusses how it might be used in a raspi context.)

From the 2017 release of the SanDisk industrial and automotive grade SD and micro SD cards, this info where “endurance” is stated as 192 TBW (teraBytes Written).

See also this info from the SD association in July 24, 2023.

So far, this is about so-called industrial uSD cards. There is also a class of cards called “high endurance”. I have not researched these much but they seem to get most of the endurance advantage of industrial uSD cards but perhaps not the health monitoring.

As far as I can tell, there are two markets for these cards. The “industrial” uSD cards are “meant” for IoT, automotive, robotics and similar applications whereas the “high endurance” uSD cards are “meant” for video applications.

Now I just need to choose which such advanced uSD card to try! Leaning towards one of the SanDisk industrial uSD cards.

KeithW · October 13, 2023, 3:27pm

I’ve had really good luck with them overall. Unfortunately I no longer live in a city that has Micro Center - I’d have to drive down to Chicago. Oh well.
/K

jimrh · October 14, 2023, 11:43am

Just make sure they’re “application” rated as video-optimized cards emphasize serial read/write performance over random read/write performance which is essential for snappy O/S based applications.

If endurance is a primary requirement, along with snappy performance, Seagate’s line of micro-sized USB 3.n SSDs provide lots of storage space, SMART monitoring, support for TRIM¹, along with snappier performance and a non-trivial endurance when compared to SD cards.

The SanDisk Extreme SSDs are a good choice as, though they’re not trivially cheap, they provide a reasonable price per unit storage and are designed to be rugged². If I remember correctly, they also support TRIM, but may not support SMART monitoring or other advanced mass-storage functions that true SSDs support. (See the man pages for hdparm for more information.)

Since I’m not exactly sure what your application is, or your absolute requirements are, I’m not sure what to recommend, but I hope I’ve provided some useful guidance.

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

On a completely different topic:

If you decide to clone/backup your storage using rsync, make sure you set it to copy symlinks and hard links as symlinks and hard links, instead of dereferencing them and copying the actual files themselves, which is rsync’s default behavior. That behavior breaks essential functionality and totally screws up updates and app installs.

In the past PINN used an unmodified rsync to make the clones which caused issues. I griped that issue back then, but afterwards lost track of the project and I don’t know if that was ever implemented

What say ye?

--------------------

Footnotes:

SSD and μSD card support for TRIM requires a special modification to the OS’s attributes for the SSD. It’s not difficult but is a bit gnarly.
I’ve done things to those SD cards that shouldn’t happen to a DOG!

For example, I’ve rolled over them with office chairs on hard floors after dropping them or vacuuming them up with a motorized floor brush. I haven’t tried hitting them with a hammer, or strapping them to high explosives, (), but aside from that, I have subjected them to just about everything a total clutz could subject them to - and they have survived well.

este · October 14, 2023, 7:58pm

Thanks for those suggestions @jimrh.
Right now, I am making regular image backups of my Raspi uSD card (using Win32DiskImager to make the image and then using PiShrink to “deflate” the image).

jimrh · October 15, 2023, 1:46pm

I can’t say I’ve tried either of those methods so I’m not really qualified to have an opinion.

I am given to understand that the native “SD copy” in Raspbian/GoPiGo OS does a good job.

I’ve tried a couple of the “deflation” (trimming) routines to remove the unused space in an image and I have reported results elsewhere.

Key tips:

Make sure you clean up things like the update cache by using apt-get clean.
Clean up things like /var/log and /usr/tmp.
Clear the browser cache.
Clear “secrets” (any passwords you’ve used on-line). Some cleanup/compression routines do this automatically if you pass the correct parameters.

This will result in the best and smallest image.

Test:
Try mounting the image with imagemounter. If the image is valid, both /boot and /root partitions will mount and be readable.

este · October 15, 2023, 3:51pm

PiShrink is great because it it “shrinks” by removing unused space on the image. For example, on my Raspi uSD card, only about half of storage space is used. Sure enough, after applying PiShrink to the image created by Win32DiskImager from that uSD card the resulting “shrunk” image is half the size! When you then restore that “shrunk” image, it “grows” (Is that the opposite of shrink?) back to the original size. Magic!