ELECINF344/381

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

Catégories

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.

IRL : firsts tests with the real laser

Real laser

Today we replaced the oscilloscope by the real laser. As expected, it does not exactly work the same way, but our first test with « The Riddle » is not so bad. You can see it on the video below, it is little as we do not have a lot of space in the classroom. You can see that the image is blinking, this is partly due to our code, but also partly due to the camera sync, and the « real » result is cleaner than what can be seen here.

FPGA design

The new design suggested by our teachers has been implemented, except for the FIFO which for the moment does not use the internal RAMs This will normally be done tomorrow. The FIFO, as it is now sometimes, leads to some bugs that we do not really understand yet. We will also investigate those issues tomorrow. Nevertheless, we have a functional design, the one we used tonight to make the video.

Tweet to ILDA

Concerning the way we will display tweets, Sam suggested us to make a smooth horizontal scrolling. Our first idea was to generate a big ILDA image containing the whole tweet on one line, and to clip it at display time, just before sending it to the laser. It seems that is was not the best way to act. So, we are now trying to generate an ILDA animation corresponding to the scrolling with a Python script. We are on our way and we have yet disclosed a few points of intersert to change in our design to make it work soon.

Web interface

The library we mentionned last time (libmicrohttpd) seems to fit quite well with our needs. It is not a complete Web server, but it is enough to make the card serve a static HTML page and a little REST API to get tweets and validate them. The authentication is for the moment very basic it consists in a « secret » token as segment of the URI. It is not very secure, but it is not our priority at the very moment.

Copterix : finalisation du filtre de Kalman

Alors, comme nous l’avons dit hier, cette journée a été dédiée aux tests du FQA et du filtre de Kalman sur une IMU. On récupère les données brutes des capteurs (3 gyroscopes, 3 accéléromètres et 3 magnétomètres) par un script python. Le Kalman qui sera implémenté sur la Gumstix est en C++. Il a donc fallu dans un premier temps faire communiquer le script python et le programme C++ afin d’acheminer les données des capteurs vers notre Kalman. Nous avons pour cela utilisé ZeroMQ avec une architecture Publisher/Subscriber.

Une fois la communication fonctionnelle, nous avons pu commencer à tester notre FQA et notre Kalman. Au début, nous avions pas mal de problèmes au niveau de l’orientation de nos axes. Mais après avoir passé pas mal de temps à étudier les sorties des capteurs pour comprendre selon quels axes ils étaient positionnés, nous avons obtenu des résultats plutôt satisfaisants :

Dans la première vidéo , nous n’utilisons pas le filtre de Kalman (juste le FQA) alors que dans la seconde, le filtre de Kalman est activé. L’utilisation du filtre permet d’éliminer pas mal de bruit. Il reste tout de même quelques petits détails à régler car il y a quelques indéterminations qui chamboulent un petit peu le filtre.

Nous avons en outre reçu notre PCB :

La journée de demain sera consacrée à établir la communication avec notre nouvelle carte !

IRL : avancées de la journée

Ajourd’hui nous avons travaillé en parallèle sur deux thèmes : le FPGA, et l’interface web.

Côté FPGA, nous avons pu simuler une RAM lisible et inscriptible depuis le processeur, ce qui est encore peu mais nous permet de penser qu’on a compris comment le lien fonctionne. Nous avons ensuite une une réflexion sur l’architecture fonctionnelle des modules du FPGA.
La mémoire du FPGA doit pouvoir servir de tampon, étant donné que Linux (peu précis au niveau du timing) enverra des paquets de données par à-coups, alors que la sortie vers le laser devra être cadencée bien régulièrement. Nous utiliserons les blocs de RAM internes du FPGA comme buffers avant et après la RAM (cf schéma), et les RAMs SPI de manière à ce que l’ensemble soit vu comme une FIFO par l’extérieur.
Le module de sécurité surveille les sorties du bloc de contrôle des DACs pour s’assurer que le laser ne reste pas allumé dans une trop petite zone durant un temps trop long. La taille de la zone (du moins sa traductions en déplacements « absolus » au niveau des coordonnées numériques) devra être fonction de la distance minimale à laquelle un observateur peut potentiellement se trouver. La durée maimale d’exposition sera à déterminer à partir de la puissance du Laser et des recommandations médicales. Cet ajustement n’est clairement pas la priorité actuelle.

 

 

 

Du côté du serveur Web, ça a été plus chaotique. Nous étions partis depuis deux jours sur l’utilisation de WebPy. Cependant son intégration avec SQLite impose l’utilisation de modules Python tierce partie, et la cross-compilation de ces modules nous pose beaucoup de problèmes. Dernièrement nous avons tenter de passer à la daily-build de la µClibC pour résoudre un problème avec l’importation de pysqlite3, ce qui a eu pour résultat de casser notre rootfs (kernel panic au démarrage à cause de dl_iterate_phdr()). Une simple recompilation en rechangeant de version de µClibC semble ne pas suffire (pour une raison inconnue), nous tenterons une recompilation depuis zéro demain.
Ces problèmes nous ont pris assez de temps et nous allons probablement chercher sur d’autres pistes, peut-être du côté de Mongrel2 comme Sam nous l’a conseillé.

MB Led: Dialogues en zMQ

Ces derniers temps, j’ai principalement implémenté notre algorithme en C, tournant sous FreeRTOS sur un PC classique.

En effet,  j’ai préféré utiliser directement les possibilitées de FreeRTOS (tâches, sémaphores, etc.) plutôt que de coder en C classique puis de modifier tout cela lorsque j’aurai voulu mettre cela sur un module MBLed (ou GLiP).Cependant, j’ai eu beaucoup de difficultés à paramétrer FreeRTOS pour que cela marche sur un ordinateur. J’ai dû me plonger dans la documentation pour finalement réussir à faire un Makefile qui marche vendredi soir.

Pour simuler les échanges entre modules, nous utilisons zéroMQ en mode PUB/SUB. Chaque module que l’on lance intéragit avec le script en python grâce à deux sockets : avec l’un, les modules publient leurs infos et le script les récupère; avec l’autre, le script python publie les informations (qu’il a modifié pour que la partie « Origine » du message soit devenue une partie « Destination ») et chaque module récupère uniquement les informations le concernant.
Pour l’implémentation de l’algorithme à proprement dit, je tente de reprendre le code en python pour le passer en C bien qu’il soit assez difficile de faire cela. J’avais beaucoup utilisé l’orienté objet dans le script et le C ne gère pas cela. Toutefois l’implémentation se fait assez vite et j’espère avoir fini cela pour jeudi ou vendredi.

IRL : Mise en marche de l’armadeus, et autres

Fin des PCB : Nos PCB pour la carte additionnelle laser et la carte DMX ont été finis et envoyés vendredi soir. Pas de message d’Alexis, bonne nouvelle…

Installation de l’armadeus : nous avons pris possession de l’Armadeus APF27-dev en fin de semaine dernière, et nous avons commencé à nous en servir. Pour l’instant nous avons :

  • Compilé un noyau sur lequel on a réussi à booter
  • Compilé un rootfs (plusieurs fois pour ajouter quelques fonctionnalités au fur et à mesure), en version UBIFS pour accélérer la vitesse de montage des partitions au démarrage (sur conseil d’Alexis)

Notre carte dispose maintenant d’un serveur SSH (pratique pour travailler à plusieurs dessus), et d’un serveur web boa (qui parfois donne des erreurs au démarrage, on cherche) grâce auquel nous avons pu accéder à une page web hébergée sur l’armadeus. Nous avons également testé un Hello Word en CGI, en bash pour commencer, puis en C++.
À ce propos, nous nous interrogeons sur le langage à utiliser pour l’interface web côté serveur. Nous hésitons entre Python plus facile et adapté (mais buildroot ne propose pas le mode CGI, peut-être est-il par défaut) et du C++ à l’aide de libcgicc (probablement plus rapide mais plus source à embêtements).

Par ailleurs, nous pensons utiliser sqlite pour associer des masques DMX, des images et animatiosn ilda à différents mots-clés que l’on pourrait extraire des tweets, ou à différentes ambiances prédéfinies. Nous ne sommes pas encore sûrs d’utiliser une base de données, c’est à étudier plus en profondeur.

Framebuffer : on nous avait soufflé l’idée d’utiliser le framebuffer de Linux pour se servir du laser comme écran, cette idée était trop complexe et mal adaptée. Sam et Alexis nous ont proposé une autre idée plus abordable (mais qui restera comme du « bonus » et ne sera pas un objectif principal) qui serait d’afficher la sortie d’une console série. Laurent a fait un petit script qui construit un fichier ILDA simplifié au fûr et à mesure des saisies d’un utilisateur. Cette idée paraît donc réalisable, on la garde pour plus tard.

Alphabet ILDA : nous avons besoin d’une bibliothèque de fichiers ILDA (ou ILDA simplifié X, Y, on/off) contenant les caractères affichables par notre laser. Comme Alexis nous l’a conseillé, nous sommes parti d’un alphabet SVG que nous parsons pour aboutir à notre format ILDA simplifié. Nos essais sur une dizaine de lettres sont concluants.

FPGA : on a pris en main l’IDE et synthétisé un exemple (blinking LED) de la doc. Nous pensons l’avoir flashé  correctement sur le FPGA, cependant l’alimentation de la LED requiert le branchement de deux pins de l’Armadeus, nous attendons l’avis de Sam ou Alexis pour être sûrs de ne rien griller. Par ailleurs, Laurent a réalisé un module en Verilog qui gère la communication avec les mémoires SPI, il reste un détail à modifier mais l’essentiel est là et le code est sythétisable.

MB Led: Algorithmie

Après une journée très épuisante lundi avec le communication challenge, nous voilà reparti sur le projet. Hier, j’ai revu l’algorithmie de base avec l’aide de Cédric et Benjamin. Aujourd’hui, j’ai parlé avec Sam sur le zéro MQ. En effet, pour l’instant, ma simulation est uniquement en Python (une classe pour le module, une pour l’envoi de message, une pour la réception). Sam me dit qu’il serait préférable — quand l’algorithmie sera au point — de programmer les modules en C directement et d’utiliser zéro MQ pour simuler un scénario et envoyer les messages entre modules.

 

Le schéma algorithmique est le suivant :
PING -> ELECTION DE LEADER -> ORIENTATION -> POSITIONNEMENT.

  • PING

Les modules ping tout le temps leur 4 interfaces (disant « HELLO MY_ID »). Au bout d’un certain nombre de messages reçus sur une interface, il considère qu’il a un voisin.

  • ELECTION DE LEADER

A la fin de la phase d’identification, il y a « élection de leader » pour savoir qui décidera de l’orientation. Pour l’élection, on choisit le module Bluetooth en premier et sinon, c’est celui avec l’ID le plus grand.

Si un module arrive sur un réseau déjà orienté, il n’y a pas d’élection de leader, il « subit » la loi du nombre.

  • ORIENTATION

Le « leader » oriente les autres modules selon son orientation.

  • POSITIONNEMENT

Le but est de savoir à chaque instant qui est dans le réseau (et où exactement).

Nous avons opté pour la création d’un tableau de voisin stocké en RAM. Au centre de ce tableau est inscrit le numéro du module.Ensuite, les voisins « directs » (accessibles par IrDA) sont stockés selon l’UART avec laquelle ils communiquent.

Ex : Le module est en rouge ici, le voisin qui communique avec l’UART 1 est stocké en 1, etc.


Quand un module arrive sur un réseau, il n’est pas considéré comme faisant parti du réseau tant qu’il n’est pas orienté correctement. Quand il le devient, il envoie un message à ses voisins disant « coucou je fais parti du réseau », ce à quoi on lui répond « OK. Voici tous les modules connectés au réseau (avec leurs coordonnées) »

Quand l’algorithme de positionnement sera fini (d’ici peu j’espère), je passerai à la programmation en C des modules et je tenterai un affichage graphique de la simulation.

 

MB Led: Article post communication challenge.

Aujourd’hui j’ai enfin réussi à flasher quatre modules conçus par l’équipe GLiP de l’an dernier. J’ai flashé le code maitre pour un bloc contrôlable avec un PC et minicom pour la sélection des animations ainsi que le code pour trois esclaves.

Lors de la compilation de ces codes sont incluses les différentes animations préalablement convertis grâce au script python gif2glip (conçu par l’équipe GLiP).

Nous avons donc pu faire tourner des petites animations sur un réseau carré de quatre GLiP tout en constatant que les animations étaient bien affichées après mélange des blocs.

Cette étape m’a permis de me familiariser avec l’architecture du code de GliP et de m’imprégner de leurs algorithmes pour la réorganisation du réseau ainsi que pour l’affichage des images via les drivers de LED. La compréhension de ce code nous permettra de faire des premiers tests notamment pour les communications IRDA et nos algorithmes réparties en attendant d’avoir nos propres modules.

Ce soir je me suis consacré à la réorganisation de nos PSSC et à la création d’un diagramme de Gant pour une meilleur répartition des ressources dans notre équipe. Le temps passé sur le TP sur le STM32 nous a obligés de décaler les différentes deadlines pour nos PSSC.

====== Reprise du projet GLiP : ======
- A partir de GIF convertibles par gif2glip nous savons les charger via le bloc maître et les jouer sur un réseau de bloc en utilisant leur matériel ⇒ Fait

====== Conception de la carte et test : ======
- Choix des composants terminé : Fait

- Image PCB prête (on peut passer la commande du circuit imprimé) ⇒ 25 mars

Puis en supposant que nous recevons les PCB au plus tard le 4 avril :

- Soudage des composants sur les cartes => 6 avril

- Contrôle de la matrice de LED (affichage d’image) ⇒ 15 avril

====== IRDA ======
- Echange de messages entre deux blocs ⇒ 11 avril

- Ecriture via Irda sur la sdcard => 22 avril

====== Bluetooth: ======
- Communication Bluetooth avec un ordinateur ⇒ 16 avril
- Exécution de commandes reçu en Bluetooth ⇒ 21 avril
- Application de contrôle Android ⇒ 26 avril

====== Gestion de la mémoire : ======
- Lecture sur la SD Card. ⇒ 12 avril
- Ecriture sur la SD Card. ⇒ 17 avril
- Exécution d’un programme stocké en SD Card. ⇒ 22 avril
- Mise à jour du firmware depuis la SD Card. ⇒ 24 avril

====== Système réparti : ======
- Environnement de simulation en place ⇒ 3 avril
- Gestion dynamique du réseau de bloc⇒ 15 avril

====== Jeux sur l’ensemble : ======
- Jeu du morpion fonctionnel (sans Bluetooth) ⇒ 24 avril
- Jeu du morpion fonctionnel (avec Bluetooth) ⇒ 27 avril

 

IRL avance sur deux fronts, ILDA et DMX

DMX

Notre équipe a rencontré hier et ce soir l’équipe de TSM qui rappelons le est en charge des soirées à Télécom ParisTech.
Nous avons discutés longuement de notre projet avec TSM, en particulier Hervé qui a pris beaucoup sur son temps et que nous remercions grandement pour son aide. Il nous a expliqué en pratique le fonctionnement des éclairages de soirée pilotés par DMX.
Nous avons pu à notre tour manier un contrôleur DMX et faire fonctionner deux lampes de manières indépendantes.
Nous avons éclaircis tous les points d’ombres que nous avions sur la mise en pratique du protocole et sommes assurés de pouvoir bénéficier d’éclairages et d’un contrôleur au moment opportun pour pouvoir tester notre système dans les prochaines semaines.

ILDA

Laurent a exploré les possibilités de prototypage du système laser en python.
Il a réalisé un petit programme de test basé sur :
- le code de Micah Dowty pour traiter les fichiers ILDA (http://svn.navi.cx/misc/trunk/laserprop/client/ILDA.py)
que nous décortiquerons pour créer un programme beaucoup plus léger et adapté à notre problématique.
- le module turtle de python pour simuler les déplacements du laser.

Au final, à partir d’une image ILDA on obtient dans une fenêtre la liste des points sous la forme des voltages à envoyer en sortie des DAC (entre 0 et 10V donc) et dans une autre fenêtre une représentation de ce qui sera affiché par le laser.
Il reste encore des pistes à exploiter pour ce prototype comme l’étude des effets des changements de résolution des DAC.


Perspectives

Nous comptons par ailleurs commencer le PCB à la fin de la semaine et éventuellement faire une simulation de la carte laser en Verilog.

MB Led : architecture fonctionnelle

Durant cette semaine, nous nous sommes surtout focalisés sur le TP STM32. Cependant, nous avons revu notre choix des composants pour MB Led.
Nous avons trouvé – merci Alexis – le TCL59116 de chez Texas Instrument. C’est un driver de LED où le contraste de chaque LED est programmable en soft. Ainsi, il serait possible d’avoir la même intensité pour toutes les LEDs. Etant donné qu’il contrôle seulement 16 LEDs, nous en prendrons deux. Le STM32 communiquera avec les TCL59116 par bus I²C, ce qui ne changerait pas notre brochage.
Pour le reste des composants, nous ne changeons pas notre choix initial (cf https://spreadsheets.google.com/ccc?key=0AncMdD-cz6M-dE5adzNDWkNnel9qNzd3LU1faUpuNEE&authkey=CNSan78L&hl=en#gid=0 )

Durant ce week end, j’ai aussi continué de programmer le test bench en Python. L’apprentissage du python se fait difficilement mais j’arrive à communiquer entre deux threads, c’est déjà un bon début.

Voici notre architecture fonctionnelle : les 16 blocs ont la même face recto et pour le verso, un des bloc intègre un module Bluetooth tandis que les autres ne l’ont pas.