Site ELEC344/ELEC381

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

Catégories

Serpentina - Bugs, blocage et une petite vidéo

Aujourd’hui, on a travaillé pour essayer de corriger des erreurs qui causaient des blocages de quelques cartes de notre serpent. Comme on a un système distribué, c’était dur de le debugger, et en plus on n’arrivait pas toujours à réproduire ces blocages. On a pu corriger quelques erreurs mais qui nous amenaient à d’autres, et à la fin de cette après-midi, notre exécution se bloquait encore au moment de faire un virage. Demain je me lance là pour trouver la cause du problème.

Ah, on a aussi transformé en paramétrable la variable qui donne la vitesse du serpent, et on a changé quelques configurations de la sinusoïde pour avoir des mouvements plus constants.

Et pendant qu’on essaie de trouver les solutions pour nos problèmes, voici une petite démo de notre serpent.

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;

vacances de printemps

Depuis que nous ne sommes plus bloquées à cause des bibliothèques ST, on a pu avancer.

Cette semaine j’ai fait :

-          L’ADC fonctionne dans le mode non continu ;

-          J’ai amélioré l’interface pour control du serpent en utilisant la carte du TP ;

-          J’ai modifié l’interface écrit en python du bootloader/contrôleur de l’année dernière, et on peut l’utiliser pour contrôler notre serpent.



Serpentina : début de la semaine

Lundi : étant bloqué au nombre de tâches depuis la semaine dernière, j’ai cherché des solutions pour notre problème de blocage. Je savais que le code de l’année dernière avec notre bibliothèque ne marchait pas, alors j’ai essayé de trouver la bonne configuration de cette bibliothèque (en la comparant avec celle de 2009), mais sans succès. À la fin de la journée, Jon m’a aidé, mais aussi sans succès pour trouver la source du blocage. Ce qu’on a vu qui marchait c’était notre code avec la bibliothèque de 2009.

Mardi : après un OK de Sam, on a migré notre code vers la bibliothèque de 2009. Enfin, après à peu près une semaine bloqué dans le même problème (dans cette période on a pu faire d’autres choses en plus), on a pu continuer à dévélopper notre programme. J’ai travaillé aussi sur notre carte du TP pour coder un programme qui simule d’autres cartes du serpent (comme ça, on peu vérifier qu’un carte reçoit et envoie bien des données par le can). Par fin, les configs du zigbee et du convertisseur analogique-numérique ont été ajouté au code des cartes du serpent.

Mercredi : J’ai fixé des bugs du zigbee, et il semble marcher bien. Je l’ai synchronisé avec la carte du tp, et la petite carte arrive à recevoir des données. Bientôt les cartes seront soudées dans les vertèbres et on pourra faire des tests directement dans le serpent, en espérant qu’il va bien faire des mouvements.

Serpentina : jeudi et vendredi

Jeudi et vendredi derniers, moi et Flavia, on a travaillé sur la communication can de la carte du serpent (entre deux cartes du Tp, le can marchait bien). On ne savait pas la raison (on pensait aux interruptions), mais toujours il y avait quelque chose qui bloquait son exécution. Peu à peu, on a trouvé des morceux de code qui ne nous posaient pas de problème et enfin on a fini par bien transmettre des trames. Juste l’interruption pour la transmission ne marche pas mais on peu envoyer des données quand même.

Ensuite, on s’est lancé à la réception des trames can. Toujours, quand on activait toutes nos tâches, la carte se bloquait. Donc, on a essaie d’utiliser juste une tâche de réception. Après mettre beaucoup de temps pour bien configurer notre carte du Tp et faire des tests, la réception a bien marché avec des interruptions et des masques.

Pendant cette recherche des solutions pour la communication can, on a trouvé un autre problème (peut-être celui qui nous posait des problèmes pour le can) qui ne nous semble pas être simple : on est limité à lancer juste trois ou quatre tâches maximum (cela dépend de ce qu’on configure/initialise). On ne connait pas la raison (on a parlé à Sam, mais il ne le sait pas non plus), et on est maintenant bloqué dans cette partie.

J’ai essayé d’utiliser le code de l’année dernière (juste la configuration des clocks et des leds pour savoir si la carte se bloque ou pas) avec notre bibliothèque STM32 et notre linker, et le blocage continue.

Demain, je continue à chercher une solution pour ce blocage.

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.

Finalement un bootloader qui marche!

Aujourd’hui, Flavia et moi, on est resté très longtemps pour essayer de faire marcher le bootloader de l’année dernière. En fait, depuis vendredi dernier j’essaie de l’utiliser.

On a vu qu’il y a avait plusieurs erreurs dans notre code, surtout dans la partie de communication serial-can. Tout d’abord, on n’arrivait pas à recevoir les ACKs de la carte-vertèbre (problème de la communication can). Ensuite, ce que notre carte du tp recevait de la petite carte n’était pas envoyé vers le PC (problème de communication série).

Tout corrigé, notre carte se bloquait après quelques instants d’exécution. Le problème : l’impression sur le lcd apparament mettait très longtemps. On les a viré.

À la fin, le bootloader a marché. J’ai écrit un programme qui n’a pas marché (celui qui fait le test d’un seul moteur), et ensuite j’ai flashé le main de l’année dernière et tout a été exécuté normalement.

12/04

Aujourd’hui j’ai été surtout sur le code du bootloader. Comme il n’y a ni jtag ni boot mode ram sur les cartes des vertèbres, on doit les flasher afin de faire tous nos tests.

J’ai mis un moment pour comprendre comment utiliser le bootloader de l’année dernière : on doit exécuter un scrip python, qui va lire le programme (binaire) et l’envoyer vers les cartes. Notre carte du tp fait l’interface entre l’ordinateur et les petites cartes à travers le port serial (elle reçoit les données par le serial et les envoie par le CAN).

Cette après-midi, Jon nous a aidé à utiliser ce script python. On a vu qu’il manquait encore quelque traitement de message et c’est sur ce code qu’on travaille. La carte du Tp reçoit bien les données, mais il manque les headers des messages can et le traitement des acks.

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.