Skip to main content

Hello ! This is my blog powered by Known. I post articles and links about coding, FOSS, but not only, in French (mostly) or English (if I did not find anything related before).


Raspberry Pi install checklist

2 min read

This is some memo for me, to use as a checklist whenever I set up a new Raspberry Pi which is to be running continuously (typically as a webserver).

First, I start from the lite version of Raspbian.

After install:

  1. sudo apt-get update && sudo apt-get upgrade

  2. sudo raspi-config and tweak according to my needs.

  3. Install some useful tools:

sudo apt-get install ack-grep fail2ban git heirloom-mailx htop libxml2-dev libxslt1-dev libyaml-dev moreutils msmtp-mta python-dev python-pip python3 python3-dev python3-pip screen vim zlib1g-dev

  1. Install RPi-Monitor. First install its dependencies:

sudo apt-get install librrds-perl libhttp-daemon-perl libjson-perl libipc-sharelite-perl libfile-which-perl

  1. cd $HOME; git clone; cd RPi-Monitor; sudo TARGETDIR=/ STARTUPSYS=systemd make install to install it. Be careful about a current bug with systemd install

  2. Some useful bash config: echo 'export PATH=$HOME/.local/bin:$PATH' >> $HOME/.bashrc; echo 'export EDITOR=vim' >> $HOME/.bashrc.

  3. Use NTP to keep the system in sync with current time: sudo timedatectl set-ntp true.

  4. Load ip_conntrack_ftp module: sudo echo "ip_conntrack_ftp" >>& /etc/modules-load.d/modules.conf.

  5. Set up an iptables systemd service à la Arch Linux. See this unit. Put iptables config in /etc/iptables/ip{6,}tables.rules.

  6. Remove the file in /etc/sudoers.d which prevents pi user from having to type its password.

  7. Configure msmtp to be able to send emails using the mailserver on my main server.

  8. Harden SSH configuration as you would do for a server.

  9. Set a MAILTO address in crontab and edit aliases.


Doing low cost telepresence (for under $200)

8 min read

With a friend, we recently started a project of building a project of low cost telepresence robot (sorry, link in French only) at our local hackerspace.

The goal is to build a robot that could be used to move around a room remotely, and stream audio and video in both directions. Our target budget is $200. We got a first working version (although it does not yet stream audio), and it is time for some explanations on the setup and how to build your own =) All the instructions, code and necessary stuff can be found at our git repo.

Screen capture

3D model

Basic idea

When taking part in a group meeting remotely, using some videoconference solution, it is often frustrating not being able to move around the room on the other side. This prevents us from having parallel discussions, and if the remote microphone is poor quality, we often do not hear clearly everybody speaking. Plus, someone speaking may be hidden by another speaker and many other such problems happen.

The goal was then to find a solution to do videoconferences (streaming both audio and video in both directions) and be able to move on the other side, to be able to see everyone and to come closer to the current speaker. Commercial solutions exist but they are really expensive (a few thousands dollars). We wanted to have the same basic features for $200, and it seems we almost achieved it!

Bill of Materials

The whole system is built around a Raspberry Pi and a PiCamera, which offer decent performances at a very fair price. The rest is really basic DIY stuff.

Here is the complete bill of materials:

Total: $140


  • We had to use a Raspberry Pi model 2 for the nice performance boost on this model. Even more important is the increased number of GPIOs on this model, with 2 usable hardware PWMs (provided that you don't use the integrated sound card output). This is useful to control the two wheels with hardware PWM and have a precise control of the move. The camera holder can be safely controlled with a software PWM and we did not experience any troubles doing so.
  • You can easily replace those parts by equivalent ones as long as you keep in mind that the battery pack should be able to provide enough current for the raspberry pi and the servos. We used standard USB battery packs for simplicity and user friendliness. However, they are more expensive than standard modelling lithium batteries and provide less current in general.
  • We had to use two battery packs. Indeed, the peak current due to the servos starting was too excessive for the battery pack and it was crashing the raspberry pi. Using two separate alimentation lines for the raspberry pi and the servos, we no longer have this problem and this solution is easier than tweaking the alimentation line until the raspberry pi stops freezing (which it may never do).

For the next version, we plan to add:

Total with these parts: $228


  • We used an HDMI screen as the official RaspberryPi screen uses most of the GPIOs pins, which we need. We decided to use bluetooth speakers as the integrated sound card was not usable as we were using the two hardware PWM lines for motion. This way, we have a speaker with a built-in microphone, which smaller than having the two of them separately.
  • The USB bluetooth adapter is impressively expensive, but it is the only one we found at the moment which we were sure would be compatible with Linux without any problems. Plus others adapters we found were not much cheaper.
  • The total budget is $223 without shipping. It is a bit over the initial budget goal, but we can easily lower it to $200. Indeed, we did not especially look for the cheaper parts. In particular, we bought the servos from Adafruit and I think we can find some servos for less (especially the camera holder servo, which can be a micro servo at $5 and should be enough). The bluetooth adapter is quite expensive as well and we could find a cheaper one I think. Budget shrinkage will be our next goal, once we have everything working.

Building the robot

All the necessary stuff is in our git repo (or its github mirror, both should be kept in sync). The repo contains three main directories: - blueprints which are the models of the robot. - disty which is the main server code on the Raspberry Pi. - webview which is the web controller served by the Raspberry Pi.

First of all, you should cut the parts and print the 3D parts in the blueprints dir. eps files in this directory are ready to cut files whereas svg files should be the same ones in easily editable format. You should laser cut the top and bottom files. picam_case_* files are the camera case we used,

You should 3D print:

  • the picam_case_* files for the camera case (licensed under CC BY SA).
  • teleprez.blend is the complete CAO model of the robot in Blender.
  • camera_servo_holder.stl is the plastic part to hold the camera servo. You need to print it once. wheel_servo_holder.stl is the plastic part to hold the servos for the wheels. You need four of them.

Assembling your Disty robot should be straightforward and easy to do if you look at the following pictures :) Use two ball transfer units to stabilize the robot and lock them with some rubber band (or anything better than that). Adjust tightly the height of the wheels so that the two wheels and the ball transfer units touch the ground.




GPIO pinout for the connection can be found at

GPIO pinout

For the electrical wiring, we used a standard USB-Micro USB cable to power the Raspberry Pi from one battery (located below the robot, to add weight on the ball transfer units and ensure contact is made with the surface). On the other battery, we just cut a USB - Micro USB cable to plug into it and connect the servos directly through a piece of breadboard to the battery. We had to use two batteries to prevent the draw from the servos to reboot the Raspberry Pi.

Here you are, you have a working Disty!

Running it

This may not be super user-friendly at the moment, we hope to improve this in the future.

Download any Linux image you want for your Raspberry Pi. Install uv4l and the uv4l-webrtc component. Enable the camera and ensure you can take pictures from the command line (there is a lot of doc) about this on the web.

Then, clone the Git repo somewhere on your Raspberry Pi. You should build the main disty code (which is the serverside code). This code will handle the control of the servos (emit PWMs etc) and listen on UDP port 4242 for instructions sent from the webview. Instructions to build it are located in the associated README. You will need cmake and a system-wide install of wiringpi to build the code.

You can then start the robot. Start by launching the disty program (as root as you need access to the GPIOs), ./disty, and then start the webview, ./ as root also as it serves the webview on port 80, which is below 1024 and owned by root. If you have ZeroConf on your Raspberry Pi (or a decent router), you can go to http://disty (or whatever hostname is set on your Raspberry Pi) to get the webview. Else, use the IP address instead. Webview usage should be almost straightforward.

It should work out of the box on your local LAN. If you are behind a NAT, it will need some black magic (which is implemented but may not be sufficient) to connect the remote user and Disty camera. In any case, you need to be able to access the webview (disty port 80) from the remote side.


All contributions and feedbacks are more than welcomed!

All the source code we wrote is under a beer-ware license, under otherwise specified.

* --------------------------------------------------------------------------------
* "THE BEER-WARE LICENSE" (Revision 42):
* Phyks and Élie wrote this file. As long as you retain this notice you
* can do whatever you want with this stuff (and you can also do whatever you want
* with this stuff without retaining it, but that's not cool...). If we meet some
* day, and you think this stuff is worth it, you can buy us a beer
* in return.
*                                                                       hackEns
* ---------------------------------------------------------------------------------

If you need a more legally valid license, you can consider Disty to be under an MIT license.

Some sources of inspiration and documentation


Quelques astuces pour Arduino

2 min read

Voici astuces en vrac pour Arduino que j'ai découvertes ces derniers jours, en codant pour CitizenWatt et en particulier pour le capteur.

Stocker des données en Flash

Il peut arriver d'avoir pas mal de données statiques dans un programme et donc d'arriver à court de RAM disponible (2ko sur un ATMega 328p / Arduino Uno). Et quand ça arrive, c'est le drame (typiquement, le Serial se mettait à faire n'importe quoi dans mon cas)…

Par exemple, à chaque appel de Serial.println("Quelque chose");, la chaîne de caractères "Quelque chose" est chargée en RAM. Du coup, sur un code assez long, avec pas mal d'affichage verbeux sur la liaison série, on sature vite la RAM.

Qu'à cela ne tienne, il est possible de stocker la chaîne dans la Flash et de la charger directement depuis la Flash. Avant, c'était compliqué, il fallait utiliser PROGMEM, mais depuis la version 1.0 de l'IDE, il suffit d'entourer la chaîne de F(), par exemple Serial.println(F("Quelque chose"));. Source

Et au passage, un petit bout de code pour savoir combien il reste de RAM disponible.

Les préférences de l'IDE

Je n'avais jamais été faire un tour dans les préférences de l'IDE non plus, principalement par flemme. Qu'à cela ne tienne, c'est désormais chose faite, et j'y ai croisé quelques options vraiment vitales.

En particulier, Afficher les résultats détaillés pendant compilation qui permettra d'avoir un output plus verbeux pendant la compilation.

Mais la vraie révélation de cette soirée, c'est l'option Utiliser un éditeur externe. Vous ne supportez plus l'éditeur Arduino et son indentation pourrie, ses fonctionnalités dignes de notepad premier du nom et son non affichage des numéros de ligne (à part en bas dans un petit coin, inutilisable au possible pour débugger efficacement), cette option est faite pour vous ! En l'activant, Arduino ne lira plus le fichier. Vous pouvez l'éditer comme vous voulez dans un éditeur externe (Vim uploader le code, l'IDE Arduino ira relire le fichier, le compiler et l'uploader.



Graver un bootloader sur ATmega8

3 min read

Pour un projet avec mon hacklab hackEns (éclairage de façades avec des LEDs de puissance, dans la même veine que AllColorsAreBeautiful du CCC, voir cette page pour plus d'infos), on a eu besoin de graver 30 bootloaders sur des ATmega8. On n'a pas de programmateur et on le fait donc avec des Arduinos. Comme toujours, il nous a fallu 2h de debug avant de graver le premier :) (mais cette fois, ça a été rentable avec 30 bootloaders gravés d'un coup !).

Du coup, je fais une petite compil' des liens qui marchent et des trucs importants à vérifier pour ne pas perdre deux heures (les messages d'erreur du soft Arduino étant *tellement* explicites... et il y a 10 méthodes différentes, chacune aboutissant à une erreur différente sur le net).

Tout d'abord, un bon lien qui marche bien : ArduinoToBreadboard dans la doc Arduino. Les montages sont clairs et ont été testé par moi-même ces derniers jours :).

Gravure de bootloader

Montage pour graver le bootloader Montage pour graver le bootloader, in situ

Envoi de programmes

Montage pour l'upload Montage pour l'upload

Notes diverses

  • Testé avec un Arduino Uno comme programmateur, sans capacités ni résistances sur les pins de reset. Et ça fonctionne ! Par contre, on a eu des problèmes avec un Arduino Mega, donc on est resté sur l'Uno (sans chercher plus, sûrement un problème de reset automatique).
  • Si ça ne marche pas, vérifier que l'ATmega est bien enfoncé dans la breadboard ! C'est stupide, mais on oublie une fois sur deux... :)
  • Hyper important ! Sur le montage pour graver le bootloader, la résistance au reset est en pull-up (connectée au 5V) et non en pull-down (connectée au GND). J'ai perdu 1h là-dessus...
  • Testé et approuvé avec la dernière version du soft Arduino et du sketch ArduinoISP. Pas besoin d'une vieille version a priori.
  • Si ça ne marche toujours pas, bien vérifier le montage, encore et encore :)
  • Mieux vaut utiliser le soft Arduino que la ligne de commande avec avrdude. En effet, Arduino gère tout seul les fuse bits (utilisation d'un cristal externe, temps de démarrage, protection du bootloader) et c'est donc moins prise de tête. Sinon, pour les calculer, c'est par ici et par ici pour plus d'infos sur l'utilisation d'un quartz externe.
  • Lorsque le bootloader est gravé, pour envoyer des programmes facilement, il faut qu'il puisse reset sur serial (sinon, il faut faire un reset manuel à chaque fois). Pour ça, il faut mettre une capacité et une résistance sur le pin de reset (cf schematics des Arduino).