#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).
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.
/K
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:
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.
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.
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
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.
