Site ELEC344/ELEC381

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

Catégories

Wheely deuxième vidéo

Voici une deuxième vidéo illustrant l’état d’avancement du robot wheely.
Il nous reste encore à améliorer en priorité l’asservissement en position et l’interface de pilotage du robot.

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 vidéo

Comme Arnaud l’a annoncé, voici donc un petit montage (rapide !) des premiers ‘pas’ de Wheely en équilibre.
Le lien de la vidéo se trouve également sur le site de Wheely.

1min30sec d’équilibre pour Wheely

Aujourd’hui deux évolutions ont été apportées au robot :

  • Kellya et Daniel ont amélioré le système de calibration. Désormais, l’accéléromètre est supposé juste et permet au démarrage la calibration du gyro. Ce système a l’avantage d’être robuste une fois que la carte est bien fixée horizontale sur le robot. Il nous reste à éventuellement ajuster un petit offset en dur dans le code.
  • J’ai réglé le PID et trouvé des coefficients très chouettes car on a réussi à le faire tenir en équilibre 1min30sec dans moins d’un mètre. Ensuite, il a trop dérivé et s’est retrouvé au bord de la table. Daniel va poster la vidéo très prochainement !!!

Sur ce, c’est reparti demain pour de folles aventures. What’s next ? Intégrer les données des encodeurs dans le PID de la carte propulsion pour contrôler la dérive suivant x.

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.

Impasse

Voilà trois jours que je travaille à améliorer le contrôle des moteurs mais je suis dans une impasse.

Le problème se situe à basse vitesse, à vitesse moyenne et haute, la mesure en vitesse des encodeurs est bien proportionnelle à la commande en PWM.

Les moteurs font des à-coups à basse vitesse et ne commencent à bouger que lorsque le duty cycle dépasse une valeur d’environ 1300 / 16384.  Malheureusement, ce seuil et le comportement du moteur à basse vitesse dépendent directement du voltage en entrée du pont en H et ce de façon assez sensible.

J’ai alors réfléchi à un asservissement. Problèmes : les encodeurs n’ont pas une définition excellente (360 tic / tours) et donc je ne peux mesurer la vitesse des roues que sur des intervalles relativement long et de fait, les corrections agissent comme des à-coups qui viennent s’ajouter à ceux dus à la mécanique des moteurs… Et les moteurs présente également des phénomène d’hystérésis (si j’applique une commande de  1300/16384 alors que le robot vient de s’allumer, les roues ne bougent pas. Si je mets le robot en route et fait décroitre la commande en PWM jusqu’à 1300/16384… Le moteur bouge…

Donc au final, je vois pas trop ce que je peux faire mais ceci étant dit, je pense que le Wheely ne tient pas debout à cause du bruit dans les capteurs engendré par le mouvement et non par les moteurs : on peut trouver sur internet pleins d’exemple de robot en équilibre en Légo Mindstorm et ceux-ci ont des moteurs dont les caractéristiques sont bien pires que les notres.

Et quand ça n'avance pas...

Après avoir laissé vendredi soir Wheely tout juste monté, nous avons pu partir contents de nous pour un week-end bien mérité.

En rentrant, j’ai fait quelques tests sur le LQR pour remarqué quelques problémes bètes, en particulier un problème de saturation qui faisait repartir le robot dans le mauvais sens quand il était trop penché… Après quelques heures de tests, nous avons décidé de commencer par essayer de faire rouler Wheely grâce à un PID sur l’angle, sans l’asservir du tout en position, puisque cela ne faisait que compliquer la recherche pour le moment.

Lundi, nous avons donc refait toue une série de tests tous ensemble (puisque les avions ne volent plus…) sur le PID et Fabien a rajouté un étage au robot pour monter encore le centre de gravité.

Mardi, je me suis penchée sur le problème de la mise en flash du code. Daniel y travaillait déjà sans succés, donc on s’est dit qu’un autre essai ne ferait pas de mal. Après de longues recherches et un certain désespoir, j’ai fini par découvrir que notre problème venait d’une mauvaise initialisation de la flash, que nous faisions trop tard (ie après que l’horloge soit réglée sur la PLL et non avant). Sam a aussi remarqué un warning du compilateur qui nous a poussé à faire une petite modification dans le ld script.

Ce matin, j’ai donc modifié le hardware_init et le ld script pour toutes les cartes, ainsi tous nos codes seront harmonisés, en vérifiant bien que ce code fonctionnait aussi bien en flash qu’en ram, et que toutes les tâches fonctionnent toujours correctement (vu les problèmes rencontrés par les autres gruopes, je m’attendais à tout!). J’ai fait tous les tests qu’il me semblait possible de faire sur la carte propulsion et je n’ai rencontré aucun problème majeur.

Ne reste plus qu’à faire rouler Wheely maintenant…

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é !

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é :(