L’objectif de ce projet est d’utiliser un setup de dix enceintes, réparties dans le Fablab, afin de spatialiser le son en fonction du mouvement d’un objet. Nous avons pour ambition de générer un son de voiture dans la pièce, qui suit les déplacements de notre voiture dans le Fablab. La gestion de l’intensité sonore de chacune des dix enceintes permettra de créer un effet de spatialisation de notre voiture.
Nous avons décomposé en trois parties distinctes ce projet. La première traite du calcul de position de notre voiture en mouvement. La seconde partie quant à elle est la partie réseau du projet, car il faudra transmettre la position de notre objet connecté au PC, gérant la spatialisation des enceintes. Enfin la dernière partie relève du traitement de ces données réceptionnées, afin de gérer cette fameuse spatialisation sonore.
Contenus de la page
Determination de position par calcul de retard
Dans cette partie nous allons détailler la méthode utilisée permettant de localiser l’objet à l’intérieur de la salle. Pour se faire nous avons décidé d’utiliser encore une fois le système d’enceinte.
Le principe général est le suivant :
Chaque enceinte envoie au même moment sa signature ultrasonore, l’objet identifie chaque signaux provenant des différentes enceintes, et mesure leurs retards. A partir des retards il détermine sa position dans la pièce.
Plus en détail…
Chaque enceinte émet un signal binaire connu et unique modulé en OOK à une fréquence elle aussi unique. Le micro du récepteur capte toutes les différentes fréquences et les traite une par une. Il réalise ensuite l’inter corrélation entre la trame écoutée et le signal binaire connu de l’enceinte afin de connaître à quel instant de la trame il a été reçu. Il réalise cela pour tout les différents messages binaires et en déduit ainsi les retards entre chaque signaux.
En connaissant les retards et les positions de chaque enceintes on peut en déduire les coordonnées de l’objet. Les temps de calculs étant assez élevés, afin d’augmenter au maximum la fréquence de rafraichissement de la position de l’objet on décide de diminuer au maximum le nombre d’émetteur car la recherche de messages binaires dans la trame est l’élément le plus chronophage de l’algorithme. Ainsi étant donné qu’on se situe dans une enceinte fermée rectangulaire on peut se contenter de seulement deux émetteurs placés dans deux coins adjacents car même si théoriquement même s’ils identifieront deux positions possibles, une des deux sera toujours aberrante (hors de la pièce) comme décrit sur le schéma ci-dessous
Transmission des données : communication Websocket en Javascript
Pour avoir un objet connecté permettant de traiter et envoyer des données à l’ordinateur qui s’occupe de piloter les 10 enceintes, nous travaillerons avec une carte Raspberry Pi 4, occupée d’une puce Wifi qui permet de connecter à un réseau sans fil , et dont le microprocesseur offre des performances de calcul similaire à celle d’un ordinateur. Cette carte traite le son capté par le microphone/capteur connecter à l’un des ports usb ou au ports GPIO.
La carte alimenter par une batterie externe va nous servir comme un serveur, et on utilise le Wifi comme support de communication puisqu’il offre des performances important par rapport au Bluetooth qui fournit souvent un faible portée (10 mètres), La socket serveur TCP (WebSocket) envoie en permanence chaque 2 secondes les coordonnées spatiales introduit dans la partie précédent de la carte vers l’ordinateur de pilotage, pour que le logiciel qui gère les 10 enceintes puisse traquer la position de l’objet en mouvement.
Une fois que la carte est redémarrée, il faudra que la connexion et le déclenchement du serveur se fait automatiquement, sans aucune intervention de l’utilisateur. Pour cette raison, on ajoute deux fichiers de configuration ont été ajoutés au système d’exploitation de la carte, l’un « /boot/wpa_supplicant.conf » permettant de connecter automatiquement au WiFi, et l’autre « /pi/.config/autostart/auto.desktop » permet d’exécuter/lancer le fichier « serveur.js » à chaque démarrage.
Spatialisation sonore
L’installation du système de 10 enceintes permet d’obtenir des sources sonores à 360°. Cela rend possible la localisation précise d’un son dans la salle. On peut dire que c’est une évolution du système Stéréo qui lui ne permet que de répartir le son entre la source droite et gauche. Ce genre de système audio est souvent utilisé dans le monde du spectacle ou de l’attraction, car il peut en effet créer une expérience immersive pour le spectateur.
Ce genre de système fonctionne de paire avec un contrôleur de sources, un logiciel qui va permettre de placer et déplacer des sources virtuelles sonore dans l’espace couvert par les dix enceintes. Il existe de multiples méthodes pour réaliser cela. Les Digital Audio Workstations offrent souvent la possibilité de contrôler un système son complexe, comme celui installer à Eirlab. Avec des Plugin (extension des ces logiciels) il est alors assez simple de placer une source sonore en contrôlant le volume de chaque enceinte. Cependant, nous n’avons pas opté pour cette solution car d’autres outils étaient à disposition au labo. En effet, le SCRIME est venu installer deux logiciels pour pouvoir travailler avec ce système audio.
Le premier outil est MOSCA, c’est un logiciel qui permet de créer et placer des sources sonore dans l’espace. Il requiert une configuration préalable pour pouvoir être utilisé. L’espace couvert doit être défini lors de l’installation. La position de chaque enceinte dans la salle doit être renseignée. Les axes de l’espace doivent aussi être définis pour pouvoir localiser les sources sonore. Une fois MOSCA correctement configuré et ouvert, il est possible de créer des sources sonore à placer dans l’espace. Chaque source a plusieurs propriétés, notamment le son qui va devoir être jouer et sa position dans l’espace en coordonnées polaires ou cartésiennes. Une fois créée, la source peut être déplacée dans l’espace donné et le son semblera provenir de différents endroits du labo.
Maintenant que l’on possède une source de son dont on peut contrôler la position dans l’espace, il nous faut la lier avec la position de l’objet mobile. En supposant que l’on reçoive d’une quelconque manière la position la voiture sur l’ordinateur, plusieurs solutions s’offrent encore à nous.
Le langage dans lequel est codé MOSCA est le SuperCollider. Ce langage offre la possibilité de communiqué avec du hardware connecté en port série. On aurait pu donc, par exemple, avoir une carte recevant la position de l’objet via bluetooth, puis récupérer la donnée avec un script SuperCollider, intégrer ce script dans le code source MOSCA pour lier les coordonnées de l’objet avec celles de la sources sonore. Cependant, nous n’avions aucune connaissance dans ce langage, donc mis cette solution de côté.
Le second logiciel installé par le SCRIME est Ossia Score. C’est un séquenceur audio, il permet de créer des séquences de temps dans lesquelles on peut choisir d’appliquer des effets à une source audio, envoyé des messages MIDI, OSC, etc… Le premier point intéressant pour nous est qu’il est possible d’effectué un mapping entre deux données. Dans notre cas, on souhaite mapper les coordonnées reçues avec celle de la source sonore dans MOSCA.
Dans Score, le mapping se fait entre une donnée d’un Device entrée et une donnée d’un Device en sortie. Ils nous faut donc créer deux Devices. Notre Device de sortie doit être lier à la source sonore dans MOSCA. Cette opération se réalise facilement en créant un OSC Device dans Score, et comme MOSCA envoie toutes ses données en messages OSC, le device de Score les récupère. On peut donc avec accès aux coordonnées de notre source sonore. On l’ajoute donc en sortie du mapping.
Il nous reste désormais à créer le Device d’entrée qui stocke les coordonnées de l’objet mobile. Nous avons opté donc pour un device client de websocket. Un script en javascript permet de créer l’arborescence du device, ici uniquement nécessaire de créer un attribut « coordinates », un vecteur à trois composantes. C’est cet attribut qui sera placé en entrée du mapping. Une fonction est aussi définie pour pouvoir recevoir le message envoyé par le serveur et le stocker dans « coordinates ». Le message envoyé doit respecté une syntaxe de type JSON, pour être correctement décodée.
Par exemple : ‘{« coordinates » : x, y, z}’
Tous les éléments sont présent pour lier l’objet mobile à la source sonore. Cependant, malgré que le serveur soit fonctionnel, que la communication s’effectue correctement, et que le message soit effectivement reçu par l’ordinateur client, nous pas été en mesure de l’obtenir sur Score. Cela a été la dernière barrière qui nous a empêcher de pouvoir effectuer un test complet du système
Construction de l’objet
Nous avons découpé grâce à l’imprimante laser de l’Eirlab une boite de 50x40x15cm^3 . Trois roues ont été ajoutées afin de faciliter le mouvement de notre objet.
Le dimensions ont été calculées afin de pouvoir mettre à l’intérieur :
- La Raspberry permettant le calcul de la position et l’envoie de la coordonnées de position
- La batterie et la carte permettant de plugger la batterie sur la Raspberry
- Les récepteurs à sonores
- Tout le câblage permettant d’interconnecter les éléments embarqués
Conclusion
Au terme de ces six séances de 3h et de plusieurs heures de travail personnel, nous sommes arrivés à terminer individuellement chaque partie. Cependant l’intégration n’a pas pu être réalisée, par faute de temps. Si toutes les parties sont fonctionnelles, elles peuvent être améliorées et affinées pour permettre au projet de mieux tourner.
Pour la partie de calcul de position, il peut être judicieux d’intégrer d’autres bibliothèques et d’autres méthodes de calculs afin d’accélérer le processus. Pour ce qui est de la partie réseau, le serveur et le client écrits en Javascript ne fonctionnent pas à 100%, il pourront donc être complétés par la suite. Enfin pour la spatialisation sonore des enceintes, on pourra veiller à automatiser le traitement des coordonnées, car à présent nous devons nous servir de l’interface graphique de Score pour faire fonctionner notre projet.
Il en vient enfin de soit que la voiture contenant tout l’embarqué du projet pourra être largement mieux designer et conçu en fonction des choix de chacun des composants utilisés. Car pour le moment nous n’utilisons que des éléments assez volumineux , qui pourrons être remplacés par d’autres technologies plus compactes et non surdimensionnées.
Lien GitHub du projet:
https://github.com/lgsnr/Culture_Maker