Synchronize2011-1
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.
- Photo *
Programmation pour la première partie du projet
Première partie du programme:
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 successivement d'un angle donné à gauche et 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.
Seconde partie du programme:
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 avancant 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.
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.
