Arbalet Mesh (fr)


#1

Cahier de bord du prototype Arbalet Mesh

Arbalet Mesh est un kit de mise en lumière architecturale capable de transformer n’importe quel bâtiment en une oeuvre éphémère de Pixel Art. Mais plus qu’une simple mise en lumière, Arbalet Mesh est aussi un outil pédagogique Edtech permettant d’enseigner les bases de la programmation informatique sous forme événementielle. C’est un support de divertissement et de formation qui détourne notre environnement immobilier.

Arbalet Mesh donne suite au projet Arbalet Frontage, testé à partir de 2017 par l’association Arbalet Living Lab sur une façade d’un bâtiment de l’Université de Bordeaux. Après 2 ans d’ateliers ouverts gratuitement au public sur cette installation artistique pérenne, ce projet doit s’exporter en dehors des murs de l’Université. Ainsi Arbalet Mesh héritera de tous les points forts d’Arbalet Frontage en matière de décoration et d’éducation, rassemblés dans un kit au format léger et itinérant.

Nous sommes une équipe de 7 étudiants informaticiens de l’école d’ingénieur ENSEIRB-MATMECA qui allons concevoir le prototype avec Arbalet Living Lab afin de rendre cet outil d’art et d’enseignement accessible à tous. Ce document décrira la mise au point technologique du prototype.

Le principe est plutôt simple : chaque fenêtre du bâtiment abrite un pixel coloré, créant ainsi une grand oeuvre d’art visible de l’extérieur.

Implémentation technologique

Comme dans notre cas nous affichons des images sur des surfaces très grandes, il est nécessaire d’avoir pour chaque pixel un micro-contrôleur , ainsi, il faut pouvoir les synchroniser entre elles. Sur Arbalet Mesh, il était nécessaire de relier les pixels entre eux et à un boitier central qui s’occupait d’envoyer à chaque pixel les informations dont ils avaient besoin. Mais cela présentait des inconvénients, comme le besoin de devoir câbler chaque contrôleur vers la centrale, ce qui limitait grandement notre portée et causait des soucis d’infrastructures, sans compter le temps que cela pouvait prendre.

La topologie Mesh

La topologie Mesh, ou système de communication de réseau en maille, est une organisation pensée de telle manière que chaque point du réseau est connectée à ses voisins, ainsi ici, les informations vont être envoyé de proche-en-proche, ici de micro-contrôleur à micro-contrôleur jusqu’à ce que tous les composants du réseau reçoivent l’information. Utiliser cette topologie présente deux grands avantages :

  • Si un des composants du réseau venait à ne plus fonctionner, on peut tout de même continuer à communique au reste du réseau grâce au principe de re-routage
  • On n’est pas obligé de relier chacun des composants à la centrale, permettant de réduire le câblage nécessaire au bon fonctionnement du système (aucun câblage réseau nécessaire)

L’objectif de notre implémentation

L’objectif pour nous est de parvenir à trouver une implémentation qui soit évolutive et efficace répondant aux besoins de ce projet, pour ce faire nous discuterons des différentes technologies et modules les plus adaptés à ce projet, que cela soit d’un point de vue logiciel (langage de programmation), électronique (module d’extension et type de micro-contrôleur utilisé) ou matériel. Il nous faudra réaliser une intégration logicielle stable et robuste, implémenter notre propre système électronique et notre propre carénage pour pouvoir à la fin réussir à connecter 6 pixels en temps réel, et, à terme, pouvoir présenter notre prototype final d’ici l’été 2019.


#2

Les Pixels

Les pixels ont pour but d’être fixé à l’intérieur des bâtiments, sur les rebords de fenêtre. De plus ils doivent être strictement identiques et interchangeables pour faciliter l’installation.
Pour ce faire, ils doivent :

  • pouvoir communiquer entre eux via la technologie Mesh (qui garantie l’interchangeabilité des pixels);
  • éclairer de la couleur choisie;
  • être alimenté en énergie.

Nous nous intéressons ici à la partie hardware des pixels.

Composants électroniques

1) Communication et choix de couleur

Les pixels communiqueront entre eux à l’aide d’un réseau WifiMesh. Ils seront tous dotés d’une carte ESP32 qui leur permettra de communiquer via le Wifi.
De plus, les cartes ESP32 étant pourvues d’un microprocesseur et d’une mémoire suffisante, elles se suffiront à elles-mêmes.
Elles auront pour rôle d’assurer la communication au sein du réseau Mesh et de modifier la couleur du pixel (dont elles font parties) en fonction des informations qu’elles reçoivent.

2) Éclairage

Pour assurer l’éclairage, nous reprenons les mêmes rubans de LEDs que ceux utilisés dans les projets Arbalet précédents, à savoir le ruban WS2812B.
Ces rubans montent en parallèle des LEDs chacune pourvue d’un microcontrôleur et d’un identifiant. Elles sont donc adressables indépendamment les unes des autres.
Le ruban nécessite d’être alimenté en 5V et le niveau logique est lui aussi de 5V.

3) Alimentation

Les pixels seront équipés d’un boitier d’alimentation secteur délivrant la tension et le courant suffisant.
Les cartes ESP32 et les rubans WS2812B ayant des tensions de fonctionnement différentes, l’alimentation devra fournir à chacun des composants le voltage et l’ampérage adéquat.

Schéma du montage


#3

Première itération

Pour cette première itération, nous avons fait le point sur notre matériel, puis mis en place des objectifs simple pour se familiariser avec celui-ci.

Notre matériel

Pour ce projet, nous disposons de :

  • 6 cartes ESP32, correspondant chacune à un pixel. Ces cartes sont équippé d’un module de développement, facilitant leur manipulation.
  • 6 cables USB, 3 de 20 cm et 3 de 1m.
  • 2 chargeurs adaptateurs USB
  • 6 Alim 5V 2A
  • 6 adaptateurs femelle DC à souder

Une fois notre matériel présenté, nous avons défini les objectifs de notre première itération, centrée sur la communication au sein du réseau.

Le réseau

Présentons d’abord la structure du réseau. Nous disposons d’un serveur, sur lequel tourne le Backend : c’est à lui que se connecteront les clients, il a ainsi un rôle de superviseur. Il sélectionne les informations à transmettre au réseau Mesh, concernant les pixels à allumer et comment.

Ce serveur transmet ensuite ces informations au réseau Mesh, composé des différents noeuds, chacun d’entre eux correspondant à une carte ESP. Un noeud peut avoir différents rôles :

  • Noeud maître : noeud unique situé à l’entrée du réseau Mesh, passerelle avec le serveur.
  • Noeud intermédiaire : noeud capable d’exécuter du code, et de relayer les informations aux autres noeuds du réseau.
  • Noeud feuille : noeud terminal, ne retransmettant pas les messages qu’il reçoit.

Le réseau s’agençant de façon à transmettre le plus efficacement possible, ces rôles sont interchangeables entre noeuds, permettant de rapidement pallier à une panne réseau.

Nos objectifs

Nous avons ainsi décidé de nous concentrer sur deux grands axes :

  • La communication serveur - ESP32. Dans un premier temps, nous allons employer une communication serial via cable USB. Par la suite, nous vérifierons s’il est possible d’utiliser une connexion Wi-Fi entre les deux sans créer d’interférences dans le réseau Mesh.
  • La communication ESP32 - ESP32, base du réseau Mesh. Nous testerons d’abord comment initialiser cette connexion entre deux cartes, puis nous nous assurerons des propriété du réseau Mesh en les éloignant sufisamment pour qu’elles ne puissent plus communiquer entre elles et en ajoutant une troisième carte entre les deux.

Pour nous assurer que les données soient transmises et bien reçues, les cartes enverront un certain nombre, et les cartes le recevant devront clignoter d’autant de fois. Les cartes seront programmées avec l’IDE Arduino, configuré pour pouvoir téléverser le code sur les ESP32 directement.

Notre objectif est d’ainsi mettre en place une preuve de concept du réseau Mesh.


#4

Seconde itération

Résultats de l’itération précédente :

Lors de la première itération, le groupe a implémenté quelques preuves de concept pour mieux connaitre les cartes ESP32. Le groupe a alors testé l’interface serial entre un ordinateur et une carte, l’interface WiFi entre un ordinateur, un réseau et une carte et finalement l’interface WiFi entre plusieurs cartes. Ce dernier test n’a pas très bien marché, raison pour laquelle ces tests doivent être repris plus en profondeur. De plus, il faudra réaliser des tests entre un ordinateur et une carte sans un point d’entrée (téléphone portable par exemple) entre les deux.

La structure physique

Les cartes seront placés dans un compartiment liée à un tube. Dans ce tube, il y aura des LEDs avec une ouverture afin que leur lumière puisse être dirigée vers les fenêtres où le projet sera installé. La figure ci-dessous montre la structure prévue.

Le protocole d’adressage

Afin que l’installation soit rapide et efficiente, il faut définir un protocole d’adressage initial. Il faut tout d’abord indiquer au système quelles sont les dimensions d’installation. Ce dernier doit ensuite essayer trouver le positionnement physique des cartes de manière automatique, par une recherche basée sur l’intensité des signaux. Pourtant, il est possible que cette technique ne soit pas parfaite, et donc il est nécessaire d’avoir une interface pour calibrer les pixels mal positionnés. Une idée implémentable pour une calibration manuelle assistée est de faire clignoter les pixels l’un après l’autre, de manière à ce qu’une personne puisse indiquer sur une matrice quelle est sa bonne position. Cependant, il faut bien réfléchir sur les différents manières de faire le calibrage.

Nos objectifs pour la prochaine itération

Les objectifs suivants doivent être atteints pour la prochaine itération:

  • Mieux comprendre la communication entre les différents cartes ESP32 : en affichant le MAC adresse de chaque carte connectée au réseau, on peut découvrir d’où viennent les problèmes identifiés lors des tests de communication entre cartes.
  • Chercher la porté standard pour les cartes ESP32 : sur IRC ou forums spécialisés en microcontrôleurs, essayer de trouver la portée usuelle d’une carte ESP32.
  • Tester la communication entre les différentes cartes ESP32 en utilisant la bibliothèque MDF : un autre choix d’implémentation qui n’a pas correctement fonctionné lors de la précédente itération, contrairement à PainlessMesh.
  • Tester la communication entre un ordinateur et une carte via WiFi sans un point d’entré : les tests déjà faits utilisaient un point d’entrée entre les deux, il faut donc tester la communication directe.
  • Tester la communication du réseau Mesh : après validation des précédents tests, tester la communication entre une carte qui est connecté (sur WiFi) à un ordinateur, et au même moment connectée avec les autres cartes
  • Réfléchir sur les possibilités de protocole d’adressage à utiliser pour calibrer les pixels lors de l’installation du système Arbalet Mesh

#5

Résultats de l’itération précédente :

Une réduction du nombre de bauds a permis d’augmenter la portée des cartes utilisées, et des recherches empiriques ont permit de confirmer jusqu’à 20 mètres de portée de communication entre ESP. La bibliothèque ESP MDF a été utilisée avec succès afin d’implémenter un protocole de communication entre les ESP. Un protocole d’adressage a été proposé.

Protocole d’adressage et de communication

Afin de réaliser l’adressage nécessaire à la mise en place initiale du réseau Mesh, ainsi que le bon transfert des messages entre les différentes cartes électroniques, l’idée retenue est de réaliser 3 trames aux fonctionnalités différentes :

  1. Une trame beacon envoyée lors de l’arrivée d’un nouveau noeud dans le réseau, et relayée par les noeuds environnants, contenant un numéro de trame et l’adresse MAC du noeud joignant le réseau ;
  2. Une trame install envoyée à l’initialisation par le serveur, dotée d’un numéro de trame, et qui va attribuer à chaque pixel un numéro identificateur ;
  3. Une trame de communication, dotée d’un numéro de trame, et qui transmet un tableau dont chacune des cases contient les composantes RGB associées à un pixel, le numéro de la case du tableau étant associé au numéro identificateur du pixel correspondant.

Nos objectifs pour la prochaine itération

Les objectifs suivants doivent être étudiés pour la prochaine itération :

  • Effectuer des recherches sur les antennes, en particulier la nécessité de modifier la programmation, les PIN de branchement relatifs aux antennes, ou encore la possibilité de fabriquer une antenne soi-même ;
  • Poursuivre le travail sur la communication entre ordinateur-ESP et ESP-ESP en même temps, et réaliser une PoC ;
  • Décider d’un framework de développement parmi MDF & PainlessMesh ;
  • Commencer la réalisation des trames de communication.

#7

Quatrième itération

Résultats de l’itération précédente :

Une description formelle des différentes trames (beacon, install et communication) a été réalisée. Les trois trames sont représentées sous la forme suivante :

  1. Beacon : {n trame, @MAC}
  2. Install : {n trame, {@MAC1, … , @MACn}}
  3. Color : {n trame, {{r,g,b},…,{r,g,b}}}

Un protocole d’adressage initial a été proposé. En plus, plusieurs scénarios ont été traité (l’ajout, la modification et la suppression d’un nœud). La bibliothèque MDF a été choisie pour le reste du projet. Une recherche sur les antennes a été réalisée pour étendre la portée des cartes ESP32. Une communication simultanée entre ordinateur-ESP et ESP-ESP a été établie, la communication entre l’ordinateur et la première carte ESP32 se fait par WiFi, l’autre communication se fait par Mesh.

Protocole d’adressage manuel avec assistance:

Le protocole d’adressage manuel avec assistance consiste à récupérer l’adresse MAC des cartes ESP32, puis associer à chaque adresse sa position dans le plan. Pour cela, il a été proposé de réaliser une partie frontend qui permet initialement à l’administrateur de fournir les dimensions du bâtiment (sa longueur et sa largeur) sur une première page, puis une autre page s’affiche sous forme une grille (une matrice). Les pixels commencent à s’allumer un par un, ainsi l’administrateur fourni la position du pixel courant en cliquant sur sa place correspondante sur la grille.

Nos objectifs de la prochaine itération :

  • Documenter le protocole d’adressage initial.
  • Documenter le protocole de réadressage à chaud.
  • Implémenter un protocole d’adressage assisté avec un script python.
  • Faire une configuration de la géométrie du backend avec le Frontend.

#8

Cinquième itération

Retour sur l’itération précédente

Lors de l’itération précédente, nous avons documenté le protocole d’adressage manuel assisté, développant en profondeur l’utilisation des trames BEACON, INSTALL et COLOR. Ainsi que l’utilisation du frontend.

Nous avons également mis à jour le document de spécifications concernant la taille maximum d’une trame qui circule sur un réseau ESP. L’objectif étant d’envoyer qu’une seule trame COLOR pour ne pas diviser l’envoie des données.

Les démos

Démo d’adressage

L’objectif de cette démo est de montrer que chaque carte ESP connait ses coordonnées physiques sur une structure donnée. L’idée est de faire clignoter la LED d’une ESP (x * y) fois, nous permettant de vérifier si les coordonnées (x, y) enregistrées par la carte correspondent a ses coordonnées physiques, excepté l’erreur où la carte serait en (y, x).

Démo des trames de couleur

L’objectif de cette démo est de montrer que chaque ESP reçoit bien la trame COLOR et sait la traiter. L’idée est que chaque carte ESP reliée à une LED s’allume à la reception de la trame.

Machine à états

La machine à états est un automate fini qui énumère les différents états de nos ESP et leurs transitions. Cet automate nous permet de distinguer visuellement les différents états des cartes.
Un exemple de changement d’état possible est lors de la phase initiale. La carte ESP n’est alors pas encore dans un réseau Mesh, lorsqu’elle en capte un, elle va envoyer une trame BEACON et attendre une trame INSTALL qui va lui donner un identifiant puis elle passe en mode écoute, état dans lequel elle peut exécuter les trames COLOR.

Objectifs pour l’itération suivante

  • Finir le travail sur l’adressage manuel assisté, dont la machine à états.

  • Configuration de la géométrie du backend et Frontend (Accèder aux données en faisant des accès par la base de données, interface utilisateur, …).

  • Démo d’adressage sur toutes les structures possibles avec 6 pixels

  • Démo des trames COLOR

  • Mettre à jour le document de spécifications sur les différentes pannes possibles

  • Documenter le protocole de ré-adressage à chaud


#9

Sixième itération

Retour sur l’itération précédente

Lors de l’itération précédente nous avions fixé plusieurs objectifs :

  • Nous devions finir le travail sur l’adressage manuel assisté, nous avons produit le graphe conceptuel de la machine à état, nous avons presque terminé l’implémentation.

  • Nous devions établir un système de communication entre le backend et le frontend. Nous avons réussi à créer une nouvelle page dont l’accès est reservé à l’administrateur et qui permet de configurer la disposition des ESP sur le batîment .

  • La démo d’addressage sur toutes les structures possibles avec 6 pixels a été réalisée et fonctionne : l’administrateur peut configurer la structure des ESP.

  • La démo des trames COLOR a été réalisée et fonctionne, on parvient à faire clignoter les ESP de manière séquentielle, rythmée par l’envoie des trames COLOR (La 1ère ESP reçoit la 1ère trame COLOR et clignote une fois, la 2ème reçoit la 2ème trame et clignote 2 fois etc).

  • Le documents de spécifications a été mis à jour avec les différentes pannes possibles.

  • Le protocole de réadressage à chaud a été documenté.

    Configuration du réseau par l’administrateur

    La nouvelle page Mesh_page permet à l’administrateur de configurer le réseau mesh, il suffit qu’il place les ESP dans la disposition de son choix et qu’il se rende sur la page de configuration, elle va lancer l’application qui permettra à l’administrateur de confirmer la disposition des ESP et de la sauvegarder dans la base de données, pour pouvoir en cas de redémmarage du système pouvoir relancer directement le réseau (sans devoir reconfigurer).

    Objectifs pour l’itération suivante

    • Réussir à ouvrir correctement les ports pour permettre la communication avec le serveur et le réseau mesh.

    • Tester que les communications avec nos applications depuis le réseau mesh fonctionnent et vérifier le bon état de la base de données.

    • Rajouter des protocoles pour permettre de connaître la disponibilité des ESP lors de l’addressage (Blanc -> disponible, Vert -> ESP en cours de sélection, Gris -> Indisponible).

    • Rajouter des conditions pour empêcher l’admnistateur de configurer le réseau de manière incohérente (Dimensions négatives par exemple).

    • Vérifier les communications à travers le Websocket (lorsque l’on se sert d’une application).


#10

Septième itération (datée du 22 février 2019)

Retour sur l’itération précédente

Les précédents objectifs incluaient l’ouverture et la stabilisation des échanges entre le réseau mesh et le serveur de test, des corrections mineures sur la base de données.

Travail réalisé

Les échanges entre le réseau mesh et le serveur de test sont désormais stable et les informations correctement communiquées. La base de donnée a été épurée de quelques erreurs mineures.

Prochains objectifs

  • Le serveur restant malgré tout un serveur de test, un véritable serveur doit à présent être développé, capable à la fois de recevoir des informations en amont pour les transmettre au réseau mesh (affichage des couleurs) et de transmettre les informations en aval vers le backend. À cette fin, le serveur sera incorporé dans docker comme container.
  • Le réseau mesh doit être à nouveau modifié afin de répondre à de nouveaux besoins du futur serveur, ainsi qu’à préparer l’implémentation du protocole de réadressage à chaud.
  • Une nouvelle f-app spécialisé dans l’exécution de l’adressage manuel et exécutant les opérations lui étant relatives vis-à-vis des autres containers doit être implémentée. Cette f-app doit être uniquement lancée sur ordre de l’administrateur via un bouton situé sur le frontend. Cette application gèrera en outre à la fois l’adressage manuel initial et le réadressage.
  • Le protocole de réadressage doit par ailleurs être réécrit entièrement, afin d’être plus exhaustif, ainsi qu’afin de se conformer aux nouvelles spécifications apparues via l’utilisation d’une seule f-app.

L’objectif principal de cette itération sera de pouvoir laisser tourner durant quelques jours l’ensemble de système lors de la prochaine itération, afin d’identifier de possibles problèmes.


#11

Huitième itération

Retour sur l’itération précédente

Le projet avançant et le cas nominal étant correct, et les erreurs simples gérées, il était temps de le mettre à l’épreuve en le laissant tourner une journée entière, sous surveillance, de façon à voir s’il supporte la charge.

Travail réalisé en amont

Nous avons testé et implémenté différentes gestions des cas d’erreur, et nous sommes assuré que le cas nominal était valide et fonctionnel. En parallèle, des avancements ont été faits sur des fonctionnalités n’ayant pu être prêtes à temps pour le test.

Déroulement du test

Nous avons configuré le Backend le matin, puis avons installé les cartes, et enfin avons fait la procédure d’adressage.

Une heure et demi après, hormis l’ESP Root, toutes les cartes étaient inactives. Il s’est avéré qu’une sécurité bloquante avait persisté dans les séances de débug de la veille. Les cartes ont été débranchées, les tests stoppés temporairement le temps de tout corriger.

Les tests ont mis en évidence des irrégularités dans le comportement des cartes électroniques et du serveur, et les interactions étaient souvent interrompues par des problèmes parfois durs à identifier, menant à une session de tests méthodique.

Améliorations qui ont suivies

  • Des tests plus exhaustifs, au cas par cas, ont été réalisé de façon à mettre en avant les différents cas de panne existants, et une résolution adaptée à chacun d’entre eux.
  • La procédure de réadressage à chaud à été finalisée, et testée de façon à s’assurer de son bon fonctionnement.
  • Une nouvelle fonctionnalité, permettant de réutiliser un adressage existant, a été implémentée.
  • Le Frontend a été corrigé, de façon à ce que toutes les anciennes F-app soient compatibles avec lui et que la nouvelle F-app Mesh réalisent toutes les opérations dont nous avions besoin.

Conclusion

Maintenant, il n’y a plus de problème de communication entre les ESP, le serveur et le client. Les cartes peuvent être adressées de différentes façons, et la base de données est mise à jour accordément. Le Frontend et le Backend peuvent être installé en suivant les modes d’emploi disponibles sur leur dépôts respectifs.