ELECINF344/381

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

Catégories

IRL: Tweets on the laser and DMX

This morning our armadeus board seemed not to want to work properly. We must repare it or use another one.

DMX

We did our first real tests with the DMX yesterday. We are now able to control a light with our DMX board. The information sent to the light can be modified by ZigBee. The ZigBee signal will be generated by a daemon on the armadeus which will listen to requests sent through 0MQ. These features are written but we need to get our armadeus back before performing full tests.
Next step is to use data from the database to select which parameters must be send to the light depending on the tweet we want to display.

Displaying tweets on the laser

Yesterday, we finally displayed a tweet retreived in the database on the laser, with a smooth scroll.
The main daemon, in C, starts by querying the oldest validated tweet in the database, then sends the string to a program that converts it to ILDA frames representing the animation of the scrolling text. As this processing is a bit too heavy to be efficiently done on the board, we decided to offload it on Google AppEngine, which offers great performances ! Whenever we do not have access to AppEngine, the processing is done on the board, but it is really slower. A cache mecanism is being implemented. If you want to use this service, you can find a documentation at irlrose2011.appspot.com. For the moment, it is protected by a password because we need to keep the bandwith and CPU time for our own tests.
Then, the result (a series of ilda points) is sent back to the main daemon through a socket, that tranforms these ILDA points in points that will be displayed on the laser, and passes it through a 0MQ socket to the process handling the laser queue.

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.

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

FPGA
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 !

Copterix: First flight

Today, I finalized the emission of the commands for the motors, from the Gumstix to the STM32 and their reception (check the validity of the packet and if it’s valid, update the commands sent to the motors).

Then, with Samuel, we added 0MQ exchanges on the Gumstix between Kalman and the PID and between the PID and the UART.

On the Gumstix, the program that handles the UART has two threads. One receives data from the sensors from the STM32 and sends it -thanks to 0MQ- to the program computing Kalman. The other one, receives the commands of the motors from the PID and sends them to the STM32.

 

Copterix IHM

Copterix's IHM

We also attached the PCBs on the copter:

PCB's on copter

We configured Kalman with the new axes and the offset of roll and pitch angles.

 

Finally, we all tested the PID. The algorithm seems okay, however, we’ll have to set each coefficient properly.

We’re trying  to control roll and pitch angles with a low thrust (in order to prevent any accident). Then, we’ll add a control on Z thanks to the Sharp sensor.

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.

ILDA

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.

Twitter

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

FPGA

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

Authentification

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.

Copterix : communications

Depuis mercredi, je me suis occupé d’implémenter la communication via UART entre STM32 et Linux.

Comme nous ne disposions ni de la gumstix parfaitement fonctionnelle, ni du STM32, j’ai commencé à communiquer entre ma carte de TP et mon ordinateur, via un cable micromatch 4 / USB.

J’ai commencé par réaliser la partie du code du STM32, sous FreeRTOS. Je me suis alors rendu compte que contrairement à ce que je pensais, le protocole XModem n’était pas vraiment adapté à ce que je voulais, mais qu’il y avait dans celui-ci de bonnes idées, il a donc constitué un très bon départ pour un protocole maison. Voici le protocole que j’ai finalement adopté :

Les données à envoyer sont regroupées au sein de structures C (une pour l’ensemble des données des capteurs, une pour l’ensemble des commandes des moteurs). On envoie les données structures par structures, de cette manière :
On commence par envoyer un octet qui caractérise le paquet (dans notre cas, j’ai choisi 0×03 si c’est les données du capteur, 0×01 pour les commandes moteur, 0×02 pour les commandes RF). Ensuite on envoie la structure, octet par octet, sachant que l’émetteur et le receveur connaissent la structure, donc sa taille, et donc le nombre d’octet attendu. Enfin, on envoie un checksum, constitué de la somme de tous les octets modulo 256. Le récepteur va ensuite vérifier le paquet reçu avec le checksum, et l’utiliser s’il est correct, l’ignorer sinon : il n’y a pas de renvoi des paquets erroné, car cela me semble inutile, vu l’aspect temps réel des paquets échangés.

Du coup, on peut se passer d’acquittement, ce qui nous permet de fonctionner en full duplex : on devrait pouvoir envoyer les données des capteurs et recevoir les données des moteurs en même temps.

Hier donc, j’ai codé la partie STM32 (sauf les commandes RF, il faudra que je les rajoute après), puis j’ai vérifié, en dialoguant avec le PC via des scripts Python, que cette partie fonctionnait correctement.

Aujourd’hui, je me suis occupé de la partie côté Linux, en C : j’ai implémenté le protocole de réception, pour stocker les données reçues dans la structure correspondante. Ensuite, j’ai mis en place une communication 0MQ basée sur le système de Publisher/Suscriber : le module de réception publie ainsi chaque update. J’ai également créé un programme qui souscrit à ces updates, et les affiches : ses fonctions pourront être intégrées au filtre de Kalman, pour qu’il puisse souscrire aux updates.

Il me reste donc à implémenter le module d’émission côté Linux, à ajouter les paquets provenant du module RF, et je pense qu’ensuite j’aurais intérêt à faire quelques simulations pour estimer le taux d’erreurs, ainsi que le taux d’erreurs non détectées.

 

MB Led: Journée de présentation

Dernièrement, nous avons passé beaucoup de temps à adapter la structure de notre projet en fonction de nos possibilités et idées. La préparation de la présentation de demain matin nous a donc pris pas mal de temps.
Nous avons ainsi revu l’organisation logicielle des blocs que nous posterons après validation des enseignants. Nous avons également pensé à un système d’interaction avec les blocs permettant de les utiliser comme une manette de jeu vidéo. Benjamin continue la lecture de la Datasheet du driver de LED et continue à l’implémenter. Guillaume a continué de débugger la simulation de l’algorithme que nous avons choisi. A partir de différents scénarios (arrivée progressive des modules, deux réseaux qui se rencontrent, etc.), nous avons testé le modèle d’élection de leader, d’orientation et il semblerait marcher. Le plus dur étant le retrait d’un ou de plusieurs modules, ce qui oblige à recommencer le processus d’élection de leader, … .  A présent, Guillaume va commencer à l’implémenter en C via 0MQ. Pour ma part j’ai défini la structure du module de gestion de l’IrDA afin de l’adapter à l’envoi de données de tailles importantes.

Copterix : FQA, PCB et Communication avec le STM32

Pour résumer les événements de la journée :

PCB

Bertrand a fini le PCB aujourd’hui.

FQA

Avec Samuel on a implémenté une première version de l’algorithme FQA (résolution du problème de Wahba) en C++, afin de récupérer les informations données par le magnétomètre et les accéléromètres pour en faire un quaternion exploitable. Le sujet étant assez prise de tête, de nombreux débugs restent à faire…

Communication avec le STM32

Loïc s’est penché sur la communication avec le STM32 :
D’abord pour trouver un protocole pour dialoguer entre la gumstix et le STM32, via le port série. La question était posée par François Xavier dans un commentaire du précédent post : est-ce qu’on utilise un protocole particulier? Il a pensé au protocole CoAP, pour rendre notre code interropérable, au cas où on voudrait isoler notre carte de capteur pour l’insérer dans un autre projet, et réutiliser le code. Il y a aussi la possibilité d’utiliser un protocole « maison », pour envoyer les données comme on le souhaiterait.
Il pense que 0MQ ne serait pas adapté pour une telle communication, il lui semble qu’il faut un système Unix ou Windows pour l’utiliser. Et même, il faudrait implémenter une pile IP sous FreeRTOS, pour pouvoir l’utiliser, ce qui lui semble beaucoup pour peu de chose.
Ensuite, il s’est renseigné sur la manière d’écrire en Flash via l’UART vu qu’on ne devait pas disposer de port JTAG… Mais finalement on va tout de même placer un JTAG sur notre carte.

Architecture logicielle de Copterix

Aujourd’hui, après m’être renseigné sur 0MQ, pour le dialogue entre les différents modules de notre futur Copter, j’ai essayé de fixer l’architecture logicielle qu’on pourrait utiliser, à travers un schéma. Le voici, suivi de quelques explications :

 

Le STM32, qui fonctionnerait sous FreeRTOS, est directement relié aux capteurs et actionneurs de la carte. Ceci est nécessaire, notamment pour l’acquisition des données fournies par les capteurs : le filtre de Kalman nécessite que les données de tous les capteurs soient acquises presque en même temps. Il nous faut donc du vrai temps-réel, d’où l’intérêt du STM32 sous FreeRTOS.

 

Tournant sur la Gumstix :

Un module serait dédié aux communications avec le STM32 via l’UART. Ce module ferait des updates régulières des données des capteurs pour le filtre de Kalman, via les bibliothèques 0MQ.

Le filtre de Kalman fait l’objet d’un module à part, qui se chargerait d’envoyer régulièrement des updates au module de contrôle, pour lui indiquer l’attitude de l’objet.

D’autre part, la caméra fournit un flux vidéo (via l’API Video4Linux), qui sert comme source pour le filtre de Kanade, afin d’estimer la vitesse en translation de l’hélicoptère, fournie ensuite au module de contrôle. On aurait pu envisager d’inclure cette vitesse au filtre de Kalman, mais ce renseignement n’étant pas obtenu au même moment que les données des autres capteurs, il nous semble nécessaire de traiter séparément l’asservissement en attitude et l’asservissement en translation, quitte à utiliser un autre filtre de Kalman pour la vitesse.

Au niveau du streaming vidéo via wifi, je pense qu’on aurait pu se servir de GStreamer afin d’envoyer un flux compressé via Wifi, mais nous avons laissé cette possibilité de côté pour le moment : l’utilisation de la caméra et du filtre de Kanade semblent déjà trop gourmands en ressources pour qu’on puisse se permettre cette fantaisie. Pour le moment, Axel s’occupe de voir s’il est possible d’améliorer les performances, trop faibles pour l’utilisation du filtre de Kanade. Nous verrons donc plus tard si nous pourrons réenvisager de faire du streaming vidéo.

D’autre part, un module de communication en Wifi serait chargé de transmettre des « ordres » reçu d’un ordinateur ou smartphone au module de contrôle.

 

En revanche, il y a un problème dans cette architecture : le module (matériel) radio-fréquence est connecté directement sur le STM32. Or, les ordres reçus via RF devraient idéalement être transmis au module de contrôle. Je vois différentes solutions à ce problème :

- Transmettre les ordres RF reçus à la Gumstix, via l’UART. Mais cela semble être un chemin assez compliqué (et inutile) pour ces ordres.
- Contrôler les actionneurs selon les ordres donnés par la Gumstix, sauf quand on reçoit des ordres RF. Mais cela me semble difficile comme solution (comment faire en sorte que l’asservissement n’annule pas aussitôt les commandes transmises via RF?)
- Déporter la partie logicielle de contrôle sur le STM32, ce qui permettrait en plus de décharger la gumstix d’une partie de sa charge. (après tout, je ne sais pas ce qui m’a poussé à considérer la partie contrôle sur la Gumstix, et pas sur le STM32)

Je pense que la meilleure solution serait plutôt la troisième, mais j’attends quand même de voir ce qu’en pensent les autres.

 

De leur côté, Samuel et Bertrand ont fini les schematics du PCB, et le routage est en cours, il devrait être bientôt fini, comme prévu.

Communications internes et externes

Maintenant que certains d’entre vous en sont à prototyper certains aspects de vos projets, voici quelques rappels et conseils sur les interfaces et la communication.

Les interfaces

Toutes les interfaces entre un projet et l’extérieur devront utiliser des protocoles usuels. Si vous le pouvez, utilisez HTTP et REST, en préférant JSON ou XML à un format ad-hoc. Si vous utilisez un STM32 avec 802.15.4, choisissez plutôt CoAP.

Les communication inter-modules

Dans la mesure du possible, pour ceux qui utiliseront des Linux embarqués (que ce soit sur Armadeus, Gumstix ou Beagleboard), ne faîtes pas un gros programme monolithique qui permet de gérer tous les aspects de vos projets. Des petits modules indépendants, communiquant entre eux à l’aide de 0MQ, seront beaucoup plus facilement testables et remplaçables par des alternatives.

Par exemple, dans le cas du projet IRL, il n’est pas souhaitable de faire un seul programme qui gère à la fois l’aspect interface avec le monde extérieur (serveur web, récupération des messages Twitter, etc.) et la communication avec le FPGA pour piloter le laser. Un programme qui ne fait que le pilotage du laser interfacé avec 0MQ pour recevoir des commandes sera plus souple et plus efficace.

De même, si un de vos programmes possède plusieurs threads, envisagez la possibilité de leur faire échanger des données non-modifiables à l’aide de 0MQ, cela facilitera la synchronisation.