Teleguide2011-1 : Différence entre versions
(→Principe) |
(→Idée d'amélioration du guidage par wifi) |
||
Ligne 24 : | Ligne 24 : | ||
== Idée d'amélioration du guidage par wifi == | == Idée d'amélioration du guidage par wifi == | ||
+ | [[Image:LancieriMaurice4.JPG|le prototype est bien avancé...|200px|thumb]] | ||
Plutôt que de récupérer les ordres de direction lorsque l'on clique sur la page web du robot, on peut les récupérer via un joystick raccordé à une machine qui enverra les ordres a la foxboard par wifi. Le guidage sera ainsi plus intuitif (et plus rigolo...). | Plutôt que de récupérer les ordres de direction lorsque l'on clique sur la page web du robot, on peut les récupérer via un joystick raccordé à une machine qui enverra les ordres a la foxboard par wifi. Le guidage sera ainsi plus intuitif (et plus rigolo...). | ||
=== Principe === | === Principe === | ||
− | |||
* Un programme client récupère les informations d'une manette de jeu (état des axes, hats et boutons) et les convertit en ordres simples (avancer/tourner à telle vitesse). | * Un programme client récupère les informations d'une manette de jeu (état des axes, hats et boutons) et les convertit en ordres simples (avancer/tourner à telle vitesse). | ||
* Le programme client envoie les ordres via un protocole textuel simple à un programme serveur tournant sur la foxboard. | * Le programme client envoie les ordres via un protocole textuel simple à un programme serveur tournant sur la foxboard. |
Version du 10 mai 2012 à 11:41
Sommaire
Robot téléguidé 1, le Gros Tony
Étudiants: Jean-Dominique Lancieri et Thomas Maurice.
1ère étape, construction du robot
Pour construire le robot, nous avons d'abord essayé de suivre les instructions du manuel Lego fourni, mais plusieurs problèmes d'érgonomie sont assez vite apparus, comme par exemple la non utilisation d'un moteur et l'espace insuffisant entre les moteurs restants pour intercaler les capteurs de luminosité et de puces RFID. Nous avons donc décidé de développer notre propre châssis plus large que celui de base, pour éviter de trop élever le robot par la suite en ajoutant des composants, afin de conserver un assez bon équilibre.
Idée d'amélioration du guidage par wifi
Plutôt que de récupérer les ordres de direction lorsque l'on clique sur la page web du robot, on peut les récupérer via un joystick raccordé à une machine qui enverra les ordres a la foxboard par wifi. Le guidage sera ainsi plus intuitif (et plus rigolo...).
Principe
- Un programme client récupère les informations d'une manette de jeu (état des axes, hats et boutons) et les convertit en ordres simples (avancer/tourner à telle vitesse).
- Le programme client envoie les ordres via un protocole textuel simple à un programme serveur tournant sur la foxboard.
- Le programme serveur envoi des ordres dans la "mailbox" du robot via bluetooth, en lui indiquant quelles actions effectuer (tourner un moteur,bipper...) et combien de temps.
(Programme client en C++ avec la SDL pour la gestion du joystick et programme serveur en C++ standard, partie réseau réalisée avec une petite lib réseau en C++ la libtsocket)
Seconde idée d'amélioration
Affin de s'affranchir totalement de l'utilisation nécessaire du wifi pour la direction du robot, il pourrait être intéressant de faire passer la communication entre le robot qui handle le joystick et la foxboard uniquement via bluetooth, à tester...
Programme
La libtsocket
La libtsocket est une petite bibliothèque réseau orientée objet développée par Thomas Maurice, elle est sous licence GNU/GPL. C'est en fait une surcouche orientée objet des sockets de la STL. Elle a pour but de permettre de développer rapidement des petites applications réseau en ne se préoccupant pas de la partie manipulation des sockets qui est assez lourde à l'usage. La libtsocket inclue aussi la possibilité de se connecter en SSL (sans toutefois pouvoir effectuer de vérifications sur les certificats, versions de protocoles etc...) de manière assez simple. La bibliothèque est codée en C++ standard et est portable sous Linux et Windows (OSX non testé), elle se compose de 3 classes simples :
- Server_socket qui définit une socket serveur
- Client_socket qui définit une socket client
- Connected_socket qui définit une socket connectée (récupérée par) une socket serveur. Elle s'utilise exactement comme une Client_socket (elles héritent toute deux de la classe mère Abstract_socket)
Server_socket
Cette classe définit une socket serveur. Elle se déclare simplement :
Server_socket(int port); // Pour une utilisation simple Server_socket(int port, int type, bool use_ssl, std::string cfile, std::string kfile); // Pour SSL
On bind la socket au port choisi avec :
int Server_socket::connect_socket(); // qui renvoie 0 si tout est glop, -1 si pas glop
On peut ensuite récupérer les éventuelles connexions entrantes avec :
std::vector<Connected_socket> Server_socket::get_pending();
Le vector étant de longueur nulle si personne ne tente de se connecter.
On peut ensuite asser à la manipulation des sockets récupérées par le biais de la classe Connected_socket.
Connected_socket
Cette classe permet de gérer les connexions entrant sur une Server_socket. Le constructeur n'a pas besoin d'être explicité (on construit la socket en lui passant le file descriptor qui va bien et les éventuels paramètres de contexte SSL) car géré par le Server_socket. Les fonctions intéressantes de cette classe sont les suivantes pour la préparation à la lecture :
bool Connected_socket::can_getline() // Si une ligne a été reçue (pour les protocoles en mode texte // à la IRC, HTTP, ou juste Telnet. bool Connected_socket::can_getchar() // Pareil mais avec un char. bool Connected_socket::can_getchars() // Pareil mais avec plusieurs chars (octets pour les protocole binaires).
Ensuite pour la lecture :
std::string getline(); // Récupère la dernière ligne (en ancienneté) su buffer et l'efface std::vector<char> getchars(); // Récupère les octets du buffer et les efface std::string getchars_as_string(); // Récupère les octets du buffer en tant que chaine char getchar(); // Récupère le plus vieux caractère du buffer et l'efface
Puis pour l'écriture :
int Connected_socket::write(std::string data) // Écrit une chaîne int Connected_socket::write(char c) // Écrit un octet int Connected_socket::write_line(std::string data) // Écrit une chaîne plus un retour chariot \n
Enfin quelques accesseurs :
std::string Connected_socket::get_host() // Renvoi l'IP int Connected_socket::get_port() // Renvoi le port bool Connected_socket::is_connected() // Renvoi si la socket est connectée, en cas d'erreur // de lecture ou d'écriture la socket sera considérée comme // fermée.
Et les classiques opérateurs de comparaison == et != (qui portent sur l'host et le port de la socket) Enfin, on ferme la socket en appelant la méthode :
Connected_socket::close_socket() // tadadaaaaaaaaam
Client_socket
Cette classe représente une socket client. Elle se déclare simplement :
Client_socket::Client_socket(std::string p_host, int p_port, bool use_ssl = false)
On la connecte ainsi :
Client_socket::connect_socket()
Et la ferme ainsi :
Client_socket::close_socket()
Les fonctions de lecture, écriture, accesseurs et mutateurs sont les mêmes que pour la classe Connected_socket()
Le programme mstormjoystick
Codé en C++ en utilisant la SDL et la libtsocket, le programme permet de récupérer les événements du joystick (inclinaison des axes, boutons, appui sur les hats (flèches directionnelles situées en haut a gauche sur une manette type PS2)) et les converti en ordres numériques (en fait une chaîne de nombres qui du type "05 456 -123" par exemple qui contient les informations de mouvement pour le robot). Ces informations sont envoyées via le réseau à un autre programme, le programme joystick-server.
Le programme joystick-server
Codé en C++ également, il utilise la libtsocket. Le programme reçoit les chaines du mstormjoystick via un protocole textuel ("protocole" est un bien grand mot, en fait mstormjoystick se contente de balancer les lignes d'ordres séparées par un retour à la ligne). Le serveur analyse la chaine :
- Si l'ordre est entre 0 et 6, alors c'est un ordre avancer/reculer/stop/droite/gauche et il est posté dans la boite 3
- Si c'est un ordre 5 on récupère les valeurs des moteurs et on les place dans les boites 5 et 6
Connexion de mstormjoystick à joystick-server
Pour diminuer les risques de détournement du robot par une force extraterrestre, le serveur va demander un mot de passe de connexion au client, via la commande IDENT. Le mot de passe est connu a l'avance et est passé comme paramètre aux deux programmes via l'option --key. L'échange se fait comme il suit (">" est une commande du client et "<" une du serveur.
> IDENT mot_de_passe < IDENT_OK
Si le mot de passe est bon, le client commence ensuite à envoyer ses commanes. Si le mot de passe est faux, le serveur envoi :
< IDENT_FAIL
Et ferme la connexion.
Problèmes rencontrés
Mécaniques
Pour des raisons mécaniques, il arrive que la trajectoire du robot soit parfois biaisée. Ce défaut peut cependant être corrigé en adaptant un peu la direction du joystick. Nous avons du également amélioré la structure du robot, en la renforçant, pour éviter le flambage. Une amélioration serait possible, en utilisant la boussole du robot, et en gardant le cap pour aller tout droit.
Réseaux
Nous avons eu quelques problèmes mineurs de connexions, notamment par rapport au bluetooth. Rien d'insurmontable, les solutions sont abordées plus haut, dans le man du programme joystick-server.
Programmation
Une des tâches les plus prenantes consiste à programmer le robot en nxc. Les difficultés ont été rencontrées à l'interface entre les senseurs, moteurs et le programme, parfois. Il a notamment fallu tester et afficher les valeurs recueillies par le robot, afin d'adapter les algorithmes. Les documentations disponibles permettent de s'en sortir, et même parfois de faire jouer la marche turque à tony.
Documentation
Page man du programme mstormjoystick
mstormjoystick(1) Joystick Mindstorm controller mstormjoystick(1) NAME mstormjoystick - Logiciel de contrôle du robot Lego Mindstorm via le réseau. SYNOPSIS mstormjoystick --host host --port port --key key DESCRIPTION Ce programme permet de communiquer avec le serveur joystick-server et de ce fait de contrôler le robot Lego Mindstorm qui est equipé du pro‐ gramme guidage.nxc. Ce programme est développé pour la manette de jeu Logitech RumblePad 2, il est donc possible qu'une autre manette provoque des comportements inattendus si elle est utilisée avec ce pro‐ gramme. Pour capter les évènements de la manette, le programme utilise la bibliothèque SDL, et pour communiquer à travers le réseau, il utilise la libtsocket une petite bibliothèque réseau orientée objet développée en C++. OPTIONS --host host Spécifie l'host de connexion --port port Spécifie le port de connexion --key pass Spécifie le pass de connexion UTILISATION Le programme se lance après avoir une manette configurée branchée à la machine, la manette sera automatiquement détectée (en théorie) et la connexion au serveur se fera automatiquement après la détection de la manette. Les contrôles sont simples : Les hats Permettent de contrôler le robot en lui indiquant un cap à tenir, en fait, si vous appuyez sur le hat haut/bas il suivra la direction indiquée. Si en revanche vous appuyez sur les côtés le robot tournera bêtement en rond. Les axes Permettent de diriger le robot en continu et non cap à cap comme avec les hats. Lors d'un déplacement en avant, il est possible de faire tirer le robot plus à droite ou plus à gauche pour cor‐ riger un éventuel défaut mécanique ou une inégalité du sol. C'est aussi possible avec l'arrière, on peut ainsi diriger plus finement lerobot. Les boutons Le bouton 9 est le bouton d'arrêt du programme, il doit être utilisé pour quitter le programme joystick. Le bouton 10 est le bouton d'arrêt du programme ET du serveur (hébergé sur la même machine ou sur la foxboard). Appuyer sur ce bouton causera l'arrêt des deux processus. Le bouton 5 permet de stopper le robot quand il est commandé par les hats,notez qu'une action sur le joystick produira le même effet. Le bouton 2 est un avertis‐ seur sonor, un genre de klaxon si le robot en a besoin. PROBLEMES CONNUS Parfois les contôles semblent inversés, c'est parce que la manette est passée pour une raison X ou Y en mode axes inversés, appuyez sur le bouton mode et tout devrait rentrer dans l'ordre. AUTEURS Thomas Maurice <thomas.maurice@polytech-lille.net> Jean-Dominique Lancieri <jean-dominique.lancieri@polytech-lille.net> Version 1.0 Thomas MAURICE - Mars 2012 mstormjoystick(1)
Page man du programme joystick-server
joystick-server(1) Joystick-server Mindstorm controller joystick-server(1) NAME joystick-server - Intermédiaire entre le robot Lego Mindstorm et la manette de jeu qui sert à le contrôler. SYNOPSIS joystick-server --port port --key key --target XX:XX:XX:XX:XX:XX DESCRIPTION Ce programme permet de faire le lien entre le programme joystick et le robot Lego Mindstorm équipé du programme guidage.nxc. Il transforme les commandes reçues par le logiciel joystick en ordres plus simples (chaines d'entiers) compréhensibles plus simplement par le robot. Pour communiquer avec le robot le programme utilise libbluetooth et une sur‐ couche fournie par les développeurs du NXC. Pour communiquer à travers le réseau, il utilise la libtsocket une petite bibliothèque réseau ori‐ entée objet développée en C++. OPTIONS --port port Spécifie le port d'écoute --key pass Spécifie le pass de connexion --target XX:XX:XX:XX:XX:XX Adresse MAC de la brique Lego Mindstorm UTILISATION Le programme se lance sur un ordinateur équipé d'une clef bluetooth ou bien de la foxboard qui est montée sur le robot. Le lancement n'est pas bien compliqué, il suffit de fournir les paramètres du programme au moment de taper la commande et c'est tout. PROBLEMES CONNUS La vitesse de transmission peut être lente si le programme est lancé depuis une foxboard, dû à la lenteur de son tout petit processeur. Pour obtenir un résultat optimal, sans aucun lag, il faut le lancer depuis une 'vraie' machine. MESSAGES D'ERREUR Endpoint not connected Le programme n'a pas réussi à s'appairer avec le robot, pour pallier à cela vous devez lancer 'bluetooth-agent 1234' et répondre positivement à la demande d'apairage qui s'affichera sur la brique. No route to host Le programme n'a pas pu initialiser le bluetooth. Soit la clé bluetooth du serveur n'est pas reconnue par le serveur, soit elle n'est pas connectée soit le robot n'est pas dans les par‐ ages avec son bluetooth activé. AUTEURS Thomas Maurice <thomas.maurice@polytech-lille.net> Jean-Dominique Lancieri <jean-dominique.lancieri@polytech-lille.net> Version 1.0 Thomas MAURICE - Mars 2012 joystick-server(1)