Synchronize2011-2 : Différence entre versions

Version du 9 avril 2012 à 11:07

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 connection wifi et bluetooth.

• 

  Installation de la Foxboard

• 

  Installation de l'alimentation USB

• 

  Installation du contrôleur NXT

• 

  Installation du HUB USB

• 

  VBRB est né !

• 

Programmation NXT

Du point de vue logiciel, nous avons commencé durant la deuxième semaine à nous familiariser avec l'environnement NXT que nous avons trouvé relativement ergonomique. Notre premier objectif a consisté au déplacement du robot avec évitement d'obstacles.

Durant la troisième semaine, nous avons tenté de perfectionner 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 prenait une taille de plus en plus importante mais ne fonctionnait toujours pas. Un peu déçus, nous avons donc travaillé sur le programme que l'autre groupe avait réalisé et qui utilise une méthode un peu différente que celle que nous voulions programmer.

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 que l'obstacle parte. 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 programmeur NXT é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.

Petit détail : Nous avons également appris que les autres capteurs (RFID, RGB...) serviront pour la seconde partie du BE qui consistera à rassembler nos différents projets sur une seule machine. Nous ajusterons alors le moment venu notre robot afin qu'il puisse accueillir ces nouveaux éléments.

Synchronisation des robots

Nous voilà déjà à la septième séance ! 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 se fera obligatoirement sur le canal 0 pour l'esclave et sur le 1,2 ou 3 pour le maître. Il faudra également prendre en considération le fait que la réception et l'émission s'effectuent à chaque fois 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). De plus, il est nécessaire que l'émission et la réception s'effectue en parallèle et non à la suite comme nous avions commencé à 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. Pour ce faire, il faut que chaque robot effectue la même manœuvre d'évitement s'il y a obstacle devant l'un ou l'autre : dans ce cas, le robot qui a l'obstacle envoie le nombre 1 à l'autre via Bluetooth (il devient maître temporairement) afin que ce dernier effectue avec lui la manœuvre. Il faudra également modifier le premier programme (manœuvre d'évitement) afin qu'il s'insère correctement dans le principal.

Fin de la 11ème séance :

Nous avons poursuivis les travaux avec l'autre binôme et finalement, nous nous sommes rendu compte au fil des séances que le logiciel NXT n'était pas vraiment ergonomique et que, si nous le connaissions, le langage C nous aurait peut être simplifier la tâche. Pour ce qui est du programme, nous n'avons pas réussi à le faire fonctionner avec l'autre binôme. En effet, le programme était trop conséquent et 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écoupait en 3 parties: communication des mesures, prise de décision, et manœuvres. La prise de décision permettait de choisir le coté où il fallait tourner, c'est à dire du côté du robot qui était 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".

Fin de la 13ème séance :

Nous avons enfin terminé de corriger les bugs de notre programme d'évitement synchronisé et avons donc pu réaliser les vidéos de démonstration : Évitement d'obstacle seul et Évitement d'obstacle synchronisé (Prochainement)

Intégration des fonctionnalités