Synchronize2011-1 : Différence entre versions
(→Construction du Robot synchronisé, ATOM.) |
|||
| Ligne 295 : | Ligne 295 : | ||
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. | 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. | 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. | ||
| + | |||
| + | |||
| + | == 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 la personne chargée de la réalisation de la vidéo pour sa patience et son dévouement. | ||
<br> | <br> | ||
<br style="clear: both;" /> | <br style="clear: both;" /> | ||
Version du 29 mai 2012 à 18:44
Sommaire
Les objectifs de ce Bureau d'Etude
Le but de ce Bureau d’Étude est de concevoir dans un premier temps des robots remplissant une fonction précise comme le suivi de ligne ou la synchronisation avec un autre robot et dans un second temps, les robots doivent intégrer toutes les fonctionnalités proposées. Nous avons été chargé de concevoir un robot destiné à être synchronisé avec un autre robot.
Objectifs de la première partie:
1) Il faut concevoir un robot permettant d'accueillir principalement un boîtier NXT, un boîtier de piles, une foxboard et quatre capteurs.
2) Le robot qui rencontre un obstacle s'arrête et cherche une issue en balayant successivement à gauche et à droite. Lorsque aucun objet n'est détecté, le robot redémarre.
3) Il faut connecter les deux robots communicants par bluetooth afin qu'ils puissent mutuellement recevoir et envoyer des messages à l'autre.
4) 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 :
1) être capable de suivre une ligne bleue et une ligne rouge discontinues
2) être capable de capter une carte RFID
3) être capable de connaître sa position exacte
4) être capable de se synchroniser avec d'autres robots
5) être téléguidé via un téléphone androïd
Le robot final effectuera une réprésentation à la fin du Bureau d'Etude.
Construction du Robot synchronisé, ATOM.
30/01/2012: Première séance: Construction 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 à sa fonctionnalité. Puis, nous avons monté les roues avec dans un premier temps des chaînes. Finalement, nous avons opté pour des pneus car les chaînes n'étaient pas assez tendues et occasionnaient des frottements.
Nous avons ensuite mis en place le boîtier NXT puis le capteur ultrasons nécessaire à la réalisation de la première partie du programme. Nous avons ensuite installé la Foxboard en prévision du projet final qui nécessite cet équipement.
06/02/2012: Deuxième séance: Fin de la construction, début de la programmation.
Nous avons terminé de construire la structure du robot en 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.
Nous avons pu commencer la programmation par le logiciel Lego Mindstorm.
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.
Programmation pour la première partie du projet
Première partie 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
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 la vidéo de démonstration de l'évitement d'un obstacle, à savoir la première partie du premier objectif.
Seconde partie 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 droite alors qu'ils le contournent par la gauche 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
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 la deuxième partie du premier objectif.
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, le temps de l'exécution du programme de cette deuxième partie.
Intégration de toutes les fonctionnalités
Programme du suiveur de ligne
Nous avons tout d'abord crée 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
Nous avons crée un programme indépendant de téléguidage de notre robot. Nous nous sommes connecté sur le serveur Web de la FoxBoard via un ordinateur et y avons rentré l'adresse MAC de notre boîtier NXT. Puis, nous avons connecté par bluetooth la NXT et la FoxBoard.
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ée 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. Ensuite, nous avons crée un programme indépendant permettant de lire les cartes RFID lorsque le robot en détecte une et de stocker le tag de la carte. Ainsi, à tout moment, une personne peut communiquer avec le robot via l'interface de la FoxBoard et lui demander la valeur de la dernière carte enregistrée. Pour ce faire, il suffit de rentrer l'ordre 65 pour que le robot renvoie le dernier tag enregistré. Cela va permettre de situer le robot sur la carte de l'interface web de la FoxBoard.
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éer 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é.
Difficultés liées à la seconde partie
Le logiciel Lego MindStorm
Dans un premier temps, nous avons été réjouis 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é dans un premier temps. En effet, le logiciel est plutôt difficile à gérer d'une part pour la navigation à l'intérieur d'un programme et d'autre part pour conserver les liaisons entre blocs qui se défont trop facilement. Dans un second temps, nous avons eu beaucoup de 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.
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 la personne chargée de la réalisation de la vidéo pour sa patience et son dévouement.
