Software

Je ne parlerai ici que de ma propre partie du soft, Muphins faisant l’explication de la sienne sur son site!
Je ne détaillerai pas non plus du paramétrage du micro-contrôleur (timers, PWM etc.), donc si vous voulez plus de précisions, je vous invite à poster des commentaires, je m’efforcerai d’y répondre.

Fonctionnement

Tout au long de la conception du code, j’ai fait comme si la partie résolution du labyrinthe fonctionnait. C’est à dire que mon seul but était de faire en sorte que le robot aille là où on lui disait d’aller!

Pour expliquer, le mieux est encore un bon exemple! Pour cela on va considérer un labyrinthe de 3×3 cases:

Labyrinthe exemple

Première chose: pourquoi y’a 4×4 cases? Simplement parce que la sortie est à l’extérieur du labyrinthe! :)

D’après le règlement, le robot commence forcément dans un coin. Ce qui nous permet de relativiser et donc on dira qu’il commence toujours en bas à droite (parce qu’on en a envie) et orienté au Nord (parce qu’on en a envie aussi). Cela nous permet d’initialiser les variables d’orientation et de position du robot:

Au commencement

Le [S] est la sortie (si si!), les cases connues, c’est à dire celles dont le robot connaît la position des murs, sont en vert fade.

Imaginons maintenant que le robot se trouve dans la configuration suivante:

Au bout d’un moment

La partie Head vient de calculer le chemin pour aller à la case inconnue la plus proche: [1:1]. Ce chemin est stocké dans un tableau sous la forme des coordonnées X et Y de chaque case du chemin.
Il aura donc la forme: [2:3][2:2][2:1][1:1]. Le robot sait aussi qu’il est orienté vers le Sud grâce aux déplacements qu’il a faits précédemment.

Il va donc calculer les mouvements à effectuer, les stocker à son tour dans un autre tableau, et ensuite il n’aura plus qu’à exécuter ces mouvements au fur et à mesure qu’il avancera.
J’ai défini au préalable les mouvements nécessaires au déplacement du robot comme ceci:
– Avancer d’une case [F]
– Tourner à droite [R]
– Tourner à gauche [L]
– Faire demi tour [B]
– Arrivée à la case cible [T]
Dans notre exemple, cela donne:

Mouvements calculés

Avec le robot orienté vers l’Ouest une fois arrivé.

Théorie

C’est bien beau de savoir les mouvements à faire, mais au final il faut les effectuer!
Le robot doit se placer au centre d’une case à son arrivée pour pouvoir scanner les murs correctement. C’est là que j’ai décomposé les mouvements en mouvements élémentaires:
– Avancer d’une demi case
– Tourner sur place à droite
– Tourner sur place à gauche
– Inverser la position logique des capteurs

– Avancer d’une case entière
– Tourner normalement à droite
– Tourner normalement à gauche

Dans la première partie ce sont les mouvements qui ne seront effectués qu’au début (hormis l’avance d’une demi case qui se fait également à l’arrivée dans la dernière case), pour quitter la première case. Ensuite le robot se déplace d’un bord de case à un autre, ce qui permet pour les virages de tourner avec une roue allant plus vite que l’autre, et donc d’optimiser le virage plutôt qu’un virage sur place à 90°.

Voyons voir ce que ça donne dans notre exemple:

La position du robot à la fin de chaque étape

1) Inversion de la position logique des capteurs, le robot est orienté Nord sans avoir bougé une roue!
2) Le robot avance d’une demi case, et se retrouve entre les cases [2:3] et [2:2]
3) Le robot avance d’une case entière, et se retrouve entre les cases [2:2] et [2:1]
4) Le robot tourne à gauche, et se retrouve entre les cases [2:2] et [2:1]
5) Le robot avance d’une demi case pour se centrer dans la case d’arrivée en [1;1]

Cet exemple est applicable à n’importe quelle configuration. Les mouvements étant calculés avant d’être effectués. Si dans notre cas il avait été orienté vers l’Ouest au départ, il aurait tourné sur lui même à droite, puis avancé d’une demi case et se serait retrouvé à l’étape n°2.

Pour éviter de se prendre les murs lorsqu’il avance tout droit, le robot asservit chaque moteur en fonction de la distance au mur. En réalité il suit le mur à sa droite, et dans le cas ou il n’y aurait pas de mur à droite, il s’asservit sur le mur à sa gauche.

Pratique

En pratique malheureusement, les moteurs étaient de trop mauvaise qualité, et il était impossible d’avoir une variation au moins linéaire des moteurs, ils se commandaient presque en tout ou rien.
Les solutions ont été de faire uniquement des virages sur place, et pour la correction de trajectoire, il a donc fallu rajouter des coefficient différents pour chaque moteur selon le sens dans lequel il tournait: alourdissement du code.

Il est aussi apparu que l’asservissement par rapport aux murs latéraux n’était pas suffisant. Il a fallut rajouter une correction de distance par rapport à un mur devant le robot. Ce morceau de code a été rajouté à la toute dernière minute et n’a pas très bien fonctionné…

Téléchargements

Tout le code est disponible en téléchargement via ce lien. Il est normalement suffisamment commenté, sauf les dernières parties rajoutées à la va vite.

La suite et fin ici!