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;

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)

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.



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 !…).

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.

bilan de l’après midi

Cet après midi j’ai codé la fonction d’initialisation des DAC, et deux fonctions de test, l’une qui sort un signal constant à VCC/2, l’autre qui génère un signal en dent de scie entre 0V et VCC de période 1s. Je n’ai pas eu le temps de les tester vraiment (il faut dire qu’un oscilloscope, c’est un peu une usine à gaz quand on a juste besoin d’un voltmètre). Cette fonction s’est vite codée (1 petite heure).

En revanche, j’ai passé beaucoup de temps (3h) à faire éxécuter un programme de base (initialisation + leds) sur la carte de projets. J’ai été ralenti par plusieurs petites erreurs bêtes, comme par exemple le fait de m’apercevoir au bout d’une heure qu’on bootait sur le bootloader de st (merci du tuyau Sam!). Maintenant ca marche.