Télécharger la présentation
La présentation est en train de télécharger. S'il vous plaît, attendez
1
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
2
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
3
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
4
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
5
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
6
Description de l’algorithme de formation de cercle (2)
Triangle isocèle
7
Description de l’algorithme de formation de cercle (3)
Triangle scalène (quelconque)
8
Implémentation
9
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
10
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)
11
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
12
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: Tableau: > > > > > > La précision n’est pas jugée suffisante, l’algorithme continue
13
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
14
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
15
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
16
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
17
Démonstration // serveur try { sock.accept(); msg = sock.rcv();
} catch (IOExcept e) { e.show(); } // client sock.connect(); sock.send(BLUE);
18
Implémentation de l’algorithme de mise en cercle
Problème de précision du sonar Démonstration
19
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
Présentations similaires
