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


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

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 : accelerometer done and progress update

One of our PSSC was to have a functionnal accelerometer for last monday. Despite the fact we didn’t post that day, we did have a working implementation and we were able to compute the inclination angle using the normalized 3D acceleration vector. We did this only with interruptions and without any kind of polling. The code was actually already working at our last demo. But in the meantime we’ve made some improvements that deserve to be described here. We used to detect rising edge of the accelero’s RDY pin to update the values. The rate at which values are calculated depends on the decimation factor chosen. According to the datasheet it spans from 40 Hz to 2560 Hz (with only 4 different values) and because of the fact we need 200 values per second we chose a decimation factor of 32 that enabled us to refresh values at a rate of 400Hz (closest value). Using interruptions at rising edge of RDY pin and then requesting the values from the device using SPI bus protocol was a bit demanding for the processor at this rate. We have therefore chosen not to use the RDY pin to be able to choose more precisely our rate of update. Some changes have also been made on the number of bytes used to represent data and a global coordinate system has been defined for both accelerometer and gyroscope.


Video of our sensorboard displaying the inclination angle using a color led.

Today we also assembled the mechanics of the Zzaag project. We could even try to ride it using the board shipped with. Here is a picture of what it looks like:

Mechanics of th Zzagg project

Mechanics of th Zzagg project

We had the time to begin the drivers for our hypothetical encoders (we are not sure to be able to set them on the mechanics) and we will be able to finish them tomorrow to be able to validate another PSSC.

At this point we have several pieces of software that wait to be integrated in our boards softs. The integration of the sensorboard has been started. In the main task an infinite loop wakes up every 5ms (200Hz). We retrieve the values of the accelerometer and the gyroscope that are updated separately in independant tasks. Then we need to give these values to the kalman filter for the final angle to be computed getting rid of the noise. But the kalman filter needs to estimate the next state before correcting the given values. We then need to receive the current values of the commands applied to the motors sent on the CAN bus by the main board. Finally we broadcast the computed angle and angular velocity on the CAN bus.

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.



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] Carte STM32

Nous avons aujourd’hui poursuivi la prise en main de notre carte, en commençant par l’écran. Mauvaise surprise, il se commande en SPI 9 bits, et le STM ne fait que du 8 ou du 16 bits. D’après certains forums, il est possible de contourner le problème en utilisant un USART, mais malheureusement aucun USART du STM n’est remappable sur les pins que nous avons choisis pour contrôler l’écran. Nous avons donc dû commander l’écran en bit-banging. Nous nous sommes appuyés sur le tutoriel de James P. Lynch, très clair, pour les protocoles d’initialisation de l’écran et d’écriture. Celui-ci fournit également trois fontes de caractères dans un format facilement utilisable. Notre écran est à base de contrôleur de type Epson (l’écran peut en effet être à base de deux types différents de contrôleurs), mais la plupart des pins de configuration ne sont pas accessibles depuis la sortie de l’écran (comme celles permettant de faire du SPI 8 bits…).

Heureusement, la flash se commande quant à elle en SPI 8 bits, et l’utilisation du DMA devrait permettre de soulager un peu plus le processeur lors du chargement d’images à afficher…

Prochaine étape : communication UART pour envoyer des images à afficher, et les stocker dans la flash.


TSV Safe Express: Le débogage avec bus CAN

Hier, nous avons eu problèmes avec multiple nœuds. Alors, aujourdhui, nous essayions de stabiliser le protocol NMRA pour le bus CAN. Un problème intéressant a été les paquets du bus CAN ne sont pas dans le bon ordre. Qu’est-ce qui se passait?
Notre théorie est la suivante. Nous avons « transmit mailbox » dans le contrôleur CAN avec la capacité de 3. La fonction de transmission de la bibliothèque CAN tente de trouver « transmit mailbox  » vide et envoyer le paquet. Supposons qu’il écrit le premier paquet en deuxième mailbox , puis premier mailbox (car il a trouvé les mailboxes vide dans cet ordre). Mais la transmission de messages CAN commence de 0 mailbox. Ainsi, les paquets ne sont pas envoyés dans l’ordre correct.

Une solution possible peut être de s’assurer d’utiliser une seule mailbox pour envoyer des messages CAN. Cela peut être réaliser en commençant par transmettre CAN gestionnaire d’interruption qui se synchronise avec le CAN transmettre fonction à l’aide de sémaphores. Mais, avec ça nous ne pouvons pas prendre l’avantage de trois mailbox. D’autres solutions sont les bienvenus.

Avec, le bootloader, nous avons réussi en faire le lecture et écriture sur le flash. Maintenant, nous sommes en train de faire le l’autre choses de bootloader comme le usart.

Nous avons reçu noter carte feux. Demain, nous allons faire le SPI pour cette carte.

IRL : Une journée fructueuse

Aujourd’hui nous nous sommes principalement concentrés sur le fpga.

Ram Spi
Nous sommes désormais capable de faire communiquer le fpga avec la ram spi : nous pouvons lire et écrire des valeurs dans la ram depuis le fpga (valeurs à écrire codées en dur dans le fpga, vérification des lectures à l’oscilloscope).

Le développement de la communication processeur-ram/spi à travers le fpga est bien avancé. Il est déjà possible de consulter sur l’armadeus la dernière valeur lue sur la ram/spi par le fpga. En revanche l’écriture n’est pas encore possible. Le contrôleur qui permettra au processeur d’indiquer les opérations (lecture / écriture/ adresse) qu’il souhaite réaliser est en cours d’écriture.

Nous parvenons à afficher un point en codant ses deux coordonnées en dur dans le fpga. La prochaine étape consistera à piloter les coordonnées du point depuis le processeur.
Par ailleurs un module permet d’afficher une diagonale. Nous pourrons ainsi régler les potentiomètres des amplificateurs dès que nous aurons mis la main sur un tournevis !

Serveur Web
Nous avons peu travaillé sur ce sujet aujourd’hui. Nous avons recompilé les bibliothèques de buildroot avec les symboles de debug pour pouvoir comprendre pourquoi mongrel fait une erreur de segmentation au démarrage.

Copterix : Premiers résultats avec notre PCB !!

En utilisant le code généreusement fourni par Loïc pour la communication en UART avec le PC, nous avons pu débugger puis parler en SPI avec l’accéléromètre, et ainsi lire ses données qui se sont révélées pertinentes. Nous avons ensuite pu récupérer les données des magnétomètres, qui ont l’air cohérentes modulo un offset qu’il nous reste à régler. Il faudra aussi attendre d’avoir connecté l’axe Z du magnétomètre pour le paramétrer complètement.

Programme de demain : discuter en I2C avec les gyroscopes puis avec les moteurs

IRL : dure journée …

Nous avons eu beaucoup de doutes ces derniers temps concernant les choix à faire pour avancer. Voici ce que nous avons fait durant les deux derniers jours.

Serveur web

Comme pouvait le laisser penser notre dernier post, nous avons exploré les possibilités offertes par mongrel2.
Il s’agit d’une application qui multiplexe des requêtes http et les recopie sur des sockets 0mq (pour plus de détail : http://mongrel2.org/home).
Nous avons testé mongrel sur nos machines avec succès et il nous semble tout à fait adapté pour résoudre nos problèmes.
Nous avons essayé de le crosscompiler mais sommes confontés pour l’heure à des problèmes.
À terme, nous voulons l’intégrer dans notre buildroot.


Nous avons l’ensemble des caractères ISO8859-15 sous la forme de fichiers ILDA. Et nous avons trouvé une nouvelle police qui donne des meilleurs résultats. Nous avons fait un script qui nous donne le numéro du caractère ISO8859-15 entré sur stdin.


Nous nous sommes familiarisés avec Twitter et nous réussissons à récupérer les tweets portant le htag #rose2011 directement sur la carte.


Nous avons synthétisé et testé sur le FPGA un code utilisant une des rams internes du FPGA et permettant d’y écrire et lire depuis le processeur. Nous sommes en train de parler à la ram SPI qui nous reste (en effet, nous avons mal routé une des deux rams SPI dont nous allons peut-être devoir nous passer).


Nous avons clarifié nos idées concernant la manière dont l’authentification sera mise en oeuvre sur la carte. Nous nous repencherons sur la question quand mongrel2 marchera.