ELECINF344/381

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

Catégories

[Casper] Face tracking

We now have our face tracking algorithm running on BeagleBoard. Since a tracking only based on face detection was to slow and not very intuitive (you always have to look the camera), we decided to use a blob tracking algorithm, which we initialize with the face detection algorithm.

First, Casper looks for a face. When it finds one, it learns the associated color histogram. After what it tracks the histogram (with the OpenCV Camshift function), for a few tens of frames. If it does not find a face again during the blob tracking, it stops at the end of the frames. Otherwise, it keeps tracking the « blob » face.

We adopt a multithread program : a thread looks for a face every second, and a thread is responsible for blob tracking when a face is found. The first thread is used to set a counter which is decremented by the second thread.

 

[CASPER] Today’s news

We progressed in different fields today.

Alain designed a small extension PCB for the beagleboard. This board will include the necessary elements for audio amplification in and out, and for level shifting between the beagleboard’s output and the motors’ input.

At the same time, we worked with Thomas to build a first tracking system demo, by placing the webcam on top of casper’s body, connecting it to the beagleboard and then connecting the serial link to drive the motors. This demo gave some first results tonight, and will be kept under improvement.

Finally, we managed to create a custom language model and dictionary, which combined with the pocketsphinx engine’s data now allow the beagleboard to understand french vocal commands.

Copterix: motors control, 1st test

Sensors and effectors

For now, we configured all sensors and effectors:

  • The Sharp, the distance sensor, works in 1-5m range and we get values with 3cm precision
  • Inertial Measurement Unit (gyros, accelerometers and magnetometers return correct values)
  • Radio Frequency (remote control, see video)
  • Motors (see video)

Here is a small video where we directly control motors’ speed with remote control:

Communication

We now have a reliable communication between our PCB and the Gumstix, thanks to Samuel Tardieu’s help.
We mostly use ZeroMQ to share data between our processes and even between our computers !

Kalman

Kalman is quite smoothly, works as well on PC as on Gumstix, and we are now optimizing each operation. The actual filter is fast enough for real-time execution (we spend a lot more time to wait after data than to actually process it), but we want the filter to use less processor working time in order to execute other heavy tasks, like Lucas and Kanade (video tracking algorithm).
We do now have a way to get by Wifi only the Kalman’s results in order to display them on a PC using OpenGL as you could have seen it on our previous videos.

Next step

We are now up to test for the first time real servomechanism PID on our Copterix !

Copterix : état des choses pour ce vendredi soir

I2C, et PCB en général

Samuel et moi-même avons pu finalement communiquer avec les gyroscopes de notre PCB, non sans mal (cf le post d’hier soir). Nous avons donc été en mesure de montrer un exemple de récupération des données des gyroscopes, accéléromètres et magnétomètres en temps réel lors des démonstrations de cet après-midi. Le programme de ce weekend de ce côté-là serait donc de discuter à présent avec les moteurs.

Communication avec le PCB

Loïc a fait une petite démonstration de sa gestion des erreurs lors des transmissions de paquets entre le PCB et un PC. Certains points restent à éclaircir, comme notamment le compte des erreurs et la gestion des coupures.

Tracking

La démonstration du tracking ne s’est pas vraiment bien passée : effectivement, nous n’avons pas défini de protocole de test rigoureux, ce qui fait que nous avons une très mauvaise estimation des capacités réelles de notre tracking à l’heure actuelle. De plus, à cause de fuites de mémoires dans openCV non encore résolues, le programme tourne pendant 3 minutes avant de devoir s’arrêter faute de RAM. Un gros effort reste donc à fournir de ce côté-ci, mais cette fonctionnalité n’étant pas vitale pour faire voler l’hélicoptère, elle n’est pas en haut de la liste des priorités.

Kalman

Notre implémentation du filtre du Kalman en test avec les données d’une IMU gentiment fournie par Samuel Tardieu n’a pas fait une grande impression sur le jury, le fait qu’il était facile de l’affoler en secouant un tout petit peu la carte ne devant pas y être étranger. Une explication possible mise en avant par Alexis serait que nous avons mal pris en compte l’orientation des gyroscopes : je vais donc m’y pencher dès que possible pour essayer de résoudre ce problème, qui lui est vital pour la bonne marche du projet.

Copterix : Omap & Camera

Aujourd’hui, j’ai installé Ångström sur la Tide, avec un kernel 2.6.34 patché pour supporter la pixhawk.

La caméra marche ; la chaîne de compilation est installée. Il reste à tester opencv pour voir les performances du tracking vidéo.

Le driver que nous utilisons pour la caméra nous permet d’utiliser cette dernière comme un périphérique V4L2. Samuel s’est donc renseigné sur l’API V4L2. Il a commencé à développer un programme pour pouvoir récupérer des images de la caméra. Il utilise principalement plusieurs appels à ioctl() pour configurer pas mal de chose comme notamment le format des données ou le type des buffers utilisés.  Cela sera utile si on n’utilise pas opencv.

 

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] Définition de l’architecture

Nous approchons d’une architecture définitive.

Nous pensons utiliser une beagleboard car elle permet de faire du traitement audio/video (DSP) et dispose d’une puissance de calcul conséquente. Nous embarquerons certainement un linux pour ne pas avoir à réécrire les drivers type webcam etc et faciliter les traitements.

La partie mécanique sera gérée par une carte que nous allons fabriquer avec un STM32. Elle recevra les consignes issues de la beagleboard (du tracking video et du gestionnaire d’émotions) et commandera en conséquence les servomoteurs.  Il va falloir écrire des drivers linux pour que cette carte soit considérée comme un périphérique par la carte maîtresse.

 

Architecture de CASPER

Pour les différents mouvements du robot nous envisageons (principe fourni par M. Polti), d’utiliser un système de trois tiges semi-rigides reliées d’une part à des moteurs et à un plan de l’autre. (voir le système en action) Ce système permet de bien reproduire les possibilités motrices d’un cou. On aurait également un moteur pour effectuer des rotations complètes du robot.

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