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.

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 : 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.

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…

09/04 avancement

Aujourd’hui j’ai travaillé sur le protocole de communication du système. Nous avons déterminé les messages qui seront envoyées par le zigbee.

J’ai écrit une interface utilisateur pour la carte de tp, en utilisant le lcd et les boutons. L’option choisie par l’utilisateur est envoyé par zigbee au serpent.

Le serpent reçoit le message par zigbee et la distribue par le bus CAN. J’ai commencé à écrire la partie où les messages sont interprétés et envoyés à fonction de calcul.

Carte logique wheely

Hier, j’ai fait fcontionné le bus CAN sur la carte logique de Wheely, ce qui m’a permis de communiquer avec ma carte de TP et donc de pouvoir faire du débuggage plus parlant sur l’écran LCD. J’ai donc pu m’atteler au fonctionnement du gyroscope qui a fonctionné ce matin.

Ensuite, je me suis occupée des interrupteurs qui m’ont posé pas n=mal de problèmes en particulier parce qu’ils sont sur le même handler d’interruption.

Le gyroscope fonctionne aussi, et l’accéléromêtre étant exactement sur les mêmes pins sur notre carte que sur la carte IMU, il n’y a pas de modifications à faire sur la partie du code le concernant.

J’ai ensuite essayé de faire fonctionner l’UART1, mais pour l’instant mes essais ne sont pas concluants…

J’ai aussi fait un fichier utils.h avec les fonctions de base, qui contient pour l’instant atoi et itoa.

J’ai fais quelques recherches sur la récupération de l’ID des cartes, dans le but de faire une fonction qui vérifie qu’on a bien fait les #define qui conviennent à la carte connectée.

08/04 après midi

Aujourd’hui j’ai travaillé un peu plus sur l’ADC, mais il continue à ne pas marcher…

J’ai inclus les ids dans la communication par le CAN. J’ai crée 2 filtres pour cella, les messages envoiés directement à une vertèbres sont dans la FIFO0, les messages envoiés à tous dans la FIFO1.