<< The Fribotte Homepage >>
Un club de passionnés en robotique participant à la coupe de France E=M6.
[Accueil] [Qui sommes-nous ?] [Robots] [Coupe e=m6] [BD Technique] [Forum] [Reportages] [Liens] [WiKiFri]

Fribotte



Le PID sur PIC V3
L'asservissement de position


Ayant besoin, pour Cnossos, d'un asservissement de position dans la phase initiale de recherche de position dans le labyrinthe, il me fallait adapter le PID v3 pour qu'il accepte ce type de consigne, ce qui, mine de rien, change pas mal de choses et surtout toute la philosophie de l'asservissement du PID sur PIC.

A la suite de très interressantes discutions sur le forum de Planète Sciences - et je tiens à remercier ici Coco (qui a remporté le concours du post le plus long ;) Gael et les autres pour leur aide extrêmement précieuse - j'ai pu facilement adapter le PID sur PIC pour réaliser un asservissement de position de bonne qualite (enfin je pense ;)

Voici pour info la courbe d'évolution renvoyée par le PIC obtenue après un réglage rapide des coefficients du PID. En X on a le temps en ms, et en Y on a successivement le nombre de pas de l'encodeur par ms, la position de la roue en pas et l'erreur en pas par rapport à la consigne théorique. Un pas équivaut ici à 40µm d'avance du robot du côté de la roue à peu près.

Voici aussi une vidéo prise de l'asservissement de position quasiment terminée.

J'ai ensuite adapté cet asservissement de position pour en refaire un asservissement de vitesse (different néanmoins de celui du PID V2).

Malheureusement, même si l'asservissement en lui-même marche, j'ai du bidouiller pas mal de choses en particulier sur la communication qui n'était pas adaptée. Je ne pourrais pas donc fournir ce PID V3 tout de suite... je m'y mettrai après la compétition.

 


Un peu d'algo ...
Comment Cnossos trouve où il est ?

 

Ce n'est pas très compliqué. Cnossos démarre sur une case qu'il ne connaît pas. Il va d'abord trouver la distance entre lui-même et les murs haut, bas, gauche, droite avec les capteurs sharp. Ceci trouvé, il enregistre leurs positions (ou leur absence) dans des tableaux en RAM. Ensuite il avance d'une case (le règlement dit qu'il y a forcément une case libre devant le robot). A nouveau, il trouve les distances des murs et enregistre leur position en RAM.

A partir de là, il va chercher si son tableau en RAM avec les positions des murs qu'il connait correspond à une des cases des tableaux du labyrinthe qu'il a en ROM. Il cherche donc successivement toutes les possitibiltés (7*7 cases, vu que le règlement dit aussi que le robot ne peut pas démarrer d'une case adjacente à un mur extérieur) et le tout en quadruple car il cherche les 4 orientations de départ possible.

Ca peut paraître long, mais en réalité ces opérations sont des décallages de bits et des ET logiques bit à bit. Rien d'insurmontable pour un PIC donc.

Reste le cas plus compliqué où deux déplacements ne suffisent pas. Là il faut décider d'un endroit où aller (tout droit, gauche, droite, demi-tour ?) et recommencer. Un algo tout simple est prêt mais demande encore à être codé et testé !

 

Comment Cnossos trouve le plus court chemin ?

 

Cnossos utilise ici un très classique algorithme de Dijkstra (plus court chemin dans un graphe) pour calculer le plus court chemin vers la sortie (ou un point quelconque du labyrinthe). C'est un peu le fusil pour chasser les moustiques, mais ça s'adapte bien et j'ai un peu simplifé :)

On a comme résultat une liste de cases qu'il faut successivement atteindre avant d'aller sur la sortie !

 

Comment Cnossos va vers la sortie ?


Ayant sa liste de cases à atteindre, Cnossos va générer une serie de commandes à son asservissement de position (du robot, pas des moteurs !).

En fait, pour une case donnée, ça marche comme ceci :

  • le PIC maître demande au PIC esclave (celui qui traite le PID) de combien il a avancé/reculé sur la roue gauche/droite (odométrie).
  • Il en calcule la nouvelle position théorique précise du robot X, Y, angle (en cm et en flotant, ce n'est pas à la case près).
  • Il calcule, dans le repère du robot, la position du point à atteindre (changement de repère).
  • Il déduit de cette position des consignes à appliquer sur les deux moteurs. Par exemple si le point est dans une certaine "bande" tout droit, il va demander la vitesse maxium d'avance sur les deux moteurs.
  • Il donne une nouvelle consigne de vitesse au PIC esclave.
  • Il réalise aussi un calcul de recallage. Voir ci-dessous.

Ce type d'asservissement avait déjà été réalisé sur Coredump.


Comment Cnossos ne se prend pas un mur avant la fin ?

 

Bien que les odomètres soient relativement précis, on a toujours des erreurs dues aux mauvais réglages, aux glissements du robot, aux rotations qui ne se font pas nécessairement bien au centre des deux roues motrices, etc ..

Du coup, sans une correction de la position théorique du robot de temps à autre, il finit par se prendre un mur au bout de quelques mètres parcourrus.

Le plus pénible étant bien sûr toujours l'erreur angulaire, qui a tendance à faire diverger le robot de plus en plus, et de plus en plus vite.

Les essais ont quand même montré que ce n'était pas systématique. Avec une odométrie au micro-poil, il est peut-être possible de faire des miracles. Mais personne n'a envie de croire aux miracles quand il n'y a pas de second essai possible au concours :)

Du coup pas le choix, il faut repositionner le robot. Comment ? Ben pas le choix non plus, il faut utiliser la seule info qu'on ait, c'est à dire les capteurs de distance dans les quatre directions.

Pour Cnossos j'ai choisis une approche brutale et systématique. Après chaque consigne d'asservissement il lit les informations des capteurs de distance. A partir de là, il va les comparer à une distance thérorique du robot par rapport aux murs qu'il devrait voir si il était placé comme il croit l'être.

Tout ça se fait à angle quelconque entre 0 et 2Pi. Donc bonjour les calculs de trigo, et c'est certainement la partie du code la plus complexe de Cnossos, qui doit être aussi pas mal optimisée pour ne pas surcharger le PIC !

Et ce n'est pas tout, maintenant qu'il a une distance théorique par rapport au point où il croit être, il va recalculer la même chose avec un léger décalage en X ou en Y (9 cas en tout).

Il trouve ensuite le décalage qui se rapproche le plus des distances réelles qu'il a mesuré sur les capteurs.

Du coup, il applique une correction d'une fraction du décalage initial.

Facile non ?

Ca c'est pour X et Y. Mais le plus important étant l'angulaire, il faut aussi recaler l'angle ...

Les valeurs de distance directe n'étant d'à peu près aucun secours par manque de précision, j'ai utilisé une astuce. Quand le robot doit se recaler vers la gauche ou la droite, je considère que ça vient d'une erreur angulaire initiale, et je corrige légèrement l'angle dans l'autre sens, en plus de corriger la position. C'est assez simple en fait.

Cette partie est toujours en cours de test, mais c'est assez prometteur même si ça ne marche pas encore à 100% (l'erreur venant peut-être de l'imprécision des capteurs, mais ce n'est pas sûr !).

 


Les tests à la base technique de Planète Sciences
Le labyrinthe dans la base technique

 

Heureusement la base technique est grande, ce qui nous a permis avec Lionel de faire des tests sur un labyrinthe réel (toujours celui de l'an dernier - on n'a pas encore le plan définitif) pendant une permanence pour la table Coupe.

C'est quand même grand ces labyrinthes !

Et c'est aussi long de faire les 90 murs nécessaires ;)

 

La vidéo de Cnossos trouvant la sortie

 

Sur cette vidéo, Cnossos sait où il est au départ (je n'ai activé la détection de départ qu'ensuite, et elle ne marche pas encore dans tous les cas, mais promis-juré la plupart du temps ça marche). Il démarre de la case la plus loin de la sortie.

Il calcule donc tout seul le plus court chemin, et y va comme un grand.

Le recalage, aussi bien en X,Y qu'en angle est bien visible !

La vitesse max de Cnossos est ici de 60cm/s. Rappellons que le but est d'atteindre les 1m/s ! (pas gagné ça ;)

Remarquez les corrections qui font qu'à la fin le robot passe bien au milieu de la sortie !

 

Dernière photo de Cnossos

Voila à quoi il ressemble actuellement :

 

 

Ce qu'il reste à faire ...

 

Bon ben c'est pas tout ça, mais c'est pas fini !

Mécaniquement il manque l'interrupteur de départ au dessus (différent du on/off général) et la coque, et toute la déco. Les fils devant font désordre, mais je vois pas trop comment m'en débarasser ...

De roues plus droites amélioreraient aussi l'odométrie ;)

En tous cas merci a Gilles pour cette version des roues, qui sont certes un poil de traviolle (pas évident sans tour ...) mais qui sont tout de même bien utile ! :)

Electroniquement ... heu non, normalement il n'y a rien à faire ! (si rien ne grille bien sûr ;)

Logiciellement : Encore pas mal de boulot ... mais c'est surtout du réglage et remettre des bouts ensemble.

  • Gérer les cas de départ qui restent
  • Gérer le tir de la balle ! (aller près du centre, se positionner correctement, tirer, repartir)
  • Essayer d'améliorer l'asservissement de position pour couper plus le virage
  • Essayer d'augmenter la vitesse
  • Essayer d'améliorer le recalage.

Plus que deux semaines ...

++ :)

Julien - pour les Fribottes

 


Complétez cette page, posez vos questions et remarques ici : WiKiFri

Page http://fribotte.free.fr/bdtech/cnossos/robot_cnossos2.html modifiée le 13/09/2004.
Copyright fribotte@free.fr, libre de droit pour toute utilisation non commerciale.
Reproduction autorisée par simple mail