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.

Copterix : avancées du lundi

Samuel a fini d’implémenter les magnétomètres et accéléromètres en SPI alors que je faisais le sharp.

Ensuite, Samuel et moi-même avons fini de bricoler Kalman en C++, avant de commencer à implémenter la communication en I2c avec les gyroscopes.

L’arrivée de Samuel Tardieu avec son IMU qui renvoie des données brutes par port série a chamboulé nos plans et fera que notre journée de demain sera consacrée à des tests sur notre Kalman en conditions « réelles »…

Copterix : Gumstix

Aujourd’hui j’ai remplacé la Gumstix TIDE par la FE, ce qui a permis après quelques configurations d’avoir le Wi-Fi sur notre carte. Celle-ci crée un réseau ad-hoc qui sera très utile pour tester, quand nous aurons notre pcb, Kalman avec notre IMU et plus tard pour ajuster « au vol » les coefficients du PID dès que l’on mettra nos cartes sur l’hélicoptère.

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.

Copterix : choix des composants

Nous nous sommes fixés sur l’électronique embarquée de notre drone. Nous restons sur une gumstix. Pour l’IMU, nous aurions voulu un chip ST  LSM303DLH avec magnétomètre et accéléromètre trois axes intégrés (5,25€), mais malheureusement il est devenu indisponible récemment. Nous prendrons finalement :

  • un accéléromètre 3 axes LIS302DLH – I2C, SPI – (4,74€)
  • 3 magnétomètres (un SEN-Z et deux Sen-XY)  – SPI – (32,50€)
  • un capteur de pression MPL115A1 numérique – SPI – (10€)
  • un gyroscope 3 axes IMU-3000 – I2C , série – (24€)

On mettrait aussi :

  • une caméra e-CAM32_OMAP_GSTIX qui sera branchée sur le port dédié de la Gumstix (70€)
  • un capteur Sharp  GP2Y0D02YK0F (15,16€) pour connaître notre altitude de manière plus précise lorsque le copter sera près du sol.

Coût des composants ~ 156€.

Coût total (avec la gumstix et une estimation du coût de fabrication de la carte) : 156+219+66.30=441€.

En parallèle, Axel et Samuel sont allés au département TSI pour des conseils sur un algorithme de tracking pour la caméra et il leur a été conseillé d’utiliser une méthode de flux optique. Il y a plusieurs implémentations possibles, mais la plus simple et la moins gourmande en ressources est l’algorithme de Lucas & Kanade. Nous nous renseignons plus en détails sur l’implémentation de cet algorithme.

Ce soir, sachant que l’on aura probablement une gumstix sur hélicoptère, Samuel a regardé de quelle façon on pouvait communiquer entre un pc et la carte pour flasher celle-ci. Il y a pas mal de tutoriel expliquant la communication.

Copterix : Changements post présentation

Suite à la présentation, nous avons décidé de faire une carte d’extension pour la gumstix sans STM32 et de reporter l’ensemble des calculs (Kalman et asservissement) sur le CortexA8.

Samuel et moi avons aussi commencé à réfléchir sur l’architecture de cette carte (partie IMU). On aimerait mettre :

  • Un gyroscope 3 axes IMU-3000 (I2C)
  • Un accéléromètre 3 axes LIS302DLH (I2C, SPI)
  • 1 altimètre
  • On hésite entre un sharp (IR) et un capteur ultrason pour l’altitude par rapport au sol