Site ELEC344/ELEC381

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

Catégories

Heliokter et le yaw-yaw


Dans la journée de jeudi, on s’est finalement fixé sur un meilleur protocole que la planche qui roule (qui changeait un peu l’inertie du copter et qui n’etait pas vraiment no plus une rotation pure autour de l’axe), en tenant juste l’Heliokter avec ses mains (mais c’est peut-être plus dangereux et certainement plus fatiguant). En mettant ses pouce et index en anneau autour des deux branches d’un axe, on laisse donc au copter une liberté totale autour de cet axe et seulement autour de cet axe, sans modifier le bras de levier des moteurs.

Cette histoire de bras de levier devient très gênante puisque dès qu’on veut tester l’hlicoptere en vol à quelques centimètres au dessus du sol (ou de la table en l’occurence), et qu’un des pieds vient toucher le sol, le copter se bloque sans essayer de revenir à l’horizontal (enfin il essaye mais la table le bloque). Maintenant que j’y pense, il faudrait en fait poser son ventre sur un truc assez haut et assez fin pour ne pas que les pieds entravent son mouvement et lui laisser une plus grande liberté … Si le truc en question est un tuyau (genre PVC), on peut même faire passer la ficelle dedans, comme sur ce schéma :

Grâce à ça, on a pu régler jeudi de manière assez correcte l’asservissement en pitch et roll (tangage et roulis). Après une perturbation, il revient au bout de deux oscillations àa sa position stable. Nous avions aussi un problème d’erreur statique que nous n’arrivions pas à corriger avec notre coefficient intégral puisque l’intégrale était en fait remise à zéro periodiquement. Samuel nous a conseillé d’utiliser une intégrale bornée qui a le mérite de de ne pas diverger tout en jouant correctement son rôle d’intégrale. La mise à jour du calcul de l’intégrale (une ligne de code) a révélé une sorte de bug a priori inexplicable qui nous a necessité plusieurs heures. C’est soit un problème de pile, soit un problème d’initialisation (on a pu le corriger en mettant une fois l’intégrale à zéro quelques secondes après le reset) …

Et jeudi soir, on a essayé l’asservissement en lacet (yaw en anglais, cf. titre hilarant), sans grand succès pour le moment, l’hélico tourne sans jamais s’arreter bien que les coefficients intégral et dérivé soient nuls …

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.

Heliokter : Simulateur et discussions

Je progresse toujours sur le simulateur.  J’ai mis un peu de vent pour voir notre hélico qui tombe dans les choux au bout d’une seconde. J’ai aussi fait ma partie de l’interface  pour l’asservissement qui fournit les valeurs des capteurs (pour le moment non bruitées). J’ai essayé également de mettre un contrôle avec les touches, mais par définition, sans asservissement, c’est pas terrible …

Comme l’a dit Etienne, on a aussi discuté hier pour arreter notre choix de composants et de processeur (le F103RET6) et on a fait un premier brochage.

Cette après-midi, on va essayer de coupler le simulateur et l’asservissement pour enfin pouvoir le tester. Et aussi commencer à travailler la soutenance.

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…

Wheely : modélisation matlab

Simulation du modèle physique du robot en équilibre sur matlab.

L’asservissement LQR marche bien et se paramètre bien.

En attente de résultat de l’équipe Kalman pour modéliser plus fidèlement le bruit des capteurs et implémenter Kalman sur le modèle.

En attente du robot pour corriger les paramètres mécaniques. (Croulebois prévenu ? Commande des moteurs ? )

Exemple de résultat : freinage à partir d’une vitesse initiale de 1m/s avec un bruit blanc de 5% sur les mesures de vitesse angulaire et de position au sol. Et un bruit blanc de +/-0.1V sur la commande de chaque moteur. la postion est en [m] et les angles en radian. Le temps de calcul entre commandes sur le moteur est fixé à 50ms.

à venir : choix des composants et PCB de la carte propulsion.

Wheely : asservissement et méca

- Etablissement des équations différentielles qui décrivent la mécanique du robot

- Recherche du principe du LQR.

- Détermination de la matrice qui prend en entrée l’angle des roues et du corps du robot et qui rend la tension à appliquer au moteur en fonctions de tous les paramètres du moteur.

Problème : les infos sur les moteurs et les roues sont insuffisants pour faire les choses précisemment ( on recevra peut-être la datasheet avec les moteurs, avec un peu de chance).

- Choix du l’accéléromètre (LIS3LV02DQ) à faire valider.

- Méca : plans terminés à communiquer à Alain Croulebois.

à venir ce soir : simulation matlab avec en entrée des mesures bruitées et en sortie l’angle du robot en fonction du temps (donc avec Kalman + asservissement) pour tester l’influence des différents paramètres.