Site ELEC344/ELEC381

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

Catégories

Quel fourbe cet accéléromètre !

En ce début de semaine nous avons travaillé à essayer de faire tenir Wheely en équilibre. Ce n’est pas convainquant du tout pour l’instant.

Nous avons passé une journée entière à jouer sur les paramètres du PID pour essayer de stabiliser le robot, mais en vain. Impossible.

Suite à une remarque d’Alexis, j’ai trouvé d’où venait le problème. Bien qu’ayant scrupuleusement testé l’accéléromètre, je l’avais fait en rotation et non en translation. Or puisque on utilisait bêtement l’équation g*sin(theta) = acc_x, lorsque l’on translate le capteur ça fausse tout.

Hier j’ai établi avec Fabien et Sam une équation plus complète :

z=g*cos(t)+(x+g*sin(t))*tan(t)

où : z = acc_z, x = acc_x, t = theta

Je l’ai ensuite donnée à MATLAB qui l’a résolue ainsi :

>> solve(‘z=g*cos(t)+(x+g*sin(t))*tan(t)’,'t’)
ans =
(-2)*atan((x + (- g^2 + x^2 + z^2)^(1/2))/(g + z))
(-2)*atan((x – (- g^2 + x^2 + z^2)^(1/2))/(g + z))

C’est là que ça se corse. Il y a deux solutions. J’essaie la première. Zut ça marche pas. La seconde ? Non plus.

Je me suis rendu compte que je faisais la racine carrée d’un nombre négatif en pratique en utilisant cette formule. En théorie ça n’arrive jamais, mais avec le bruit ça peut déborder un peu. Je corrige en prenant la racine de 0 si le nombre est négatif. Toujours pas. Je réfléchis un peu, et je tente une combinaison des deux solutions, en prenant la première si x est négatif, la deuxième sinon.

C’est beaucoup mieux. Maintenant, en translation, si la carte est horizontale, l’angle reste bien égal à 0. Super ! C’est normal, dans ce cas précis z = g et donc on fait atan(0)

Mais en translation inclinée, ça ne fait toujours pas ce que je veux. L’angle varie de 7 ou 8 degrés… Alors qu’il ne devrait pas d’après la démarche que nous avons faite. J’ai passée toute la journée à creuser la dessus, à tenter différentes combinaisons des solutions, à tracer les courbes de chacune des deux solutions pour trouver une idée… En vain.

J’ai l’impression d’avoir tout essayé, je ne sais plus quoi faire… :( Je suis désespéré !

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.

Filtres complémentaires : mission accomplie

Bon, suite aux travaux d’aujourd’hui, j’ai réussi à obtenir de très bonnes courbes. Notre problème d’offset sur les valeurs et de temps de réponse du filtre a été résolu en choisissant une valeur beaucoup plus grande pour la fréquence de coupure.

J’ai ensuite mis en place un benchmark assez complet : oscillation rapide, oscillation lente avec plateau ou non, oscillations rapides de demi amplitudes.

J’ai ensuite calibré le coefficient relatif entre l’accéléromètre et le gyroscope en utilisant des oscillations de différentes fréquence, l’un et l’autre se manifestant ainsi différemment. Le bon coefficient relatif est celui qui permet d’avoir une même mesure de l’angle pour des oscillations de fréquence différente.

Voici le graphique obtenu, avec en haut la commande d’angle donnée aux servomoteurs, et en dessous, l’inclinaison, calculée en degré, en fonction des données recueillie par les capteurs lors du mouvement. Le seul défaut que l’on peut constater est un angle calculé un chouilla en dessous de 0 lorsque l’on vient de remonter la carte (aucun soucis lorsqu’elle vient de descendre). Cela est probablement du à un petit défaut des servo vis à vis de la gravité, et n’est donc a priori pas lié à notre travail.

J’ai ensuite implémenté le nouveau filtre en C, modifié le code du gyroscope pour intégrer après filtrage (et non avant comme c’était fait), et créé deux fonctions get_angle_degree et get_angle_radian qui intègrent les bons coefficients.

Enfin, j’ai testé l’execution sur la carte de tout ça, envoyant via bluetooth le résultat de la commande get_angle_degree*100 (pour avoir de la précision malgré le cast en entier pour l’itoa).

J’obtiens des résultats à l’image de la simulation MATLAB, plutôt satisfaisants. Hormis pour le troisième type d’impulsion, ou ça ne colle pas. Ca n’atteint pas les 10°, et surtout, ça fait deux oscillations au lieu d’une.

Compte tenu que j’ai bien vérifié que le filtre et les données traitées (vitesse donnée par le gyroscope et accélération donnée par l’accéléromètre) sont exactement les mêmes je ne comprends pas trop. Si quelqu’un à une piste je suis preneur, en attendant, je continue à chercher…

Que le filtre soit et le MATLAB fût

Aujourd’hui nous avons travaillé sur la fusion de capteurs et la calibration du filtre. Nous avons mis au point une méthode expérimentale avec un servomoteur qui permet de contrôler précisément le mouvement donné à la carte et de les analyser ensuite.

Après avoir bataillé un peu dans tous les sens et joué avec les différents paramètres nous obtenons des courbes plutôt sympathique… Mais affaire à suivre !

Réseau Wheely

Hier, j’ai passé trois heures à essayer en vain de recevoir des informations par UART en les entrant dans minicom pour m’apercevoir que le câble qui connecte la carte à l’odrinateur était en train de se désouder.

J’ai aussi fait un programme permettant de commander la vitesse des roues en l’écrivant dans minicom, puis en passant par la carte logique par UART et enfin à la carte de puissance par CAN.

J’ai ensuite adapté le code de commande des servos-moteurs fait par le club robotique (merci!) pour pouvoir faire des tests d’angle et de vitesse avec notre carte logique. Ce code fonctionne bien, donc nous allons pouvoir commencer les tests.

J’ai commencé à relire ce que nous avions décidé pour le LQR et les fichiers Matlab. Nous devons nous synchroniser avec Fabien pour avoir un code bien cohérent entre ce qui sera fait sur la carte logique et ce qui sera fait sur la carte propulsion.

Ce matin, j’ai ajouté le code de l’UART au code de la carte propulsion et j’en ai profité pour harmoniser tout le code avec le code de la carte logique.

Gyroscope et filtre anti dérive d'ordre 2

Aujourd’hui j’ai continué à travailler sur le gyroscope. J’ai commencé par chercher le mystérieux bug d’hier et j’ai découvert à mes dépend que l’opérateur % en C (modulo) ne renvoit pas le modulo n canonique (le nombre compris entre 0 et n-1) mais le reste de la division euclidienne. Ce qui signifie que -1%3 = -1.

D’où des underflow dans mes buffers… D’où des résultats bien étrange. Mais ce temps est révolu !

J’ai donc ensuite testé le filtre MATLAB de Fabien, après l’avoir implémenté en C. Les résultats sont cohérents avec les simulations MATLAB de Fabien, comme vous pouvez le voir dans les diagrammes ci-dessous, que j’ai tracé avec l’excellent freeware Mac qu’est Plot, découvert pour l’occasion.

X et Y intégrés (représentent l'angle de rotation de la carte) sans filtrage. La carte est immobile. La partie agitée correspond à une agitation de la carte qui ne fait qu'accentuer gravement la dérive.

X et Y intégrés (représentent l'angle de rotation de la carte) avec filtrage. Cette fois ci, une agitation de la carte qui ne déclenche toujours pas de dérive significative ! C'est un peu normal vu le filtre, mais ça devrait produire des résultats intéressants une fois combiné à l'accéléromètre.

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.

Avancements récents

  • Avancement du brochage et du schématique de la carte de puissance. Suite à une discussion avec Alexis et Sam, l’asservissement aura simplement une commande en tension et non en couple ce qui nécessitait aussi la mesure du courant.
  • Trop de Matlab tue le Matlab : certaines caractéristiques de la simulation dépassent mon niveau mathématique . J’en suis arrivé à la conclusion que
    1. Pour vraiment affiner le traitement des bruits il faudra attendre des essais sur les composants.
    2. De petites bidouilles sur le vrai système ont simplifié la vie de pas mal de prédécesseurs et m’éviteront surement d’implémenter des usines à gaz (genre linéarisation stochastique d’actuateurs qui saturent).
  • Préparation de la soutenance avec quelques interrogations  : est-ce que la soutenance a une visé pédagogique pour les autres groupes ? autrement dit si je dis que j’ai simuler un filtre complémentaire est-ce que je dois expliquer de quoi il s’agit précisément au cas où ça intéresserait d’autres groupes ?  Ne doit-on faire état que des avancements ou aussi de l’organisation des travaux à venir ou des interrogations ?

À faire : se plonger dans l’introduction au STM32 et surligner ce qui me semble utile et particulièrement pertinent pour le projet : cela me fera surement gagner du temps par la suite.

Heliokter : début de vacances

Mon boulot pendant les vacances est de faire marcher le simulateur de manière à peu près réaliste. Je me suis un peu bloqué sur le calcul de la matrice d’inertie du truc; même si c’est des formes simples, c’est pénible de voir comment ça se combine (j’ai ni Solidworks ni Matlab, je suis avec mon papier, mon crayon et mon C …). En plus, je ne suis pas bien sûr de la taille de notre copter.

Par contre, je suis tombé sur le forum de Mikrokopter et là, c’est génial ! J’ai réussi à trouver quels étaient les addresses et commandes envoyées sur le port I2C pour contrôler les moteurs.

Sinon, j’ai mis à jour notre wiki pour proposer une première structure de l’asservissement, en écho aux réflexions du vendredi soir. C’est un peu plus clair pour moi maintenant.

Sinon, je suis bloqué sur le routage de la carte de TP à cause de mon Windows qui ne sait pas faire du WPA …

Matlab : le retour de la vengeance 2.

Avancées en ce début de vacance :

-Lecture de datasheet de pont en H avec Kellya. (et pas mal de problème pour faire des correspondances entre deux datasheet).

Poursuite de la modélisation matlab. Ah LQR j’ai ajouté les filtres complémentaires.

Sur les conseils d’Alexis nous avons décidé d’abandonné Kalman au profit des filtres complémentaires.Cela consiste à faire un passe-bas sur l’accéléromètre et un passe haut sur le gyro, avec deux filtre dont le gain de la somme vaut 1 à toute les fréquence.

J’ai modélisé les mesures de l’accéléromètre par la mesure de l’angle prédit par mon modèle + pas mal de bruit + un offset (aléatoire sur chaque tirage)et la mesure du gyro + par la vitesse angulaire prédite par le modèle + du bruit blanc+ un offset puis j’intégre la mesure. (D’où un bruit en forme de marche aléatoire + une dérive).

Résultats :

Points positifs :

  • même en surdosant clairement les bruits par rapport aux valeurs données dans les datasheets, les résultats sont vraiment bons et les réglages faciles.
  • Facile à implémenter en C (suites récursives d’ordre 2)

Fait également : tests rapides pour voir l’influence des différents paramètres mécaniques sur l’efficacité de l’asservissement. A priori ce n’est pas crucial cependant il va falloir trouver comment les déterminer le plus précissement possible une fois qu’on aura le robot au complet. (@ Alexis : n’hésite pas à me prévenir si tu recois les moteurs pendant les vacances, je reste à Paris…).

à avancer : carte de puissance.

à éluder : en simulation le robot se stabilise en x autour d’une position proportionnel à la dérive du gyroscope. à priori pas génant (de l’ordre de 10cm) mais je n’arrive pas à savoir pourquoi…