Version actuelle datée du 21 février 2020 à 07:21

Caractérisation d’un objet IoT à partir de l’étude de l’émission sonore.

• Étudiant : Pierre FRISON
• Tuteurs école : Alexandre BOÉ et Thomas VANTROYS
• Tuteur entreprise : François BOUCHAUD
• Projet Git : https://archives.plil.fr/pfrison/IOT_Acoustic
• Rapport intermédiaire : Format PDF
• Présentation intermédiaire : Format PDF
• Rapport final : Format PDF
• Présentation finale : Format PDF

Présentation générale

Description

Identifier un objet connecté par l’analyse des signaux sonores engendrés par les composants électroniques. Déterminer l’activité et les opérations réalisées par le composant. Automatiser l’extraction du bruit et construire une base de données des signatures acoustiques des composants. Etudier la possibilité de classification.

Objectifs

Dans un premier temps, le projet consiste à aider à l'identification d'un appareil électronique grâce à l'analyse du son qu'il émet. Il y a aura une partie matériel pour les mesures acoustiques, et une partie logiciel comprenant l'analyse du signal, l'identification des paternes propres à l'appareil, et le renseignement dans une base de donnée. Dans un second temps, si la finesse des mesures le permet, nous nous attarderons sur une analyse plus en profondeur des signaux pour essayer de déchiffrer les opérations effectuées par l'appareil.

Préparation du projet

Cahier des charges

Côté matériel :

• Maximiser la plage de fréquence du microphone
• Privilégier la linéarité de la réponse en fréquence du microphone
• Minimiser le bruit du montage microphone + éléments d'amplification
• Trouver des coût raisonnables

Côté logiciel :

• Trouver des outils de traitement de signal pour identifier des caractéristiques propres à l'appareil
• Classifier ces caractéristiques et organiser un modèle pour une base de donnée
• Automatiser le processus de traitement de signal et d’identification

Choix techniques : matériel et logiciel

Actuelle liste de matériel :

Pour la qualité studio :

• Microphone de mesure : BEHRINGER ECM8000 ou PRESONUS PRM1
• Carte son (Amplificateur + alimentation fantôme 48V + échantillonneur) : STEINBERG UR12
• Câble XLR mâle / XMR femelle (symétrique) : BIRD INSTRUMENTS MC21 - XLR / XLR - 3M
• Câble USB B mâle / USB A mâle : (déjà en stock)

Pour la qualité prototype :

• Microphone : KEEG1538WB-100LB
• Amplificateur : LM386 (déjà en stock dans le magasin d'électronique)
• Une sortie jack 3.5 mm : lien Farnell
• Un câble jack double mâle 3.5 mm : lien Farnell
• Trois potentiomètres de 10 kOhm : (déjà en stock)
• Deux capacités de 250 nF : (déjà en stock)
• Une capacité de 0.05 nF : (déjà en stock)
• Une capacité de 10 uF : (déjà en stock)
• Une résistance de 2.2 kOhm : (déjà en stock)
• Une résistance de 10 Ohm : (déjà en stock)

Liste des tâches à effectuer

Le projet se découpe en trois points majeurs qui se suive chronologiquement :

• Trouver du matériel adapté
• Mesures et recherche de moyen de classifications
• Mise en place d'une base de donnée et automatisation du processus d'identification

Etat de l'art

Il m'a été remis un papier de recherche (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis) pour me présenter l'état de l'art dans le domaine des attaques par canal auxiliaire dans le domaine acoustique. Il a été analysé la première semaine.

Dans le papier de recherche, les auteurs ont mis en place plusieurs scénarios d'attaque qui ont pour but d'extraire une clé RSA en écoutant le son produit par un ordinateur (plusieurs marques ont été testées) lorsqu'il décrypte un message. L'extraction est possible dans tous les cas avec un montage digne d'un laboratoire et dans la plupart des cas avec un microphone de téléphone portable.

Leur méthode n'est pas d'écouter directement les opérations une à une pour en déduire la clé, c'est impossible à cause de la différence d'ordre de grandeur entre les opérations du processeur (quelques GHz) et la plage de fréquence des microphones (une centaine de kHz maximum). À la place, ils déterminent les bits de la clé un à un, à chaque décryptage en utilisant un message spécialement conçus pour trahir le bit attaqué lorsque décrypté.

Réalisation du Projet

Semaine 1

Première réunion pour contextualiser et préciser le projet. Il m'a été remis un papier de recherche (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis) pour me présenter l'état de l'art dans le domaine des attaques par canal auxiliaire dans le domaine acoustique. L'objectif de la semaine est d'analyser le papier de recherche.

Le papier de recherche utilise du matériel de laboratoire principalement, des capsules microphones ayant des fréquences maximums de 21 kHz à 350 kHz monté sur un pré-amplificateur suivit d'un amplificateur, d'un convertisseur analogique numérique et d'un ordinateur. Les auteurs ont aussi obtenu des résultats convainquant avec un microphone de téléphone portable.

Le papier souligne que le problème principal d'une attaque par analyse acoustique est la grande différence d'ordre de grandeur entre la fréquence de calcul de l'appareil (quelques GHz) et la bande passante naturelle induite par l'air pour la propagation du son (environ 300 kHz). Néanmoins, notre projet consiste simplement à l’identification de l'appareil (dans un premier temps) et le bruit induit par les opérations de l'appareil peuvent être de l'ordre de l'audible (comme le démontre le papier en utilisant un microphone de téléphone portable). Secondement, nous avons un accès physique à l'appareil dans notre cas, c'est-à-dire qu'il nous est possible de placer le microphone au plus proche de la source pour avoir un rapport signal-bruit important.

Semaine 2

Après l'analyse du papier de recherche, il est temps de chercher des solutions matériels pour acquérir les signaux sonore. J'ai exploré plusieurs pistes en plus de la piste "classique" du microphone.

Une plaque de résonance avec capteurs piézométriques. L'idée est de se passer de l'air comme milieu de propagation du son. En effet, le son se propage beaucoup moins bien dans un gaz que dans un solide ou un liquide (l'air est limité à 300 kHz. Au-dessus, les fréquences sont noyées dans l'agitation thermique des molécules et l'espace entre les molécules deviens trop important). En utilisant la coque de l'appareil puis une plaque en contact avec la coque, le son ne passe plus que dans du solide. La bande passante est en théorie plus grande. Cependant, il faudra garder un œil sur les effets de résonance dans les solides, ainsi qu'à la sensibilité des capteurs piézométriques.

Un vibromètre laser. L'idée est encore de se passer de l'air. Le vibromètre mesure directement les vibrations des composants sans être limité en fréquence théoriquement et sans perturber mécaniquement l'appareil. C'est l'outil idéal mais bien trop cher pour ce projet.

Remplacer l'air par un liquide ou un gel. Toujours dans cette idée d’ignorer l'air, si on trouve un liquide ou un gel compatible avec l'électronique et un micro compatible, il est possible d'augmenter grandement la bande passante du milieu de propagation. Cependant, dans un souci de préserver au maximum l'objet étudié, cette solution n'est pas applicable dans le cadre de ce projet.

J'ai dans un même temps entamé mes recherches pour des microphones. Quelques pistes non-concluantes surgissent :

• Avisoft Bioacoustics, qui propose des microphones allant jusqu'à 250 kHz. Malheureusement, leur prix est excessif (de l'ordre du millier d'euros) : https://www.avisoft.com/usg/microphones.htm
• Batsound (et beaucoup d'autres), propose des détecteurs d'ultrason. Ils sont inadaptés à la mesure : https://batsound.com/
• D'autres magasins comme Dodotronic propose des microphones, mais aucune information précise n'est présenté sur leur qualité : https://www.dodotronic.com/product-category/usb-microphones

Il est très compliqué pour moi d'obtenir des résultats en rapport avec mes recherches, j'ai demandé de l'aide à des professeurs pour m'aider à filtrer mes recherches.

Semaine 3

Grâce à l'aide de mes professeurs (Alexandre BOÉ, Emmanuelle PICHONAT et Thierry FLAMEN), j'ai pu affiner mes recherches.

Tout d'abord, la piste plaque de résonance a été abandonnée. Les effets de résonance et la faible sensibilité des capteurs piézométriques en sont la cause.

Pour ce qui est des microphones, j'ai classé mes recherches de matériel en trois parties proportionnelle à la qualité :

• une qualité laboratoire : des microphones capsules principalement, avec leur pré-amplificateur associé, un amplificateur si besoin et un convertisseur analogique numérique.
• une qualité studio : des microphones de mesure acoustique utilisé par les amateurs et les professionnels du son pour calibrer leurs autres micros en fonction de l'acoustique de la pièce. Ces microphones ont une réponse en fréquence très linéaire et sont très sensibles.
• une qualité prototype : regroupe le matériel destiné à être utilisé pour créer des circuits électroniques.

Dans la catégorie laboratoire, deux entreprises ont retenu mon attention : Brüel & Kjær et Microtech Gefell. Des courriels ont été envoyés pour avoir plus de précision sur leur prix.

Dans la catégorie studio, j'ai fait beaucoup de recherches sur les microphones de mesure. Dans beaucoup de cas, ce sont des microphones capacitifs et ils ont besoin d'une alimentation fantôme +48V. Après avoir épluché quelques forums, j'ai fait une liste de matériel sur Woodbrass :

• Microphone de mesure : BEHRINGER ECM8000 ou PRESONUS PRM1
• Amplificateur + alimentation fantôme +48V : BEHRINGER MIC100 TUBE ULTRAGAIN
• Câble XLR mâle / XMR femelle (symétrique) : BIRD INSTRUMENTS MC21 - XLR / XLR - 3M
• Câble Jack 6,35 mm / Jack 6,35 mm (symétrique) : BIRD INSTRUMENTS AC80 - JACK STEREO - 1M
• Adaptateur Jack 6,35 mm / mini-Jack 3,5 mm : EAGLETONE ACO66 - JACK FEMELLE STEREO/MINI JACK MALE STEREO

À savoir que le microphone BEHRINGER ECM8000 est plutôt réservé aux amateurs et le PRESONUS PRM1, aux professionnels d'après mes recherches sur des forums.

Dans la catégorie prototype, il faudra privilégier un microphone électret : en plus de ça haute sensibilité, il n'a pas besoin d'alimentation comparé aux microphones capacitifs. Cependant, la qualité de la mesure va dépendre grandement de l'amplificateur. Des recherches sont en cours.

Semaine 4

Exemple de spectrogramme (valeurs en dB) de la note C4 d'un piano optenu avec SciPy (calcul) et Matplotlib (affichage)

J'ai consacré cette semaine à la recherche de solutions pour l'analyse des signaux. Python me semble un choix évident pour sa simplicité et son abondance de librairies. J'ai réaliser les premières fonctions qui me seront utiles, à savoir : l’acquisition via la carte son interne de l'ordinateur (avec la librairie PyAudio), réalisation de spectrogrammes (avec l'aide de SciPy) et la lecture d'audio (avec l'aide de PyDub). Les scripts sont disponibles sur le récemment créé projet git. J'ai aussi manipulé GNU Radio, un logiciel de traitement du signal commandable par Python.

J'ai aussi modifié la liste de matériel pour la qualité studio en remplaçant l'amplificateur + alimentation fantôme en une carte son présentant les même fonctionnalités en plus d'intégrer un échantillonneur plus performant que celui d'un ordinateur. Avec cette carte son, il sera possible d’échantillonner à 192 kHz et donc d'avoir un son beaucoup plus clair. La nouvelle liste est la suivante :

• Microphone de mesure : BEHRINGER ECM8000 ou PRESONUS PRM1
• Carte son (Amplificateur + alimentation fantôme 48V + échantillonneur) : STEINBERG UR12
• Câble XLR mâle / XMR femelle (symétrique) : BIRD INSTRUMENTS MC21 - XLR / XLR - 3M
• Câble USB B mâle / USB A mâle : (déjà en stock)

Semaine 5

Ma recherche de solution pour du matériel pour la qualité "prototype" c'est affinée. J'ai choisi la paire suivante :

• Microphone : KEEG1538WB-100LB
• Amplificateur : LM386 (disponible dans le magasin d'électronique à Polytech)

À noter qu'un montage sera nécessaire pour l'alimentation du microphone comprenant : (montage explicité dans la documentation du microphone)

• Une résistance de 2.2 kOhm
• Une capacité de l'ordre de 100 nF (pour le découplage)

Un montage pour le réglage du gain et pour protéger la sortie jack : (montage explicité page 11 de la documentation de l'amplificateur)

• Une capacité de 10 uF
• Deux potentiomètre de 10 kOhm (un en entrée pour le réglage de la tension, un autre à la place de la résistance de 1.2 kOhm présentée sur le schéma pour un réglage du gain)
• Une capacité de l'ordre de 100 nF (découplage à la sortie)
• Une capacité de ~0.05 nF et une résistance de ~10 Ohm (protection de la sortie)

Et pour la connectique PCB-PC :

• Une sortie jack 3.5 mm : lien Farnell
• Un câble jack double mâle 3.5 mm : lien Farnell

Semaine 6

Schéma électrique de la solution "prototype"

Circuit imprimé de la solution "prototype"

Le schéma électrique et le circuit imprimé de la solution prototype ont été dessiné sur Eagle. La carte dispose de deux potentiomètres pour régler le volume et un potentiomètre pour régler l'alimentation du microphone (à environ 2V).

Les fichiers Eagle sont disponibles sur le projet git dans le dossier "/PCB".

La liste du matériel a été modifiée en conséquence pour correspondre au choix des valeurs des composants.

Semaine 7

Démonstration de la nouvelle fonction pour réaliser des spectrogrammes par l'analyse de la note C4 d'un piano.

Comparaison de la nouvelle fonction pour réaliser des spectrogrammes par l'analyse de la note C4 d'un piano.

Cette semaine a été consacrée à la réalisation d'un meilleur spectrogramme en partant de la fonction fft de scipy. La fonction programmée montre une résolution plus fine et il me sera maintenant possible de régler plusieurs paramètres à savoir : la plage de fréquence à analyser, la plage de valeur à afficher, le découpage de l'échantillon sonore et le chevauchement (comparable à un lissage) des fft dans le spectrogramme.

La démonstration (image à gauche) montre les différentes possbilités qu'offre la nouvelle fonction :

• En haut à gauche, seules les valeurs entre 0% et 10% du signal sont affichés, ce qui permet de révéler des détails cachés par le constraste.
• En haut à droite, la plage de fréquence a été limitée entre 4000 Hz et 3000 Hz (en utilisant la même résolution).
• En bas à gauche, ici la résolution du spectrogramme choisie est très grande. Il faut zoomer (en bas à droite) pour voir distinctement les valeurs.

L'image de droite compare les deux fonctions (entre la fonction native de SciPy et la nouvelle). À gauche, l'ancien spectrogramme réalisé avec SciPy. À droite, la nouvelle fonction construite à partir de fft.

Remarque : les spectrogrammes sont ici tous en linéaire.

Semaine 8

Plan en 3D de la boite d'isolation acoustique.

Il y a eu une modification mineure dans le schéma électrique et le PBC (les images sur le wiki ont été mis à jour en conséquence).

Réalisation en 3D de la boîte d'isolation acoustique pour connaitre la dimension des planches de bois. L'assemblage des planches sera fait grâce à des indentations sur les côtés pour pouvoir les emboîtées. La boite aura pour dimension 560x560x310mm.

Semaine 9

Spectrogrammes de la première expérience : Peut-on différencier un appareil branché au chargeur par l'analyse du son du chargeur ?

Spectrogrammes de la seconde expérience : Peut-on déduire l'activité d'un appareil branché au chargeur par l'analyse du son du chargeur ?

Maintenant que j'ai un générateur de spectrogramme complet, j'ai décidé de faire quelques analyses sonores en guise d'entraînement. Chez moi pendant la nuit, je suis perturbé par un sifflement très aigue et à peine audible (autre que le compresseur du frigo). La source de ces nuisances se trouve être le chargeur USB qui recharge mon téléphone pendant la nuit. J'ai donc eu l'idée de faire quelques expériences en enregistrant le son du chargeur. J'ai utilisé le micro de mon téléphone en attendant que la commande de matériel arrive.

Peut-on différencier un appareil branché au chargeur par l'analyse du son du chargeur ? Pour la première expérience, j'ai enregistré le son du chargeur lorsqu'aucun téléphone n'était chargé, puis en branchant mon téléphone principal (nomé téléphone n°1, un Moto G5 Plus), puis en branchant mon vieux téléphone (nomé téléphone n°2, un Samsung Galaxy S4 mini). Après visionnage des spectrogrammes (figures de gauches), la différence est flagrante entre les différents cas. À noter que les deux téléphone était inactifs et en mode avion lors de l'enregistrement. Aussi, les spectrogrammes sont en dB.

Peut-on déduire l'activité d'un appareil branché au chargeur par l'analyse du son du chargeur ? Pour la seconde expérience, j'ai développé une application Android très simple pour faire travailler le processeur du téléphone. J'ai enregistré le son du chargeur lorsque le téléphone était inactif, puis lorsqu'il incrémente une variable 100 000 000 fois, puis lorsqu'il calcule les 5 000 premiers nombres premiers, puis lorsque le mode avion est désactivé (sans input de la part de l'utilisateur). Après visionnage des spectrogrammes (à gauche), on peut conclure plusieurs choses :

• la différence entre l'état actif et inactif du téléphone est visible.
• Sur les spectrogrammes de droite, il est même possible de faire correspondre le moment où l'utilisateur appui sur le bouton pour lancer les calculs (grâce au son du doigt qui clique sur l'écran entouré en rouge sur les figures) et le bruit lors de l'activité de processeur.
• On remarque aussi que le téléphone n'est pas totalement inactif lorsque l'utilisateur ne demande aucun calcul, même en mode avion.
• Lorsque le mode avion est désactivé, l'acitivité du téléphone est très intense et le bruit est très riche.

Note importante : dans la deuxième expérience, le spectrogramme en haut à gauche à l'air plus actif que ceux de droite. En effet lors du calcul du spectrogramme, les valeurs sont recadrées entre 0 et 1 (le minimum du signal devient 0 et le maximum devient 1). Ce-ci permet d'analyser et de comparer deux signaux quel que soit leur volume. Pour se convaincre que le spectrogramme du téléphone inactif est plus faible que ceux de droite, on peut regarder le trait dessiné à la fréquence proche de 7 500 Hz. Cette perturbation (à mon avis propre à ma chambre ou au micro) apparaît différemment sur les quatre spectrogrammes, preuve que le volume des signaux est différent.

En conclusion : si dans la suite du projet, il est impossible d'obtenir des résultats à partir du son de l'appareil, il sera toujours possible d'utiliser une alimentation pour trahir l'appareil.

Seconde note importante : après un rapide test, il semblerait que les résultats dans la seconde expérience ne soient possible que lorsque le téléphone est rechargé à 100 %. En effet, le bruit témoigne du courant circulant dans le chargeur. Donc lorsque le téléphone est n'est pas plein d'énergie, il demande le maximum de courant au chargeur ce qui ne trahit plus l'activité du téléphone.

Semaine 10 & 11

Photo de la boite d'isolation acoustique

La boite a été réalisée comme précisée dans la semaine 8. Les plaques en mousses ont été fixées à l'aide de bandes double-face. Deux charnières ont été fixées grâce à des boulons pour le mouvement de la porte et une poignée a été ajoutée.

Aussi, j'ai réalisé quelques tests pour estimer l'isolation acoustique. Les mesures montre une diminution du bruit (claquement de main) de 10 à 15 dB.

Semaine 12

Après une réunion avec mes tuteurs il a été convenu que les mesures devaient se faire avec une carte électronique sous batterie plutôt qu'un ordinateur pour d'une part éviter le bruit de la machine (ventilateurs, nuisance électronique beaucoup plus forte qu'une simple carte) et d'autre part pour éviter la nuisance du secteur (à 50 Hz). Il m'a donc été demandé de configurer une Rapsberry Pi. J'ai donc installé un Raspbian, puis installé et configuré les librairies Python, et modifié mes scripts.

Quelques mesures préliminaires ont montré que la carte son et les micros fonctionnaient bien. Il me sera possible d'enregistrer des mesures jusqu'à 98 kHz. À noté que même si les micros sont garantis jusqu'à 22 kHz, ils semblent quand même fonctionner jusqu'à 98 kHz.

La semaine prochaine sera consacrée à la mesure et l'analyse de divers appareils sous des conditions proches du produit finit.

Semaine 13

Spectrogrammes de la première expérience : Comparaison des deux microphones

Spectrogrammes de la seconde expérience : Analyse du son du chargeur avec différents appareils

Spectrogrammes de la troisième expérience : Analyse de la carte stm32f769i-disco sous différentes activités

Cette semaine a été consacrée à la mesure et l'analyse de 3 expériences :

• Comparer la performance des deux microphones de qualité "studio".
• Analyser le son du chargeur avec différents appareils dans des conditions proches de la fin du projet.
• 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 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.

La dernière expérience visait à montrer s'il était possible de différencier la carte stm32f769i-disco dans différent mode de fonctionnement. Aucune différence n'est détectable en l'état. À noter que pour le spectrogramme du bas, le microphone a été éloigné par mégarde : le signal est donc plus faible mais pas moins similaire.

Semaine 14

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.

Semaines 15 & 16

Caractérisation, en fréquence, de la réduction de bruit par la boite (échelle logarithmique)

Pour affiner la mesure effectué 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.

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

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.

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

Liste des documents et ressources rendus :

• Projet Git : https://archives.plil.fr/pfrison/IOT_Acoustic
• Rapport intermédiaire : Format PDF
• Présentation intermédiaire : Format PDF
• Rapport final : Format PDF
• Présentation finale : Format PDF