IMA5 2019/2020 P24 - Historique des versions

Pfrison le 21 février 2020 à 07:21

2020-02-21T07:21:42Z

Pfrison le 19 février 2020 à 08:30

2020-02-19T08:30:39Z

Pfrison : /* Semaines 15 & 16 */

2020-02-19T08:02:25Z

‎Semaines 15 & 16

Pfrison : /* Semaine 14 */

2020-01-22T23:51:47Z

‎Semaine 14

Pfrison : /* Semaine 13 */

2020-01-15T18:54:44Z

‎Semaine 13

Pfrison le 17 décembre 2019 à 21:49

2019-12-17T21:49:12Z

Pfrison : /* Documents Rendus */

2019-12-17T00:43:06Z

‎Documents Rendus

Pfrison le 17 décembre 2019 à 00:42

2019-12-17T00:42:00Z

Pfrison : /* Semaine 13 */

2019-12-16T22:21:16Z

‎Semaine 13

Pfrison : /* Semaine 13 */

2019-12-16T20:44:21Z

‎Semaine 13

@@ Ligne 10 : / Ligne 10 : @@
 * Présentation intermédiaire : [https://projets-ima.plil.fr/mediawiki/images/9/9c/IOT_Acoustic_Diapo_inter.pdf Format PDF]
 * Rapport final : [https://projets-ima.plil.fr/mediawiki/images/1/1e/IOT_Acoustic_Rapport_final_Pierre_Frison.pdf Format PDF]
 =Présentation générale=
@@ Ligne 392 : / Ligne 393 : @@
 * Présentation intermédiaire : [https://projets-ima.plil.fr/mediawiki/images/9/9c/IOT_Acoustic_Diapo_inter.pdf Format PDF]
 * Rapport final : [https://projets-ima.plil.fr/mediawiki/images/1/1e/IOT_Acoustic_Rapport_final_Pierre_Frison.pdf Format PDF]

@@ Ligne 9 : / Ligne 9 : @@
 * Rapport intermédiaire : [https://projets-ima.plil.fr/mediawiki/images/b/b1/IOT_Acoustic_Rapport_inter_Pierre_Frison.pdf Format PDF]
 * Présentation intermédiaire : [https://projets-ima.plil.fr/mediawiki/images/9/9c/IOT_Acoustic_Diapo_inter.pdf Format PDF]
 =Présentation générale=
@@ Ligne 390 : / Ligne 391 : @@
 * Rapport intermédiaire : [https://projets-ima.plil.fr/mediawiki/images/b/b1/IOT_Acoustic_Rapport_inter_Pierre_Frison.pdf Format PDF]
 * Présentation intermédiaire : [https://projets-ima.plil.fr/mediawiki/images/9/9c/IOT_Acoustic_Diapo_inter.pdf Format PDF]

← Version précédente		Version du 19 février 2020 à 08:02
Ligne 282 :		Ligne 282 :

	On remarque une efficacité maximale vers 2000Hz.		On remarque une efficacité maximale vers 2000Hz.
		+
		+	==Semaine 17==
		+
		+	La suite du projet se concentrera sur l'automatisation de la classification. 3 options ont été étudié :
		+	* Réaliser un logiciel de traitement d’images (spectrogrammes) pour faciliter la caractérisation par un humain.
		+	* Utiliser une réduction par l’analyse en composantes principales (PCA) et une classification avec des machines à vecteurs de support (SVM ou SVC).
		+	* Utiliser une architecture par réseau de neurones artificiels capable de différencier les spectrogrammes.
		+
		+	La première solution semble à la fois coûteuse en temps à mettre en place et peu efficace comparé aux autres solutions. Quant à la dernière solution, elle demande un nombre important de mesure (et donc de temps) pour l’entrainement du réseau de neurone. C’est donc la seconde solution qui sera testé pour ce projet.
		+
		+	Pour réaliser une telle analyse, il faut d'abord avoir des données et les classifier à la main. Pour augmenté mes chances de succès, je me suis placé dans le cas où on se sert d'un chargeur USB pour produire du son. J'ai donc enregistré et classifié 87 fichiers audio en 8 catégories : 2 téléphones effectuant chacun 4 opérations différentes (attendre / ne rien faire, incrémenter une variable, multiplier 2*2, tester si 1==1).
		+
		+	==Semaine 18==
		+
		+	Avant de commencer la programmation, il m'a fallu en apprendre plus sur la PCA et la SVM. Voici un résumé de mes connaissances.
		+
		+	De manière générale, l’analyse en composantes principales (aussi appelé PCA qui est son acronyme en anglais) cherche à transformer une grande quantité de données en un tableau de vecteur (un vecteur par donnée) dont la dimension est choisie. Un tableau à deux dimensions (matrice, ou "tableau de tableau") est fourni à la PCA qui va chercher à approximer cette matrice en une multiplication de deux matrices.
		+
		+	La première matrice représente une liste de vecteur : chaque tableau dans le tableau de tableau en entrée de la PCA va être assimilé à un vecteur. C’est ce vecteur qui nous intéresse. La seconde matrice est un tableau des vecteurs propres du jeu de données, en d’autres termes : si on multiplie ce tableau de vecteur propres à un vecteur correspondant à une donnée, on retrouve (presque, car c’est une approximation) la donnée. Ces vecteurs propres sont appelés eigenvalues.
		+
		+	Une donnée est la somme de son vecteur associé multiplié par les vecteurs propres (commun à toutes les données). Au final, la donnée est assimilé à son vecteur, ce qui permet de simplifier le jeu de donnée (passage de données à n valeurs à un vecteur de p valeurs, en choisissant p<n). Dans le cas d’images, notre jeu de donnée est en trois dimensions (hauteur, largeur, nombre d’images). Pour réaliser la transformation, il suffit de transformer chaque image en une liste unidimensionnelle. Cela est possible en mettant bout-à-bout les lignes de pixels. En choisissant un nombre de composante relativement bas (4 par exemple), on réduit donc considérablement la quantité de données à traiter : en assimile une image de largeur*hauteur valeurs à 4 valeurs (dans notre l’exemple).
		+
		+	Une fois la PCA réalisée, nous avons notre jeu de données réduit à des vecteurs (des coordonnées en d’autres termes). Puisque, plus les images sont similaires, plus les coordonnées seront proches, il est possible de laisser un ordinateur faire le regroupement de ces points : c’est le but d’une SVM (aussi appelé SVC).
		+
		+	Après avoir associé chaque point à un groupe (ce travail est fait grâce à un humain à postériori), on choisit un kernel (ou méthode de calcul) et la SVM va déterminer des zones qui correspondent à chaque groupe. Lorsqu’une donnée nouvelle (qui n’était pas présente dans le jeu de donnée initial) va être transformée par la PCA, les coordonnées de son vecteur vont être comparées et la SVM va attribuer à cette donnée un groupe. Idéalement, le groupe attribué est le même que celui qu’un humain lui aurait donnée.
		+
		+	On appelle la phase où les données traitées par la PCA et la SVM sont des données classifié par un humain, la phase d’apprentissage. La phase de prédiction est le traitement de nouvelles données, la PCA+SVM doit retourner sa prédiction. Pour que cette phase de prédiction soit suffisamment précise, il faut une grande quantité de données lors de la phase d’apprentissage.
		+
		+	==Semaines 19 & 20==
		+
		+	[[Fichier:IOT_Acoustic_PCA_SVM_Comp.png\|800px\|thumb\|left\|Résultats du programme avec la PCA seule et différentes méthodes pour la SVM]]
		+
		+	Après les recherches sur la PCA et SVM (qui se sont continués pendant ces deux semaines), il est temps de créer le programme pour classifier automatiquement nos données. Tout d'abord, le programme qui génère les spectrogrammes a été retravaillé pour pouvoir être utilisé comme librairie.
		+
		+	Le programme créé prend en entrée une liste de dossier (un dossier est traité comme un groupe). Il repère les fichiers audio dans les dossiers, créé les spectrogrammes (à l’aide de la librairie des spectrogrammes et de l’annulation du bruit), puis entraine une PCA et une SVM en faisant correspondre chaque spectrogramme venant du même dossier au même groupe. Par faute de temps la PCA et la SVM qui en résulte ne sont pas sauvegardé. Ce sont les sorties de notre programme.
		+
		+	L'image ci-contre montre la PCA sans SVM et avec SVM avec plusieurs méthodes, ce qui permet de les comparer. On observe que peu importe la SVM, les groupes sont suffisamment bien détourés pour réaliser des prédictions correctes. Augmenter le nombre de données d’entrainement pourrait permettre de voir des différences plus amples entre les différentes SVM. Pour l’instant le choix le plus adapté pour cet expérience est la méthode linéaire car plus rapide à calculer.
		+
		+	<div style="clear: left;"></div>
		+
		+	=Annuaire des programmes et leur utilisation=
		+
		+	==Enregistrement audio==
		+
		+	Nommé record.py, il permet d’enregistrer du son. Les variables au début du programme permettent de régler :
		+	* CHUCK : La taille du buffer pour la lecture du flux de données audio.
		+	* CHANNELS : Le nombre de canaux audio (1 mono, 2 stéréo, etc.).
		+	* RATE : L’échantillonnage audio.
		+	* TIME : Le temps d’enregistrement.
		+
		+	À la fin de l’enregistrement, le programme écrit dans un fichier situé à "./sounds/recordOutput.wav". Il faut donc penser à copier le fichier audio avant une nouvelle mesure. Ce programme a besoin de pyaudio pour fonctionner.
		+
		+	==Génération de spectrogramme et annulation du bruit==
		+
		+	Ce programme, nommé customSpectrogram.py, s’occupe de générer les spectrogrammes et, si un nom de fichier lui est donné, l’analyse et l’annulation du bruit. Ce script est utilisation depuis un autre programme python comme une librairie. Les fonctions principales sont les suivantes :
		+	* getSpectrogramFromFiles : Retourne un spectrogramme. Elle prend en entrée :
		+	** mainFile, le chemin du fichier à analyser.
		+	** noiseFile (optionnel, défaut None), le chemin du fichier de bruit.
		+	** minFreq (optionnel, défaut None), la borde inférieur de fréquence du spectrogramme.
		+	** maxFreq (optionnel, défaut None), la borde supérieur de fréquence du spectrogramme.
		+	** dB (optionnel, défaut False), booléen pour la transformation du spectrogramme en décibel.
		+	** temporalDivider (optionnel, défaut 500), nombre de découpe dans le fichier audio.
		+	** overlaping (optionnel, défaut 5), nombre de FFT qui s’entrelace.
		+	* getSpectrogramFromSamples : Retourne un spectrogramme. Elle prend les mêmes paramètres que getSpectrogramFromFiles mais à la place des chemins de fichiers, elle accepte des tableaux d’échantillons et demande un temps d’échantillonnage (sampleRate). On peut utiliser les fonctions loadFile et loadFiles pour obtenir les échantillons à partir d’un chemin de fichier.
		+
		+	La relation avec temporalDivider et overlaping est la suivante : plus le temporalDivider est haut, plus le fichier sera découpé et donc moins il y aura de point en fréquence. Mais moins temporalDivider est haut, moins les FFT traduisent "l’instant" mais traduisent un temps plus large : on a moins de points en temps. Pour avoir une représentation plus instantanée du signal tout en gardant un nombre de point en fréquence suffisant, overlaping permet d’entrelacer (moyenner) plusieurs "longues" FFT. Grâce à overlaping, on a plus de points en temps pour un même temporalDivider.
		+
		+	Les spectrogrammes sont des tableaux de flottants à deux dimensions dont les dimensions sont les suivantes : [Temps,Fréquence]=[temporalDivider * overlaping,n_échantillons / temporalDivider]. Les valeurs des flottants dans les spectrogrammes vont de 0 à 1 dans le cas linéaire (dB = False) et de 0 à –infini dans le cas décibel (dB = True).
		+
		+	Ce programme a besoin de numpy, scipy et de matplotlib (si utilisé en tant que programme principal) pour fonctionner.
		+
		+	==Caractérisation en fréquence de la boite==
		+
		+	Deux programmes réalisent cette fonction. Le premier nommé boxFrequenciesAnalysis.py construit et joue un son sinusoïdal augmentant progressivement en fréquence (par palier). Le second, analyse deux enregistrement audio et en déduit, fréquence par fréquence, la différence de puissance acoustique entre les deux signaux.
		+
		+	Ces programmes ont besoin de numpy, scipy et de matplotlib pour fonctionner.
		+
		+	==Classification automatique par PCA et SVM==
		+
		+	Un seul programme régit cette fonction : PCA.py. Les paramètres sont disponibles au début du programme et sont les suivants :
		+	* temporalDivider : Voir la documentation sur la génération des spectrogrammes.
		+	* overlaping : Voir la documentation sur la génération des spectrogrammes.
		+	* takeAPeekAtSpectrogram : Afficher le premier spectrogramme pour vérifier.
		+	* nComponents : Nombre de composantes de la PCA.
		+	* meshgridPrecision : Précision de la grille qui dessine les zones de la SVM.
		+	* SVCKernel : Choix du kernel (méthode) pour la SVM (valeur possible : linear, poly, rbf ou sigmoid).
		+	* figureName : Nom de la figure matplotlib.
		+	* filesFolders : Liste des dossiers à fouiller pour trouver les fichiers audio. Un fichier sera traité comme un groupe pour la SVM.
		+	* noiseFile : Fichier audio du bruit pour l’annulation du bruit.
		+
		+	Les fichiers audio doivent avoir la même fréquence d’échantillonnage pour être comparés. Une fois les fichiers audio chargés, le programme cherche le fichier le plus court et réduit la taille des autres fichiers (par rapport à leur centre), il faut donc veiller à ne pas mettre de fichier trop courts par rapport aux autres. Ce programme a besoin de numpy, sklearn, matplotlib, et de customSpectrogram pour fonctionner.
		+
		+	==Application Android==
		+
		+	L’application Android a été réalisée avec Android Studio. Le code source est disponible dans le dossier Android à la racine du projet git, il est écrit en Java (partie dynamique : code exécutable) et en XML (partie statique : graphique et mise en page). Il sert à donner des opérations à faire exécuter au téléphone de manière périodique.
		+
		+	L’application ne comprend qu’une page (activity) comprenant des boutons généré dynamiquement. Le programme comporte deux classes :
		+	* MainActivity.java : Le "point d’entrée" du programme. Génère la page et les boutons en fonction de la liste des opérations nommé LOOPS dans la classe Loop.java. C’est cette classe qui lance ou stoppe le calcul lors de l’appui d’un bouton par l’intermédiaire d’un Runnable et d’un Handler (utilisé pour relancer le calcul à l’infini sans bloquer le thread principal pendant l’attente).
		+	* Loop.java : La classe hôte de l’objet Loop. Cet objet permet de normaliser le concept d’opération à effectuer (symbolisé par un String nom et d’un Runnable code). Cette classe est aussi l’hôte de la liste des opérations possible dans le tableau LOOPS qui initialise des objets Loop. Lorsque la méthode runCode d’un objet Loop est appelée, le Runnable est exécuté dans un objet DoInBackground dérivé de l’objet AsyncTask pour éviter de bloquer le thread principal avec le calcul.
		+
		+	L’application requière la version 19 de l’SDK Android (ou supérieur) pour fonctionner. Ce qui correspond à une version 4.4 d’Android. Il est peut-être possible, si besoin, de réduire la version minimale requise en changeant cette valeur dans le fichier app/build.gradle (il est possible que le code puisse avoir besoin d'être retravaillé pour correspondre à la nouvelle version).

	=Documents Rendus=		=Documents Rendus=

← Version précédente		Version du 22 janvier 2020 à 23:51
Ligne 272 :		Ligne 272 :

	En contrepartie, le temps de traitement est doublé à cause de l'analyse du bruit.		En contrepartie, le temps de traitement est doublé à cause de l'analyse du bruit.
		+
		+	==Semaines 15 & 16==
		+
		+	[[Fichier:IOT_Acoustic_boite_analysis.PNG\|400px\|thumb\|right\|Caractérisation, en fréquence, de la réduction de bruit par la boite (échelle logarithmique)]]
		+
		+	Pour affiner la mesure effectué [[#Semaine_10_.26_11\|les semaines 10 & 11]] sur la qualité de l'isolation de la boite acoustique, j'ai fait des mesures avec un haut-parleur pour observer l’atténuation du son par la boite sur la plage de fréquence audible.
		+
		+	Les haut-parleurs ont été placés à une centaine de centimètres de la boite et le micro (un cas dans la boite et un autre à l’extérieur) placé vers les haut-parleurs. Un script Python génère un signal qui parcourt toutes les fréquences de l'audible (croissance logarithmique) toutes les 0.5 secondes (le ton du son est stable pendant 0.5 secondes pour permettre une analyse propre avec une fft). Une fois les deux fichiers son du micro découpés et synchronisés, un autre script repères les fréquences, l'intensité du son pour chaque cas, fait la soustraction (l'enregistrement du son à l'extérieur de la boite sert de calibration) et trace le graphique ci-contre.
		+
		+	On remarque une efficacité maximale vers 2000Hz.

	=Documents Rendus=		=Documents Rendus=

← Version précédente		Version du 15 janvier 2020 à 18:54
Ligne 255 :		Ligne 255 :

	<div style="clear: left;"></div>		<div style="clear: left;"></div>
		+
		+	==Semaine 14==
		+
		+	[[Fichier:IOT_Acoustic_Annulation_bruit.png\|400px\|thumb\|left\|Démonstration de l'annulation du bruit]]
		+
		+	Cette semaine a été consacrée à la réalisation d'un annulateur de bruit. À partir d'un fichier enregistrant le bruit (mesure à vide dans la boite) et du ficher de mesure, le script va créer le modèle du bruit et le soustraire à la mesure.
		+
		+	Pour créer le modèle de bruit, on fait la moyenne des ffts sur l'ensemble du bruit (il faut que le nombre d'échantillons par fft soit le même que celui qui sera utilisé pour faire le spectrogramme du fichier principal, pour avoir le même nombre de points (fréquences) dans notre fft de bruit, et donc pouvoir faire les soustractions). On obtient donc une fft représentative du bruit que l'on va soustraire à chaque fft lorsque nous allons faire le spectrogramme du fichier de mesure.
		+
		+	La figure ci-contre montre :
		+	* à gauche : le bruit mesuré
		+	* au milieu : les mesures sans annulation de bruit (en haut : le bruit du chargeur USB, en bas : le bruit de la carte stm32f769i-disco)
		+	* à droite : les mesures avec annulation de bruit (en haut : le bruit du chargeur USB, en bas : le bruit de la carte stm32f769i-disco)
		+
		+	On note une très nette amélioration notamment pour la suppression d'une fréquence parasite à ~64kHz. Les parties basses et moyennes fréquences sont elles aussi améliorées et sont devenues plus contrastées.
		+
		+	En contrepartie, le temps de traitement est doublé à cause de l'analyse du bruit.

	=Documents Rendus=		=Documents Rendus=

@@ Ligne 8 : / Ligne 8 : @@
 * Projet Git : https://archives.plil.fr/pfrison/IOT_Acoustic
 * Rapport intermédiaire : [https://projets-ima.plil.fr/mediawiki/images/b/b1/IOT_Acoustic_Rapport_inter_Pierre_Frison.pdf Format PDF]
 =Présentation générale=
@@ Ligne 260 : / Ligne 261 : @@
 * Projet Git : https://archives.plil.fr/pfrison/IOT_Acoustic
 * Rapport intermédiaire : [https://projets-ima.plil.fr/mediawiki/images/b/b1/IOT_Acoustic_Rapport_inter_Pierre_Frison.pdf Format PDF]

← Version précédente		Version du 17 décembre 2019 à 00:43
Ligne 256 :		Ligne 256 :

	=Documents Rendus=		=Documents Rendus=
		+
		+	Liste des documents et ressources rendus :
		+	* Projet Git : https://archives.plil.fr/pfrison/IOT_Acoustic
		+	* Rapport intermédiaire : [https://projets-ima.plil.fr/mediawiki/images/b/b1/IOT_Acoustic_Rapport_inter_Pierre_Frison.pdf Format PDF]

@@ Ligne 246 : / Ligne 246 : @@
 * Analyser un même appareil (la carte stm32f769i-disco) sous différentes activités.
-Pour comparer les deux microphones, 3 mesures par micro ont été réalisées : sans appareil, autre avec le chargeur USB seul, en collant le micro au haut-parleur de mon second téléphone (sans musique). On remarque alors sur les spectrogrammes que le micro 2 est moins sensible que le premier. On remarque aussi que le haut-parleur, même inactif, peut émettre du bruit. L'origine du bruit est inconnu mais on peut penser qu'il s'agit de la carte son qui capte des interférences électroniques et les amplifie vers le haut-parleur.
+Pour comparer les deux microphones, 3 mesures par micro ont été réalisées : sans appareil, autre avec le chargeur USB seul, en collant le micro au haut-parleur de mon second téléphone (sans musique). On remarque alors sur les spectrogrammes que le micro 2 est moins sensible que le premier. On remarque aussi que le haut-parleur, même inactif, peut émettre du bruit. L'origine du bruit est inconnue mais on peut penser qu'il s'agit de la carte son qui capte des interférences électroniques et les amplifie vers le haut-parleur.
 Pour la seconde expérience, la fréquence d'échantillonnage a été augmentée à 192 kHz (la limite imposée par la carte son). On remarque que même sans appareil, le micro enregistre un bruit de fréquence ~64 kHz qui est sûrement produite par l'électronique du microphone ou la carte son. Les autres spectrogrammes nous confirment que de reconnaître un appareil grâce à sa consommation électrique est possible avec la configuration actuelle.