ELECINF344/381

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

Catégories

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 : 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 prend la route !

Aujourd’hui nous avons commencé à élaborer le planning du projet.

Un bug tracker a été rapidement mis en place (Redmine) et va nous permettre de :

  • Lister nos tâches et en garder des traces
  • Faire du suivi de bugs et d’ajout de fonctionnalité
  • Nous assigner des tâches les uns les autres
  • Générer des diagrammes de Gantt
  • Partager des fichiers non versionnés (pdf, images, …)

Nous avons pu éclaircir quelques points sur lesquels nous nous posions des questions :

- Il est nécessaire de charger le Rosewheel avec des objets ayant un poids inférieur à 90kg et dont le centre de gravité est approximativement le même que celui d’un être humain.

- Il faut utiliser à la fois un gyroscope et un accelerometre pour nous permettre de mesurer l’angle d’inclinaison du manche du RoseWheel car on a :

  • gyro : integrale(biais + theta_point) = derive linéaire + theta
  • accelero : theta + bruit

ces deux mesures sont en fait complémentaires,

  • gyro = theta + composantes basses fréquences
  • accelero = theta + composantes hautes fréquences

donc fusion des capteurs = filtrage passe-bas + filtrage passe haut.

- Peut-être utiliser en plus un Kalman pour rendre le signal issu de la fusion des capteurs d’angle encore plus propre.

-  Pour la gestion de la sécurité de RW (Arret si detection d’obstacle), nous avons pensé à utiliser un système de sonars et/ou détecteurs infrarouges (Sharps). L’idée serait d’en avoir plusieurs  à l’avant du robot : certains pointant horizontalement pour détecter des murs, d’autres pointant vers le sol pour détecter un changement de pente ou un objet au sol. Détecter un changement de pente  pourrait permettre d’adapter l’allure : si descente on ralentit, si montée on accelère. Par ailleurs on pourrait évetuellement détecter un trou et s’arreter pour ne pas tomber dedans. Nous n’avons pas encore poussé plus loin nos investigations en terme de chiffrage et de choix  de composants.

- Il faut utiliser comme processeur principal un processeur capable de traiter à la fois les calculs des différents filtres (Kalman,passe-haut et passe-bas) pour les calculs de l’angle theta, de traiter les calculs issus des capteurs de distance (Sonars, sharps), de traiter les données issus des encodeurs. De calculer les prochains nombre de tours à appliquer aux moteurs.

- Nous allons remplacer les moteurs CC d’origine par des moteurs Brushless, il sera donc nécessaire d’utiliser un processeur sur la carte de puissance afin de gérer la commande de ceux-ci.