ELECINF344/381

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

Catégories

[CASPER] New video

We posted a new video showing our group performing with casper :

- Video tracking

- Dancing

- Mail fetching

- Vocal commands

 

[CASPER] can fetch and store mails

We made some improvements in our mail fetcher. Now, it’s able to fetch mails from most mail server ( pop3, secured or not). It can fetch the last mail received and store its content and subject into a file, so it can be read by our text-to-speach engine.

Moreover, we had the mail fetcher work in the Beagleboard.

As a reminder, we are using the C++ library Vmime 0.9.1.

[CASPER] Fetching mails

We started to work on the first web service we would like to have casper use : MAILS.

We choose to use the C++ library Vmime which support many protocols such as pop or imap. It also has functions to parse the retrieved mails and get only the parts interesting to us.

We wrote a program able to connect in POP3 to the pop3.free.fr mail server (which allows unsecured connections). Giving a login/password pair this program is able to print a mail (the first of the list for now).

We are now working on organizing and selecting the right data from the mail server.

 

 

[CASPER] PSSC

After some over-the-internet discussions, we finally agreed on the following list of goals and milestones :

A interface task is placed between SVOX Pico and ALSA on the beagleboard  – 04/18  Thibault
The beagleboard and Casper PCB communicate over an UART link – 19/04  Alain
We store and read images to and from the flash memory on the Casper PCB – 20/04  Alain
We are capable of having the beagleboard read a text file out loud – 20/04 Thibault
The beagleboard is able to recognized predetermined vocal commands – 21/04  Thibault
The LCD display adapts itself according to the robot’s orientation – 22/04  Alain
We are capable of controlling the robot’s tilt angle  -  22/04  Thomas
We are capable of controlling the robot’s orientation (azimuth) – 22/04   Thomas
The robot as been assembled, and the devices (camera, PCB, …) are on board – 23/04  Thomas
We can make the robot track a face (the robot’s orientation follows slow mouvements) – 25/04   Alain
The API we previously defined is accessible from LUA scripts - 27/04   Thibault
The robot is capable of accessing a simple mail box (without encryption protocols) – 28/04   Alain
The robot has a simple remote http setup interface – 29/04   Thomas
We use a LUA script, using the API, to drive the robot for the demo – 29/04   Thomas
The servomotors are being driven by a linux device driver on the beagleboard – 29/04  Thibault

TSV Safe Express: à partir de carte TP à la carte réelle

Pendant le week-end, nous avons essayé de stabiliser le protocol de NMRAnet (CAN bus) avec trois cartes. Nous avons réussi avec 3 cartes mail il y avait beaucoup de problèmes quand on utilise plus que un carte pour le nœud. Les plus importants sont:-
Pour rappel, nous avons 3 cartes – Un carte central station, 2 qui sont nœuds.
1. Premier nœud se timed out lorsque le deuxième nœud entre dans le réseau –
Raison- Il y avait trop des paquets à partir de le nouvelle carte parce que Il se fait programmé. Alors, le « network manager » supprime le premier nœud s’il ne reçoit pas le paquet état ​​dans un délai prédéterminé.
Solution- Utilise le CAN Filter qui lui permet de recevoir que les paquets qui le concernent. ça va dire , une fois le filtre statique est installé, les nœuds ne recevraient pas de paquets qui sont envoyés par d’autres nœuds soit le gestionnaire du réseau (« Network Manager »)ou de l’outil de configuration(« Configuration Tool »).
Futur Développement possible – Actuellement, pour les évènements de carte feux(« Consumer ») il n’y a pas de filtres qui signifie que chaque noeud reçoit les événements qui sont générés par d’autres. Pour cela, nous avons besoin d’installer des filtres CAN dynamiquement en fonction du nombre d’événements qui lui sont donnés par le gestionnaire du réseau. Nous le ferons en fonction de comment ça se passe avec les 12 attendus plus de cartes.

2. Redémarre de le nœud ne marche pas –
Raison – Si le redémarrage est très rapide, le nœud n’a pas reprogrammé par l’outil de configuration. C’est parce que le gestionnaire de réseau n’a pas assez de temps pour lui de supprimer de sa table nœud.
Solution – Après le redémarrage, le nœud inactif pendant 3 secondes qui donne la gare centrale de suffisamment de temps pour lui supprimer.
Futur Développement possible – Au lieu de dormir aveugle de 3 secondes, l’introduction de l’Etat en fonction le contrôle opérationnel au niveau du « Network Manager ».

3. Redémarre de le station central –
Raison – Depuis le nœud est déjà programmée, ainsi qu’il ne devient pas programmé encore par l’outil de configuration.
Solution – Au démarrer de la gare centrale, il envoie une commande broadcaste à tous les nœuds de se réinitialiser.
ça marche mais avec deux carte, ça ne marche plus. Juste une carte, qui devient programmé. Nous sommes en train de trouver la raison.

Pour le Carte Feux (pas de TP) – Nous avons réussi avec CAN et nous pouvons contrôle cette carte à partir de station central. Maintenant, Theodoros, il est en train de travailler sur le SPI. Siwar continue de travailler à CAN bootloader. Vaibhav travaille sur le code existant.

[CASPER] Architecture et liste de composants

Architecture globale

 

La beagleboard est l’élément central du système (www.beagleboard.org). Elle est chargée des algorithmes de haut niveau tel que le traitement de la vidéo et le traitement audio. C’est aussi elle qui se chargera de la connectivité internet et du pilotage des actionneurs.

Elle sera étendue par une carte embarquant un contrôleur STM32 chargé de piloter un écran LCD à partir de données stockées dans une mémoire flash.

Les informations sur les composants requis sont fournies dans les paragraphes suivants, les informations détaillées concernant les actionneurs/servomoteurs seront publiée dans un prochain post.

 

Ecran

Color LCD 128×128 Nokia Knock-Off

http://www.sparkfun.com/products/569

Avantage : bien documenté

Connexion au STM32 : un seul port SPI (pas de bus data)

Rq : sparkfun indique vendre un « loose connector » pour 2$ sur la même page, qui apparemment facilite le soudage…

Accessoires écran

1 transistor pour contrôle du rétroéclairage (http://fr.farnell.com/nxp/bc846/transistor-npn-boitier-sot-23/dp/1081227)

1 régulateur tension de 7V (pour le rétroéclairage).

Le modèle choisi sera finalement un LT1932 (http://fr.farnell.com/linear-technology/lt1932es6-pbf/ic-dc-dc-convert-led-dr-6sot2/dp/1651929). Il s’agit en réalité non pas d’un régulateur de tension mais d’une source de courant spécifiquement conçue pour alimenter une ou plusieurs leds.

Pour fonctionner, ce régulateur a besoin outre quelques résistances et condensateurs, d’une diode schottky (http://fr.farnell.com/rohm/rb050la-40tr/diode-schottky-40v-3a/dp/1680015) et d’une inductance de 6.8µH telle que celle-ci http://fr.farnell.com/panasonic/eljfa6r8jf/inductance-1210-6-8uh/dp/3838341 qui peut se commander à l’unité.

Carte STM32

1 STM32F103CBT6 (ou modèle équivalent, on a juste besoin d’un port SPI pour l’écran, un deuxieme pour une mémoire flash, un UART pour la liaison avec la beagle, et le reste des I/O serviront pour les extensions éventuelles)

1 régulateur 3.3V (L4931CD33)

1 prise jack pour l’alimentation

1 quartz 8MHz

1 prise JTag

1 switch (pour le reset…)

1 connecteur UART

1 transceiver UART (http://radiospares-fr.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=6608802)

1 connecteur 6 broches (pour le SPI)

1 mémoire flash http://fr.farnell.com/spansion/s25fl032k0xmfi011/memory-flash-32m-3v-spi-8soic/dp/1861630 , qui servira à stocker les images pour le lcd

À noter : la fréquence de fonctionnement de cette flash (104MHz) laisse une marge suffisante pour récupérer des images 128*128 couleur à envoyer au LCD afin de l’animer. C’est en pratique le microcontrôleur qui limitera la vitesse de fonctionnement.

 

Son

Haut-parleur

2 Haut-parleurs MCKP2852SP1F-4752 (Ref Farnell 1801037, http://fr.farnell.com/multicomp/mckp2852sp1f-4752/dp/1801037)

Ce modèle est suffisamment petit pour pouvoir l’intégrer au visage de casper. Le deuxième pourra être placé dans le socle

 

Microphone

5 Micro pastille MCKPCM-40H15-40DB-4797 (Ref Farnell 1758416, http://fr.farnell.com/multicomp/mckpcm-40h15-40db-4797/microphone/dp/1758416)

Ce modèle a l’avantage d’être très plat (1.5mm) ce qui permettra de l’intégrer plus facilement. Plutôt que d’ajouter juste un micro à Casper, nous pourrions en ajouter 3 ou 4 autres à la base qui pourraient servir à la détection de la provenance du son. On peut alors imaginer toutes sortes de réactions du robot.

À noter : chaque microphone a besoin d’un petit circuit de polarisation, composé d’une résistance et d’une capacité de 5µF.

WiFi

Étant donné la présence de l’USB hôte sur la Beagleboard, nous pouvons pencher pour une solution de clef USB Wifi facilement trouvable dans la grande distribution (http://www.grosbill.com/4-bluestork_cle_wifi_nano_usb_wifi_n_150mbps-80561-reseaux-carte_reseau_sans_fil)

Une carte Wifi de facteur de forme SD pourrait toutefois être essayée (?).

Camera

Nous utiliserions là encore une Webcam très classique (http://www.grosbill.com/4-logitech_c120-100684-peripheriques-webcam) reconnue par linux.

Nous sortirions les différents composants de la coque de la caméra afin de pouvoir les intégrer dans un volume compact.

 

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

Laser, début de l’aventure

Premier post sur le blog pour les débuts de la conception du laser. Voici brièvement ce que chacun a fait et ce que le groupe a fait.

En groupe : réflexion sur l’architecture globale, comment organiser le tout ? Où mettre l’intelligence ? Pour l’instant, on aurait au centre un processeur (est-il fourni ou doit-on le choisir ?) avec un Linux qui s’occupe de récupérer les infos venus de l’interface de contrôle (modération du contenu venu d’internet, probablement processing du texte, passage d’ordres simples, …), de piloter le laser. On doit aussi gérer du DMX, probablement avec un FPGA.
L’utilisation de Twitter est un peu contraignante (les gens doivent être sur Twitter),  on pense à une interface mail (au moins en plus de Twitter et /ou Facebook)

Caroline : s’est renseignée sur la carte K12N (interface avec la carte laser), le format ILDA, le signal ILDA, le bus ILDA-DB25

Laurent : a commencé d’étudier le protocole DMX, rapide proof of concept en python que l’interface mail ne posera pas de problème

Yoann : réflexion sur la manière d’organiser la modération, de gérer/stocker les images (carte et modération), découverte de l’existence d’une lib Python pour faire du processing de langage naturel (pourra servir plus tard),  ILDA – DB25 avec Caroline.