Synchronize2011-2 : Différence entre versions

De Wiki de bureau d'études PeiP
(Intégration des fonctionnalités)
Ligne 1 : Ligne 1 :
 
== Construction du robot ==
 
== 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.
+
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.
  
 
<gallery>
 
<gallery>
Ligne 12 : Ligne 12 :
 
</gallery>
 
</gallery>
  
== Programmation NXT ==
+
== 1ère partie : Evitement synchronisé ==
  
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.
+
=== Programmation NXT ===
  
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:
+
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
 
  compteur = 0
Ligne 36 : Ligne 38 :
 
  fin tant que
 
  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.
  
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 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é...
 
 
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.
+
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 ===
== Synchronisation des robots ==
 
 
 
 
 
=== 7è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''' :  
 
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.
+
::''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. 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.
 
  
=== 11ème séance ===
+
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 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.  
+
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".  
 
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.  
+
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 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.
+
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.
 
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.  
+
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".
 
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".
  
=== 13ème séance ===  
+
=== 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.
 
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.
Ligne 85 : Ligne 77 :
 
</gallery>
 
</gallery>
  
== Intégration des fonctionnalités  ==
+
== 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.
 
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 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 couple le suiveur de ligne fonctionnel avec un programme 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. Malheureusement, les valeurs répondues sont erronées pour le moment. Des captures d'écran de notre programme seront uploadées.
 
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 couple le suiveur de ligne fonctionnel avec un programme 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. Malheureusement, les valeurs répondues sont erronées pour le moment. Des captures d'écran de notre programme seront uploadées.
 
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.
 
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.

Version du 26 mai 2012 à 14:04

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.

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) :

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 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 couple le suiveur de ligne fonctionnel avec un programme 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. Malheureusement, les valeurs répondues sont erronées pour le moment. Des captures d'écran de notre programme seront uploadées. 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.