Robots siffleurs - Historique des versions

Eric : /* Solution I : Analyse Fréquentielle */

2021-03-11T15:48:34Z

‎Solution I : Analyse Fréquentielle

Mkhairi.Soukaina : /* Solution Finale : Analyse de l'amplitude */

2017-05-29T00:10:25Z

‎Solution Finale : Analyse de l'amplitude

Mkhairi.Soukaina : /* Partie 2 : Réception audio */

2017-05-29T00:10:01Z

‎Partie 2 : Réception audio

Berger : /* Partie 3 : Liaison Bluetooth-Teensy */

2017-05-28T23:27:45Z

‎Partie 3 : Liaison Bluetooth-Teensy

Berger : /* Partie 3 : Liaison Bluetooth-Teensy */

2017-05-28T23:13:15Z

‎Partie 3 : Liaison Bluetooth-Teensy

Berger le 28 mai 2017 à 22:31

2017-05-28T22:31:41Z

Mkhairi.Soukaina : /* Scénario Commande des robots */

2017-05-28T17:03:33Z

‎Scénario Commande des robots

Mkhairi.Soukaina : /* Partie 2 : Réception audio */

2017-05-28T16:38:56Z

‎Partie 2 : Réception audio

Mkhairi.Soukaina : n

2017-05-28T16:34:52Z

Mkhairi.Soukaina : /* Solution Finale : Analyse de l'amplitude */

2017-05-28T16:29:59Z

‎Solution Finale : Analyse de l'amplitude

← Version précédente		Version du 11 mars 2021 à 15:48
Ligne 170 :		Ligne 170 :

	===Solution I : Analyse Fréquentielle===		===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 <br />		'''Lien vers le code''' : https://drive.google.com/open?id=0B3Ivyh2VygOyQjFrdUQtS3VxeUE <br />

← Version précédente		Version du 29 mai 2017 à 00:10
Ligne 222 :		Ligne 222 :
	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. <br />		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. <br />

−	[[Fichier:Ampl.PNG]	+	[[Fichier:Ampl.PNG]]

@@ Ligne 170 : / Ligne 170 : @@
 ===Solution I : Analyse Fréquentielle===
 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. <br />
@@ Ligne 198 : / Ligne 200 : @@
-=== Solution III : Test et comparaison des différentes méthodes de l'analyse audio ===
+=== 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. <br />
@@ Ligne 218 : / Ligne 220 : @@
 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.<br />
-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.
+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. <br />
 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().<br />

@@ Ligne 297 : / Ligne 297 : @@
 Ci-après un diagramme représentant les différents message de connexion au récepteur bluetooth RNBT-3F1D:
-[[Fichier:Connexion.png|vignette]]
+[[Fichier:Connexion.PNG|vignette]]
 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.
@@ Ligne 305 : / Ligne 305 : @@
 Ci-après le schéma récapitulatif des étapes de connexion et d'envoie de données:
-[[Fichier:Principe.png|vignette]]
+[[Fichier:Principe.PNG|vignette]]

@@ Ligne 280 : / Ligne 280 : @@
 si : si
-[[Fichier:Interface2|vignette]]
+[[Fichier:Interface2.png|vignette]]
@@ Ligne 294 : / Ligne 294 : @@
 Malheureusement, nous n'avons pas pu implémenter une commande sur tous ces ordres faute de temps.
-[[Fichier:Interface3|vignette]]
+[[Fichier:Interface3.png|vignette]]
 Ci-après un diagramme représentant les différents message de connexion au récepteur bluetooth RNBT-3F1D:
-[[Fichier:Connexion|vignette]]
+[[Fichier:Connexion.png|vignette]]
 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.
@@ Ligne 305 : / Ligne 305 : @@
 Ci-après le schéma récapitulatif des étapes de connexion et d'envoie de données:
-[[Fichier:Principe|vignette]]
+[[Fichier:Principe.png|vignette]]

← Version précédente		Version du 28 mai 2017 à 22:31
Ligne 250 :		Ligne 250 :

	[https://drive.google.com/file/d/0B6-f6LPpeNc-em1tOHVfSVdCWVE/view?usp=sharing code android]		[https://drive.google.com/file/d/0B6-f6LPpeNc-em1tOHVfSVdCWVE/view?usp=sharing 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
		+	[[Fichier:Interface1.png\|vignette]]
		+
		+	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
		+
		+	[[Fichier:Interface2\|vignette]]
		+
		+
		+	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.
		+	[[Fichier:Interface3\|vignette]]
		+
		+	Ci-après un diagramme représentant les différents message de connexion au récepteur bluetooth RNBT-3F1D:
		+	[[Fichier:Connexion\|vignette]]
		+
		+	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:
		+	[[Fichier:Principe\|vignette]]
		+
		+
		+

	On commence par ajouter l'objet "bluetooth" pour pouvoir interagir avec lui par la suite.		On commence par ajouter l'objet "bluetooth" pour pouvoir interagir avec lui par la suite.

@@ Ligne 145 : / Ligne 145 : @@
 === Scénario Commande des robots ===
 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 : <br />
@@ Ligne 158 : / Ligne 161 : @@
 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. <br />
 ===Communication série entre les deux Teensy===

@@ Ligne 170 : / Ligne 170 : @@
 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. <br />
 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.<br />
 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.  <br />
@@ Ligne 185 : / Ligne 181 : @@
 === Solution II : Analyse Fréquentielle et intégration temporelle ===
-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 : <br /><br />
+'''Lien vers le code''' : https://drive.google.com/open?id=0B9qqwhvMbb6TVWRpQ1ZES1dDWkU <br />
 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. <br />
@@ Ligne 198 : / Ligne 195 : @@
 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. <br />
 === Solution III : Test et comparaison des différentes méthodes de l'analyse audio ===
@@ Ligne 217 : / Ligne 212 : @@
 === Solution Finale : Analyse de l'amplitude===
-Lien vers le code : https://drive.google.com/open?id=0B3Ivyh2VygOySGV4Q095dkJid1E<br />
+'''Lien vers le code''' : https://drive.google.com/open?id=0B3Ivyh2VygOySGV4Q095dkJid1E<br />
 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.<br />

@@ Ligne 211 : / Ligne 211 : @@
 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.<br />
 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().<br />
@@ Ligne 229 : / Ligne 233 : @@
 [[Fichier:Code3.PNG]]
 === Optimisation : Suivi avec la méthode des deux micros ===