Site ELEC344/ELEC381

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

Catégories

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 !

Heliokter: Wahba

Aujourd’hui:

Première version d’une bibliothèque de quaternions (samble marcher).

Première version du FQA (semble marcher).

Hier:

Lecture du protocole i2c (partie théorique et le datasheet).

Première version d’une bibliothèque i2c.

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 …

Heliokter et Wahba

Projet :

  • Finalisation de la liste des composants : la magnétomètre et l’accéléromètre seront finalement en SPI tandis que les gyroscopes et les télémètres seront analogiques. Pour le processeur, le F103 du TP semble convenir ( on peut y mapper deux UART, le bus I2C, le bus SPI, 6 entrées analogiques et il reste encore pas mal d’IO pour les LEDs et autres). Encore une petite question qui me taraude sur ces ports séries et les périphériques qu’on va utiliser : GPS, ZigBee et debug intial avec DB9, ça fait 3 mais qu’on n’utiliseras pas en même temps (d’abord debug puis ZigBee puis ZigBee/GPS) donc ça ne sert à rien d’avoir trois UART et en même temps ça serait embetant de déssouder la carte. Donc ça serait pratique d’avoir un truc qui se branche.
  • Simulateur : j’ai réussi à compiler de l’OpenGL avec un Makefile (tout avait été jusque là magnifiquement caché par mon IDE) mais ça ne marche évidemment que sur mon Mac. C’est pas essentiel non plus mais faudrait penser à une belle architecture des sources pour que d’autres puissent aussi implémenter leur openGL tout en laissant le code principal inchangé
  • Code source de Mikrokopter : la grande question est : Mais qu’est-ce que diable fait-on circuler sur le port I2C pour controler les moteurs (via les controleurs Brushless) ?  J’ai déjàé trouvé dans quels fichiers et quelles fonctions ça se passait mais il me manque encore quelques variables globales/macros que je n’ai trouvées dans aucune source. Peut-être une libraire fournie avec leur processeur ?

Exposé : Etude de l’aglorithme TRIAD et des variations qui en ont été faites. Rédaction des slides pour la présentation de vendredi.

TP : Début du placement/routage de la carte de TP. J’ai découvert que c’était vachement plus pratique d’avoir le schéma logique sous les yeux avec les identifiants des composants pour placer et router les composants efficacement. Je me rends compte aussi que la moitié (si ce n’est les 3/4) des connexions à faire  (les traits blancs) sont en fait des connections d’alim …


Kopter : farfouille

En fouillant sur les pages germanophones du site de Mikrokopter, je suis tombé sur de magnifique courbes Poussée / Ampérage, caractéristique de l’ensemble moteur+hélice. Ca me semble utile pour le simulateur, même si je ne suis pas sûr qu’au final, ce soit vraiment l’ampérage des moteurs que l’on contrôle (bus I2C, connection PPM ???!!??).

Toujours pour le simulateur, j’ai trouvé un petit article « Théorie des hélicoptères multirotors » qui met un peu en équation tout ça. Cet article se trouve sur le blog d’un passioné du désert qui est lui aussi en train de construire son Mikrokopter, donc potentiellement intéressant.

Enfin, des débuts de recherche sur le problème de Wahba.

Sinon, je vois que tout le monde prend un super nom/acronyme pour son projet, je ne sais pas si Oktokopter suffit pour nous (sachant que c’est déjà plus ou moins son appellation officielle par les gens de Mikrokopter)