Odométrie et NXT

Ca fait un moment que la chose me travaillait. En fait, depuis que j’ai vu sur le Web que les ports moteurs du NXT exposent directement les signaux de l’encodeur en quadrature embarqué dans les blocs moteur.

Le NXT contient le code d’asservissement (un PID classique, dont RobotC permet d’ailleurs de régler certains paramètres) des moteurs en vitesse ou en position, et l’utilise pour contrôler ceux-ci. C’est déjà un gros progrès par rapport au RCX, où tout se faisait au chrono, ou dans le meilleur des cas avec les capteurs de rotation (mais au prix de 2 entrées). Mais ce n’est pas suffisant pour faire des déplacements vraiment fiables, car on n’est pas informé des éventuels glissements et patinages.

L’idée

L’idée est donc la suivante : puisqu’on peut accéder aux signaux des encodeurs intégrés, pourquoi ne leurrerait-on pas le firmware en y substituant ceux générés par des encodeurs montés sur des roues suiveuses (ododmétriques pour utiliser un terme savant) ? En faisant cela, au lieu d’asservir sur la position ou la vitesse des moteurs, il asservirait sur la position ou la vitesse du robot.

La manip

Maintenant en possession de connecteurs RJ12 approvisionnés chez MindSensors (oui, je sais, j’aurais pu me les modifier moi-même, mais le temps c’est de l’argent, et en ce moment, j’ai moins de temps que d’argent) et de la pince à sertir du club, j’attaque deux câbles maison pour tripatouiller les signaux. Pour information, les signaux disponibles sur les ports moteurs sont les suivants :

Rien de bien compliqué :
– on laisse la liaison moteur inchangée (signaux 1 et 2)
– on alimente l’encodeur avec la masse et le 4v3 (signaux 3 et 4) (NB : il se trouve que les encodeurs utilisés pour le test sont donnés pour 5V, mais fonctionnent correctement à partir de 3V3)
– on connecte les sorties de l’encodeur aux signaux 5 et 6

Reste ensuite à monter l’encodeur sur une roue suiveuse, qu’on entrainera en la mettant en contact avec un des roues du robot (histoire de ne pas cavaler dans la pièce). Une petite photo valant mieux qu’un long discours, jetez un oeil sur ce qui suit :

On y voit (outre le bazar qui règne sur mon bureau) :
– l’encodeur monté sur un bras oscillant à l’aide d’élastiques
– la boite de connexions rapides pour accéder facilement aux divers signaux
– les deux câbles maison (en nappe grise)

Les tests

Grâce aux divers outils de RobotC, on peut manipuler directement les moteurs sans avoir besoin de programmer quoi que ce soit, ce qui est très pratique pour des tests comme celui-ci.

On y va donc en donnant une consigne de vitesse. Oula, ça ratouille. On essaye maintenant avec une consigne de position. Ca bouge un peu, puis ça oscille frénétiquement.

En fait c’est normal. Avant d’aller plus loin, il faut dire que l’encodeur utilisé est un 1024 pas (fourni à des conditions hors compétition par notre ami George. Encore merci à toi 😉). Or les encodeurs intégrés ont une résolution beaucoup moins élevée (la résolution en sortie de bloc moteur, c’est à dire après le train réducteur intégré est de 1 degré. On imagine donc que l’encodeur au niveau du moteur lui-même n’a que quelques pas (ce que confirment d’ailleurs les dessins techniques disponibles çà et là, ainsi que divers reportages photographiques d’autopsies de moteurs). Notre bête envoie trop d’impulsions telle que nous l’avons montée. Ce n’est pas grave, il suffit de démultiplier (pas de photo, mais vous imaginez facilement).

Et là, ça fonctionne très bien. Bon, le revers de la médaille, c’est qu’on se retrouve donc au final avec une résolution analogue à celle d’origine, mais il fallait s’y attendre puisque le firmware est inchangé et qu’on ne fait que le berner en lui faisant croire qu’il prend son feedback depuis l’encodeur intégré. Mais le côté agréable, c’est qu’on n’a rien fait pour obtenir ce résultat.

L’étape suivante est de monter un système odométrique complet avec deux encodeurs sur roues suiveuses, et de voir si on arrive à diriger notre robot avec précision.

Ce sera pour plus tard...