ELECINF344/381

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

Catégories

RoseWheel : à pleine vitesse

Voici un compte rendu des avancées que nous avons fait pour la démonstration de vendredi et pendant le weekend :

Carte capteurs

Côté accéléromètre, nous avons réussi à communiquer proprement avec accéléromètre en utilisant une interruption externe liée au signal RDY ; cela nous a permis plusieurs démonstrations intéressantes : contrôle d’une LED suivant l’angle, envoi des valeurs mesurées par le port série, affichage de l’angle mesurée avec Matlab.

Pour le gyroscope, nous avons eu plus de difficultés, notamment pour bien gérer l’implémentation du protocole I2C dans le STM32. Après quelques heures de debug, nous sommes arrivés à une implémentation minimale du driver pour la démonstration, les données lues étant transmises par le port série et affichées dans le même graphique que celles en provenance de l’accéléromètre ; cependant, le capteur parfois s’arrêtait sans explication.

Dans un premier temps, nous avions attribué ce problème à des micro-coupures d’alimentation. Néanmoins, nous ne sommes toujours pas satisfaits de cette explication, puisque une telle fragilité n’est pas désirable pour une partie si vitale de notre projet ; alors, nous avons travaillé sur le code pendant le weekend pour essayer de trouver la source des instabilités, mais nous n’avons pas encore trouvé la réponse. À suivre donc…

Filtre de Kalman

Nous avons implémenté en C notre filtre de Kalman dans la journée du vendredi. Afin de procéder aux tests « définitifs », nous attendons d’avoir des drivers plus fiables pour le gyroscope et la partie mécanique monté, étant donné qu’il est indispensable de tester le filtre dans les conditions prévues sur le système pour lequel il a été conçu.

Entre-temps, nous envisageons d’utiliser une version un peu modifié qui ne traquerait que la dérive du gyroscope sur notre banc de test. Pendant la démonstration, nous avons montré nos performances en simulation, dont nous avions parlé dans notre dernier post.

Banc de test

Nous avons également montré au jury le fonctionnement de notre banc de test, notamment le graphique de variation d’angle et de vitesse angulaire, que nous avons détaillé dans des posts précédents.

CAN

Nous avons aussi avancé sur le bus CAN, et nous pensons à le tester demain avec les drivers que nous avons écrit ce week-end.

Moteurs

Nous commençons à implémenter les des moteurs et l’utilisation de PWM pour contrôler les ponts en H.
Sur notre PCB, nous utilisons des « pilotes de demi ponts en H » (IRS2184SPBF) qui permettent (entre autres) d’éviter les court circuits.
Dans le schéma suivant, ces composants se brancheraient à droite et à gauche de façon à ne jamais avoir A et B à la même valeur :


Pour pouvoir changer le sens de rotation, on pense utiliser la broche enable disponible sur le « pilote » (IRS2184SPBF).
Le chronogramme suivant illustre ce que l’on croit nécessaire au moment de la transition d’un sens de rotation à l’autre :

 

De façon à éviter d’entendre le signal de contrôle, on pense utiliser une fréquence de l’ordre de 20KHz mais on ne sait pas encore si cela ne sera pas trop élevé pour « limiter les pertes lors de la commutation des transistors du pont en H ».
Un certain nombre d’incertitudes persistent donc toute suggestion serait la bienvenue !

Planning pour la semaine – « micro-tâches »

Envisageant pouvoir asservir correctement le segway avant dimanche prochain, nous nous sommes attribués les « micro-tâches » suivantes pour la suite :

Drivers carte capteurs

- I2C / Gyroscope -> João 12/04
- SPI / Accéléromètre -> Clément 11/04

Drivers carte principale

- Drivers Ponts en H -> Cédric 13/04
- Contrôle moteurs -> Cédric 14/04
- Drivers CAN -> Florian 11/04
- Tests Drivers CAN -> Florian 11/04
- Protocole CAN -> João 13/04
- Tests protocole CAN -> João 14/04
- Drivers encodeurs -> Clément 14/04

Tests filtre de Kalman

- Intégration filtre TestBench -> Florian 13/04
- Réglage filtre -> Florian 17/04

Intégration logicielle carte capteurs

- Implémentation asservissement en C -> Clément 12/04
- Réglage de l’asservissement -> Clément 17/04
- Réglage direction -> João 17/04

Divers

- Montage RoseWheel -> Cédric 12/04
- Montage encodeurs RoseWheel -> Cédric 13/04

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.

RoseWheel : Test bench & Kalman

Aujourd’hui nous avons continué l’amélioration de notre test bench d’un coté et recommencé la modélisation physique de l’autre.

 

Le document de Rich Chi Ooi a été complètement abandonné, il y aurait apparemment des erreurs de calcul (au moins intermédiaire) et son implémentation complexe n’était vraiment pas pratique.

Les équations de BoRam seraient de loin bien plus simple à implémenter et les résultats sont beaucoup plus satisfaisants.

Il reste néanmoins un facteur 4 dans le sens où on obtient des commandes en tension au dessous de 100V au lieu de 24V (alors qu’on avait une erreur de l’ordre de 10 000V avec Rich Chi Ooi).

 

Les améliorations sur le test bench sont moins conséquentes puisqu’il ne s’agissait que d’optimisations.

Tout d’abord avons rendu le test asynchrone de façon à pouvoir changer d’inclinaison cible en cours de route sans avoir à attendre la fin de l’exécution d’une commande (ce qui peut être long si la vitesse demandée est faible). Pour ce faire, nous utilisons des queues que nous remplissons d’objets composés de commandes angulaire et de leur délai associé pour aller à la vitesse demandée.

Enfin, nous avons doublé la précision de calibration de la commande du moteur en mesurant de nombreuses fois chaque PWM associé à un angle et ce tous les 10°.

A l’origine, nous utilisions un tableau de valeurs à interpoler pour calculer les PWM à mettre dans le registre TIM1->CCR3 :

const static uint16_t PWM_list[] =
{
59840, 60130, 60400, 60700, 61010, 61310 // -60° -> -10
61580, // 0°
61900, 62190, 62500, 62780, 63050, 63430, // +10° -> +60°
};

Cette mesure expérimentale présentait une irrégularité non négligeable mais en considérant la linéarité du moteur nous avons fait une régression linéaire pour diminuer l’imprécision.

Voici l’approximation graphique obtenue avec open office (courbe de tendance) :

 

On peut voir en haut à gauche de l’image la fonction à utiliser dans notre code C.

Et pour finir, pour interpréter les données obtenues par l’ADC de façon à connaitre plus précisément notre inclinaison nous avions un tableau similaire :

const static uint16_t ADC_list[] =
{
663, 845, 1018, 1169, 1324, 1485, // -60° -> -10
1644, // 0°
1764, 1975, 2127, 2284, 2455, 2611, // +10° -> +60°
};

…et voici l’approximation graphique ainsi que la fonction linéaire associée que nous en avons extrait :

 

On peut voir que R², le coefficient de détermination, est très proche de 1 dans les 2 cas, donc notre linéarisation peut être considérée comme fiable.

RoseWheel : Simulation filtre de Kalman

Aujourd’hui, et depuis le début de la semaine nous avons travaillé à simuler notre système sur Matlab. Voici les premiers résultats :

Simulation

Nous avons tout d’abord repris les équations de mouvement de Rich Chi Ooi afin de les adapter à notre système, les équations étant en fait sensiblement les même, seuls les paramètres changaient. Nous avons cependant eu quelques soucis pour en déterminer certains :

  • Le moment d’inertie du corps humain. Aussi étonnant que cela puisse paraitre, il nous a été très difficile de trouver un papier sur le net dans lequel sont  mesurés avec précision le moment d’inertie du corps humain ainsi que la position de son centre de gravité. Nous sommes finalement tombés sur un document déclassifié de la défense américaine, publié en 1963, avec des données qui nous semblent fiables. Pour les gens intéressés, c’est ici !
  • La détermination de la constante de couple ainsi que la BEMF (Back ElectroMotive Force) ne devait plus poser de soucis après les éclaircissements d’Alexis sur ce sujet. Mais d’après nos calculs, on trouve seulement 0.06 N.M/A pour la constante de couple qui est égale à la BEMF. Cette valeur nous semble un peu faible dans la mesure ou lors de la modélisation de notre modèle, lorsqu’on applique la tension de commande de 24V aux moteurs avec ces paramètres et alors que le RoseWheel est en train de tomber (donc que l’angle entre le manche et la verticale augmente), cela ne rectifie pas du tout l’angle. Nous avons attribué cela au fait que vu la valeur de la constante de couple, le couple généré par le moteur, même à pleine puissance, n’était pas capable de redresser le manche.

Filtrage de Kalman

Afin de nous familiariser un peu plus avec le filtrage de Kalman et pouvoir déterminer notamment quelle répartition choisir entre les capteurs participant à l’évolution du système et ceux servant vraiment de mesure, nous avons ajouté aux équations d’état de notre système du bruit blanc centré dont nous connaissions la variance et nous avons implémenté un filtrage de Kalman afin de pouvoir faire varier les différents paramètres et voir comment le filtre réagissait.

Pour le moment le filtre est assez basique dans la mesure ou aucune optimisation n’est apportée. Il utilise un vecteur d’état comportant 4 termes : x, x_dot, theta, theta_dot et un vecteur de mesure comportant lui aussi les 4 termes mesurés x_m, x_dot_m, theta_m, theta_dot_m. Ce qui nous oblige, notamment à travailler avec des matrices 4 *4. Voilà un petit printscreen :

Ce graphique représente l’évolution de l’angle du manche du RoseWheel par rapport à la verticale et soumis à un petit angle initial. Dans ce cas de figure, le Rosewheel n’est pas asservi. Il tombe donc de plus en plus rapidement vers le sol jusqu’à atteindre un angle de pi/2

dt est le pas d’échantillonnage.

On voit ici que l’on  a choisi d’accorder plus de confiance à la valeur estimé par le filtre de Kalman (W représentant la variance du bruit de processus et V représentant la variance du bruit de mesure) par rapport à la valeur mesurée. Ce qui se traduit par W < V.

Perspectives

Il faut maintenant définir le modèle définitif du filtre de Kalman qui sera implémenté dans le RoseWheel, celui ci devra

  • Tenir compte du biais du gyroscope en l’incluant comme variable d’état.
  • Dans un souci de simplicité et de facilité de calcul, utiliser des équations d’état pour lesquelles, le RoseWheel est toujours immobile. Afin de tenir compte du fait qu’en vérité il ne l’est pas, on augmentera le bruit de processus afin de signifier au filtre de Kalman que le modèle utilisé est faux et qu’il doit accorder plus d’importance aux mesures. D’où la nécessité de bénéficier de mesures fiables.
  • Faire la juste répartition entre les mesures participant à l’évolution du système et celles utilisées en tant que « vraies » mesures.  A priori, seule la mesure provenant de l’accéléromètre tiendra lieu de « vraie » mesure.
  • Faire le choix d’une implémentation alternative, ou non, de Kalman, nécessitant un peu plus de calculs mais plus robustes aux erreurs de calcul en virgule fixe.

 

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.

tsv safe express: module ethernet

Pour le driver ethernet, nous avions l'idée d'utiliser un Trans-receiver au lieu du controlleur Phy.
Pour cela, nous avons trouvé ce site (open source): STE101P.

En effet, nous avons trouvé  (le site a été donné dans la page Tp) une implémentation de STM32107P avec Ethernet.

Sinon, on pense à transformer l'intensité de courant qui parcourt les Leds en tension mesurable
par le microcontrolleur, à travers un transisteur.

[RoseWheel] Implémentation du filtre de Kalman

Après de nombreuses hésitations quant à l’implémentation exacte du filtre qui nous permettra de traiter les données issues des capteurs de position (drift du gyroscope notamment) nous nous dirigeons de plus en plus vers l’association entre un filtre complémentaire (présenté dans un post un peu plus bas) et un filtre de Kalman permettant d’estimer le drift du gyroscope à chaque instant.

L’implémentation du filtre de Kalman est en fait assez simple. Voilà les données du problèmes :

On mesure à chaque instant la vitesse angulaire (theta_dot)  et l’angle d’inclinaison du manche de RoseWheel par rapport à la verticale (theta).

On considère que la mesure theta_m de  l’angle d’inclinaison est entachée d’un bruit blanc gaussien centré v(t).

On considère de plus que la mesure de la vitesse angulaire theta_dot_m est biaisée par un signal b(t) susceptible d’évoluer dans le temps (le drift).

A partir de ces 2 mesures theta_m et theta_dot_m on construit un filtre de Kalman permettant d’estimer le biais b(t). On pourra alors facilement corriger les valeurs en fonctions de l’estimation de ce biais.

Comme il n’est pas possible de modéliser la façon dont évolue le drift b(t) car celle-ci dépend de beaucoup de paramètres différents. On va considérer pour l’implémentation du Kalman que ce biais b(t) est constant. Mais ce qui nous donne en régime permanent un gain de Kalman nul car l’équation n’est pas bruitée. Ainsi, une fois le biais constant estimé, le filtre ne sera plus capable de détecter la dérive de ce biais. Ce qui est problématique.

Cependant on va ajouter à l’équation d’état un bruit fictif w(t) plus ou moins important qui va permettre de signaler au filtre de Kalman qu’il faut qu’il accorde à chaque itération plus de confiance dans les mesures et moins de confiance dans la modélisation, celle-ci étant incorrecte dans la mesure ou on a considéré un drift constant.

On obtient ainsi une estimation du biais b(t) du gyroscope qu’il est ensuite facile de soustraire au signal theta_dot_m mesuré par celui-ci.

C’est en particulier le filtre qui a été utilisé par Rich Chi Ooi dans sa thèse : Balancing of a Two-Wheeled Autonomous Robot

Des simulations Matlab/Octave sont à venir.

Sur un autre front, Clément à quant à lui commencé à regarder la théorie des algorithmes LQR mais nous attendons la présentation de vendredi pour nous y pencher de plus près.

Kalman, encore du Kalman…

Aujourd’hui, avec Axel, nous nous sommes enfin penchés sur la théorie du filtre de Kalman. Ce qui était une bonne idée, puisque nous y voyons déjà beaucoup plus clair sur le fonctionnement théorique de celui-ci. Il n’empêche que beaucoup d’imprécisions restent encore à lever. Pour implémenter le filtre de Kalman, il faut être capable d’exprimer l’état prédit du système à l’instant k en fonction de l’état du système à l’instant k-1. Pour ce faire, il faudrait tenir compte de l’équation d’état du système (et donc considérer le système dans son ensemble, donc réfléchir d’ores et déjà à la physique du système, avec les hélices).

C’est un point que nous avons du mal à comprendre concernant le filtre de Kalman : dès lors que nous tenons compte de la physique du système, comment peut-on tester la centrale inertielle seule, non intégrée au système final? Pourtant, celle que nous avons déjà pu tester nous-mêmes semblait fonctionner plus ou moins correctement, seule.

 

Il nous reste également à déterminer ce qu’on veut filtrer exactement, si c’est tout le système, ou bien uniquement les gyroscopes. Et encore si on utilise un modèle physique réaliste et donc non linéaire, ou bien si on utilise des astuces pour le rendre linéaire, par exemple en introduisant les mesures et erreurs de mesure dans le résultat (solution proposée par Florian, mais qui reste encore un peu obscure pour moi).

Bref, nous avons avancé sur la compréhension de la théorie, maintenant nous nous heurtons au problème des hypothèses et de l’implémentation. Demain nous devrions essayer de préciser les équations physiques pour voir si nous arrivons à trouver une manière d’exprimer correctement l’algorithme.