ELECINF344/381

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

Catégories

[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.

 

Drivers

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] 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] Demo de vendredi et API RS232

Voici dans ce post un bilan de la démonstration de Vendredi, ainsi qu’un bref état des lieux des avancées d’aujourd’hui concernant la programmation série en C sous linux.

 

Démonstration de vendredi

Nous avons Vendredi fait état de nos dernières avancées.

Nous avons débuté la démonstration par la présentation du PCB que nous avions réalisé et qu’Alexis nous avait remis il y a peu. Alain a, comme il l’a montré dans un post précédent, réussi à piloter l’écran LCD et afficher une animation simple comportant des rectangles de couleur et du texte.
Reste maintenant à réaliser l’interface série entre la carte et un ordinateur, puis programmer la mémoire flash embarquée.

Nous avons poursuivi par la démonstration de Thomas qui a piloté par l’intermédiaire de la carte de TP STM32 l’un des servomoteurs que nous allons utiliser. Grâce à son programme, nous sommes capables de piloter ces moteurs en leur fournissant une consigne angulaire.
Reste désormais à piloter le prototype en installant trois servomoteurs dans sa base.

Nous avons ensuite effectué une démonstration logicielle qui rassemblait les « helloworlds » que nous avions réalisés avec les différentes bibliothèques. Nous avons ainsi pu piloter à la voix l’ordinateur, lui demander de faire l’apprentissage de deux visages, puis de passer en mode reconnaissance. Une fois en mode reconnaissance, le moteur de synthèse vocale interfacé pour le moment avec pulseaudio a salué les visages connus en les nommant par leurs prénoms.

 

Comme Thomas l’a signalé dans son billet, nous avons pour le moment mis de côté le développement de drivers, pour nous concentrer essentiellement sur la mécanique, la programmation du PCB, et le port de nos applications sur la beagleboard.

Afin de préciser notre démarche, nous publierons bientôt sur ce site une liste actualisée de nos PSCC et des responsables associés.

 

Avancées de la journée : API RS232

De mon côté, je me suis penché sur la programmation du port série en C sous linux. J’ai trouvé à ce sujet une excellente source de documentation, qui m’a permis de comprendre rapidement l’interface posix permettant d’en effectuer la configuration. Vous retrouverez ce guide ici.

J’ai créé une interface de plus haut niveau permettant de lire et d’écrire sur un nombre indéfini de ports série, et de rentre transparente la gestion des lectures et écritures avec tampon.

Il suffit en effet pour utiliser un port série d’en demander l’ouverture en précisant le fichier /dev/tty* associé, et de donner en argument la fonction que l’on souhaite être appelée pour traiter les données.

L’API se charge ensuite d’appeler cette fonction lorsque de nouvelles données sont disponibles, ainsi que d’écrire les données stockées dans des tampons chainés lorsque le matériel est prêt.

L’utilisateur peut donc utiliser des fonctions non bloquantes pour écrire, et utiliser ses propres fonctions pour lire.

Pour finir, bien que cela ne soit pas encore implémenté, il est possible d’ajouter à cette API les sockets en plus des ports série. Cela permettrait de gérer par le biais d’une interface unique toutes les transmissions de la beagleboard, que ce soit par réseau ou avec le PCB.

[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.