Version actuelle datée du 15 avril 2011 à 15:10

Objectifs du premier semestre

Réaliser 2 robots communicants. C'est-à-dire réaliser un programme tel que :

• Les robots avancent s'ils ne rencontrent pas d'obstacle
• Un robot qui voit un obstacle s'arrête et envoie un message à l'autre robot pour que lui aussi s'arrête.

L'envoi des messages doit se faire via Bluetooth.
Les objectifs ont été atteints le 18/02 à 12h00.

Conception des robots

La conception du robot est une des difficultés rencontrées au cours de ce Bureau d’étude. Tout d’abord, il faut que nos robots puissent intégrer tous les programmes que les autres groupes réaliseront ; ainsi notre robot doit laisser place à un accès pour tous les capteurs susceptibles de s’y greffer (capteurs de couleurs, d’ultrasons, tactiles, etc.). Deuxièmement, nous devions aussi faire en sorte de facilement pouvoir atteindre le compartiment à piles pour que, lorsque l’on remplace ces dernières, le robot ne soit pas entièrement démonté. Enfin, en ce qui concerne les moteurs et la direction, 2 choix s’offrent à nous : soit on fait un robot sur chenilles, méthode simple pour faire des rotations mais qui ralentit considérablement le robot, soit on utilise 3 ou 4 roues (2 motrices et 1 ou 2 directionnelle(s)), méthode complexe au niveau de la programmation mais qui assure au robot une plus grande rapidité de mouvement. Etant donné que nous travaillons sur 2 robots, chacune des méthodes est utilisée : les chenilles sur 3PJ et les 4 roues avec une direction sur BOB.

Robot A : 3PJ

Nous avons donc débuté le projet par la conception du robot. Les 2 premières séances ont été mises à profit pour assembler 3PJ et découvrir le fonctionnement des algorithmes.

3PJ 1.0

La version initiale de 3PJ, réalisée lors de la première séance, était copiée sur le manuel de la boîte Lego. Elle a permis de comprendre l'utilisation des différents capteurs et l'avantage d'une propulsion par chenilles. Mais cette version a très vite été démontée afin de tester d'autres techniques, comme un robot à 3 roues indépendantes, qui s'est révélé totalement inapte à répondre aux ordres simples de direction.

3PJ 2.0

Version 2.0 de 3PJ

Contrairement à BOB, nous avons préféré une propulsion par chenilles plutôt que par roues indépendantes pour 3PJ. Cela simplifie le système de direction car l'utilisation de chenilles permet de diriger le robot comme un char : si le moteur droit s'arrête et le gauche continue de tourner, le robot tourne à droite et inversement. Les manoeuvres sont ainsi beaucoup plus faciles. Il restait ainsi le troisième moteur que nous avans monté verticalement et qui entraine un système d'engrenages reliés à des bras et à une pièce simulant une antenne. Ce montage nous a permis de vérifier le fonctionnement de l'algorithme de réception des messages par Bluetooth.

3PJ 2.5

Version 2.5 de 3PJ

Avec l'arrivée de nouveaux composants tels que la Foxboard avec les clés WiFi et Bluetooth, il a fallu adapter le robot. Les changements ne sont pas importants, la base restant la même. Un bac apparaît à l'arrière afin de contenir la Foxboard, et la brique NXT est relevée à 45 degrés. La partie avant est repensée afin d'équilibrer au mieux le robot. Pour des soucis d'encombrement, le troisième moteur a disparu mais reste à disposition pour une éventuelle utilisation.

Robot B : BOB

La conception de BOB a été la toute première étape du projet. Nous avons donc consacré les deux premières séances à prendre connaissance des objectifs et à réaliser un robot correspondant aux attentes, mais aussi à notre goût.

BOB 1.0

BOB 1.0

Lors de la première séance, nous avons créé le robot de « base », en suivant le plan étape par étape fourni avec la boîte du robot. Cela nous a permis de découvrir les pièces Lego™ à notre disposition, les différents capteurs, moteurs, et d’obtenir une première base.

BOB 2.0

BOB 2.0

Très vite, cette version nous a gênés car peu recherchée. Et surtout, nous voulions utiliser les roues fournies dans la boîte plutôt que les chaînes, préférant une voiture à un char. Cette idée d’utiliser les roues a entrainé un premier problème, se résumant à cette question : comment le robot va-t-il tourner ?
L’avantage des chenilles était qu’elles utilisaient un moteur de chaque côté, et permettaient au robot de pivoter sur lui-même en désynchronisant les moteurs.
Nous nous sommes alors inspiré d’un projet déjà existant : la NXT Race Car (http://www.nxtprograms.com/NXT2/race_car/index.html). Nous avons récupéré la direction de ce modèle afin de gagner du temps, puis avons adapté nos capteurs.

BOB 2.5

BOB 2.5

Le 2e semestre de BE a entraîné son lot de nouveautés, parmi lesquelles un changement de cap. Nous avons d'abord reçu une Foxboard à intégrer au robot (ainsi que sa batterie, le hub USB et les émetteurs Bluetooth/Wifi), mais aussi une nouvelle mission : réaliser la partie « suivi de ligne », non accompli par le groupe assigné.

Nous avons donc réalisé un premier programme suiveur de ligne. Le programme était simple : le robot avançait dans tous les cas. La direction restait droite lorsque le robot voyait "Rouge", avec par défaut une variable à 0 (indiquant que la direction est droite). Lorsqu'il captait du blanc, il tournait la direction vers la droite une fois et mettait la variable à 1 (pour ne pas tourner la direction à l'infini), puis la remettait à 0 en retrouvant du rouge. De même de l'autre côté, symétriquement.

Notre direction était très pratique pour suivre des courbes larges, mais après plusieurs tests en jouant sur la puissance des moteurs, nous avons compris qu'il serait impossible de suivre les virages serrés de la piste pour notre robot. L'abandon d'une direction n'était pas obligatoire : il aurait fallu soit modifier le robot pour pouvoir tourner les roues avant à plus de 45° (ce qui était impossible sur BOB 2.0), soit réaliser un programme effectuant une manoeuvre avec une marche arrière à chaque perte du centre de la ligne.

Trop fastidieux, nous avons donc décidé d'abandonner notre direction et de désynchroniser les moteurs arrières pour faire pivoter le robot. Nous avons donc "condamné" la direction, puis retiré les pneus à l'avant afin d'obtenir une sorte de roue folle (double), les roues tournant en ligne droite et pouvant glisser aisément lorsque les moteurs arrières sont désynchronisés (voir photo ci-contre).

La version 2.5 de BOB verra le capteur de couleur, initialement placé au centre du robot, déplacé à l'avant du robot afin que le capteur effectue un plus grand déplacement "latéral" lorsque le robot tourne d'un même angle.

BOB 3.0

BOB 3.0

Le changement de cap de BOB 2.5 a entraîné de nouveaux problèmes : le poids n'étant pas idéalement réparti, les roues arrières (motrices) avaient tendance à patiner lorsque le robot devait pivoter, immobilisant ainsi le robot. Celui-ci souffrait du poids de la direction inutilisée (et du 3e moteur placé à cet effet).

Nous avons donc totalement supprimé la direction, que nous avons remplacé par une simple roue sans pneu. A l'instar des roues avant de BOB 2.5, la roue avant tourne normalement quand le robot avance, et glisse lorsque le robot pivote. Nous avons choisi de ne mettre qu'une roue afin de minimiser les frottements lors des pivots (contrairement à BOB 2.5). Le robot peut donc désormais pivoter sans difficulté et ainsi suivre des lignes formant des virages, même très serrés.

Fonctionnement des programmes

Connexion maître – esclave

L'utilisation du Bluetooth sur les NXT Lego a nécessité un grand nombre de tests afin de comprendre le fonctionnement de cette connexion. La connexion et l'envoi de messages par Bluetooth entre les 2 robots doit se faire en plusieurs étapes. Tout d'abord, un des 2 robots entame la connexion, il devient le « maître ». Il se connecte sur le deuxième robot grâce à son identification, en effet chaque robot doit posséder son propre nom (les nôtres se nomment 3PJ et BOB) et le programme doit contenir le numéro du port de connexion entre 1 et 3 que va utiliser le robot maître pour se connecter. L'autre robot accepte la connexion et devient ainsi « esclave », et le robot « maître » se connecte obligatoirement sur le port 0 de l'esclave. Après la connexion, le maître peut envoyer un message de forme numérique, texte ou booléenne à l'esclave, mais ce dernier peut également envoyer un message au maître. Ainsi, il suffit qu'un seul des robots prenne l'initiative de la connexion pour que les 2 puissent dialoguer. A la fin du programme, on peut utiliser une instruction pour que l'un des robots, maître ou esclave, coupe la connexion.

Description des programmes

Programme maître

Programme du maître

Pour nos essais nous avons choisi que BOB serait le maître, mais le choix du maître et de l'esclave n'a aucun impact sur la réussite du programme.
Le maître est donc celui qui entame la connexion Bluetooth (première instruction). Le programme est ensuite composé d'une boucle (de longueur infinie ici) qui contient 2 instructions : la première est la réception d'un message par Bluetooth : si un message est reçu, le robot s'arrête, si aucun message n'est reçu, le robot avance en vérifiant par ultrasons qu'il n'y a pas d'obstacle devant lui. La deuxième instruction utilise le capteur d'ultrasons : si le robot ne capte rien, il avance, mais si un obstacle est situé devant lui il le détecte, s'arrête et envoie un message à l'autre robot.

Programme esclave

Programme de l'esclave

Le robot 3PJ est donc l'esclave. Son programme est construit de la même manière que le programme maître. La seule différence est qu'il ne démarre pas de connexion Bluetooth. De plus lorsqu'il reçoit un message provenant de l'autre robot, le moteur C démarre afin d'entrainer une action telle que rotation de bras. Ceci nous permettait lors de la phase de programmation de vérifier que le robot recevait bien le message.

Remarques pour l'élargissement du programme aux autres robots

Il faut un nom différent pour chaque robot 

En effet, il faut d'abord que les robots soient enregistrés dans un « carnet de contacts » intégré au NXT pour pouvoir se connecter entre eux. Pour cela, il faut lancer une recherche des NXT présents et choisir comme contacts ceux sur lesquels on aura besoin de se connecter. Il faut donc pour éviter toute confusion et erreur de robot un nom unique pour chaque robot, ce nom peut être changé à partir du logiciel Lego. De plus, lors de l'écriture d'un programme, si une connexion Bluetooth est nécessaire, on doit configurer le bloc « Entamer la connexion Bluetooth » en choisissant entre autres le nom du robot qui recevra la connexion.

1 robot ne peut se connecter qu'à seulement 3 autres robots 

Un NXT ne contient que 3 ports de connexion Bluetooth numérotés de 1 à 3, plus un port 0 réservé à la connexion d'un NXT maître. Un NXT peut donc être le maître de 3 NXT et l'esclave d'un autre NXT. Ceci pose un problème si l'on doit faire interagir entre eux tous les robots du bureau d'étude. Il faudra mettre en place un ordre de connexion, c'est-à-dire un maître pour 3 esclaves, et chacun de ces esclaves pourra être le maître de 3 nouveaux robots. Il suffira de programmer en conséquence, par exemple lorsqu'un robot reçoit un ordre de son maître, il devra transmettre cet ordre à ses propres esclaves.

Réflexions quant à l'utilisation de ce système

Il faut tout d'abord trouver une solution au problème du nombre de connexions autorisé pour chaque robot. Une solution pourrait être de passer par un ordinateur équipé de Bluetooth, voire, si tous les robots sont équipés de Foxboard, une transmission par WiFi entre les Foxboards (même si le sujet ne demandait que du Bluetooth), ce qui limite le risque de perte de signal à cause de la distance. Ce PC (qui peut très bien être une Foxboard embarquée sur un des robots) pourrait servir de lien entre le robot qui rencontre un obstacle et les autres : le robot bloqué envoie un signal au PC qui répète ce signal à tous les autres robots. De plus, le PC peut être le maître de tous les NXT, ce qui simplifie le programme pour les robots (plus besoin de démarrer la connexion).
On va également réfléchir à une solution de "déblocage", c'est-à-dire un algorithme qui contrôle une manoeuvre des robots. En effet, pour l'instant lorsqu'un robot rencontre un obstacle, il attend que celui-ci disparaisse pour recommencer à se déplacer et autoriser l'autre robot à faire de même. On peut écrire un programme qui propose une solution au robot qui rencontre l'obstacle, comme par exemple tourner d'un certain nombre de degrés afin de pouvoir éviter l'obstacle.
Enfin, le plus difficile sera d'assembler toutes les fonctionnalités également développées par les autres groupes pour enfin obtenir un robot performant et capable de répondre aux exigences du sujet initial, à savoir la confrontation sur une piste dans le hall de l'école.

Déroulement du deuxième semestre

Le deuxième semestre avait pour objectif la démonstration finale dans le hall de l'école. Les fonctionnalités requises sur les robots étaient un suivi de ligne rouge et bleue dans les deux sens, un programme permettant de passer en mode "recharge" et un mode "télécommande". Par manque de temps, ces objectifs ont été revus un peu à la baisse avec abandon du mode recharge.

Fonctionnalités définitives de 3PJ et BOB

Suivi de ligne

Principe du suivi de ligne

Le suivi de ligne rouge a été mis au point très rapidement, l'algorithme n'étant pas très compliqué : il s'agit d'une cascade de blocs de comparaison. Prenons l'exemple de la ligne rouge discontinue avec bordure blanche à gauche et bordure noire à droite. Si le robot capte la couleur rouge, il avance tout droit et enregistre la lettre R dans une variable. Si la couleur captée n'est pas rouge, alors :

• si elle est blanche et la variable vaut R, le robot tourne légèrement sur la droite pour retrouver le rouge
• si elle est noire et la variable vaut R, le robot tourne légèrement sur la gauche pour retrouver le rouge
• si elle n'est ni noire ni blanche, alors le robot sait qu'il capte le sol où il n'y a pas de ligne (car elle est discontinue). Il sait alors qu'il doit avancer toujours tout droit, enregistre la lettre V dans une variable (nom choisi arbitrairement car le sol était vert). Ainsi, lorsqu'il retrouve une ligne :
  • si elle est blanche et la variable vaut V, le robot tourne légèrement sur la gauche pour amorcer le virage créé par la ligne discontinue puis avance un peu pour retrouver la ligne rouge
  • si elle est noire et la variable vaut V, le robot tourne légèrement sur la droite pour amorcer le virage créé par la ligne discontinue puis avance un peu pour retrouver la ligne rouge
  • si elle est rouge, il avance tout droit et remplace la valeur de la variable par R.

Télécommande

Programme du mode télécommande

Le mode télécommande a demandé plus de travail et des échanges avec les autres groupes (un grand merci à Louis et Antoine -et leur robot Bumblebee- pour ce travail magnifique) pour parvenir à un résultat satisfaisant. Tout d'abord, il a fallu installer le système d'exploitation de la Foxboard, y enregistrer l'adresse MAC de la brique NXT afin de faire fonctionner le Bluetooth et y placer les pages Web qui servent d'interface afin de piloter le robot. Ensuite il a fallu créer le programme permettant au robot de savoir ce qu'il devait faire en recevant les différents messages. Le programme est tout d'abord composé d'un bloc "réception de message Bluetooth", puis le message reçu, qui contient une valeur numérique, est transformé en variable. Ensuite un bloc "switch" permet d'associer le message reçu avec une action :

• si le message reçu est 0, les moteurs s'arrêtent
• si le message reçu est 1, le robot avance
• si le message reçu est 2, le robot recule
• si le message reçu est 3, le robot tourne à gauche
• et enfin si le message reçu est 4, le robot tourne à droite.

Programme complet contenant toutes les fonctionnalités

Page de contrôle de la FoxBoard

Tous les programmes décrits ci-dessus fonctionnent séparément, mais le but du sujet était de les combiner en un seul programme. Notre premier travail fut d'éditer la page Web de la Foxboard afin d'y insérer un volant et des flèches de couleur. En cliquant sur le volant, on devait passer en mode télécommande, et les flèches devaient permettre de passer en mode suivi de ligne dans un sens, dans l'autre, ligne rouge, ligne bleue.
Ce programme devait contenir également le mode recharge, c'est-à-dire un mode dans lequel le robot se mettait à la recherche d'une borne afin de recharger ses batteries, et qui envoyait un message aux autres robots qui devait leur indiquer que la borne de recharge était occupée. Par manque de temps, ce mode n'a même pas été abordé.

Résultat : Semi-réussite. En effet, le mode télécommande fonctionne, ainsi que le passage d'un mode à un autre. Cependant, dans le mode suivi de ligne, le robot se contente de faire l'action associée à la première couleur qu'il capte. Ceci avait été corrigé en ajoutant une boucle autour du programme "suivi de ligne", mais de ce fait il devenait impossible de sortir de ce mode.

Difficultés rencontrées et raisons du non fonctionnement du programme complet

Limites du logiciel Lego

Trop de blocs, moins d'espace visible

Au départ, l'utilisation du logiciel livré avec la boîte NXT s'était révélée la meilleure solution, en effet ce logiciel permet d'assembler intuitivement un programme simple sous forme graphique et n'oblige pas à apprendre un langage comme le C. Cependant, le logiciel a vite montré ses limites dès que le programme devenait un peu plus complexe et contenait beaucoup d'instructions. En effet, lorsque le programme dépasse la taille donnée par l'écran, il devient difficile de retrouver tous les blocs et la navigation d'un point à un autre du programme est malaisée (les clics de souris provoquent des actions involontaires), de plus l'interface graphique alourdit l'affichage, ce qui implique un ralentissement important. De ce fait, se déplacer sur l'écran pour aller vérifier une instruction particulière devient quasiment impossible, de même que l'édition et l'ajout de nouveaux blocs qui, du fait de la lenteur de l'affichage, se positionnent n'importe où. Affin d'alléger l'affichage, nous avons dû créer nos propres blocs mais ils devenaient ensuite difficilement éditables.

Non fonctionnement du suivi de ligne

Boucle dont la sortie se fait par lecture d'une variable particulière

L'intérêt du programme contenant toutes les fonctionnalités était bien entendu qu'il ne fallait pas arrêter un programme pour en lancer un autre. Malheureusement, le nôtre plante lamentablement dans le mode suivi de ligne : le robot se contente de faire l'action associée à la première couleur qu'il capte, alors que cette partie du programme est la même que pour le programme "suivi de ligne" seul, qui fonctionne parfaitement. Nous avons testé d'ajouter une boucle autour du programme "suivi de ligne", mais de ce fait il était impossible de sortir du mode. En effet, seule une boucle infinie fonctionnait, alors que théoriquement une boucle avec sortie possible (par lecture de variable, réception de message, temps ou encore incrément) est totalement fonctionnelle. Ceci est peut-être dû à une erreur lors de la compilation au format lisible par le robot, car on utilise des blocs personnalisés plus faciles à transporter (en fait il s'agit simplement du programme "suivi de ligne" compilé en un seul bloc), mais qui rendent au final le programme très lourd, donc très long à compiler. Par manque de temps (l'heure de la démonstration devant les caméras approchait à grands pas), nous avons fini par abandonner et pour la démonstration, nous avons donc utilisé deux programmes différents.