ELECINF344/381

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

Catégories

[CASPER] PSSC

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.

 

Text-to-speech

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] Beagleboard, pilotes et pwm

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

 

Bootstrap

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.

[CASPER] Reconnaissance vocale et synthèse

Bonjour à tous.

Comme vous le savez déjà pour la plupart, nous avons montré Mercredi que nous étions désormais capables d’effectuer une reconnaissance vocale performante en Anglais, en utilisant la librairie CMU Pocketsphinx.

Cette librairie permet la reconnaissance de phrases complètes, ce qui permet de bénéficier d’une bonne qualité de détection en prenant mieux en compte la nature du langage. Afin d’améliorer la détection des commandes, nous avons généré à partir des outils fournis avec pocketsphinx un dictionnaire et un modèle de langage qui ne contiennent que les mots dont nous avons besoin.

Nous souhaiterions générer ce type de dictionnaire/modèle de langage pour le Français, ce qui s’avère plus compliqué étant donné qu’il n’existe pas encore d’outils réalisant ce travail.

 

En ce qui concerne la synthèse vocale, notre choix s’est porté sur l’excellente librairie SVOX Pico, qui fait déjà ses preuves sur les téléphones Android (avis aux amateurs voulant l’essayer).

La voix est, en comparaison avec d’autres solutions libres, naturelle et fluide. Cette bibliothèque supporte l’anglais (US et GB), l’allemand, le français, l’espagnol et l’italien. Nous avons à présent un Hello world fonctionnel qui synthétise la voix correspondant à un texte (stocké en dur dans le code pour le moment) et qui envoie les échantillons directement à pulseaudio pour une lecture sur haut parleur.

Cette bibliothèque nous laisse entrevoir la possibilité de lire des messages dans les 5 langues précédemment citées, ce qui pourrait donner une valeur ajoutée intéressante au projet.

 

Il nous reste à porter tous ces programmes sur la beagleboard et mesurer leurs performances respectives, en terme d’occupation mémoire et de temps de calcul.