Dans le cadre du projet Cyclope, l'équipe du développement de l'application a comme tâche principale de créer un programme complet qui va gérer les demandes de l'utilisateur et les données recueillies par l'image caméra pour ensuite transmettre dles commandes au robot. Et ce, repectant la contrainte de l'utilisation du Web pour commander le robot.

2.0 Responsabilités

L'équipe de l'application a comme responsabilités :

• La gestion de la communication entre l'applet et l'application.
• La gestion de la communication entre l'application et le robot.
• Analyser les informations venant de l'imagerie.
• Déterminer les commandes à envoyer au robot, et les envoyer.

Respectant la contrainte de pouvoir être accessible par le web, l'application est divisée en deux parties soit un applet Java qui sera exécutée sur l'ordinateur client et une application Java qui roulera sur l'ordinateur serveur. Nous avons choisi le langage Java pour son intégration facile à l'internet et ses classes déjà faites permettant la communication client/serveur sur l'internet et la communication avec le port série.

3.2 L'applet client

De par l'applet tout peut-être controllé. On y retrouve un rectangle qui représente l'aire de déplacement du robot et où 1 pixel équivaut à 1 cm réel. De petits cercles représentent les cibles, de gros représentent les obstacles et on y retrouve aussi le robot avec son orientation. Des boutons permettent de faire avancer ou reculer le robot sur une distance que l'on choisie et il en va de même pour tourner. Ensuite, un bouton peut abaisser ou relèver la gratte, un autre demande l'identification de la pièce et un dernier permet de ramasser la pièce que ce soit pour la transporter ailleur où la déplacer du chemin.

Globalement, le rôle de l'application serveur est d'abord d'attendre la connexion de l'applet client. Ensuite elle attend des ordres de l'applet que ce soit pour une analyse du terrain, un déplacement ou l'identification de la pièce. Elle envoit ensuite ces ordres au robot par le port série du serveur qui lui est relié au modules RF de communication avec le robot. À son tour, le robot peut renvoyer le temps d'exécution d'une commande avance ou la valeure de la pièce identifiée au serveur qui lui l'envoie directement à l'applet.

Lorsqu'une analyse du terrain est demandée, le travail consite à analyser le fichier généré par l'application de traitement d'image. On y retrouve les coordonnées du robot ainsi que son orientation puis les coordonnées des cibles et des obstacles. Ces informations sont donc traitées puis envoyées à l'applet qui place graphiquement ces objets à l'écran et on obtient ainsi un équivalent de l'aire de déplacement du robot mais sur l'applet client qui lui n'est pas nécessairement dans la même pièce que le robot.

3.4 La communication client-serveur

Nous utilisons des objets Socket "TCP/IP" de la classe java.net de la librairie Java. Ces objets permettent d'envoyer très facilement dans les deux sens des chaînes de caractères. Par contre, la sécurité de tels liens de communication n'est pas très élevée et c'est pourquoi ce lien entre l'applet et l'application n'est pas supporté par tous les navigateurs. Il existe des moyens pour contourner ces sécurités comme par exemple d'utiliser un proxy ou de faire "signer électroniquement" par Sun notre Applet. Mais, après avoir passé déjà plus de temps que prévu sur cette section, nous avons choisi d'utiliser l'ApletViewer fournie gratuitement par Sun dans son "Java Developper Kit". Cette application qui est appellée dans une fenêtre DOS a beaucoup moins de sécurité à ce même niveau et par conséquent notre applet fonctionne parfaitement et il est possible de contrôler notre robot par le Web comme il l'était exigé. Il suffit de dire à l'applet le numéro d' IP de la machine serveur ainsi que le numéro du port sur lequel le programme serveur écoute.

3.5 L'algorithme de déplacement

Le principe choisi est d'utiliser une approche que nous appellons de l'élastique. En premier lieu une ligne est tracée entre le point de départ du robot et la cible. Ensuite, tout dépendant des obstacles sur le chemin, cette ligne est étirée d'un côté ou de l'autre pour éviter ces obstacles.

Nous nous étions gardé cette partie du projet pour la fin histoire de s'assurer d'abord que le mode de contrôle manuel fonctionnait parfaitement. Nous avons donc malheureusement manqué de temps et avons choisi de ne pas faire de mode de déplacement automatique.

3.6 La consommation énergétique

Lorsqu'une commande avance est envoyée au robot, une fois complétée, celui-ci renvoit le temps que cette commande a pris à l'application. Ensuite, avec cette donnée et la distance qui avait été demandée, on peut comparer ces chiffres avec un test fait en utilisant une batterie à pleine capacité.

Malheureusement nous avons manqué de temps pour écrire la fonction sur le robot qui devait chronométrer le temps que prenait la commande avance. Par contre, tout le reste fonctionne soit que lorsque le serveur envoit la commande avance, aussitôt terminée, il reçoit une valeur donc toute le reste de la structure est fonctionnel.

---

[ Application ]   [ Communication ]   [ Imagerie ]   [ Robot ]

	Retour en arrière