• Code source des routines
 
 
 
 

Dans ce qui suit, vous trouverez le compte-rendu du développement de l'interface usager (UBINTERFACE) ainsi que les différents algorithmes nécessaires au contrôle de notre robot UBICOP.
 

La somme de travail effectuée à chaque semaine correspond à environ 6h par personne, pour un grand total de 180 heures. De plus, des réunions hebdomadaires ont eux lieu, d’une durée moyenne de deux heures par semaine.
 

La matrice d'obstacles représente le terrain de 5 m par 5 m que nous avons divisé en carreaux. La grandeur des carreaux peut être changée facilement dans le programme. Nous avons choisi cette grandeur en fonction de la précision que nous avons pour la position du robot et pour le positionnement des obstacles.  La taille optimum des carreaux est de 50 cm par 50 cm, ce qui est un bon compromis entre la précision du positionnement spatial et l’exactitude des déplacements.

 La matrice contient la position des obstacles physiques ainsi que les obstacles virtuels que nous pouvons ajouter à partir de 'interface. Chacun de ces deux types d’obstacles possède son propre code dans la matrice de façon à ce que l’on puisse les différencier dans la matrice. Sur l'interface, les obstacles virtuels sont représentés par des carrés noirs et les obstacles réels, par des carrés verts. Pour faciliter le traitement dans les algorithmes, nous simulons un obstacle autour de la matrice afin que le robot ne sorte pas du terrain. De plus, pour éviter que le robot passe trop près des obstacles, nous avons ajouté une zone grise autour de chaque obstacle.
 
 

 Le positionnement des obstacles physiques est possible grâce à l’information transmit par le robot. Les routines de contrôle implantées dans le robot vérifient à chaque cycle si un obstacle lui fait face. Si c’est le cas, l’information nécessaire est aussitôt envoyée à l’interface via le lien série. Ainsi, nous pouvons vérifier dans la matrice s'il y a un obstacle ou non et faire les ajustements nécessaires.

Le robot utilise deux types de détection. Le premier est réalisé par les infrarouges qui permettent de voir les obstacles à tance(environ 30 cm). Le deuxième type est les représenté par les détecteurs de collision du robot. Dans les deux cas, il est possible de savoir si l'obstacle est à gauche, à droite ou au centre et il est ajouté en conséquence dans la matrice d'obstacle.
 
 

Pour notre programme d’application, nous effectuons le contrôle du lien série avec un objet de la classe CSerialPort. À l’ouverture de l’application, le port série est ouvert. Il est possible de modifier la configuration de la communication série comme le montre la
figure#2. En fait, les seuls paramètres qui nous sont utile de modifier est l’identification du COM et la vitesse de transmission. En effet, chaque station de travail sur lesquelles nous avons travaillé n’utilise pas nécessairement le même COM, donc la possibilité de modifier ce paramètre nous à été fort utile. Pour ce qui est de la vitesse de transmission, l’équipe qui s’occupe de créer le lien série sans fils n’était pas en mesure de nous dire quelles seraient les vitesses supportées par ce module, donc nous avons conservé la possibilité de modifier ce paramètre. Les autres paramètres sont fixés car on sait que le robot communique toujours sur son port série avec la même configuration.
 

Pour nous aider à calculer la distance, nous avons associé à un   déplacement horizontal et vertical une valeur de 1 et à un déplacement en  diagonal une valeur de 1.4 (les déplacements diagonaux sont plus longs). 

Après avoir terminé le traitement avec le premier carreau, on prend un élément du monceau, qui est en fait une de nos structures. On a donc la position d'un carreau. Pour ce carreau, on vérifie tous les carreaux autours de celui-ci. Pour chaque carreau, on vérifie si celui-ci  n'est pas occupé par un obstacle, et on vérifie aussi si le chemin pour se rendre à ce carreau n'a pas déjà été trouvé en regardant dans la matrice de chemins. Si ce n'est pas le cas, on indique la direction dans la matrice de chemins. On met la position de ce carreau dans une nouvelle structure et on additionne 1 ou 1.4 (dépendant de la direction) à la variable Distance du carreau d'avant. On met ensuite, cette structure dans le monceau.

On répète ceci jusqu'à ce que l'on arrive au point d'arrivé ou jusqu'à ce que le monceau soit vide. Si le monceau est vide, c'est qu'il n'y a pas de chemin possible. Si l'on arrive au point d'arrivée, nous pouvons être certains que le chemin est le plus court possible, car le monceau retourne toujours la distance minimum pour arriver à un carreau.

 Ensuite, pour trouver le chemin à suivre, nous n'avons qu'à commencer à partir de la position d'arrivée dans la matrice de chemins et suivre la direction inverse qu'indique le code de direction.
 
 

Une autre solution, celle que nous avons adoptée, est de calculer dynamiquement la direction du robot au fur et à mesure que celui-ci se déplace. En effet, nous recalculons la position du robot ainsi que sa direction à chaque fois qu'il change de carreau dans la matrice. Donc, le robot va pouvoir effectuer les modifications nécessaires s'il y a des perturbations extérieures qui le font dévier de sa trajectoire (ex : une roue qui tourne dans le vide).

 La figure #7 montre le diagramme du fonctionnement de l'algorithme qui s'occupe de diriger le robot. 
 

• Affichage en temps réel de la position du robot, de sa destination et du chemin qu’il doit suivre ;
• Affichage de la position du contrevenant ;
• Affichage de l’information reçue et transmise sur le port série ;
• Affichage de la tension des batteries ;
• Affichage de la vitesse de chaque roue du robot.

• Sélection de la position virtuelle du robot (pour fin de test) ;
• Sélection de la destination ;
• Sélection de la position du contrevenant ;
• Démarrage/arrêt de la simulation virtuelle ;
• Démarrage/ arrêt de la simulation en temps réels ;
• Vérification de l’état du port série ;
• Suppression des obstacles virtuels/réels de l’environnement du robot.
 

Il est également possible de configurer le port série grâce à une boite de dialogue (voir figure #2) qui affiche les paramètres, tel que mentionné dans la section Communication série.
 
 
 

Comme vous avez pu le constater, ce groupe à construit l'interface et les algorithmes en supposant que les autres parties du projet marcheraient plus ou moins. En effet, l'interface permet de mettre des obstacles virtuels au cas où la détection d'obstacle ne marcherait pas. Les grosseurs des carreaux de la matrice peuvent varier selon la précision du positionnement. Une vérification du positionnement est faite par l'interface pour s'assurer que la position du robot est réaliste. L'orientation du robot est vérifiée à chaque fois qu'il change de carreau dans la matrice. Le trajet optimal est recalculé périodiquement pour contrer les influences extérieures qui pourrait faire dévier le robot. Ce n'est pas par manque de confiance auprès des autres groupes que nous avons agit ainsi, mais pour facilité l'intégration des différentes partie.
 
 
 

Malheureusement, les résultats obtenus sont loin d'être ceux escomptés. Le robot à de grandes difficultés à suivre le chemin optimum. Cela s'explique par le fait que le délai entre l'envoie des vitesses et l’exécution de la commande par le robot est trop long. Il faut environ deux secondes pour le robot pour trouver sa position. Durant ce temps, il avance de beaucoup et lorsqu’on lui envoi une commande, elle est pour ainsi dire, désuète. Donc, le robot tourne soit trop loin, soit trop longtemps et il tourne donc autour de l'obstacle. Cependant, il fini souvent par atteindre son but, ce qui est le principal.

De plus, nous avions de la difficulté à faire tourner le robot sur lui-même. On voulait une fonction qui fait tourner le robot d'environ 180 degrés mais le robot n'était vraiment pas assez précis (les encodeurs ne marchaient pas bien) et il ne tournait jamais du même angle.

Le temps est le plus grand facteur qui a joué contre nous. Notre algorithme du chemin optimum fonctionne très bien et le positionnement aussi. Avoir eu plus de temps, nous aurions pu améliorer de beaucoup la trajectoire suivit par le robot. Nous aurions pu aussi inclure l'odométrie pour contrer l'effet du délai dans le calcul de la position par le robot.
 
 
 

Pour ce qui est des autres exigences, tels que la détection des collisions et la détection des obstacles, les résultats sont très ppréciables. Le robot détecte bien les obstacles et lors d’une collision, il passe en marche arrière, recule d’une courte distance et peut ainsi continuer son chemin en évitant l’obstacle détecté. L’affichage de la tension des batteries n’a pas été réalisé, mais l’interface dispose d’un mécanisme prévu à cet effet.

Le projet en est donc encore à l’étape du prototype. Plusieurs possibilités sont envisagées pour remédier aux divers problèmes mentionnés précédemment, mais l’échéancier ne nous permet pas de continuer le développement.

Néanmoins, le logiciel d’application est disponible dans la section téléchargement, et est totalement opérationnel.
Adressez vos commentaires, questions ou autres, à un des deux responsables de la section Interface usager :

Sébastien Pouliot : poulio00@gel.ulaval.ca
Pierre Martin-Dumont : martin01@gel.ulaval.ca