ELECINF344/381

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

Catégories

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

Voici la mise à jour de nos PSSC

  • Réalisation d’une carte d’extension fonctionnelle (design PCB)  – Fait
  • Récupérer la vitesse de translation grâce à la caméra  – Fait avec openCV
  • Communication Wifi avec le Copterix  – Statut : Ok en ad-hoc reste à tester avec un routeur wi-fi sécurisé – Date : 08/04
  • Récupération des données des capteurs du STM32 - Statut  : En cours, non testé – Date : 10/04
  • Filtrage de Kalman fonctionnel – Statut : Ok avec l’IMU, modulo un léger bruit,  reste à le tester sur notre PCB – Date : 13/04
  • Piloter chaque moteur à la vitesse voulue (i2c) – Statut : Non commencé – Date : 13/04
  • Communication entre la gumstix et le stm32 avec un protocole permettant de récupérer l’ensemble des valeurs des capteurs et d’envoyer les consignes moteurs – Statut : En cours de debug – Date : 13/04
  • Contrôler les moteurs en fonction des données des capteurs pour atteindre un vol stationnaire – Statut : Non commencé – Date : 20/04
  • Gestion des déplacements - Statut : Non commencé – Date : 25/04
  • Contrôle avec une télécommande – Statut : Non commencé – Date : 25/04

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 : les aventures commencent

Changement de planning :

Suite aux semaines mouvementées que nous avons eu, nous avons refait un planning plus réaliste :

20/03 : Design du PCB (peut dépendre des empreintes disponibles sous Mentor)
21/03 : Lukas & Kanade fonctionnel sur PC
24/03 : Communication Wifi avec la Gumstix pour le streaming video
28/03 : Fin de l’étude physique (Simulation, Kalman)
04/04 : Kalman fonctionnel sur l’IMU
15/04 : Vol stable
22/04 : Déplacement de coptérix

Gumstix :

Nous avons depuis hier deux Gumstix. La première (Tide) n’a pas de flash donc on ne peut pas la briquer…par contre elle n’a pas de Wifi intégré. On utilise donc au début la Tide pour bien prendre en main les Gumstix avant de passer sur la deuxième Gumstix (FE) qui elle supporte le Wifi.

La carte doit booter sur une micro SD. On a donc suivi un tutorial pour pouvoir faire une carte SD bootable à partir d’un noyau précompilé. On a pu aujourd’hui tester la carte et y installer ssh. Par contre, le noyau que nous utilisons ne reconnait pas la caméra. Il faudra soit utiliser un autre noyau pré-compilé soit compiler nous-même le noyau en y rajoutant le driver pour pouvoir utiliser la caméra.

Tracking :

Axel s’est intéressé à l’algorithme de Lucas and Kanade.  Il utilise OpenCV. Voici quelques résultats :
Il a implémenté un petit programme qui montre d’une image à l’autre les déplacements sous forme de traits rouges. L’idée à terme est de faire un filtre médian sur ces vecteurs pour en tirer un vecteur de déplacement fiable.

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

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

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.