MARTANI Fayssal, GORNIAK Tomasz Encadrant: Franck Petit Projet PSAR Mise en place de différents algorithmes distribués sur des robots LEGO MARTANI Fayssal, GORNIAK Tomasz Encadrant: Franck Petit

But du projet Implémenter et tester des algorithmes distribués sur des robots bas de gamme Modèles théoriques applicables sur des robots LEGO? Protocole de communication explicite Mise en cercle de trois robots

Modèle théorique Déplacement avec une précision infinitésimale Mobiles, autonomes, pas de moyen de communication standard (sans fil). Chaque message destiné à un robot r est effectivement reçu par ce robot Mouvements précis du point de vu de l’observateur

Description de l’algorithme de communication Robots communiquant par mouvements Se déplace à gauche pour envoyer 1 (droite pour 0) et revient en position initiale

Description de l’algorithme de formation de cercle (1) Formation de cercle avec trois robots 3 cas généraux Cas 1 : robots alignés

Description de l’algorithme de formation de cercle (2) Triangle isocèle

Description de l’algorithme de formation de cercle (3) Triangle scalène (quelconque)

Implémentation

Robots utilisés LEGO Mindstorm NXT 2.0 Cout: 280$ Capteurs: Sonar (portée 10 – 80 cm) Couleur (6 couleurs disponible) Moteur avec tachymètre API : LeJos

Limitation des robots par rapport au modèle théorique Sonar Même position, 2 résultats différents Interférence Précision 2 ~ 3 cm Détection uniquement dans le champs de sonar (propriété du réception du modèle pas vérifiée) Intervalle de 30 à 45 degrés Changement de direction après quelques centimètres parcourus (impossible de détecter sans boussole)

Implémentation de l’algorithme de communication explicite (1) Communication synchrone brute Les robots commencent face à face Modèle client/serveur Les robots se déplacent verticalement et non horizontalement Déplacement horizontal pose beaucoup plus de problèmes Connaître le sens de déplacement d’un robot nécessite du travail supplémentaire Le sonar a simplement plus de chance de manquer le robot Client avance pour envoyer 1, recule pour envoyer 0 Le robot client opère par rapport à une position initiale Le message est envoyé lorsque le robot client est sorti d’un cercle de rayon 9 Il est de retour lorsqu’il est de nouveau dans un cercle de rayon 3 Au bout de quelques bits, un message est considéré reçu Le robot peu bloquer car il n’y a pas de timeout Le robot peu recevoir les bits d’un autre message (3 bits d’un message, 1 bit du suivant) A permis de déceler les problèmes Fiabilité des prises de valeur du sonar Fiabilité de la réception d’un message entier

Implémentation de l’algorithme de communication explicite (2) Le modèle nécessite des échanges fiables Communication synchrone fiable Fiabilisation des données du sonar Un tableau de 10 valeurs dont 8 doivent être égales à 1 près, les deux autres peuvent être quelconques Pour chaque nouvelle valeur issue du sonar, la valeur avec laquelle elle a le plus grand écart est supprimée La nouvelle valeur est insérée dans l’ordre croissant Continue jusqu’à la fin ou déclenchement d’un timeout Exemple avec 4 valeurs: Données reçu: 30 35 32 31 255 28 34 Tableau: 255 255 255 255 -> 30 255 255 255 -> 30 35 255 255 -> 30 32 35 255 30 31 32 35 -> 31 32 35 255 -> 28 31 32 35 -> 31 32 34 35 La précision n’est pas jugée suffisante, l’algorithme continue

Implémentation de l’algorithme de communication explicite (3) Communication synchrone fiable 2.) Fiabilisation du protocole On choisit un protocole apparenté au protocole TCP Système d’ACK et de timeout On utilise des paquets de la forme: S | F | D | D 1 bit de numéro de séquence 1 bit de flag 2 bits de data (extensible) Implémentation dans la classe TcpSocket Implémentation au moyen de 6 méthodes principales explicites public void send (MSG msg) throws IOExcept; private void tcpsend (BitPacket pqtem) throws IOExcept; private void udpsend (BitPacket pqtem); public MSG rcv () throws IOExcept; private BitPacket tcprcv () throws IOExcept; private BitPacket udprcv () throws IOExcept; La réception est faite au moyen d’un thread qui écoute en permanence Les données sont accumulées dans une buffer Rcv extrait des données du buffer ou se met en attente

Implémentation de l’algorithme de communication explicite: timeout et exception (4) Le but est de simplifier au maximum et de travailler dans un environnement familier (API socket java) Chaque erreur a son exception Chaque timeout a son exception Chaque exception dérive d’une classe IOExcept, classe d’exception principale pour les exceptions réseaux

Implémentation de l’algorithme de communication explicite: alignement des robots (5) Le but est de faire une séquence d’échanges de données complète entre les 2 robots Relativement long Les 2 robots utilisent leur sonar en même temps Problème et difficulté pour alterner entre les modes <<capture>> et <<ping>> du sonar Beaucoup de prises sont nécessaires car il faut travailler avec des moyennes La précision n’est pas bonne

Implémentation de l’algorithme de communication explicite 2 étapes: Communication synchrone brute Les robots commencent face à face Les robots se déplacent verticalement et non horizontalement Déplacement horizontal pose beaucoup plus de problèmes Sens de déplacement du robot Suivre le robot Le sonar a simplement plus de chance de manquer le robot Modèle client/serveur Au bout de quelques bits, un message est considéré reçu Le robot peu bloquer car il n’y a pas de timeout Le robot peu recevoir les bits d’un autre message (3 bits d’un message, 1 bit du suivant) A permis de déceler les problèmes Fiabilité des prises de valeur du sonar Blocage des robots Fiabilité de la réception d’un message entier Communication synchrone fiable Alignement Échange de données ACK, timeout (protocole apparenté au TCP) Système de paquets 1 bit séquence 1 bit flag 2 bits de données 6 méthodes principales : TcpSend, UdpSend, TcpRcv, UdpRcv, Send, Rcv

Démonstration // serveur try { sock.accept(); msg = sock.rcv(); } catch (IOExcept e) { e.show(); } // client sock.connect(); sock.send(BLUE);

Implémentation de l’algorithme de mise en cercle Problème de précision du sonar Démonstration

Conclusion Nécessité de remplacer le sonar pour avoir la précision Plusieurs points importants du modèle ne peuvent pas êtres vérifier dans l’état actuel du robot Détection à 360° Robot dans le champs d’un autre n’implique pas forcément que les mouvements soient détectés interférence Dans l’état actuel, extension à trois robots impossible