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 : 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 : Good news !

As you see, yesterday we were having fun with the laser trying to enhance the performances of our smooth text scrolling show. We now have embedded the whole program and it generates directly the ILDA file on board. We still have some speed issues, namely the program which generates the ILDA files is still pretty slow (it takes more than a minute for a tweet), but our imagination is thriving regarding optimization tricks and yet we gained a significant factor on the computing time.

We are also concerned about the beauty of the text. In fact we noticed a few effects in which we’re focusing on :

- When the laser goes more quickly, the line between 2 given points tends to look like a curve Solution : we are going to fix the derangement by adding several intermediate points between our points, this will be done in C at the end of the display chain.

- When the points are too faraway one from another, the galvanometers tend to be more noisy and we tend to be more worried about the survival of our system. Solution : we reduce the size of the text (so as to narrow the space between points) and insert intermediate points between the characters and at the end of the frame to make the shifts of position smoother.

- When the laser isn’t quick enough, we recognized that the flickering effect is more important.
Solution : we need to speed the laser up.

We did some major improvements on those different points not to mention the complexity issues. Step the text is getting more and more beautiful !

I’m sure you want to know a little more about our FPGA. We have enhanced our previous design by adding a RAM FIFO which will allow us to reduce the load of the CPU. We’re working on the CPU’s side of that program. Anyway, our security module seems to be a bit too sensible and it is triggering more often than expected.

In the next few days we will stress on the development of the DMX card.

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.

IRL : Journée PCB 1/2

Aujourd’hui nous avons travaillé sur les schémas des cartes Laser et DMX. Ils sont normalement terminés, il ne manque plus qu’à vérifier que nous n’avons pas fait d’erreurs. Nous avons commencé le placement routage que nous poursuivrons demain.

Il a été décidé que nous utiliserons non pas une mais deux blocs de RAM pour le stockage des images sur le FPGA. Laurent a commencé à développer un module Verilog pour les lectures/ecritures dans ces mémoires.

IRL : Avancées de la journée

Aujourd’hui nous avons eu l’occasion de rencontrer un étudiant qui a travaillé il y a deux ans sur le projet Laser.
Nous lui avons expliqué l’architecture de notre projet et avons récupéré une partie des sources de son projet.

Nous avons mené des essais avec les cartes de TP concernant la transmission par zigbee des masques pour le flux DMX. Ces essais ont été concluants : nous arrivons à transmettre et recevoir sans erreurs différents masques DMX et à les stocker en RAM.

Nous cherchons une police adaptée au laser et sous forme de fichiers au format ILDA pour pouvoir afficher du texte sur l’écran. Nous avons constaté que l’équipe de l’année dernière a réalisé des caractères au format ILDA qui ont un bon rendu avec notre afficheur ILDA.

Nous avons par ailleurs décidé en suivant les conseils d’Alexis d’utiliser une RAM externe pour notre FPGA (ram SPI 256Kbits code radiospare : 666-8148).

Nous sommes en train de réaliser les PCB, de faire des simulation en Verilog et de réfléchir au format de stockage des informations à afficher par le laser dans le FPGA. Nous attendons l’Armadeus dont nous disposerons peut-être demain.

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.

IRL : Avancées du weekend

Nous avons avancé dans le choix des composants avec pour objectif de fournir mercredi soir une liste quasi-definitive.

Nous utiliserons probablement :

  • Un STM32 sur la carte DMX sous FreeRTOS , avec deux tranceivers RS485/RS422 et le même module XBee que celui utilisé en TP.
  • Un STM32 sur la carte Laser sous FreeRTOS, avec une connection SPI vers la carte principale et une utilisation des deux DACs en mode 12 bits  (i.e 0.7mm de précision sur un écran de 3m par 3m).
  • Une Beagleboard en tant que carte principale (moins cher qu’une Gumstix compte-tenu de la connectique nécessaire) avec comme besoin : 
    • Ethernet
    • SPI
    • UART
    • DVI pour un écran pour faire l’installation
    • GPIO pour la configuration de l’IP (boutons) et le contrôle de l’extinction du laser
    • Petit écran LCD pour la configuration de l’IP
    • Carte SD

IRL, la réflexion DMX avance

En cherchant sur Internet ce que d’autres avaient déjà pu faire en ce qui concerne la gestion de DMX, nous sommes tombés sur une page présentant un petit montage de génération de trames DMX, basé sur un Arduino et utilisant un tranceiver RS485/RS422. Le code était disponible en ligne et nous avons pu voir qu’il utilise des GPIO du processeur pour générer bit à bit les sorties. D’après Sam, il y a moyen de configurer les UARTS du STM32 pour qu’elles soient directement utilisables avec le protocole DMX, on se plongera demain dans la datasheet pour confirmer. Il nous a aussi indiqué qu’on pourrait utiliser le DMA pour l’écriture des trames.

Ensuite Sam nous a aussi renseigné sur le genre de services que FreeRTOS peut nous rendre : les tâches prioritaires (ici la récupération des trames DMX, il ne faut pas en rater) sont toujours exécutées « à l’heure » (à quelques ns près), les taches moins prioritaires (comme la récupération d’un nouveau masque via le zigbee) sont exécutées « quand il y a le temps », tout ce qui compte est de savoir qu’en moyenne on a le temps de tout faire. Le même principe nous sera utile pour la génération très précise des signaux de commande du laser. Le cours de lundi matin nous en dira plus sur ce sujet, ce sera très utile !

Enfin, nous avons une idée qui nous semble robuste concernant la boucle de sûreté du laser. Afin de résister à un crash de la carte principale (Linux) OU du STM32 qui contrôle le laser (FreeRTOS), nous avons pensé à l’architecture suivante :

  • Sur le STM32 : une routine de priorité maximale (plus que l’OS) qui vérifie à intervalles réguliers que le laser a bougé, s’il n’a pas bougé pendant une certaine durée (à déterminer ou plutôt trouver dans les normes), le laser est coupé
  • De plus, le STM32 doit signaler périodiquement à la carte principale qu’il se porte bien. S’il s’arrête de le signaler, la carte principale en déduit qu’il a crashé, et coupe le laser.

 

IRL : carte DMX

L’architecture du module DMX se précise…

La future carte DMX devra :
-recevoir les trames DMX
-les patcher avec un masque de 512 octets reçu par zigbee
-les renvoyer
-contenir tout ce qu’il faut pour être programmable…
Je me suis renseignée sur la norme EIA-485 (= RS-485) qui constitue la couche physique du protocole DMX512.
RS-485 utilise trois fils : GND, +, – .
GND sert à protéger la liaison des perturbations electromagnétiques. La liasion est différentielle,si (V+)-(V-) > 200mV on a un 1, si (V+)-(V-)<-200mV, on a un 0. Je me demande si une différence de potentiel inférieure à 200mV est interdite ou si elle constitue l’état IDLE…
Notons que Le RS-485 est half-duplex, mais que le protocole DMX ne l’utilise que dans un seul sens, les éclairages ne renvoient pas d’informations vers la console de commande.

 

Interface µP/DMX512

Notre carte DMX doit comporter deux liaisons RS-485, une pour la réception, une pour la transmission. Il me semble que l’on ne trouve pas facilement des cartes avec du RS-485 déjà fait. Je propose que l’on ne cherche pas et que l’on utilise une GPIO par liaision.

Les interfaces DMX/GPIO comporteraient côté réception:

  • Un connecteur XLR3 ou 5 mâle (à vérifier)
  • Un comparateur (impédance d’entrée supérieure à 12kOhms, qui supporte en entrée du -7 à +12 V et qui a une sensibilité qui permet de détecter une différence supérieure à 200mV)
  • Une résistance de terminaison de 120 Ohms

côté émission:

  • Un circuit pour générer un signal symétrique -U +U avec 1,5V<U<7V
  • Un connecteur XLR3 ou 5 femelle
  • Optionnellement : une résistance de terminaison de 120 Ohms. Elle n’est pas obligatoire sur une liaision RS-485 qui ne comporte qu’un seul émetteur. Sa présence augmente la consommation électrique du câble mais améliore l’intégrité du signal.

La norme DMX512 prévoit des connecteurs XLR 5 broches. Deux des broches ne servent à rien et sont réservées pour des évolutions ultérieures de la norme (retour des appareils). Pour cette raison beaucoup de constructeurs utilisent des connecteurs 3 broches. Il serait plus pratique d’avoir les même connecteurs que TSM. Cependant, le choix n’aura pas de conséquences graves, les adaptateurs XLR3/XLR5 se trouvent facilement.

Zigbee

Pour des raisons de facilité, il est probable que l’on utilise les mêmes modules que telecom robotics et qu’en TP. Ce module nécessite une UART pour la communication avec le µP .

Environnement de développement

Il serait pratique d’avoir une JTAG et une UART supplémentaire.

Récapitulation des connectiques pour le choix du microprocesseur :

  • 2 UARTs,
  • 2 GPIOs,
  • JTAG,
  • ….?

Cela devrait être trouvable…

Puissance de calcul
Il faut :

  • lire une GPIO à 250kHz
  • écrire une GPIO à 250kHz précisément (d’ailleurs il pourrait être intéressant de savoir à quel point il faut être précis…)
  • récupérer, vraiment pas souvent, 512 octets sur le zigbee
  • multi-tâche → il nous faut freeRTOS

Taille mémoire

Difficile à évaluer pour moi, par manque d’expérience. Il faudrait se faire une idée des tailles en RAM/ROM demandées par freeRTOS et zigbee. Notre programme ne va probablement pas être bien long, ni nécessiter beaucoup de RAM.