ELECINF344/381

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

Catégories

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