Site ELEC344/ELEC381

Partie interactive du site pédagogique ELEC344/ELEC381 de Télécom ParisTech (occurrence 2010).

Catégories

Encore une victoire de canard !

Suite à mon dernier article j’ai tenté toutes sortes de manières de debug pour trouver d’où le petit problème venait. Je suis passé par l’implémentation d’un programme en C sur mon ordinateur pour tester le filtre sur un échelon pour comparer à ce que donnait MATLAB (pareil), tester l’échelon sur la carte logique, j’en passe et des meilleures.

Après de longues heures à m’arracher les cheveux, j’ai enfin réussi à corriger le code. Le problème venait de l’accéléromètre. La récupération des valeurs via SPI posait des soucis et désynchronisait le filtre. J’ai donc créé une tâche  spécifique qui se charge d’updater une variable locale au programme avec ce qu’elle récupère via SPI. Ca permet d’éviter de perturber le bon déroulement du filtrage.

Voici le résultat obtenu lors du benchmark. Cela correspond pile poil aux mouvements donné à la carte par le servomoteur. Et l’axe des ordonnées indique pile poil l’angle d’inclinaison de la carte en centièmes de degrés. C’est trop cool, et surtout, ça va permettre de bosser sur la suite en ayant une totale confiance dans les angles que l’on va manipuler.

Wahba pour Kalman

Lundi

Après les larges lectures des articles sur Kalman, MAV, IMU que Alexis nos a donné maintenant je peut dire que je  comprendre mieux les choses. A début des lectures j’ai eu des problèmes pour comprendre mais après un coup d’œil aux cours de physique, probabilités, et autres aspectes commet les angles d’Euler et les quaternions les choses ont commencé à être plus claires.

Mardi

Les neuf variables d’état du filtre Kalman  sont les trois vitesses de rotation angulaire mesures pour les gyroscopes plus les deux colonnes de la matrice de rotation de la base du mobile à la base de référence. Ces colonnes de matrice de rotation son trouvés à partir du algorithme FQA. FQA prend les valeurs mesures par l’accéléromètre et magnétomètre et donné la matrice rotation. Après lecture de Wahba, FQA, et le code de Fernando on a vu il y a encore le problème de singularité quand le tangage c’est près de quatre-vingt dix degrés.

Mercredi

En cherchant résoudre le problème de singularité j’ai vu que on peut trouver les colonnes de la matrice de rotation sans passer pour les quaternions. Celui-ci utilise plusieurs opérations comme sinus et cosinus qui sont très couteuses. Ainsi, j’ai fait une fonction qui donne les colonnes de la matrice en utilisant le minimum des opérations. Avec F-X on testé sur l’IMU et on a un problème sur le tangage, quand on fait la rotation l’axe n’est pas constante. Il reste de résoudre ce problème et celui de singularité, on a besoin que le problème de Wahba soit bien résolu pour tester le filtre Kalman sur l’IMU.

Matrix reloaded ...

Hier, fort de la lecture de différents articles et codes source, je me suis lancé dans le code du filtre de Kalman, sans pouvoir toutefois réellement le tester (mais il compile !). J’ai fait attention d’optimiser un peu les opérations sur les flottants même si on peut sûrement faire quelque chose de mieux ‘hardcore style’. J’espère aussi qu’une opération flottante avec 0 prend moins de temps qu’une autre !

Au total, une passe de mon filtre de Kalman prend environ 870 multiplciations, 950 additions et 9 divisions. Je n’ai pas encore relié ça rigoureusement aux temps d’execution qu’on a mesuré avec Etienne mais il semble me souvenir que ça devrait faire aux alentours de 5ms. Vu le temps de réaction et l’inertie de l’hélicoptère, je pense qu’on est bon de ce point de vue là.

L’objectif de la journée d’aujourd’hui était d’intégrer l’algo FQA (pour la résolution du problème de Wahba) et le filtre de Kalman pour pouvoir le tester. Seulement, pour faire ça, il fallait d’abord vérifier que l’algo FQA marchait bien, à l’aide du visualisateur 3D. Le protocole est simple: Le visualisateur récupère les valeurs du capteur sur la carte (envoyées par Bluetooth), execute l’algo en local  (pour eviter des problèmes supplémentaires …) et met à jour l’affichage.

Et là, ça a été trèèèèèèèèèèèèèèèès long (oui, une journée complète de 10h, je ne comprends toujours pas comment le temps a pu filer ainsi !) pour avoir le lien entre l’affichage et la matrice renvoyée par l’algo avec tous les problèmes de changements de base (carte->monde physique réél->monde openGL->représentation de la carte dans le monde OpenGL), de matrices transposées ou pas, bref !

Voyant que je pataugeais, Etienne D. m’a bien aidé pour essayer de voir les choses clairement et systématiquement et on est (visiblement !) arrivé à quelque chose de cohérent là-dessus.

Ce qui nous a permis de voir que l’algo FQA (ainsi qu’une version allégée que Miguel a codé en parallèle) ne marche pas très bien, vraisemblablement à cause d’un problème d’ordre de rotation. J’ai essayé aussi de reprendre l’algo TRIAD (qui n’utilise que des opérations vectorielles donc normalement exempt de ces problèmes d’angle) sans grand succès non plus…

Bref, c’est un peu une journée désespérante de ce côté là, heureusement qu’Etienne avait à côté des résultats positifs (et que Pulse aussi, derrière nous, on pouvait s’amuser à les pinger ou à les synflooder pour se détendre :P ).

Propulsion

Depuis le début de la semaine j’ai travaillé sur la propulsion, le LQR et le filtre complémentaire.

Concernant l’avancement du filtre complémentaire : voir l’article d’Arnaud.

Pour la propulsion : J’ai asservi les roues en lacet. C’était d’autant plus nécessaire que la réponse de chaque moteur à un même PWM était nettement différente et risquait de compromettre les tests en lignes droite même sur de petites distance. J’ai également fait quelques tests de mesure de vitesse avec le protocole suggéré dans l’insider guide mais les résultats ne sont pas satisfaisant : soit le temps entre deux mesures de vitesse est trop long, soit la précision est insuffisante.

Sur le LQR, J’ai modifié mes valeurs en fonction de ce qu’on a déjà fait. L’adaptation entre l’échelle des capteurs et les entrées du LQR ne devrait pas posé de problème mais la correspondance entre la valeur de sortie du LQR et la commande des moteurs n’est pas aussi évidente.

Kalman farçi, Kalman à l'américaine ...

Aujourd’hui, j’ai fait beaucoup de recherches sur le filtrage de Kalman, afin que ce soit bien clair dans ma tête et pour enfin voir concrètement ce qu’on va faire.

C’est un peu frustrant (surtout à ce stade du projet) de passer une journée où on ne produit rien de concret mais je pense que ça aidera quand même .

J’ai eu de gros moment de doutes dans la journée (notamment sur le calcul d’erreur et la manière dont on l’utilisait pour mettre à jour la variable d’état) qui se sont dissipés au fur et à mesure des lectures. Ca ne fera surement pas de mal non plus de confronter ce que j’en ai compris avec Miguel demain et d’en parler aussi avec Alexis.

Tout d’abord, le mot clé  AHRS (pour Attitude and Heading Reference Systems) m’a ouvert pas mal de portes pour trouver d’autres articles que ceux d’Alexis, certains plus théoriques et aussi des exemples de code. J’ai aussi découvert le projet OpenPilot (dont les sources sont normalement libres, mais je n’ai pu trouver les sources de leur AHRS (!) dans leur dépôt SVN ) et Rotomotion, asez présent sur le net.

Deux liens ici vers des exemples de code que je ne trouve pas parfait non plus (notations peu claires, syntaxe hésitante, utilisation de flottants) mais qui permettent de se donner une idée de ce qu’on devra faire.

Et un article, qui reprend l’idée de considérer le gyroscope comme commande et les accéléromètre comme mesure. Ils utilisent également les quaternions  et donnent les matrices utilisées dans le filtre de Kalman à part les matrices de covariance.

Voilà, j’espère qu’on pourra demain décider finalement ce qu’on met dans notre filtre, éclaircir les dernières zones d’ombre avec Alexis et commencer à le coder !

Quant au code de Mikrokopter, il m’a l’air très artisanal, avec des tests sur les écarts entre gyros et accélérometres et autres. Bref, pas de filtre de Kalman de ce côté là.

J-27 Host in translation

Alors comme je n’ai pas posté depuis 3 jours, voici un petit récapitulatif.

Jeudi : j’ai regardé un peu le code qu’avaient fait les autres et j’ai réfléchi à une architecture plus propre pour notre PID, plus facilement portable sur STM.

Vendredi : Comme j’avais tout bien dans la tête après avoir rêvé de PID, j’ai refait bien proprement et de façon bien modulaire le code de l’aservissement. Un point important et que j’ai bien fait attention à n’utiliser que les données des capteurs que l’on aura réellement, parce qu’avant, le temps d’établir le modèle d’asservissement, je considérai toutes les données que je voulais en « trichant » avec le simulateur ( position, vitesse, acclération, angle, vitesse, vitesse angulaire, accélération angulaire ). Cette première phase nous avait permis de bien mettre le doigt sur l’intérêt d’un double asservissement. Dans ce nouveau asservissement tout est doublement asservi en position et vitesse ce qui donne de jolis résultats.

Samedi : Auujourd’hui j’ai amélioré le code d’asservissement pour les angles, en particulier en faisant en sorte que la poussée des moteurs lors des inclinaisons continue à compenser la gravité. J’ai également réfléchi aux cas limites pour l’asservissement, quand il fallait le désactiver pour passer en mode « exceptionnel ».

Sur le simulateur j’ai ajouté quelques sorties et scripts gnuplot pour représenter de façon pratique la réponse de notre engin aux différentes commandes. Je pense que cela pourra être utlie lorsqu’on fera voler l’heliokter au début pour analyser les données de vol.

J’ai aussi commencé à regarder l’article sur Kalman pour bien rester en phase avec les autres. J’ai lu la documentation de Free RTOS. Normalement demain je vais essayer de compiler et benchmarker mon code sur le STM de carte de TP ( pour avoir une idée de ce qu’il donnera sur notre carte ) .

Travail du Weekend et Mardi

Le week-end dernier j’ai fini faire marcher le simulateur sur mon PC et j’ai commencé a lire plus sérieusement sur le filtre Kalman. Mardi j’ai travaillé sur Matlab, j’ai testé le filtre que F-X utilisé pour éliminer le gros bruit du accéléromètre. Maintenait je peut désigner n’importe quel filtre à partir des spécifications :  fréquence d’échantillonnage, atténuation dans la bande passante, atténuation dans la bande atténue et fréquences de coupure.

Finalement, j’ai récupérée le travail qui a été fait  l’année dernier dans le projet « Localisation GPS/IMU » sur le filtre Kalman, j’ai lu l’article que ils ont fait mais pour bien comprendre je suis entrain de lire leur source.

Travail du mardi à jeudi

Mardi j’ai fini rédiger la partie de mon article, j’ai changé le sujet suite à la suggestion de Samuel. Jeudi j’ai continué avec ma carte, j’ai testé le filtrage des fréquences des messages reçus et maintenant ma carte joue de la musique.

Heliokter: Wahba

- Lectures:

« A Simplified Quaternion-Based Algorithm for Orientation Estimation From Earth Gravity and Magnetic Field Measurements »

attitude determination (50%)

- Mise en oeuvre du algorithme TRIAD simple.

- Simulateur marche sur linux.

A Simplified Quaternion-Based Algorithm for Orientation Estimation From Earth Gravity and Magnetic Field Measurements

Carte IMU : Nord, où es-tu ?

Après avoir encore essayé plusieurs solutions pour faire marcher le Bluetooth entre hier et aujourd’hui (utiliser un code de Samuel -> ça ne marche pas mieux, changer de système -> problème de virtualisation), j’ai décidé de faire autre chose et de me lancer dans un des composants inertiels.

Comme je n’ai pas de câble USB mâle-femelle pour alimenter la carte, elle est directement fixée sur un port USB de mon ordi donc j’ai décidé de commencer avec le magnétomètre, qu’on peut tester sans trop bouger et en restant à plat. La magnétomètre utilise l’interface SPI pour communiquer avec le processeur.

Et là, surprise ! ça semble marcher. Je suis tellement content que je vous mets même des photos (réalisées sans trucage).

Pour le moment, j’ai juste réglé la LED sur le signe de la composante ‘x’ de la boussole, donc c’est censé changer de couleur dès qu’on croise le Nord magnétique.

Avec une localisation GoogleMaps de ma rue et un alignement soigné de la table par rapport à la fenêtre, j’en ai déduit que ça marchait plutôt bien !!

Sinon, pour ce qui est de l’article, j’avais pas mal travaillé dessus la semaine dernière donc j’ai fait hier une petite conclusion sur ma partie.

Edit (00:34) : Ca y est, l’accéléromètre prend le bon chemin ! Encore en contrôlant le signe des valeurs mesurées avec la LED, j’obtient de jolies choses(rouge je penche à droite, vert je penche à gauche ;-) ). Par contre, dès que je compare des valeurs entre elles ça devient un peu plus cahotiques,  j’ai vraiment hâte d’avoir un moyen de communication  pour connaître les valeurs chiffrées des mesures :p.