Site ELEC344/ELEC381

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

Catégories

Nouvelle avancée : rotation des blocs

Voici une petite vidéo pour illustrer la possibilité de tourner tous les blocs sauf le maître :

Serpentina : début des bons mouvements

Jeudi :

La calibration des cartes (trouver le degré neutre de chaque servo de toutes les cartes) a été fini et le code a été changer pour prendre en compte le fait que les servos verticaux sont alternés toutes les deux cartes (degré positif -> la vertèbre monte, degré positif -> la vertèbre suivante descend).
À partir du moment qu’on a eu une interface pour contrôler individuellement les servos, Flavia et moi avons aussi corrigé la relation entre l’angle de mouvement et la largeur du pulse (avant le mouvement du serpent ne correspondait pas à ce qu’on voulait).
Cela corrigé, on a commencé à faire des tests de déplacement avec le serpent. Et, finalement il a bougé. Et après des corrections, on a pu le faire marcher en avant, en arrière et a le faire s’arrêter et retourner à une position de reset (tout droit et plat).
Le soir, j’ai commencé à vérifier les envois des messages pour faire le virage du serpent.
Ah, le bootloader arrive bien à flasher les dix cartes. On a eu un problème de temps qu’il mettait pour tout finir mais c’était notre carte du TP qui le retardait. Sans aucun affichage dans le LCD, il met à peu près une vingtaine de secondes pour flasher toutes les dix cartes en parallèle.

Vendredi :

L’après-midi, j’ai mis quelques heures pour trouver un problème dans notre bootloader. D’un coup, il ne marchait plus. C’était une configuration du can, mais comme rien par rapport à cette configuration n’avait été changé dans notre dépôt, c’était dur de le trouver. Le bizarre c’est qu’il marchait avant. Ensuite, j’ai continué à travailler sur les virages. J’ai vu que les messages envoyés étaient ce qu’on voulait, mais le robot ne marchait pas.

Samedi :

Ce matin, j’ai pensé à une autre solution pour le virage. Au lieu de le tourner en une position X fixé, la tête du serpent tourne quand elle reçoit le message TURN et ensuite elle envoie un message à la vertèbre suivante. Celle-ci attend quelques instants, tourne et envoie un message à la vertèbre suivante. Ça jusqu’à la dernière vertèbre. Après des corrections, on a réussi à faire des virages dans le deux sens (quand le serpent marche en avant et en arrière). Cependant, on a encore des erreurs : parfois, les cartes se bloquent. Je reviens à ça ensuite.

La vidéo d'illustration ...

Voici la vidéo dont Julie a parlé :

EDIT : Les positions sont recalculées après déplacement !

EDIT2 : Avec une (petite) animation !

Serpentina : premier contact avec le robot

De la fin de la semaine dernière (les après-midis de jeudi et vendredi) jusqu’à aujourd’hui (hier et cette après-midi), j’ai travaillé sur le codage de l’algo pour faire le serpent tourner. On avait une idée de la façon de le faire, mais il n’était pas encore codé. En bref, nous avons deux modes : un premier qui prend en compte une valeur X (déplacement horizontal) qui vaut toujours entre 0 et la valeur de la période de la sinusoïde, et un seconde dont la valeur X n’est pas limitée par la période. Comme on ne pouvait pas faire des tests pratiques, on a codé les deux modes. J’ai aussi fait une vérification du code de la partie de communication et synchronisation entre l’arrivée d’une message de commande et son exécution.

Ce soir, Alexis a fini de souder les cartes de l’année dernière et j’ai commencé à faire la calibration (trouver l’angle neutre de chaque servo) des moteurs et à vérifier si toutes les cartes marchent bien. J’ai testé quatre ou cinq cartes et je n’ai pas eu aucun problème. Pour cela, j’ai utilisé ma carte du TP pour flasher les cartes.

Prochaines étapes pour la suite :
- finir la calibration/tests individuels de chaque carte;
- réviser le code parce que les servos qui contrôlent les mouvements verticals sont alternés;
- vérifier qui le bootloader va bien marcher pour les 10 cartes en parallèle (apparemment oui);
- commencer par tester une carte, deux cartes, trois cartes, …, jusqu’à avoir toutes les cartes en marche;

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.

Avancement GLiP

Pendant la fin de la semaine dernière, j’ai fini le bootloader pour les GLiPs, piloté par la carte de TP. Je n’avais que deux blocs à ma disposition mais il semblait bien fonctionner. J’ai maintenant beaucoup plus de doutes quand je vois tous les problèmes que l’on rencontre avec 4 blocs !…

Dans l’hypothèse où un GLiP serait directement relié au PC par port série, j’ai aussi écrit (aujourd’hui, mardi) une interface en Python pour le flasher via port série, puis transmis par IrDA. Je n’ai pas pu tester ce mode.

Hier, j’ai regardé avec Julie les différents problèmes que l’on rencontre lors de l’initialisation de la carte. La majorité des problèmes sont du à la communication IrDA plutôt hasardeuse et peut-être à des problèmes de priorités entre les tâches qui gèrent l’IrDA et l’affichage par LED. (cf posts à venir de Mika et Enzo)

Bootloader GLiP

Ces derniers jours, je me suis attelé à programmer un bootloader pour GLiP. En effet, lorsqu’on devra flasher les 16 blocs, ça serait beaucoup plus pratique de le faire via IrDA plutôt que par JTAG.

Dans un premier temps (vendredi, samedi après-midi, lundi après-midi), je me suis donc basé sur le bootloader du projet serpent de l’année dernière (qui flashait via le bus CAN) et j’ai adapté le système de paquets pour le bootloader. En effet, le checksum est indispensable (on ne va pas flasher n’importe quoi) mais on peut se passer de certains champs (TTL, émetteur, …).

J’ai repris la bibliothèque pour l’écriture dans la Flash de l’année dernière (mardi).

Aujourd’hui (jeudi), j’ai enfin réussi à jumper à une adresse mémoire donnée au bout d’un Timeout (lorsqu’aucune commande bootloader n’a été reçue), ce qui est une fonction assez intéressante pour un bootloader !

Programme de demain : débugger la communication IrDA qui ne semble pas fonctionner (le bootloader jump même si une commande a été envoyée !…).

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…

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

Serpentina : contrôle d’un moteur

Hier j’arrivais à écrire dans la flash avec le bootloader de l’année dernière, par contre mon propre programme ne marchait pas.

Aujourd’hui, pas-à-pas, Flavia et moi, on a testé d’abord la configuration des leds et ensuite celle du moteur. Quand on a bien configuré la sortie du moteur, il y a avait juste une petite erreur dans le PWM qui génerait cette sortie, problème qu’on a résolu avec l’aide de l’oscilloscope. La prochaine étape était mettre un moteur en marche à un angle désiré, ce qui a été fait sans soucis.

Ensuite, on a ajouté le can qui était déjà configuré et parciellement testé (pour vérifier les envoies des trames CAN). Dans cette partie, parfois notre carte plante. On essaie de faire un debug du programme pour trouver exactement où se trouve l’erreur.

Prochaines étapes : vérification de la réception des trames CAN par les cartes des vertèbres, soudage des cartes dans les vertèbres, tests du serpent.