ELECINF344/381

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

Catégories

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

Rosewheel restructure son planning

Aujourd’hui nous avons pris le temps de réétudier un peu notre planning. Les travaux pratiques de l’UE ont, pour les premières semaines, un peu empiété sur le temps que nous voulions consacrer au projet et quelques modifications s’imposent. Nous pensons néanmoins être toujours dans les temps par rapport à nos objectifs finaux. Notre planning prévisionnel était :

  1. Étude : Kalman, composants, banc de test
  2. Conception PCB : logique, capteurs
  3. Contrôle en vitesse non asservi
  4. Fusion de capteurs & asservissement
  5. Tenir debout, tourner, s’arrêter
  6. Détection d’obstacles
  7. Conception & implémentation contrôle brushless
  8. Conception de l’application Android & video
  9. Soutenance finale

L’étude du filtre de Kalman en première semaine a été concluante. Nous disposons de tous les éléments théoriques pour concevoir le filtre optimal pour notre application. Afin d’assurer un bon équilibre entre robustesse du filtre et complexité des calculs, différentes approches, complémentaires, sont mises en place. Tout d’abord, afin d’assurer la robustesse du filtre aux erreurs numériques susceptibles de se produire du fait de l’utilisation de calculs en virgule fixe, nous comptons utiliser l’algorithme du square root filtering. Ensuite, nous séparerons bien les capteurs entrant dans l’équation d’évolution du système et les capteurs n’ayant un rôle que de « mesure », ceci afin d’alléger la taille des matrices utilisées dans le filtre. Enfin, nous nous placerons dans la situation, fictive, où RoseWheel est toujours immobile. Le mouvement de ce dernier sera vu comme un bruit que nous intégrerons dans les équations et qui, si le choix des différents paramètres est judicieux, nous permettra là aussi d’obtenir des résultats satisfaisant tout en garantissant la simplicité des calculs.

Une étude plus approfondie de la dynamique du système nous a également permis de définir plus précisément nos différentes unités de traitement : filtre Kalman pour supprimer le bruit des capteurs, LQR pour asservissement en inclinaison, LQR pour asservissement en vitesse des moteurs brushless. Il nous manque toujours certaines informations pour pouvoir établir des modèles notamment des informations sur les divers éléments mécaniques et les capteurs. Nous n’avons pas encore finalisé le choix des capteurs et autres composants que nous allons utiliser. Nous avons collecté suffisamment d’informations sur ces derniers mais nous devons maintenant trancher en fonction de plusieurs contraintes : coût, précision, bruit de mesure, disponibilité, délais de livraison, possibilités de collaboration… Par exemple, nous pourrions partager les efforts avec Copterix pour les accéléromètre (MMA7660FCR1), gyroscope (IMU-3000) et capteur sharp (GP2Y0D02YK0F) de façon à factoriser les développements. Mais nous pourrions aussi utiliser des composants plus appropriés comme ce qui a été proposé à la soutenance initiale (nous n’avons par exemple pas besoin de 3 axes pour le gyroscope). Nous allons affiner notre sélection durant les prochains jours pour converger vers un choix final au plus tard samedi prochain (justifications à l’appui) de façon à pouvoir finir les PCB logique et capteurs pour dimanche soir comme prévu..

La première semaine devait également faire l’objet d’une étude sur la réalisabilité d’un banc de tests pour nos capteurs. Suite à plusieurs fausses pistes nous avons finalement trouvé où nous procurer des servos et du bois/plexi. L’implémentation, assez triviale, a bien avancé. La réalisation du banc de test reste tout de même moins prioritaire que l’avancée sur les capteurs et le filtre de Kalman : il est inutile de tester quelque chose que l’on a pas encore conçu. Nous avons donc décidé de reporter la semaine 3, soit la semaine prochaine. Nous devrions avoir un prototype viable en fin de semaine.

Enfin nous avons pris un peu de temps pour développer un simulateur simple de la physique de notre système (pour l’instant tel que décrit dans la thèse de Rich Chi Ooi) à l’aide d’Octave. Cela nous permettra de faire des premiers tests sur le filtre de Kalman et le (les) LQR assez rapidement.

RoseWheel : banc de tests et filtre de Kalman

Depuis ce week-end, nous avons avancé dans le projet sur deux fronts : d’un côté le banc de tests, de l’autre le filtre de Kalman.

En ce qui concerne le banc de tests, nous avons commencé à concevoir la partie logicielle du système. Clément et moi avons attaqué la partie « haut niveau », c’est-à-dire, les fonctions qui vont gérer la réalisation des tests et le calcul des statistiques d’intérêt ; en quelques lignes de Python (langage que Cédric et moi avons commencé à découvrir ce week-end), nous avons réussi à faire un script qui génère une série de valeurs de test aléatoires, simule les mesures correspondantes et calcule la moyenne et la variance de l’erreur. En y ajoutant encore quelques lignes, et à l’aide de matplotlib, Clément a réussi à afficher dynamiquement les résultats avec une belle interface graphique, dont voici un aperçu :

Écran du script du banc de tests. Les deux premières figures représentent les angles « thêta » et « phi », et la dernière, la vitesse angulaire dans l'axe des « thêta ». Les valeurs d'entrée sont dessinées en bleu, et les mesures simulées, en vert

En parallèle, Cédric a commencé à écrire, également en Python, une petite bibliothèque pour contrôler des servo-moteurs AX-12 (merci Samuel pour la recommandation) à travers le port série. Les prochains pas seront d’intégrer ce code dans l’application principale et implémenter des fonctions pour lire les valeurs des capteurs.

Sur l’autre front, Florian a beaucoup travaillé pour comprendre+implémenter le filtre de Kalman et pouvoir l’expliquer aux autres. Cependant, nous recherchons encore la meilleure manière d’intégrer à ce dispositif le filtre complémentaire (passe-bas pour l’accéléromètre + passe-haut pour le gyroscope).

En outre, nous avons réfléchi davantage sur le choix des capteurs, mais pour le gyroscope nous hésitons encore entre prendre l’IMU-3000 (3 axes) ou le MLX90609 (notre premier choix, avec un seul axe). La performance du projet « robot de equilibrio », qui utilise cette dernière puce, nous a beaucoup impressionné, et le fait que son drift soit faible (selon la datasheet) est assez intéressant ; pourtant, avoir un axe supplémentaire pourrait être utile pour l’asservissement dans les courbes, et permettrait le partage d’une intégration plus grande du travail avec Copterix.

Finalement, comme toute production électronique est censée être versionnée, nous avons tous eu droit à une vraie leçon pratique de Clément pour utiliser Git. En nous apprenant à sauvegarder nos avancées temporaires sur notre dépôt de projet, il a pu aussi préparer sa stratégie pédagogique pour la présentation de vendredi.

RoseWheel : réorganisations

Nous avons tiré des enseignements de notre présentation de ce matin. Particulièrement pour l’organisation générale du projet. Ainsi nous avons choisi de nous focaliser en priorité sur l’objectif majeur du projet RoseWheel : réussir à le faire tenir en équilibre sur ses 2 roues. L’asservissement que nous allons mettre en place sur les moteurs doit nous permettre au plus vite d’atteindre cet objectif. Pour ce faire nous avons remanié notre planning.

L’utilisation de moteurs brushless est une amélioration fondamentale mais peut être faite a posteriori. Au lieu de commencer par celà nous pouvons commencer par utiliser les moteurs à courant continu. Fournis avec une carte de puissance, ils nous permettront de tester rapidement notre asservissement. Le contrôle des moteurs brushless pourra être fait par la suite.

Mais avant cela l’asservissement doit fonctionner. La fusion de capteurs et la mise en place d’un filtre de Kalman doivent être au centre de nos préocupations. Nous avons réalisé à la soutenance que l’équipe Copterix traîterait de problématiques similaires. Nous allons donc essayer de coopérer avec eux. Il est possible que, pour joindre nos efforts, nous devions passer à un gyroscope 3 axes (et non le mono-axe de la présentation).

La semaine prochaine nous allons devoir développer des modèles de nos filtres sur Octave mais aussi de fabriquer un banc de tests pour vérifier que l’information filtrée est valide. Une carte développée par nos prédécesseurs/amis et comportant des capteurs similaires nous permettra de tester nos filtres avant de concevoir les cartes. Pour cela il faudra utiliser un/des servo-moteurs pour commander l’inclinaison d’une planche et vérifier que la sortie correspond bien à la commande que nous allons envoyer.