ELECINF344/381

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

Catégories

TSV Safe Express: Demystifying Conundrums

During the last two days, we have faced a lot of problems with the sensors of the track. We had two types of interrupts that were causing us problems:-
1. Debouncing Interrupts
2. Fake Interrupts

Problem: We have configured STM32 GPIO ports to Internal Pull-Up. All our sensors cards are powered by the Central Station Card through the CAN bus. We observed that there is some kind of parasitic signal that comes from the booster towards our Central Station which produces a glitch in the power towards the Nodes (Sensors card in this case). Due to this glitch in power, the GPIO ports which were pulled high become low and thus Fake Interrupts are produced. Thanks to Alexis who stayed till 5 in the morning to help us debug the problem.

The first one was solved by making sure that the any interrupts (that is not fake) from the sensors is processed only if there is atleast a gap of 100ms since the last time it was called. For the second one, which is more tricky, we use a simple method (a FreeRTOS task) which checks for glitches. This method was proposed by Samuel and we thank him for assisting with our software.

Right now, we are trying to do all the mapping of Reed Sensors and Lights to the XML Layout of the track. This is required as the central station needs to talk to server giving him with sensor input.

MB Led : First test with MB Led blocks

Yesterday, Alexis gave us 3 MB Led so that we could check the IrDA of the blocks. So far, Cédric achieved to communicate through UART 2 and 3 without any problem. For UART 4 and 5, he encountered problems to receive messages due to missing characters in the UART data register.

Benjamin started to check the  LED driver so that we could light the MB Leds soon.

Both of them used the oscilloscope to understand signals from the component.

Meanwhile, I fixed some bugs in the algorithm and my tests were successful on the GLiP blocks. Thoses blocks can only communicate through UART 2 & 3 so my job is now to test the algorithm on fully operating GLiP blocks (with their 4 IrDA transceivers), waiting for Cédric to test on our MB Led blocks. It seems that FreeRTOS scheduler is blocked when I tried to launch 16 tasks at once. I would try to fix this without reducing the numbers of tasks, cause each one is important…

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.

MB Led: Des séparations difficiles…

L’implémentation de l’algorithme est désormais presque fini. Tant que personne ne « quitte » le réseau, l’algorithme permet à tout le monde de savoir qui est dans le réseau et où il est; cela passe par une phase d’identification, une phase d’élection de leader, un positionnement des modules et la propagation de l’information au réseau entier.

Le problème principal est de bien faire cela dans l’ordre et que les informations données soient fiables et bien retransmises.

Lorsqu’un des modules quitte le réseau, celui qui s’en aperçoit propage l’information qu’il faut tout recommencer.
Pour remarquer qu’un module a disparu, la technique est simple : on envoie un PING et on laisse x ms à l’autre module pour répondre par un PONG. Si cela n’est pas fait, le module a sûrement disparu.
Lors de départ de module, il faut donc envoyer toutes les informations nécessaires sans oublier d’acquitter rapidement les PING, c’est pourquoi j’ai préféré utiliser une tache freeRTOS de très haute importance pour cela. Cependant, lors d’une simulation avec 9 modules, l’élection de leader se fait partiellement. De plus, l’acquittement ne se fait pas forcément et donc on repart à rien, ce qui peut conduire à un autre acquittement raté, etc.

 

Grâce à terminator, je peux suivre en temps réel les messages échangés entre les modules via zmq. (Les ping/pong ne sont pas montrés et il y a certains commentaires pour m’aider dans le débug.)

 

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

Les feux et les capteurs du circuit.

Bonsoir !

Apres  la discussion avec Samuel nous étions au courant de la possibilité pour obtenir la rétroaction du signal de DCC sur le rail en lisant un signal qui est fourni du booster. Nous comprenons que après l’ envoi d’un signal de DCC (qui normalement sera créé utilisant PWM) que nous devrions vérifier la valeur appropriée du signal de retour ou peut-être installer un mécanisme d’interruption au cas du probleme. L’étude appronfondie de FreeRtos indiquera probablement comment contrôler en pratique ce genre de situations.

Un autre problème semblable au lequel nous avions pensé, est de essayer  trouver le statut du LED’  s. Cela devra probablement inclure un mécanisme pour convertir le courant en tension mais c’est tout pour moment.

Pour ce qui concerne l’allumination de Led’  s. Nous avons trouvé quelques manières cool de les allumer avec une approche minimale et simple ici. Afin de réduire au minimum les pins qui contollent les LEd’s nous irons utiliser quelque Led Driver comme le  TLC  5925.

Nous avons aussi essayé de trouver un moyen pour détecter la position du train. Il existe deux types de capteurs: -
1. Capteur magnétique
2. Capteur infrarouge
Les deux ont à peu près le même coût. Mais nous avons décidé d’aller pour la première option car il nous semble qu’il peut être plus facile à installer dans notre modèle Train Track. On peut aller pour HAMLIN – 59140-010 coûté près de 2.4 euros.

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