ELECINF344/381

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

Catégories

MB Led: Easter Saturday in A405

Today, we continued on our recent work : I worked on the algorithm and on the rotation of a block. The rotation works quite well now. The algorithm for this rotation is simple : When a communication between two blocks is stopped (due to the left of someone), the two blocks save their « interfaces » (aliases of the UARTs ). When there is a PING from a block, we check the saved interfaces in order to see if the block was a « friend » of this block. If it’s the case, we just calculate the rotation of the block.

The main problem is that a block can communicate with 4 others blocks at the same time. So, sometimes, we have to wait a little bit when we want to compare the interfaces.

Cédric noticed in the afternoon a bug in the IrDA functions and we fixed this. Now, the IrDA has more reliable and there are few problems in the network.

I still have problems when two networks meet with more than one block each involved in the « deal » but things are going better each day.

Benjamin worked on the launcher task. He thought of a remote block who can control the animation/game that will be played soon after.

Cédric continued the firmware transmission and the protocol is actually functional at good speed. But he is now facing problems with flash writing.

 

Here is a little video of the synchronization (running on the GLiPs but the MBLed are arriving soon):

 

Every block knows its i,j and minI, minJ, maxI, maxJ in the network. The block in the north-west shows a M; north-east a B; south-west LE: south-east D. If he is alone, he shows a M too.
That’s why sometimes in the video, there are 2 M : one of the block has encountered problems and reset himself.

For the synchronization, the leader gives the time every 20 PING (approximately every second), when a block receive that, it transmits it to his neighbor and so on.

 

 

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.