Site ELEC344/ELEC381

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

Catégories

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.

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;

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.

Que le filtre soit et le MATLAB fût

Aujourd’hui nous avons travaillé sur la fusion de capteurs et la calibration du filtre. Nous avons mis au point une méthode expérimentale avec un servomoteur qui permet de contrôler précisément le mouvement donné à la carte et de les analyser ensuite.

Après avoir bataillé un peu dans tous les sens et joué avec les différents paramètres nous obtenons des courbes plutôt sympathique… Mais affaire à suivre !

Fusion de capteurs et petits oscillations

Comme annoncé dans mon précédent billet, j’ai relevé des mesures pour des petites oscillations, plus proche de la réalité. La méthode d’analyse des courbes me parait très bonne pour calibrer et analyser la fusion de nos capteurs. De plus les résultats mesurés sont plutôt bons et reflètent bien la réalité.

Dans l’idéal, si l’on pouvait monter la carte inertielle sur une servomoteur, et lui faire subir des oscillations bien contrôlées (dont on connait l’angle et la fréquence), il serait possible de faire par ma méthode une calibration parfaite ! Je sais pas si Alexis à un servomoteur adéquat qui traîne ?

Voici les résultats obtenus :

Heliokter : acquisition des gyros

Hier et aujourd’hui, je me suis centré sur l’acquisition des données des gyroscopes, à l’aide des ADC (contrairement à l’accéléromètre et aux magnétomètre qui possédaient une interface numérique SPI). J’ai eu un peu de mal hier après-midi pour faire marcher l’ADC puisqu’il fallait mettre le bit ‘enable’ de l’ADC deux fois à 1 : une fois pour ‘power up’ et l’autre pour activer réellement la conversion.
J’ai vu (et corrigé) ce problème hier soir ce qui m’a permis de reprendre aujourd’hui sur un bon pied et d’implémenter l’acquisition sur plusieurs canaux, avec la DMA.
J’ai essayé de faire une mise à l’echelle (avec un rapport VDD/nbre de bits et la sensibilité des gyroscopes) pour obtenir des valeurs en degrés par seconde mais je doute un peu de la méthode. Voilà une des courbes que j’obtient en prenant un point toutes les 20ms, et en faisant l’intégration en post-production (avec awk). Le mouvement que je fais faire à la carte est une rotation de 90° dans un sens puis dans l’autre (du plan horizontal au plan vertical, autour de l’axe Y).

Sur cette courbe, on voit que :

  • La forme est correcte (c’est déjà ça !)
  • Les valeurs non nulles des gyros au repos (je n’ai pas encore fait d’offset) entraine une grosse déviation de l’angle (15°  environ au bout des 2 secondes de test ici)
  • Ma fonction de mise à l’échelle n’est pas terrible, même en prenant en compte la déviation du gyro. C’est aussi peut être dû à l’intégration offline qui n’est faite que toutes les 20 ms du coup …
  • Ou alors c’est la calibration de l’ADC …
  • Peut-être aussi qu’on a aucune garantie du fait que  Vdd correspond à 4095 et Gnd à 0 une fois encodé sur l’ADC, même en calibrant tout ce qu’on veut …

Voilà sinon, c’est à la mode, j’ai fait un petit diagramme de Gant pour les deux semaines qui vont venir. Les noms indiqués sont les noms des responsables et bien sûr il y aura de la collaboration sur certaines tâches.

C’est assez flou sur la dernière semaine puisque ça dépend beaucoup de ce qu’on aura effectivement réussi.

Edit (00:36) :

J’ai implémenté le calcul de l’intégrale sur la carte. Pour le problème de la virgule fixe (qu’on ne peut pas résoudre avec la nouvelle norme de C avec les _Fract et _Accum, celle-ci n’etant pas porté pour nos architectures), j’ai pour le moment fait un bête scaling de 1000 et je représente mon nombre sur un long. C’est ce qui m’a paru le plus logique puisque je sample des valeurs entières sur un nombre entier de millisecondes. C’est peut être pas le plus malin en terme de bits mais ça a le mérite d’être simple . Et voilà la nouvelle courbe que j’obtiens, beaucoup plus satisfaisante (en post-traitement, j’ai juste recalé la valeur intégrée à 0 au début et divisé la valeur par 1000). Modulo le décalage, on atteint plus que 80°, sachant que je n’ai pas vraiment pris mon équerre pour faire le mouvement.

A ce propos, est-ce qu’on peut disposer à peu de frais d’un dispositif tournant à vitesse lente, constante et connue sur lequel on pourrait tester les gyroscopes précisément ?

Études de cas

Sujets

  1. PWM et ponts en H
    • principe des ponts en H
    • différents mode du contrôleur PWM : rôle, intérêts ?
    • équipe : Julie, Flavia, Romain, Étienne M.
       
  2. Contrôle par PID
    • principe
    • calibration
    • équipe : Daniel, Micka, Étienne D.
       
  3. Filtre de Kalman
    • principe
    • calibration
    • équipe : Kellya, Enzo, Thibaut
       
  4. Problème de Wahba
    • TRIAD, QUEST, FAQ…
    • équipe : Fabien, Alexandre, Efix
       
  5. Processus de décision répartis
    • équipe : Florent, Renato, Miguel
       
  6. Capteurs inertiels (MEMS + magnétomètres)
    • type d’information renvoyée
    • utilisation
    • défauts, correction
    • équipe : Arnaud, Xavier, Fernando

Déroulement

  1. Vendredi 26 février : soutenance orale de 20 minutes par exposé, chacune suivie de 10 minutes de questions.
  2. Mardi 30 mars : publication sur ce site d’un article consacré au sujet de chaque équipe.