Synchronize2012-1 : Différence entre versions

Version actuelle datée du 28 mai 2013 à 20:02

Le but du Bureau d'Etude

A travers ce Bureau d'Etude, nous allons concevoir un robot patrouilleur semi-autonome, c'est-à-dire qu'il sera capable d’interagir avec son environnement en accumulant des données sur celui-ci (des images par exemple) sans une intervention humaine. Dans un premier temps, le robot devra remplir une fonction précise (suivi d'une ligne, d'un parcours RFID ...). Dans notre cas, il s'agira de concevoir un robot étant synchronisé en bluetooth avec un autre. Dans un second temps, le robot devra intégrer un certain nombre de fonctionnalités étudiées par les autres binômes. Une vidéo de présentation et de démonstration du robot finale clôturera ce projet.

Buts de la première partie :

• Concevoir un robot basique intégrant le capteur ultrason et le boîtier NXT.
• 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é.
• Les deux robots doivent communiquer par bluetooth pour mutuellement s'envoyer et recevoir des messages par rapport 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 détecté.

Buts de la seconde partie :

Le robot doit maintenant intégrer les fonctions suivantes :

• Suivi d'une ligne de couleur discontinue
• Capter une carte RFID et enregistrer et renvoyer sa valeur
• Indiquer sa position exacte avec l'outil boussole
• Se synchroniser avec d'autres robots et communiquer
• Circulation auto en évitant les obstacles ou pilotage via téléphone ou tablette.

Construction du Robot : WALL_E

Construction de la base du robot

Robot base de la notice Lego

Pour cette première séance, nous avons réalisé la base du robot : Nous avons suivi le montage proposé par la notice Lego Mindstorms, qui comporte 3 moteurs et le boitier NXT. Mais le 3ème moteur étant superflue, et étant le seul groupe a travailler sur les robots synchronisé, nous avons décidé de réaliser un robot plus basique en utilisant le moins de pièces Lego possibles pour pouvoir réaliser un 2ème robot identique.

Base motrice du nouveau Robot

Nous avons donc utilisé 2 moteurs reliés simplement par des barres Lego pour former un socle destiné à recevoir le boitier NXT comme on peut le voir sur la photo ci-contre. Par la suite, nous avons fixé les 4 roues, dont 2 sur les moteurs qui, lors de leur activation permettent au robot d'avancer, ainsi que le capteur infrarouge, nécessaire pour entreprendre la première partie, puisqu'il permet de détecter les obstacles. Une première version du robot ayant été réalisée, nous avons pu nous familiariser avec les fonctionnalités du robot grâce à la fonction "Try Me" intégrée dans le boitier NXT. Nous avons ainsi rencontré un premier problème : l'utilisation des roues n'était pas très adaptée, puisque lors des rotations et de l'avancée du robot, la conduite n'était pas très fluide. Nous avons donc opté pour les chenilles.

Nous avons ainsi obtenu la première version de WALL_E :

Première version de WALL_E

Modification de WALL_E

Suite à l'utilisation de notre robot, nous nous sommes rendu compte que le capteur à ultrasons était installé un peu trop haut par rapport aux obstacles présents dans la pièce, comme les pieds de chaises ou de tables par exemple. Nous avons donc effectuer plusieurs test pour trouver la bonne hauteur pour mettre en place le capteur. Entre temps, un autre groupe nous a rejoint sur le projet. Nous n'avons donc pas du construire un deuxième robot, puisque c'est le second groupe qui s'en est chargé.

WALL_E et EVE

Suite à l'intégration des nouvelles fonctionnalités, nous avons relooké WALL_E. Nous avons tout d'abord modifié la structure de base, en reprenant celle de la notice, qui était beaucoup plus stable à notre goût. Nous avons ensuite remis le capteur ultrason, mais nous avons également ajouté un capteur de couleur et un capteur RFID à sa droite et sa gauche. Plaçant le boîtier NXT à la verticale, nous avons ajouté la FoxBoard et sa batterie, maintenant le tout à l'aide d'une jolie fil de fer. Sur la FoxBoard, nous avons branché un Hub sur lequel nous avons rebranché une Webcam, une clef Wifi et une clef bluetooth. Voici le résultat :

WALL_E 2.0 de dessus

WALL_E 2.0 de face

WALL_E 2.0 de profil

WALL_E et EVE 2.0 réunis

Première Partie

Mode Autonome

Programme pour éviter les obstacles

Après avoir pris connaissance et s'être familiarisés avec le logiciel de programmation Lego Mindstorm, nous avons débuté la programmation par la réalisation d'un premier programme qui permettra au robot d'avancer puis de s’arrêter s'il détecte un obstacle. Par la suite nous avons établit un programme un peu plus complet qui permet au robot de circuler tout en évitant les obstacles. On peut voir ci-contre le code du programme :

Ici, le principe est simple : Le robot commence à avancer puis on rentre dans une boucle vide qui tourne. S'il rencontre un obstacle, on sort de cette boucle, le robot s'arrête et commence à tourner. On rentre à nouveau dans une boucle vide : le robot va donc tourner jusqu'à ce qu'il ne détecte plus d'obstacle. Si c'est le cas, on sort de la boucle et le robot peut se remettre à avancer et ainsi de suite.

Voici une petite vidéo de démonstration : Vidéo évite obstacles ou Lien YouTube

Même si le robot semble rapide, il existe un inconvénient : on voit que le robot favorise une direction, qui est la gauche. On voit en effet que le robot tourne en rond. Mais comme ce programme n'est pas d'une extrême importance, nous avons choisi d'ignorer cet inconvénient et de passer à la suite.

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. Et voici donc la vidéo du résultat :

YouTube - Objectif Intermédiaire

Deuxième Partie

Après avoir réussi l'objectif intermédiaire, nous avons commencé la deuxième partie du bureau d'étude, qui consiste en l'intégration de toutes les fonctionnalités sur notre robot WALL_E.

Nous avons donc commencé par modifier la structure de celui-ci en lui ajoutant une FoxBoard, une clef wifi, une clef bluetooth, une webcam, le capteur couleur et RFID (Voir partie construction robot plus haut).

Ensuite, nous avons collaboré avec les autres groupes, afin d'obtenir leur programme et ainsi pouvoir les intégrer au programme final.

C'est ainsi que nous nous sommes rendus compte des inconvénients du logiciel Lego MindStorm. Au début, nous trouvions sympathique l'idée d'assembler des bloques, puisque cela ne nécessitait pas de compétences en langage de programmation. Par la suite, plus les programmes devenaient complexes, plus il y avait de bloques et donc plus le programme était lourd. Cela occasionnait quelques bugs du logiciel (des barres qui apparaissent n'importe où et qui corrompent le fichier, qui ne peut donc être exécuté par le boîtier NXT) mais aussi des problèmes de navigation à l'intérieur du logiciel pour se déplacer du bloque tout à gauche jusqu'à celui de droite (ralentissement, problèmes de malléabilité pour déplacer des bloques ... ).

De plus, tous les groupes n'ont pas utilisé le logiciel, mais ont programmé en C. Il était donc impossible d'utiliser directement leur programme. Nous avons donc du recréer un programme nous même sur Lego MindStorm (notamment avec la RFID).

Suiveur de ligne

Suivi de ligne continue

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.

Contrôle à distance

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.

RFID

Lecture d'une carte RFID

Suivi de ligne discontinue avec une carte RFID avec le programme "suivligne+RFID"

Tout d'abord, nous avons créé un petit programme permettant de connaitre le code d'une carte RFID, comme on peut voir ci-contre. Ainsi WALL_E est maintenant 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.

Comme on peut le voir sur le programme ci-contre, nous avons créé un programme de suivi de ligne discontinue mais en reprenant sous forme de "My Blocs" le programme précédemment créer pour suivre les lignes continues (tout en enlevant la grande boucle du vrai programme). En effet tant que WALL_E n'a pas détecté la carte RFID, il va effectuer le suivi de ligne. Mais lorsqu'il la détecte (ce qui signifie que la ligne sera discontinue après), alors il va stopper le suivi de ligne et va avancer tout droit jusqu'à retomber sur une ligne verte. C'est le programme "Suivligne+RFID".

Programme Final

Algorithme

Suivi de ligne discontinue avec plusieurs cartes RFID

Le programme précédent permettait de suivre une ligne discontinue mais seulement avec la présence d'une seule carte RFID. Nous l'avons donc modifié pour que WALL_E puisse faire un tour de circuit en passant les deux "trous" grâce aux deux cartes RFID les annonçant. Nous avons relevé le numéro des cartes à l'aide du programme "Lecture carte". Puis nous avons créé une variable logique RFID qui est fausse si le capteur RFID ne détecte aucune des deux cartes ou vraie si il en détecte l'une des deux.

En reprenant le programme précédent "Suivligne+RFID", nous avons créé un nouveau "My Blocs" appelé suivligne encore une fois. Dans celui-ci, nous avons remplacé les boucles "tant qu'il n'y a pas de RFID" et "tant qu'il n'y a pas la couleur verte" par un Si : Si la variable RFID est fausse alors on effectue le programme classique de suivi de ligne continue. Si elle est vraie, alors on avance tout droit tant qu'on ne retrouve pas la ligne verte.

Le programme final est donc composé du programme de suivi de ligne discontinue avec plusieurs cartes RFID (ci-dessus) ainsi que du programme de Contrôle à distance ajouté séparément.

Démonstration

Vidéo de démonstration de toutes les intégrations précédentes :

| Lien YouTube de la vidéo de présentation de WALL_E

Bilan du Bureau d'Etude

Ce Bureau d'Etude nous a fait découvrir un certain nombre de chose, notamment à propos de la spécialité IMA. Mais également sur l’importance du travail par projet, pour lequel il est primordial de fournir des efforts réguliers sous peine de ne pas terminer totalement ou en retard, comme ce fut notre cas. Malgré les difficultés rencontrées, nous avons tout de même réussi à terminer les principaux objectifs et cela grâces aux professeurs. Nous tenons donc à remercier M. Xavier REDON et M. Alexandre BOE pour leur aide et leur patience tout au long de ce BE.

BONUS

WALL_E danse Gangnam Style pour le plaisir de vos yeux