Synchronize2011-2

De Wiki de bureau d'études PeiP

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.

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 programme 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 un 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. 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 pu fonctionner...

Nous avons également appris qu'il fallait que les autres capteurs (RFID, touche...) soient installés sur le robot car ils serviront pour la seconde partie du BE qui consistera à rassembler nos différents projets sur une seule machine.