Synchronize2012-2 : Différence entre versions

Version du 29 mai 2013 à 13:57

Objectif

L'objectif de ce Bureau d'Etude fixé par mon groupe et celui de Corentin et Safouane est d'arriver à "coupler" nos deux robots afin de pouvoir les faire avancer grâce aux informations transmises par l'un et l'autre. Pour y parvenir, nous programmerons de prime abord de façon indépendante chacun de nos robots. Une fois autonome et apte à se déplacer sans encombre dans un environnement hostile, nous utiliserons la connexion Bluetooth® pour émettre et recevoir des informations relatives à cet environnement grâce au capteur infrarouge. Enfin, nous exploiterons le travail fait par les autres groupes pour intégrer les différents modules programmés.

Mode autonome

• Concevoir un robot basique intégrant le capteur ultrason et le boîtier NXT. Pour faciliter la suite du projet, EVE et WALL_E seront d'exactes répliques.
• Le robot avance tout droit et s'arrête dès qu'il détecte un obstacle avec son sonar. Il effectue une rotation sur place et redémarre lorsqu'aucun objet n'est détecté.

Mode couplage

• Les deux robots doivent communiquer par bluetooth pour mutuellement s'envoyer et recevoir des messages relatif aux informations obtenues sur l’environnement pendant leur navigation.
• Dans le mode couplé, les robots avancent en même temps, mais si un obstacle est détecté par le sonar d'un des robots, le couple tourne dans la direction où aucun obstacle n'est pas détecté.
• Nous tenterons de prendre en copte le cas ou les deux robots détectent un obstacle, auquel cas ils s'arrêtent.

Intégration des autres composantes

On distinguera le mode autonome du mode téléguidé :

• Mode autonome :
  • Suivi d'une ligne de couleur discontinue ou non
  • Se diriger grâce à l'outil boussole
  • Capter le tag d'une carte RFID et communiquer sa valeur à la FoxBoard
  • Communiquer avec les autres robots (notre premier objectif)

• Mode téléguidé :
  • Contrôle par un téléphone ou une tablette Android® via le serveur web de la FoxBoard
  • Commande permetant d'avance, de reculer ou de tourner
  • Affichage de l'image de la webcam embarquée sur le support de guidage

Construction du Robot : EVE

EVE 1.0

La structure du robot inclut 2 moteurs à 2 roues motrices. Les moteurs se branchent ensuite sur les ports A et B du boitier NXT. Le premier montage fût celui proposé par la notice LEGO Mindstorms.

Nous l'avons simplifié par la suite pour pouvoir construire 2 robots identiques, Wall-E et Eve. Pour commencer, seul le capteur infrarouge pouvait nous aider à détecter les obstacles, problème majeur soulevé dans la seconde partie du BE. Il ne restait plus qu'à intégrer les chaines; les roues n’étant pas très adaptés à une conduite "fluide" notamment lors des rotations.

EVE 1.0, clone parfait de son homologue WALL_E, fît ses premiers pas sur Terre.

Structure du robot

EVE 1.0

Robot base de la notice Lego

EVE 1.5

Après divers test du mode autonome dans la salle, nous nous sommes aperçu que la "tête" de nos robots était trop haut perchée pour percevoir les bas de chaises et autres obstacles. Apres quelques tentatives la hauteur idéale fût trouvée.

Premiers regards entre WALL_E et EVE

EVE 2.0

Seulement voilà : le printemps arriva, la nouvelle tenue de EVE aussi. L'intégration des fonctionnalité est l'occasion rêvée de faire peau neuve. Nous revînmes sur nos pas en appliquant la base de la notice Mindstorm®, plus stable surtout au niveau des chenilles. Le boîtier NXT, la FoxBoard et sa batterie furent placées verticalement par dessus la base, maintenu par un fil de fer. Nous avons branché un Hub sur la FoxBoard sur lequel nous avons branché une Webcam, une clef Wifi et une clef bluetooth. Voici le résultat :

WALL_E et EVE 2.0 réunis

EVE 2.0 vue du dessus

EVE 2.0 vue de face

EVE 2.0 vue de profil

Mode autonome

Programme pour éviter les obstacles

La programmation s'est faite en deux étapes : un premier programme "basique" de détection d'obstacle amélioré par la suite afin de pouvoir éviter ces derniers. Le principe est simple : le robot avance tout droit jusqu'à rencontrer un obstacle, qu'il évite alors en tournant sur place et reprend sa route lorsque la voie est libre. Le robot commence à avancer puis rentre dans une boucle de laquelle on ne sort que si un obstacle est détecté. On ordonne alors au robot de tourner jusqu'à ce que la voie soit libre. On sort alors de cette boucle pour revenir au début et se remettre à avancer. Voici la vidéo évite obstacles ou Lien YouTube

Mode Couplage

WALL_E et EVE étant prêts pour une programmation en couple, nos deux groupes ont travaillé ensemble pour la réalisation des programmes.

Mise en place de la connexion bluetooth

Notre premier essai consistait en la réalisation d'un programme qui permettait de faire avancer les deux robots et de les arrêter lorsque l'un des deux détectait un obstacle. Mais cet essai fut un échec. En effet, nous nous sommes précipités dans la programmation sans tester la connexion bluetooth et vérifier le couplage des deux boitier NXT.

Sur les conseils d'un encadrant, nous avons donc réalisé un programme basique juste pour tester la connexion bluetooth. Ce programme était le suivant : WALL_E envoie un message bluetooth à EVE. Tant qu'EVE ne reçoit pas le message bluetooth, elle affiche :(. Au contraire si elle le reçoit, elle affiche un :). Malheureusement, même ce programme basique ne fonctionnait pas. Après avoir passé un long moment à vérifier ou modifier le programme, nous avons eu une idée : changer le nom des deux robots (qui ne s'appelaient pas encore WALL_E et EVE à ce moment). Miracle ! Le programme fonctionna à merveille. La cause était toute simple : WALL_E se connectait à un autre boitier de la pièce qui portait exactement le même nom que celui d'EVE avant modification.

Test communication en mouvement

Dans un premier temps, sur la base de ce programme, qui mettait en évidence la bonne réception des messages bluetooth, nous avons réalisé un programme plus complexe qui était le suivant : EVE avance et lorsqu'il y a un obstacle devant WALL_E (notre main) celui-ci envoie un message bluetooth à EVE pour lui dire de s'arrêter et EVE s'arrête. Voici deux screens des programmes maître (WALL_E) et esclave (EVE):

WALL_E test stop

EVE test stop

Ici, chez WALL_E, on test en boucle les obstacles à l'aide du capteur ultrason. S'il y a un obstacle, il envoie un message texte "stop" à la connexion 1 (EVE) dans la boite 4.

Chez EVE, le robot démarre, il test en boucle s'il a reçu un message dans la boite 4. S'il en reçoit un, il s’arrête, sinon il continue.

Voici une petite vidéo du programme en action : Test stop par message bluetooth ou Lien YouTube

Démarrage synchronisé

Suite au succès du test précédent, nous avons tenté de faire démarrer les robots simultanément. Cela à l'aide de message envoyés par bluetooth. Le principe était le suivant :

• Les bluetooth des deux robots s'allument, WALL_E lance la connexion à EVE.
• WALL_E envoie un message "start" à EVE par blutooth pour lui dire de partir.
• Si EVE reçoit le message, elle démarre et elle renvoie un message bluetooth "go" à WALL_E.
• Quand WALL_E reçoit le message "go" il démarre.

Ce principe correspondait en quelque sorte à un accusé de réception du coté de WALL_E. Malheureusement, ce programme ne fonctionnait pas à tous les coups. Il se pouvait que les robots démarrent en même temps, ou au contraire un peu en décalage, comme on peut le voir sur la vidéo suivante : Départ avec message bluetooth ou Lien YouTube

La cause était peut être la perte de message, ou un temps de latence qui empêchait les messages d'arriver simultanément. Nous avons donc décidé de faire démarrer les robots quoi qu'il arrive, mais en laissant un certain temps (5 à 10 secondes) pour être sûr que les deux robots soient connectés par bluetooth.

Test START & STOP

Puis, dans un second temps, nous avons réalisé deux nouveaux programmes (un pour Wall_E, l'autre pour EVE). Le but de ce nouveau test était de mettre les deux robots en mouvements, puis lorsqu'il y avait un obstacle devant WALL_E alors les deux robots s’arrêtent, et lorsqu'il n'y a plus d'obstacle, les deux robots redémarrent. Voici en image les programmes de chacun des robots.

WALL_E test start & stop

EVE test start & stop

• Ici, le programme de WALL_E possède trois branches :

- 1e Dans une grande boucle, on passe dans une petite boucle vide qui permet au robot d'avancer tant qu'il n'y a pas d'obstacle. S'il y a un obstacle, on sort de la boucle puis on rentre dans la seconde petite boucle qui permet d'arrêter le robot et de lui faire envoyer le message bluetooth "stop" à EVE dans la boîte 1, et cela tant qu'il y a un obtacle. Lorsqu'il n'y en a plus, le robot redémarre et on revient au début de la grande boucle.

- 2e Le Bluetooth s'allume et il lance la connexion à EVE

- 3e Après 5 secondes le robot démarre

• Quant à EVE, elle possède deux branches :

- 1e Le Bluetooth s'allume (pour que WALL_E se connecte).

- 2e Après 5 secondes, on rentre dans une boucle infinie, puis une petite boucle : Tant que EVE n'a pas reçu le message bluetooth "stop" dans la boîte 1, elle avance, dès qu'elle le reçoit elle s'arrête et on repart au début de la boucle. Sauf qu'ici, comme il y a un obstacle et que WALL_E continue d'envoyer "stop", on ne rentre pas dans la petite boucle et EVE reste donc à l’arrêt. Quand il n'y a plus d'obstacle, WALL_E n'envoie plus de message, on rentre donc dans la petite boucle pour que EVE avance jusqu'au prochain message "stop".

Voici une petite vidéo de démonstration : Test Start & Stop ou Lien YouTube

Après ce test, nous avons décidé de réaliser un programme qui permet aux robots de s'arrêter s'il y avait un quelconque obstacle devant l'un des robots (WALL_E ou EVE) et de redémarrer lorsqu'il n'y aait plus d'obstacle. Pour cela, nous avons utilisé le programme précédent en essayant de l'intégrer sur les deux robots :

EVE Test start stop 2

• Programme de EVE avec trois branches :

- 1e Grande boucle dans laquelle on retrouve une petite boucle avec aucune action tant qu'il n'y a pas d'obstacle. Quand il y en a un, on passe à la seconde boucle qui donne l'ordre au robot de s'arrêter et d'envoyer STOP par bluetooth à WALL_E tant qu'il y a un obstacle. Enfin, quand il n'y a plus d'obstacle, on passe dans la dernière boucle qui envoie GO à WALL_E pour se remettre en route.

- 2e Lancement de la connexion bluetooth

- 3e Temps de 5 secondes pour lancer la connexion bluetooth puis un grande boucle dans laquelle il y a deux autres petites boucles : la première qui ordonne à EVE d'avancer tant qu'elle reçoit le GO de WALL_E et la deuxième de s'arrêter quand elle reçoit le STOP de WALL_E.

WALL_E Test start stop 2

• Programme de WALL_E avec 3 branches :

- 1e de même que pour EVE, une grande boucle dans laquelle WALL_E ne fait fait rien quand il n'y a pas d'obstacle, qui s'arrête et envoie STOP à EVE lorsqu'il y en a un et enfin envoie GO à EVE quand il n'y en a plus.

- 2e Lancement de la connexion bluetooth

- 3e De même que pour EVE, temps de 5 secondes avant de démarrer, une grande boucle et deux petites boucles qui ordonne à WALL_E d'avancer quand il reçoit le GO de EVE et de s'arrêter quand il reçoit le STOP de EVE.

Ce programme fonctionnant en apparence, nous avons décidé de commencer un programme, sur la même base que celui-ci, pour permettre à WALL_E et EVE de tourner de concert. Pour simplifier les choses nous avons imposé le fait que WALL_E serait toujours à droite et EVE à gauche. Ainsi lorsqu'il y a un obstacle devant EVE, les deux robots tournent à droite et quand c'est devant WALL_E, ils tournent à gauche.

Pour réaliser le programme nous n'avons eu qu'à changer quelques blocs seulement :

• Chez EVE : le bloc STOP pour s'arrêter de la première ligne est devenu un bloc pour tourner à droite (quand il y a un obstacle devant EVE) et celui de la troisième ligne est devenu un bloc pour tourner à gauche (quand il y a un obstacle devant WALL_E et qu'il envoie STOP).

• Chez WALL_E : le bloc STOP pour s'arrêter de la première ligne est devenu un bloc pour tourner à gauche (quant il y a un obstacle devant WALL_E) et celui de la troisième ligne est devenu un bloc pour tourner à droite (quand il y a un obstacle devant EVE et qu'elle envoie STOP).

Pour la première fois, nos deux robots ont tourné de concert, c'est à dire à droite quand il y avait un obstacle devant EVE et à gauche quand c'était devant WALL_E. Malheureusement, ce programme n'était pas vraiment parfait. En effet, il marchait très bien certaines fois, mais d'autres fois, on pouvait observer des bugs, comme des saccades lors des virages ...

Nous avons donc appelé le professeur a la rescousse et lui avons montré notre programme Test start & stop 2. C'est ainsi qu'il nous a fait remarqué que notre programme était un peu bancale et qu'il y avait des contradictions entre la 1e et 3e branche (un ordre STOP dans la 1e qui rentre en conflit avec un ordre AVANCER dans la 3e), ce qui expliquait que parfois les robots marchaient très bien et d'autres fois non.

Une autre forme de programmation nous a donc été proposée pour ce Start & Stop et qui permettait de ne plus avoir de conflit. Nous avons donc pu réaliser la version 3 du test Start & Stop qui est la version finale :

EVE Test start & stop 3

WALL_E Test start & stop 3

Ici des deux côtés, nous avons un programme à trois branches :

- 1e Une boucle qui permet de tester en continue la présence d'obstacle. S'il y en a un le robot s'arrête et envoie un STOP à l'autre, sinon il envoie GO.

- 2e Lancement de la connexion bluetooth

- 3e Temps de 5 secondes pour démarrer la connexion bluetooth, puis démarrage du robot. On rentre ensuite dans une grande boucle qui teste en continue la réception de message bluetooth. Si le robot reçoit un message, il enregistre le texte (STOP ou GO dans notre cas) dans une variable Texte 1 et en fonction de cette variable, s'il s'agit du GO le robot avance, s'il s'agit du STOP le robot s'arrête. Si le robot ne reçoit pas de message il ne fait rien et continue donc d'avancer.

Test virage de concert

Nous avions déjà réussi à faire tourner les robots de concert en fonction des obstacles, mais cela avec un programme un peu bancale. Il s'agit donc ici de poursuivre notre avancé, mais sur la base de la version 3 du Test Start & Stop, toujours avec comme postulat WALL_E à droite et EVE à gauche.

Nous en sommes donc arrivé à ces deux programmes pour chacun des robots :

WALL_E Synchronisation virage

EVE Synchronisation virage

• Chez WALL_E trois branches :

- 1e WALL_E teste en boucle les obstacles à l'aide du capteur ultrason. S'il y a un obstacle, il change sa variable logique "local" en vraie et envoie un message "obstacle" en bluetooth à EVE (qui permettra à EVE de savoir qu'il y a un obstacle devant WALL_E). Sinon la variable "local" devient fausse et WALL_E envoie "libre" à EVE.

- 2e lancement de la connexion bluetooth puis une branche qui permet l'action du robot. En effet, dans ce programme, chaque robot va décider pour l'autre. On a donc un test logique qui va suivre : Si les variables "local" et "distant" sont vraies, on envoie STOP à EVE, sinon si l'une des deux est vraie, si c'est "local" qui est vraie, alors on envoie "gauche", sinon on envoie "droite" car dans ce cas c'est "distant" qui est vraie et donc il y a un obstacle devant EVE. Et enfin si aucune des deux variables est vraie, on envoie "GO" à EVE car la voie est libre.

- 3e Temps de 5 secondes pour la connexion bluetooth, puis WALL_E démarre. Ensuite dans la boucle on test les messages bluetooth reçus dans deux boîtes différentes. Dans la première, on teste les messages de la boîte 2, qui permettent à WALL_E d'agir s'il reçoit STOP, GO, DROITE ou GAUCHE. Dans la deuxième, on teste les messages de la boîte 3, ce qui permet de mettre la variable "distant" à jour c'est à dire vrai ou faux s'il y a un obstacle devant EVE ou non.

• De même chez EVE, trois branches :

- 1e Teste en continue des obstacles devant EVE pour tenir à jour la variable logique "local" de EVE et d'envoyer un message à WALL_E pour qu'il mette à jour sa variable "distant".

- 2e lancement de la connexion bluetooth, puis les mêmes testes que chez WALL_E. Sauf qu'ici, si "local" de EVE est vraie on envoie DROITE à WALL_E sinon si "local" est faux alors "distant" est vraie et on envoie GAUCHE.

- 3e Temps de 5 secondes, puis EVE démarre. De même que chez WALL_E, on teste les boîtes 1 et 4. Dans la 1, EVE agit en fonction des ordres reçus. Dans la 4, on tient à jour la variable "distant" de EVE en fonction des obstacles présents ou non devant WALL_E.

Ce programme n'a malheureusement pas marché, alors que techniquement il le devait. Pour en trouver la cause, nous l'avons repris point par point. Après plusieurs heures sans trouver la cause, nous avons décidé de tester l'envoie des messages bluetooth par de simples programmes.

Nous avons donc essayé avec un petit programme qui permet d'afficher sur chacun des deux boîtiers NXT de WALL_E et EVE la distance des obstacles devant les capteurs ultrasons. Pour ce faire, WALL_E envoyait en continue la valeur de son radar par bluetooth à EVE (qui l'afficher à son écran) et inversement, EVE envoyait en continue la valeur de son radar par bluetooth à WALL_E (qui afficher également la valeur sur son écran).

C'est ainsi que nous avons trouvé la cause du problème ! Sur l'écran de EVE on observait d'énormes fluctuations de la valeur du radar de WALL_E qui passait de 0 à 256 très rapidement et en clignotant. Nous en avons déduis qu'il y avait quelques problèmes dans l'envoie des messages bluetooth de WALL_E ou dans la réception des messages bluetooth de EVE.

Or le programme de synchronisation que nous avions fait était composé de beaucoup de messages bluetooth. Nous avons donc décidé de réduire le nombre un maximum.

C'est en regardant le programme du groupe de l'année précédente que nous avons eu une idée : Chaque programme (celui de WALL_E et celui de EVE) sera composé d'un unique envoie de message bluetooth.

En effet, chaque robot va envoyer la valeur de son radar à l'autre. Ainsi, chaque robot aura en temps réel la valeur des deux radars et pourra agir en fonction de ces valeurs.

Par exemple si il y a un obstacle à 25 cm de EVE, les deux robots seront au courant et décideront chacun de leur côté de tourner à droite.

EVE Synchronisation des radars

WALL_E Synchronisation des radars

Voici donc les deux programmes que nous avons obtenus. Tous les deux composés de trois branches et conçus de la même manière.

Dans la 1ère branche, qui correspond à l'action, on teste d'abord si la valeur du radar de WALL_E est inférieure à 30 (c'est à dire s'il y a un obstacle à moins de 30 cm) si c'est le cas alors on tourne à gauche, sinon si c'est la valeur du radar de EVE qui est inférieure à 30 alors on tourne à droite et sinon on continue d'avancer.

Dans la 2ème branche, les robots testent en continue la valeur de leur radar pour l'inscrire dans une variable (radar_w chez WALL_E et radar_e chez EVE) et envoie cette valeur à l'autre robot par message bluetooth pour la garder à jour. On aura donc également un radar_w chez EVE et un radar_e chez WALL_E.

Dans la 3ème branche, les robots lisent la valeur qu'ils reçoivent par message bluetooth et l’inscrivent dans une variable qui correspond à la valeur du radar de l'autre robot. Ici on peut remarquer qu'il y a deux variable : celle du radar mais avant cela, une variable Nombre 1. Nous avons remarqué sur les affichages à l'écran des boîtier NXT que la valeur passait en continue et très rapidement (clignotement) de 0 à la bonne valeur. En fait, quand le robot ne reçoit pas de message, il inscrit quand même une valeur (0 en en l'occurrence) dans la variable. Il suffisait d'un petit temps de latence pour perturber les valeurs des radars, et ainsi le programme ne pouvait marcher.

Nous avons donc introduit cette variable Nombre 1 pour stocker toutes les valeurs (0 et la bonne valeur), et nous avons décidé d'inscrire la valeur de cette variable dans radar_e ou radar_w seulement quand le robot avait reçu un message. Ainsi dans les variables radar_w ou radar_e, nous avions la bonne valeur du radar sans fluctuations.

C'est finalement cette version qui nous a permis d'atteindre l'objectif intermédiaire. Vous trouverez la vidéo sur ce lien : Objectif Intermédiaire

Intégration des autres composantes

Le BE touchant à sa fin, nous avons pu récupérer et ajuster les programmes des autres groupes afin d'intégrer les fonctions suivantes :

Suiveur de ligne

Nous avons commencé par le suiveur de ligne continue en créant un programme indépendant. Nous nous sommes inspirés de celui du groupe de l'année précédente. Le principe est le suivant : Le robot avance tout droit lorsque le capteur couleur détecte la ligne verte. Lorsque celle-ci ne se trouve plus devant le capteur couleur, le robot s'arrête et effectue un balayage de la droite vers la gauche avec un angle de plus en plus grand. Dès que le robot retrouve la ligne verte, il se remet en route. Vous pouvez voir la démonstration ici : Suiveur de ligne

Contrôle à distance

Pour le contrôle à distance, nous avons commencé par configurer la FoxBoard via un pc Linux. Cette étape étant réalisée, nous avons pu nous connecter sur le serveur Web de la FoxBoard par wifi et avec notre Smartphone. Dans la page configuration, nous avons rentré l'adresse MAC du boîtier NXT de WALL_E, puis nous avons connecté le NXT à la FoxBoard par bluetooth.

Les connexions étant au point, il ne manquait plus qu'un programme au boîtier NXT pour pouvoir contrôler le robot à distance. Ce programme nous a été fourni par un groupe, ainsi, sans perdre de temps, nous avons pu le tester directement.

Le programme étant lancé par le NXT et toujours avec le smartphone, connecté en Wifi à la FoxBoard via la clef Wifi branchée sur celle-ci, nous nous sommes rendu sur la page de pilotage. Comme prévu, nous avons pu contrôler le robot à l'aide des flèches, mais également grâce à la rose des vents.

Enfin, dernière étape du contrôle à distance : la Webcam. Pour cela, nous l'avons branchée à la FoxBoard via USB. Cette fois-ci à l'aide d'un PC, nous nous sommes connecté via Wifi à la FoxBoard et nous sommes allés dans l'onglet configuration pour activer la Webcam. Ainsi, l'image de la Webcam était retransmise sur la page de pilotage. Nous nous sommes donc amusés à piloter le robot via les flèches tout en regardant la vidéo pour nous diriger. Vous trouverez la vidéo du contrôle à distance sur ce lien

RFID

WALL_E est capable de lire les cartes RFID grâce à un bout de programme que nous avons inclus dans le suiveur de ligne. En effet, dès que WALL_E rencontre une carte RFID sur la piste, il sait que la ligne va être coupée, et qu'il va donc devoir continuer tout droit jusqu'à trouver une nouvelle carte RFID ou la suite de la ligne verte du circuit.

Démonstration

Je termine avec une vidéo résumant mon travail lors de ce bureau d'étude. Ce fût très formateur et me permis de conforter mon choix pour le cycle ingénieur : l'IMA. Je tiens à remercier M. Xavier REDON et M. Alexandre BOE de nous avoir permis de mener à terme ce projet.

Bonus !

La nouvelle star du net WALL_E nous interprétant Gangnam style.