ELECINF344/381

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

Catégories

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 : le retour !

Après une semaine bien dense pendant laquelle certains ont pu travailler sur Kalman et d’autres sur LQR, nous avons aussi avancé dans notre recherche de composants mais il reste encore quelques incertitudes.
Sachant que nous allons partager nos efforts avec Copterix pour les tests des gyroscope et accéléromètre, nous allons prendre les mêmes qu’eux.
Un bon schéma vaut toujours mieux qu’un long discours, voilà donc l’architecture de notre système :
Schéma RoseWheel-AndroWheel

Architecture du projet

 

Pour télécommander notre RoseWheel Nous utiliseront probablement le bluetooth puisque c’est sur tous les téléphones. Nous avous estimé que du bluetooth 2.0 (~1.4MB/s) class2 (portée ~10m) devrait largement suffire pour une première version. De plus, nous aimerions vraiment implémenter un retour vidéo mais ça va dépendre du temps qu’il nous reste.

Si le temps se fait rare, nous pourrions envoyer la vidéo au téléphone sous android grâce à une « caméra wifi » de ce genre :

http://www.bewan.fr/entreprise.php?page=entreprise&parm1=presse&parm2=communique&id=47

=> Nous l’avons trouvé à 56€ ici :

www.cdiscount.com/informatique/materiel-reseau-wifi-internet-bluetooth/bewan-icam-100n-bwbc-100n/f-10715290802-bwbc100n.html

Si nous n’arrivons pas à connecter la caméra directement au téléphone, cette solution impliquerait de passer par un routeur, de streamer la vidéo sur un serveur et de s’y connecter avec l’android.
Si cette solution ne marche pas non plus, nous pensons utiliser une beaglebord ou une gumstix pour y brancher une caméra et envoyer la vidéo au téléphone sous android.

Nous avons plusieur solutions :

- par bluetooth 3.0 (24Mb/s) avec un dongle usb pour une vingtaine d’euros en plus (Nous pourrons utiliser le samsung galaxy S qui  a le bluetooth 3.0 mais sinon c’est rare)

- par wifi, plus démocratisé, mais c’est plus compliqué à utiliser.

La beaglebord a l’avantage d’embarquer un DSP et du wifi mais même si c’est moins cher, c’est bien plus gros qu’une gumstix.

Nous verrons plus tard les codecs de compression vidéo utilisables mais à priori ça suffit largement. Nous devrons donc faire tourner un petit linux dessus ce qui fera grand plaisir à certain d’entre nous ;)

Nous avons également étudié plus en détail la physique du système.
La thèse de Rich Chi Ooi présente un modèle physique assez complet décrivant un gyropode comme une combinaison de trois sous-systèmes : les moteurs, les roues et le chassis.
Nous avons donc refait les calculs pour être surs de les avoir compris et pour éclaircir les points sur lesquels l’auteur passe rapidement.
Par ailleurs ce dernier donne une modélisation intéressante des moteurs à courant continu mais le principe physique des moteurs brushless étant différant, nous devrons peut être réfléchir à un modèle plus approprié.
La modélisation de notre système sous la forme x’= Ax + Bu nous permettra prochainement de mettre en application le cours sur le LQR donné vendredi par nos collègues.

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.