Version du 9 mars 2011 à 20:55

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 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 finale 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 silumant une antenne. Ce montage nous a permis de vérifier le fonctionnement de l'algorithme de réception des messages par Bluetooth.

Branchements

A & B : Moteurs de propulsion
C : Moteur qui entraine l'antenne fictive
1 : Capteur photosensible
2 : Libre pour l’instant
3 : Libre pour l’instant
4 : Sonar à ultrason (placé à l’avant)

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

Version initiale de BOB

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

Version actuelle de BOB

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.

Branchements

A & B : Moteurs de propulsion (/!\ BOB avance quand les moteurs vont dans le sens « reculer »)
C : Moteur de la direction
1 : Libre pour l’instant
2 : Capteur photosensible (placé en dessous en position centrale)
3 : Libre pour l’instant
4 : Capteur à ultrason (placé à l’avant)

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îter 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'uil 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.

Projets futurs

Il faut réfléchir aux problèmes de perte du signal due à la distance ou aux conditions du milieu.
Il faut également 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.