Différences

Ci-dessous, les différences entre deux révisions de la page.

--- projets:brutbox:dev:wireless:accueil [2020/04/10 12:46]
laurent [latence routeur/broadcast/carte wifi/ OS]
+++ projets:brutbox:dev:wireless:accueil [2020/04/10 15:07] (Version actuelle)
laurent [la solution ?]
@@ Ligne 40: / Ligne 40: @@
 ===== ESP8266 =====
 ==== code original ====
-Le [[https://framagit.org/guiaum/EMI_WALLET | 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.
+Le [[https://framagit.org/guiaum/EMI_WALLET | code original]] é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.
 ==== code v2 ====
 Cette [[https://github.com/reso-nance/brutbox-wifi | 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 :
@@ Ligne 51: / Ligne 51: @@
   * attribution automatique pour chaque brutbox d'un nom unique comprenant son adresse MAC
-===== communication avec puredata =====
+===== communication ESP8266 -> puredata =====
-À 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.
+À 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. Des essais ont été menés pour en déterminer la cause.
 ==== latence ESP8266 ====
-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
+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
 ==== latence routeur/broadcast/carte wifi/ OS ====
 Puisque la latence ne provient pas de l'ESP8266, elle peut être imputable :
@@ Ligne 63: / Ligne 63: @@
 **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.
+{{ :projets:brutbox:dev:wireless:toutesbbalumees2.png?direct&400 |}}
 ==== osc2pd ====
-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.
+Un [[https://github.com/reso-nance/brutbox-wifi/raw/master/osc2pd/osc2pd.py | 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.
+Le gain en vitesse de calcul comparé à la réception OSC interne à puredata n'a pas été évalué et il peut être tout de même bénéfique d'externaliser ce traitement en utilisant //liblo// à la place d'une abstraction pd. Un [[https://github.com/reso-nance/brutbox-wifi/raw/master/osc2pd/setup | script d'installation]] pour debian et ses dérivés (ubuntu, raspbian...) ainsi qu'un [[https://github.com/reso-nance/brutbox-wifi/raw/master/osc2pd/example.pd | exemple puredata]] sont disponibles sur le git. L'installation se fait en téléchargeant le dossier osc2pd sur le disque dur puis en exécutant ''%%sudo bash ./setup%%''. Une connection à Internet est nécessaire pour télécharger les dépendances. Le script peut alors être lancé par la commande ''%%python3 osc2pd.py%%''. Il écoutera sur le port 8000 et renverra à pd sur le port 10000.
+==== osc2alsa-midi ====
+Pour essayer une autre voie de communication, un troisième [[https://github.com/reso-nance/brutbox-wifi/raw/master/osc2midi/osc2alsa-midi.py | script python]] retranscrit les messages OSC reçus sous forme de **control change** MIDI sur l'entrée MIDI ALSA de puredata. Comme pour osc2pd, la transcription des données en alsa-midi n'a pas fait disparaître le problème de latence mais n'a pas été testée contre la gestion de l'OSC par pd. Cette méthode n'est pas conseillée puisqu'elle demande un adressage OSC -> numéro de CC et réduit la précision des données qui passent d'un float a un entier 7bit.
+=== installation ===
+Un [[https://github.com/reso-nance/brutbox-wifi/raw/master/osc2midi/setup | script d'installation]] pour debian et dérivés (ubuntu, raspbian...) permet d'installer les dépendances requises. Une fois connecté à Internet, exécuter ''%%sudo bash ./setup%%'' pour lancer l'installation. Le script se lance par la commande ''%%python3 osc2alsa-midi.py%%''
+=== utilisation ===
+Par défaut, le script tente de se connecter au port ALSA-midi de puredata quand on le lance. Si puredata n'est pas lançé ou pas configuré pour utiliser ALSA-MIDI avec au moins un port en entrée, une erreur sera affichée et le script s'arrêtera. Pour lancer automatiquement puredata avec la bonne configuration midi, ajouter les arguments ''%%-alsamidi -midiaddindev "ALSA MIDI device #1"%%'' au lancement de pd. Il est également possible de demander au script de lancer puredata en indiquant son chemin ligne 29 ( ''%%pdCommand = "pd"%%'' ou ''%%pdCommand = "/home/monUser/pd-0.xx/bin/pd"%%'' par exemple)
+La réception des données depuis le patch s'effectue comme n'importe quelle interface midi avec l'objet ''%%[ctlin]%%''. Un [[https://github.com/reso-nance/brutbox-wifi/raw/master/osc2midi/example.pd | patch d'exemple]] est fourni.
+=== adressage ===
+Le script tient une liste des adresses OSC reçues dans le fichier //OSCaddresses.txt// qu'il génère si nécessaire. À tout nouveau message reçu sera attribué un numéro de control change entre 0 et 127. Il est possible d'ajouter ou modifier manuellement les attributions en modifiant ce fichier texte. Pour assigner le CC#5 à l'adresse ///monOSC//, il suffit d'ajouter une ligne : ''%%/monOsc -> 5%%''. Les lignes commençant par le symbole # seront ignorées. Si deux adresses sont assignées au même CC, le script affichera un message d'erreur et la seconde sera ignorée. Pour chaque message, la valeur attendue est un float entre 0 et 1 qui sera transformé en une valeur entière entre 0 et 127
+==== la solution ? ====
+Comme nous l'avons vu, le problème de congestion observé provient bien de la façon dont les données sont gérée à l'intérieur de pd. Mes connaissances du fonctionnement interne de pd ne permettant pas d'en déterminer la cause plus avant, j'ai cherché une solution plus simple mais fiable. En limitant la quantité de messages émis par les capteurs à ~30 à 40 messages par secondes, ce phénomène ne se produit plus. Cette limitation n'étant pas liée à un //delay()// dans le code de l'ESP8266, elle n'induit aucune latence additionnelle. Le délai minimal entre deux messages émis par le même capteur est ajustable en en-tête des firmwares par la ligne ''%%#define MAX_RATE 30%%'' où il est renseigné en millisecondes. La valeur de **30ms** (soit ~33 messages/seconde max) semble sûre mais réactive. **Des tests additionnels en situation réelle doivent être poursuivis avant de considérer ce problème comme définitivement clos.**
 ===== Photos =====
 {{:projets:brutbox:dev:wireless:all-bbb-inok.png|}}

Wiki

Outils pour utilisateurs

Outils du site

Différences

Outils de la page