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 !

[CASPER] Remote control on Casper

Today, we made some improvements in the way casper moves. Now, it will reach a specified target (direction + bending) passing by every intermediary position, preventing casper from brutal moves… Moreover, we added a way of specifying the movement’s speed.

Besides, now we can control Casper remotely. We are currently using a Zigbee module but eventually it will be controlled by a wired UART connexion with the BeagleBoard. We specified the following protocol :

Command format :

x represents a number
A command can’t exceed 10 chars

S : start
E : end
A : absolute command indicator
R : relative command indicator
X : special command indicator

Absolute command :

xxx.xx : direction xxx (0 to 360) – bending xx (0 to 90)

Example :       > SA145-90E
Casper moves to direction 145°, bending 90°

Relative command :

(+/-)xxx(+/-)xx

Exemples :      > SR+300-10E
Casper’s direction increases by 300° and bending decreases by 10°

Special commands :
0 : YES
1 : NO
2 : 180°
3 : 360°

Example : > SX0E : Casper says mechanically yes.

Tomorrow, we will add speed management to these commands.

 

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.

Communication challenge 2011

Cette année, le communication challenge repose sur la possibilité d’exécuter des commandes en tâche de fond et de stocker des commandes pour usage futur.

Communication avec le serveur

Le serveur communique en 802.15.4. Son identité est « CC » (0×43 0×43). Chaque client doit être configuré avec les initiales du participant sur deux caractères comme c’était le cas pour la mise en œuvre il y a deux semaines. Les messages envoyés en broadcast seront rejetés et pourront conduire à l’élimination de la personne fautive. Toute tentative, réussie ou non, de se faire passer pour le serveur, pour un autre client ou de perturber un autre participant sera sanctionnée.

Toutes les communications utilisent un protocole découpé en lignes, chaque ligne étant terminée par le caractère ‘\r’ (line feed). Aucune ligne, émise par le serveur ou par les cartes, ne peut contenir plus de 50 caractères (y compris le caractère de fin de ligne).

Lorsque des valeurs doivent être échangées entre le serveur et le client en hexadécimal ou en base 33, celles-ci utiliseront les chiffres de 0 à 9 puis les lettres majuscules, de ‘A’ jusqu’à, respectivement, ‘F’ ou ‘W’. Les valeurs transmises par le serveur contiendront systématiquement deux chiffres lorsqu’elles sont en hexadécimal ou un seul chiffre lorsqu’elles sont en base 33. Les valeurs transmises en hexadécimal par le client contiendront autant de chiffres que nécessaire (jusqu’à 3).

Les paquets envoyés par le serveur auront systématiquement la forme suivante :

SLOTID [CMD] EOL

où :

  1. SLOTID est un caractère en base 33. Il vaut soit ’0′, pour signifier une exécution immédiate, soit une valeur entre ’1′ et ‘W’ indiquant qu’il faut stocker les commandes dans le slot correspondant (il faut donc prévoir 32 slots) pour une exécution future (voir, plus bas, la commande ‘X’).
  2. [CMD] représente 0, 1 ou plusieurs commandes, concaténées sans séparateur intermédiaire.
  3. EOL représente le caractère de fin de ligne ‘\r’.

La réponse à la réception d’une commande doit être envoyée immédiatement (avant exécution éventuelle) sous la forme d’un paquet de deux caractères :

SLOTID EOL

Ensuite, si SLOTID vaut 0, la commande doit être exécutée (ce qui peut provoquer l’envoi de paquets supplémentaires comme indiqué dans la description individuelle des commandes.

Les exemples donnés le sont à titre d’illustration et ne sont pas contractuels (ils peuvent contenir des erreurs, même si un effort particulier a été fait pour qu’ils soient corrects). Le préfixe « > » représente une ligne envoyée par le serveur à la carte et le préfixe « < » un envoi d’une ligne de la carte vers le serveur.

Pour initier le dialogue avec le serveur, la carte doit, après avoir configuré son adresse correctement, envoyer une ligne « START », et le serveur enverra alors sa première commande. À tout moment, en cas de réponse incorrecte, le serveur peut arrêter d’envoyer des commandes à la carte, et ne recommencera que lorsqu’un nouveau « START » sera renvoyé. L’envoi de « START » par le client est permis à tout moment et redémarrera la séquence.

Commandes

Ping

La commande Ping est constituée d’un unique caractère ‘P’. L’effet de son exécution est l’envoi d’un paquet contenant le caractère ‘P’ suivi d’un caractère de fin de ligne (l’envoi de ce caractère de fin de ligne est valable pour toutes les commandes qui envoient quelque chose, son utilisation ne sera pas rappelée par la suite).

Exemple d’exécution de la commande Ping

> 0P
< 0
< P

Leds

La commande Leds est constituée du caractère ‘L’ suivi de trois valeurs hexadécimales comprises entre 00 et FF représentant, respectivement, l’éclairage des leds rouge, verte et bleue composant la led tricolore équipant la carte. Elle ne donne lieu à aucune réponse.

Exemple d’allumage de la LED tricolore à environ 50% de vert et 0% de rouge et bleu

> 0L007F00
< 0

Execute

La commande Execute est constituée du caractère ‘X’ suivi d’un numéro de slot en base 33 entre ’1′ et ‘W’. Elle ne donne lieu à aucune réponse directe, mais l’exécution des commandes stockées dans le slot correspondant peut donner lieu à l’envoi de paquets si ces commandes le prévoient.

Attention : l’exécution d’une commande dans un slot particulier peut contenir des ordres d’exécution d’autres commandes. Il est donc important que l’exécution de commandes imbriquées soit possible.

La carte ne doit pas traiter de nouvelles commandes entrantes tant que la commande en cours n’a pas terminé son exécution. Par exemple, le traitement de la commande « 0X1″ (exécuter immédiatement le contenu du slot 1) doit effectuer les commandes du slot 1 avant d’accepter une nouvelle commande entrante.

Exemple de stockage d’une commande (double ping) dans le slot 1 suivi de son exécution

> 1PP
< 1
> 0X1
< 0
< P
< P

Exemple de stockage et d’exécutions multiples

> 1X2X2
< 1
> 2PP
< 2
> 0PX1X2
< 0
< P
< P
< P
< P
< P
< P
< P

Upper LCD line

Cette commande permet d’afficher un message sur la ligne supérieure du LCD. Si le message contient 16 caractères ou moins, le message doit être simplement affiché en l’alignant à gauche. Si le message contient plus de 16 caractères, il doit défiler continuement en tâche de fond jusqu’à ce qu’un nouvel affichage sur cette ligne ait lieu lors de l’exécution d’une nouvelle commande du même type.

La commande est constituée du caractère ‘U’, de la longueur du message en hexadécimal puis des caractères individuels à afficher. L’exécution de cette commande ne renvoie rien.

Exemple d’affichage du mot « PING » sur la ligne supérieure et de la réponse à un Ping

> 0U04PINGP
< 0
< P

Lower LCD line

La commande ‘D’ est à traiter comme la commande ‘U’ à la différence qu’elle affiche le message sur la ligne inférieure de l’écran LCD.

Exemple d’affichage du message « Hello world » sur les deux lignes

> 0U05HelloD05world
< 0

Switch

La commande Switch est constituée de l’unique caractère ‘S’. Son exécution doit, dans l’ordre :

  1. attendre que les deux boutons soit relâchés ;
  2. envoyer, selon le bouton pressé, respectivement ‘L’ pour le bouton de gauche (left) ou ‘R’ pour le bouton de droite.

Exemple d’appui sur le bouton gauche puis le bouton droit

> 0U0EPresser gaucheD0Apuis droitSS
< 0
< L
< R

Analog sensor

La commande Analog est constituée de l’unique caractère ‘A’. Son exécution renvoie la valeur, en hexadécimal, du potentiomètre tel que lu sur 12 bits sur le convertisseur analogique-numérique. Cette valeur sera comprise entre 0 et FFF.

Afin de pallier les problèmes liés aux légères variations du convertisseur analogique-numérique dans les poids faibles de la valeur retournée, il est permis (et conseillé) de lisser la valeur retenue en procédant ainsi : si la valeur est éloignée de moins de 50 (décimal) de la valeur précédemment lue, cette valeur précédente peut être conservée. Par exemple, si la valeur « 7F8″ (hexadécimal) a été précédemment utilisée, elle peut être retournée tant que la valeur lue dans le convertisseur est comprise entre « 7C6″ (hexadécimal) et « 82A » (hexadécimal).

Exemple de lecture du capteur analogique positionné approximativement à mi-course

> 0A
< 0
< 7F8

Connect analog sensor to stored commands

Cette commande permet d’exécuter, en tâche de fond, la valeur lue sur le convertisseur analogique-numérique à des commandes préalablement stockée. La plage de sensibilité du capteur (entre « 0″ et « FFF ») doit être divisée en zones de taille égale et ordonnées, et la commande correspondante doit être exécutée.

La commande est constituée du caractère ‘C’ suivi d’une valeur hexadécimale indiquant le nombre de zones à utiliser, puis la liste ordonnée des slots correspondant à ces zones. Un nombre de zones égal à « 00″ désactive cette fonctionalité. La commande ne renvoie rien.

Cette commande doit alors s’exécuter en tâche de fond. Vous avez la garantie que le serveur n’enverra pas de commandes perturbant l’exécution de cette commande avant d’avoir stoppé son exécution.

Si vous avez opté pour la procédure de lissage conseillée pour l’implémentation de la commande ‘A’, vous devez également utiliser ce lissage pour l’implémentation de cette commande.

Exemples de séparation en trois zones (rouge, vert, bleu)

> RLFF0000
< R
> GL00FF00
< G
> BL0000FF
< B
> 0C03RGB
< 0

Rendu du code

Le code du challenge devra se trouver dans un répertoire appelé « challenge2011″ dans la branche « master » de votre dépôt personnel. Il ne doit y avoir qu’un seul répertoire portant ce nom, et il peut se trouver où vous le souhaitez dans l’arborescence de votre dépôt.

Rosewheel : conception des cartes

Conformément à nos objectifs, nous avons passé la journée à établir les schémas électriques de notre carte logique et capteurs.

Vu la diversité des bus de communication de nos capteurs et le nombre d’entrées/sorties nécessaires, nous sommes d’abord partis sur un processeur de type STM32 possédant 64 broches contre 48 pour celui utilisé sur la carte de TP (le processeur reste le même). Après avoir fait l’assignement des broches nous nous sommes dit qu’il serait peut être plus simple d’essayer de brocher le STM32 sur un boitier de 48 broches. Nous avons donc fait deux modifications majeures vis-à-vis de notre modèle initial :

  • Au lieu d’utiliser un port SPI pour l’accéléromètre et un port I2C pour le gyroscope, nous avons choisi de tout multiplexer sur l’I2C. D’aprés nos calculs ça devrait pouvoir tenir le débit.
  • Au lieu d’utiliser 3 UARTs, nous n’utilisons que 2 UARTs et branchons sur la même UART le module Zigbee et l’UART de debug.

Nous nous sommes aussi rendu compte que le module Bluetooth que nous avions initialement choisi était maintenant déconseillé par le constructeur pour des applications Bluetooth récentes. Nous nous sommes donc rabattu sur le même module que celui utilisé l’année dernière par l’équipe Wheely.

La majeure partie étant faite (schéma électrique), nous ferons le placement et le routage dans le courant de la semaine prochaine afin de pouvoir bénéficier de conseils sur l’intégrité du signal notamment. Cela nous a laissé le temps de commencer notre carte de puissance. Nous n’avons néanmoins pas pu terminer le schéma électrique du fait de notre manque de connaissance en électronique de puissance (une petite aide serait la bienvenue). Globalement, la commande des moteurs brushless serait réalisé par 6 transistors MOSFET commandé par 6 PWM en sortie du processeur STM32. 3 capteurs à effet hall sont aussi présents afin de permettre au STM32 de connaitre à chaque instant la position du rotor par rapport aux stators du moteur.

Pour les schémas électriques de la carte de puissance nous nous sommes basés sur ce document : Contrôle Brushless.

Nous avons assigné plus de broches que nécessaire sur les cartes logiques et de puissance pour les sharps et les sonars afin de nous laisser la liberté de choisir ensuite plus précisément la meilleure configuration possible.

Le schéma de la carte logique et capteurs est disponible ici. Toute remarque est bienvenue.

IRL : choix des composants

Après une semaine bien occupée par le TP STM32, nous nous sommes penchés sérieusement sur le choix des composants pour le laser.

DAC : il nous faut 2 DACs pour contrôler les valeurs X et Y du laser, nous avons opté pour un DAC parallèle 12 bits 2 voies (AD5342). l’interface parallèle le rendra plus pratique à piloter à l’aide d’un FPGA qu’une interface SPI, 12 bits offrent une précision d’environ 1mm sur une surface de projection de 3m x 3m, ce qui nous paraît suffisant.

Amplificateurs : Le DAC choisi offre une sortie 0 – 3,3V, or nous avons besoin de 0 – 10V pour piloter le laser (si on branche les pins négatives à la masse), il nous faut donc un amplificateur x3, ce qui se fera à l’aide d’un AO et de deux résistances, l’une double de l’autre. L’AO présent dans Mentor nous laisse perplexe (le nom fait référence à un AO double, l’empreinte en montre un simple).

FPGA de l’Armadeus : un grand nombre d’IO, ce qui rend possible l’utilisation d’un DAC parallèle. Les IO peuvent sortir du 3,3V, ce qui permettra de piloter directement l’allumage/extinction du laser sans intermédiaire. Le modèle de FPGA dont nous disposons (Xilinx Spartran XC3S200A sauf erreur) possède 288 kbits de RAM block, ce qui permet de stocker environ 6000 points ILDA standards (1 point ILDA = 16 bits X, 16 bits Y, 8 bits couleur, 8 bit on/off), à savoir un peu moins d’une demi seconde d’image au débit max de 15000 points par seconde. Un chip de RAM externe semble donc inutile, d’autant plus que la représentation interne au FPGA pourrait se passer des 8 bits de couleur).

Zigbee : l’armadeus possède deux UARTs, dont une est reliée à deux pins métalliques sur lesquels on pourra simplement brancher des fils allant jusqu’à la carte additionnelle sur lequel sera soudé un module Zigbee identique à celui de la carte de TP (et identique à celui de la carte DMX).

Voici comme les schémas bloc de nos cartes (en PNG désolé, wordpress me refuse l’upload d’un SVG) :

Schéma de la carte Armadeus, carte additionnelle laser

 

 

Schéma de la carte DMX

Présentation des études de cas

Voici les présentations des études de cas :

Dans l’ensemble, ces présentations étaient d’une grande qualité !

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.

IRL : du nouveau, encore du nouveau !

Après une n ème réflexion le projet IRL évolue et se précise :

Laurent s’est penché sur les datasheets de différents modules Zigbee, notamment ceux employés à Télécom Robotics (nous remercions au passage Samuel pour son lien). Il a étudié comment brancher les modules Zigbee pour pouvoir les utiliser via un lien RS232. Pendant ce temps, Yoann s’est renseigné sur internet sur les DAC et nous avons tous ensemble regardé les cartes d’extensions disponibles pour la Beagleboard.

Yoann et Caroline ont compris grâce à Alexis que Linux ne serait pas bien adapté à l’envoi en temps réel des points au laser. Nous utiliserons donc un micro contrôleur dédié à cette tâche avec un OS temps réel qui sera vraisemblablement FreeRTOS (toutes suggestions serait la bienvenue). Ceci porte à trois ou quatre le nombre d’entités du système qui est désormais formé des éléments suivants :

  • Une carte (appelée « principale » par la suite) hébergeant l’interface web d’administration, dont les fonctions principales sont le stockage des informations et le pilotage du système.
  • Un micro contrôleur traitant le flux DMX à la volée, recevant des informations de la carte principale par Zigbee.
  • Un micro contrôleur en charge des déplacements du laser, recevant des informations par un lien filaire qu’il a avec la carte principale.
  • Un autre micro contrôleur en charge de la sécurité : il coupe le laser s’il reste sur un même point pendant trop longtemps (cette fonction pourrait éventuellement être déportée sur la carte principale).