ELECINF344/381

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

Catégories

[CASPER] Choix du système de fichiers

Comme décrit par le précédent post de Thomas, nous avons été amené à faire un choix quant au système de fichiers utilisé sur la carte SD afin de stocker le système d’exploitation.

Le choix en la matière est relativement large, notamment en ce qui concerne les systèmes de fichiers spécialisés pour les périphériques de stockage par blocs (ntfs, fat, extx et autres).

Les mémoires flash ne sont pas des mémoires à blocs tels que les disques durs, et notre attention s’est donc portée dans un premier temps sur les systèmes de fichiers spécialisés tels que JFFS, YAFFS ou encore UBIFS.

Ces systèmes de fichiers prennent en compte la durée de vie limitée des secteurs de la flash et répartissent donc leurs écritures sur toute la mémoire, ce qu’un système de fichiers par blocs ne fait pas, menant ainsi à la rapide destruction des secteurs fréquemment écrits, comme ceux stockant la table d’allocation par exemple.

Cependant une remarque des développeurs du système de fichier UBIFS a retenu notre attention: Étant donné que la plupart des cartes mémoires et clefs usb utilisent à présent le système propriétaire FAT qui ne respecte pas la fragilité de la mémoire et l’use rapidement, les fabricants ont donc décidé d’incorporer des chips FTL (flash translation layer) qui se chargent d’émuler un périphérique par blocs vu de l’extérieur, tout en répartissant les écritures en interne.

Ce faisant, les systèmes de fichiers par blocs de type FAT ou extx ne détruisent plus aussi rapidement la mémoire flash, mais les systèmes de fichiers spécialisés sont devenus inadaptés, bien qu’en principe plus efficaces car ayant une vue plus globale des écritures et lectures à effectuer sur la mémoire que la puce interne à la carte.

Ces systèmes de fichiers sont donc à recommander pour les mémoires flash pures, et déconseillés pour les cartes SD/MMC.

Notre choix s’est donc tourné finalement vers un système de fichiers par blocs.

Étant donné qu’un système de fichiers non journalisé limite le nombre d’écritures sur la carte, prolongeant ainsi sa durée de vie, notre choix final s’est donc porté sur l’ext2.

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

Présentation des études de cas

Voici les présentations des études de cas :

Dans l’ensemble, ces présentations étaient d’une grande qualité !

Copterix : début du projet

Voici une présentation de nos réflexions sur le projet :

Nous avons décidé d’utiliser une carte Gumstix pour la gestion de la caméra. Elle possède un DSP (traitement vidéo), du Wifi (commande du robot et débug),  et un OS libre. Elle est de plus petite et légère (comparé à une Beagleboard).

Ensuite, on designerait une carte centrale qui communiquerait avec la gumstix. Elle intégrerait aussi une centrale inertielle et se chargerait de l’alimentation. On hésite encore entre l’utilisation de la gumstix ou du stm32 de la centrale inertielle pour l’asservissement des moteurs.

Concernant la caméra, on en a deux en vue : la firefly et la e-cam32.
La première a le défaut d’être en USB et d’être grosse, par contre elle est en global shutter.  La deuxième est toute petite, on peut directement la brancher sur le port dédié de la Gumstix, par contre on ne sait pas encore si elle est en global shutter.

Voila, sinon on a établi une liste de PSSC, une répartition des rôles et un planning prévisionnel.

Attribution des présentations

Les présentations sont réparties de la manière suivante :

  • Git : Clément, Bertrand, Laurent, Vaibhav
  • Filtre de Kalman : Thibault, Caroline, Florian
  • PID / PWM / Pont en H : Siwar, Cédric LN, Samuel
  • Accès structuré (REST, COAP) et interopérabilité : Cédric H, Yoann, João Paulo
  • Contrôleur LQR : Thomas, Alain, Axel
  • Communication dans un système embarqué (IPv6, SD-card, USB) : Benjamain, Loïc, Theodoros, Guillaume