Site ELEC344/ELEC381

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

Catégories

Un protocole générique

Semaine du Vacances

Étant donné que on travaille avec le bluetooth ou avec le ZigBee pour établier la communication entre la PC et entre la carte du notre Heliokter ou avec l’IMU, donc j’ai commence à travailler sur un protocole de communication universel. Avec ce  protocole on aura la possibilité soit de recevoir ou envoyer des données au Heliokter en utilisant les mêmes fonctions quand on fait use de la communication par ZigBee ou par Bluetooh. Le protocole doit être générique du côte PC et du côte carte .

Au début de la semaine j’ai commencé à faire le protocole en utilisant la carte interface ZigBee. Cette carte à un module ZigBee et est relié à la PC directement. Après la remarque du Samuel sur la configuration de la carte j’ai réussi faire la communication avec la carte du TP.

Après j’ai commence à faire le codage des fonctions génériques dans les fichiers protocol.c et protocol.h et j’ai testé sur la carte su TP.

Vendredi et jeudi,  j’ai lu code de Fernando sur le i2c et on a travaille ensemble, surtout le vendredi,  pour trouver les erreurs de la communication i2c. Au début les fonctions de i2c bloquaient tout le système quand ils n’avaient pas de moteurs sur le bus. Après de regarder, en utilisant l’oscilloscope, les trames qui ont était envoyés  au ISL pour lire la température ou autres registres du ISL , on a trouvé que il avait des cas que n’ont était pas traités dans les interruptions.

Lundi 25  et Mardi 26

J’ai porté la communication par Bluetooth sur le protocole générique. Aussi avec Fernando on a réfléchi  sur les possibles erreurs du protocole du communication.

Nous avons pris comme référence le protocole de Mikrocopter pou faire la notre. Mais, on avait des problèmes quand le byte de fin de trame était présent en milieu de la trame.  La solution qu’on a pris est de utiliser le caratère de échappe ( ‘\’ ) pour identifier les données qui ont le même valeur qui le caractère du fin du trame et le même caractère du échappe.

J’ai fait les fonctions génériques pour le protocole, mais il fallait aussi modifier les fonctions du ZigBee et du Bluetooth, toujours des deux côtes : PC et carte.  Maintenait ça marche bien avec le bluetooth, pour le zigbee , avec Fernando, on a finit de faire le codage mais il  maque faire les test.

Heliokter bourdonne

J’ai passé la fin des vacances sur le filtre de Kalman, pour l’affiner/le corriger. Je me suis rendu compte avec la carte IMU que je ne prenais en fait pas en compte les gyroscopes et que je me basais seulement sur l’accéléromètre/magnétomètre (l’accéléromètre étant excentré par rapport au centre de rotation de la carte IMU, on s’en aperçoit mieux). Le modèle cinématique de mise à jour de létat en fonction des gyros était en fait légèrement erroné (une petite matrice par-ci …).

Bon bref j’ai réussi à regler tout ça et avoir des resultats corrects et sans lag.

Hier, on a commencé à intégrer tout le code et à contrôler les moteurs correctement avec l’I2C, mais je laisse les autres détailler, je n’etais pas là l’après-midi …

Et aujourd’hui, c’etait au tour de l’asservissement d’être integré dans le code et testé. Il a fallu évidemment faire face aux éternels problème d’orientation  (argh, la carte est à 45° par rapport à l’avant de l’Helico !) et d’angles, en passe d’être résolu ce soir.

Fernando et Miguel s’occupent d’un protocole de communcation par ZigBee ou Bluetooth (compatible avec celui de Mikrkopter) qui nous permettra de régler les coefficients du PID de manière dynamique (sans avoir à reflasher à chaque fois). Je leur laisse le soin de détailler.

Voilà une petite vidéo du rodéo actuel, avec un asservissement inexact et trop fort.

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.

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.

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 -_- )

29/03

Matin: J’ai fini mon TP, je reçoit la musique. J’ai aussi essayé de laisser le code plus propre.

Après-midi: J’ai travaillé dans la rédaction de l’article.

TP prêt

Aujourd’hui j’ai fait marcher la transmission du zigbee. Là, ma carte reçoit les fréquences et le buzzer sonne (aparamment) bien les chanson reçus. J’ai profité aussi pour faire un cleanup de mon code et pour créer des fonctions d’une API qui pourront être utiles pour l’avenir.

J’ai également fini la rédaction de ma partie de l’article.

TP : Zigbee et Buzzer

Lundi 29 j’ai fini avec la communication  zigbee. La réception et la transmission marchent bien.  J’ai aussi crée une fonction pour faire travailler le buzzer à n’importe quelle fréquence et ça marche bien. Pour finir le TP, il me manque seulement filtrer les fréquences de réception et passer ces fréquences au buzzer pour jouer de  la musique.

TP et Gyromètre

TP: Le buzzer semble marcher. Le code du zigbee a été déjà fait en utilisant des queues de FreeRTOS et interruptions. Après, il faudra le tester.

Gyromètre: j’ai lu 3 articles:

  • Un capteur, du début du gyromètre MEMS, qui utilise piézorésistance, force de Coriolis et Lorentz (ici).
  • Pour mieux comprendre le principe physique des erreurs du gyromètre (ici).
  • Avec filtre de Kalman (ici)(malheureusement je n’ai pas bien compris, j’ai doit étudier le Kalman tout seul avant).