Synchronize2011-2
Sommaire
Construction du robot
Durant les deux premières semaines, nous avons commencé par monter le robot Mindstorms en suivant la procédure du manuel. Nous l'avons ensuite personnalisé de manière à ce que le modèle fini correspondent aux objectifs du projet, c'est-à-dire en rajoutant les différents modules que sont la Foxboard, son alimentation USB, les capteurs nécessaires (dans notre cas, l'ultrason) ainsi que le HUB USB pour la connexion wifi et Bluetooth.
Installation de la Foxboard
Installation de l'alimentation USB
Installation du contrôleur NXT
Installation du HUB USB
VBRB est né !
1ère partie : Evitement synchronisé
Programmation NXT
Nous avons commencé durant la deuxième semaine à nous familiariser avec le logiciel de programmation que nous avons trouvé relativement ergonomique, tout du moins au début. Notre premier objectif a consisté au déplacement du robot avec évitement d'obstacles.
Durant la troisième semaine, nous avons modifié notre programme pour qu'il ne favorise pas une direction particulière lorsqu'il évite un obstacle. Nous avons tenté l'algorithme suivant:
compteur = 0
tant que infini
tant que distance < 20
si compteur < 6 alors
tourne à gauche de 5°
compteur = compteur + 1
sinon
compteur = 0
tourne à droite 30°
tant que distance < 20
si compteur < 6 alors
tourne à droite 5°
compteur = compteur + 1
sinon recule
fin tant que
avance
fin tant que
Malheureusement, le programme devenait de plus en plus grand mais ne fonctionnait pas pour autant. Un peu déçus, nous avons donc travaillé sur le programme que l'autre groupe avait commencé à réaliser et qui utilise une méthode un peu différente que celle que nous voulions utiliser auparavant.
Elle consiste en une analyse de la distance tous les x degrés en alternance gauche/droite jusqu'à ce que le robot ait la voie libre pour avancer. Dans le cas d'un trop grand nombre d'analyses gauche/droite (obstacle en U par exemple), le robot attend qu'il n'y ait plus d'obstacle devant lui. En comparaison, le programme de notre binôme avait l'inconvénient de favoriser davantage le côté gauche mais avait en revanche prévu une manœuvre de recul dans le cas d'un obstacle en U. Le cas idéal serait de pouvoir introduire cette manœuvre dans le programme mais le temps nous est compté...
Nous avons su par la suite d'où provenait notre erreur sur notre premier programme : Ce que nous pensions être la condition d'entrée de boucle sur le logiciel était en réalité la condition de sortie ! Bref, notre programme aurait peut-être pu fonctionner mais nous avions déjà commencé à travailler avec l'autre binôme sur la synchronisation de nos robots.
Synchronisation des robots
La mise en place de la connexion Bluetooth entre les robots nous a pris un certain temps ! Avec l'aide de l'enseignant, nous avons déjà commencé par réaliser un programme permettant de vérifier l'envoi et la réception de données entre les robots grâce à un compteur qui s'incrémente lorsqu'il y a transmission. Nous avons alors découvert comment fonctionnait réellement le Bluetooth entre les contrôleurs NXT :
- Pour qu'un robot puisse envoyer des données, il faut qu'il s'apparie à l'autre robot (et non l'inverse), ce qui fera de lui le "maître" alors que le robot récepteur devient "l’esclave". L'appariement doit être effectué sur le canal 0 pour l'esclave et sur le 1,2 ou 3 pour le maître. De plus, la réception et l'émission doivent d'effectuer sur deux boîtes aux lettres distinctes (émission boîte aux lettres 1 à partir du robot 1 et réception boîte aux lettres 2 sur le robot 2 par exemple) et de manière parallèle (et non à la suite comme nous avions commencé par faire).
Nous avons terminé la séance sur une ébauche du programme final qui permettra aux deux robots connectés d'éviter un obstacle dans un mouvement synchrone. Chaque robot effectue la même manœuvre d'évitement s'il y a obstacle devant l'un ou l'autre et pour ce faire, le robot qui est bloqué par l'obstacle envoie le nombre 1 à l'autre via Bluetooth (il devient alors maître temporairement) afin que ce dernier effectue avec lui la manœuvre. Il faudra modifier le premier programme (manœuvre d'évitement) afin qu'il s'insère correctement dans le principal.
Nous avons poursuivi les travaux avec l'autre binôme et finalement, nous nous sommes rendu compte au fil des séances que le logiciel de programmation vendu avec le robot Mindstomrs n'était pas vraiment ergonomique et que, si nous le connaissions, le langage C nous aurait peut être simplifié la tâche. Pour ce qui est du programme, nous n'avons pas encore réussi à le faire fonctionner avec l'autre binôme. En effet, chaque robot manœuvrait indépendamment de l'autre, ce qui posait des soucis de synchronisation. Le professeur nous a alors expliqué qu'il fallait plutôt "communiquer la mesure du sonar locale à l'autre robot et faire en sorte que les robots réagissent en fonction des deux mesures". C'est ce que nous avons donc fait. Notre programme se découpe en 3 parties: communication des mesures, prise de décision, et manœuvres. La prise de décision permet de choisir le coté où il faut tourner, c'est à dire du côté du robot qui est le plus loin de l'obstacle. Nous n'avions pas mis la partie communication des mesures en parallèle avec les deux autres, ce qui a posé de nouveau des problèmes de synchronisation.
Après correction, le programme fonctionnait lorsque les manœuvres consistaient à s’arrêter si l'un des deux robots captait un obstacle. Les robots "savent" maintenant qui rencontrent l'obstacle. Les prochaines séances serviront donc à améliorer les manœuvres d'évitement et à "prendre en compte la différence de comportement entre chenille et roues".
Démonstration
Nous avons enfin terminé de corriger les bugs de notre programme d'évitement synchronisé et avons donc pu réaliser les deux vidéos de démonstration ci-dessous.
Ainsi que les trois boucles du programme d'évitement synchronisé (version maître ici) :
Envoi de la distance captée à l'autre robot par Bluetooth
Réception de la distance captée par l'autre robot
Boucle de prise de décision et de mouvement
2ème partie : Intégration des fonctionnalités
Durant les deux premières séances, nous avons d'abord récupéré les programmes fonctionnels des autres binômes qui serviront à l'objectif final en modifiant bien sûr les numéros de ports et de moteurs. En l'état actuel des choses, le suivi de lignes ainsi que la télécommande (basic et total) fonctionne. Nous avons également modifier la structure du robot afin que les capteurs RFID et RGB soient centrés à l'avant du robot :
VBRB 2.0 !
Nous avons lors de l'avant-dernière séance réaliser un programme, toujours en Mindstorms (le même programme codé en C a déjà été réalisé par un autre groupe), qui envoie à la Foxboard la valeur de la boussole (si la Foxboard lui envoie 64), la couleur de ligne actuellement suivie (si la Foxboard lui envoie 66) et le tag de la dernière puce RFID rencontrée (si la Foxboard lui envoie 65).
Les boîtes aux lettre d'envoi et de réception sont respectivement la 5 et la 4. Les tests et corrections sur le programme nous ont pris temps puisque il a fallu switché entre windows, pour le logiciel Mindstorms, et linux pour vérifier que le robot réponde (et réponde correctement) à la Foxboard. Nous avons pour cela utiliser l'add-on Firebug du navigateur permettant d'accéder à la console de la page "Position" de la Foxboard et ainsi voir les échanges entre la Foxboard et le robot.
Nous avons également mis à jour sur la SD de la Foxboard le schéma du circuit final et avons ajouté au programme "conduire" la liste des positions des puces RFID sur le circuit.
Notre programme fonctionne puisque nous voyons notre robot sur le schéma du circuit à l'emplacement de la puce RFID correspondante. De plus, il s'oriente en direct grâce aux valeurs de la boussole.
En collaboration avec les autres binômes, nous avons également réaliser un programme qui couple le suiveur de ligne avec possibilité de demi-tour avec le contrôle télécommandé basique et total.
Nous avons pour finir tenter de coupler ce programme commun avec notre programme d'envoi des valeurs captées. Malheureusement cela n'a pas fonctionnait et nous n'avons pas eu le temps de pouvoir le corriger. Nous pensons par ailleurs que cela est dû à un conflit de boîte aux lettres : en effet les échanges Foxboard/robot réalisés par le programme commun (pour la télécommande et le demi-tour) sont effectués dans la même boîte que celle que nous utilisons pour la transmission des valeurs.
Nous avons terminé par la réalisation de la vidéo de démonstration. Notre robot fut capable de :
- suivre une ligne - faire demi-tour sur une ligne - être contrôlé à distance - éviter un obstacle seul ou synchronisé avec un autre robot - être détecté par la Foxboard sur le circuit (RFID et boussole)
