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.

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.

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.

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.

Tic Tac Tic Tac

Journée fructueuse (Youhou!!!)

Comme indiqué par Kellya ce matin le bus CAN fonctionne (ENFIN !!!). Cet après midi je me suis donc attaqué à la récupération des encodeurs. Comme il est impossible d’utiliser les modes « encodeur » des timers de la carte de TP (pins déja prises), j’ai utilisé la carte du projet propulsion de l’an dernier… Et pour pouvoir afficher le nombre de tic sur l’écran LCD je l’ai relié à ma carte de TP… avec le bus can (il faut bien qu’il serve à quelque chose…).

Le montage électrique est assez moche (dommage que je n’ai pas mon appareil photo !) mais ça fonctionne. En revanche on (Kellya et moi) constate qu’il y a une latence d’une seconde entre la rotation de la roue et l’affichage sur le LCD.

à faire :

déterminer d’où vient la latence. (LCD ? CAN ? encodeurs ?)

réaliser un petit programme de communication carte TP / port série  parce que minicom c’est quand même mieux qu’un LCD de 32 caractères.

faire les fonctions qui donnent la position, la vitesse, l’angle de lacet et la vitesse de rotation en lacet avec des unités compréhensibles (plus pratique pour le calibrage et les tests).

PS : j’ai aussi complété les slides de mon groupe pour la soutenance de Mercredi.

Communication challenge 2010

Le but de ce challenge est de vous faire utiliser un protocole de communication conçu pour l’occasion, tout en vérifiant que vous savez utiliser les différents périphériques de votre carte de TP. Ce challenge est conçu en étapes successives : la carte annonce au serveur l’étape qu’elle souhaite vérifier. Les étapes doivent se faire dans l’ordre croissant et aucune ne peut être omise sous peine de causer la disqualification du participant.

Description du protocole

  • Le protocole est basé sur des chaînes de texte terminées au choix de l’envoyeur par l’un ou les deux de « \r » et « \n ».
  • Les différentes composantes de chaque échange sont formés à partir de chaînes de caractères (sans délimiteur) et d’entiers positifs ou nuls.
  • Toutes les entités sont séparées par des espaces.
  • Aucun espace n’est autorisé en début ou en fin de commande, et un double-espace est interdit.
  • À l’exception de la commande « STEP » qui est envoyée spontanément par le client (votre carte), toutes les opérations sont initiées par le serveur et sont suivies d’une réponse du client.
  • Toute commande non comprise par le client ou mal formée doit être ignorée et ne doit provoquer l’envoi d’aucune réponse.
  • Aussi bien le serveur que le client peuvent, à tout moment, envoyer une ligne vide qui sera ignorée.
  • Un message ne comprendra jamais plus de 256 caractères.

Étape 1 : configuration Zigbee

  • Configurer la carte Zigbee pour que son identité soit vos initiales (comme lors du TP), sauf pour François-Xavier qui choisira « FX ».
  • Les réponses seront envoyées à l’identité « CC » : il faut donc configurer dans DH et DL l’adresse idoine.
  • Bien que cela ne soit aucunement obligatoire, il est conseillé d’utiliser le mode API 1 du module Zigbee : ce mode permet de savoir si un paquet a bien été reçu par le destinataire ou s’il est nécessaire de le retransmettre.
  • Envoyer le message « STEP 1″ au serveur.

Cette configuration Zigbee devra être maintenue pour les étapes suivantes. De plus, chaque commande implémentée devra le rester, car elle sera utilisée dans la suite du challenge. Chaque étape peut constituer en plusieurs cycles commande/réponse.

Étape 2 : gestion d’une commande simple

  • Envoyer le message « STEP 2″ au serveur.
  • Accepter la commande « PING ».
  • Répondre en renvoyant « PONG ».

Étape 3 : gestion d’une commande avec arguments

  • Envoyer le message « STEP 3″ au serveur
  • Accepter la commande « ADD t n1 n2 n3 … nt » où « t » (un entier positif) est le nombre d’entiers positifs ou nuls qui suivront.
  • Répondre en renvoyant « ADD-R m » où « m » est l’addition des entiers « n1″ à « nt ».

Étape 4 : afficheur LCD

  • Envoyer le message « STEP 4″ au serveur.
  • Accepter la commande « LCD n [chaîne] » où « n » vaut 1 ou 2 et « chaîne » est une chaîne de caractères délimitée par les caractères « [" et "] » et pouvant contenir des espaces.
  • Répondre en renvoyant « LCD-R m » où « m » est le nombre de caractères de la chaîne contenue entre « [" et "]« 
  • Afficher la chaîne de caractères sur l’afficheur LCD en la faisant défiler si et seulement si la chaîne fait plus de 16 caractères. Attention, le défilement doit se faire en tâche de fond et continuer tant qu’autre chose n’a pas été spécifié.
  • L’affichage sur les deux lignes doit être indépendant.
  • Si une chaîne fait moins de 16 caractères, les caractères non affichés sur la ligne concernée doivent être effacés (remplacés par des espaces).

Étape 5 : boutons poussoirs

  • Envoyer le message « STEP 5″ au serveur.
  • Accepter la commande « SWITCH » et attendre, une fois que les deux boutons sont relâchés, qu’un bouton soit appuyé par l’utilisateur.
  • Répondre en renvoyant « SWITCH-R s » où « s » vaut soit « LEFT » si le bouton de gauche a été pressé, soit « RIGHT » si le bouton de droite a été pressé.
  • Pour valider cette étape, faire les tests proposés.

Étape 6 : leds

  • Envoyer le message « STEP 6″ au serveur.
  • Accepter la commande « LEDS r g b » où « r », « g » et « b » sont des valeurs entre 0 et 255 correspondant au rapport cyclique à positionner respectivement sur les leds rouge, verte et bleue. 0 correspond à un rapport cyclique de 0% (led éteinte), 255 correspond à un rapport cyclique de 100% (led allumée), et les valeurs intermédiaires sont à traiter linéairement.
  • Répondre en renvoyant « LEDS-R n » où « n » est la somme de « r », « g » et « b ».
  • Pour valider cette étape, faire les tests proposés.

Étape 7 : buzzer

  • Envoyer le message « STEP 7″ au serveur.
  • Accepter la commande « BUZZER n f1 d1 f2 d2 … fn dn » où « n » est le nombre de notes envoyées, et « fi » et « di » la fréquence et durée en millisecondes de la note « i ». Une fréquence de 0 signifie l’arrêt du buzzer pendant le temps indiqué. La dernière durée peut être nulle.
  • Répondre en renvoyant « BUZZER-R n » lorsque la mélodie a été jouée.
  • Pour valider cette étape, faire les tests proposés.

Étape 8 : consommation

  • Envoyer le message « STEP 8″ au serveur.
  • Accepter la commande « CURRENT ».
  • Répondre en renvoyant « CURRENT-R n » où « n » est la consommation moyenne de courant sur les trois dernières secondes en micro-ampères.

Retour sur à nos moutons !

Aujourd’hui, après de trop nombreux jours en dehors de la A405 ( formation humaine intensive … ), je retourne enfin à des occupations normales.

Cet après-midi, j’ai rendu mon code plus modulable : fonctions de lecture et écriture sur le Zigbee, fonctions d’écriture par ligne sur le LCD, petit retour sur les queues pour avoir quelque chose de vraiment propre ( queue de message rx/tx pour le Zigbee, par ligne pour le LCD et de notes pour le buzzer ).

Alexis m’a aussi installé un potentiomètre, j’ai donc écrit du code pour le ADC qui nous servira plus tard sur l’Heliokter, je peux maintenant utiliser mon slider comme instrument de musique.

Préparation psychologique pour le challenge de demain (aux aurores -_- )

Musique sans fil

Ma carte de TP est maintenant capable de jouer l’Ave Maria !

Restent quelques améliorations : voir si on peut améliorer le rythme de la musique via Zigbee (j’ai l’impression de louper un peu trop de notes), mettre en place une queue pour l’affichage sur LCD (actuellement, il y a un sémaphore), remanier quelques parties de code pour le rendre plus modulaire et donc réutilisable.

TP Carte

Hier j’ai fait le PWM pour le  backlight du LCD, aujourd’hui j’ai fini les interruptions pour le bouton et j’ai réussi à varier l’intensité du LCD avec le bouton.  Je aussi commencé avec le module ZigBee, j’ai déjà fait tous les configurations pour la  réception et transmission.