ELECINF344/381

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

Catégories

Copterix : First outdoor flight

We can now control the attitude of our copter with the RF remote control. We have also implemented the possibility of turning on/off the motors directly with the RF remote control. Bertrand has made a script for running all the control tasks at boot. We can thus take control of our Copter as soon as the gumstix has started and is running Linux, without using any SSH connexion.

Then, we took the Copter outside for a first flight in real conditions. We succeed in taking off, but I wasn’t very comfortable with it. Then, we had a big crash: Bertrand accidentally put the thrust too high at the takeoff. The Copter overturned and damaged/broke some propellers. Fortunately, we put a protection onto the motors’ boards yesterday. They thus don’t seem to have suffered damages. Here are some photos after the crash. (Photos are from Samuel Tardieu)

the broken propeller... what a shame.

Crash of the 22th April, 2011

 

Tomorrow, we’ll try to improve our PID algorithm for pitch, yaw and roll, and then we’ll probably work on the Kanade algorithm, for X and Y control loop.

IRL : Settings !

In our last article we described some ways to enhance the display of a text scrolling smoothly.
We actually tried several possibilities of settings for the scrolling text and finally found a convenient one (as shown on the video above).

We did some major improvements concerning the speed of the code on the card succeeding in speeding it by a factor of 5. We deemed that a major issue of that program lays on the access time of the memory. Indeed it takes more than 20 seconds to write an ILDA file of a tweet from the ram to the flash. Samuel suggested that we could use a socket to directly send the ILDA file from the python script to the C program in charge of the FPGA communication. In fact, with such a strategy we would avoid the slow speed flash access and be able to send a tweet to the laser around 30 seconds after its validation.

In addition we’re going to add some bit stuffing to make the frames equally populated in terms of points so as to assure a constant frame rate. You can easily notice that disturbing effect on the video above.

In parallel, we’re getting familiar with the DMX protocol and are working on the DMX board.
We haven’t forgotten the software fifo between the C program and the FPGA. We deemed that a zeromq socket would be a interesting solution and we are currently working on it.

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

[CASPER] Http setup interface

Today, we have been looking for the simplest way of giving a http control interface to our project. We found that the C library Microhttpd was matching our needs.

It’s a library which will allow us to create a very simple http server on the BeagleBoard. This way a user will be able to get registered into Casper’s « Database ». Eventually, through this interface, he will be able to give his name, a new Lua script or his various logins/passwords to access his mails and so on…

Besides, we made some changes in Casper’s prototype. We made a « box » in wood which contains the motors and supports Casper itself, so it’s easier to move it.

 

Copterix : on passe entièrement sur la Gumstix !

Aujourd’hui, avec Bertrand, puis rejoins par Samuel et Axel, nous nous sommes concentrés sur la communication Gumstix/STM32. Nous avons enfin réussi à connecter comme nous le voulions les deux cartes.

Nous avons d’abord dû activer le GPIO 10, le pin correspondant n’étant pas configuré par défaut en tant que GPIO. Nous avons donc choisi de le configurer à chaque démarrage par l’intermédiaire d’un script shell, exécuté automatiquement, réalisant l’accès en mémoire nécessaire à la configuration, à l’aide de l’utilitaire memdev2.

Après avoir débugué notre carte à l’oscilloscope, et résolu un problème de soudure, nous avons donc enfin pu communiquer entre nos deux cartes. Les premiers essais ne furent malheureusement pas très fructueux : alors que les échanges de paquets se faisaient sans soucis entre PC et carte de TP STM32, avec le même protocole, nous avons à présent plus de 10% de perte de paquets (parfois 25%), et surtout, de longs moments (se décomptant en secondes) qui s’écoulent avec presqu’aucun paquet de valide. Les cartes sont donc inutilisables dans ces conditions.

Après analyse des données échangées, il semblerait que de nombreux octets ne sont pas reçus par la Gumstix, ceux-ci se perdant, à un niveau qu’il nous reste encore à déterminer. Exemple : sur des paquets qui devraient être de 21 octets, nous avons parfois observé plus de la moitié des octets perdus. Et ce, malgré le fait que nous avons redescendu la vitesse de l’UART à 115200 bps.

Les différentes pistes que nous avons à explorer demain, pour essayer de résoudre ce problème, sont les suivantes:

- Alexis nous a suggéré d’essayer de modifier le préscalaire de l’horloge concernée. Les quartzs n’étant pas forcément très fiables, il se peut que le souci vienne d’une vitesse de communication approximative, qu’on pourrait essayer de compenser de cette manière.
- Axel m’a suggéré de modifier légèrement le protocole. En effet, si on perd un octet, on perd au minimum deux paquets. Je rappelle le protocole :
On envoie un octet de start : 0xfe. Puis un octet identifiant le paquet : 0x4b. Ensuite on lit le nombre d’octets correspondant. Si on perd un octet, on va déborder sur le paquet suivant dans la lecture, et on ne le lira donc pas non plus. La solution proposée par Axel serait d’enregistrer la position de tout octet 0xfe croisé dans le contenu d’un paquet, et si le paquet est invalide, revenir à cette position pour « récupérer » ce paquet. Toutefois cela ne résoudra pas le problème, il s’agit juste de perdre moins de données à cause du protocole.

 

D’autre part, nous allons abandonner l’altimètre. Il semblerait que celui-ci soit trop peu précis, et trop complexe à utiliser. Nous allons donc plutôt faire des tests avec un détecteur à ultrasons ou un sharp, pour voir si nous obtenons quelque chose de plus satisfaisant.

Nous avons également été chercher l’hélicoptère, afin de pouvoir tester les commandes des moteurs très bientôt.

IRL : dure journée …

Nous avons eu beaucoup de doutes ces derniers temps concernant les choix à faire pour avancer. Voici ce que nous avons fait durant les deux derniers jours.


Serveur web

Comme pouvait le laisser penser notre dernier post, nous avons exploré les possibilités offertes par mongrel2.
Il s’agit d’une application qui multiplexe des requêtes http et les recopie sur des sockets 0mq (pour plus de détail : http://mongrel2.org/home).
Nous avons testé mongrel sur nos machines avec succès et il nous semble tout à fait adapté pour résoudre nos problèmes.
Nous avons essayé de le crosscompiler mais sommes confontés pour l’heure à des problèmes.
À terme, nous voulons l’intégrer dans notre buildroot.

ILDA

Nous avons l’ensemble des caractères ISO8859-15 sous la forme de fichiers ILDA. Et nous avons trouvé une nouvelle police qui donne des meilleurs résultats. Nous avons fait un script qui nous donne le numéro du caractère ISO8859-15 entré sur stdin.

Twitter

Nous nous sommes familiarisés avec Twitter et nous réussissons à récupérer les tweets portant le htag #rose2011 directement sur la carte.

FPGA

Nous avons synthétisé et testé sur le FPGA un code utilisant une des rams internes du FPGA et permettant d’y écrire et lire depuis le processeur. Nous sommes en train de parler à la ram SPI qui nous reste (en effet, nous avons mal routé une des deux rams SPI dont nous allons peut-être devoir nous passer).

Authentification

Nous avons clarifié nos idées concernant la manière dont l’authentification sera mise en oeuvre sur la carte. Nous nous repencherons sur la question quand mongrel2 marchera.

Copterix : ubuntu sur gumstix && communication STM32/Gumstix

Hier et aujourd’hui, j’ai -comme Casper- fait passer Ubuntu d’ext3 à nilfs2 pour des raisons de performances et pour augmenter la durée de vie de la microSD.

Les noyaux fournis par Gumstix ne le supportant pas, j’ai recompilé le kernel (patché pour supporter la Camera), généré un uInitrd et reconfiguré le bootloader.

En parallèle, j’ai terminé un script faisant un debootstrap adapté à nos besoins, avec les paquets et les fichiers de configurations idoines. Il permet ensuite de formater correctement la microSD et d’y installer notre ubuntu fraichement créé.

 

Loïc continue de travailler sur la communication Gumstix/STM32. Pour des raisons de vitesse de transfert (avoir au moins 1000 paquets/s, un paquet contenant l’ensemble des données des capteurs), il a poussé l’UART à 1 Mhz et est en train de faire des testbenchs pour mesurer le débit utile.

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.

MB Led: Dialogues en zMQ

Ces derniers temps, j’ai principalement implémenté notre algorithme en C, tournant sous FreeRTOS sur un PC classique.

En effet,  j’ai préféré utiliser directement les possibilitées de FreeRTOS (tâches, sémaphores, etc.) plutôt que de coder en C classique puis de modifier tout cela lorsque j’aurai voulu mettre cela sur un module MBLed (ou GLiP).Cependant, j’ai eu beaucoup de difficultés à paramétrer FreeRTOS pour que cela marche sur un ordinateur. J’ai dû me plonger dans la documentation pour finalement réussir à faire un Makefile qui marche vendredi soir.

Pour simuler les échanges entre modules, nous utilisons zéroMQ en mode PUB/SUB. Chaque module que l’on lance intéragit avec le script en python grâce à deux sockets : avec l’un, les modules publient leurs infos et le script les récupère; avec l’autre, le script python publie les informations (qu’il a modifié pour que la partie « Origine » du message soit devenue une partie « Destination ») et chaque module récupère uniquement les informations le concernant.
Pour l’implémentation de l’algorithme à proprement dit, je tente de reprendre le code en python pour le passer en C bien qu’il soit assez difficile de faire cela. J’avais beaucoup utilisé l’orienté objet dans le script et le C ne gère pas cela. Toutefois l’implémentation se fait assez vite et j’espère avoir fini cela pour jeudi ou vendredi.