ELECINF344/381

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

Catégories

[CASPER] API update and software architecture

During these past weeks, we implemented several features in separate demonstration programs.

The time as now come to merge these features in a common architecture. For this purpose we revised the API we previously defined, in order to better fit our prototype and libraries.

Then we drew a schematic representation of casper’s software architecture, which should have a LUA script interpreter as the central element. This script interpreter will communicate with the other libraries by posting/retrieving data in a producer/consumer scheme, an exception being the configuration transactions.

The new version 0.2 of the API can be downloaded here: Casper API.

The software architecture is available in pdf file format here: architecture.

Copterix : finalisation du filtre de Kalman

Alors, comme nous l’avons dit hier, cette journée a été dédiée aux tests du FQA et du filtre de Kalman sur une IMU. On récupère les données brutes des capteurs (3 gyroscopes, 3 accéléromètres et 3 magnétomètres) par un script python. Le Kalman qui sera implémenté sur la Gumstix est en C++. Il a donc fallu dans un premier temps faire communiquer le script python et le programme C++ afin d’acheminer les données des capteurs vers notre Kalman. Nous avons pour cela utilisé ZeroMQ avec une architecture Publisher/Subscriber.

Une fois la communication fonctionnelle, nous avons pu commencer à tester notre FQA et notre Kalman. Au début, nous avions pas mal de problèmes au niveau de l’orientation de nos axes. Mais après avoir passé pas mal de temps à étudier les sorties des capteurs pour comprendre selon quels axes ils étaient positionnés, nous avons obtenu des résultats plutôt satisfaisants :

Dans la première vidéo , nous n’utilisons pas le filtre de Kalman (juste le FQA) alors que dans la seconde, le filtre de Kalman est activé. L’utilisation du filtre permet d’éliminer pas mal de bruit. Il reste tout de même quelques petits détails à régler car il y a quelques indéterminations qui chamboulent un petit peu le filtre.

Nous avons en outre reçu notre PCB :

La journée de demain sera consacrée à établir la communication avec notre nouvelle carte !

[CASPER] Beagleboard, pilotes et pwm

Voici un petit compte rendu de ce que Thomas et moi-même avons réalisé hier et aujourd’hui.

 

Bootstrap

Partant de ce que Thomas avait réalisé précédemment, nous avons automatisé l’installation de la carte SD pour la beagleboard. En effet, celle-ci doit contenir dans une première partition FAT les fichiers du noyau nécessaires au démarrage, et sur une deuxième partition du format de notre choix la racine du système de fichiers.

Afin de pouvoir choisir plus finement quel noyau et quel paquets nous souhaitons installer sur notre beagleboard, et pour pouvoir la placer rapidement dans une configuration « prête à utiliser » lors d’une éventuelle réinitialisation, nous avons choisi de ne pas utiliser les images de rootfs proposées sur internet par la communauté de développeurs beagleboard.

Nous avons donc construit notre propre image rootfs à l’aide de l’outil debootstrap couplé à l’émulateur qemu, ce qui permet de créer sur un ordinateur portable classique une distribution pour une architecture arm, par exemple. Nous avons inclus de nombreux paquets tels que la bibliothèque opencv qui nous sert pour le traitement de l’image, et SVOX pico, qui nous sert pour la synthèse vocale.

Nous avons ensuite configuré la distribution afin d’obtenir une console sur le port série et paramétré la distribution afin de la rendre directement utilisable.

Ces étapes ont été totalement automatisées dans un script, ce qui nous permettrait éventuellement de regénérer tout ceci très rapidement, tout en faisant évoluer nos paramètres.

Nous avons ensuite généré les fichiers de boot à partir du noyau de sorte qu’il supporte le système de fichiers nilfs2¹ (Le garbage collector du nilfs2 sera lancé automatiquement, dès lors que les paquets nilfs-tools et nilfs2-tools sont installés sur le système. Il faut donc les ajouter dans le script debootstrap_init.sh).

 

Le système de fichiers nilfs2 offre en résumé deux avantages : sa structure garantit l’intégrité des fichiers écrits ce qui évite la corruption de la carte en cas de coupure de courant ou de plantage et il offre d’excellentes performances sur la carte SD en comparaison avec l’ext2 par exemple.

Cela est certainement dû à sa structure circulaire, et à son mode de fonctionnement avec garbage collector. En effet, les fichiers supprimés ne sont pas effacés immédiatement, ce qui aurait pour effet de ralentir les opérations. Ces effacements ne sont réalisés que beaucoup plus tard, à la fin d’un compte à rebours ou lorsque les segments propres sont en nombre insuffisant. Ainsi, l’écriture est rapide puisque sans effacement, et l’effacement est retardé ce qui à nouveau permet de gagner beaucoup en vitesse de fonctionnement. (L’installation de paquets logiciels est aussi rapide que sur un ordinateur moderne avec nilfs2, ce qui était loin d’être le cas avec ext2 puisqu’en fonction des dépendances, il fallait entre 15 et 60 min)

 

Ensuite, un autre script que nous avons réalisé automatise la génération d’une archive tarball rootfs.

Une version adaptée du script setup_sdcard.sh (http://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh) nous permet ensuite, là encore de manière automatisée, de formater la carte mémoire et de créer les partitions, de générer les fichiers uImage et uBoot, et enfin de copier les fichiers de boot et d’extraire le tarball rootfs sur les partitions correspondantes.

Nous avons de plus écrit une notice détaillant l’utilisation de ces scripts en vue de générer rapidement une installation pleinement fonctionnelle et incluant tous les paquets logiciels nécessaires sur la carte SD.

 

¹ Merci PHH pour les conseils !

 

 

Pilotes et PWM

Thomas continue de se pencher sur la question des pilotes. Il a réalisé un helloworld que nous ne pouvions malheureusement tester sur la beagleboard, du fait que celle-ci était immobilisée par les opérations de préparation de la carte SD. Maintenant que celle-ci est prête, nous allons pouvoir tester la compilation et l’installation dynamique de ce module de communication helloworld dans le noyau.

Étant donné que la beagleboard n’était pas prête, et outre sa participation à la création de la nouvelle distribution au travers de son expérience précédente avec la première installation que nous avions réalisée avec le script setup_sdcard.sh, Thomas a continué de se documenter sur la réalisation de pilotes et sur l’utilisation des modules PWM sur la beagleboard.

RoseWheel : avancées post-soutenance

Depuis la soutenance de mercredi matin, nous avons essayé d’avancer sur trois aspects de notre projet :
- Simulateur : nous avons commencé à écrire un nouveau module pour tester seulement la modélisation des moteurs, étant donné que nous avons toujours des résultats inacceptables au niveau de la tension requise pour l’équilibre. En parallèle, nous vérifions les équations du modèle physique général, pour essayer de trouver les erreurs « cachées » ;
- Banc de test : après avoir mis une référence plus visible pour lire le rapporteur, nous avons calibré à nouveau le moteur. Désormais, il reste intégrer ce nouveau calibrage au potentiomètre pour pouvoir savoir exactement la position où se trouve le moteur, et ainsi reprendre nos tests avec une meilleure précision. Voici l’état actuel de notre dispositif :
- Cartes : nous avons commencé à réflechir à la l’implémentation des drivers pour les divers périphériques. Nous voudrions utiliser une architecture plus générique que celle que nous utilisions pour le TP STM32. Suite à quelques essais il semble difficile de faire des fonctions génériques de configuration de périphériques sans faire trop compliqué (fonctions longues, bricolage sur les masques et les offsets…) ; peut-être que des macros préprocesseur seraient plus adaptées… nous explorerons d’autres pistes demain. Nous allons tout de même essayer de faire simple et ne pas implémenter plus de généricité que nécéssaire pour nos deux cartes.

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.

[CASPER] Prototype mécanique du robot.

Cette semaine, nous avons réalisé un prototype de la partie mécanique du projet.

Nous avons une tige centrale renforcée pour soutenir le dispositif de la tête, celle-ci est fixée à des plaques intermédiaires qui guident les fils de contrôle (tiges en carbone).

Cette architecture nous conduira à utiliser des actionneurs linéaires pour tirer sur ces fils de contrôle.

Vidéos du prototype en action :

MB Led : architecture fonctionnelle

Durant cette semaine, nous nous sommes surtout focalisés sur le TP STM32. Cependant, nous avons revu notre choix des composants pour MB Led.
Nous avons trouvé – merci Alexis – le TCL59116 de chez Texas Instrument. C’est un driver de LED où le contraste de chaque LED est programmable en soft. Ainsi, il serait possible d’avoir la même intensité pour toutes les LEDs. Etant donné qu’il contrôle seulement 16 LEDs, nous en prendrons deux. Le STM32 communiquera avec les TCL59116 par bus I²C, ce qui ne changerait pas notre brochage.
Pour le reste des composants, nous ne changeons pas notre choix initial (cf https://spreadsheets.google.com/ccc?key=0AncMdD-cz6M-dE5adzNDWkNnel9qNzd3LU1faUpuNEE&authkey=CNSan78L&hl=en#gid=0 )

Durant ce week end, j’ai aussi continué de programmer le test bench en Python. L’apprentissage du python se fait difficilement mais j’arrive à communiquer entre deux threads, c’est déjà un bon début.

Voici notre architecture fonctionnelle : les 16 blocs ont la même face recto et pour le verso, un des bloc intègre un module Bluetooth tandis que les autres ne l’ont pas.

 

TSV Safe Express: architecture

Bonjour à tous,
La carte principale (au milieu) prend les commandes de Rocrail et les code, puis les envois à travers le bus CAN ou à travers les rails. Nous ne sommes décidés pour le STM32F107 pour cette carte puisqu’il contient un module ethernet et puisque nous avons trouvé un tranceiver CAN avec une interface RMII.
Pour les petites cartes avec CAN nous utilisons STM32F103T4 puisqu’elles sont les moins chers dans les STM32 qui contiennent une interface CAN. Il est à citer que programmer les cartes d’une même famille est plus simple.
Pour la carte feu qui commande seulement en DCC, nous utilisons le STM32F100 qui est le moins cher (2.35E).
Merci pour vos commentaires.

 

RoseWheel : Choix des composants – Architecture matérielle

La réunion de vendredi avec Alexis et Samuel nous a permis d’éclaircir un certain nombre de points. Nous avons ainsi pu établir aujourd’hui un choix quasiment définitif de nos composants ainsi que l’architecture  matérielle de RoseWheel.

Le système est composé de 3 cartes :

  • Une carte mère contenant toute la logique
  • Une carte de puissance permettant de contrôler les moteurs Brushless
  • La carte de puissance permettant de contrôler les moteurs DC du projet ZZAAG

La carte mère qui se trouvera sur le guidon contient :

  • 1 processeur STM32 qui sera en charge de traiter les calculs nécessaires à l’implémentation du filtre de Kalman pour la fusion des capteurs ainsi que les calculs pour l’algorithme d’asservissement des moteurs. Concernant cet asservissement, nous avons choisi dans un premier temps d’implanter un PID. Ensuite nous nous dirigerons vers l’implémentation d’un LQR
  • Les capteurs permettant le contrôle de l’équilibre, soit le gyroscope et l’accéléromètre
  • 3 UARTs, pour une connexion RS232 pour le debug, une connexion Zigbee, une connexion Bluetooth
  • 1 LCD permettant d’afficher des informations pour l’utilisateur
  • Des jumpers ADC pour la connexion d’une partie des Sharps pour la détection des obstacles
  • 1 port CAN bidirectionnel permettant de communiquer avec la carte de puissance de contrôle des moteurs Brushless

La carte de contrôle en puissance des moteurs Brushless qui permettra aussi, dans un premier temps, de faire l’interface entre la carte de contrôle de puissance des moteurs DC du ZZAAG et la carte logique. Cette carte contient :

  • 1 processeur STM32 permettant de générer les PWM nécessaires au fonctionnement, d’une part des moteurs DC sur la carte du ZZAAG, d’autre part les PWM permettant de gérer le contrôle des moteurs Brushless
  • 1 connecteur CAN bidirectionnel fin de communiquer avec la carte mère logique différentes informations. Notamment les données permettant l’asservissement des moteurs
  • 1 jumper pour la connexion des Sharps nécessaires à la détection des obstacles à courte distance
  • 1 jumper pour la connexion des encodeurs
  • 3 ports pour la connexion des données provenant des capteurs à effet Hall du moteur Brushless et permettant de gérer le contrôle de ces moteurs

La carte de contrôle de puissance du ZZAAG qui sera contrôlée par la carte de contrôle de puissance des Brushless et qui ne nécessite en entrée que 2 PWM (1 pour chaque moteur) ainsi que 2 autres entrées permettant de contrôler la direction.

Le choix plus précis des composants est à priori :

Accéléromètre : LIS3LV02DL – 3 axes – port SPI – boitier LGA-16 – fréq échantillonnage 640 Hz – prix : 15,09 €

Gyroscope : IMU-3000 – 3 axes – port I2C – boitier QFN – fréq échantillonnage 8000 Hz – prix : 34,98 €

Encodeurs : HEDS-5500#A06 – Vmax 30000 tour/min ( un peu beaucoup mais moins cher ) – fréq échantillonnage 100 kHz – prix : 50,07 €

Bluetooth: AMB2300 – prix : 29,04 €

Xbee : XBP24-AWI-001 – prix : 30,62 €

LCD : MDLS16265LED043V – prix 39,29 €

Sharps :

  • GP2Y3A003K0F – Min distance : 20cm – Max distance : 150cm  - Angle de vision : 25°  - prix 55,35 €
  • GP2Y0A710K0F - Min distance : 40cm – Max distance : 300cm  - Angle de vision : 25°  - prix 25,57 €

Capteurs ultrason :

  • MSU05 – Angle de détection plus large que les Sharps (55°) : possibilité de fusion de capteurs – Utilisation simple : 1 GPIO – prix 21.5 €

Enfin voici un schéma de notre architecture materielle :

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