Site ELEC344/ELEC381

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

Catégories

A toute vitesse

Ces derniers jours, tout le groupe s’est acharné à faire rouler le robot à nouveau, puisqu’après les exploits de dimanche nous sommes allés de déboire et déboire. D’abord, un bug d’initialisation du gyro nous a empéché d’avancer une journée entière, avec un robot qui ne tenait plus du tout. Ensuite, grâce à des conseils avisés d’Alexis qui a beaucoup travaillé sur nos filtres, nous avons grandement amélioré le filtre, en introduisant un filtre de Kalman en plus de notre filtre complémentaire, pour annuler le drift du gyroscope de façon satisfaisante. Le filtre de Kalman étant moins performant en translation, nous avons néanmoins conservé nos calculs.

Nous avosn pu commencer un début d’asservissement en x, encore beaucoup de tests en perspective…

En paralléle, Fabien a fait un script pour afficher les courbes en temps réel, ce qui nous a permis de faire des acquisitions et de nous rendre compte plus facilement de nos réussites et de nos problèmes. Ainsi, la vitesse en x est toujours nulle (on s’y attèle très vite).

Par contre, les résultats pour la vitesse angulaire sont assez bon, au vu de nos premier tests :

La courbe bleue représente la vitesse angulaire calculée par le robot (décalée pour les besoins de l’observation), alors que la verte donne la dérivée de l’angle.

Améliorations pour le code de Wheely

Cette nuit, Alexis nous a communiqué le fruit de ses recherches sur le filtrage. Sa conclusion : Le filtre complémentaire que nous utilisions est très bon une fois qu’on lui soustrait le drift, mesuré à l’aide d’un filtre de Kalman tournant en parallèle.

Avec l’aide du code fourni par Alexis, j’ai intégré le Kalman et la soustraction du drift. Le code d’Alexis m’a par ailleurs inspiré sur pas mal de points, en terme de propreté, donc j’en ai profité pour faire une bonne petite refonte du code de Wheely, avec des variables plus claires, et une API pratique et compréhensible.

Cet après midi nous avons testé le code. Après que nous ayons corrigé quelques coquilles, nous obtenons sans l’asservissement sur X des résultats plutôt satisfaisant. Le robot tient assez bien sur place, à condition que le léger offset sur l’angle soit bien réglé à la main. Mais il est assez stable, autour de 0.6°, désormais codé en dur.

Difficile pour l’instant de bien contrôler les effets d’un asservissement sur X lorsque nous l’introduisons.

Wheely apprend à tenir debout

Jeudi et Vendredi, nous avons travaillé avec l’aide d’Alexis à faire tenir le robot debout.

Jeudi, la journée a été consacrée à corriger et à améliorer le code des capteurs et des filtres dont on déduit l’angle d’inclinaison du robot. Désormais, l’angle renvoyé lorsque la carte est en translation est cohérent, bien qu’on puisse affiner un chouilla encore.

Vendredi, nous avons joué avec le PID. J’ai programmé une interface qui permet d’ajuster tous les paramètres du PID dynamiquement via bluetooth, et de récupérer toutes les données de fonctionnement du robot en temps réel. Ainsi, nous avons réussi à faire tenir le robot debout pendant une dizaine de secondes. Nous avons perdu beaucoup de temps avec Alexis sur un plantage du au fait qu’un char truc[3] importé dans un autre fichier se déclare en extern char truc[3] et non en extern char* truc. Mais désormais, c’est clair et corrigé.

What’s next ? Continuer à jouer avec le PID pour améliorer les coefficients, et éventuellement affiner la fréquence de coupure du filtre complémentaire.

Wheely - le robot en déséquilibre !

Aujourd’hui, nous avons réussi à corriger le problème lié au filtre complémentaire (cf. post d’Arnaud) et commencer les tout premiers tests de l’asservissement LQR.
En voici une première vidéo (merci Florent pour la caméra !). Nous mettrons à jour des vidéos plus intéressantes la semaine prochaine (au fur et à mesure que nos tests seront plus satisfaisants), puisque le robot est désormais monté (merci Fabien !).
Je vais m’occuper de la mise en en flash du programme (pour l’instant nous ne flashons qu’en RAM) ce weekend puisque mon avion pour l’Irlande a été annulé :(

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.

Wheely – filtre complémentaire

Depuis quelques jours, nous travaillons sur les données du gyroscope et de l’accéléromètre que l’on filtre (respectivement en passe haut et passe bas) afin d’utiliser la technique du filtre complémentaire. Pour l’instant, (après pas mal de tests) le temps de stabilisation du filtre se situe aux alentours de 20 secondes (ce qui est un peu long quand même !). De plus, la moyenne des signaux filtrés n’est pas centrée en 0 (ce qui est embêtant pour l’utilisation du LQR par la suite…).

Wheely - accélromètre suite

Aujourd’hui j’ai rajouté le filtre passe bas pour l’accéléromètre. J’ai perdu un peu de temps puisque je n’avais pas les bons coefficients au départ.
J’ai fait des tests avec l’accéléromètre et le gyroscope afin de déterminer l’orientation des axes par rapport à la carte IMU.

J’ai fait une première version du filtre complémentaire (somme de l’output X du gyroscope et de l’accéléromètre, puisque c’est l’orientation qui correspond à celle de la carte).
J’ai voulu ensuite déterminer un angle précis afin d’avoir une référence et pouvoir calculer le coefficient multiplicatif à rajouter devant la composante de l’accéléromètre et celle du gyroscope, mais je me suis heurté à un problème.
Le gyroscope une fois intégré donne effectivement un angle mais il y’a une dérive qui ne facilite pas la mesure de celui-ci. Une fois filtré les données du gyroscope ne dérive plus, mais il se comporte à nouveau comme une vitesse angulaire et non un angle, donc cela ne nous convient pas non plus.

En faisant quelques petits tests empiriques, on a constaté que les données obtenus étaient plutôt satisfaisantes (réactives et stables) pour un coefficient de 0.8 pour la composante gyroscope.
Avant mercredi, il faudra avoir élucidé la façon rigoureuse de trouver le bon coefficient multiplicatif. (Sinon Arnaud ne sera pas content, puisqu’il est responsable de cette partie ;) )

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.