Site ELEC344/ELEC381

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

Catégories

La joie des grands espaces

Après la soutenance de vendredi, voyant que la démo s’était bien passée, nous avons décidé de profiter du grand espace intérieur du complexe pour (enfin !) s’amuser avec notre Heliokter.

Et voici un vol assez long et stable, avec Etienne au pilotage (le son a été supprimé) :

Télécommande

Le weekend dernier j’ai révisé sur comment faire un système de asservissement plus fiable que le PID qui, jusqu’à ce moment, fait bien sont travail. Mais, le problème est que même si on trouve des valeurs pour Kp, Kd et Ki, qui font que le Heliokter soit stable, pour réaliser des mouvements un peut plus complexes comme la translation je ne suis pas sûre que ces mêmes valeurs joueront bien aussi.

Étant donné que on déjà le Kalman que marche bien donc on peut profiter de ses variables d’état pour implémenter un  contrôle optimale ou prédictive pour le système d’asservissement. Avant de mettre dans le vrai Heliokter je  pense que il est nécessaire de bien tester sur le simulateur. Pour faire ça j’ai commencé à créer des fonctions qui servent à faire la description physique de l’Heliokopter dans la simulation.

Lundi J’ai travaille avec Fernando pour trouver les trames de transmission de la télécommande.  J’ai ajouté le timer pour savoir si la donné que on a corresponde bien à une trame reçue, comment Samuel a dit j’ai mis 50ms.

Mardi après le examen : (   on a testé mais il ne marchait pas car on s’est trompé dans la configuration du port Usart, il n’est pas le même que on a sur la carte du TP. Après correction la télécommande a commencé à fonctionner et on a pu faire bouger l’Heliokter, et c’est dans un de ces tests qui on a eu un petit souci comme F-X à dit dans son mail.

J-3 May the Fourth : take the kopter in the air

Dimanche

après avoir eu un vol pseudo stationnaire mais peu asservis en lacet, nous  avons compris que les moteurs étaient tous différents les uns des autres, nosu avons commencé à placer des offsets pour les compenser, mais c’est difficile étant donné que cela influe sur les autres paramètres du PID. La gestion des intégrales a été bien améliorée en remettant à zéro les intégrales du PID lorsque l’erreur est proche de zéro (sachant que nos offset doivent annuler les erreurs statiques).

Lundi

Miguel et Fernando ont développé le code pour pouvoir utiliser la télécommande et j’ai mis en place le télémètre et l’asservissement en altitude, le résultat s’améliore doucement. Le lacet est toujours problématique, à cause des importantes disparités des moteurs.

Mardi

Aujourd’hui nous avons commencé à tester avec la télécommande qui permet de régler la poussée des moteurs et donc de stabiliser facilement le copter en altitude ( plus précisément qu’avec le télémètre), nous avons pu faire quelques décollages et vol stationnaires pendant 3-4 secondes en intérieur mais nous avons besoin maintenant d’aller tester en extérieur avec plus d’espace car  en intérieur, une petite déviation d’1 mètre et c’est la catastrophe ( heurt de poteau, alimentation , écran etc … ) , nous avons d’ailleurs cassé notre (enfin!) première hélice …

Demain notre copter verra la lumière du jour !

Heliokter : premiers vols

Depuis le dernier post, nous essayons de customiser notre PID pour parvenir à un résultat en vol meilleur. Le gros problème, c’est que c’est dur de définir ‘meilleur’, l’hélicoptère bouge forcément un peu, c’est difficile de le laisser completement libre dans la salle mais dès qu’on le contraint, on modifie son comportement …

Vendredi et samedi, on a quand même réussi à caractriser un comportement oscillatoire de grande période et grande amplitude, vraisemblablement dû à l’intégrale du PID : Si le le mouvement a tendance à être sinusoïdal, l’intégrale est aussi sinusoïdale mais déphasée de π/2, ce qui entretient voire amplifie les oscillations.

Pour remédier à cela, Alexis nous a conseillé une méthode de remise à zéro de l’intégrale dès que l’erreur change de signe pour eviter ce phénomène. Nous avions essayé d’autres méthodes de remise à zéro de l’intégrale avant mais celle-ci semble bien marcher.

Nous avons donc pu avoir, hier soir, un vol qu’on peut considérer comme stable d’une quinzaine de secondes, visible là :

L’hélicoptère descend lentement, c’est normal, il n’y a pas encore d’asservissement en altitude et  nous avons préféré le faire descendre plutôt que de le faire monter !

Voilà, sinon comme vous pouvez l’entendre, on gagne haut la main le prix du projet le plus bruyant ! :p

Alors evidemment, ce n’est pas parfait, mais c’est vrai qu’on a du mal  à savoir si on peut mieux faire et comment, et comment le savoir !

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 …

J-8 Heliokter l'indomptable

Mardi

Comme on a travaillé ensemble avec FX je ne détailles pas les parties déjà explicitées, mais mardi, après avoir réglé des problèmes d’orientation et de précédence dans les angles, nous avons commencé à asservir l’Heliokter en angle, ce n’est pas une partie de gâteau, pour avoir un protocole de test cohérent, nous avons avec FX tracé les courbes correspondant aux erreurs du PID, les commandes des moteurs et l’évolution des différents angles. Nous avions trouvé une façon de limiter les mouvements à un seul degré de liberté, mais la technique consistant à attacher une des pattes de l’engin s’est révélée inadaptée dans la mesure où cela introduit une dissymétrie dans les bras de levier des moteurs que l’on voulait asservir.

Mercredi

Idem on a travaillé ensemble avec FX, grâce à la modification du code nous permettant de régler les coefficients à la volée et la mise en place d’un nouveau protocole pour avoir un degré de liberté mais sans les problèmes de mardi, ( Heliokter scotché à une plaque de polystyrène posée sur un cylindre de bois sous le centre de gravité ), nous avons constaté que le réglage du double asservissement restait très délicat, de plus les mesures des gyros étaient inexploitable car variant trop vite. Donc sur les conseils d’Alexis nous avons fait deux choses :

  • Filtrer les gyros sur un centième de seconde, ( Un+1 = alpha * Un + (1-alpha)*gyro où alpha = tau/(dt+tau) avec dt temps entre deux échantillons de gyros ( 5 ms chez nous ) et tau 1/fréquence de coupure donc tau = 10 ms chez nous ) .
  • Schinter le deuxième asservissement pour les régler l’un après l’autre.

Dans la soirée nous ne réussissions plus à démarrer les moteurs, nous avons perdu un bout de temps pour nous rendre compte que lors d’un merge malheureux, une version vieille de l’i2c avait écrasé la version fonctionnelle ( et que la numérotation du versionnage par hg peut être trompeuse ). Après ça, peu de temps avant les derniers métro, nous avons eu un asservissement décent en roulis et tangage à la fois, prochaine étape : régler le lacet et l’altitude.

Un protocole générique

Semaine du Vacances

Étant donné que on travaille avec le bluetooth ou avec le ZigBee pour établier la communication entre la PC et entre la carte du notre Heliokter ou avec l’IMU, donc j’ai commence à travailler sur un protocole de communication universel. Avec ce  protocole on aura la possibilité soit de recevoir ou envoyer des données au Heliokter en utilisant les mêmes fonctions quand on fait use de la communication par ZigBee ou par Bluetooh. Le protocole doit être générique du côte PC et du côte carte .

Au début de la semaine j’ai commencé à faire le protocole en utilisant la carte interface ZigBee. Cette carte à un module ZigBee et est relié à la PC directement. Après la remarque du Samuel sur la configuration de la carte j’ai réussi faire la communication avec la carte du TP.

Après j’ai commence à faire le codage des fonctions génériques dans les fichiers protocol.c et protocol.h et j’ai testé sur la carte su TP.

Vendredi et jeudi,  j’ai lu code de Fernando sur le i2c et on a travaille ensemble, surtout le vendredi,  pour trouver les erreurs de la communication i2c. Au début les fonctions de i2c bloquaient tout le système quand ils n’avaient pas de moteurs sur le bus. Après de regarder, en utilisant l’oscilloscope, les trames qui ont était envoyés  au ISL pour lire la température ou autres registres du ISL , on a trouvé que il avait des cas que n’ont était pas traités dans les interruptions.

Lundi 25  et Mardi 26

J’ai porté la communication par Bluetooth sur le protocole générique. Aussi avec Fernando on a réfléchi  sur les possibles erreurs du protocole du communication.

Nous avons pris comme référence le protocole de Mikrocopter pou faire la notre. Mais, on avait des problèmes quand le byte de fin de trame était présent en milieu de la trame.  La solution qu’on a pris est de utiliser le caratère de échappe ( ‘\’ ) pour identifier les données qui ont le même valeur qui le caractère du fin du trame et le même caractère du échappe.

J’ai fait les fonctions génériques pour le protocole, mais il fallait aussi modifier les fonctions du ZigBee et du Bluetooth, toujours des deux côtes : PC et carte.  Maintenait ça marche bien avec le bluetooth, pour le zigbee , avec Fernando, on a finit de faire le codage mais il  maque faire les test.

Heliokter bourdonne

J’ai passé la fin des vacances sur le filtre de Kalman, pour l’affiner/le corriger. Je me suis rendu compte avec la carte IMU que je ne prenais en fait pas en compte les gyroscopes et que je me basais seulement sur l’accéléromètre/magnétomètre (l’accéléromètre étant excentré par rapport au centre de rotation de la carte IMU, on s’en aperçoit mieux). Le modèle cinématique de mise à jour de létat en fonction des gyros était en fait légèrement erroné (une petite matrice par-ci …).

Bon bref j’ai réussi à regler tout ça et avoir des resultats corrects et sans lag.

Hier, on a commencé à intégrer tout le code et à contrôler les moteurs correctement avec l’I2C, mais je laisse les autres détailler, je n’etais pas là l’après-midi …

Et aujourd’hui, c’etait au tour de l’asservissement d’être integré dans le code et testé. Il a fallu évidemment faire face aux éternels problème d’orientation  (argh, la carte est à 45° par rapport à l’avant de l’Helico !) et d’angles, en passe d’être résolu ce soir.

Fernando et Miguel s’occupent d’un protocole de communcation par ZigBee ou Bluetooth (compatible avec celui de Mikrkopter) qui nous permettra de régler les coefficients du PID de manière dynamique (sans avoir à reflasher à chaque fois). Je leur laisse le soin de détailler.

Voilà une petite vidéo du rodéo actuel, avec un asservissement inexact et trop fort.

J-11 L'envol du petit !

Ca y est ! Aujourd’hui vers 17h00, notre petit protégé à fait vrombir ses huit moteurs et a décollé, tentant d’échapper aux cordelettes qui le retenaient prisonnier ! Les photos et vidéos arriveront bientôt ! Ses parents sont très fiers mais s’inquiètent un peu de sa voracité.

En effet le petit consomme facilement 24A pour une tension de 13V pour un vol repoussant la gravité. Nous avons du brancher 4 alimentations en parallèle pour le nourrir.

Sinon d’un point de vue plus prosaïque, le code de Fernando pour l’I2C a marché quasiment du premier coup : nous avions une petite erreur d’adressage pour les moteurs et le handler d’interruption n’est pas encore parfait ( probablement un problème de prise de sémaphore pour l’accès au bus ), le fix temporaire étant un delay de 20ms.

Concernant les moteurs nous avons appris que :

  • leurs adresses sont 0×52 + 2*i ou i dans [ 0 , 7 ] et que l’ordre est devant gauche, devant droite, droite avant, droite arrière etc dans le sens horaire.
  • la valeur qui compense la gravité (en portant la batterie ) en unsigned char est aux alentours de 140
  • ils sont voraces : 24A à 13V pour les 8 moteurs à une commande de 160.

A demain pour la suite !

Vacances

- Lecture de tutorial OpenGL (le plus avancé était la gestion de caméra: free fly et track ball) et wxWidgets .

- J’ai commencé a faire une interface graphique en C++ avec wxWidgets. Intégrer OpenGL à wxWidget demande un peu de travaille. De plus, je ne sais pas faire très bien les threads en C++, peut-être utiliser la librairie boost serait intéressant, mais j’ai créé une classe de base, Thread, qui utilise le POSIX. J’ai crée des buffer générique(template) et thread safe pour intégrer les modules (kernel <–> driver, kernel <–> GUI)[Miguel a fait le driver].

- Maintenant, j’arrive à lire la température de le circuit ISL6295. J’ai créé les fonctions de lecture et écriture, en utilisant les interruptions, pour le SMBus. Une interruption d’erreur arrête la communication, et la fonction appelé retourne erreur. Ça sera utile à les moteurs de l’heliokter, car quand un tombe en pane le système continue à marcher. J’ai fait aussi les fonction d’écriture et lecture des moteurs, il faut les tester.