Synchronize2011-2 - Historique des versions

Rex : /* Construction du robot */

2012-05-31T16:44:59Z

‎Construction du robot

Rex : /* 2ème partie : Intégration des fonctionnalités */

2012-05-30T17:31:33Z

‎2ème partie : Intégration des fonctionnalités

Rverheyd : /* 2ème partie : Intégration des fonctionnalités */

2012-05-29T13:28:57Z

‎2ème partie : Intégration des fonctionnalités

Rverheyd : /* Synchronisation des robots */

2012-05-26T16:32:01Z

‎Synchronisation des robots

Rverheyd : /* 2ème partie : Intégration des fonctionnalités */

2012-05-26T16:29:19Z

‎2ème partie : Intégration des fonctionnalités

Rverheyd : /* 2ème partie : Intégration des fonctionnalités */

2012-05-26T16:25:04Z

‎2ème partie : Intégration des fonctionnalités

Rverheyd : /* 2ème partie : Intégration des fonctionnalités */

2012-05-26T15:48:20Z

‎2ème partie : Intégration des fonctionnalités

Rverheyd le 26 mai 2012 à 14:04

2012-05-26T14:04:25Z

Rverheyd : /* Intégration des fonctionnalités */

2012-05-15T19:53:26Z

‎Intégration des fonctionnalités

Rverheyd : /* Intégration des fonctionnalités */

2012-05-15T17:55:13Z

‎Intégration des fonctionnalités

@@ Ligne 1 : / Ligne 1 : @@
 == Construction du robot ==
+<include nopre noesc src="/home/pedago/ppeip/include/video-RobotCommunicant2-2011-iframe.html" />
 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.
+<br style="clear: both;">
 <gallery>
 Fichier:06-02-12 0934.jpg|Installation de la Foxboard

@@ Ligne 111 : / Ligne 111 : @@
 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 suivi de lignes) sont effectués dans la même boîte que celle que nous utilisons pour la transmission des valeurs.
+<br style="clear: both;">
 Notre robot est donc capable de :
- - suivre une ligne
+* suivre une ligne
- - faire demi-tour sur une ligne
+* faire demi-tour sur une ligne
- - être contrôlé à distance
+* être contrôlé à distance
- - éviter un obstacle seul ou synchronisé avec un autre robot
+* éviter un obstacle seul ou synchronisé avec un autre robot
- - être détecté par la Foxboard sur le circuit (RFID et boussole)
+* être détecté par la Foxboard sur le circuit (RFID et boussole)
 Nous avons terminé par la réalisation de la vidéo de démonstration.

@@ Ligne 114 : / Ligne 114 : @@
-Nous avons terminé par la réalisation de la vidéo de démonstration.
+Notre robot est donc capable de :
-Notre robot fut capable de :
   - suivre une ligne
   - faire demi-tour sur une ligne
@@ Ligne 121 : / Ligne 121 : @@
   - éviter un obstacle seul ou synchronisé avec un autre robot
   - être détecté par la Foxboard sur le circuit (RFID et boussole)

@@ Ligne 46 : / Ligne 46 : @@
 === 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''' :
+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.
 ::''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.

@@ Ligne 80 : / Ligne 80 : @@
 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 :
+Nous avons également modifié la structure du robot afin que les capteurs RFID et RGB soient centrés à l'avant du robot :
@@ Ligne 90 : / Ligne 90 : @@
 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.
+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 du 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.
@@ Ligne 107 : / Ligne 107 : @@
-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 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 suivi de lignes) sont effectués dans la même boîte que celle que nous utilisons pour la transmission des valeurs.

@@ Ligne 1 : / Ligne 1 : @@
 == 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>
@@ Ligne 12 : / Ligne 12 : @@
 </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.
   compteur = 0
@@ Ligne 36 : / Ligne 38 : @@
   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 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é...
-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 ===
 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).''
-=== 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".
-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.
-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".
-=== 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.
@@ Ligne 85 : / Ligne 77 : @@
 </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.
 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.

← Version précédente		Version du 15 mai 2012 à 19:53
Ligne 89 :		Ligne 89 :
	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.

← Version précédente		Version du 15 mai 2012 à 17:55
Ligne 87 :		Ligne 87 :
	== Intégration des fonctionnalités ==		== 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 ~~essayons donc~~ de ~~coupler~~ le programme suiveur de ligne avec un ~~autre~~ programme ~~permettant~~ de ~~sauvegarder dans une variable~~ la ~~position~~ de la puce RFID qu'il ~~vient~~ de ~~passer dans~~ le ~~circuit~~.	+	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.