ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

Copterix : état des choses pour ce vendredi soir

I2C, et PCB en général

Samuel et moi-même avons pu finalement communiquer avec les gyroscopes de notre PCB, non sans mal (cf le post d’hier soir). Nous avons donc été en mesure de montrer un exemple de récupération des données des gyroscopes, accéléromètres et magnétomètres en temps réel lors des démonstrations de cet après-midi. Le programme de ce weekend de ce côté-là serait donc de discuter à présent avec les moteurs.

Communication avec le PCB

Loïc a fait une petite démonstration de sa gestion des erreurs lors des transmissions de paquets entre le PCB et un PC. Certains points restent à éclaircir, comme notamment le compte des erreurs et la gestion des coupures.

Tracking

La démonstration du tracking ne s’est pas vraiment bien passée : effectivement, nous n’avons pas défini de protocole de test rigoureux, ce qui fait que nous avons une très mauvaise estimation des capacités réelles de notre tracking à l’heure actuelle. De plus, à cause de fuites de mémoires dans openCV non encore résolues, le programme tourne pendant 3 minutes avant de devoir s’arrêter faute de RAM. Un gros effort reste donc à fournir de ce côté-ci, mais cette fonctionnalité n’étant pas vitale pour faire voler l’hélicoptère, elle n’est pas en haut de la liste des priorités.

Kalman

Notre implémentation du filtre du Kalman en test avec les données d’une IMU gentiment fournie par Samuel Tardieu n’a pas fait une grande impression sur le jury, le fait qu’il était facile de l’affoler en secouant un tout petit peu la carte ne devant pas y être étranger. Une explication possible mise en avant par Alexis serait que nous avons mal pris en compte l’orientation des gyroscopes : je vais donc m’y pencher dès que possible pour essayer de résoudre ce problème, qui lui est vital pour la bonne marche du projet.

MB Led: Des séparations difficiles…

L’implémentation de l’algorithme est désormais presque fini. Tant que personne ne « quitte » le réseau, l’algorithme permet à tout le monde de savoir qui est dans le réseau et où il est; cela passe par une phase d’identification, une phase d’élection de leader, un positionnement des modules et la propagation de l’information au réseau entier.

Le problème principal est de bien faire cela dans l’ordre et que les informations données soient fiables et bien retransmises.

Lorsqu’un des modules quitte le réseau, celui qui s’en aperçoit propage l’information qu’il faut tout recommencer.
Pour remarquer qu’un module a disparu, la technique est simple : on envoie un PING et on laisse x ms à l’autre module pour répondre par un PONG. Si cela n’est pas fait, le module a sûrement disparu.
Lors de départ de module, il faut donc envoyer toutes les informations nécessaires sans oublier d’acquitter rapidement les PING, c’est pourquoi j’ai préféré utiliser une tache freeRTOS de très haute importance pour cela. Cependant, lors d’une simulation avec 9 modules, l’élection de leader se fait partiellement. De plus, l’acquittement ne se fait pas forcément et donc on repart à rien, ce qui peut conduire à un autre acquittement raté, etc.

 

Grâce à terminator, je peux suivre en temps réel les messages échangés entre les modules via zmq. (Les ping/pong ne sont pas montrés et il y a certains commentaires pour m’aider dans le débug.)

 

Copterix : communications

Depuis mercredi, je me suis occupé d’implémenter la communication via UART entre STM32 et Linux.

Comme nous ne disposions ni de la gumstix parfaitement fonctionnelle, ni du STM32, j’ai commencé à communiquer entre ma carte de TP et mon ordinateur, via un cable micromatch 4 / USB.

J’ai commencé par réaliser la partie du code du STM32, sous FreeRTOS. Je me suis alors rendu compte que contrairement à ce que je pensais, le protocole XModem n’était pas vraiment adapté à ce que je voulais, mais qu’il y avait dans celui-ci de bonnes idées, il a donc constitué un très bon départ pour un protocole maison. Voici le protocole que j’ai finalement adopté :

Les données à envoyer sont regroupées au sein de structures C (une pour l’ensemble des données des capteurs, une pour l’ensemble des commandes des moteurs). On envoie les données structures par structures, de cette manière :
On commence par envoyer un octet qui caractérise le paquet (dans notre cas, j’ai choisi 0×03 si c’est les données du capteur, 0×01 pour les commandes moteur, 0×02 pour les commandes RF). Ensuite on envoie la structure, octet par octet, sachant que l’émetteur et le receveur connaissent la structure, donc sa taille, et donc le nombre d’octet attendu. Enfin, on envoie un checksum, constitué de la somme de tous les octets modulo 256. Le récepteur va ensuite vérifier le paquet reçu avec le checksum, et l’utiliser s’il est correct, l’ignorer sinon : il n’y a pas de renvoi des paquets erroné, car cela me semble inutile, vu l’aspect temps réel des paquets échangés.

Du coup, on peut se passer d’acquittement, ce qui nous permet de fonctionner en full duplex : on devrait pouvoir envoyer les données des capteurs et recevoir les données des moteurs en même temps.

Hier donc, j’ai codé la partie STM32 (sauf les commandes RF, il faudra que je les rajoute après), puis j’ai vérifié, en dialoguant avec le PC via des scripts Python, que cette partie fonctionnait correctement.

Aujourd’hui, je me suis occupé de la partie côté Linux, en C : j’ai implémenté le protocole de réception, pour stocker les données reçues dans la structure correspondante. Ensuite, j’ai mis en place une communication 0MQ basée sur le système de Publisher/Suscriber : le module de réception publie ainsi chaque update. J’ai également créé un programme qui souscrit à ces updates, et les affiches : ses fonctions pourront être intégrées au filtre de Kalman, pour qu’il puisse souscrire aux updates.

Il me reste donc à implémenter le module d’émission côté Linux, à ajouter les paquets provenant du module RF, et je pense qu’ensuite j’aurais intérêt à faire quelques simulations pour estimer le taux d’erreurs, ainsi que le taux d’erreurs non détectées.

 

RoseWheel : Simulateur et Testbench

Aujourd’hui nous avons travaillé sur plusieurs fronts à la fois en vue de préparer la présentation d’une part et d’autre part d’avancer sur les différentes PSSC en cours, notamment la finalisation du TestBench et du simulateur.

Nous avons complètement restructuré la mécanique du Testbench. En effet, en rapport avec le Post d’hier soir, nous observions trop de bruit lors des transitions du moteur entre les différents angles.
Afin de palier à ce problème, nous avons ajouté un potentiomètre sur l’axe du servomoteur afin de pouvoir mesurer en temps réel et de façon précise le mouvement exact du moteur. Nous sommes alors en mesure d’extraire la partie issue du moteur dans le bruit du signal mesuré.
Nous avons de plus ajouté un rapporteur centré sur l’axe du servomoteur afin d’avoir un moyen de plus pour nous permettre de valider la fiabilité de la mesure des angles issus de l’accéléromètre et du gyroscope.

Concernant le simulateur, nous observons toujours des problèmes vis-à-vis des paramètres physiques. En effet, avec les paramètres que nous utilisons pour le moment, nous obtenons toujours une valeur saugrenue de la tension de commande (aux alentours de 3000V au lieu des 24V prévus). Nous avons donc remis en question chacun des paramètres que nous avions initialement calculés et nous sommes arrivés à la conclusion que les valeurs de la constante de couple reliant le courant au couple moteur et la constante de force contre électromotrice reliant la tension contre électromotrice à la vitesse de rotation étaient peut-être faussées.
Nous nous sommes donc penchés à nouveau sur une doc (très sommaire) des moteurs utilisés dans le zzaag. De plus Alexis nous a conseillé de simuler à l’aide de Matlab/Octave les équations d’état des moteurs que nous avions injectées dans les équations d’état de RoseWheel afin d’observer directement les valeurs du couple et de la vitesse de rotation de l’axe pour différentes valeurs des 2 constantes précédemment citées. Ceci nous permettra de vérifier les valeurs que nous avons calculé.

Dans l’optique de la présentation de demain, nous nous sommes penchés à nouveau sur un certain nombre de choses :

Le schéma de l’architecture matérielle a été revu et corrigé :

 

Le schéma de l’architecture logique a  été lui aussi corrigé :

Copterix : Architecture

Quelques changements depuis mon dernier post :

  • On remet le stm32 (stm32f103RE) pour deux raisons : multiplexer les sorties des capteurs et surtout avoir un os temps réel (FreeRTOS) permettant de prendre des échantillons en même temps sur l’ensemble des capteurs, indispensable pour Kalman.
  • On change de gumstix (problème de disponibilité). On prend finalement l’Overo Tide COM avec une TOBI (carte d’extension).
  • On branchera notre PCB sur la TOBI avec un connecteur barrette.
  • On remplace notre caméra par la Caspa FS à laquelle il faudra ajouter un filtre infra-rouge
  • On branchera un dongle Wi-fi sur la tobi
  • On utilisera le transceiver RF pour piloter le copter avec la radiocommande.

 

J’ai aussi fait l’assignation des pattes du STM32 pendant que Samuel commençait le PCB sur Mentor Graphic.

 

IRL, la réflexion DMX avance

En cherchant sur Internet ce que d’autres avaient déjà pu faire en ce qui concerne la gestion de DMX, nous sommes tombés sur une page présentant un petit montage de génération de trames DMX, basé sur un Arduino et utilisant un tranceiver RS485/RS422. Le code était disponible en ligne et nous avons pu voir qu’il utilise des GPIO du processeur pour générer bit à bit les sorties. D’après Sam, il y a moyen de configurer les UARTS du STM32 pour qu’elles soient directement utilisables avec le protocole DMX, on se plongera demain dans la datasheet pour confirmer. Il nous a aussi indiqué qu’on pourrait utiliser le DMA pour l’écriture des trames.

Ensuite Sam nous a aussi renseigné sur le genre de services que FreeRTOS peut nous rendre : les tâches prioritaires (ici la récupération des trames DMX, il ne faut pas en rater) sont toujours exécutées « à l’heure » (à quelques ns près), les taches moins prioritaires (comme la récupération d’un nouveau masque via le zigbee) sont exécutées « quand il y a le temps », tout ce qui compte est de savoir qu’en moyenne on a le temps de tout faire. Le même principe nous sera utile pour la génération très précise des signaux de commande du laser. Le cours de lundi matin nous en dira plus sur ce sujet, ce sera très utile !

Enfin, nous avons une idée qui nous semble robuste concernant la boucle de sûreté du laser. Afin de résister à un crash de la carte principale (Linux) OU du STM32 qui contrôle le laser (FreeRTOS), nous avons pensé à l’architecture suivante :

  • Sur le STM32 : une routine de priorité maximale (plus que l’OS) qui vérifie à intervalles réguliers que le laser a bougé, s’il n’a pas bougé pendant une certaine durée (à déterminer ou plutôt trouver dans les normes), le laser est coupé
  • De plus, le STM32 doit signaler périodiquement à la carte principale qu’il se porte bien. S’il s’arrête de le signaler, la carte principale en déduit qu’il a crashé, et coupe le laser.

 

IRL : du nouveau, encore du nouveau !

Après une n ème réflexion le projet IRL évolue et se précise :

Laurent s’est penché sur les datasheets de différents modules Zigbee, notamment ceux employés à Télécom Robotics (nous remercions au passage Samuel pour son lien). Il a étudié comment brancher les modules Zigbee pour pouvoir les utiliser via un lien RS232. Pendant ce temps, Yoann s’est renseigné sur internet sur les DAC et nous avons tous ensemble regardé les cartes d’extensions disponibles pour la Beagleboard.

Yoann et Caroline ont compris grâce à Alexis que Linux ne serait pas bien adapté à l’envoi en temps réel des points au laser. Nous utiliserons donc un micro contrôleur dédié à cette tâche avec un OS temps réel qui sera vraisemblablement FreeRTOS (toutes suggestions serait la bienvenue). Ceci porte à trois ou quatre le nombre d’entités du système qui est désormais formé des éléments suivants :

  • Une carte (appelée « principale » par la suite) hébergeant l’interface web d’administration, dont les fonctions principales sont le stockage des informations et le pilotage du système.
  • Un micro contrôleur traitant le flux DMX à la volée, recevant des informations de la carte principale par Zigbee.
  • Un micro contrôleur en charge des déplacements du laser, recevant des informations par un lien filaire qu’il a avec la carte principale.
  • Un autre micro contrôleur en charge de la sécurité : il coupe le laser s’il reste sur un même point pendant trop longtemps (cette fonction pourrait éventuellement être déportée sur la carte principale).