ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

[Casper] OpenCV et Beagleboard

Aujourd’hui j’ai porté les algorithmes de détection et reconnaissance faciale sur Beagleboard, sans trop de soucis. Comme nous n’avons pas encore reçu la webcam, je me suis contenté de les tester sur des images jpeg. Les temps de traitement sont deux fois plus longs sur Beagleboard que sur mon PC, et nous allons donc certainement jouer sur la taille des images pour avoir un temps de traitement convenable.

Je me suis également penché sur le projet d’optimisation d’OpenCV utilisant le DSP de la beagleboard, mais un benchmark disponible sur le site du projet montre que le gain en performances est plus que relatif. Le seul intérêt pourrait être de décharger le processeur de certains traitements. Nous reviendrons donc vers ce projet uniquement si le besoin s’en fait réellement sentir…

Nous avons de plus reçu notre carte aujourd’hui et nous commençons donc sa prise en main.

[CASPER] Reconnaissance faciale

Nous avons implémenté la détection et la reconnaissance de visages à l’aide de la bibliothèque OpenCV. Celle-ci utilise l’algorithme de Viola-Jones pour la détection et l’algorithme des eigenfaces dont nous avons déjà parlé dans ce billet pour la reconnaissance.

Nous allons donc ici expliquer uniquement l’algorithme de Viola-Jones.

Algorithme de Viola-Jones

Cet algorithme est un algorithme de boosting, c’est-à-dire qu’il classifie une zone de l’image comme visage ou non-visage à partir de plusieurs classifieurs faibles (c’est-à-dire ayant un taux de bonne classification légèrement meilleur qu’un classifieur aléatoire). Ces classifieurs faibles, inspirés des ondelettes de Haar, consistent à sommer des pixels sur certaines zones (rectangulaires) de l’image et à les soustraire sur d’autres (on trouve ainsi par exemple un classifieur faible dont le but est de détecter des yeux en sommant sur les yeux et en soustrayant entre). Afin de réduire le coût computationnel de ces sommations, Viola & Jones ont introduit les « images intégrales » : celles-ci consistent à recueillir dans chaque pixel la somme des pixels du rectangle qu’il délimite avec le pixel origine. Les classifieurs faibles sont ensuite agrégés à l’aide de l’algorithme AdaBoost.

Afin d’accélérer le traitement, l’algorithme de Viola-Jones utilise plusieurs classifieurs « forts » en cascade, et les agrège par unanimité : dès qu’un classifieur classifie une zone de l’image comme non-visage, le traitement de cette zone s’arrête et celle-ci est classifiée comme non-visage.

Un des problèmes que soulève cette méthode est que les classifieurs faibles (et donc les classifieurs forts) sont définis pour une taille de visage donnée. Or en pratique les visages susceptibles d’apparaître sur une image ont une taille quelconque. Le traitement est donc réalisé de manière pyramidale.

Un deuxième problème est l’agrégation des résultats. En effet, en faisant glisser une fenêtre de détection sur l’image, le même visage est susceptible d’être détecté plusieurs fois, pour des décalages de quelques pixels de la fenêtre. Afin de palier ce problème, l’algorithme regroupe les fenêtres se chevauchant de plus d’une certaine proportion, et en retourne une fenêtre « moyenne ».

Une des principales limitations de cet algorithme est qu’il n’est pas invariant pas rotation, ce qui impliquera de faire un prétraitement pour redresser l’image de la caméra selon la position de notre robot avant de lancer l’algorithme.

Viola-Jones et OpenCV

Plusieurs bases de classifieurs sont fournies par défaut avec OpenCV, notamment pour détecter des visages de face ou de profil. Deux bases détectent les visages de face, les bases « haarcascade_frontalface_default.xml » et « haarcascade_frontalface_alt.xml ». Nous utilisons la deuxième, car la détection est plus rapide (de l’ordre de 50%).

Nous utilisons plusieurs paramétrages fournis par OpenCV, notamment le fait de s’arrêter dès qu’un visage a été détecté, et de commencer par rechercher les visages les plus grands.

Ceci permet d’avoir des temps de détection acceptables (de l’ordre de 50ms sur un PC portable vieux de deux ans à base d’Athlon X2) quand un visage est présent dans l’image, mais beaucoup plus longs si aucun visage n’est présent (de l’ordre de la seconde). Nous pouvons donc envisager d’arrêter la recherche dès que celle-ci dépasse la centaine de millisecondes. Nous attendons cependant le portage sur beagleboard pour évaluer les temps de calcul en conditions réelles. Il existe de plus un projet d’optimisation d’OpenCV utilisant le DSP présent dans l’OMAP de la beagleboard, qu’il sera intéressant de tester.

Algorithme complet

L’algorithme complet de détection et reconnaissance donne des résultats intéressants sur PC portable, la prochaine étape étant de les tester sur beagleboard. Nous rencontrons de même un problème de latence sur OpenCV : l’algorithme se comporte en effet comme s’il existait un buffer de quatre images qui introduit un retard sur les images traitées, le problème étant d’autant plus perceptible en cas d’absence de visage lorsque le traitement de chaque image prend une seconde… Nous n’avons cependant pas encore mené de recherches approfondies sur ce problème.

[CASPER] Premiers contacts avec PocketSphinx et OpenCV

Aujourd’hui nous avons poursuivi l’exploration des bibliothèques de traitement vidéo et audio.

Partie Audio : La bibliothèque que nous utilisons s’appelle PocketSphinx. Nous sommes aujourd’hui capable de reconnaître des mots ou des phrases en anglais et de les associer à des commandes (appui sur une touche clavier ou ouverture d’un fichier par exemple). La prochaine étape est de faire fonctionner un synthétiseur vocal.

Partie Vidéo : La bibliothèque que nous utilisons s’appelle OpenCV. Nous avons écrit un programme qui récupère un flux vidéo de la webcam et détecte dans chaque frame la présence d’un visage ou non. Si il en trouve un, il l’encadre. On peut observer la détection dans une fenêtre qui affiche les frames au fur et à mesure de leur traitement. La prochaine étape est d’implémenter l’apprentissage et la reconnaissance de visages.

Enfin, nous avons préparé la soutenance intermédiaire de demain.

[CASPER] – Mouvements et expression d’émotions

Comme nous l’avons précisé lors de la soutenance initiale, CASPER devra pouvoir exprimer des émotions. Il nous fallait encore préciser sous quelle forme.

Nous avons finalement choisi de doter CASPER de deux sourcils, et éventuellement d’une mâchoire, articulés. Les mouvements possibles resteront basiques :
- rotation des sourcils autour d’un axe (ce qui permet de les incliner plus ou moins et d’exprimer assez naturellement des émotions comme la surprise, la colère, la perplexité, etc.)
- éventuellement mouvement vertical de la mâchoire inférieure, l’intérêt étant principalement de pouvoir simuler sommairement la parole lors des épisodes de synthèse vocale, afin de rendre  CASPER plus « vivant ». Nous ne sommes cependant pas encore certains de l’implantation de cette fonctionnalité (a-t-elle un impact réellement intéressant du point de vue de l’utilisateur ?)

De plus, afin de rendre possible le tracking visuel, le tout sera monté sur une base pivotante (tracking horizontal) et sera inclinable (tracking vertical).

Tous ces mouvements seront réalisés grâce à des servomoteurs, dont nous n’avons pas encore fixé le(s) modèle(s).

J’ai quant à moi commencé à implanter une version de test des algorithmes de détection des visages et reconnaissance faciale afin de tester l’influence de certains paramètres, comme les conditions d’éclairage et la résolution de la prise de vue. Le but est de pouvoir quantifier la robustesse de ces algorithmes et la charge de calcul que pourraient ajouter certains pré- et post-traitements nécessaires en vue d’en augmenter la robustesse.

[CASPER] Reconnaissance et synthèse vocale / Solutions Wi-Fi

Nous aborderons ici les solutions envisagées pour le projet casper en ce qui concerne la reconnaissance et la synthèse vocale, ainsi qu’en terme de connexion Wi-Fi

I. Reconnaissance et synthèse vocale [Thibault P.]

 

Afin d’intégrer des fonctionnalités de reconnaissance et de synthèse vocale dans notre projet, il est nécessaire de commencer par une étude des solutions existantes et accessibles.

Nous pouvons les diviser naturellement en deux branches, les solutions Hardware et Software.

1) Hardware

La société Sensory, Inc. (http://www.sensoryinc.com/) réalise des IC spécialisés dans le traitement audio, et notamment dans tout ce qui concerne la reconnaissance et la synthèse vocale, mais aussi l’identification biométrique par la parole (fonction de mot de passe vocal) sur certains modèles.

L’avantage est donc de décharger le microprocesseur principal par un matériel spécialisé, ce qui permettrait, par exemple, d’avoir un algorithme un peu plus gourmand de reconnaissance faciale (cf post d’Alain du 27 Fev).

L’inconvénient est de devoir mettre en place un environnement de développement spécialisé pour cette tâche, avec les coûts que cela implique, et l’incertitude quant aux performances de la synthèse en terme de calcul de prétraitement (construction des phonèmes).

Concernant les performances des puces, il semble que les fonctions de reconnaissance soient suffisantes par rapport à ce que l’on souhaite faire (reconnaissance d’un vocabulaire restreint pour la commande de casper), mais il se pourrait que les fonctions de synthèses ne soient pas assez performantes pour traiter sans coupure un long texte. Les données techniques exactes ne sont pas directement fournies* (du moins je ne les ai pas trouvées) ce qui confère à ce choix technique une dose de hasard non négligeable.

* L’information la plus précise que j’ai trouvée à ce sujet est que la fonction de synthèse text-to-speech ne peut pas traiter plus de 160 caractères en un coup. Il faudra donc couper les longs messages en plusieurs parties, ce qui permettrait de demander confirmation à l’utilisateur qu’il souhaite poursuivre la lecture, mais qui peut être ennuyeux si il faut attendre un délai trop important avant que la lecture ne reprenne.

Processeur NLP-5x de Sensory, Inc. : text-to-speech + reconnaissance vocale + autres

Processeur RSC-4x de Sensory, Inc. : reconnaissance vocale + mot de passe vocal + synthèse vocale (ne semble pas être text-to-speech) + autres

 

2) Software

Pour ce qui est d’une solution software, il existe des bibliothèques libres que nous pourrions donc utiliser. Parmi celles-ci, il existe une bibliothèque C spécifiquement conçue pour l’embarqué : il s’agit de Pocketsphinx, qui est l’un des blocs du projet CMU Sphinx.

On peut trouver concernant cette bibliothèque des informations de performance en terme de détection, mais il est difficile de trouver des informations sur les performances en terme de ressources utilisées.

On peut noter toutefois que cette bibliothèque a été utilisée avec succès sur l’iPhone d’Apple, ce qui implique donc qu’elle est bien « portable » et « embarquable ».

La bibliothèque pocketsphinx est donc une bibliothèque dont la licence nous permettrait d’en faire usage dans notre projet, qui présente une solution à faible investissement et qui de plus a été spécifiquement conçue pour la reconnaissance vocale dans un système embarqué.

Pour ce qui est de la synthèse vocale, on peut noter l’existence d’une autre bibliothèque issue de la même Université, la CMU Flite, qui elle aussi est proposée dans une version spécifique à l’embarqué.

 

Les avantages de cette solution sont donc le faible coût initial de mise en œuvre ainsi que sa spécialisation pour l’embarqué, ce qui lui permettrai de l’incorporer dans notre système, éventuellement dans un contrôleur dédié si nous souhaitons décharger l’unité principale.

Les inconvénients sont à nouveau l’incertitude quant aux performances en termes de ressources utilisées et en terme de temps de calcul.

 

II. Wi-Fi [Thomas Q.]

Nous avons exploré les différentes options pour la connectivité wifi. Radiospares propose une large gamme de produits qui ont tous l’avantage d’être connectable par bus SPI.

La principale différence se fait au niveau des débits visés. On trouve des chips à un débit réduit de 1-2 Mbps (peu chers) ou des chips configurables de 1 à 54 Mbps (plus chers).
Les bas débits seraient suffisants pour les applications web type mail ou VoIP mais pourraient limiter l’évolutivité du robot en cas de flux vidéo.
Dans le cas où l’on partirait pour une gumstick pour la carte mère (Le choix de l’architecture matérielle n’étant pas encore fixé) il existe un modèle (le AIR COM) qui intègre déjà un module wifi.
Finalement, le modèle de H&D pourrait s’avérer un bon choix (ou sous sa forme SD card) car il consomme peu, intègre un mode de veille (important si l’on souhaite avoir une alimentation par batterie), et propose une large gamme de débits. Cependant, j’ai l’impression que le produit ne comporte pas d’antenne, il est donc nécessaire de l’acheter séparément et de prévoir ce qu’il faut pour la connecter si c’est le cas… Et donc de prévoir le coût de conception supplémentaire, notamment en terme de temps.

Détection de visages et reconnaissance faciale

Voici l’état des dernières réflexions sur la partie reconnaissance faciale du projet CASPER.

1) Acquisition du flux vidéo

Une première réflexion s’impose : il est inutile de faire de la reconnaissance faciale à 20fps, un test toutes les secondes est déjà largement suffisant. Le traitement n’a dès lors pas besoin d’une vitesse d’horloge phénoménale (on étudie les algos un peu plus loin), cependant la vitesse d’acquisition est déterminée par la caméra utilisée. On pense donc utiliser un DMA pour transférer le flux vidéo en SRAM. On utiliserait un double buffer : pendant que le DMA transfère une image dans une zone de la RAM, on travaille sur une image stockée dans une seconde zone. On pourrait dès lors utiliser 2 puces de SRAM, ce qui permettait d’avoir un double accès mémoire à moindre coût…

En travaillant à une résolution de 640*480, chaque pixel étant stocké sur 16 bits (5 bits pour rouge et bleu, 6 bits pour vert, comme sur cette caméra), une image prend 5Mbits… On pourrait aussi travailler en 320*240, ce qui ne fait plus que 1.2Mbits par image. Pour réduire la taille, on pourrait prendre directement les images encodées en JPEG (la caméra ci-dessus le propose par exemple), mais le coût de traitement ultérieur sera plus élevé… A étudier…

2) Détection des visages

On partirait sur la technique décrite dans cet article. Elle a l’avantage d’être très simple et beaucoup plus rapide que les méthodes à la Viola-Jones, ce qui permet de l’implanter avec des ressources de calcul réduites.

Le principe : on regarde la couleur de chaque pixel pour le classer en « peau / non peau ». On construit alors deux histogrammes représentant le nombre de pixels « peau », le premier en sommant sur chaque ligne, le second sur chaque colonne. On peut alors segmenter des « blobs » de peau dans l’image. A noter : cette technique peut donner des résultats plus ou moins aléatoires avec plusieurs visages sur la même image. On écarte ce cas pour commencer…

En 320*240 16bits, ça fait de l’ordre de 150000 accès mémoire 8bits pour parcourir l’image : rien d’insurmontable…

3) Reconnaissance faciale

On part sur la technique des « eigenfaces » (basée sur de l’analyse par composantes principales), technique assez ancienne qui a fait ses preuves.

Le principe : à partir d’une base de visages à différencier, on construit une base de vecteurs propres (les « eigenfaces ») de la matrice de covariance, sur laquelle on projette le visage à identifier. A partir des valeurs des composantes, on peut calculer la distance à chaque visage de la base, et reconnaître ainsi l’utilisateur. Un seuil peut permettre de rejeter le visage en cas de trop grande distance. Grâce à des astuces de calcul, la construction des vecteurs propres à partir de N images de M pixels peut se faire sur une matrice N*N, et non M*M, taille de la matrice de covariance initiale (ouf ! ca reste faisable…). A noter : la diagonalisation n’a besoin d’être faite que lors de changements de la base, chose somme toute rare et ponctuelle… De plus, rien n’empêcherait que ce calcul soit fait sur PC (puisque de toute manière on utilisera l’interface de configuration http pour associer les identités à chaque visage enregistré…).

Le gros de la reconnaissance est alors la projection du visage à tester sur la base (produit scalaire sur les M pixels de l’image pour chaque « eigenface »). Heureusement, cette technique ne nécessite pas une résolution très élevée, et peut fonctionner avec des images de 20*20 pixels, ce qui reste très raisonnable… Il faut simplement ajouter le coût du sous-échantillonage pour que tous les visages aient la même résolution…

Reste le stockage de la base d’ « eigenfaces ». En se donnant une limite de 10 visages à différencier, si chaque image fait 20*20 pixels et est codée en niveau de gris 8bits, 32 kbits suffisent…une mémoire de masse quelconque (flash, SDCard,…) partagée avec l’ensemble du système fait tout à fait l’affaire…

4) Mise en oeuvre

Reste la mise en oeuvre du tout, c’est-à-dire principalement le choix du microcontrôleur… Deux choix architecturaux s’opposent : un seul très gros microcontrôleur qui contrôle l’ensemble de CASPER, ou plusieurs microcontrôleurs dédiés chacun à une tâche. Cette deuxième solution a l’avantage d’autoriser à mettre en veille une partie des fonctionnalités s’il ne se passe rien : par exemple, mettre en veille la reconnaissance faciale s’il ne se passe rien, et la réactiver seulement si l’ambiance sonore dépasse un certain seuil (quelqu’un vient de claquer la porte par exemple), d’où une économie d’énergie (pour avoir le même effet avec un « gros » microcontrôleur, il faudrait en plus pouvoir modifier dynamiquement sa fréquence de fonctionnement, ce qui serait susceptible de perturber d’autres tâches (par exemple le traitement du son)). De plus, seuls les résultats intéressants seraient envoyés au contrôleur principal (« chef d’orchestre »), par le biais d’interruptions, ce qui facilite l’écriture du « comportement » de CASPER. En outre, les besoins en multi-tâche seraient beaucoup plus sommaires (inexistants ?).

On partirait donc sur un contrôleur milieu de gamme (référence à déterminer), quelques dizaines de MHz devant suffire pour toute cette partie « reconnaissance faciale ».

Casper – Keypoints

Aujourd’hui précision des objectifs du projet pour lequel tout restait à définir.

Nous avons opté pour un mix entre le sytème Keepon et le système Nabaztag.

On reprendra la connectivité du Nabaztag et l’interaction « émotionnelle » du keepon.

L’idée est d’avoir un petit robot qui identifie son utilisateur grâce à une caméra (reco faciale) et l’interface avec différents services web (mails par exemple) par des commandes vocales.

L’interactivité émotionnelle passera par sa capacité à parler et par un visage expressif (mécanique ou tableau de leds).

Nous avons également ébauché une répartition des rôles et un planning. Nous débutons un premier repérage sur les bibliothèques existantes au niveau de la reconnaissance faciale et vocale et sur les besoins matériels. Est-il intéressant de choisir des chips dédiés pour le traitement vidéo, le traitement du son ou la connectivité ?

Nous avons ajouté à notre réflexion la possibilité d’incorporer un langage de script appelé lua (suggestion de Samuel Tardieu et Alexis Polti) afin de rendre flexible et évolutive l’architecture, en l’ouvrant aux utilisateurs.