Robots siffleurs

Le projet du module Robots connectés 2016/2017 propose d'utiliser des robots holonomes (à roues suédoises) communiquant entre eux par des signaux acoustiques.
3 robots sont utilisés, un maître télécommandé par bluetooth via un dispositif Androïd, équipé d'un haut-parleur, et 2 esclaves équipés de microphones, qui suivent le robot maître grâce aux commandes sonores émises par ce dernier.

Robot Siffleur

Le scénario qui nous a été proposé consiste à réaliser trois robots holonomes. Le premier dit "Maître" communique et ordonne leur faits et gestes aux deux autres robots appelés "esclaves". La description de chacun d'eux est apporté ultérieurement.

Cahier des Charges

Description projet :

3 robots Holonomes :

Moteurs
Ponts en H
Carte microcontrôleurs moteurs (bas niveau) (Teensy3.2)
Carte microcontrôleurs logiciel(haut niveau) (Teensy3.2)

Communication inter robot : signal acoustique (note de musique)

Haut parleurs pour l'émission
Microphone pour la réception

Robot maitre télécommander par une application Androïd sur téléphone ou tablette via Bluetooth
2 robots esclaves : suivent les ordres du robot maitre (suivre, autre action)
Utilisation de l'AudioLibrary sur l'Audioboard Teensy

Schéma synoptique

Nous avons commencé par diviser le projet en trois premières parties : La première consistera en l'émission d'un signal sonore maitrisé, une autre en la réception et la compréhension de ce signal, et enfin une troisième qui consistera à gérer la liaison Bluetooth.

Partie 1 : Émission audio

Participants : Alix Barrière, Florian Courbon, Quentin Leroy, Florian Taillandier.

Notre Travail

Tout d'abord voici les documents permettant de reprendre ce projet là ou nous en étions :

Lien vers code du robot maître (HL) : https://drive.google.com/open?id=0B3RzegXT8aoXZUw0eEVwVGxYcU0

Lien vers code de notre robot esclave (HL) : https://drive.google.com/open?id=0B3RzegXT8aoXZGZBRW9zckNNYk0

Lien vers code de notre robot esclave (BL) : https://drive.google.com/open?id=0B3RzegXT8aoXdGt6c1kwcktOY0E

Lien vers notre présentation PowerPoint : https://drive.google.com/open?id=0B3RzegXT8aoXM1dPSnh4S0gyR3c

Cahier des charges de l'émission

Le but de la partie "émission" était de pouvoir envoyer une note de musique à l'instant ou le robot maître allait dans une direction (une note par direction). Pour cela nous avions 1 robot holonome 4 roues comme robot maître, 2 cartes Teensy : une pour gérer les moteurs et une pour gérer la gestion des notes de musique. Et pour finir un Haut-Parleur.

Nous devions réaliser une communication entre le robot maître et esclave par l'intermédiaire de ces notes. La commande du robot maître était faite par une application mobile Androïd réalisée par un autre groupe.

Génération d'un signal sonore

Afin de générer un signal audio, une note de musique nous avons commencé par utiliser un amplificateur audio : !!!! PHOTO AMPLI AUDIO !!!! Avec cet amplificateur il nous suffisait de créer un signal de forme sinusoïdale et de fréquence correspondant à une note de musique. On peut d'aider de ce tableau pour savoir quel est la fréquence des notes :

Il suffisait ensuite simplement d'ajouter un fil sur la broche correspondante à ce signal et relier l'amplificateur audio aux haut-parleurs.

Dans un second temps nous avons choisit d'arrêter l'utilisation de cette amplificateur au profit d'une audioboard, c'est une carte qui possède une liste de librairies et d'autres choses utile à la génération d'une note ou même à sa détection.

Voici la carte en question :

Avec cette carte nous avons pu mettre au point un code générant une note dont on pouvait modifier sa note, son octave, le volume ou elle était jouée, le temps qu'elle allait durer ainsi que le temps avant de jouer une autre note. Voici le code permettant de jouer une note :

Espionnage sur la liaison TX/RX

Afin de pouvoir envoyer une note de musique à l'instant ou nous faisions avancer le robot il fallait que la carte Bluetooth contenue sur le robot maître dialogue avec les deux cartes : celle qui gère les moteurs et celle qui gère la génération d'une note. Afin de faire cela nous avions plusieurs possibilités : La première était d'envoyer l'information de commande (ar, ag, av etc...) sur une des deux cartes Teensy, puis, via une liaison série, renvoyer cette information sur la deuxième carte. Le problème fut que nous n'avions pas assez de broches TX/RX sur nos cartes Teensy, due à l'audioboard et aux ponts en H. Pour résoudre ce problème nous avions deux choix : ajouter une troisième carte Teensy qui gère la distribution des données ou réaliser un espionnage de données.

Nous avons donc choisit l'espionnage de données pour des raisons de simplicités et d'économie d'une carte Teensy. Cet espionnage est très simple : la carte Bluetooth et la carte BL du robot communique via leurs ports TX/RX, et nous venons simplement faire un pont entre les ports RX des deux cartes Teensy (BL et HL) de notre robot maître. Comme ceci :

Choix des commandes associés

Une fois que nous étions capables de générer une note et de savoir a quel moment la jouer il fallait associer un ordre à chaque note. Nous avons choisit de faire au plus simple, c'est a dire autant de boucles "if" que de commande, voici notre code :

Pour le choix des notes nous avions tout d'abord opté pour des notes graves afin qu'elles soit agréables à l'oreille et reproductibles par un instrument, puis dans un second temps nous avons choisit d'augmenter les notes d'une octave, donc de doubler la fréquence de celles ci, afin de dépasser la fréquence des moteurs située entre 0 et 1200 Hz. Avec cette modification nous gardions des notes a peu près agréables et reproductibles par un instrument.

Voici un tableau des notes utilisés :

Création d'un Robot esclave pour test

Pour pouvoir caractériser correctement l'émission, on a décidé de réaliser en parallele au groupe Réception une autre solution de réception. C'est avec cette étude que l'on à déterminer les fréquences présentée plus haut pour avoir une influence sonore des moteurs moindre tout en évitant des aiguës trop pénible à l'oreille. De plus, ayant deux robots esclaves à notre disposition, cela n'a pas pénaliser l'autre groupe.

Réception d'une note

Recherchant des notes à des fréquences bien précise, un étude de maximas par FFT nous à permis d'avoir rapidement de bon résultat dans des situations sonore très favorable. En ajoutant par la suite une étude temporelle de ces maximas, on peut rejeter les bruits de forte intensité trop court ou trop long. En fixant le temps d'émission entre 100 et 600ms, on élimine les bruits de choc et continu. Malgré cette amélioration, le bruit des moteurs, étant pas parfaitement stable en fréquence, perturbe le détection. De plus notre robot esclave fait beaucoup plus de bruit que le second ce qui nous a amené à penser à des solutions physiques présentées plus bas.

Une dernière solution logiciel a été mise en oeuvre pour réduire les faux positifs. Il s'agit d'écouter le bruit ambiant, le mémoriser, puis le soustraire aux prochaines mesures. Pour que cela soit efficace, il ne faut pas envoyer d'ordre pendant cette première écoute et que les moteurs aient fini d'accélérer ou décélérer. C'est pendant les 500ms qui suivent un ordre, on ne prendra plus en comptes les maximas. Seul la commande "stop" est disponible pendant cette période. C'est à la fin de cette période que l'on réalise l'écoute du bruit ambiant.

Atténuation du bruit

Un problème majeur s’est posé à nous : le bruit des moteur était un bruit évolutif, situé entre 0 Hz et 1200 Hz, soit dans notre bande de travail. Nous avons alors choisit, en plus des traitements fait en software, de réduire le bruit physiquement. Le bruit se décompose en deux types : le bruit mécanique (vibrations répercutés jusqu'au micro) et le bruit acoustique (le bruit que fait le moteur).

Nous avons commencé par réduire le bruit acoustique en séparant le robot en deux parties : une partie haute et une basse. Puis nous avons ajoutés une plaque de polyester et une plaque de PVC entre ces deux parties comme ci dessous :

Puis dans un second temps nous avons surélevé le micro avec des entretoises et finalement avec un mât :

Enfin, pour finir nous avons tenté de réduire les vibrations par plusieurs moyens : le premier était de laisser le micro suspendu par des fils, puis nous avons ajouté deux entretoises séparés par un morceau de matière molle afin de faire une sorte d'amortisseur :

Cependant cette solution s'est avérée fonctionnelle mais inutile (due au mât).

Partie 2 : Réception audio

Participants : Aiman Ben Sallam, Hamza Bourachdi, Soukaina Mkhairi, Anass Rahhal.

Principe de fonctionnement

Acquisition du son et analyse fréquentielle
Différenciation des fréquences
Association d'une action à chaque fréquence
Transmission des données entre les cartes bas-niveau et haut-niveau
Le programme de la carte bas-niveau est modifié en fonction des besoins de mouvement du robot

Scénario Commande des robots

Lien vers le code : https://drive.google.com/open?id=0B3Ivyh2VygOybkNEWTZydnpnSXM

Nous avons utilisé le code fourni par M. Minon pour commander les moteurs avec une Teensy dédiée. Le code nécessitait quelques modifications au niveau de la vitesse des moteurs et le temps d’asservissement. Nous étions capable d’établir une liaison série et de commencer à tester les commandes vocales dans un environnement sans perturbations. Les notes étaient générées par le logiciel Audacity, la détection était quasi-parfaite sur une distance de 50cm. Le seul problème rencontré était par rapport aux déplacements à gauche et à droite. La formule utilisée par M. Minon générait un décalage qui s’amplifiait rapidement en une déviation très importante lors d’un déplacement à droite ou à gauche. Considérant que c’était une formule mathématique (la somme des vecteurs de vitesses des trois roues), nous avons conclu que le problème provenait d’une différence entre les valeurs de vitesses calculées des moteurs et les valeurs réelles, et peut-être aussi d’une différence entre les vitesses des trois moteurs. La solution à laquelle nous avons pensé était la suivante. Par exemple les étapes à suivre pour déplacer le robot à droite :

a. Tourner le robot de 90° à droite

b. Se déplacer à l’aide de 2 roues en ligne droite

c. S’arrêter et tourner 90° à gauche (pour avoir la même orientation qu’au départ)

Pour résoudre le problème de l'interférence du bruit des moteurs avec la commande sonore, le robot émet la commande avant de se mettre à bouger, et envoie la commande après l'arrêt des moteurs.

L’objectif était atteint, nous étions capables de générer tous les déplacements du robot maître pour pouvoir les copier plus tard.

Communication série entre les deux Teensy

Relier les Tx et Rx
Adapter le Baudrate
Envoyer les commandes suivant la fréquence détectée de la carte haut-niveau vers la carte bas-niveau

Solution I : Analyse Fréquentielle

Le développement du code arduino se fait via une plateforme web, qui permet de configurer les modules audio graphiquement, puis de générer le code : https://www.pjrc.com/teensy/gui/index.html

Lien vers le code : https://drive.google.com/open?id=0B3Ivyh2VygOyQjFrdUQtS3VxeUE

Cette méthode se base sur le code FFT de la librairie Audio des développeurs de la Teensy AudopShield. Cet exemple permet de calculer la Transformée de Fourier Rapide ( Fast Fourier Transform - FFT) pour une gamme de fréquence allant de 0Hz à +2 KHz. Elle permet une grande rapidité de calcul et une grande sensibilité, en effet même les fréquences à très faible puissance génèrent une perturbation. Par contre sa faible résolution ( colonnes multiples de 43 Hz ) complique la détection des notes de a même octave.

L'analyse de ses résultats nous a permis de conclure que les notes générées pratiquement par l'équipe de l'émission correspondaient effectivement aux fréquences théoriques souhaitées.

Dans un premier temps nous avons choisi de travailler en hautes fréquences (+ 1.5K Hz) pour s’éloigner le maximum des « fréquences sonores humaines ». Les résultats obtenus étaient bons, mais le problème soulevé par les profs était qu’avec ces fréquences, commander le robot avec un vrai instrument de musique aurait été quasi-impossible. Nous avons décidé alors de revenir aux basses fréquences et d’essayer de trouver une caractéristique qui pouvait nous permettre de différencier la puissance générée par le bruit de celle générée par les notes de musiques.

Solution II : Analyse Fréquentielle et intégration temporelle

Lien vers le code : https://drive.google.com/open?id=0B9qqwhvMbb6TVWRpQ1ZES1dDWkU

Au lieu de décider si la fréquence souhaitée est présente sur le signal en se basant sur un seul résultat de la FFT, nous avons décidé de faire des calculs sur 200ms et d’analyser les nouvelles valeurs obtenues. Ceci nous a permis d’augmenter significativement la différence entre un bruit (de volume normal) et les notes de musique générées. Le travail à faire en suite était d’optimiser le seuil de détection pour s’affranchir même de la problématique du bruit de haut volume. Nous nous sommes concentrés sur les tests réels de la solution. Parmi les tests effectués :

a. Test bruit ambiant, même volume et distance variable : Pour un volume du haut-parleur constant, on arrivait à détecter les notes jusqu’à un mètre de distance en laissant le seuil de détection très haut. Pour pouvoir s’éloigner encore plus, nous étions obligé de réduire le seuil, du coup avoir plus d’interférence du bruit ambiant.

b. Test bruit ambiant, même distance et volume variable : Même effet que la variation de distance.

c. Test avec bruit des moteurs continu : La perturbation est forte, le seuil devait être grand pour rester au-dessus des niveaux générés par les moteurs. Le haut-parleur doit être proche du micro, sinon le volume doit être grand. Quelques fréquences donnaient de bons résultats et d’autres non.

d. Test avec du bruit humain : Les sifflements et cris généraient des perturbations sur toute la gamme de fréquences, c’était encore pire que le bruit des moteurs.

Puisque le travail qui restait à ce moment était juste un travail de réglage de seuil (ou de découverte d’une méthode plus robuste), nous avons décidé de se pencher sur l’autre élément de la réception audio : la commande des moteurs.

Test et comparaison des différentes méthodes de l'analyse audio

Depuis le début du projet, nous avons utilisé la FFT pour différencier les fréquences du signal audio et détecter les notes de musiques quand elles étaient générées. La méthode donnait de bons résultats, mais même avec les différents réglages effectués, un plafond de détection était atteint et nous ne pouvions plus faire mieux. M. Bru nous a demandé d’essayer la fonction « notefreq », une des fonctions prédéfinies par les développeurs de la bibliothèque audio de la Teensy. Nous avons décidé donc de tester, pas seulement « notefreq », mais la majorité des autres fonctions d’analyse fournies par la bibliothèque.

a. Fonction « peak » : Pas d’utilité dans le cas d’un seul micro, mais peut être utilisable dans le cas de deux micros pour voir lequel des deux est plus proche de la source. Le problème majeur était que pour un signal de volume normal, la valeur retournée pouvait facilement atteindre la valeur de saturation (1).

b. Fonction « fft256 » : Même performance que la fft1024 utilisée auparavant dans certains cas. L’inconvénient est que la résolution est beaucoup plus basse (172 Hz), donc d’un côté nous devions utiliser des fréquences bien éloignées, et qui doivent correspondre aux fréquences de calculs. Quelques fréquences de calcul : 0Hz, 172Hz, 344Hz, 516Hz. Essayer de détecter la fréquence 250Hz n’obligeait à lire la valeur soit à 172 Hz soit à 344 Hz, chose non pratique avec du bruit parce que la puissance était très atténué à +/- 50 Hz de la fréquence générée. Plus de contraintes sans intérêts.

c. Fonction « notefreq » : Cette fonction nous permettait de détecter la fréquence fondamental du signal. Or le problème rencontré n’était pas un problème de détection, surtout que les fréquences générées avaient une et une seule fréquence chacune, pas d’harmoniques. Dans le cas d’une perturbation humaine, la fonction ne pouvait pas faire la différence entre la note et le sifflement humain qui s’étalait sur plusieurs fréquences. Nous n’avons pas pu penser à une méthode qui pouvait nous permettre de rendre cette fonction plus exploitable.

d. Fonction « tone » : Cette fonction n’avait pas présenté un grand intérêt au début, surtout que les valeurs des amplitudes atteignaient rapidement la valeur de saturation égale à 1. Heureusement, nous avons essayé de voir sur internet l’état d’art des méthodes utilisées pour la différenciation des fréquences audio. L’article Wikipédia « Spectral density » nous a inspiré à travailler avec les amplitudes au lieu de la FFT.

Solution Finale : Analyse de l'amplitude

Lien vers le code : https://drive.google.com/open?id=0B3Ivyh2VygOySGV4Q095dkJid1E

Cette méthode est inspirée par la densité spectrale d'un signal, nous calculons l'énergie de chaque fréquence et la comparons avec un seuil déterminé empiriquement.

Nous avons utilisé le code Tone pour réaliser une analyse des amplitudes, le premier avantage de cette méthode était la possibilité de choisir les fréquences que nous souhaitions détecter. La FFT avait une résolution de 43Hz, problème résolu avec la fonction « tone ». Nous avons modifié rapidement le code utilisé pour la FFT, donc nous avons conservé l’intégration des calculs sur 200ms. Nous avons testé la méthode pour voir quelles sont les valeurs générées et ainsi pouvoir choisir un seuil adapté. Nous avons remarqué que la méthode ne permettait pas d’éliminer à 100% les effets du bruit, mais elle donnait des résultats un tout petit peu meilleur que la FFT ! Peut-être c’était juste question de réglage ! Nous n’étions pas capable de comparer les deux méthodes face à face dans des conditions de bruit réelles, mais l’essentiel est que notre robot était capable de suivre 95% des commandes du robot maître, et une fois perturbé par un sifflement ou un cri, le robot était très heureux de pouvoir exécuter sa danse.

L'énergie du signal à une certaine fréquence est la valeur de l'amplitude de cette fréquence au carré.

Nous calculons la somme de la valeur actuelle et la valeur précédente car le calcul se fait sur 200ms. Donc on garde les valeurs précédentes pour 200ms et on les incrémente à chaque calcul. Elles sont remises à 0 dans la dernière partie du void loop().

Calcul de la densité spectrale de l'énergie des fréquences recherchées :

L'énergie du signal à une certaine fréquence est la valeur de l'amplitude de cette fréquence au carré, nous calculons donc la valeur actuelle et la valeur précédente puisque le calcul se fait sur 200 ms. Nous gardons alors les valeurs précédentes pour 200ms et nous les incrémentons à chaque calcul. Elles sont remises à 0 dans la dernière partie du void loop().

Nous recherchons l'indice du max des amplitudes des fréquences recherchées en utilisant la fonction GetIndexOfMax qui recherche l'indic de la plus grande valeur d'un tableau.

La fonction is present retourne un 1 quand la note recherchée est détectée. Exemple : Pour 3 notes [n1, n2, n3] le tableau isPresent prendra pour chaque note soit la valeur 0 soit 1 selon le résultat du calcul de l'amplitude, par exemple isPrensent=[0,1,0] veut dire que seule la note n2 a été détectée. Une note est détectée si la valeur de l'amplitude sur l'intervalle de calcul dépasse un seule que nous fixons empiriquement.

Nous commençons par voir si la fréquence de la danse est présente, pour qu'elle soit prioritaire par rapport à des perturbations externes comme une personne qui crie ou siffle.

Optimisation : Suivi avec la méthode des deux micros

Une amélioration possible du robot esclave est ajouter un autre micro, pour simuler le fonctionnement d'oreilles humaines pour détecter la position du robot maître. Le robot en comparant la puissance du signal reçu par les deux micros peut retrouver le robot maître et le rejoindre pour ajouter une fonction suivi de mouvement qui complète la copie du mouvement par commande vocale.

Partie 3 : Liaison Bluetooth-Teensy

Participants : Louis Berger, Romain Chiesa, Julien Desvignes.

code android

Le principe du code de déplacement est simple. L'application envoie un ordre sous forme d'une chaine de 2 caractères qui indique au robot récepteur (robot maitre) la direction à suivre. Il envoie un signal d'ordre pour commencer l'action, et un signal de stop lorsque l'utilisateur relache le bouton pour arrêter l'action. Ci-après la liste des ordres: st : signal stop av : avancer ar : reculer dr : droite ga : gauche rd : rotation horaire rg : rotation trigonométrique ad : diagonale avant droite ag : diagonale avant gauche bd : diagonale arrière droite bg : diagonale arrière gauche

Nous avons commencé par une interface simplifiée avec seulement les boutons de commande de base. L'application fonctionnait sous Android 4.1

Cependant, certains de nos appareil ne supportait pas la version 4.1. Nous sommes donc passé à Android 4.0.3. Nous avons aussi ajouté un bouton générant seulement le son stop. Enfin, nous avons ajouter 7 boutons correspondant aux notes de musique, si l'utilisateur veut composer sa mélodie et voir comment réagisse les robots esclaves. les ordres ajoutés sont: ut : do re : ré mi : mi fa : fa so : sol la : la si : si

Enfin, une troisième interface plus fonctionnelle a été créée, pour simplifier les déplacements diagonaux (il fallait auparavant appuyer sur deux touches en même temps) Le mode 'danse' permet d'envoyer d'autres ordre, dans une gamme plus aigue, afin de faire réagir les robots esclaves différemment les ordre du mode danse sont: za : avancer zb : reculer zd : droite zg : gauche xd : rotation droite xg : rotation gauche

Malheureusement, nous n'avons pas pu implémenter une commande sur tous ces ordres faute de temps.

Ci-après un diagramme représentant les différents message de connexion au récepteur bluetooth RNBT-3F1D:

Initialement déconnecté, lors de l'appuie sur la touche 'connect', le smartphone va regarder si le bluetooth est allumé et l'activé si non. Puis il va regarder si il est appairé au module et si il est détecté. Le message d'erreur violet s'affichera si non. Enfin, une fois connecté, on verra l'adresse MAC du récepteur appairé (le programme s'appaire grâce à son nom: RNBT-3F1D, et récupère l'adresse mac du module auquel il s'est appairé). Si plusieurs module RNBT-3F1D sont à proximité, l'adresse MAC nous permettra de voir auquel le smartphone s'est associé. L'utilisateur n'a plus qu'à envoyé ses ordres.

Ci-après le schéma récapitulatif des étapes de connexion et d'envoie de données:

On commence par ajouter l'objet "bluetooth" pour pouvoir interagir avec lui par la suite. Bluetooth adapter nous permet de voir si le bluetooth est activé.

Ensuite on initialise la connexion en affichant un message de connexion. Une fois que la carte à trouvé un appareil auquel se connecter, il l'indique en sortant un message "connected". En cas de problème ou si on ne trouve pas d'appareil, on affichera alors "unable to connect" en spécifiant le problème lorsque le bluetooth n'est pas activé.

Bibliographie

Des ultrasons pour pister les téléphones