Synchronize2011-1 : Différence entre versions

Version actuelle datée du 31 mai 2012 à 16:49

Les objectifs de ce Bureau d'Etude

Le but de ce Bureau d’Étude est de concevoir, dans un premier temps, un robot remplissant une fonction précise comme le suivi de ligne par exemple et dans un second temps, le robot doit intégrer un certain nombre de fonctionnalités. Ce projet sera clôturé par le tournage d'une vidéo de présentation et de démonstration. Nous avons été chargé de concevoir un robot destiné à être synchronisé avec un autre robot.

Objectifs de la première partie:

- Il faut concevoir un robot permettant d'accueillir principalement un boîtier NXT, un boîtier de piles, une foxboard et quatre capteurs.

- Le robot avance tout droit; lorsqu'il rencontre un obstacle, il s'arrête et cherche une issue en balayant successivement d'un angle à gauche puis à droite.

Lorsque aucun objet n'est détecté, le robot redémarre.

- Il faut connecter les deux robots communicants par bluetooth afin qu'ils puissent mutuellement recevoir et envoyer des messages entre eux.

- Les deux robots avancent en même temps; lorsqu'un robot détecte un objet, il envoie un message à l'autre et ils exécutent le programme d'évitement mis au point précédemment.

Objectifs de la deuxième partie:

Le robot doit intégrer les fonctionnalités suivantes :

- être capable de suivre une ligne bleue et une ligne rouge discontinues

- être capable de capter une carte RFID, de mémoriser et de renvoyer sa valeur

- être capable d'indiquer sa position exacte grâce à l'outil boussole

- être capable de se synchroniser avec d'autres robots et de communiquer

- être téléguidé via un téléphone androïd ou de fonctionner en mode automatique

Construction du Robot synchronisé, ATOM.

30/01/2012: Première séance: Construction du robot.

La base du robot

Nous avons construit la base de la structure du robot incluant trois moteurs. Néanmoins, nous n'utilisons que deux des trois moteurs installés. Le troisième moteur ne sert que d'élément de structure. Nous avons tout d'abord repris le modèle de construction du manuel Légo puis nous avons modifié l'original pour que le robot puisse intégrer tous les éléments nécessaires à la réalisation du programme final. Nous avons opté pour des roues car les chaînes n'étaient pas assez tendues de par notre structure.

Après introduction du boîtier NXT

06/02/2012: Deuxième séance: Fin de la construction, début de la programmation.

Après introduction de la Foxboard

Nous avons terminé de construire la structure du robot incluant le matériel nécessaire à l'alimentation des moteurs, le fonctionnement du capteur à ultrasons etc. Nous avons situé à la base de notre robot, le boîtier de piles. Cependant, nous avons laissé un accès pratique en cas de changement de piles.

Première version de ATOM

10/05/2012: Avant dernière séance: Modification de la structure du robot.

Pour le projet final, il nous a fallu ajouter une boussole, un lecteur RFID et un capteur de couleurs. Chaque capteur doit être placé dans une position particulière; Par exemple, le capteur de couleur doit être situé verticalement, très proche du sol. De ce fait, nous avons eu quelques difficultés d'intégration de ce matériel et nous avons été contraints de revoir la structure de ATOM. Nous avons également retiré les roues et installé des chaînes qui nous ont paru plus pratique pour la démonstration finale. En effet, les roues occasionnaient plus de frottements que les chaines et cela déviait la trajectoire du robot lors de l'exécution du programme.

Version anatomique finale de ATOM

Programmation pour la première partie du projet

Premier objectif du programme:

Quelques explications...

Nous avons réalisé un premier code via le logiciel Lego Mind Storm permettant au robot de s'arrêter s'il détecte un obstacle et d'avancer sinon. Puis nous avons mis au point un système de balayage de la zone : Le robot pivote d'abord d'un angle donné à gauche puis il pivote, de nouveau, du double de cet angle à droite etc ; ainsi, il contourne l'objet par le chemin le plus accessible selon la position de l'obstacle. Nous avons imposé un angle maximum de pivot pour éviter que le robot tourne de 360°. De cette façon, si l'obstacle est en mouvement, le robot s'arrête quand il atteint l'angle limite et il redémarre quand il n'y a plus d'obstacle.

Algorithme pour l'évitement d'un objet

Programme d'évitement d'un obstacle

Voici une partie de l'algorithme qui permet d'éviter un obstacle en empruntant le chemin de plus court. Ici, on visualise surtout la partie qui permet le pivotage du robot d'un degré exponentiel et la partie qui permet au robot de s'arrêter au bout certain angle défini.

Démonstration

Voici une vidéo de démonstration de l'évitement d'un obstacle. Ce programme constitue la moitié de l'objectif de la première partie.

Second objectif du programme:

Quelques explications...

Nous avons tout d'abord réalisé un court programme, en collaboration avec le second groupe chargé des robots communicants, qui permet d'envoyer et de recevoir des messages par bluetooth d'un robot à l'autre. Ensuite, nous avons élaboré un code qui permet aux robots d'éviter des obstacles simultanément grâce à la communication par bluetooth. Ainsi, Les deux robots démarrent le programme en avançant tout droit; Lorsque l'un des deux détecte un obstacle, ils l'évitent ensemble en le contournant. Pour ce faire, nous avons du définir par défaut que le maître serait toujours à la gauche de l'esclave. De ce fait, si l'esclave détecte l'objet, les deux robots le contourne par la gauche alors qu'ils le contournent par la droite si c'est le maître qui a l’obstacle. Si les deux robots détectent un objet simultanément alors ils s'arrêtent. Ils redémarrent lorsque l'objet est retiré.

Connexion Bluetooth

La connexion bluetooth entre deux robots se décompose en plusieurs étapes. Tout d'abord, l'un des robots doit être défini comme le maître et par défaut, l'autre devient esclave. Le robot maître est celui qui entame la connexion bluetooth avec l'autre robot. L'esclave occupe obligatoirement la connexion 0 alors que le maître est libre de se connecter sur celle qu'il souhaite. Afin de pouvoir créer la connexion, il est nécessaire de sélectionner l'intitulé exact du robot auquel on souhaite s'appareiller.

Les robots maître et esclave ne peuvent partager un même programme de communication inter-robots; Tout d'abord, le programme du maître doit intégrer la fonction: démarrer la connexion bluetooth avec l'esclave. Ensuite, il nous faut définir une boîte aux lettres pour l'envoi et une autre pour la réception. Par ailleurs, la boîte aux lettres sur laquelle émet le robot maître doit être celle définie comme boîte de réception du robot esclave et inversement.

Algorithme de synchronisation des deux robots

Action face à un objet

Programe du Maître

Programme de l'esclave

Voici les algorithmes des programmes maître et esclave d'évitement synchronisé d'un objet. On peut voir sur le programme du maître, le démarrage de la connexion en plus du reste du programme. Nous avons crée deux blocs que nous avons intégré à notre programme; l'un permettant d'envoyer un message à l'autre robot et l'autre contrôlant l'action des deux robots lorsqu'un objet est détecté par l'un ou l'autre des sonars. Ce deuxième bloc est détaillé sur la photo suivante:

Démonstration

Voici la vidéo de démonstration de l'évitement d'un obstacle avec les deux robots synchronisés, à savoir le deuxième objectif de la première partie.

Les problèmes rencontrés

La connexion bluetooth

Nous avons constaté que le démarrage de la connexion bluetooth du maître vers l'esclave pouvait prendre un certain temps de l'ordre d'une dizaine de secondes. Du fait, si l'esclave rencontrait un obstacle avant que la connexion soit établie, le maître n'exécutait par l'évitement de cet obstacle. Pour outrepasser ce problème technique, nous avons du instaurer un délai d'attente d'une quinzaine de secondes avant que les deux robots exécutent le programme.

Les manœuvres d'évitement

Au début de la deuxième partie, nous souhaitions intégrer, à notre programme de communication inter-robots, notre manœuvre d'évitement de la première partie. Rapidement, nous avons renoncé à cette intégration de par sa complexité. En effet, il était nécessaire de modifier intégralement la manœuvre d'évitement pour le maître et pour l'esclave afin de l'intégrer au programme de communication. De plus, l'importante capacité du fichier final occasionnait de nombreux "bugs" du logiciel Lego Mind Storm. De ce fait, nous avons été contraints de définir une position par défaut, du maître par rapport à l'esclave pour l'évitement d'obstacles.

La compatibilité des deux robots

De par leurs différences de morphologie et de poids, nous avons eu quelques difficultés de compatibilité entre les deux robots. En effet, le robot esclave est bien plus lourd que le maître ce qui implique une différence de vitesse entre les deux. Pour dépasser ce problème, nous avons "ré-agencer" le robot maître. De plus, les roues du maître occasionnaient plus de frottements lors de l'évitement d'un obstacle que les chaînes de l'esclave. De ce fait, nous avons changé les roues pour des chaînes, et ce jusqu'à la fin du projet.

Intégration de toutes les fonctionnalités

Programme du suiveur de ligne

Nous avons tout d'abord créé un programme suiveur de ligne indépendant. Nous nous sommes inspiré de celui mis en oeuvre par le groupe chargé du suivi de ligne. L'objectif premier est de suivre une ligne rouge qui peut être discontinue. Le robot effectue un balayage de la zone (même principe que pour le programme d'évitement d'un obstacle) jusqu'à repérer une ligne rouge grâce au capteur de couleur. Nous avons fixé un angle maximal qui, une fois atteint, impose au robot de revenir dans sa position initiale et lui indique d'aller tout droit pendant 5 secondes. De ce fait, il a des chances de retrouver, sur son chemin, une autre ligne. Cette partie fut rapidement exécutée. La deuxième étape consiste à établir deux circuits de deux couleurs différentes (un rouge et un bleu par exemple) et les robots doivent alors pouvoir passer d'un circuit à l'autre par simple commande de celui qui le contrôle. Cependant, par manque de temps, nous n'avons pas réussi à faire la deuxième étape. Notre robot n'est donc capable que de suivre un circuit de couleur rouge.

Contrôle à distance

Programme de contrôle à distance

Dans un premier temps, nous avions un programme simple permettant de contrôler à distance le robot par les flèches sur le serveur de la FoxBoard. Après avoir branché une clé wifi sur celle-ci, il suffit de lancer le programme de notre robot et de le contrôler grâce aux flèches. Pour finir, nous avons créé un deuxième programme, légèrement plus compliqué, permettant le contrôle à distance par la rose des vents. Cette deuxième partie de programme sera par la suite intégrée au programme final qui regroupe toutes les fonctionnalités.

Lecteur de cartes RFID

En collaboration avec les autres groupes du bureau d'études, nous avons mis au point un circuit de couleur rouge et placé plusieurs cartes RFID sur toute la longueur du circuit. Préalablement, nous avons rentré les coordonnées des cartes RFID dans le fichier .png et avons modifié la carte (fichier .html) du circuit présente sur l'interface web de la FoxBoard. Le robot va renvoyer le dernier tag relevé lorsqu'il recevra l'ordre 65 émis par la Foxboard; ce qui va nous permettre de connaître sa position qui se matérialisera sur la carte par un triangle de couleur noire.

Intégration de la boussole

Pour intégrer l'outil boussole, nous avons repris le même schéma que pour les cartes RFID. Nous avons intégrer au programme précédent une lecture des coordonnées de la boussole toutes les 0,1 secondes. Ainsi, toujours via l'interface web de la FoxBoard, en envoyant l'ordre 64 au robot, celui ci nous renvoie la dernière valeur de la boussole qu'il a enregistré. Cela permet, en absence de visuel de ATOM, de connaître son emplacement exact. De plus, si plusieurs robots circulent sur le même circuit, connaître leurs coordonnées précises permet d'éviter une collision entre deux ou plusieurs robots.

Programme final

Le but ultime de de bureau d'études est d'intégrer toutes les fonctionnalités du robot dans un unique programme. Pour ce faire, nous avons créé 3 blocs: un suivi de ligne, un lecteur RFID et un lecteur de la Boussole et nous avons, dans un nouveau programme, exécuté les trois actions en parallèle. Par manque de temps, nous ne sommes pas parvenu à ajouter à celui ci le passage du mode automatique au mode téléguidé.

Programme Final

Difficultés liées à la seconde partie

Le logiciel Lego MindStorm

Dans un premier temps, nous avons apprécié de travailler sur un logiciel ne nécessitant aucune compétence informatique pour la programmation. Cependant, nous avons très vite déchanté quant aux problèmes de malléabilité. En effet, le logiciel est plutôt difficile à gérer pour la navigation à l'intérieur d'un programme. Nous avons eu quelques problèmes dès qu'il s'agissait de travailler sur un programme volumineux. Le simple fait d'ouvrir le programme occasionnait de nombreux dysfonctionnements.

La collaboration inter-groupes

Nous avons rencontré quelques difficultés à se coordonner avec les différents groupes car certains tardaient à terminer leur première partie. De plus, certains binômes ayant codé en langage C, il n'était pas possible de collaborer pour la partie finale. La grande difficulté de cette partie a été de comprendre le fonctionnement des différentes fonctionnalités, de réussir à coder plusieurs programmes rapidement et de parvenir à les combiner en un seul.

Bilan du Bureau d'études

Malgré des débuts un peu brouillon avec la programmation en Légo, ce BE fut très complet et enrichissant. Nous cernons d'avantage la spécialité IMA et l'intérêt d'une pédagogie par projets. Le programme est intéressant même si les contraintes de temps nous obligent à passer outre plusieurs objectifs. Il serait sûrement intéressant pour les années futures d'instaurer un espace de stockage en ligne afin que chaque groupe puisse déverser au fur et à mesure les programmes qu'ils veulent. En effet, nous avons perdu beaucoup de temps à récupérer morceau par morceau et bloc par bloc les programmes. Par un espace commun, chacun amènerait une partie de programme et les objectifs pourraient être remplis.

Remerciements

Nous tenons à remercier M. Xavier REDON et M. Alexandre BOE pour leur investissement et leur persévérance tout au long de ce bureau d'études. Nous remercions également tous les binômes pour leur contribution et leur aide à l'aboutissement du programme final. Pour finir, nous remercions Laurent ENGELS, le spécialiste multi-média de l'école pour sa patience et son dévouement lors des prises de vues nécessaires à la vidéo.