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


[CASPER] API update and software architecture

During these past weeks, we implemented several features in separate demonstration programs.

The time as now come to merge these features in a common architecture. For this purpose we revised the API we previously defined, in order to better fit our prototype and libraries.

Then we drew a schematic representation of casper’s software architecture, which should have a LUA script interpreter as the central element. This script interpreter will communicate with the other libraries by posting/retrieving data in a producer/consumer scheme, an exception being the configuration transactions.

The new version 0.2 of the API can be downloaded here: Casper API.

The software architecture is available in pdf file format here: architecture.

RoseWheel: tests preparation

This week we tried to put together our developments and make them interact with each other. It includes sensors communication, kalman filter, control feedback, motors control, CAN communication protocol. We were dogged by bad luck as we realized the heatsink of our mainboard was too big to fit in the Zzaag… A few millimeters required us to order for a new one with a more suitable shape. Fortunately Alexis and Samuel helped us to find a new one. Because of that we were not able to validate the following « feedback control tuning » PSSC for Saturday as planned. Adviced by Samuel we also decided to postpone the « encoders drivers » PSSC as it wasn’t really in our first order priorities.


We tried to make profit of this situation and decided to prepare everything for the first tests. Alexis helped us defining our tests procedure to be as safe as possible for both hardware and people. Motors need special attention as they can be broken with unsuitable commands. Because of the wheels and the weight of the chassis they have a really high inertia. Asking them sharply to reverse their direction of rotation when they are rotating fast can seriously damage them and the H-bridges. If we damage them we wouldn’t be able to order new ones before the end of the course, it would be fatal for our project. Therefore we need at first to make some testing at low speed so as to define the maximum acceptable speed at which we can run the motors before they get damaged. To this extent we need an interpreter running on the mainboard and communicating using RS232 to be able to give motors various commands and define this maximum speed. Then we need to limit our commands to this maximum speed using software limitations. Finally the interpreter should be able to change the feedback control values for our testing to be more flexible. We implemented such an interpreter and made a video. The motors commands in the video are given between 0 and 1000 such as:

  • ml0 = 0%:  max negative speed
  • ml500 = 50%: stop
  • ml1000 = 100%: max positive speed


Before trying the Zzaag motors we do some testings on other DC motors with less inertia that we cannot damage as easily as the Zzaag’s ones. Putting all the pieces together we were able to shoot a video which shows the motors reacting appropriately to the inclination of the sensorboard. As for the Kalman filter, we implemented a lighter version than the one of RoseWheel as it works best when tested on the real system. This version was only able to track the gyroscope drift and correct it. As far as we could see during the testing, it did it well. Concerning the PID, we tried to test the version that we are going to use in the RoseWheel but it still needs to be improved during the next tests.


Tomorrow we will be able to work on the Zzaag motors using our safe procedure and the tools developped. We look forward to it as it is a major step further for our project…

RoseWheel: gyroscope and communication protocol

Yesterday, after several days of debugging, we finally managed to gather data from the gyroscope. We ultimately found out that the freezes we were experiencing were caused by a reset interrupting an I2C cycle in the exact moment a slave was about to write a ’0′ on the SDA line (as an acknowledgement or during a read cycle); when the STM32 woke up and tried to generate a START condition, the slave would immediately force SDA to a low state, thus preventing the microcontroller from reclaiming the bus. We fixed this problem by sending several clock pulses on the SCL line until the IMU-3000 releases SDA; then, we can force a STOP condition and abort the incomplete cycle.

We have also completed a first version of our communication protocol. Under normal operating conditions, the following messages are exchanged on the bus:

ID Name Description Vital MAIN SENSOR HI
0×08 STOP Emergency Stop !!! Tx/Rx Tx/Rx Tx/Rx
0×09 RESET Reset !!! Tx/Rx Tx/Rx Tx/Rx
0x0A ANGLE_ANGVEL Angle from accelerometer, angular velocity from gyroscope !!! Rx Tx
0x0B SPEED Speed of RoseWheel !!! Tx Rx Rx
0x0C DANGER Danger (detected by distance sensor) !!! Tx/Rx Tx Rx
0x0D MOTORCOMMAND Command sent to the motor
0×10 REMOTECONTROL Remote control (from Bluetooth/UART) Rx Tx Rx
0×11 BATTERYLEVEL Battery level Tx Rx Rx
0×12 USERCOMAND User command Rx Rx Tx

In debug mode, the sensor board sniffs the bus so that it can send it by Bluetooth or serial port. The HI board monitors the exchanges as well to display relevant information on the LCD:

ID Name Description Vital MAIN SENSOR HI
0×08 STOP Emergency Stop !!! Tx/Rx Tx/Rx Tx/Rx
0×09 RESET Reset !!! Tx/Rx Tx/Rx Tx/Rx
0x0A ANGLE_ANGVEL Angle from accelerometer, angular velocity from gyroscope !!! Rx Tx Rx
0x0B SPEED Speed of RoseWheel !!! Tx Rx Rx
0x0C DANGER Danger (detected by distance sensor) !!! Tx/Rx Tx/Rx Rx
0x0D MOTORCOMMAND Command sent to the motor Tx Rx Rx
0×10 REMOTECONTROL Remote control (from Bluetooth/UART) Rx Tx Rx
0×11 BATTERYLEVEL Battery level Tx Rx Rx
0×12 USERCOMAND User command Rx Rx Tx



RoseWheel : CAN & Kalman

Today, we finished and/or improved some of the micro tasks we assigned to each other at the beginning of this week.

We tested a lighter version of the Kalman Filter that will be used in RoseWheel on the testbench we made a few weeks earlier. We used a light version because the full one needed to know the state equations of the system to be accurate. As we didn’t want to loose time trying to find out the state equations of the testbench (even if they are really similar to the ones of RoseWheel), we decided to test a version that was only able to track the drift of the gyroscope and make some minor corrections on the signal from the accelerometer during x axis translation. The light Kalman filter worked well and did what we expected, he tracked the drift and thus corrected the gyroscope noise and also filtered the signal from the accelerometer thanks to the sensor fusion.

During the experiments, we could observe that the noise from both the accelerometer and the gyroscope weren’t as high as we expected, that is a good news. However, even if the drift problem is correct by the Kalman filter, the measurements from the accelerometer are still not accurate during movements because of the noise induced by the other accelerations components. These other acceleration components are only dependents on the angle and its derivatives. We thought of a way to subtract those noisy components at each step by using the estimation of this values at the previous step. We will test it tomorrow on the testbench if we have time to do it.

We also finished the implementation of the CAN drivers and we tested it on our laboratory boards as we didn’t receive yet our mainboard. The tests were satisfaying. But as at the time we performed the tests we hadn’t decided yet the final version of the CAN protocol we were going to use for the communication between our 3 board (mainboard, sensorboard, HI board ), we didn’t use any filters. Hopefully tomorrow we will be able to test the CAN protocol as we will receive our mainboard.


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

RoseWheel : à pleine vitesse

Voici un compte rendu des avancées que nous avons fait pour la démonstration de vendredi et pendant le weekend :

Carte capteurs

Côté accéléromètre, nous avons réussi à communiquer proprement avec accéléromètre en utilisant une interruption externe liée au signal RDY ; cela nous a permis plusieurs démonstrations intéressantes : contrôle d’une LED suivant l’angle, envoi des valeurs mesurées par le port série, affichage de l’angle mesurée avec Matlab.

Pour le gyroscope, nous avons eu plus de difficultés, notamment pour bien gérer l’implémentation du protocole I2C dans le STM32. Après quelques heures de debug, nous sommes arrivés à une implémentation minimale du driver pour la démonstration, les données lues étant transmises par le port série et affichées dans le même graphique que celles en provenance de l’accéléromètre ; cependant, le capteur parfois s’arrêtait sans explication.

Dans un premier temps, nous avions attribué ce problème à des micro-coupures d’alimentation. Néanmoins, nous ne sommes toujours pas satisfaits de cette explication, puisque une telle fragilité n’est pas désirable pour une partie si vitale de notre projet ; alors, nous avons travaillé sur le code pendant le weekend pour essayer de trouver la source des instabilités, mais nous n’avons pas encore trouvé la réponse. À suivre donc…

Filtre de Kalman

Nous avons implémenté en C notre filtre de Kalman dans la journée du vendredi. Afin de procéder aux tests « définitifs », nous attendons d’avoir des drivers plus fiables pour le gyroscope et la partie mécanique monté, étant donné qu’il est indispensable de tester le filtre dans les conditions prévues sur le système pour lequel il a été conçu.

Entre-temps, nous envisageons d’utiliser une version un peu modifié qui ne traquerait que la dérive du gyroscope sur notre banc de test. Pendant la démonstration, nous avons montré nos performances en simulation, dont nous avions parlé dans notre dernier post.

Banc de test

Nous avons également montré au jury le fonctionnement de notre banc de test, notamment le graphique de variation d’angle et de vitesse angulaire, que nous avons détaillé dans des posts précédents.


Nous avons aussi avancé sur le bus CAN, et nous pensons à le tester demain avec les drivers que nous avons écrit ce week-end.


Nous commençons à implémenter les des moteurs et l’utilisation de PWM pour contrôler les ponts en H.
Sur notre PCB, nous utilisons des « pilotes de demi ponts en H » (IRS2184SPBF) qui permettent (entre autres) d’éviter les court circuits.
Dans le schéma suivant, ces composants se brancheraient à droite et à gauche de façon à ne jamais avoir A et B à la même valeur :

Pour pouvoir changer le sens de rotation, on pense utiliser la broche enable disponible sur le « pilote » (IRS2184SPBF).
Le chronogramme suivant illustre ce que l’on croit nécessaire au moment de la transition d’un sens de rotation à l’autre :


De façon à éviter d’entendre le signal de contrôle, on pense utiliser une fréquence de l’ordre de 20KHz mais on ne sait pas encore si cela ne sera pas trop élevé pour « limiter les pertes lors de la commutation des transistors du pont en H ».
Un certain nombre d’incertitudes persistent donc toute suggestion serait la bienvenue !

Planning pour la semaine – « micro-tâches »

Envisageant pouvoir asservir correctement le segway avant dimanche prochain, nous nous sommes attribués les « micro-tâches » suivantes pour la suite :

Drivers carte capteurs

- I2C / Gyroscope -> João 12/04
- SPI / Accéléromètre -> Clément 11/04

Drivers carte principale

- Drivers Ponts en H -> Cédric 13/04
- Contrôle moteurs -> Cédric 14/04
- Drivers CAN -> Florian 11/04
- Tests Drivers CAN -> Florian 11/04
- Protocole CAN -> João 13/04
- Tests protocole CAN -> João 14/04
- Drivers encodeurs -> Clément 14/04

Tests filtre de Kalman

- Intégration filtre TestBench -> Florian 13/04
- Réglage filtre -> Florian 17/04

Intégration logicielle carte capteurs

- Implémentation asservissement en C -> Clément 12/04
- Réglage de l’asservissement -> Clément 17/04
- Réglage direction -> João 17/04


- Montage RoseWheel -> Cédric 12/04
- Montage encodeurs RoseWheel -> Cédric 13/04

[CASPER] Avancées du projet côté mécanique…

Du côté de la mécanique, nous avons mis en pause le développement des drivers linux qui doivent à terme contrôler les moteurs. En effet, nous avons jugé que commander les moteurs au plus tôt et avec précision était plus prioritaire. Nous nous sommes donc penchés sur le contrôle des servos par PWM en utilisant la carte de TP STM32.

Jusque ici nous avons écrit un programme qui prend en charge les trois servos, qui est capable de prendre en entrée un angle comprit entre 0 et 180° et d’amener un servo à cette position. La prochaine étape est d’implémenter le modèle mécanique que nous avons conçu afin de donner au programme la direction de casper (sur 360°) et son inclinaison (sur 90°). Le programme interprétera ces données en terme de commandes moteurs.

RoseWheel : développement carte capteurs


Cédric a terminé le banc de tests. Après quelques ajustements au niveau communication (les deux cartes n’envoyaient pas leurs données à la même vitesse) nous sommes en mesure d’afficher :

  • la valeur de l’ADC donnant la position du potentiomètre et donc l’inclinaison
  • l’angle d’inclinaison calculé à partir de l’acceleromètre
  • la vitesse angulaire donnée par le gyroscope
  • la vitesse angulaire calculée à partir des données de l’ADC

Voici un exemple de graphe affichant en rouge ADC, en bleu calcul de l’angle à partir de l’accéléromètre, en vert la mesure du gyroscope et en noir la vitesse angulaire calculée à partir de l’ADC :

La prochaine étape est donc de confronter la simulation de notre filtre de Kalman au banc de tests…

Florian a travaillé à ajuster notre filtre de Kalman pour qu’il ne tienne compte que des données que nous récupérons sur le banc de tests. En effet jusqu’ici nos simulations faisaient l’hypothèse de la présence d’encodeurs. En simulation nous éstimons connaître parfaitement notre déplacement et notre vitesse de déplacement. Le montage du Zzaag nous dira si il est possible ou non d’inclure des encodeurs dans notre version finale. Florian et João ont également travaillé à l’amélioration du simulateur et de l’asservissement LQR.

João et moi-même avons bien avancé sur les drivers. Nous avons développé ces derniers en utilisant la bibliothèque STM32F10x_StdPeriph_Driver ce qui nous permet d’avoir un peu plus de flexibilité qu’en configurant directement les registres. Nous essayons d’implémenter les drivers pour nos différents périphériques aussi indépendemment que possible du brochage. Ainsi, pour chacune de nos cartes, nous aurons juste à « instancier » nos périphériques en indiquant la patte sur laquelle ils sont branchés. Nous avons nommé cette bibliothèque libperiph et en générons une version statique (.a) que nous lierons avec les objets de nos différentes cartes. Nous disposons dores et déjà de drivers pour :

  • Adcin (tout périphérique nécessitant des conversion ADC en « single conversion »)
  • Button
  • Buzzer
  • Leds
  • Sharps (utilisation de l’ADC en « continuous conversion » et du DMA)
  • Switch

Nous allons aujourd’hui tester ces drivers sur la carte de TP et implémenter les autres :

  • CAN
  • Accéléromètre (SPI)
  • Gyroscope (I2C)
  • UART
  • Bluetooth
  • Sonar
  • Encodeurs
  • Moteurs

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

IRL : avancées de la journée

Ajourd’hui nous avons travaillé en parallèle sur deux thèmes : le FPGA, et l’interface web.

Côté FPGA, nous avons pu simuler une RAM lisible et inscriptible depuis le processeur, ce qui est encore peu mais nous permet de penser qu’on a compris comment le lien fonctionne. Nous avons ensuite une une réflexion sur l’architecture fonctionnelle des modules du FPGA.
La mémoire du FPGA doit pouvoir servir de tampon, étant donné que Linux (peu précis au niveau du timing) enverra des paquets de données par à-coups, alors que la sortie vers le laser devra être cadencée bien régulièrement. Nous utiliserons les blocs de RAM internes du FPGA comme buffers avant et après la RAM (cf schéma), et les RAMs SPI de manière à ce que l’ensemble soit vu comme une FIFO par l’extérieur.
Le module de sécurité surveille les sorties du bloc de contrôle des DACs pour s’assurer que le laser ne reste pas allumé dans une trop petite zone durant un temps trop long. La taille de la zone (du moins sa traductions en déplacements « absolus » au niveau des coordonnées numériques) devra être fonction de la distance minimale à laquelle un observateur peut potentiellement se trouver. La durée maimale d’exposition sera à déterminer à partir de la puissance du Laser et des recommandations médicales. Cet ajustement n’est clairement pas la priorité actuelle.




Du côté du serveur Web, ça a été plus chaotique. Nous étions partis depuis deux jours sur l’utilisation de WebPy. Cependant son intégration avec SQLite impose l’utilisation de modules Python tierce partie, et la cross-compilation de ces modules nous pose beaucoup de problèmes. Dernièrement nous avons tenter de passer à la daily-build de la µClibC pour résoudre un problème avec l’importation de pysqlite3, ce qui a eu pour résultat de casser notre rootfs (kernel panic au démarrage à cause de dl_iterate_phdr()). Une simple recompilation en rechangeant de version de µClibC semble ne pas suffire (pour une raison inconnue), nous tenterons une recompilation depuis zéro demain.
Ces problèmes nous ont pris assez de temps et nous allons probablement chercher sur d’autres pistes, peut-être du côté de Mongrel2 comme Sam nous l’a conseillé.