Projets d'élèves

1. Introduction

Pourquoi un "Pong à moteur ?"

J'ai choisi ce sujet car ma dernière année d'étude au gymnase s'est vue entravée par une maladie persistante, ce qui m'a conduit à choisir un projet au résultat tangible qui me semblait accessible. Cependant ils serait faux de penser que c'est un projet simpliste. En effet, ce projet peut être étoffé en utilisant la communication infrarouge des Thymio ou bien de faire un terrain mobile, ou encore en pilotant les Thymio "palettes", ainsi que bien d'autres possibilités.

Pour avoir un aperçu du résultat de mon projet : voici la vidéo de présentation

2. Matériel et méthodes

Matériel

-3 Robots "Thymio II" de l'EPFL.

-Un ordinateur avec le logiciel "Aseba Studio"

Méthode

Le projet est séparé en deux parties distinctes. Le robot-"balle" et les robots "palettes".

Programmer dans Aseba Studio

Pour des éventuelles questions quant à la programmation de base dans Aseba Studio, je vous invite à visiter le site officiel pour apprendre à programmer Thymio II. La programmation à l'aide d'états ne faisant pas partie des compétences de bases dans Aseba Studio, il me semble ici important de bien comprendre en quoi cela consiste pour appréhender le comportement des robots.

Les états

Les états sont particulièrement pratique pour avoir une lecture claire du comportement du robot et pouvoir agir sur le code en cas de problème. D'autre part, cela permet d'être sûr que le robot ne va pas faire un comportement indésirable. Les états sont littéralement des états dans lesquels le robot peut se trouver suite à telle ou telle autre action (input). Par exemple, dans un distributeur de boissons, la machine ne donnera pas la boisson choisie sauf si l'on introduit de l'argent. Elle est par défaut dans l'état "Neutre" et ne peux passer directement à l'état Fournir Boisson sans recevoir d'argent (input). L'ordre dans lequel les états s'enchaînent pour passer dans l'état Fournir Boisson n'est pas important si la machine est programmée de la même manière que dans le schéma ci-dessous. (Figure 1) Sinon la marche à suivre est spécifiée sur la machine (choix de la boisson, puis montant. Ou inversement). Ainsi si l'on insère le montant indiqué, la machine est dans l'état Argent Reçu et peut par conséquent, entrer dans l'état Fournir Boisson lorsque le consommateur fait son choix. Finalement la machine lui rend sa monnaie (s'il y en a). Par ailleurs, si entre les différents états, une trop longue période sans "input" est détectée, la machine considère que la transaction est annulée, et retourne dans son état neutre. (Et retourne toute monnaie non utilisée)

En définitive, c'est par l'addition des états choix reçu et argent reçu que la machine peut accéder à l'état fournir boisson.

Figure 1) Schéma du fonctionnement des états d'un distributeur de boissons :

Dans mon cas, les états ont été utilisés pour passer d'un état d'arrêt à un état en mouvement, puis de l'état en mouvement à l'état qui simule le rebond, etc...

Voici quelques exemple d'états que j'ai utilisé :

ETAT_ARRET

C'est l'état dans lequel le robot se trouve au démarrage ; l'état par défaut. Dans cet état, ses moteur sont à l'arrêt, et les différentes LED s'allument en blanc/bleuté.

ETAT_MARCHE

Comme l'état précédant, son nom est assez explicite. C'est l'état dans lequel le robot va avancer droit. Dans cet état, les moteurs de la roue droite et de la gauche sont à la même vitesse positive.

ETAT_REBOND(G/D/LEGER/FORT)

Ces états sont utilisés pour simuler les différents rebonds que le robot-balle peut rencontrer. Par exemple : dans l'état ETAT_MARCHE , si seulement les 2 capteurs les plus à droite sur la face avant du Thymio (Figure 2) détectent un obstacle, le robot passe dans l'état ETAT_REBOND_G, c'est à dire d'arrêter son moteur gauche et laisser son moteur droit à plein régime le temps d'une demi seconde, puis de retourner à l'état ETAT_MARCHE.

Figure 2

Exemple en situation:

Si le robot détecte un obstacle, il va l'éviter. Cependant cela serait inutile voire gênant que cela arrive dans le cas où le robot est à l'arrêt. Ainsi, nous donnons l'ordre au robot d'éviter les obstacles uniquement lorsqu'il est en mouvement.

Le robot réagit en fonction des capteurs à condition qu'il soit dans l'état ETAT_MARCHE

Ce qui permet au robot de ne pas être influencé par les obstacles durant un rebond.

La balle

Pour commencer, j'ai programmé la Balle du jeu. La balle est le robot qui va devoir "rebondir" entre les parois de la zone de jeu, et qui va se faire repousser par les "palettes" des joueurs. Pour ce faire, le robot doit pouvoir avancer et capter les obstacles (ici les murs et les palettes) pour rebondir correctement dessus. Comme vu dans l'explication des états rebonds, la façon dont le robot va rebondir va dépendre du nombre de capteurs détectant un obstacle ; Ainsi, si le Thymio va presque directement dans un mur, l'angle du rebond sera plus proche du demi-tour complet, et au contraire si seul un capteur des bords détecte un obstacle, cela veut dire que le changement de direction sera léger. D'ailleurs, pour ajouter un peu d'imprévu à la partie, plutôt que de programmer le robot de façon à ce qu'il revienne ennuyeusement quand il rencontre un obstacle de plein front, je l'ai programmé pour reculer un court instant pour ensuite tourner sur lui-même pendant une durée aléatoire. Ce qui pousse tous les joueurs à rester sur le qui-vive à tout moment.

Pour faire comprendre au robot-balle qu'un point à été marqué, j'utilise une ligne noire épaisse de 2 cm tracée avec du ruban adhésif qui est détectée à l'aide des 2 émetteurs/récepteurs infrarouge situés au-dessous du Thymio. Cette ligne à une double fonction : faire comprendre au robot-balle qu'un point est marqué, et s'assurer que les robots palettes ne puissent que se déplacer sur une zone définie.

Les palettes

Les 2 palettes sont théoriquement plus simples à programmer, car elles ne se déplacent que sur un axe ; d'avant en arrière. C'est à l'aide de nos mains que l'on va faire se déplacer le robot. Pour se faire, les capteurs 0,4,5 et 6 sont utilisés. Lorsque le Thymio capte quelque chose à l'arrière, il avance. Et inversement, lorsqu'il capte quelque chose à l'avant, il recule.

Cependant, ce n'est pas aussi simple car malheureusement, les moteurs du Thymio II sont jonchés d'aléatoire; le moteur de droite peut différer de celui de gauche, ils peuvent ne pas être correctement fixé, peuvent ne pas être bien centrés sur leurs axes de rotation., etc... Cette accumulation de problèmes conduit au fait que le robot n'avance pas parfaitement droit et qu'il faut donc compenser les défauts de direction. Pour ce faire, j'utilise du ruban adhésif noir suffisamment large pour que les 2 capteurs situés au-dessous du robot puissent le détecter. Lorsque le capteur de gauche ne perçoit plus la ligne noire, c'est que le robot est en train de se diriger trop vers la droite, ainsi, je ralentis la vitesse du moteur de gauche pour que le Thymio puisse corriger sa course.

N.B.

La fabrication d'une zone de jeu fixe ne faisait pas partie de mon projet. Ce qui amène des avantages et des inconvénients. Les principaux avantages sont que j'ai programmé les robots de la façon la plus adaptable : il est donc possible d'utiliser mes codes pour une multitude de variantes, que ce soit au niveau des différences des zones de jeu (dimensions, surfaces), ou bien aux nombres de robots (plus de 2 joueurs, plusieurs robots-balle). Cependant, cela implique qu'il n'est pas possible de jouer sur n'importe quelle surface. Au risque que le robot-balle ne détecte pas les obstacles ou que les palettes soient confuses et croient qu'elles ne sont pas en train de suivre une ligne désignée sur le sol. Bien sûr, c'est inconvénients peuvent être évités en modifiant le code pour l'adapter, mais dans sa forme brute il est possible de rencontrer des erreurs.

Malgré que je n'ai pas fabriqué de zone de jeu, à titre de référence j'utilise une table retournée typique du gymnase Provence (dimensions : Longueur : XXX cm, Largeur : XXX cm : hauteur minimale des bordures pour que les capteurs puissent les détecter : 4 cm). Je mets 2 lignes de ruban adhésif contiguës perpendiculairement à la longueur de la zone, à une dizaine de centimètres du bord. (Voir figure 3)

3. Résultats

On remarque que la partie peut avoir lieu et que l'on peut même prendre du plaisir à y jouer (en partie grâce à cette dose d'aléatoire ajoutée par rapport au jeu de Pong original). Cependant, le résultat final n'est pas exempt de défaut. Les limitations du matériel commencent déjà à apparaître : le Thymio n'est pas capable de suivre fidèlement une ligne droite en marche arrière. Une certaine dose d'aléatoire entre en compte dans les déplacements du robot. Le frottement des roues sur la surface de jeu, les roues peuvent ne pas être correctement montées sur leurs axes de rotation, la luminosité de la pièce (ce qui viendrait altérer la précision des capteurs), tous ces éléments convergent pour aboutir à une imprécision telle que la fluidité de jeu peut en être affectée. Il est en effet possible que les robots-palettes se mettent à sortir de leur zone définie ou encore que le robot-balle ne détectent pas les murs en fonction de leur surface et leur capacité de réflexion.

Les problèmes dus à la variation de la lumière, ou la capacité de réflexion des murs, peuvent être corrigés directement dans le code en changeant à partir de quelle valeur de lumière détectée le robot va interagir.

4. Discussion

Difficulté des palettes à rester sur leur axe.

En effet, en marche arrière, puisque les capteurs se situent dans la traîne du robot, faire des corrections de mouvement se trouvent être beaucoup plus ardues que celles à faire en marche avant. Il faudrait que le Thymio soit équipés des mêmes capteurs à l'opposé pour assurer une précision suffisante, et qui ouvrirait bien d'autres possibilités à notre fidèle robot.

Approfondissement du sujet.

Ce projet pourrait être approfondi en ajoutant de nouvelles dimensions au projet. Comme l'ajout d'une carte SD dans le robot pour conserver le programme et pour lui faire faire jouer des sons un plus complexes (fichiers .wav). On pourrait également utiliser la communication infrarouge des Thymio pour qu'ils puissent communiquer entre eux : par exemple lorsqu'un point est marqué, tous les robots réagissent, et l'on pourrait même faire une différence entre un rebond contre un autre robot ou contre un mur. On pourrait aussi envisager de piloter les robots-palette via une télécommande universelle adaptée.

Changements ayant eu lieu

J'avais tout d'abord prévu de faire une fine ligne de ruban adhésif. Le ruban passait entre les 2 capteurs inférieurs, mais cela demandait trop de précisions de la part du Thymio.

J'avais initialement prévu que le comportement aléatoire du robot ne se produise qu'en cas d'intervention extérieure à une partie normale. Cependant, en expérimentant, je me suis rendu compte que cette dimension aléatoire ajoutait à l'expérience de jeu et amusait beaucoup les participants.

5. Conclusion

Malgré l'apparence simpliste de ce projet, il n'est pas aussi aisé d'optimiser les codes pour arriver à un résultat tout à fait fluide et plaisant. Les limitations du Thymio se font vite sentir et nous rappellent le but initial de ce robot de l'EPFL : C'est tout d'abord un outil pédagogique destiné à familiariser les néophytes au monde de la programmation et de la robotique. C'est en trouvant par soi-même les limites du présent matériel, qu'il nous est possible de se questionner et de trouver une alternative plus adaptée à ses besoins, et pourquoi pas, de la développer soi-même.