First experience with RPi3
I am working on a project that required some computing power and commanding an Arduino UNO running GRBL. Things have changed quite a bit from
original plan, so because radio reception was awful, the original plan of using dump1090 with a USB dongle had to be ditched. Of course I only learned that once I have it working nicely on the Raspberry Pi 3.
Plan B would be to use the Ethernet network interface. Once that was working we realized it was not possible on our target installation.
Plan C was to use wifi. And while it is really simple to get it working with stock Jesse, I found a way to waste my time when I added spaces in between variables and equal signs in /etc/wpa_supplicant/wpa_supplicant.conf. So now you have been warned.
Once wifi connection was working and the rest of the project code was up and running I wanted to have it all to autostart. However, I always like to be able to peek into each program to see how that is going on.
If I had chosen to start each program off /etc/rc.local I had the problem that I won't be able to see what is going on with the terminal output of each program unless I redirect its output to a file, but that usually uses up disk space and eventually needs to be deleted and wears the flash memory.
Instead, I decided to use screen command to launch each program. And, as usual, it did not work at first try. Several things are slightly different there than from bash command line:
Plan B would be to use the Ethernet network interface. Once that was working we realized it was not possible on our target installation.
Plan C was to use wifi. And while it is really simple to get it working with stock Jesse, I found a way to waste my time when I added spaces in between variables and equal signs in /etc/wpa_supplicant/wpa_supplicant.conf. So now you have been warned.
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
iface eth0 inet manual
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#------------ wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="mynet"
psk="mypass"
}
Once wifi connection was working and the rest of the project code was up and running I wanted to have it all to autostart. However, I always like to be able to peek into each program to see how that is going on.
If I had chosen to start each program off /etc/rc.local I had the problem that I won't be able to see what is going on with the terminal output of each program unless I redirect its output to a file, but that usually uses up disk space and eventually needs to be deleted and wears the flash memory.
Instead, I decided to use screen command to launch each program. And, as usual, it did not work at first try. Several things are slightly different there than from bash command line:
- root user in the one running the show there, if you launch something it will be under that user (unless you do something about it)
- commands and files locations need to be specified carefully, as there is no $PATH value to rely on.
- you can always use su - username -c "command" to launch a program under other user credentials
- any program you launch here needs to end quickly as you are delaying the boot process, if you need to launch a long program it has to be on the background (use &)
Once I understood all these points I was able to launch my commands using lines like this:
- su - pi -c "/usr/bin/screen -d -m /home/pi/mycommand"
And while you do not see the & at the end of the line, it is the -d parameter of screen what takes care of running it as a daemon process and not blocking the script flow.
The good thing is that later, I can log into the RPi3 and use screen -r
Comments
When we built the trashcan bot at CRF we added a RPI (I think it was version 2) with a wireless USB card so we could send voice from a mobile phone using mumble, distort it to make it sound robotic using a set of effects and jackd and then play it so it could be heard over some speakers built in the base of the robot.
We found though that the system took a lot of power which limited the amount of time we could use it as the batteries where shared with the electric motors controlling the wheels and the lighting fixtures.
Works quite OK for me.
I usually also redirect syslog to remote server (and replace it with busybox version) and have the RPi mounted read-only to save the SD card.
Although this requires a bit better management of tmpfs to make sure you don't run out of memory (and therefore storage space).
So, sometimes, I also mount nfs drive for things that need frequent read-write ops.
However, the screen solution is great for debugging early versions of scripts :D).
Thanks for documenting it - I am always reinventing the wheel when I use it ;)