1) But
Pour le contrôle du robot, nous avions les objectifs suivants:
1) Être en mesure de déplacer le robot avec le plus de précision possible.
2) Être en mesure de communiquer au robot les commandes qu'il doit effectuer.
3) Être en mesure de saisir les cibles au moyen d'un électro-aimant.
4) Être en mesure d'observer l'état des piles pour détecter un besoin de recharge.

2) Réalisation du projet
A- Déplacement du robot
L'objectif de cette section est de développer du code qui permet de déplacer le robot le plus précisément possible. Ce code doit être suffisamment flexible pour permettre à l'application principale de guider le robot vers les cibles visées et de corriger des imprécisions à ce niveau lorsque nécessaire.
Les premiers tests nous ont permis de constater que le robot ne se dirigeait pas tout droit. Après avoir étudié les fonctions fournies avec le robot, nous avons découvert qu'il y avait des paramètres à ajuster afin de palier à ce problème. Nous avons aussi remarqué que les fonctions de déplacement étaient très peu précises. Il était impossible d'obtenir un déplacement constant du robot avec des paramètres identiques. En continuant les tests, nous nous sommes aperçus que les fonctions qui permettent de calculer la rotation des moteurs ne donnaient pas les mêmes résultats. Il y a une fonction pour chaque roue qui doit nous retourner la rotation que son moteur respectif a effectuée. En fait, les deux fonctions ne sont pas implantées de la même façon, et avec des tests assez simples, nous avons observé qu'avec un des deux moteurs, les résultats sont erronés( ils ne donnent jamais une représentation exacte de la rotation du moteur). Nous avons ajusté les fonctions de déplacement en conséquence et nous utilisons seulement la fonction d'un moteur en supposant que l'autre moteur suit correctement. Avec des tests simples, il est possible d'avoir de bons résultats au niveau de l'évaluation de la rotation des moteurs. Par contre, nous n'avons toujours pas réussi à faire avancer les moteurs d'une rotation précise et constante.
Nous avons développé des fonctions de déplacement relativement fiables et les résultats sont acceptables. Pour palier aux problèmes de précision, nous avons ajouté des fonctions de déplacement qui exécutent de petits incréments permettant d'ajuster la position du robot (de l'ordre du centimètre). De cette façon, l'application pourra guider le robot et corriger les imprécisions de ses déplacements. Nous avons fait quelques tests avec ces fonctions, et, en guidant le robot, nous arrivons à le positionner sur une cible à quelques centimètres près.

B- Communication avec le robot
Afin de pouvoir assurer une communication fiable avec le robot, un protocole a été conçu pour gérer tout envoi ou réception de données ou de commandes entre l'application hôte et le robot. Le design de ce protocole a été fait afin de lui assurer une robustesse à toute épreuve afin de contrer les erreurs qui pourraient s'introduire dans le processus de communication sans fil. Comme simplicité et souplesse vont de paire avec la robustesse, il a été décidé de ne pas inutilement imposer de limites à notre protocole afin de lui permettre de s'adapter à toute nouvelle condition.

I- Concept général
Le protocole a été bâti sur une base client-serveur. L'ordinateur hôte est défini comme le client et le robot est en quelque sorte le serveur. Le robot attend donc une connexion via le port série et l'ordinateur tente de se connecter à celui-ci.
Une fois la connexion établie, il est possible d'envoyer des requêtes au robot afin qu'il exécute certaines actions. Le robot doit donc constamment vérifier s'il a reçu des données sur le port série et réagir en conséquence lorsqu'il décode un paquet valide.
II- Encapsulation
Le protocole a d'abord été conçu sur deux ordinateurs sous la plate-forme Windows NT. De cette façon, il a été possible de tester plus facilement les premières versions du protocole. Cette façon de procéder a permis d'introduire plusieurs niveaux d'abstractions dans notre protocole afin d'avoir peu de choses à modifier lors de l'implantation du protocole sur le robot.

Donc, lors de l'intégration du protocole avec le robot, il fut possible de faire marcher ce module sans avoir à réécrire d'autre code que celui qui s'occupe des entrée-sorties sur le port série.
De plus, s'il y a une modification à apporter au protocole, il sera possible de la faire de façon globale, sans avoir à se soucier de modifier à la fois le code du robot et celui de l'ordinateur hôte.
III- Paquets
La base de notre protocole de communication est un paquet de 8 bytes. Il est divisé en 4 parties, soit l'entête (header), la commande à exécuter ainsi que deux champs de 8 bits pour les paramètres.
Voici le contenu de l'entête d'un paquet type du protocole Robocomm:


Le paquet lui-même est ainsi constitué:

Le premier octet de l'entête est simplement un caractère qui permet d'identifier si les données reçues font partie d'un paquet de notre protocole. Il permet ainsi de distinguer un paquet d'un octet de négociation.
Chaque paquet comprend la longueur de celui-ci, ce qui serait utile dans le cas où nous voudrions ajouter un troisième paramètre ou changer la longueur du paquet pour quelque raison que ce soit.
Les paramètres rx_id et tx_id de l'entête servent à identifier l'hôte et le robot à l'aide de numéros. Ainsi il serait possible de contrôler plusieurs robots avec le même ordinateur hôte et de les faire collaborer entre eux pour accomplir différentes tâches.
La vérification de checksum sera effectuée avec l'algorithme CRC-32, qui permettra de mieux identifier les erreurs de transmission qui pourraient se glisser à cause des interférences radio.
Nous avons déterminé que deux paramètres seraient amplement suffisants pour répondre aux requêtes de l'ordinateur hôte.
IV- Contrôle du protocole
Voici un schéma représentant la logique du protocole

Avec ce protocole, nous avons obtenu des résultats impeccables. Cependant, il y eux plusieurs ajustements au niveau de la transmission des paquets de l'ordinateur hôte vers le robot car ce dernier est beaucoup moins rapide à recevoir les bytes qui arrivent sur le port série. De plus, il reçoit les bytes par une méthode de "polling" ce qui veut dire qu'il reçoit les bytes un par un et qu'il n'y a pas de méthode de stockage des bytes qui arrivent. C'est l'application du robot qui doit s'occuper de recevoir chaque byte qui arrive sur le port, sinon il le perd. Nous avons donc effectué les modifications suivantes au protocole:
-L'application de l'ordinateur attend un "acknowledge" après la transmission de chaque byte.
-Pour le dernier byte du paquet d'une commande, le acknowledge est envoyé seulement lorsque le robot a fini de l'exécuter.
Ces deux mesures permettent au robot de toujours être en état de recevoir les bytes qui proviennent de l'ordinateur. Avec ces changements et avec un canalde transmission sans erreur (avec un fil), la communication entre l'application de l'ordinateur et celui du robot est parfaite.
Avec la communication sans fil, il y avait encore quelques modifications à faire pour que tou fonctionne. D'abord, étant donné que les modules de communications ont un récepteur et un transmetteur, les bytes qui sont transmis sont aussitôt reçus par le module. Il fallait donc ajouter une lecture sur le port série après chaque écriture. De plus, puisque le robot doit lire le port série après avoir envoyé un acknowledge, il fallait ajouter un délai dans l'application de l'ordinateur entre la réception d'un acknowledge et la transmission du prochain byte, le temps que le robot puisse faire la lecture supplémentaire causée par les modules sans-fil.
De cette façon, la communication avec les modules de communication sans-fil est parfaite lorsqu'ils sont bien placés. Cependant, lorsque les modules produisent des erreurs de transmission, l'application de l'ordinateur et celui du robot n'arrivent pas à maintenir un lien et le contrôle sur le robot peut être perdu. Ceci est dû au fait que la détection d'erreurs n'est pas très élaborée et que les applications ne protègent pas tous les cas d'erreur.