Site ELEC344/ELEC381

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

Catégories

Glip: Affichage Mercredi 28 - Vendredi 30

Un résume du travail :

Mercredi:

Finalisation du code d’affichage. Changement de la manière comm on génère le PWM par software. Le Glitch avec l’ancienne routine d’affichage a disparu, par contre un nouveau Glitch dans la troisième ligne est apparu.

Création d’une librarie pour la construction des images et une autre pour la configuration des animation

Jeudi:

Correction du Glitch de la deuxième ligne de la matrice. Le problème, une variable qui n’était pas définie comme ‘static’ comme il fallait. Affichage d’une image fixe 100% fini

Début de la confection d’une barrière pour les modules. Après plusieurs heures de travail avec Alexis, le groupe a opté pour une solution qui incluait de la mousse. Finalement un commande a été envoyé à Farnell.

Vendredi :

Adaptation de la routine d’affichage d’une image en incluant une table de couleurs. Test dans une animation.

Lecture et compréhension de différents parties du code python de gif2glip.

Création d’un programme en C qui crée des fichiers include (DATA0, DATA1, …. ) à partir des données d’un fichier .glip pour la configuration des images à afficher dans chaque bloque.

Test dans les modules. L’image montré est similaire à celle qui est montré dans l’écran de l’ordinateur par gif2glip.

GLiP : Problème d'affichage

Lundi matin, j’ai commencé à réviser la routine d’affichage car de différents problèmes sont apparues quand on a testé la communication par IRDAs avec l’affichage. Cela est dû au fait que les 4 UARTS qui gèrent les IRDAs interrompent la tâche qui gère l’affichage. Comme résultat des petits points se voient dans les LEDS.

L’après midi, SAM à recommandé de refaire la routine de d’affichage en utilisant que l’interruption par le TIMER.

Hier soir, j’ai réussi à faire marcher le SPI en utilisant le module DMA.

Aujourd’hui (Mardi) je me suis dédié à continuer l’implémentation d’une nouvelle routine d’affichage. Par contre je suis seulement arrivé à montrer une ligne, mais pas une image complète correcte. Après d’avoir parlé avec SAM, une modification plus profonde dans ma façon de générer le PWM pour les LEDS semble d’être le problème.

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.

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.

Propulsion

Depuis le début de la semaine j’ai travaillé sur la propulsion, le LQR et le filtre complémentaire.

Concernant l’avancement du filtre complémentaire : voir l’article d’Arnaud.

Pour la propulsion : J’ai asservi les roues en lacet. C’était d’autant plus nécessaire que la réponse de chaque moteur à un même PWM était nettement différente et risquait de compromettre les tests en lignes droite même sur de petites distance. J’ai également fait quelques tests de mesure de vitesse avec le protocole suggéré dans l’insider guide mais les résultats ne sont pas satisfaisant : soit le temps entre deux mesures de vitesse est trop long, soit la précision est insuffisante.

Sur le LQR, J’ai modifié mes valeurs en fonction de ce qu’on a déjà fait. L’adaptation entre l’échelle des capteurs et les entrées du LQR ne devrait pas posé de problème mais la correspondance entre la valeur de sortie du LQR et la commande des moteurs n’est pas aussi évidente.

Silence on tourne, moteur… Action !

Après quelques journées où j’ai oublié de poster, voilà où j’en suis :

Je travaille sur la carte propulsion qu’on a reçu cette semaine. J’y ai adapté les programmes que j’avais écrit pour la carte de TP et la carte propulsion 2009. Désormais, je récupère la valeur des deux encodeurs, calcul la vitesse du robot et envoi le tout en permanence par bus CAN à l’autre carte qui se chargera de calculer la commande d’asservissement. Pour l’instant je ne renvoie pas l’angle de lacet ni la vitesse angulaire, ceux-ci ne servant que si on décide en fin de projet d’asservir le robot sur une trajectoire. En attendant, pour tourner il suffira j’ajouter des offsets différents sur les roues. Je peux également commander les moteurs en PWM.

à venir :

  • une API pour pouvoir facilement commander les moteurs en vitesse.
  • un asservissement basique pour pouvoir les commander en position (dans le but de faire des tests d’étallonage du gyro et de l’accéléromètre, plus de détails dans les prochains posts).
  • Essayer le trouver une solution au problème des roues voilées…

Avancement 09/04

Aujord’hui j’ai fait d’abord la configuration du PWM des deux broches (vers les deux moteurs de chaque vertèbre). La largeur du pulse est en fait le duty cycle (ça je ne comprenais pas trop avant…). Pour les tester, j’ai montré sur le LCD le résultat du calcul de la largeur du pulse et j’ai vérifié sur les leds (qui étaient branché sur les mêmes sorties) qu’il y avait une variation de l’intensité de luminosité.

Ensuite, j’ai travaille un peu plus sur la routine qui reçoit sa position, fait le calcul de celle de la prochaine vertèbre et le lui envoie. Pour cela, j’utiliserai au moins une file pour faire la synchronisation.

Par fin, je me suis lancé dans le bootloader, pour pouvoir flasher un programme et faire le « test d’un seul moteur » (étape du diagramme de Gantt). Mais j’ai eu un soucis parce que je ne comprenais pas trop le bootloader de l’année dernière (qui flashe toutes des 10 dix cartes en parallèle). Jon me l’a expliqué (merci, Jon) et je me suis lancé dans l’écriture du code pour utiliser celui de l’année dernière.

Algorithme sur le STM32

Jusqu’à hier, je faisais des simulations de l’algorithme sur mon ordinateur, pour évaluer si les positions encontrées à partir des calculs mappeaient le serpent dans une sinusoïde.

Aujourd’hui, j’ai ajouté ce code dans le code de la carte du TP pour faire la même simulation, mais sur le STM32. J’ai dû changer quelques details, surtout par rapport à la déclaration des constantes, mais à la fin, apparament les calculs en virgule fixe sont bien faits.

Ensuite, j’ai commencé à regarder la configuration du timer pour avoir une sortie PWM et à penser au déroulement de la tâche de contrôle du moteur principal (qui tourne up/down) d’une vertèbre : une queue blocke la tâche jusqu’à l’instant où la vertèbre reçoit sa position x0 calculée par la vertèbre précedente. Ensuite, elle calcule le prochain point (x1), et envoie ce résultat à celle d’après. Les calculs de l’angle et du pulse de sortie sont faits et le moteur est mis en marche.

08/04 : Bilan de la journée

Ce matin j’ai débugué l’initialisation des DAC, et des amplis. J’ai pu valider la sortie d’un signal dans les bonnes bornes (0-10V vers la carte K12N).
Cet après midi je me suis mis à coder la tâche de gestion de la carte K12N, qui regarde s’il y a une image à afficher, et qui l’affiche point par point. Il ne faut pas afficher les points trop vite : 50us par point minimum. Du coup j’ai initialisé un timer qui lève une interruption toutes les 50us. Visiblement le timer s’initialise correctement, puisque j’arrive à faire générer une PWM en lui mettant une sortie sur une patte non attribuée. En revanche les interruptions ne sont pas levées. Entre ca et un autre problème (un vTaskDelay entraine une hardfault) je n’ai pas pu terminer et passer des images sur l’écran de l’oscilloscope. J’essaierai de faire ca demain.

A part ca j’ai aidé Etienne en faisant la configuration du bus SPI nécessaire pour le controleur ethernet.

Au niveau du temps passé je dirais 2h30 ce matin et 6h cet aprem.

Avancé - Serpentina

Cet après-midi, j’ai travaillé sur le codage de l’algorithme de mouvement avant/arrière du serpent.

Pour l’instant, j’ai deux fonctions qui font les calculs pour trouver le zéro d’une fonction. Chacne utilise une méthode :
- celle de la dichotomie, qui est la plus simple à implémenter, mais qui converge moins vite; je l’ai utilisé pour une première simulation.
- celle de Brent, qui utilise les méthodes de la dichotomie, de la sécante et de l’interpolation quadratique inverse et qui théoriquement est plus rapide pour converger.

Ensuite, j’ai aussi calculé les valeurs d’un tableau d’arctangente, dont je me sers pour le calcul de l’angle de mouvement du moteur.

Ce que je fait là c’est la séparation du code pour chaque vertèbre, pour ensuite faire son intégration avec le PWM.

Flavia et moi, on a aussi choisi les responsables pour les tâches à accomplir. Notre diagramme de Gantt est le suivant (en rouge les tâches dont la responsable est Flavia, je suis responsable pour les tâches en bleu, et en vert ce sont des tâches optionnels et la préparation pour la soutenance) :