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

#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).


1 Like

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.

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.

1 Like

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
 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.

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

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.

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.

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.

1 Like

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:

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.


1 Like

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…

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)

wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.XX  netmask  broadcast
        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 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

1 Like