ELECINF344/381

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

Catégories

MB Led: Dialogues en zMQ

Ces derniers temps, j’ai principalement implémenté notre algorithme en C, tournant sous FreeRTOS sur un PC classique.

En effet,  j’ai préféré utiliser directement les possibilitées de FreeRTOS (tâches, sémaphores, etc.) plutôt que de coder en C classique puis de modifier tout cela lorsque j’aurai voulu mettre cela sur un module MBLed (ou GLiP).Cependant, j’ai eu beaucoup de difficultés à paramétrer FreeRTOS pour que cela marche sur un ordinateur. J’ai dû me plonger dans la documentation pour finalement réussir à faire un Makefile qui marche vendredi soir.

Pour simuler les échanges entre modules, nous utilisons zéroMQ en mode PUB/SUB. Chaque module que l’on lance intéragit avec le script en python grâce à deux sockets : avec l’un, les modules publient leurs infos et le script les récupère; avec l’autre, le script python publie les informations (qu’il a modifié pour que la partie « Origine » du message soit devenue une partie « Destination ») et chaque module récupère uniquement les informations le concernant.
Pour l’implémentation de l’algorithme à proprement dit, je tente de reprendre le code en python pour le passer en C bien qu’il soit assez difficile de faire cela. J’avais beaucoup utilisé l’orienté objet dans le script et le C ne gère pas cela. Toutefois l’implémentation se fait assez vite et j’espère avoir fini cela pour jeudi ou vendredi.

[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.

Copterix : Topo sur Lucas and Kanade

L’algorithme de Lucas et Kanade

Principe

Nous disposons de deux images en niveau de gris, A et B, espacées dans le temps de δt.
Nous cherchons à déterminer les vecteurs déplacement de certains points d’intérêt, que nous pouvons par exemple soit choisir arbitrairement, soit trouver grâce à un filtre de Sobel (détection de contours), soit finalement rechercher d’une manière plus lourde mais qui donne des résultats plus efficaces que nous aborderons dans la dernière partie. Bien entendu, un grand nombre de points d’intérêt permettrait d’avoir une meilleure estimation de la vitesse globale de l’image, mais une quantité plus faible de points d’intérêt demanderait moins de ressources système et de temps de calcul : un compromis est donc nécessaire pour les systèmes embarqués.
Nous nous donnons pour cela une fenêtre de recherche pour chaque point d’intérêt trouvé de taille 2*ωx+1 par 2*ωy+1 (en nombre de pixels). Une fois encore, une plus grande fenêtre permettrait de trouver une plus grande amplitude du mouvement, mais demanderait plus d’itérations (ce problème est en grande partie pallié par la forme pyramidale, que nous aborderons par la suite).
Il ne reste plus qu’à trouver le déplacement qui minimise l’erreur :


Développements

Nous commençons donc par calculer la dérivée de l’erreur par rapport au déplacement :

pour ensuite lui appliquer un développement de Taylor à l’ordre 1 autour du déplacement [0, 0] (valide si nous estimons que le déplacement est petit , ce que nous allons admettre) :

À partir d’ici, nous pouvons arrêter les calculs pour faire quelques considérations.
Tout d’abord, l’expression A(x, y) – B(x, y) fait penser à la dérivée de l’image dans le temps au point (x, y), que nous noterons dI(x, y).
Ensuite, les dérivées partielles de B en x et en y ressemblent à un gradient. Nous pouvons de plus considérer que la fenêtre étant grande en comparaison du vecteur mouvement, la dérivée de l’image dans la fenêtre sur l’image B sera la même que sur l’image A. Nous avons donc le gradient suivant :

pour tout (x, y) appartenant à la fenêtre :
Avec ces notations, nous obtenons :

Enfin, une légère transformation nous permet d’obtenir :

Si nous nous donnons :
et

nous pouvons réécrire l’équation précédente sous la forme :

Or, ne l’oublions pas, le but de cette démarche étant d’annuler la dérivée de l’erreur afin de la minimiser, nous avons


G est inversible si le gradient de A est défini, c’est-à-dire si la fenêtre se trouve dans l’image et que nous disposons d’un contraste suffisamment élevé dans la fenêtre (se référer à la dernière partie pour un choix correct des bons pixels à suivre).

Nous avons ici le moyen de calculer le vecteur déplacement ‘le plus cohérent’ qui permet de passer de l’image A à l’image B dans la fenêtre donnée.

Itérations sur k pour affiner la recherche

Le calcul précédent représente un unique passage de l’algorithme. Nous pouvons affiner le résultat en effectuant plusieurs passages, jusqu’à ce que, par exemple, la norme du déplacement soit inférieure à une valeur que nous pouvons choisir.
Pour un indice d’itération k, si nous avons un résultat , nous transformons B ainsi :


pour calculer :

Nous voyons ici l’intérêt de calculer le gradient sur A et non sur B car ainsi nous n’avons qu’à calculer b à chaque itération.
Nous obtenons le déplacement final suivant :

Du problème des déplacements de plus grande amplitude : la mise en pyramide

Nous avons vu dans la première partie que la fenêtre ne suffisait pas à obtenir un compromis satisfaisant entre vitesse de calcul et détection des grands mouvements.
Une solution à ce problème est l’utilisation de pyramides.

Nous nous donnons m niveaux de pyramide (souvent égal à 3) et nous appliquons l’algorithme entier à chaque niveau de Lm à 0.
À chaque niveau de la pyramide, nous construisons une image de résolution 2^L fois inférieure à l’image originale.
Nous gardons la fenêtre de la même taille et transformons les coordonnées des pixels à suivre pour rester cohérent avec la nouvelle résolution.
Pour obtenir le déplacement final, il ne reste plus qu’à sommer tous les déplacements trouvés mis à l’échelle :

Voici une petite illustration du procédé :

Certains pixels sont plus faciles à suivre que d’autres

Nous pouvons déterminer les meilleurs pixels à suivre en nous basant sur l’utilisation que nous souhaitons en faire.
Ici, ce sera le calcul de l’inverse de G qui sera déterminant, il nous faut donc un déterminant non nul pour chaque pixel de la fenêtre, ou bien, pour rester plus mathématique, une valeur propre minimale maximale.
Nous pouvons donc procéder de la manière suivante :

  1. Calculer G et sa valeur propre minimale λ pour chaque pixel de l’image A
  2. Retenir la plus grande valeur λ sur toute l’image (et s’arranger pour éviter que son pixel soit trop au bord pour faciliter les problèmes de fenêtrage)
  3. Garder les pixels qui ont un λ supérieur à un certain pourcentage de ce maximum (5 ou 10 % par exemple)
  4. Parmi les pixels sélectionnés, choisir ceux dont λ est le maximum dans leur voisinage 3×3
  5. Ne garder que les pixels qui ont une distance suffisante (5 ou 10 pixels par exemple)
  6. Enfin, supprimer les pixels de λ minimal pour respecter un seuil maximal de nombre de pixels à suivre que nous nous serons fixés

Cette procédure est un petit peu lourde, d’autant plus qu’il faudrait théoriquement la répéter à chaque nouveau couple d’images à traiter, c’est pourquoi nous pouvons garder les pixels suivis d’une image à l’autre sur par exemple 10 itérations avant de les rechercher à nouveau.

Conclusion

Nous avons vu la version de l’algorithme de Lucas et Kanade implémentée en openCV. Cet algorithme se révèle facile à comprendre et à implémenter, et est personnalisable à souhait pour s’adapter aux besoins exigeants des systèmes embarqués.

Source

Pyramidal Implementation of the Lucas Kanade Feature Tracker

MB Led: Journée de présentation

Dernièrement, nous avons passé beaucoup de temps à adapter la structure de notre projet en fonction de nos possibilités et idées. La préparation de la présentation de demain matin nous a donc pris pas mal de temps.
Nous avons ainsi revu l’organisation logicielle des blocs que nous posterons après validation des enseignants. Nous avons également pensé à un système d’interaction avec les blocs permettant de les utiliser comme une manette de jeu vidéo. Benjamin continue la lecture de la Datasheet du driver de LED et continue à l’implémenter. Guillaume a continué de débugger la simulation de l’algorithme que nous avons choisi. A partir de différents scénarios (arrivée progressive des modules, deux réseaux qui se rencontrent, etc.), nous avons testé le modèle d’élection de leader, d’orientation et il semblerait marcher. Le plus dur étant le retrait d’un ou de plusieurs modules, ce qui oblige à recommencer le processus d’élection de leader, … .  A présent, Guillaume va commencer à l’implémenter en C via 0MQ. Pour ma part j’ai défini la structure du module de gestion de l’IrDA afin de l’adapter à l’envoi de données de tailles importantes.

MB Led: Du hardware au software

LE PCB:

Nous avons terminé le PCB vendredi matin. Après avoir validé notre routage, Alexis nous a appris qu’il avait fait en parallèle sa propre version du PCB. Sa raison étant, non pas qu’il ne croyait pas en nous, mais que contraint par le temps il a préféré commencer un routage prenant directement en compte certaine contraintes (écartement des pistes, congestion des pistes etc.). En effet les commandes pour les PCB devaient être passé dimanche soir et cela laissé peu de temps à Alexis pour revoir les PCB de toute les équipes. Au final les différence entre nos deux PCB ne sont pas grandes (mis à part les contraintes évoquées plus haut). Nous avons même rajouté quelques composants par rapport à ceux prévus au départ, avant de finaliser le routage vendredi (merci Cédric). Alexis a donc vérifié et finalisé notre(son) PCB ce week-end avant de le placer dans notre dépot GIT.

Nouvelle perspective:

Alexis nous a aussi appris que ce seront non pas 16 mais 40 blocs qui seront commandés pour notre projet (et surement pour d’autres plus tard). Les possibilités de jeu et d’application s’en trouvent donc décuplées.

Algorithme:

Nous passons désormais au software. Guillaume continue sur sa lancée pour la simulation en python. Nous avons réfléchi à une nouvelle version pour notre algorithme, principalement pour le positionnement. Après une phase d’élection pour connaître le bloc qui sera utilisé comme référant pour connaître le nord, ce “leader” attribue aux autres blocs leur coordonnées. Il se définit en (0,0); les autres connaissent alors leur position relative par rapport au leader. Après cette phase, il est nécessaire de savoir quel est le plus grand rectangle sur lequel nous pouvons afficher quelque chose. Après une recherche d’algorithme tous très complexes, nous avons décidés d’un algorithme simple (que nous préciserons dans un prochain post). Désormais, nous cherchons un système pour acquitter tous les messages puisque nous ne sommes pas sûrs de la fiabilité de l’infrarouge.

IrDA:

Conformément à notre planning, Cédric commence à se renseigner plus en détail sur le protocole IrDA et sur l’échange de message entre les blocs. Il va dans un premier temps étudier le code de l’équipe GLiP pour comprendre leur façon de faire. A la suite de cela il établira un nouveau protocole d’échange de messages inter-bloc adapté à notre algorithme.

Driver de LED:

Pour ma part, j’ai imprimé la datasheet du nouveau driver de LED et l’ai compris à un niveau plus approfondi. Je commence maintenant à implémenter la gestion de l’affichage d’image via ce driver. Dans la précédente version chaque LED (rouge, vert bleu) pouvait varier entre 16 niveaux d’intensité. Avec ce nouveau driver, elles pourront varier sur 4096 niveaux. Les contraintes de place nous amèneront peut-être à revoir ce nombre à la baisse.
Guillaume, Cédric et Benjamin.

MB Led: Article post communication challenge.

Aujourd’hui j’ai enfin réussi à flasher quatre modules conçus par l’équipe GLiP de l’an dernier. J’ai flashé le code maitre pour un bloc contrôlable avec un PC et minicom pour la sélection des animations ainsi que le code pour trois esclaves.

Lors de la compilation de ces codes sont incluses les différentes animations préalablement convertis grâce au script python gif2glip (conçu par l’équipe GLiP).

Nous avons donc pu faire tourner des petites animations sur un réseau carré de quatre GLiP tout en constatant que les animations étaient bien affichées après mélange des blocs.

Cette étape m’a permis de me familiariser avec l’architecture du code de GliP et de m’imprégner de leurs algorithmes pour la réorganisation du réseau ainsi que pour l’affichage des images via les drivers de LED. La compréhension de ce code nous permettra de faire des premiers tests notamment pour les communications IRDA et nos algorithmes réparties en attendant d’avoir nos propres modules.

Ce soir je me suis consacré à la réorganisation de nos PSSC et à la création d’un diagramme de Gant pour une meilleur répartition des ressources dans notre équipe. Le temps passé sur le TP sur le STM32 nous a obligés de décaler les différentes deadlines pour nos PSSC.

====== Reprise du projet GLiP : ======
- A partir de GIF convertibles par gif2glip nous savons les charger via le bloc maître et les jouer sur un réseau de bloc en utilisant leur matériel ⇒ Fait

====== Conception de la carte et test : ======
- Choix des composants terminé : Fait

- Image PCB prête (on peut passer la commande du circuit imprimé) ⇒ 25 mars

Puis en supposant que nous recevons les PCB au plus tard le 4 avril :

- Soudage des composants sur les cartes => 6 avril

- Contrôle de la matrice de LED (affichage d’image) ⇒ 15 avril

====== IRDA ======
- Echange de messages entre deux blocs ⇒ 11 avril

- Ecriture via Irda sur la sdcard => 22 avril

====== Bluetooth: ======
- Communication Bluetooth avec un ordinateur ⇒ 16 avril
- Exécution de commandes reçu en Bluetooth ⇒ 21 avril
- Application de contrôle Android ⇒ 26 avril

====== Gestion de la mémoire : ======
- Lecture sur la SD Card. ⇒ 12 avril
- Ecriture sur la SD Card. ⇒ 17 avril
- Exécution d’un programme stocké en SD Card. ⇒ 22 avril
- Mise à jour du firmware depuis la SD Card. ⇒ 24 avril

====== Système réparti : ======
- Environnement de simulation en place ⇒ 3 avril
- Gestion dynamique du réseau de bloc⇒ 15 avril

====== Jeux sur l’ensemble : ======
- Jeu du morpion fonctionnel (sans Bluetooth) ⇒ 24 avril
- Jeu du morpion fonctionnel (avec Bluetooth) ⇒ 27 avril

 

MB led: Liste des composants, modulation d’intensité et Python

Depuis vendredi dernier nous avons terminé d’établir la liste des composants qui serons utilisé dans chacun de nos blocs. Elle possède quelques différence avec celle du projet GLIP, leurs tranceivers IRDA ne sont plus disponibles, nous intégrerons un lecteur de carte microSD, nous rajoutons des résistances variables. Nous intégrons aussi à l’un des blocs le module recevant et émettant des informations en Bluetooth depuis un terminal Android. La liste détaillée se trouve ici .
Le coût total serait pour l’instant de plus de 1000€ pour 16 blocs et un module bluetooth ce qui parait excessif, il faut que nous trouvions une alternative afin de diminuer cette somme.
Nous nous sommes posées la question de la modulation de la puissance des LEDs bleus qui, d’après l’équipe de GLiP, serait 10 fois plus puissantes que les jaunes et rouges. Pour cela Samuel nous a conseillé d’utiliser une résistance variable réglable depuis en logiciel, l’idée serait d’en connecter une par colonne de led bleu (8 au total), nous les brancherions toutes sur la même sortie GPIO du micro-contrôleur, mais en mettre 8 prendrai une place considérable sur la carte. Nous cherchons des réseaux de résistances variables afin d’économiser de la place sur la carte.
Guillaume s’est intéressé ce week-end à la programmation en Python, langage qu’il ne connaissait pas, mais qui nous a été conseillé pour développer un environnement de simulation de notre réseau de bloc notamment pour son paradigme objet. Cela nous permettra avant même d’avoir les cartes de pouvoir définir précisément le comportement de notre système dans des scénarios variés. Cette environnement part du principe que les communications infrarouge se déroulent sans problèmes (trop grande portée de l’infrarouge, messages corrompus, temps de réaction trop lent etc) cela afin de bien séparer dans un premier temps matériel et algorithmie.
Voici une présentation de Gerard Padio qui traite d’algorithmie répartie et d’échanges d’informations entres modules dans un réseau pair-à-pair. Cela correspond exactement à ce que nous voulons faire. Nous pensons donc nous inspirer de ce protocole pour gérer les échanges inter-blocs.

Copterix : choix des composants

Nous nous sommes fixés sur l’électronique embarquée de notre drone. Nous restons sur une gumstix. Pour l’IMU, nous aurions voulu un chip ST  LSM303DLH avec magnétomètre et accéléromètre trois axes intégrés (5,25€), mais malheureusement il est devenu indisponible récemment. Nous prendrons finalement :

  • un accéléromètre 3 axes LIS302DLH – I2C, SPI – (4,74€)
  • 3 magnétomètres (un SEN-Z et deux Sen-XY)  – SPI – (32,50€)
  • un capteur de pression MPL115A1 numérique – SPI – (10€)
  • un gyroscope 3 axes IMU-3000 – I2C , série – (24€)

On mettrait aussi :

  • une caméra e-CAM32_OMAP_GSTIX qui sera branchée sur le port dédié de la Gumstix (70€)
  • un capteur Sharp  GP2Y0D02YK0F (15,16€) pour connaître notre altitude de manière plus précise lorsque le copter sera près du sol.

Coût des composants ~ 156€.

Coût total (avec la gumstix et une estimation du coût de fabrication de la carte) : 156+219+66.30=441€.

En parallèle, Axel et Samuel sont allés au département TSI pour des conseils sur un algorithme de tracking pour la caméra et il leur a été conseillé d’utiliser une méthode de flux optique. Il y a plusieurs implémentations possibles, mais la plus simple et la moins gourmande en ressources est l’algorithme de Lucas & Kanade. Nous nous renseignons plus en détails sur l’implémentation de cet algorithme.

Ce soir, sachant que l’on aura probablement une gumstix sur hélicoptère, Samuel a regardé de quelle façon on pouvait communiquer entre un pc et la carte pour flasher celle-ci. Il y a pas mal de tutoriel expliquant la communication.

[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.