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


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

MB Led: Led Matrix, Direction and Acknowledgment

It is time to make a debriefing about last week achievement.

Led Matrix:

Colour gradient and intensity

Benjamin worked on the Led driver in order to display a picture and has fixed some problems with luminosity. He balanced green, blue and red and we are now able to display a white colour on our blocks (although a blue tint remains on videos). From now on, we also have a linear gradient of intensity for each primary colour. In order to obtain this gradient, we first tried to put a linear variation of intensity in registers, but it appeared linearity didn’t worked and he had to adjusted individually each step.

Electronic visual display:

An interruption is raised with a frequency of 10kHz and each time a new line is displayed. As our Led matrix has 8 lines, we have a electronic visual display at 1,25kHz. Each time we want to display a new line we connect to the Led driver through SPI sending it thanks to a vector of 288bits matching a 8 pixel line with three colour and 12 bit of gray control. Actually we only use 4 bit for each colour.


Yesterday I implemented acknowledgement system with IrDA transmission. First I needed to divide our sending queue into 2 queues: one for quick packets which don’t need ack such as PING, PONG and synchronizing messages sent at high frequency and allowing some losses; the other one is for important packet needing a safe transmission. These packet are sent to a task which could be seen as a buffer sending a packet (every 40ms) until it receives an ACK and then picking up the next one. In order to identify a packet an ACK transmit the ID of  the sender and the ID of the packet it acknowledge and when an ACK packet is received, a message containing these information is send to the task managing output packets. In order to avoid loop waiting for an ACK , we use a counter and if a packet is not acknowledged after 10 tries we consider it as a lost packet (for ping messages, if we don’t receive one PONG for 10 of our PING,  we consider the neighbour as gone). Once a neighbour is gone we empty the sending queues for this UART.

This system is not optimal, being slow, but at higher speed we got a lot corruption during transmission and more packet are lost.


We decided to rethink our algorithm after the reactions of yesterday’s post. We changed the algorithm when some block is leaving the network. If someone is missing, the block which notice that says it to the network. Every other block answer by « I’m still here ». If the leader doesn’t answer (probably he’s gone), there is an other election; those who don’t answer are considered to be out of the network. In this algorithm, the blocks keep in memory their position and orientation and we don’t have to start an election every time some block quits.

A little video showing up some features as the use of LED driver, election and direction:

NOTE: Now once a direction is decided, it is kept when the connection is lost.


RoseWheel motor control: 1st step

We got the board that controls the motors yesterday evening so we started to test if our H-bridge driver works as expected, here is an example of our tests:

It looks good for the moment so the next step is to implement a control of the violent speed changes…


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

MB Led: Working IrDA and colored LEDs.

Algorithm on GLiP block:

Today Guillaume has worked with 9 GLiP blocks, trying our algorithm in order to elect the leader among the network and give positions to each block. He succeed in this when the network is slowly increasing but when all the blocks come in a random way, it is still difficult to have a consistent network. There is still no acknowledge with the IrDA and when some packet is corrupted, the algorithm fails. We have to fix this soon.


Cédric has resolved his problem with UART4&5 for emitting packet. After some tests with Alexis, he found a good value for the resistance(4.7KOhms) to control emission power so that the blocks would communicate only to the neighbors. All potentiometers will be replaced by classical resistances.

LED matrix:

Now I can drive the LED matrix using the new driver TLC5951. I can display a 8×8 pixel on the matrix but I have to fix some problems of intensity. We knew that blue is more powerful than red and green and we try to avoid this problem. For the moment, we can’t obtain a perfect white but I’m in a good way to fix this problem.


TSV Safe Express:the day of SPI and Led Driver

We had some hardware problems with our Led Driver today, but finally (thanks Alexi) we could test our programs for SPI and initialization of our Led Driver. Now we can control lights from the Led Driver. We are mapping light commands(from the Led Driver) to corresponding CAN messages.

We have progressed on the work on the CAN bootloader. We have been able to send data from the PC to the final card passing through a dummy card which transforms UART messages to CAN messages.

We have been able to simulate the sensors card on our TP card. Now we are able to send an event (pressing the botton) to central card.



MB Led : First test with MB Led blocks

Yesterday, Alexis gave us 3 MB Led so that we could check the IrDA of the blocks. So far, Cédric achieved to communicate through UART 2 and 3 without any problem. For UART 4 and 5, he encountered problems to receive messages due to missing characters in the UART data register.

Benjamin started to check the  LED driver so that we could light the MB Leds soon.

Both of them used the oscilloscope to understand signals from the component.

Meanwhile, I fixed some bugs in the algorithm and my tests were successful on the GLiP blocks. Thoses blocks can only communicate through UART 2 & 3 so my job is now to test the algorithm on fully operating GLiP blocks (with their 4 IrDA transceivers), waiting for Cédric to test on our MB Led blocks. It seems that FreeRTOS scheduler is blocked when I tried to launch 16 tasks at once. I would try to fix this without reducing the numbers of tasks, cause each one is important…

MB Led : Avancées du début des vacances.

Actuellement, je m’occupe de fusionner mon code d’algorithmie avec le code de Cédric concernant l’IrDA. Nous avions quelques différences sur des fonctions d’envoi et de réception de données. J’ai du réécrire certaines fonctions pour que cela marche. Désormais, nous testons les résultats en utilisant la sonde JTAG qui nous pose certains problèmes (hier, on a passé pas mal de temps à ressouder des fils qui s’étaient déssoudés).

L’IrDA est désormais fonctionnel avec des envois à haute vitesse. Cédric a utilisé un ordonnanceur pour gérer cela. En attendant, j’ai réfléchi à une façon de détecter qu’un bloc a tourné. Les tests avec FreeRTOS et zmq sont concluants et il faut juste l’appliquer au code avec IrDA.

Hier, Alexis avec l’aide de Benjamin a soudé un bon nombre des MBLeds. Nous espérons les avoir bientôt pour que Benjamin puisse tester son code sur le driver LED. Benjamin a aussi réfléchi à deux jeux que nous voudrions implanter : un morpion et un snake. Il attend que la fusion soit finie pour tester cela.

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