Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).


[Casper] Face tracking

We now have our face tracking algorithm running on BeagleBoard. Since a tracking only based on face detection was to slow and not very intuitive (you always have to look the camera), we decided to use a blob tracking algorithm, which we initialize with the face detection algorithm.

First, Casper looks for a face. When it finds one, it learns the associated color histogram. After what it tracks the histogram (with the OpenCV Camshift function), for a few tens of frames. If it does not find a face again during the blob tracking, it stops at the end of the frames. Otherwise, it keeps tracking the « blob » face.

We adopt a multithread program : a thread looks for a face every second, and a thread is responsible for blob tracking when a face is found. The first thread is used to set a counter which is decremented by the second thread.


[CASPER] can fetch and store mails

We made some improvements in our mail fetcher. Now, it’s able to fetch mails from most mail server ( pop3, secured or not). It can fetch the last mail received and store its content and subject into a file, so it can be read by our text-to-speach engine.

Moreover, we had the mail fetcher work in the Beagleboard.

As a reminder, we are using the C++ library Vmime 0.9.1.

[CASPER] Today’s news

We progressed in different fields today.

Alain designed a small extension PCB for the beagleboard. This board will include the necessary elements for audio amplification in and out, and for level shifting between the beagleboard’s output and the motors’ input.

At the same time, we worked with Thomas to build a first tracking system demo, by placing the webcam on top of casper’s body, connecting it to the beagleboard and then connecting the serial link to drive the motors. This demo gave some first results tonight, and will be kept under improvement.

Finally, we managed to create a custom language model and dictionary, which combined with the pocketsphinx engine’s data now allow the beagleboard to understand french vocal commands.

[CASPER] New video about Mechanical advances

This week-end we added a new video showing how we are able to control Casper’s direction and bending remotely. Movements are smoother and have a good response time.

Now, that we got a UART connexion working on the BeagleBoard we will be soon trying to use it to control Casper.

[Casper] Audio in/out on the beagleboard, and drivers

Audio in/out

As I said in a previous post, we are now able to synthesize speech from a text input, and play the result directly on the audio output jack using a home-made interface between the synthesis engine and alsa.

We had also to port our speech recognition hello-world on the beagleboard. We first compiled the CMU Pocketsphinx library for the board, that is to say for an arm target, and then the hello-world program.

The program successfully recognized commands we recorded and played on the laptop, while having the beagleboard’s audio input connected to the laptop’s headset output by an appropriate cable.

We now have to interface electronically our microphones to the beagleboard’s audio input.



Apart from the progress in the audio, we also managed to compile a linux kernel module hello world on the board, despite the current custom kernel’s lack of certain header files.
The helloworld ran properly, and we were able to write a string to it, and read it back.

The next step will be to start developing our custom linux device driver, responsible for casper’s mechanical control.

[Casper] Flash, Screen and Pictures…

We’ve been working these last few days on the PCB, to display pictures and to save and load them from flash.

First, we developped a set of functions to erase, write and read the flash memory, using a SPI protocol. After testing it with text strings we displayed on the screen, we tried with pictures. However, the STM32 RAM is not big enough to handle a whole picture : we have at most 20kbytes RAM, and one picture takes 25kbytes (132*132 pixels of 12 bits, 4 for each RGB channel). So we read the flash per 256 bytes blocks that we send to the LCD screen, until transfer completion. Similarly, we write flash per 256 bytes blocks when receiving a picture from the UART connection.

In order to have a simple protocol for writing pictures, we do not allow two pictures to share a same memory sector (smallest erasable area). Since each sector is 4 kbytes wide, we use 7 sectors for each picture : that’s about 3 kbytes too large. However, this allows to store 146 pictures in the flash, which should be enough for our project. We did not work yet on the possibility of storing smaller pictures which could be used to refresh a small screen area. It may be useful for animations.

Finally, we use the screen configuration options to rotate pictures by 90, 180 or 270 degrees, changing the way the screen controller reads the RAM.

Moreover, we wrote a small program which uses OpenCV library (which is already used on the beagleboard for face detection and recognition) and converts a picture (jpeg, png, bmp,…) in a 132*132 12 bits picture and saves it in a file that can be sent to the PCB by UART.


After some over-the-internet discussions, we finally agreed on the following list of goals and milestones :

A interface task is placed between SVOX Pico and ALSA on the beagleboard  – 04/18  Thibault
The beagleboard and Casper PCB communicate over an UART link – 19/04  Alain
We store and read images to and from the flash memory on the Casper PCB – 20/04  Alain
We are capable of having the beagleboard read a text file out loud – 20/04 Thibault
The beagleboard is able to recognized predetermined vocal commands – 21/04  Thibault
The LCD display adapts itself according to the robot’s orientation – 22/04  Alain
We are capable of controlling the robot’s tilt angle  -  22/04  Thomas
We are capable of controlling the robot’s orientation (azimuth) – 22/04   Thomas
The robot as been assembled, and the devices (camera, PCB, …) are on board – 23/04  Thomas
We can make the robot track a face (the robot’s orientation follows slow mouvements) – 25/04   Alain
The API we previously defined is accessible from LUA scripts - 27/04   Thibault
The robot is capable of accessing a simple mail box (without encryption protocols) – 28/04   Alain
The robot has a simple remote http setup interface – 29/04   Thomas
We use a LUA script, using the API, to drive the robot for the demo – 29/04   Thomas
The servomotors are being driven by a linux device driver on the beagleboard – 29/04  Thibault

[CASPER] : text-to-speech on the beagleboard

Here is a little summary of what has been done today, regarding the text-to-speech on the beagleboard.

Audio with alsa on the beagleboard

First, I would like to explain the step we followed to get the audio output to work on the beagleboard without damaging the TPS6595, which manages the audio, but also the power supply (now I am sure that you understand the reason why we should not burn this one down).

We have on our SD card a bootstrapped version of the ubuntu linux distribution, with alsa installed.

To get alsa to work without being the superuser, you have to add the normal user to the audio group, and reboot the beagleboard.

Then, open the alsamixer program.

Here is was you SHOULD NOT do, despite it is being advised on some forums : enable each and every device in alsamixer.
This will cause the TPS6595 chip to overheat, and may damage it.


What you should do is enable only what is necessary :

  • Increase the volume of the DAC2 analog; DAC2 digital coarse and DAC2 digital fine.
  • Increase the volume of the headset
  • Enable headsetL2 and headsetR2

You should now have a working audio output.



In order for our whole application to work properly on the board, we decided not to use pulseaudio (which requires up to 40% of the CPU on the board). We decided to implement our own interface for the audio output, which would handle all the write requests from internal threads such as the text-to-speech engine’s thread. This interface would store the corresponding samples, pre-process them in order to fit alsa’s interleaved pcm format, and play them on the audio output.

We were able to test successfully this interface today, by synthesizing speech with SVOX pico on the beagleboard, and playing it simultaneously on the audio output.

The whole process requires 30% of the cpu during a short period (synthesis/samples post) and then 0/0.7% of the CPU during the rest of the the process, which is good news compared to the 40% CPU minimum required during the whole process in our previous experiments.

The next step will be to port the CMU Sphinx recognition helloworld we designed to the beagleboard.

[Casper] OpenCV et Beagleboard

Aujourd’hui j’ai porté les algorithmes de détection et reconnaissance faciale sur Beagleboard, sans trop de soucis. Comme nous n’avons pas encore reçu la webcam, je me suis contenté de les tester sur des images jpeg. Les temps de traitement sont deux fois plus longs sur Beagleboard que sur mon PC, et nous allons donc certainement jouer sur la taille des images pour avoir un temps de traitement convenable.

Je me suis également penché sur le projet d’optimisation d’OpenCV utilisant le DSP de la beagleboard, mais un benchmark disponible sur le site du projet montre que le gain en performances est plus que relatif. Le seul intérêt pourrait être de décharger le processeur de certains traitements. Nous reviendrons donc vers ce projet uniquement si le besoin s’en fait réellement sentir…

Nous avons de plus reçu notre carte aujourd’hui et nous commençons donc sa prise en main.

[CASPER] Beagleboard, pilotes et pwm

Voici un petit compte rendu de ce que Thomas et moi-même avons réalisé hier et aujourd’hui.



Partant de ce que Thomas avait réalisé précédemment, nous avons automatisé l’installation de la carte SD pour la beagleboard. En effet, celle-ci doit contenir dans une première partition FAT les fichiers du noyau nécessaires au démarrage, et sur une deuxième partition du format de notre choix la racine du système de fichiers.

Afin de pouvoir choisir plus finement quel noyau et quel paquets nous souhaitons installer sur notre beagleboard, et pour pouvoir la placer rapidement dans une configuration « prête à utiliser » lors d’une éventuelle réinitialisation, nous avons choisi de ne pas utiliser les images de rootfs proposées sur internet par la communauté de développeurs beagleboard.

Nous avons donc construit notre propre image rootfs à l’aide de l’outil debootstrap couplé à l’émulateur qemu, ce qui permet de créer sur un ordinateur portable classique une distribution pour une architecture arm, par exemple. Nous avons inclus de nombreux paquets tels que la bibliothèque opencv qui nous sert pour le traitement de l’image, et SVOX pico, qui nous sert pour la synthèse vocale.

Nous avons ensuite configuré la distribution afin d’obtenir une console sur le port série et paramétré la distribution afin de la rendre directement utilisable.

Ces étapes ont été totalement automatisées dans un script, ce qui nous permettrait éventuellement de regénérer tout ceci très rapidement, tout en faisant évoluer nos paramètres.

Nous avons ensuite généré les fichiers de boot à partir du noyau de sorte qu’il supporte le système de fichiers nilfs2¹ (Le garbage collector du nilfs2 sera lancé automatiquement, dès lors que les paquets nilfs-tools et nilfs2-tools sont installés sur le système. Il faut donc les ajouter dans le script debootstrap_init.sh).


Le système de fichiers nilfs2 offre en résumé deux avantages : sa structure garantit l’intégrité des fichiers écrits ce qui évite la corruption de la carte en cas de coupure de courant ou de plantage et il offre d’excellentes performances sur la carte SD en comparaison avec l’ext2 par exemple.

Cela est certainement dû à sa structure circulaire, et à son mode de fonctionnement avec garbage collector. En effet, les fichiers supprimés ne sont pas effacés immédiatement, ce qui aurait pour effet de ralentir les opérations. Ces effacements ne sont réalisés que beaucoup plus tard, à la fin d’un compte à rebours ou lorsque les segments propres sont en nombre insuffisant. Ainsi, l’écriture est rapide puisque sans effacement, et l’effacement est retardé ce qui à nouveau permet de gagner beaucoup en vitesse de fonctionnement. (L’installation de paquets logiciels est aussi rapide que sur un ordinateur moderne avec nilfs2, ce qui était loin d’être le cas avec ext2 puisqu’en fonction des dépendances, il fallait entre 15 et 60 min)


Ensuite, un autre script que nous avons réalisé automatise la génération d’une archive tarball rootfs.

Une version adaptée du script setup_sdcard.sh (http://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh) nous permet ensuite, là encore de manière automatisée, de formater la carte mémoire et de créer les partitions, de générer les fichiers uImage et uBoot, et enfin de copier les fichiers de boot et d’extraire le tarball rootfs sur les partitions correspondantes.

Nous avons de plus écrit une notice détaillant l’utilisation de ces scripts en vue de générer rapidement une installation pleinement fonctionnelle et incluant tous les paquets logiciels nécessaires sur la carte SD.


¹ Merci PHH pour les conseils !



Pilotes et PWM

Thomas continue de se pencher sur la question des pilotes. Il a réalisé un helloworld que nous ne pouvions malheureusement tester sur la beagleboard, du fait que celle-ci était immobilisée par les opérations de préparation de la carte SD. Maintenant que celle-ci est prête, nous allons pouvoir tester la compilation et l’installation dynamique de ce module de communication helloworld dans le noyau.

Étant donné que la beagleboard n’était pas prête, et outre sa participation à la création de la nouvelle distribution au travers de son expérience précédente avec la première installation que nous avions réalisée avec le script setup_sdcard.sh, Thomas a continué de se documenter sur la réalisation de pilotes et sur l’utilisation des modules PWM sur la beagleboard.