• Porteur du projet : Reso-nance & Guillaume Bertrand
• Date : 2019
• Licence : libre !
• Contexte : dev
• fichiers malinette [puredata] :bb-wireless.zip
• Code original de Guillaume Bertrand : https://framagit.org/guiaum/EMI_WALLET
• Code refondu : https://github.com/reso-nance/brutbox-wifi

• Création d'un objet [bbw-in] et [bbw-in-help] sur la base de [bb-in].
• Solution temporaire pour la gestion des etats avec un fichier text local [text -k] car pb avec le systeme actuel et la malinette.
• Le patch “all-bbb-in.pd” est a ouvir en plus des patchs de jeu, qui ne contiennent pas d'objets [bbw-in].
• Le patch “all-bbb-in.pd” ne rappelle que l'etat dans lequel le patch a été enregistré. remet en question la presence des objects [bb-in] au sein de chaque patch, (pour ne pas multiplier les objects osc-in)… fonctionne avec des objects [s bbw1],[s bbw2] etc.

===proposition d'id a implémenter ds le code arduino :===

!! actuellement id pressure2= idpressure1

Le  code écrit par Guillaume Bertrand regroupe tous les types de capteurs brutbox en un seul fichier. Chaque capteur peut être personnalisé via des define placé en début de fichier. Ce code permet l'utilisation de capteurs analogiques comme numérique et prévoit une implémentation inachevée d'un gyroscope/accéleromètre à base de MPU5060. Pour en faciliter le développement et la maintenance, nous l'avons totalement refondu en une implémentation différente.

Cette nouvelle implémentation comporte trois codes distincts : un pour les capteurs analogiques (potentiomètre, pression, distance, lumière…), un pour les numériques (bouton poussoir, capteurs capacitifs…) et un pour le gyroscope/accéléromètre. Chacun de ces codes est paramétrable via des define en en-tête de fichier. Cette implémentation intègre de nouvelles fonctionnalitées :

• gestion du MPU5060 en différents modes (accéléro, gyro, choc) incorporant les fonctions du Digital Motion Processor intégré
• activation du flash en OTA (possibilité de flasher le firmware des brutbox sans les démonter, par le wifi)
• filtrage basique des données pour les capteurs analogiques
• mode “choc” pour les capteurs analogiques détectant un changement rapide de valeur (permettant par exemple de déclencher des effets différents selon le type d'appui sur le capteur de pression)
• possibilité d'ajouter simplement autant d'entrées que nécessaires sur les capteurs numériques (exemple du puzzle crèche)
• limitation du nombre de messages envoyés par seconde pour éviter une congestion des messages sous puredata
• attribution automatique pour chaque brutbox d'un nom unique comprenant son adresse MAC

À plusieurs occasions il a été constaté un dysfonctionnement important du système amenant une latence de plus en plus importante entre la manipulation du capteur à son effet audible, pouvant aller jusqu'au crash de pd. Pour en déterminer la cause, des essais ont été menés.

Pour mesurer le temps nécessaire à l'ESP8266 pour empaqueter un message OSC et l'envoyer, un firmware spécifique a mesuré le temps écoulé entre le début de l'empaquetage et la fin de l'envoi, après la suppression du message en RAM via la fonction micros(). La durée moyenne mesurée est de 600µs +- 100µs. Cette durée est extrêmement stable dans le temps et ne dépend pas du message à envoyer. La latence observée ne vient donc pas de l'ESP8266

Puisque la latence ne provient pas de l'ESP8266, elle peut être imputable :

• au routeur qui met du temps à dispatcher les messages en broadcast
• à la carte wifi de l'ordinateur sur lequel tourne pd qui met ces messages en mémoire tampon
• à la qualité de la connection wifi lorsque beaucoup d'appareils sont connectés (perte de paquets UDP)

Pour tester l'ensemble, un script python envoie régulièrement sur le port série un nombre aléatoire. L'ESP8266 reçoit ce nombre et le renvoie en OSC via le broadcast. Ce message arrive donc au routeur qui le distribue à l'ordinateur qui mesure alors le temps écoulé entre l'envoi de ce nombre sur le port série et sa réception en OSC. Il tient également le compte des messages envoyés en série mais jamais reçus en OSC (paquets perdus). La réception OSC est gérée par liblo, une implémentation en C légère et performante du protocole OSC. Ce test à été effectué sur de longues durées de fonctionnement (plusieurs heures) avec toutes les brutbox connectées. Les paquets série ont étés envoyés le plus rapidement possible soit toutes les 8ms.

Résultats : l'aller-retour des messages prends en moyenne 9ms (90% des messages ont un délai compris entre 8ms et 17ms) et la perte de paquet est minimale (inférieure à 0.6%). La latence observée (>50ms) ne peut donc être liée ni au routeur, ni à la qualité de la connection, ni au système d'exploitation. Le problème se situe donc en aval de cette chaine, dans puredata. Pour comprendre si le dépaquetage de l'OSC en était à l'origine, d'autres méthodes de communication entre les brutbox et puredata ont été essayées.

Un script python reçoit les messages OSC, utilisant toujours liblo. Il utilise ensuite l'utilitaire pdsend pour en envoyer le contenu en UDP local à puredata. Par exemple, un message /monOSC contenant le flottant 0.12 sera traduit en la commande echo /monOSC 0.12 | pdsend 10000 localhost udp qui passera l'addresse OSC ainsi que la valeur à puredata en UDP sur le port 10000. On pourra la récupérer dans un patch via [netreceive -u 10000] et éventuellement utiliser [route /monOSC] pour trier les messages entrant. Cette méthode ne nécessite donc aucun paramétrage particulier puisqu'elle traduit directement tout message entrant en un message du même nom, permettant d'utiliser les mêmes [route] qu'on utiliserait pour un message OSC. Elle s'appuie toujours sur la couche réseau de puredata mais permet d'éviter le dépaquetage de l'OSC dans pd.

À ce jour, cette méthode montre encore une latence trop importante pour être dûe au seul traitement de l'OSC à l'intérieur de puredata. Pour vérifier le rôle de la couche réseau de PD, il est nécessaire de l'éviter en utilisant une autre voie de communication.

Liste de matériel et composants a faire

Autres photos, galerie, …