ELECINF344/381

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

Catégories

Copterix: Lucas and Kanade

Today, we began to write some articles for the website and we mainly worked on Lucas and Kanade algorithm. We did some tests and we have some good results when the camera is recording pictures from the ceiling, but we have bad results when they are from the floor. Here is some illustrations:These pictures represent the evolution of the helicopter movement (x and y). The first picture was taken when the camera was watching the floor held by Loïc. We cannot distinguish a good evolution of the motion.

For the second picture, the camera was oriented to the ceiling. The copter was put on a table that we could move. The first peak represents a slow movement in one direction and a fast movement in the opposite direction. The second peak represents the same experiment with the introduction of some manual oscillations.

Tomorrow, in order to solve these problems, we will first of all apply a low pass filter and we will try to use a draughtboard on the floor with a good lighting.

[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

Architecture logicielle de Copterix

Aujourd’hui, après m’être renseigné sur 0MQ, pour le dialogue entre les différents modules de notre futur Copter, j’ai essayé de fixer l’architecture logicielle qu’on pourrait utiliser, à travers un schéma. Le voici, suivi de quelques explications :

 

Le STM32, qui fonctionnerait sous FreeRTOS, est directement relié aux capteurs et actionneurs de la carte. Ceci est nécessaire, notamment pour l’acquisition des données fournies par les capteurs : le filtre de Kalman nécessite que les données de tous les capteurs soient acquises presque en même temps. Il nous faut donc du vrai temps-réel, d’où l’intérêt du STM32 sous FreeRTOS.

 

Tournant sur la Gumstix :

Un module serait dédié aux communications avec le STM32 via l’UART. Ce module ferait des updates régulières des données des capteurs pour le filtre de Kalman, via les bibliothèques 0MQ.

Le filtre de Kalman fait l’objet d’un module à part, qui se chargerait d’envoyer régulièrement des updates au module de contrôle, pour lui indiquer l’attitude de l’objet.

D’autre part, la caméra fournit un flux vidéo (via l’API Video4Linux), qui sert comme source pour le filtre de Kanade, afin d’estimer la vitesse en translation de l’hélicoptère, fournie ensuite au module de contrôle. On aurait pu envisager d’inclure cette vitesse au filtre de Kalman, mais ce renseignement n’étant pas obtenu au même moment que les données des autres capteurs, il nous semble nécessaire de traiter séparément l’asservissement en attitude et l’asservissement en translation, quitte à utiliser un autre filtre de Kalman pour la vitesse.

Au niveau du streaming vidéo via wifi, je pense qu’on aurait pu se servir de GStreamer afin d’envoyer un flux compressé via Wifi, mais nous avons laissé cette possibilité de côté pour le moment : l’utilisation de la caméra et du filtre de Kanade semblent déjà trop gourmands en ressources pour qu’on puisse se permettre cette fantaisie. Pour le moment, Axel s’occupe de voir s’il est possible d’améliorer les performances, trop faibles pour l’utilisation du filtre de Kanade. Nous verrons donc plus tard si nous pourrons réenvisager de faire du streaming vidéo.

D’autre part, un module de communication en Wifi serait chargé de transmettre des « ordres » reçu d’un ordinateur ou smartphone au module de contrôle.

 

En revanche, il y a un problème dans cette architecture : le module (matériel) radio-fréquence est connecté directement sur le STM32. Or, les ordres reçus via RF devraient idéalement être transmis au module de contrôle. Je vois différentes solutions à ce problème :

- Transmettre les ordres RF reçus à la Gumstix, via l’UART. Mais cela semble être un chemin assez compliqué (et inutile) pour ces ordres.
- Contrôler les actionneurs selon les ordres donnés par la Gumstix, sauf quand on reçoit des ordres RF. Mais cela me semble difficile comme solution (comment faire en sorte que l’asservissement n’annule pas aussitôt les commandes transmises via RF?)
- Déporter la partie logicielle de contrôle sur le STM32, ce qui permettrait en plus de décharger la gumstix d’une partie de sa charge. (après tout, je ne sais pas ce qui m’a poussé à considérer la partie contrôle sur la Gumstix, et pas sur le STM32)

Je pense que la meilleure solution serait plutôt la troisième, mais j’attends quand même de voir ce qu’en pensent les autres.

 

De leur côté, Samuel et Bertrand ont fini les schematics du PCB, et le routage est en cours, il devrait être bientôt fini, comme prévu.

Copterix : vision et autres avancements

OS:

On a laissé tomber angström pour ubuntu et on l’a installé sur la carte.

Tracking:

La caméra a la mauvaise habitude de rendre des images en « fish eye », j’ai donc utilisé OpenCV pour arranger tout ça, et voici les résultats:

À gauche, l’image telle qu’elle est reçue par la caméra et à droite après application d’OpenCV.

On a aussi compilé mon code qui renvoie le vecteur déplacement détecté sur la Gumstix et on l’a testé, mais on tourne à une image par seconde…
Après test via Cheese, il s’avère que la résolution de la caméra est trop élevée, ce qui explique son si faible débit, je m’apprête donc à y remédier.

Physique:

On a continué à réfléchir, on a vu Wahba et Kalman. Samuel veut coder le FQA, qui résout le problème de Wahba. On aura un post sur la physique demain plus complet.

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 : Architecture

Quelques changements depuis mon dernier post :

  • On remet le stm32 (stm32f103RE) pour deux raisons : multiplexer les sorties des capteurs et surtout avoir un os temps réel (FreeRTOS) permettant de prendre des échantillons en même temps sur l’ensemble des capteurs, indispensable pour Kalman.
  • On change de gumstix (problème de disponibilité). On prend finalement l’Overo Tide COM avec une TOBI (carte d’extension).
  • On branchera notre PCB sur la TOBI avec un connecteur barrette.
  • On remplace notre caméra par la Caspa FS à laquelle il faudra ajouter un filtre infra-rouge
  • On branchera un dongle Wi-fi sur la tobi
  • On utilisera le transceiver RF pour piloter le copter avec la radiocommande.

 

J’ai aussi fait l’assignation des pattes du STM32 pendant que Samuel commençait le PCB sur Mentor Graphic.

 

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

 

RoseWheel : le retour !

Après une semaine bien dense pendant laquelle certains ont pu travailler sur Kalman et d’autres sur LQR, nous avons aussi avancé dans notre recherche de composants mais il reste encore quelques incertitudes.
Sachant que nous allons partager nos efforts avec Copterix pour les tests des gyroscope et accéléromètre, nous allons prendre les mêmes qu’eux.
Un bon schéma vaut toujours mieux qu’un long discours, voilà donc l’architecture de notre système :
Schéma RoseWheel-AndroWheel

Architecture du projet

 

Pour télécommander notre RoseWheel Nous utiliseront probablement le bluetooth puisque c’est sur tous les téléphones. Nous avous estimé que du bluetooth 2.0 (~1.4MB/s) class2 (portée ~10m) devrait largement suffire pour une première version. De plus, nous aimerions vraiment implémenter un retour vidéo mais ça va dépendre du temps qu’il nous reste.

Si le temps se fait rare, nous pourrions envoyer la vidéo au téléphone sous android grâce à une « caméra wifi » de ce genre :

http://www.bewan.fr/entreprise.php?page=entreprise&parm1=presse&parm2=communique&id=47

=> Nous l’avons trouvé à 56€ ici :

www.cdiscount.com/informatique/materiel-reseau-wifi-internet-bluetooth/bewan-icam-100n-bwbc-100n/f-10715290802-bwbc100n.html

Si nous n’arrivons pas à connecter la caméra directement au téléphone, cette solution impliquerait de passer par un routeur, de streamer la vidéo sur un serveur et de s’y connecter avec l’android.
Si cette solution ne marche pas non plus, nous pensons utiliser une beaglebord ou une gumstix pour y brancher une caméra et envoyer la vidéo au téléphone sous android.

Nous avons plusieur solutions :

- par bluetooth 3.0 (24Mb/s) avec un dongle usb pour une vingtaine d’euros en plus (Nous pourrons utiliser le samsung galaxy S qui  a le bluetooth 3.0 mais sinon c’est rare)

- par wifi, plus démocratisé, mais c’est plus compliqué à utiliser.

La beaglebord a l’avantage d’embarquer un DSP et du wifi mais même si c’est moins cher, c’est bien plus gros qu’une gumstix.

Nous verrons plus tard les codecs de compression vidéo utilisables mais à priori ça suffit largement. Nous devrons donc faire tourner un petit linux dessus ce qui fera grand plaisir à certain d’entre nous ;)

Nous avons également étudié plus en détail la physique du système.
La thèse de Rich Chi Ooi présente un modèle physique assez complet décrivant un gyropode comme une combinaison de trois sous-systèmes : les moteurs, les roues et le chassis.
Nous avons donc refait les calculs pour être surs de les avoir compris et pour éclaircir les points sur lesquels l’auteur passe rapidement.
Par ailleurs ce dernier donne une modélisation intéressante des moteurs à courant continu mais le principe physique des moteurs brushless étant différant, nous devrons peut être réfléchir à un modèle plus approprié.
La modélisation de notre système sous la forme x’= Ax + Bu nous permettra prochainement de mettre en application le cours sur le LQR donné vendredi par nos collègues.

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.