PAGE WIKI ETUDIANTS 2011-12 SERRURE VOCALE

Présentation du projet

Le but de ce projet est de développer un système de reconnaissance vocale. Le projet consiste à réaliser un programme permettant d'ouvrir une gâche électronique simplement par la parole. Les voix des locuteurs seront préalablement enregistrées, et devront être identifiées par un système de reconnaissance vocale afin de permettre ou non l'ouverture de la gâche électronique. Pour réaliser ce projet, nous disposons d'un montage électronique de la gâche qui sera ouverte ou non selon l'acceptation ou le rejet du signal reçu en entrée. Pour la démonstration du projet, nous réaliserons une interface graphique qui permettra l'enregistrement des voix ainsi que leur reconnaissance. La partie IHM sera plus expliquée en détail grâce à des sketchs par la suite.

Nous étudierons aussi à la fin du projet les performances et la robustesse de notre système.

Déroulement du travail

Etude de l'existant

Ce projet a déjà été réalisé l'année précédente, pour cela,la première étape sera d'analyser le travail effectué par les élèves de l'année précédentes, afin de garder les parties fonctionnelles et les améliorer. Ce projet est essentiellement composé de trois grandes parties:

1. Montage électronique de la gâche
2. Acquisition et Reconnaissance des données
3. IHM de pilotage de la gâche

Répartition des tâches

Nous avons réparti les différentes parties sur les différents membres du groupe. Nous allons démarrer en parallèle les trois parties: Montage, acquisition et IHM afin de gagner un maximum de temps. Une fois ces parties finies, on se penchera tous sur l'interfaçage entre l'IHM et les scripts de reconnaissance ainsi que les tests de performances. Voici les rôles de chaque membre de l'équipe:

Chef de projet:

1. NAHUM Solis

Développeurs Acquisition/ Reconnaissance:

1. MALKAS Benjamin
2. NAHUM Solis
3. EL BAKKOURI Nysrine

Montage gâche:

1. ODUL Jonathan

Développement IHM:

1. ODUL Jonathan
2. RIOT Emilien
3. SEISSON Julien

Responsable wiki:

1. EL BAKKOURI Nysrine

Diagramme prévisionnel de tâches

Requis non fonctionnels

Pour ce projet, nous avons choisi de mettre l’accent sur la fiabilité, l’utilisabilité, la maintenabilité et la robustesse du système.

Interface intuitive

L'utilisateur doit passer par une interface d'interaction afin de piloter le système, pour cela, nous avons jugé important de réaliser une interface intuitive, ergonomique et très facile d'utilisation.

Test des performances et robustesse de notre système

Afin de tester les performances de notre système, il est nécessaire de fixer une valeur seuil d’acceptation/rejet. Cette valeur doit permettre au mieux de deviner si la personne qui est en train de s’identifier est la bonne personne ou non. Nous allons donc effectuer plusieurs tests à partir de notre modèle du monde. La bonne valeur du seuil sera trouvée lorsque le nombre de faux rejets sera égal au nombre de fausses acceptations.

Requis fonctionnels

Montage électronique de la gâche

Cette partie consiste à réaliser un simple montage électronique qui nous permettra de tester le système à la fin du projet.Voici une petite vidéo montrant les différents composants du montage ainsi que le fonctionnement de celui-ci:

Acquisition et Reconnaissance des données

Cette partie demande la mise en place de l'environnement de travail, pour cela, il faut faire le TP: http://www-clips.imag.fr/geod/User/laurent.besacier/NEW-TPs/TP-Biometrie/ qui explique bien toutes les étapes d'installation.

Une fois l'environnement est installé, il faudra réaliser l’acquisition des signaux. Les signaux de départ correspondent aux voix des membres du groupe enregistrées au format raw comme dans le TP. Les vecteurs paramètres de ces voix seront ensuite générés grâce à l’outil spro, puis le modèle du monde créé en suivant les étapes décrites dans le TP préparatoire. Les modèles de locuteurs correspondant à ces voix qui seront reconnues par le système seront également créés.

L’an dernier, en plus de l’acquisition des signaux de 12 membres du groupe, deux scripts ont été également faits pour l’acquisition du signal d’un nouveau locuteur et la reconnaissance d’un locuteur quelconque par le système.

Le script d’acquisition de signaux permet donc d’enregistrer le signal d’un nouveau locuteur, de créer le vecteur de paramètre, de traiter le signal (normaliser, détecter l’énergie, renormaliser) et de l’ajouter au modèle du monde. Lors de l’acquisition le locuteur peut choisir d’être reconnu par le système ou non. S’il souhaite être reconnu alors son modèle de locuteur est généré. Une méthode java permettant d'exécuter un script shell a été réalisée mais nous ne disposons pas de cette méthode dans la documentation fournie.

Le script de reconnaissance du locuteur permet de tester l’appartenance d’un locuteur au système. Il enregistre le signal du locuteur pendant quelques secondes, crée le vecteur de paramètres, traite le signal (normalisation, détection de l'énergie, re-normalisation) puis teste, en fonction de son nom, si ce locuteur est reconnu par le système ou non. Vu que cette partie du projet a été bien réussie, nous réutiliserons, les 2 scripts fournis.

Pour ne pas avoir à chercher en permanence des personnes extérieures à notre système pour les tests, nous utiliserons les membres de notre groupe de 6 : 4 locuteurs reconnus par le système et 2 imposteurs.

IHM de pilotage de la gâche

Pour ce système, il existe 2 modes distincts:

1. Le mode acquisition qui sert à récupérer le signal et créer un modèle à partir de celui-ci.
2. Le mode test qui sert d’identification. L’authenticité de l’utilisateur est vérifiée en comparant au modèle enregistré.Ces modes sont aussi utilisés dans notre application, mais l’interface est différente.

Mode acquisition :

Il faut entrer le nom de l’utilisateur et la durée souhaitée de l’enregistrement. En dessous se trouve un texte important que l’utilisateur doit lire, après avoir lancé l’enregistrement à l’aide d’un bouton. Le problème de ce type d’interface vient du texte à lire. En effet, celui-ci représente un pavé énorme, pas forcément facile à lire pour l’utilisateur. Il serait plus aisé de lire plusieurs phrases courtes, apparaissant l’une après l’autre, plutôt que de lire cet imposant paragraphe.

Mode test :

Il y a un champ disponible pour l’identifiant de l’utilisateur, ainsi qu’un slider permettant de définir le seuil. Une fois le nom entré et le seuil réglé, l’utilisateur lance l’enregistrement à l’aide d’un bouton. Il prononce alors la phrase de son choix (environ 3secondes).

Ce modèle possède des défauts. Le plus flagrant est de donner à l’utilisateur le choix du réglage du seuil :

- Il ne sait pas forcément ce qu’est ce seuil, et ne comprend donc pas l’utilité du slider.

- S’il connait l’utilité, il peut alors le régler pour essayer de fausser la reconnaissance.

Les développeurs de cette précédente version ont précisé qu’il s’agissait d’une interface de « test » et non « d’identification », ce qui explique les libertés données à l’utilisateur.

Le second défaut est la liberté donnée pour la phrase à dire :

- D’un point de vue purement IHM, il est moins déroutant (et donc plus rapide) pour l’utilisateur de réciter une phrase affichée que d’en inventer une.

- D’un point de vue reconnaissance vocale, il est aussi plus facile de comparer une phrase connue au modèle. On limite aussi les risques (phrase trop courte par exemple).

Voici quelques prises d'écran du système:

Login

Test identification

Identification échouée

Identification réussie

Page d'administration

Gestion de profils

Page de profil

Page d'enregistrement

Enregistrement lancé