First of all we will need to download some packages (instructions assume the use of Raspbian) to allow us to compile Arduino compatible code (arduino-mk) and upload it (avrdude) to the Arduino.
sudo apt-get install arduino-core arduino-mk
Then add yourself to the dialout group to allow you to upload code to the Arduino board
sudo usermod -a -G dialout pi (Change pi to be your username if different)
Logout and then log back in again to ensure you are recognised as a member of the dialout group.
To compile an Arduino program it is neccessary to create a file called Makefile that is used to specify parameters for the compilation.
touch Makefile
Open the file for editing:
nano Makefile
And paste in the following text:
ARDUINO_DIR = /usr/share/arduino
BOARD_TAG = uno
ARDUINO_PORT = /dev/ttyACM*
ARDUINO_LIBS =
include /usr/share/arduino/Arduino.mk
You may need to change the BOARD_TAG to reflect the version of the Arduino you are using
You can test that your sketch compiles by running make and ensuring that there are no errors.
To upload your compiled sketch to the Arduino:
make upload
This process allows for programming the Arduino without using a graphical user interface, and also allows updates to Arduino code to be propagated to devices using scripts (assuming the Arduino is connected to the Pi via USB).
Tuesday, 28 January 2014
Monday, 27 January 2014
Running GUI applications from another computer on Raspberry Pi (or vice versa)
The Raspberry Pi is a great piece of kit, however it's not particularly suitable for CPU or memory hungry applications (e.g. Firefox). There may also be times that you want to run an application you have on another computer on your Pi without having to install it.
As long as you are able to SSH onto a computer where that application is installed (and it can run the X Window System - Linux will almost certainly do this out of the box) you can use a feature of the X window system to run the application on the remote computer but route the graphical window to your Pi (where it will behave - pretty much - as a standard graphical program.
To do this you must first be in a graphical environment on your Pi, for Raspbian this is started from the command line by typing startx. From here start the Terminal emulator, and log in to the remote computer over SSH using the -X switch:
ssh -X username@192.168.0.2
Replace username with your username (default on Raspbian is pi) and 192.168.0.2 with the IP address of the remote computer.
You should now have what looks like a standard SSH terminal to the remote computer, however if you run a graphical program on the remote system the output will be displayed on the Pi. If you are logging into an Ubuntu/Debian or otherwise Gnome-based computer try running gedit as a quick test.
This also works in reverse, so you can run graphical programs on the Pi and have them display on your Linux desktop.
As long as you are able to SSH onto a computer where that application is installed (and it can run the X Window System - Linux will almost certainly do this out of the box) you can use a feature of the X window system to run the application on the remote computer but route the graphical window to your Pi (where it will behave - pretty much - as a standard graphical program.
To do this you must first be in a graphical environment on your Pi, for Raspbian this is started from the command line by typing startx. From here start the Terminal emulator, and log in to the remote computer over SSH using the -X switch:
ssh -X username@192.168.0.2
Replace username with your username (default on Raspbian is pi) and 192.168.0.2 with the IP address of the remote computer.
You should now have what looks like a standard SSH terminal to the remote computer, however if you run a graphical program on the remote system the output will be displayed on the Pi. If you are logging into an Ubuntu/Debian or otherwise Gnome-based computer try running gedit as a quick test.
This also works in reverse, so you can run graphical programs on the Pi and have them display on your Linux desktop.
Running the Midori browser on my Raspberry Pi with the output redirected to an Ubuntu desktop using 'ssh -x' |
Saturday, 25 January 2014
Using public/private keys to log in to Raspbian
This assumes working from a *nix environment, and that you haven’t previously created a public/private key pair (e.g. for using Github). If you are unsure type cat ~/.ssh/id_rsa into the terminal - if you get a load of characters ending in "-----END RSA PRIVATE KEY-----" you already have a key that you can use - go straight to Step 2.
Step 1: Generating a public/private key pair
This is as easy as:
ssh-keygen -t rsa -C "name@email.com"
(Obviously replace name@email.com with your own email address).
The system may ask you whether you want to create a passphrase for this key, if you do you will be asked to enter this passphrase the first time you use the key in any given session. If you do not want to set a passphrase just hit enter.
Step 2: Getting your key to the Raspberry Pi
This is again a simple one line command that logs into Raspbian using a password and adds your key to the list of authorised keys on the system.
cat ~/.ssh/id_rsa.pub | ssh pi@10.0.2.2 "mkdir .ssh; touch .ssh/authorized_keys; cat >> .ssh/authorized_keys"
You will need to change 10.0.2.2 to the IP address used by your Raspberry Pi. You will be prompted for the password of the 'pi' user on your Raspberry Pi. If you then use the exit command to leave the pi and return to your *nix system you hsould now be able to log on simply by typing:
ssh pi@10.0.2.2
If you used a passphrase to protect your keys you will be prompted to enter this the first time you use the key in any session.
Step 1: Generating a public/private key pair
This is as easy as:
ssh-keygen -t rsa -C "name@email.com"
(Obviously replace name@email.com with your own email address).
The system may ask you whether you want to create a passphrase for this key, if you do you will be asked to enter this passphrase the first time you use the key in any given session. If you do not want to set a passphrase just hit enter.
Step 2: Getting your key to the Raspberry Pi
This is again a simple one line command that logs into Raspbian using a password and adds your key to the list of authorised keys on the system.
cat ~/.ssh/id_rsa.pub | ssh pi@10.0.2.2 "mkdir .ssh; touch .ssh/authorized_keys; cat >> .ssh/authorized_keys"
You will need to change 10.0.2.2 to the IP address used by your Raspberry Pi. You will be prompted for the password of the 'pi' user on your Raspberry Pi. If you then use the exit command to leave the pi and return to your *nix system you hsould now be able to log on simply by typing:
ssh pi@10.0.2.2
If you used a passphrase to protect your keys you will be prompted to enter this the first time you use the key in any session.
Thursday, 23 January 2014
Citizen Cyber Summit 2014 (Feb 20-22 2014)
An interesting event hosted by the Royal Geographical Society and University College London: Citizen Cyber Summit 2014.
I will be there (although not presenting) along with a number of Natural History Museum colleagues, and a number of people from the ViBRANT Citizen Science Workshop I helped organise about a year ago.
I will be there (although not presenting) along with a number of Natural History Museum colleagues, and a number of people from the ViBRANT Citizen Science Workshop I helped organise about a year ago.
Battle hardening Raspberry Pi 1: the 'Fork Bomb'
I have been thinking recently of using a number of Raspberry Pis as a platform for doing a number of biodiversity science projects. This would (possibly) require allowing people external to the project running code on the devices, so I have been looking into what needs to be done to 'battle harden' the standard Raspbian distribution for use in this, or similar projects.
Let's just say that the Pis may well end up in a number of inaccessible locations, and it might end up being very difficult to hard reset them. In my mind the first thing I think of when letting people access such a system is the 'Fork bomb' - creating an ever increasing number of processes (accidentally or otherwise) until the system runs out of resources.
Perhaps the best known *NIX fork bomb is the following:
:(){ :|: & };:
This innocuous looking code defines a function with no parameters : that calls itself and pipes the output from calling itself into a new background process { :|: &};. The final : runs the function for the first time.
The solution to this is to specify a maximum number of processes in the file /etc/security/limits.conf - adding the following line sets a limit for all users apart from root:
* hard nproc 1024
On my 512MB Raspberry Pi this easily prevents the fork bomb from causing havoc - although for most circumstances I will need a lower limit (e.g. 512) is likely to be sufficiently adequate.
Let's just say that the Pis may well end up in a number of inaccessible locations, and it might end up being very difficult to hard reset them. In my mind the first thing I think of when letting people access such a system is the 'Fork bomb' - creating an ever increasing number of processes (accidentally or otherwise) until the system runs out of resources.
Perhaps the best known *NIX fork bomb is the following:
:(){ :|: & };:
This innocuous looking code defines a function with no parameters : that calls itself and pipes the output from calling itself into a new background process { :|: &};. The final : runs the function for the first time.
The solution to this is to specify a maximum number of processes in the file /etc/security/limits.conf - adding the following line sets a limit for all users apart from root:
* hard nproc 1024
On my 512MB Raspberry Pi this easily prevents the fork bomb from causing havoc - although for most circumstances I will need a lower limit (e.g. 512) is likely to be sufficiently adequate.
Labels:
battle hardening raspberry pi,
fork bomb,
linux,
raspberry pi,
security
Monday, 13 January 2014
Darwin Core Archives
In a presentation I gave not so long ago (Building Highways in the Informatics Landscape) I suggested that Darwin Core Archive (DwC-A) was the lingua franca of biodiversity informatics. A position that I still stand by. However it's a lingua franca with different dialects - and implementation is not quite as simple as it perhaps could (should?) be. In a recent paper (Linking multiple biodiversity informatics platforms with Darwin Core Archives) in the new Biodiversity Data Journal I, along with Simon Rycroft and Vince Smith, set out some of the challenges in making a 'several dialects' DwC-A that satisfies the needs of all current DwC-A consumers of the Scratchpad project.
Subscribe to:
Posts (Atom)
ShareThis
Copyright Ed Baker