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


MB Led: weld of MB Leds and implementation of a remote

During the week end, we welded the MB Leds with Alexis. It was quite long but eventually we have our own blocks.

Benjamin created the remote functionality; It works quite well. If a block turns of 180°, it will be the remote to change the program.

I fixed some problems in the algorithm with the MB Leds and I will continue until the presentation.

After firmware transmission Cédric tried the firmware upgrade already implemented on TP PCB by Benjamin but failed to implement it on MB Led blocks in due time and eventually stopped his work : In fact, we have few time left and we prefer to focus on the presentation. Now, he will work on an animations.

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

Copterix: motors control, 1st test

Sensors and effectors

For now, we configured all sensors and effectors:

  • The Sharp, the distance sensor, works in 1-5m range and we get values with 3cm precision
  • Inertial Measurement Unit (gyros, accelerometers and magnetometers return correct values)
  • Radio Frequency (remote control, see video)
  • Motors (see video)

Here is a small video where we directly control motors’ speed with remote control:


We now have a reliable communication between our PCB and the Gumstix, thanks to Samuel Tardieu’s help.
We mostly use ZeroMQ to share data between our processes and even between our computers !


Kalman is quite smoothly, works as well on PC as on Gumstix, and we are now optimizing each operation. The actual filter is fast enough for real-time execution (we spend a lot more time to wait after data than to actually process it), but we want the filter to use less processor working time in order to execute other heavy tasks, like Lucas and Kanade (video tracking algorithm).
We do now have a way to get by Wifi only the Kalman’s results in order to display them on a PC using OpenGL as you could have seen it on our previous videos.

Next step

We are now up to test for the first time real servomechanism PID on our Copterix !


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

Copterix : first moves

Yesterday we finally observed the first moves of our octocopter. After spending all the day working on the communication with the motors, Samuel and Axel have succeeded in controlling the motors from the STM32, with the help of Jon, passing by. They speak to them in I2C, and they can control the speed of the propellers. The Copter tried to run away, but he was fortunately attached on a table. However, we have to be more careful in the way we will attach it in the future, because it was close to a disaster.

On my side, I tried the RF controller, a Spektrum DX7 transmitter/receiver. I tested it on the STM32 board that we have previously use for the communication challenge, it works as we can expect, thanks to the code of the Heliokter team. We use indeed the code from last year’s project, which seems to fit to our needs. The RF receiver gives us access to different integers, which indicate us the pitch, the roll, the yaw and the thrust, and also some commands. The way the receiver communicates with the PCB is simple : it use the RS232 protocol, with a speed of 115200 kbps. It sends packets of 16 bytes separated by long period with idle line. I have implemented the code for our PCB and for getting the commands on the Gumstix, but I still need to test it.

On his side, Bertrand principally tried to debug some aspect of the STM32 code. When we send data in the both directions and look for the values of the sensors at the same time, some freezes occur. We think it’s maybe because the code needs some optimization, so Bertrand is working on it.

[CASPER] Prototype fonctionnel

Hier, nous avons finalisé le prototype mécanique.

Nous avons installé les trois servomoteurs sous le plan du socle. Nous les contrôlons grâce à un signal PWM de la carte de TP STM32.

Nous avons changé nos anciens câbles de carbone par des câbles en plastique. Il est apparu que bien que leurs propriétés mécaniques en poussée/traction étaient bonnes, celles-ci ne sont pas assez flexible pour supporter les mouvements au niveau des bras motorisés.

Nous avons implémenté un programme de commandes qui fait effectuer un 360° à Casper que nous contrôlons par le potentiomètre (relié à l’ADC) de la carte de TP.

Nous allons maintenant travailler sur des fonctions qui permettent un contrôle précis de la direction et de l’inclinaison de Casper et en parallèle peaufiner le prototype afin qu’il soit plus robuste.

Voilà la vidéo du programme de démonstration (360° contrôlé par ADC) :


Parallèlement, l’UART sur le PCB est fonctionnel et on peut pour l’instant afficher les chaînes de caractères reçues sur l’écran LCD.

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

Copterix : mécanique & oscilloscope


Ce week-end, j’ai complètement modifié le PID. Avant, je mettais à jour à chaque itération les commandes moteurs. Maintenant, j’applique un delta aux commandes d’équilibre (à déterminer en pratique). Un testbench minimaliste montre que ce PID asservit correctement les trois angles (lacet, tangage et roulis) ainsi que l’altitude.

Après des tests sur l’hélico, il restera en l’englober dans un PID asservissant X et Y.


Samuel a terminé de récupérer les données des capteurs de notre PCB, Alexis ayant soudé les composants manquants. Il reste cependant à améliorer le calcul de l’altitude. Il faut en effet récupérer une dizaine de valeur sur l’altimètre pour calculer la pression. Pour l’instant la précision ne nous permet pas d’avoir un Δz exploitable.

Communication PCB/Gumstix

Loïc a terminé ses programmes pour communiquer entre PC et carte de TP que l’on doit porter sur Gumstix/PCB.

Nous avons donc branché le PCB sur la Gumstix. Les deux cartes sont connectées par une barrette 40 broches. On se sert de cinq d’entre elles: deux pour l’uart, une pour transmettre le VCC gumstix et deux en tant que GPIO. Il faudra écrire des modules pour la Gumstix pour contrôler les GPIO, c’est-à-dire l’enable du level-shifter (nécessaire, car la Gumstix est en 1.8V et notre PCB en 3.3V) et le reset du PCB.

Un debug à l’oscilloscope nous a montré que l’uart fonctionne en partie : on transmet de la Gumstix à notre PCB, mais cela ne fonctionne pas dans l’autre sens. En effet, les masses des deux cartes n’étant pas reliées, la différence de potentiel entre GND du PCB et VCC de la Gumstix est quasi nulle. Les sorties du level-shifter côté Gumstix sont ainsi inexploitables. Il faudra donc patcher la carte pour relier les deux masses.

Copterix : état des choses pour ce vendredi soir

I2C, et PCB en général

Samuel et moi-même avons pu finalement communiquer avec les gyroscopes de notre PCB, non sans mal (cf le post d’hier soir). Nous avons donc été en mesure de montrer un exemple de récupération des données des gyroscopes, accéléromètres et magnétomètres en temps réel lors des démonstrations de cet après-midi. Le programme de ce weekend de ce côté-là serait donc de discuter à présent avec les moteurs.

Communication avec le PCB

Loïc a fait une petite démonstration de sa gestion des erreurs lors des transmissions de paquets entre le PCB et un PC. Certains points restent à éclaircir, comme notamment le compte des erreurs et la gestion des coupures.


La démonstration du tracking ne s’est pas vraiment bien passée : effectivement, nous n’avons pas défini de protocole de test rigoureux, ce qui fait que nous avons une très mauvaise estimation des capacités réelles de notre tracking à l’heure actuelle. De plus, à cause de fuites de mémoires dans openCV non encore résolues, le programme tourne pendant 3 minutes avant de devoir s’arrêter faute de RAM. Un gros effort reste donc à fournir de ce côté-ci, mais cette fonctionnalité n’étant pas vitale pour faire voler l’hélicoptère, elle n’est pas en haut de la liste des priorités.


Notre implémentation du filtre du Kalman en test avec les données d’une IMU gentiment fournie par Samuel Tardieu n’a pas fait une grande impression sur le jury, le fait qu’il était facile de l’affoler en secouant un tout petit peu la carte ne devant pas y être étranger. Une explication possible mise en avant par Alexis serait que nous avons mal pris en compte l’orientation des gyroscopes : je vais donc m’y pencher dès que possible pour essayer de résoudre ce problème, qui lui est vital pour la bonne marche du projet.