ELECINF344/381

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

Catégories

RoseWheel : Une journée ensoleillée.

Tout d’abord, nous avons pu récupérer notre carte capteur en fin d’après-midi sur laquelle étaient soudés les principaux composants, en particulier l’accéléromètre, le gyroscope, un micromatch pour une UART et le STM32 de manière à ce que nous puissions effectuer les premiers tests et vérifier que les capteurs fonctionnaient bien.

Nous travaillons encore à traiter et à récupérer de façon propre les données de l’accéléromètre mais nous avons tout de même pu allumer une LED de deux couleurs différentes suivant l’inclinaison d’un axe, la preuve que celui-ci fonctionne comme il faut.

Nous sommes aussi en train de finaliser l’initialisation des drivers pour faire fonctionner l’I2C et le gyroscope. Les tests ne devraient pas tarder.

Enfin, nous avons pu faire fonctionner l’UART et envoyer des messages sur minicom. Ce fut un peu fastidieux et nous avons passé 2 heures à débugger une erreur très bête.

Coté filtrage, nous avons réussi à fusionner les 2 filtres de Kalman décrits dans le post précédent. Finalement nous obtenons un filtre de Kalman avec un vecteur d’état à 3 composantes [theta theta_dot drift]‘ et un vecteur de mesure à 2 composantes [theta_mes theta_dot_mes].

Les tests en simulation s’avèrent très bons, le filtre suit parfaitement le biais du gyroscope et ne décroche plus sur le long terme. Il a cependant fallu un peu de temps pour régler les valeurs d’initialisation. De plus, nous avons quasiment terminée l’implémentation en C et nous espérons pouvoir lancer des tests demain en fin de journée lorsque le gyroscope et l’accéléromètre seront en fonction.

To be continued.

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

 

RoseWheel : simulation et drivers

Aujourd’hui nous avons enfin terminé la partie simulation du RoseWheel. Nous sommes donc maintenant capables de simuler avec précision la dynamique du système ainsi que le filtrage des données des capteurs.

Évidemment, la modélisation exacte des différents paramètres, notamment les bruits des capteurs n’est qu’approximative et il faudra passer un peu de temps lors de l’implémentation en réel afin de les déterminer de manière correcte.

Concernant plus particulièrement la simulation du filtrage de Kalman, nous avons implémenté dans la simulation deux filtres de Kalman linéaires, le premier chargé d’extraire le biais de la mesure du gyroscope, le second chargé d’éliminer les composantes en hautes fréquences présentes dans les données du gyroscope et de l’accéléromètre. Cependant, pour des questions d’optimisation de temps CPU, on sera certainement amenés à fusionner ces deux filtres en un seul filtre, on espère que cela ne posera pas trop de soucis.

Nous avons cependant constaté que le filtre avait quand même du mal à suivre les variations du biais que nous simulions et que sur le long terme il lui arrivait de décrocher. Toutefois, nous pensons qu’il s’agit plus d’un problème au niveau de la simulation et que nous nous pencherons de façon plus approfondie sur le problème lorsque nous implémenterons le filtre en réel, c’est à dire demain.

Nous avons aussi pensé que cela pouvait être causé par la nature non linéaire du biais présent dans les données issus du gyroscope et qu’il serait peut-être nécessaire d’implémenter une forme de Kalman étendue plutôt que la forme linéaire. Mais encore une fois, nous testerons demain en réel afin de décider de la nécessité, ou non, de passer à une forme étendue du filtre.
Clément et Joao ont de leur côté continué d’implémenter les drivers pour les cartes.

Bonne nouvelle ! Alexis a terminé de souder les composants sur notre carte capteur. La journée de demain sera donc consacré aux différents tests de cette carte.

L’arrivée de notre carte est d’autant plus une bonne nouvelle que nous avons constaté un problème récurrent sur le gyroscope de la carte de Wheely que nous utilisions sur le testbench. En effet celui-ci a la fâcheuse tendance de ne plus rien retourner du tout parfois. Nous espérons que ce ne sera pas le cas sur notre carte.

RoseWheel : développement carte capteurs

Hier,

Cédric a terminé le banc de tests. Après quelques ajustements au niveau communication (les deux cartes n’envoyaient pas leurs données à la même vitesse) nous sommes en mesure d’afficher :

  • la valeur de l’ADC donnant la position du potentiomètre et donc l’inclinaison
  • l’angle d’inclinaison calculé à partir de l’acceleromètre
  • la vitesse angulaire donnée par le gyroscope
  • la vitesse angulaire calculée à partir des données de l’ADC

Voici un exemple de graphe affichant en rouge ADC, en bleu calcul de l’angle à partir de l’accéléromètre, en vert la mesure du gyroscope et en noir la vitesse angulaire calculée à partir de l’ADC :

La prochaine étape est donc de confronter la simulation de notre filtre de Kalman au banc de tests…

Florian a travaillé à ajuster notre filtre de Kalman pour qu’il ne tienne compte que des données que nous récupérons sur le banc de tests. En effet jusqu’ici nos simulations faisaient l’hypothèse de la présence d’encodeurs. En simulation nous éstimons connaître parfaitement notre déplacement et notre vitesse de déplacement. Le montage du Zzaag nous dira si il est possible ou non d’inclure des encodeurs dans notre version finale. Florian et João ont également travaillé à l’amélioration du simulateur et de l’asservissement LQR.

João et moi-même avons bien avancé sur les drivers. Nous avons développé ces derniers en utilisant la bibliothèque STM32F10x_StdPeriph_Driver ce qui nous permet d’avoir un peu plus de flexibilité qu’en configurant directement les registres. Nous essayons d’implémenter les drivers pour nos différents périphériques aussi indépendemment que possible du brochage. Ainsi, pour chacune de nos cartes, nous aurons juste à « instancier » nos périphériques en indiquant la patte sur laquelle ils sont branchés. Nous avons nommé cette bibliothèque libperiph et en générons une version statique (.a) que nous lierons avec les objets de nos différentes cartes. Nous disposons dores et déjà de drivers pour :

  • Adcin (tout périphérique nécessitant des conversion ADC en « single conversion »)
  • Button
  • Buzzer
  • Leds
  • Sharps (utilisation de l’ADC en « continuous conversion » et du DMA)
  • Switch

Nous allons aujourd’hui tester ces drivers sur la carte de TP et implémenter les autres :

  • CAN
  • Accéléromètre (SPI)
  • Gyroscope (I2C)
  • UART
  • Bluetooth
  • Sonar
  • Encodeurs
  • Moteurs

RoseWheel : Avancées de ce lundi

Joao et moi avons passé la journée de Lundi à chercher ce qui ne fonctionnait pas dans le modèle utilisé dans la simulation. En effet, même avec une inclinaison initiale de 5° et avec une tension de commande des moteurs à sa valeur maximale (24V) sans asservissement, le système n’arrivait pas à redresser le RoseWheel pour le ramener à sa position d’équilibre de 0° et il chutait.

Nous avons donc revu tour à tour tous les paramètres de la simulation (Voir ici un récapitulatif des paramètres que nous utilisons : parameters), que nous avons fait varier, nous avons ainsi pu observer leur influence sur l’évolution du système. Il s’est avéré que le seul paramètre critique était la constante de couple des moteurs.  A peu près tous les autres n’ayant qu’un effet sur le temps de chute. Nous avons mesuré rapidement cette constante de couple directement sur le moteur. Nous avons ainsi pu vérifier que la valeur qui était fournie dans la datasheet du moteur correspondait bien avec celle mesurée.

Il s’est finalement avéré que le problème venait des équations que nous utilisions. Nous avons repris toutes les équations et nous nous sommes rendu compte qu’il manquait un facteur 2 au niveau de celles décrivant l’effet de la commande sur les moteurs. Avec ce facteur 2 en plus, tout fonctionne parfaitement et le système est bien asservi avec une tension de commande maximale de 24V.

Nous consacrons donc cette journée de Mardi à peaufiner la simulation, notamment à choisir un set de coefficients optimum pour le LQR. De plus, jusqu’à présent nous utilisions des équations « complètes » pour le filtre de Kalman, c’est à dire que nous prenions pour hypothèse que nous avions accès à la mesure de tous les paramètres du système. Ce qui ne sera pas le cas dans la réalité. Nous allons ainsi choisir ce matin la forme définitive pour le filtre de Kalman et tester en simulation ces performances.

Cet après-midi, nous implémenterons en C cette forme du filtre de Kalman, que nous adapterons au Testbench que Drix a quasiment terminé hier et nous pourrons ainsi tester en réel le filtrage.

Clément a continué d’avancer sur l’implémentation de drivers génériques pour les deux cartes. Nous vous donnerons très bientôt plus de nouvelles à ce propos.

Copterix : simulation du filtre de Kalman

Avec Axel, nous nous sommes penchés sur le filtre de Kalman. Après de longues lectures, nous sommes arrivés à clarifier les équations mises en jeu.

Nous avons finalement décidé d’opter pour un vecteur d’état contenant les trois biais des gyroscopes ainsi qu’un quaternion déterminant l’attitude de l’hélicoptère. Nous étions initialement partis sur un vecteur d’état contenant les trois biais des gyroscopes ainsi que les deux premières colonnes de la DCM (Direct Cosine Matrix) qui elle aussi permet de déterminer l’attitude de l’hélicoptère. Ce changement nous a permis de réduire de 2 éléments notre état.

Nous avons dans un premier temps implémenté le filtre sous Matlab. Voici quelques illustrations de nos avancées :

 

 

La courbe en rouge représente l’état prédit et la courbe bleue l’état mis à jour. Nous avons choisi d’accorder plus de confiance aux valeurs estimées par le filtre qu’aux mesures. Malgré un fort bruit, le filtre se comporte plutôt bien.

Mais encore pas mal de travail reste à faire notamment au niveau de la détermination des différentes constantes mises en jeu dans le filtre ou encore au niveau du testbench.

MB Led: Journée de présentation

Dernièrement, nous avons passé beaucoup de temps à adapter la structure de notre projet en fonction de nos possibilités et idées. La préparation de la présentation de demain matin nous a donc pris pas mal de temps.
Nous avons ainsi revu l’organisation logicielle des blocs que nous posterons après validation des enseignants. Nous avons également pensé à un système d’interaction avec les blocs permettant de les utiliser comme une manette de jeu vidéo. Benjamin continue la lecture de la Datasheet du driver de LED et continue à l’implémenter. Guillaume a continué de débugger la simulation de l’algorithme que nous avons choisi. A partir de différents scénarios (arrivée progressive des modules, deux réseaux qui se rencontrent, etc.), nous avons testé le modèle d’élection de leader, d’orientation et il semblerait marcher. Le plus dur étant le retrait d’un ou de plusieurs modules, ce qui oblige à recommencer le processus d’élection de leader, … .  A présent, Guillaume va commencer à l’implémenter en C via 0MQ. Pour ma part j’ai défini la structure du module de gestion de l’IrDA afin de l’adapter à l’envoi de données de tailles importantes.

RoseWheel fait des simulations

Cet article a été rédigé hier soir…

Nous avons terminé ce week-end le PCB de notre carte capteurs. Nous avons fait le schéma de notre carte principale mais Alexis va y ajouter la partie puissance et la router pour nous.

Carte Capteurs [avant]

Carte Capteurs [arrière]

Aujourd’hui nous avons travaillé en parallèle sur l’utilisation du banc de tests et sur le simulateur qui intègre le filtre de Kalman et l’asservissement.

Le simulateur commence à fournir des résultats mais nous avons encore des problèmes de valeurs numériques. Notre simulation fait intervenir des tensions de plusieurs milliers de Volts (alors que nos moteurs n’en acceptent que 24) pour réussir à redresser le gyropode. Cela est certainement dû à une mauvaise estimation de nos constantes km (constante de couple en N.m/A) et ke (constante force contre-électromotrice en V.s/rad).

Pour les calculer nous avons récupéré les caractéristiques du moteur sur le site du distributeur :

À charge nominale on a

  • Vitesse angulaire : VA = 3751 rpm
  • Couple : T = 0.88 N.m
  • Intensité : I = 18.36 A
  • Résistance : R = 0.66 Ohm
  • Tension : U = 24.09 V

Or

  • km = T / I = 0.048 N.m / A
  • ke = (U -- R * I) / VA = 0.030 V.s / rad

Mais avec ces valeurs nous rencontrons les problèmes mentionnés plus haut. Ces problèmes viendraient-il d’ailleurs ? Alexis nous a conseillé de faire un simulateur des moteurs seuls pour déterminer vérifier nos constantes. À suivre…

Par ailleurs, comme le montre la figure suivante, le filtre de Kalman se comporte bien. Même avec un rapport signal sur bruit médiocre nous arrivons à reconstituer assez fidèlement l’angle d’inclinaison. Pour l’asservissement nous avons testé deux techniques : PID puis LQR. Le PID s’avère être délicat à régler et ne nous a pas donné de résultat satisfaisant (divergence de l’erreur au bout d’un certain temps). Le LQR se comporte beaucoup mieux et propose un réglage moins empirique. Couplé au filtre de Kalman, et problèmes de valeurs numériques exclus, notre système se comporte vraiment comme nous le souhaitons. Reste donc à vérifier si nous observons le même comportement avec les bonnes valeurs numériques pour les moteurs. Notons que pour l’instant nous incluons le déplacement et la vitesse dans nos variable d’état ce que nous ne pourrons faire que si nous arrivons à monter des encodeurs sur la mécanique du projet zzaag.

Simulateur RoseWheelCliquez sur l’image pour voir l’animation.

Concernant le banc de tests nous avons terminé sa réalisation. Nous avons monté une vidéo tournée vendredi pour le montrer en action :

Cette première version du banc de tests fonctionne ainsi :

  • on communique avec la carte de TP en RS232
  • la carte de TP commande le servo qui incline la carte capteurs du projet Wheely
  • on récupère les données des capteurs via RS232 sur l’ordinateur
  • on affiche conjointement les courbes de la commande et de la mesure

Pour les mouvements lents, nous procédons par rotations successives. La précision du servomoteur étant assez faible, cela entraîne des mouvements saccadés et introduit un bruit non négligeable lors des transitions. Par ailleurs, la calibration du banc s’avère insuffisante ce qui se traduit par un offset sur les valeurs mesurées. Nous aurions aimé présenter des courbes (superposition commande / mesure du banc de test) mais nous avons été chassés d’A405 avant d’avoir pu les exporter… No comment. Nous travaillerons demain à l’amélioration de ces résultats.

MB Led: Du hardware au software

LE PCB:

Nous avons terminé le PCB vendredi matin. Après avoir validé notre routage, Alexis nous a appris qu’il avait fait en parallèle sa propre version du PCB. Sa raison étant, non pas qu’il ne croyait pas en nous, mais que contraint par le temps il a préféré commencer un routage prenant directement en compte certaine contraintes (écartement des pistes, congestion des pistes etc.). En effet les commandes pour les PCB devaient être passé dimanche soir et cela laissé peu de temps à Alexis pour revoir les PCB de toute les équipes. Au final les différence entre nos deux PCB ne sont pas grandes (mis à part les contraintes évoquées plus haut). Nous avons même rajouté quelques composants par rapport à ceux prévus au départ, avant de finaliser le routage vendredi (merci Cédric). Alexis a donc vérifié et finalisé notre(son) PCB ce week-end avant de le placer dans notre dépot GIT.

Nouvelle perspective:

Alexis nous a aussi appris que ce seront non pas 16 mais 40 blocs qui seront commandés pour notre projet (et surement pour d’autres plus tard). Les possibilités de jeu et d’application s’en trouvent donc décuplées.

Algorithme:

Nous passons désormais au software. Guillaume continue sur sa lancée pour la simulation en python. Nous avons réfléchi à une nouvelle version pour notre algorithme, principalement pour le positionnement. Après une phase d’élection pour connaître le bloc qui sera utilisé comme référant pour connaître le nord, ce “leader” attribue aux autres blocs leur coordonnées. Il se définit en (0,0); les autres connaissent alors leur position relative par rapport au leader. Après cette phase, il est nécessaire de savoir quel est le plus grand rectangle sur lequel nous pouvons afficher quelque chose. Après une recherche d’algorithme tous très complexes, nous avons décidés d’un algorithme simple (que nous préciserons dans un prochain post). Désormais, nous cherchons un système pour acquitter tous les messages puisque nous ne sommes pas sûrs de la fiabilité de l’infrarouge.

IrDA:

Conformément à notre planning, Cédric commence à se renseigner plus en détail sur le protocole IrDA et sur l’échange de message entre les blocs. Il va dans un premier temps étudier le code de l’équipe GLiP pour comprendre leur façon de faire. A la suite de cela il établira un nouveau protocole d’échange de messages inter-bloc adapté à notre algorithme.

Driver de LED:

Pour ma part, j’ai imprimé la datasheet du nouveau driver de LED et l’ai compris à un niveau plus approfondi. Je commence maintenant à implémenter la gestion de l’affichage d’image via ce driver. Dans la précédente version chaque LED (rouge, vert bleu) pouvait varier entre 16 niveaux d’intensité. Avec ce nouveau driver, elles pourront varier sur 4096 niveaux. Les contraintes de place nous amèneront peut-être à revoir ce nombre à la baisse.
Guillaume, Cédric et Benjamin.

RoseWheel : PCB, banc de tests

Après deux jours de travail, nous avons fini les schémas de nos PCB et, à l’heure où cet article est écrit, nous parachevons le routage de la carte capteurs (autrefois appelée « carte logique »). Parmi les changements clé que nous avons faits, nous pouvons citer notamment l’inclusion d’une alimentation exclusive pour les références des convertisseurs analogique-numériques à l’intérieur du gyroscope et de l’accéléromètre – cela permet d’avoir des conversions plus fiables et donc de réduire le bruit des mesures.

Pour la carte principale (ancienne « carte de puissance »), les plans ont été un peu modifiés : finalement, le circuit de puissance, responsable du contrôle des moteurs en courant, sera intégré par Alexis à la carte, principalement à cause de problèmes d’intégrité du signal (utiliser le bus CAN en entrée permet d’être plus robuste face aux bruits induits par les moteurs à courant continu) et économiques (l’intégration élimine la nécessité de fabriquer une troisième carte qui ne ferait qu’accepter un PWM en entrée et le transmettre aux moteurs).

Côté banc de test, nous avons réussi à contrôler le servomoteur en angle avec la carte de TP, en utilisant les broches originalement assignées au bus SPI pour sortir du PWM. Nous avons commencé alors à le calibrer, puisque la position horizontale (à 0°) ne se trouve pas forcement au milieu de l’échelle du PWM ; pour faire cela, nous avons utilisé une application Android qui nous indiquait l’angle d’inclinaison du téléphone portable. Voici notre dispositif expérimental :

Après cela, nous avons  fini la partie mécanique en fixant une planche de balsa pour tenir la carte dans sa place pendant que nous faisons les tests. Le montage final est celui-ci :

Par rapport à la simulation physique, nous hésitons encore entre continuer à la développer en Octave ou passer à Matlab, étant donné que certaines bibliothèques utiles pour l’implémentation du filtre de Kalman ne sont pas disponibles dans le logiciel libre.