ELECINF344/381

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

Catégories

MB Led : Visual display of algorithm and snake first steps

Since our last post, Guillaume is still on the algorithm. Benjamin developed a display task for the old and new GLiPs. Now, we can see directly what’s going on in the network and try to debug it (see the picture). Yesterday, Guillaume tried to resolve bugs of freezing GLiP while the algorithm is running. He had to change many things in order to fix this and the only remaining freeze happens when some blocs leave the network.

There are some troubles when a block isn’t gone but don’t communicate with his neighbors. The biggest problem is when a block is rickety and that he communicates for time to time : he is considered as gone and soon after, he is here, etc. When this happens, the network can fail.

 

 

A little video to illustrate the visual debug:

 

Benjamin is develloping a special snake game concept for our system.

 

Guillaume and Benjamin.

 

MB Led: Working IrDA and colored LEDs.

Algorithm on GLiP block:

Today Guillaume has worked with 9 GLiP blocks, trying our algorithm in order to elect the leader among the network and give positions to each block. He succeed in this when the network is slowly increasing but when all the blocks come in a random way, it is still difficult to have a consistent network. There is still no acknowledge with the IrDA and when some packet is corrupted, the algorithm fails. We have to fix this soon.

IrDA:

Cédric has resolved his problem with UART4&5 for emitting packet. After some tests with Alexis, he found a good value for the resistance(4.7KOhms) to control emission power so that the blocks would communicate only to the neighbors. All potentiometers will be replaced by classical resistances.

LED matrix:

Now I can drive the LED matrix using the new driver TLC5951. I can display a 8×8 pixel on the matrix but I have to fix some problems of intensity. We knew that blue is more powerful than red and green and we try to avoid this problem. For the moment, we can’t obtain a perfect white but I’m in a good way to fix this problem.

 

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: Firmware, Bluetooth, bibliothèque graphique.

Depuis dimanche j’ai eu l’occasion d’avancer sur différentes parties:

Firmware:

Comme je l’explique dans mon précédent article nous mettons en place un système de mise à jour de firmware via IrDA. Mon travail a été d’implémenter, en utilisant les bibliothèques ST, les fonctions de déplacement de secteur de la flash depuis un bootloader situé en début de flash. J’ai effectué mes tests sur la carte de TP et utilisé objdump et openocd, ainsi que deux versions du « firmware » pour mes tests (un qui éclaire la LED en bleu et l’autre en vert). Une phase de débugage assez longue: des pages qui sont effacées sans le vouloir, la raison étant que la ligne de commande openocd faisait un « reset halt »  qui relancé l’ancien bootloader pour un nombre indétrerminé d’instructions, effaçant ainsi des mauvaises pages. Désormais on peut manipuler la flash à notre guise depuis le bootloader et effectuer la phase de recopie du nouveau firmware avant de l’exécuter sans problème.

Bluetooth:

J’ai commencer à implémenter réception/émission de commandes/réponses coté MB Led. Dès que je récupère un module bluetooth F2M03GLA, je pourrais faire des premiers tests de communication avec un client bluetooth sur mon pc.

Bibliothèque graphique:

Ecriture de premières fonction de manipulation des images, inspirées du code GLiP et d’autres plus adaptées au mode jeu (affichage de sprites, de lettres …).

A faire:

Nous devrions bientôt récupérer quelques unes de nos cartes avec les composants soudés. Je pourrais alors tester mon code pour le driver LED. En attendant je continue d’avancer sur les trois points précédents.

MB Led: Du hardware au software

LE PCB:

Nous avons terminé le PCB vendredi matin. Après avoir validé notre routage, Alexis nous a appris qu’il avait fait en parallèle sa propre version du PCB. Sa raison étant, non pas qu’il ne croyait pas en nous, mais que contraint par le temps il a préféré commencer un routage prenant directement en compte certaine contraintes (écartement des pistes, congestion des pistes etc.). En effet les commandes pour les PCB devaient être passé dimanche soir et cela laissé peu de temps à Alexis pour revoir les PCB de toute les équipes. Au final les différence entre nos deux PCB ne sont pas grandes (mis à part les contraintes évoquées plus haut). Nous avons même rajouté quelques composants par rapport à ceux prévus au départ, avant de finaliser le routage vendredi (merci Cédric). Alexis a donc vérifié et finalisé notre(son) PCB ce week-end avant de le placer dans notre dépot GIT.

Nouvelle perspective:

Alexis nous a aussi appris que ce seront non pas 16 mais 40 blocs qui seront commandés pour notre projet (et surement pour d’autres plus tard). Les possibilités de jeu et d’application s’en trouvent donc décuplées.

Algorithme:

Nous passons désormais au software. Guillaume continue sur sa lancée pour la simulation en python. Nous avons réfléchi à une nouvelle version pour notre algorithme, principalement pour le positionnement. Après une phase d’élection pour connaître le bloc qui sera utilisé comme référant pour connaître le nord, ce “leader” attribue aux autres blocs leur coordonnées. Il se définit en (0,0); les autres connaissent alors leur position relative par rapport au leader. Après cette phase, il est nécessaire de savoir quel est le plus grand rectangle sur lequel nous pouvons afficher quelque chose. Après une recherche d’algorithme tous très complexes, nous avons décidés d’un algorithme simple (que nous préciserons dans un prochain post). Désormais, nous cherchons un système pour acquitter tous les messages puisque nous ne sommes pas sûrs de la fiabilité de l’infrarouge.

IrDA:

Conformément à notre planning, Cédric commence à se renseigner plus en détail sur le protocole IrDA et sur l’échange de message entre les blocs. Il va dans un premier temps étudier le code de l’équipe GLiP pour comprendre leur façon de faire. A la suite de cela il établira un nouveau protocole d’échange de messages inter-bloc adapté à notre algorithme.

Driver de LED:

Pour ma part, j’ai imprimé la datasheet du nouveau driver de LED et l’ai compris à un niveau plus approfondi. Je commence maintenant à implémenter la gestion de l’affichage d’image via ce driver. Dans la précédente version chaque LED (rouge, vert bleu) pouvait varier entre 16 niveaux d’intensité. Avec ce nouveau driver, elles pourront varier sur 4096 niveaux. Les contraintes de place nous amèneront peut-être à revoir ce nombre à la baisse.
Guillaume, Cédric et Benjamin.

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

 

MB Led: PCB et algorithmique

Aujourd’hui, nous avons terminé le routage du PCB le TP stm32 et après une semaine nous avons pu reprendre activement l’avancement de notre projet.

Guillaume a continué à voir l’algorithme de notre système réparti avec la première et difficile question pour un bloc qui est de savoir où il est et où est son nord et cela qu’il soit seul ou dans un réseau de bloc. Ici se posent les problèmes de savoir quel bloc prendre comme base pour l’orientation dans le cas d’une modification importante du réseau de blocs (ex: on disperse tout et on reconstruit ou on colle brusquement deux réseaux de blocs). Nous sommes d’abord partis du principe que chaque bloc est une entité indépendante, mais nous envisageons maintenant de considérer le problème par réseau de blocs (un bloc seul étant un réseau d’un bloc) afin de coller à l’idée de système réparti et de permettre de traiter plus globalement les différents cas possibles. Par exemple lorsque l’on fait la jonction de deux réseaux, les deux réseaux échangent leurs états pour construire l’état du nouveau réseau. Se pose la question de la réactivité de ce système dans le cas d’une jonction simultanée de plusieurs réseaux. Il a également mis en place les bases et défini les différents types d’envois d’information en cas de transmissions extérieures (Via Bluetooth, port série) ainsi que la gestion des échanges et mise à jour de la liste des programmes et du firmware des blocs.

Benjamin a repris le schéma de GLIP comme base pour notre PCB pendant que je me penchais sur la question de l’achat des composants et des divèrses transformations que cela entraine dans le circuit. Nous nous sommes posés le problème de modulation de l’intensité d’émission des transceivers IrDA qui se fera grâce à un petit potentiomètre ainsi que celui l’intégration de la SD avec la recherche d’un connecteur (nous hésitons encore entre des cartes SD ou microSD) interfacé par le mode SDIO du STM32F103RET6 en 64 pins (48 ne seraient pas suffisants). Tout ceci nous a permis de commencer à évaluer le coût des composants des blocs pour un total d’environ 60€ (sans compter le PCB).

MB Led: Une carte trop chère…

Nous avons aujourd’hui appris que les cartes conçues par Alexis seraient trop chères, c’est donc confirmé nous devrons concevoir les cartes par nous-mêmes.

Comme nous souhaitons implémenter un stockage SD sur chaque carte et ainsi augmenter la quantité de données et de programmes (de jeux au final), nous nous orientons plutôt vers un microcontrôleur STM32F103RE qui possède une interface SDIO (pour l’interface hôte  SD) et 512kb de mémoire flash. Pour les composants, nous reprendrons l’alimentation et l’électronique des leds de GLIP. Nous devons toujours trouver une solution pour égaliser l’intensité des leds bleu vert et rouge, nous allons nous renseigner auprès de l’équipe  GLip afin qu’ils nous expliquent plus en détail le problème d’intensité trop forte des leds bleu.
D’ici vendredi nous serons fixés sur les nouveaux composants: Benjamin va s’occuper de la création sous MentorGraphic de la carte et du branchement du connecteur SD, Guillaume continuera au papier et au crayon pour l’algorithme général et Cédric va se renseigner sur des nouveaux transceiver IrDA et sur des moyens de moduler leur rayonnement.
Ce fût une longue journée, mais nous sommes désormais fixés sur ce que nous devons faire.

 

MB Led : Avancées du week end

Suite au conseil d’Alexis nous avons modifié nos PSSC afin de les adapter au scénario dans lequel nous devrions concevoir la carte pour
les blocs nous-même (et non en comptant sur celle conçue par Alexis, toujours en attente de devis). Pour la conception de notre carte, nous nous
inspirons fortement des schémas du bloc GLip (ici et) en y ajoutant un connecteur pour carte SD, en modulant la puissance des tranceivers Irda utilisés (pour éviter les problèmes de trop grande portée rencontrés par l’équipe Glip), et en rendant l’intensité des leds bleus identique à celle des leds rouges et vertes.

Nous nous sommes renseignés sur le protocole à suivre pour initialiser, lire et écrire une carte SD/SDHC et pendant nos recherches nous avons
découvert une bibliothèque implémentant ces fonctions pour les microcontroleur stm32 via le bus SPI → http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/.

Pour ce qui est de la recherche d’algorithmes répartis correspondant à notre cas nous somme tombés sur une thèse traitant de la
synchronisation des données pour le jeu multi-joueur/multi-machine ce qui est très proche de notre problématique, à savoir propager au
travers du réseau de bloc l’information sur l’état global du réseau (partie de jeu en cours, quel image est affiché dans l’animation à un
moment donné sur la matrice de bloc etc). Ce type d’algorithme a  la propriété de s’adapter facilement à l’arrivée/au départ de nouvelles
machine dans le réseau: http://tel.archives-ouvertes.fr/docs/00/54/18/49/PDF/TheseKHAN.pdf

Comme support de communication et afin de partager nos avancées intra-équipe nous utilisons un wiki (encore à l’état de brouillon) dont voici le lien : http://perso.telecom-paristech.fr/~bonny/mbled/

C’est parti pour MB Led

Hier et aujourd’hui, nous sommes partis du projet GLiP et avons pensé à des évolutions.

Nous espérons avoir les nouveaux blocs qu’Alexis a conçu, sinon il nous faudra le faire nous-même. Nous avons étudié la structure de GLiP en cas de conception de blocs. Nous repartirons sur un STM32, cependant nous regardons si nous ne trouvons pas un controleur avec une plus grande mémoire.

Nous voulons que le nouveau projet puisse lire des informations envoyés en Bluetooth par un smartphone de type Android. Ainsi, nous allons créer un module Bluetooth – Infrarouge. Pour cela, nous avons choisi le module Bluetooth F2M03GLA utilisé l’an dernier par le projet Wheely. Ce bloc ne posséderai pas de contrôleur et l’ensemble du traitement des données envoyées et reçus se feront sur la machine externe en soft.

Autre nouveauté : nous aimerions nous passer d’un maître dans les interactions entre blocs. Il faut concevoir des algorithmes d’échanges d’information en système réparti. Nous étudions actuellement les différentes possibilités.

Enfin, nous avons prévu les étapes, le planning et la liste des critères de succès finaux.