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


Copterix: a wonderful day

While Loïc and Bertrand were working on Friday’s presentation slides, Samuel and myself spent the whole day testing our copter’s PID.

We finally found two majors bugs in our code (a motor offset unbalancing the system and a Integral term too often cleared). After that we were able for the first time to get a real flight while only acting on the thrust using remote control. We now have to add yaw PID and altitude PID and we may have something really nice to show on Friday.

IRL is reaching its final rush to the last presentation.

ILDA and Web app
Since the last post we did a lot of tests in real situation, namely with several programs running on the board. We deemed that the operation to translate a text to an ILDA animation tends to be far too slow that’s why we decided to rely on a web app based on the google appengine api for Python. Yesterday, we turned words into action and started to create the web app and a proxy in the card to query the webapp or in case of a failure, redirect request to the embedded slow instance of the program. We did deploy the web app on appspot.com and our first tests tend to confirm that the service is accelerated by a factor of 30 to 60 depending on the load of the board. We did realize a website to present our restfull API to that webapp and we will put it online as soon as possible.

As far as website are concerned, we want to introduce our brand new website. Feel free to comment or share any kind of feedback.

We hunted some bugs in our code and yet it works better and we don’t intend to make any kind of fix on it till the presentation.

DMX and additional board
We have contacted TSM and we will be able to try our code with real equipments.
We can communicate with our additional board via Zigbee. We have now to connect this feature with the other parts of the project with 0MQ.

Software FIFO
Our software fifo works, we are putting all the pieces together to make our « driver/conductor/leader » module which will manage all the features of the project.
Today we’ll stick the pieces, it’s a milestone !

IRL : Settings !

In our last article we described some ways to enhance the display of a text scrolling smoothly.
We actually tried several possibilities of settings for the scrolling text and finally found a convenient one (as shown on the video above).

We did some major improvements concerning the speed of the code on the card succeeding in speeding it by a factor of 5. We deemed that a major issue of that program lays on the access time of the memory. Indeed it takes more than 20 seconds to write an ILDA file of a tweet from the ram to the flash. Samuel suggested that we could use a socket to directly send the ILDA file from the python script to the C program in charge of the FPGA communication. In fact, with such a strategy we would avoid the slow speed flash access and be able to send a tweet to the laser around 30 seconds after its validation.

In addition we’re going to add some bit stuffing to make the frames equally populated in terms of points so as to assure a constant frame rate. You can easily notice that disturbing effect on the video above.

In parallel, we’re getting familiar with the DMX protocol and are working on the DMX board.
We haven’t forgotten the software fifo between the C program and the FPGA. We deemed that a zeromq socket would be a interesting solution and we are currently working on it.

TSV Safe Express: Sensors Card Development and Ethernet

Today, we received our 7 sensors card (which will track the position of the train and feed it to the central station), thanks to alexis who worked until very late in the night for soldering all the cards. So we wrote the code for the Sensor card which has a « producer » module who generates events on the CAN bus to indicate a sensor activity.

Also, Siwar is trying to do the communication protocol between ethernet and the server (setup by Samuel which controls the rail layout).

On the stabilisation of CAN, we are now filtering out events in CAN RX Queue 1(STM32 micro controller has 2 FIFIOs) and have left messages for network management on queue 0. This is done to avoid over-utilisation of queues due to either type of messages. Here is brief video of our project.

IRL: the riddle with a mere oscilloscope!

Yesterday we achieved a new goal : we successfully played an ILDA animation on a mere oscilloscope. We attach a video as an evidence of our performance.

Let’s focus on what we actually did.
We built a program which plays directly an ILDA animation in the ILDA file format. We can set several options directly on the command line such as the time spent per frame and the scaling factor.

We enhanced our code which built an ILDA file from a string or a file. It operates directly on board and is now using an ILDA file per character instead of a SVG file with the whole charset.
We display directly on the board a list of tweets taken from a database and fetched them on the go with the twitter API that we now use in C instead of Python.

The IRL project would be nothing without those huge changes that drew our path since the beginning of the project. And we are proud to announce that we are changing (again) our architecture, and we would like to thank our teachers for their precise suggestions on that topic. In a word we are going to rely on a wishbone bus so as to assure the communication through the entities of the FPGA. In that way, out system will be cleaner plus it will enhance its capabilities.

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.

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.

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.

TSV Safe Express: à partir de carte TP à la carte réelle

Pendant le week-end, nous avons essayé de stabiliser le protocol de NMRAnet (CAN bus) avec trois cartes. Nous avons réussi avec 3 cartes mail il y avait beaucoup de problèmes quand on utilise plus que un carte pour le nœud. Les plus importants sont:-
Pour rappel, nous avons 3 cartes – Un carte central station, 2 qui sont nœuds.
1. Premier nœud se timed out lorsque le deuxième nœud entre dans le réseau –
Raison- Il y avait trop des paquets à partir de le nouvelle carte parce que Il se fait programmé. Alors, le « network manager » supprime le premier nœud s’il ne reçoit pas le paquet état ​​dans un délai prédéterminé.
Solution- Utilise le CAN Filter qui lui permet de recevoir que les paquets qui le concernent. ça va dire , une fois le filtre statique est installé, les nœuds ne recevraient pas de paquets qui sont envoyés par d’autres nœuds soit le gestionnaire du réseau (« Network Manager »)ou de l’outil de configuration(« Configuration Tool »).
Futur Développement possible – Actuellement, pour les évènements de carte feux(« Consumer ») il n’y a pas de filtres qui signifie que chaque noeud reçoit les événements qui sont générés par d’autres. Pour cela, nous avons besoin d’installer des filtres CAN dynamiquement en fonction du nombre d’événements qui lui sont donnés par le gestionnaire du réseau. Nous le ferons en fonction de comment ça se passe avec les 12 attendus plus de cartes.

2. Redémarre de le nœud ne marche pas –
Raison – Si le redémarrage est très rapide, le nœud n’a pas reprogrammé par l’outil de configuration. C’est parce que le gestionnaire de réseau n’a pas assez de temps pour lui de supprimer de sa table nœud.
Solution – Après le redémarrage, le nœud inactif pendant 3 secondes qui donne la gare centrale de suffisamment de temps pour lui supprimer.
Futur Développement possible – Au lieu de dormir aveugle de 3 secondes, l’introduction de l’Etat en fonction le contrôle opérationnel au niveau du « Network Manager ».

3. Redémarre de le station central –
Raison – Depuis le nœud est déjà programmée, ainsi qu’il ne devient pas programmé encore par l’outil de configuration.
Solution – Au démarrer de la gare centrale, il envoie une commande broadcaste à tous les nœuds de se réinitialiser.
ça marche mais avec deux carte, ça ne marche plus. Juste une carte, qui devient programmé. Nous sommes en train de trouver la raison.

Pour le Carte Feux (pas de TP) – Nous avons réussi avec CAN et nous pouvons contrôle cette carte à partir de station central. Maintenant, Theodoros, il est en train de travailler sur le SPI. Siwar continue de travailler à CAN bootloader. Vaibhav travaille sur le code existant.

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