ELE6207 : Commande des systèmes robotiques

Rapport final

Navigation d’un robot mobile dans un environnement

dynamique

par : Pierre-Yves Mailhot

Julien Beaudry

pour : Romano M. DeSantis

Hiver 2003

Résumé

Ce rapport se veut le résumé des travaux effectués dans le cadre du cours ELE6207 : Commande des systèmes robotiques, cours dans lequel il est possible de travailler sur un

C’est pourquoi un des problèmes

méthode, face à un environnement hautement dynamique,

projet personnel. Le projet présenté concerne donc la navigation d’un robot mobile dans un environnement dynamique. Ce projet s’inscrit dans les nombreux développements du Laboratoire de mécatronique du Département de génie électrique de l’École Polytechnique de Montréal. Ce laboratoire développe des robots mobiles capables de jouer au soccer de façon autonome. La principale source d’inspiration de ce projet provient de la compétition internationale RoboCup. Le jeu de soccer robotisé offre un environnement qui est hautement dynamique,

artiellement prédictible et partiellement contrôlé.pimportants auquel les développeurs doivent faire face est la navigation des robots dans cet environnement dynamique. L’objectif est de se déplacer le plus rapidement possible sur le terrain afin d’obtenir des stratégies de jeu efficaces. Cependant, il est également important de limiter les probabilités de collision avec les autres robots du terrain. Les collisions sont en effet indésirables, premièrement pour protéger certains systèmes mécaniques et électroniques plus fragiles (comme le disque dur miniature des robots), mais également pour respecter les règlements de la compétition RoboCup (règlements inspirés de ceux de la FIFA). Ainsi, au cours du dernier trimestre, une méthode de navigation a été développée afin

’atteindre cet objectif. Cette dutilise une approche réactive plutôt que prédictive. De plus, un modèle mathématique a été préconisé afin de simplifier la programmation de la méthode et de permettre des ajustements précis du comportement des robots (comportement qui pourra varier au cours d’un match). Plusieurs essais, en simulation et sur le système réel, ont permis d’ajuster et de valider la méthode développée. Suite au développement de cette méthode, des algorithmes de jeu ont pu être développés pour démontrer son utilité.

- 1 -

Remerciements

Nous aimerions tout d’abord remercier M. Richard Hurteau, professeur au Département de génie électrique et directeur du Laboratoire de mécatronique, sans qui les avancements présentés dans le présent rapport n’auraient jamais été possibles. M.Hurteau est en effet responsable de la mise sur pied de tout ce projet et il a d’ailleurs réussi à obtenir d’importants budgets afin d’équiper le laboratoire de matériel à la fine pointe de la technologie. Il est également inévitable de remercier l’Institut de recherche d’Hydro-Québec, en particulier quelques chercheurs du laboratoire de robotique, soient Michel Blain, instigateur de plusieurs initiatives dans le cadre du cours ELE3100 : Projets de génie électrique, Régis Houde, pour les précieux éléments logiciels qu’il a développés en lien avec le soccer robotisé, Jean Côté, pour son apport considérable aux éléments logiciels et à la librairie MICROB, et finalement Jean Lessard, chef d’unité, pour son support moral et financier à cette initiative. La librairie MICROB constitue un élément central du projet au niveau logiciel et c’est grâce à leur expertise que nous pouvons l’utiliser au meilleur de nos connaissances. Il serait bien maladroit de négliger le travail des nombreux étudiants qui ont effectué des projets de fin d’études au laboratoire. Ces projets, tous bien ciblés, ont réussi à faire avancer le savoir de l’équipe du laboratoire dans différents domaines jusqu’à présent peu étudiés. Par exemple, la vision artificielle étant un monde en soit, le travail acharné de Félix Duchesneau sur le système de vision global permet maintenant d’utiliser le système en temps réel et à des vitesses intéressantes, tout en se fiant à une information visuelle adéquate. Finalement, le groupe SAE Robotique est également en grande partie responsable des avancements effectués car ils ont partagé leur expertise dans le domaine de la robotique mobile, dont leurs importantes connaissances pratiques. C’est d’ailleurs un prototype développé au sein de ce groupe qui a servi de base de développement pour les robots footballeurs du Laboratoire de mécatronique.

- 2 -

Table des matières

Résumé............................................................................................................................... 1 Remerciements .................................................................................................................. 2 Table des matières............................................................................................................. 3 Table des figures ............................................................................................................... 4 1 Introduction............................................................................................................... 5 2 Présentation du Laboratoire de mécatronique ...................................................... 5

2.1 Source d’inspiration ............................................................................................ 5 2.2 Historique............................................................................................................ 6 2.3 Schéma général du système ................................................................................ 6 2.4 Robots footballeurs ............................................................................................. 7

2.4.1 Plate-forme électromécanique .................................................................... 7 2.4.2 Modélisation du robot ................................................................................. 9 2.4.3 Contrôle en vitesses .................................................................................. 10 2.4.4 Contrôle de haut niveau ............................................................................ 11

2.5 Système de vision ............................................................................................. 12 2.6 Architecture Clients/Serveurs ........................................................................... 15 2.7 Terrain de jeu .................................................................................................... 16

3 Élaboration de la solution ...................................................................................... 17 3.1 Approche réactive vs approche prédictive........................................................ 17 3.2 Méthode des champs de potentiel ..................................................................... 19 3.3 Méthode des champs de potentiel révisée......................................................... 23

4 Résultats expérimentaux ........................................................................................ 25 4.1 Simulation ......................................................................................................... 25 4.2 Système réel ...................................................................................................... 26

5 Applications de la solution ..................................................................................... 27 5.1 Algorithmes de jeu............................................................................................ 27

5.1.1 Gardien de but........................................................................................... 27 5.1.2 Attaquant................................................................................................... 29

5.2 Contrôle assisté ................................................................................................. 30 6 Discussion et recommandations............................................................................. 30 7 Développements futurs ........................................................................................... 31 8 Bibliographie ........................................................................................................... 33

- 3 -

Table des figures

Figure 1 : Schéma général du système de jeu de soccer robotisé.................................... 7 Figure 2 : Plate-forme du robot (modélisation 3D) ......................................................... 8 Figure 3 : Axe des roues motrices du robot footballeur .................................................. 8 Figure 4 : Modèle du robot et notations associées .......................................................... 9 Figure 5 : Schéma du contrôle en vitesse d’un moteur ................................................ 10 Figure 6 : Schéma-blocs de la carte de contrôle ESC629 ............................................. 10 Figure 7 : Architecture informatique du robot footballeur ............................................ 12 Figure 8 : Caméras du système de vision ...................................................................... 13 Figure 9 : Motif d’un robot footballeur vu du système de vision.................................. 14 Figure 10 : Couleurs utilisées pour différencier les 6 robots footballeurs .................. 14 Figure 11 : Système de vision robotique en fonction .................................................. 15 Figure 12 : Architecture Clients/Serveurs du système ................................................ 16 Figure 13 : Terrain de jeu et système de coordonnées ................................................ 17 Figure 14 : Exemple de situation de jeu ...................................................................... 18 Figure 15 : Schéma des forces impliquées dans la méthode des potentiels ................ 20 Figure 16 : Révision de la cible afin d’éviter les obstacles ......................................... 24 Figure 17 : Essai du système en simulation, algorithmes de jeu, 1m/s ....................... 26 Figure 18 : Positionnement du gardien en fonction de la trajectoire du ballon........... 28 Figure 19 : Séquence de positionnements du robot en rôle offensif ........................... 29

- 4 -

1 Introduction

La robotique est un domaine vaste où plusieurs champs de recherche sont impliqués. Que ce soit pour les systèmes de vision, les algorithmes de contrôle ou la coopération multi-robots, les développements technologiques s’accumulent constamment et permettent d’entrevoir de nouvelles possibilités pour les systèmes robotiques. Parmi ces nouvelles applications, nombreuses sont celles devant faire appel à des systèmes de navigation précis et robustes. En effet, les robots autonomes de demain seront appelés à évoluer dans des environnements dynamiques et non ou partiellement contrôlés. Afin d’être efficaces, ceux-ci devront être capables de reconnaître leur environnement et d’éviter les obstacles tout en poursuivant leur progression vers leur objectif dans le but ultime d’y effectuer une tâche quelconque. Le jeu de soccer robotisé est une application de la robotique qui, par son caractère ludique, soit jouer au soccer, exerce un attrait indéniable sur l’imaginaire de gens tout en permettant de mettre en application de nombreux développements reliés à la robotique. Un de ceux qui s’y prête le mieux est la navigation dans un environnement dynamique semi contrôlé. En effet, bien que le robot ne puisse rencontrer qu’une variété d’obstacles limitée, principalement les autres robots, ceux-ci sont mobiles et très difficilement prévisibles. Le jeu de soccer robotisé nous offre donc une plate-forme de développement pour des algorithmes de navigation dans un environnement en constante évolution. Ce rapport vise ainsi à présenter les travaux effectués par notre équipe dans la recherche d’un algorithme performant pouvant permettre aux robots d’évoluer efficacement sur le terrain tout en s’évitant l’un et l’autre.

2 Présentation du Laboratoire de mécatronique

2.1 Source d’inspiration

Ce projet s’inspire de la coupe du monde des robots footballeurs (RoboCup, www.robocup.org). Cette compétition internationale permet à des équipes de robots de différentes universités et même d’entreprises privées de s’affronter dans un tournoi qui a lieu chaque année dans différents coins de la planète. Différentes ligues permettent de spécifier des formats de terrain et de robots différents, dont la « Middle Size Robot League » qui sert de référence pour ce projet. Les origines de cette compétition remontent à 1992, mais la première compétition officielle n’a eu lieu qu’en 1997. Durant la dernière édition, qui a eu lieu en juin 2002 à Fukuoka au Japon, 117 300 visiteurs ont pu observer 188 équipes provenant de 29 pays différents.

- 5 -

2.2 Historique

Depuis 5 années déjà, à l’École Polytechnique de Montréal (ÉPM), le cours ELE3100 portant sur la robotique mobile et l’informatique amène des étudiant(e)s au baccalauréat en génie électrique à travailler sur la conception d’un robot footballeur, le développement de son contrôleur par simulation dynamique et le développement d’algorithmes de jeu pour participer à un tournoi. Parallèlement aux développements effectués pour ce cours, une plate-forme de robot modulaire et performant, le robot SpinoS, a été développée par une équipe du groupe SAE Robotique (http://step.polymtl.ca/~saerobot/) dans le but de participer à des compétitions étudiantes, mais également afin de servir de premier prototype pour un robot footballeur respectant les spécifications de la « Middle Size Robot League ». Les performances et la robustesse du système électromécanique, de l’électronique de contrôle et du logiciel du robot SpinoS ayant été jugées suffisamment appréciables, le professeur Richard Hurteau, du département de génie électrique de l’ÉPM, a entrepris d’utiliser cette plate-forme comme référence afin de développer le jeu de soccer robotisé du laboratoire de mécatronique. Ainsi, depuis près d’un an, des développements intenses ont lieu au sein du laboratoire de mécatronique dans le but d’obtenir deux équipes de trois robots mobiles capables de communiquer entre eux, de percevoir les différents éléments présents sur le terrain de soccer et finalement de jouer au soccer de façon entièrement autonome (sans intervention humaine).

2.3 Schéma général du système

De nombreuses composantes sont nécessaires au fonctionnement du système de jeu de soccer robotisé dans son ensemble. On compte parmi ces éléments les robots footballeurs, un système de vision robotique, un serveur de jeu et des liens de communication sans fil. La figure 1 ci-dessous schématise la disposition de ces différents éléments. D’autres éléments viennent compléter le système comme un visualisateur de scène 3D, un contrôleur de manette de jeu pour le contrôle en modes manuel et semi autonome. Les principaux éléments du système seront décrits dans les paragraphes qui suivent.

- 6 -

6 robots et terrain

2 caméras couleur

lien sans fil système de vision serveur de jeu

Figure 1 : Schéma général du système de jeu de soccer robotisé

2.4 Robots footballeurs

2.4.1 Plate-forme électromécanique

La configuration des robots footballeurs est une plate-forme à vitesses différentielles symétriques: 2 moteurs de propulsion et de direction couplés à deux roues motrices. Les roues motrices sont disposées au centre du robot et 2 roues libres assurant la stabilité sont disposées à l’avant et à l’arrière du robot. Le centre de masse se retrouve le plus près possible de l’axe des roues motrices. Les 2 figures qui suivent résument cette configuration.

- 7 -

- 8 -

Figure 2 : Plate-forme du robot (modélisation 3D)

Figure 3 : Axe des roues motrices du robot footballeur

Les principales qualités de la configuration à vitesses différentielles sont les suivantes :

• Simplicité de contrôle : la cinématique et la dynamique du robot sont très simples, facilitant le développement de contrôleurs haut niveau.

• Positionnement précis : le positionnement du robot par odométrie est relativement précis comparativement à d’autres configurations.

• Symétrie: la symétrie avant/arrière permet un contrôle plus évolué dans le cas où la mécanique et l’électronique seraient symétriques. Il est alors possible de créer un programme de contrôle qui tient compte de cette symétrie et qui est en mesure d’inverser son comportement lorsque nécessaire.

- 9 -

2.4.2 Modélisation du robot

Le modèle de simulation du robot footballeur permet de simuler le comportement du robot réel et donc de développer des algorithmes en simulation. Ce modèle est essentiel au développement du projet et il doit s’approcher le plus possible du modèle réel. Le modèle dynamique permet de générer les mouvements du robot suite à l’application de tensions à ses deux moteurs. Une fois ce modèle développé en C++ et intégré au logiciel de contrôle, il est possible de programmer les algorithmes de haut niveau, par exemple les algorithmes de jeu des robots footballeurs, et de les tester sur le simulateur. Lorsqu’un simulateur est suffisamment fidèle à la réalité, les résultats obtenus en simulation reflètent les résultats qui peuvent être prévus sur le robot réel. Le modèle de robot utilisé considère les hypothèses suivantes:

• Glissement latéral négligé: nous avons un robot à contraintes non holonomes et nous allons considérer que le glissement latéral est impossible.

• Roulis et tangage négligés: nous supposons que le centre de masse est suffisamment bas pour empêcher le roulis et le tangage du robot selon les accélérations que nous lui demandons.

• Centre de masse au milieu de l’axe des roues motrices: cette hypothèse permet de modéliser le robot comme un disque dont le centre est le centre de l’axe et dont la masse est uniformément répartie sur la surface de ce disque.

• Régime transitoire des moteurs négligé: le circuit équivalent des moteurs DC possède une constante de temps très faible comparativement à la constante de temps mécanique. Nous pouvons donc négliger le régime transitoire électrique.

Les modèles cinématique et dynamique utilisés sont ceux détaillés par Romano M. DeSantis dans [1]. Les notations utilisées sont résumées dans la figure qui suit :

Figure 4 : Modèle du robot et notations associées

2.4.3 Contrôle en vitesses

L’asservissement de chacun des deux moteurs est assuré par un circuit LM629 de National Semiconductor. Chaque contrôleur implémente une boucle PID numérique qui asservit chacun des moteurs à la trajectoire spécifiée. Dans notre cas, les moteurs sont asservis en vitesse et suivent un profil trapézoïdal défini par l’accélération maximale et la vitesse désirée. Le contrôleur est donc responsable de l’asservissement du moteur et de la génération du profil. Les deux figures qui suivent présentent la structure du contrôleur et du moteur, ainsi que le schéma blocs de la carte ESC629.

Figure 5 : Schéma du contrôle en vitesse d’un moteur

Figure 6 : Schéma blocs de la carte de contrôle ESC629

- 10 -

- 11 -

NOTE : Les documents ESC629_manual.pdf, esc629_user_guide.pdf et an-693.pdf expliquent les détails du LM629 et de la carte ESC629.

Le robot est donc en mesure d’asservir en vitesse chacun de ses deux moteurs, donc d’asservir les vitesses dans l’espace articulaire (ω B1B, ω B2 B). Par contre, au niveau du contrôle de haut niveau, il est beaucoup plus intéressant de commander les vitesses dans l’espace opérationnel (VBu B, ω). Les équations qui suivent permettent d’obtenir les vitesses dans l’espace articulaire à partir des vitesses de l’espace opérationnel :

a

u

R

lV 21

⋅−=

ωω ,

a

u

R

lV 22

⋅+=

ωω

2.4.4 Contrôle de haut niveau

Les caractéristiques désirées de la structure logicielle du robot sont la modularité, les possibilités d’évolution, l’efficacité et la robustesse. L’ordinateur embarqué performant dont nous disposons nous permet dans un premier temps d’éliminer plusieurs alternatives telles la programmation en assembleur ou autre langage de bas niveau. Il est évident que l’utilisation d’un système d’exploitation évolué et de langages de programmation de haut niveau permettent l’implantation d’un logiciel de contrôle complexe et modulaire. Le système d’exploitation utilisé sur les robots footballeurs est Debian Linux ( HTUhttp://www.debian.org/UTH) avec le noyau 2.4.18. L’ordonnanceur du système a été configuré pour fonctionner à 1kHz, ce qui donne des performances temps réel satisfaisantes. Le langage de programmation utilisé est le C++ La figure 7 présente la structure du logiciel de contrôle du robot footballeur. On y retrouve principalement 5 modules :

• Brain : se charge de prendre des décisions en fonction de l’état du robot et de son environnement. Par exemple, un attaquant, en fonction de sa position, de celles des autres joueurs et de celle du ballon, peut prendre des décisions semblables à « tirer au but », « effectuer une passe » ou encore « jouer un rôle défensif ». Plusieurs cerveaux différents ont été programmés jusqu’à présent pour répondre à des besoins divers. À l’heure actuelle, les seules actions que peut générer le cerveau sont les mouvements en vitesses dans l’espace opérationnel (vitesses rectiligne et angulaire). Toutefois, il le fait par l’entremise de la classe MotionControl en utilisant la méthode gotoxy(). Le cerveau décide donc de la cible à atteindre et la classe MotionControl se charge de le déplacer vers cette cible tout en évitant les obstacles. D’autres actions, comme celles reliées au module de contrôle du ballon, seront ajoutées prochainement.

• MotionControl : comme il vient d’être mentionné, ce module se charge principalement de déplacer le robot vers la cible désirée, à la vitesse de référence désirée, tout en évitant les obstacles du terrain. Ce module constitue en fait le projet effectué dans le cadre du cours ELE6207 : Commande des systèmes robotiques. Comme on peut le voir sur le schéma, le module détermine les vitesses désirées en fonction de la cible et des éléments du terrain.

- 12 -

• Controller : ce module a deux fonctions principales. La première est de convertir les vitesses désirées de l’espace opérationnel à l’espace articulaire et de transmettre ces vitesses désirées à la carte de contrôle. Sa deuxième fonction est de lire les valeurs des encodeurs optiques des moteurs, de déterminer les variations d’orientation de chacun des moteurs depuis la dernière lecture et de transmettre cette information au module Odometry.

• ESC629 : ce module est en fait la carte de contrôle des moteurs. Il ne constitue donc pas un module logiciel mais bien un module matériel. Toutefois, un pilote, développé par l’équipe du laboratoire, est nécessaire, afin d’assurer l’interface entre la carte et le reste du logiciel. Lorsque le logiciel est utilisé en simulation, ce module est remplacé par le modèle dynamique du robot.

• Odometry : ce module est responsable de prendre les informations provenant des encodeurs optiques (converties en mesures d’orientation par le module Controller) et de calculer les différentes valeurs numériques pertinentes de l’espace opérationnel, soient les coordonnées et vitesse généralisées. Ces données sont évidemment précieuses au module Brain.

MotionControl

Odometry

ESC629ControllerBrainX_des, Y_des Vd, dω

Vref

dd 2,1 ωω

2,1 encenc

2,1 θθ dd

ωθ ,,,, VuddYdX

remplacée par le modèledynamique en simulation

Figure 7 : Architecture informatique du robot footballeur

NOTE : Ce schéma présente les données principales qui sont échangées entre les modules. Bien sûr, beaucoup d’autres données, comme par exemple les informations du terrain, doivent être échangées.

2.5 Système de vision

L’objectif du système de vision est de mesurer la position des différents éléments mobiles du jeu de soccer (les robots et le ballon) et ce à la fréquence la plus élevée possible, le plus précisément possible et finalement de façon suffisamment robuste. Afin de couvrir le terrain en entier, le système doit utiliser deux caméras, chacune couvrant une moitié de terrain avec une zone de recouvrement commune aux deux caméras. La figure 8 présente les deux caméras telles que positionnées au-dessus du terrain de soccer au laboratoire.

- 13 -

Figure 8 : Caméras du système de vision

Pour déterminer la position des différents éléments, le système de vision procède en cinq étapes qui sont les suivantes :

• Binarisation de l’image : le système fait l'acquisition d'une image en couleurs, mais l’expérience démontre qu’il est plus robuste et beaucoup plus efficace de travailler avec une image binaire (noir et blanc seulement). Notre méthode utilise donc une image binaire pour la majorité des traitements. Cette binarisation s’effectue en ajustant la luminescence et le contraste de l’image puis en appliquant un seuil sur l’histogramme de l’image.

• Détection des régions blanches : dans l’image binarisée il est alors possible de trouver les différents amas de pixels blancs, que nous nommons régions. Un algorithme nous permet de trouver les différentes régions présentes dans l’image, d’en obtenir les dimensions et les positions.

• Classification des régions (positionnement des éléments): grâce aux dimensions des régions détectées, il est possible de les classifier en trois catégories : robots, ballon, rejet (bruit présent dans l’image). À la fin de cette étape, le système a donc identifié le ballon et les robots. Puisque le système connaît déjà la position des régions, la position des éléments est obtenue.

• Mesure de l’orientation des robots : la figure 9 présente le motif d’un robot vu du système de vision. Nous remarquons sur ce motif trois points noirs qui servent à déterminer l’orientation des robots. Deux de ces points forment un angle de 90 degrés avec le centre du robot et un produit scalaire est utilisé pour les trouver et ainsi déterminer l’orientation. Cette étape est en fait constituée de plusieurs étapes puisqu’il faut utiliser la même méthode de détection des régions, mais cette fois avec des régions noires à l’intérieur de la région blanche du robot.

- 14 -

Figure 9 : Motif d’un robot footballeur vu du système de vision

• Identification des robots : sur la figure 9 nous remarquons une zone colorée au

centre du robot. Cette zone colorée permet d’identifier les différents robots. L’image couleur acquise est séparée en trois couleurs primaires RGB (Red Green Blue). L’intensité de rouge et de bleu servent à différencier l’équipe. L’équipe 1 présente une intensité de 100% pour le niveau de bleu et de 0% pour le rouge. L’équipe 2 présente l’inverse. Ensuite, pour déterminer le numéro d’un joueur au sein d’une équipe, l’intensité du vert (0%, 50%, 100%) est utilisée. Les différences que nous obtenons sont présentées à la figure 10. Cette étape est la seule qui utilise l’image en couleurs.

Figure 10 : Couleurs utilisées pour différencier les 6 robots footballeurs

Voici donc les différentes étapes qui permettent au système de vision de positionner les différents éléments sur le terrain de soccer. Mentionnons qu’un calibrage selon la méthode de Tsaï est nécessaire afin de contrer l’effet de la déformation importante de la lentille de la caméra. La figure 11 présente l’interface développée et utilisée au laboratoire pour ajuster le système de vision et contrôler en temps réel son fonctionnement. On y voit cinq robots ainsi que le ballon positionnés correctement.

G = 0.0 G = 0.5 G =1.0

G = 0.0 G = 0.5 G =1.0

- 15 -

Figure 11 : Système de vision robotique en fonction

2.6 Architecture Clients/Serveurs

La figure 12 résume l’architecture Clients/Serveur utilisée par le simulateur tandis que la figure 2 présente le système tel que retrouvé au laboratoire. On y présente les modules suivants:

• pge0 à pge5: ces éléments correspondent aux six robots footballeurs constitués du logiciel de contrôle temps réel. Un robot, par le biais du service RobotInfoExchange, envoie ses informations d’odométrie au serveur et reçoit les informations du système de vision.

• pge_server: ce module constitue le serveur de jeu. Il permet de contrôler le déroulement d’un match et de transmettre les données d’un module à un autre.

• falcon: ce module constitue le système de vision (simulateur ou réel) utilisé au laboratoire. Ce module utilise le service FieldInfoExchange pour envoyer les données du système de vision et recevoir les données des robots et du match. La version simulateur simule la dynamique des éléments sur le terrain (collisions entre les robots, le ballon et les bandes), permet de contrôler le ballon et également de détecter les buts marqués. Cette version comporte également un serveur pour permettre à un client externe de contrôler le ballon (pour simuler des tirs au but!).

• sui: ce module est simplement la console client utilisée pour botter le ballon. • LookatSoccer: ce module constitue le visualisateur 3D du match. Il permet de

positionner sur le terrain les robots et le ballon et d’afficher quelques informations du match (pointage, pénalités, période et temps de la période).

falcon

pge_server

pge 0 pge 5. . .

LookatSoccersui

Légende:

: serveur

: client

BotterBallon

RobotInfoExchange

FieldInfoExchange

GameInfoGetTimeSTARTSTOP

Figure 12 : Architecture Clients/Serveurs du système

L’architecture présentée ici utilise la librairie C++ de contrôle de robots MICROB (http://www.robotique.ireq.ca/microb/fr/). Cette librairie, développée par des chercheurs de l’IREQ, offre de nombreux modules fort utiles dans différentes facettes d’un projet de robotique mobile. Dans ce projet, elle est principalement utilisée pour la communication interprocessus, le contrôle en temps réel ainsi que pour sa librairie mathématique.

2.7 Terrain de jeu

La figure suivante présente les caractéristiques du terrain de jeu du laboratoire ainsi que le système de coordonnées utilisé.

NOTE : Les dimensions utilisées, faute d’espace, ne sont pas conformes aux règles de la Middle-Size League, celles ci spécifiant que le terrain aura une longueur entre 8 et 12m et une largeur d’au moins 50% de la longueur.

- 16 -

Figure 13 : Terrain de jeu et système de coordonnées

3 Élaboration de la solution

3.1 Approche réactive vs approche prédictive

Dans le cadre du jeu de soccer robotisé, un des éléments les plus importants est de permettre une navigation fluide du robot sur le terrain. En effet, toutes les stratégies de jeu et la coopération multi agent seront influencées par la capacité du robot à se déplacer rapidement et de manière sécuritaire sur le terrain. Il est donc primordial de développer un algorithme qui permet aux robots d’évoluer efficacement dans un environnement dynamique et généralement imprévisible. Si de nombreuses techniques d’évitement d’obstacles ont été développées dans la littérature (par exemple les différentes techniques présentées dans [2]), presque toutes sont conçues pour s’appliquer à un environnement statique. Ces approches peuvent être considérées comme étant prédictives. Par contre, notre environnement est hautement dynamique car les robots évoluent sur le terrain à des vitesses relativement élevées. De plus, l’évolution des robots dans le temps est imprédictible, en particulier pour les robots de l’équipe adverse. Des techniques de prédiction pourraient être développées, mais elles demanderaient un effort considérable et

- 17 -

leur précision d’approximation est loin d’être assurée. La figure qui suit illustre une situation de jeu possible. On peut deviner que le fait de planifier précisément une trajectoire vers la cible est à toute fin pratique inutile puisque les mouvements des robots ne peuvent être précisément connus. C’est pourquoi il est préférable d’adopter une approche réactive qui tente dans un premier temps de planifier une trajectoire sur un horizon de temps très court et ensuite de réagir aux mouvements relatifs des objets environnants.

Figure 14 : Exemple de situation de jeu

Parmi les techniques utilisées pour éviter les collisions, nous pouvons distinguer deux grandes familles. Il y a les techniques qui s’appuient sur une quantité considérable de conditions logiques, les techniques heuristiques, et il y a les techniques avec une logique mathématique. Certains auteurs ont commencé à adapter ces techniques à un environnement dynamique. Après avoir fait un bref survol des méthodes utilisées par d’autres équipes ayant participé à la RoboCup, nous avons décidé de privilégier l’approche mathématique. Nous avons choisi cette approche car l’algorithme qui en découle se révèle beaucoup plus simple. En effet, cette technique est très générale alors que les méthodes heuristiques demandent un grand nombre de considérations pour des cas particuliers. Cela alourdit l’algorithme et rend la modification du comportement du robot beaucoup plus complexe en terme de programmation. À l’inverse, les méthodes mathématiques permettent de changer le comportement du robot à l’aide de quelques paramètres. Un algorithme plus léger permet aussi d’obtenir un temps de calcul plus rapide quoique dans notre cas, cet argument ne fût pas déterminant compte tenu des capacités informatiques des robots. De plus, en terme de performance, il nous était difficile de prévoir lequel donnerait le meilleur comportement. Néanmoins, par leur simplicité, les méthodes mathématiques nous semblaient offrir les meilleures possibilités.

- 18 -

3.2 Méthode des champs de potentiel

La stratégie adoptée s’inspire de la méthode de champs de potentiels, à la différence que nous nous évoluons dans un environnement dynamique. Nous nous sommes donc inspirés des champs de potentiels pour créer un algorithme simple qui détermine la trajectoire et la vitesse souhaitée pour chaque robot selon l’évolution de son environnement. Le principe de base derrière cette stratégie est le suivant : chaque élément sur le terrain exerce une force d’attraction ou de répulsion sur le robot considéré. C’est la résultante des forces qui donnent la direction et le module fournit une indication de la vitesse. La différence entre la direction souhaitée et l’orientation actuelle nous donne également une indication de la vitesse angulaire souhaitable. Adaptation de la méthode à notre cas Afin de pouvoir exercer un meilleur contrôle sur le comportement du robot et faciliter les ajustements, nous avons divisé les forces répulsives en plusieurs forces, chacune étant reliée à un composant spécifique. Nous avons donc divisé les forces de répulsion en trois composants : la force de répulsion due à la présence d’un autre robot, appelée force statique, la force de répulsion due à la variation de distance entre deux robots, appelée force dynamique, et finalement la force de répulsion due à la présence des bandes aux limites du terrain, appelée force des bandes. Quant à la force d’attraction, celle-ci se constitue uniquement de la force que la cible du robot exerce sur celui-ci. Un exemple des différentes forces en action est présentée à la figure 15. La force de mouvement, en bleu, s’exerce peu importe la distance qu’il y a entre le robot et sa cible. Elle est généralement plus grande que les autres forces. La force de répulsion statique, en jaune, est inversement proportionnelle à la distance. La force dynamique, en jaune également, varie selon la vitesse relative entre un robot et l’obstacle. Quant à la force de bande, en vert, elle a une composante dynamique et une composante statique semblables à celles décrites précédemment. L’orientation des forces se fait toujours en ligne droite avec le robot considéré et les autres robots ou la cible, la direction étant fournie selon que la force est attractive ou répulsive. La somme des forces nous permet d’obtenir une force résultante, présentée en rouge sur la figure, indiquant la direction et la vitesse recommandée. Fait à noter, la force dynamique peut exercer une force attractive partielle. C’est-à-dire qu’elle peut annuler une partie de la force statique exercée par un robot si le taux de variation de la distance tend à démontrer que le robot s’éloigne du robot considéré. Cela permet donc à un robot d’en suivre un autre à une vitesse intéressante. Néanmoins, cette force attractive dynamique est limitée afin d’empêcher qu’un robot ne soit attiré par un autre robot qui s’éloigne. Afin d’éviter que des forces de répulsion ne contribuent au mouvement, le champ de vision du robot dans lequel les forces sont considérées est limité. Nous observons donc dans champs de vision définie par les deux tiers seulement du cercle de 360 degrés entourant le robot. La zone considérée est donc le tiers d’un cercle, soit 120 degrés, de part et d’autre de la direction actuelle du robot. Cela évite qu’une force de répulsion incite un robot à avancer et ne compense pour des forces qui le ralentissent vers l’avant.

- 19 -

- 20 -

Figure 15 : Schéma des forces impliquées dans la méthode des potentiels

Nous allons maintenant voir en détails la formule pour chaque force. Composantes de la force résultante Dans notre code, la force d’attraction en X est définie ainsi :

( ) rbtK

desmouvement VAF θcos⋅⋅= L’équation de la force de mouvement a été définie de manière à prendre en compte la vitesse souhaitée (VBdes B) pour que le robot atteigne rapidement sa cible. Cette vitesse est normalement la vitesse maximum permise par la configuration du robot. Cette vitesse sera plus faible lorsque le robot est rendu à proximité de sa cible et qu’il a entrepris de freiner. Les coefficients A et K permettent de modifier la grandeur de la force de manière linéaire ou exponentielle. L’angle θBrbt B représente l’angle de la direction du robot avec le repère global situé au milieu du terrain. La force statique en X se définit ainsi :

Cette équation permet de prendre en compte la distance (dBobstacleB) entre un robot et son obstacle. La division par la distance du champ de vision permet de normaliser le

( ) rbtobsLobslookatobstacle

statiqueddBF _

_cosθ⋅=

Force de mouvement (+)

FFoorrcceess ddee rrééppuullssiioonn ddeess rroobboottss ((--)) ((ssttaattiiqquueess eett ddyynnaammiiqquueess))

FFoorrcceess ddee rrééppuullssiioonn ddeess bbaannddeess ((--)) ((ssttaattiiqquueess eett ddyynnaammiiqquueess))

FFoorrccee rrééssuullttaannttee ((++ oouu nnuullllee))

- 21 -

numérateur afin qu’il reste toujours dans un domaine entre zéro et un. L’angle utilisé est formé par la droite passant par le centre des deux robots et la composante X du repère global. Dans la même idée que pour la force de mouvement, les coefficients B et L permettent de modifier la force statique de manière exponentielle et linéaire. La force dynamique en X se définit ainsi :

L’objectif de la force dynamique est d’exercer une force de répulsion sur le robot lorsqu’un rapprochement est détecté, soit la variable VBobs_rbt B qui représente la vitesse relative entre les deux robots. Cette force est également influencée par la vitesse du robot considéré (VBtan B). En effet, si un robot se déplace à basse vitesse et se rapproche d’un autre robot roulant à haute vitesse, le ralentissement doit s’effectuer principalement chez le robot roulant à haute vitesse. L’objectif est d’éviter les collisions mais l’important est surtout d’éviter que nos robots en soient les responsables. On ne peut éviter toute collision si les robots adverses ne font pas preuve d’un minimum de prudence. Néanmoins, pour les tests en laboratoire et en simulation, cela ne sera pas un problème puisque tous les robots naviguent avec notre code! Finalement, le coefficient nous permet de faire varier linéairement la force dynamique. La composante en X de la force exercée par les bandes est définie ainsi :

L’objectif de cette force est de repousser le robot lorsque celui-ci s’approche des limites du terrain. Cette force est divisée en deux. Le premier segment implique la vitesse de rapprochement du robot avec la bande. À basse vitesse, cette composante sera faible et cela devrait avoir pour effet de permettre au robot de manœuvrer dans les coins à basse vitesse, notamment lorsqu’il voudrait récupérer le ballon. Pour ce qui est de l’autre segment, il implique la distance entre le robot et la limite du terrain. Plus le robot est proche de la bande, plus la force de répulsion est grande. Fait à noter, l’orientation du robot est pris en compte. Ainsi, si le robot avance en parallèle avec la bande, il ne sera pas repoussé par celle-ci. La multiplication par le nombre d’obstacles de la force permet de faire varier en temps réel l’ordre de grandeur de la force de bande pour qu’elle tienne compte de la présence de nombreux robots. En effet, si un robot détecte plusieurs autres robots dans son champ de vision et que lui-même est proche de la bande, il est souhaitable que la force de répulsion exercée par cette bande soit plus grande afin d’éviter qu’une accumulation de forces statiques et dynamiques ne pousse le robot sur la bande. Suivant la même idée que pour les autres forces, le coefficient E permet de varier

rbtobsrbtobsdynamique VCVF _tan_ cosθ⋅⋅⋅=

( )125.0

cos_

tan +⋅⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛

⎟⎟

⎠

⎞

⎜⎜

⎝

⎛

⎟⎟⎠

⎞⎜⎜⎝

⎛ ⋅−−⋅−⋅⋅−= obs

M

brdlookat

rbtXrbtbandes nb

drposwitdh

DVEF θ

linéairement la composante dynamique de la force de bande alors que les coefficients D et M permettent d’agir sur la composante statique. Ajustement des paramètres Initialement, nous avions pensé qu’il serait relativement simple de déterminer de bons coefficients pour nos équations. En utilisant des simulations mettant en valeur chaque composante des forces de répulsion, nous pensions pouvoir faire l’ajustement des paramètres. Malheureusement, les nombreuses interactions des différentes forces nous ont rendu la tâche beaucoup complexe. Néanmoins, le principe directeur que nous avons suivi fût de poser tout d’abord des coefficients arbitraires pour la force de mouvement. En effet, cette force nous sert de référence et nous guide ensuite pour ajuster les forces de répulsion afin que l’ordre de grandeur des résultats obtenus pour ces forces soit compatible avec notre force de référence. Par la suite, nous avons ajusté les coefficients en procédant principalement par essais et erreurs. Néanmoins, nous avions posé des valeurs de départ pour les coefficients des forces de répulsion. Dans le cas de la force statique, l’objectif est d’éviter qu’un autre robot à l’arrêt, situé tout près d’un autre robot à l’arrêt ne puisse entrer en collision ensemble lorsqu’il se met à avancer. Nous avons donc défini une distance minimum entre les deux robots qui devait générer une force statique égale à la force de mouvement maximale. À partir de cette distance, nous avons pu définir un point de départ pour nos coefficients de la force statique. Quant à la force dynamique, notre point de départ était basé sur une situation où deux robots foncent directement l’un vers l’autre à vitesse maximum. Cette situation devait générer une force dynamique égale à la force de mouvement maximum. Quant à la force de la bande, les mêmes principes ont été appliqués pour les composantes statique et dynamique en visant chacune une fraction partielle de la force de mouvement maximum. Il est important de mentionner que la somme de ces deux fractions était plus grande que un. Pour la composante statique, nous avions donc la situation d’un robot seul à l’arrêt proche de la bande et pour la composante dynamique, le robot s’approchait à vitesse maximum et en direction perpendiculaire à la bande. C’est donc en suivant ces principes que nous avons posé nos premiers paramètres. Résultats et discussion Les premiers essais furent faits en simulation pour des situations où tous les robots sauf un étaient statiques. Nous avons testé différentes configurations afin de visualiser comment le robot mobile réagissait. Lorsque nous avons atteint des niveaux de performance intéressants, nous avons abordé les simulations dynamiques. Nous avons fait varier la vitesse maximum des robots et nous avons aussi varié leur comportement. En effet, nous pouvions donner un comportement aléatoire ou les faire courir le ballon. Les collisions sont allées en augmentant proportionnellement avec la vitesse des robots et leur tendance à courir le ballon qui les faisait se regrouper en paquet. Une autre source de collision était notre méthode de recouvrement. Notre modèle mathématique pouvait nous entraîner dans des situations où le robot faisait de constants petits va-et-vient. Cela pouvait se produire par exemple quand la somme des forces dans une région était très faible. Le robot avait alors tendance à choisir une direction pour

- 22 -

rapidement revenir sur ses pas et ainsi de suite, au fur et à mesure que la résultante oscillait entre deux positions. Notre méthode de recouvrement était plutôt simple et consistait à calculer une force résultante sans toutefois tenir compte de la force de mouvement, l’objectif étant de sortir de l’endroit actuel plutôt que de se diriger vers une cible. Le robot reculait ensuite pendant un intervalle de temps prédéfini en suivant cette résultante. Il repartait ensuite selon une trajectoire perpendiculaire à la résultante et il retombait en mode de fonctionnement normal. Cependant, il arrivait souvent qu’en reculant il frappe des robots puisque pendant ce recul, il ne vérifiait pas la résultante des forces. À cause de l’impact des différents coefficients, chacun agissant sur une partie de l’équation globale, et des situations de jeux pouvant varier énormément, il s’est vite révélé très ardu de faire une mise au point des coefficients pour obtenir un algorithme performant en toutes circonstances. Le modèle a pu se révéler très performants à basse vitesse avec presque aucune collision sur une longue période mais il recelait plusieurs imperfections pour des conditions typiques de soccer robotisé. La présence de ces nombreuses difficultés nous a amené à reconsidérer une partie de notre modèle. Nous avons néanmoins fait des tests sur le système réel pour des conditions qui donnaient de bons résultats en simulation. Ces tests furent principalement faits dans des configurations statiques et certains passages des vidéos ont pu être visualisés lors de la présentation finale. Dans l’ensemble, les résultats obtenus sur le système réel sont comparables aux résultats en simulation. De plus, les tests sur le système réel demandaient une plus grande prudence dans l’ajustement des coefficients car les systèmes techniques de vision globale et d’odométrie connaissaient parfois des ratés.

3.3 Méthode des champs de potentiel révisée

Changements apportés Notre principal désagrément avec l’ancien modèle était de voir un robot se retrouver coincé et incapable de s’en sortir, d’autant plus qu’il générait plusieurs collisions au passage. C’est pourquoi nous sommes revenus partiellement sur notre décision initiale de ne pas considérer les méthodes heuristiques. En effet, notre méthode mathématique ne nous permet pas de bien décoder un environnement légèrement éloigné. Afin d’éviter les culs-de-sac qui sont non détectables par notre méthode mathématique, nous avons décidé de déterminer un point intermédiaire dont la trajectoire est libre de tout obstacle. Nous analysons la ligne droite entre la cible finale et le robot. Si cette ligne est encombrée, nous cherchons le rayon le plus rapproché qui est libre et nous obtenons une cible intermédiaire pour notre robot. Cette étape est effectuée afin d’éviter les coins où plusieurs robots se déplaçant lentement sont à mêmes de bloquer notre robot. Puisque nous évoluons dans un environnement dynamique, c’est la méthode mathématique qui va nous permettre de nous rendre vers cette cible intermédiaire tout en évitant les collisions. Pour le calcul des forces, la seule différence apparaît pour la force résultante qui pointe maintenant dans la direction de la cible intermédiaire. Par ailleurs, cette cible

- 23 -

- 24 -

intermédiaire sera bien sûr recalculée à intervalles réguliers. Notre algorithme de base peut donc se résumer en 4 étapes.

• déterminer la cible intermédiaire • déterminer l’orientation et la vitesse en lien avec cette cible • faire le calcul mathématique de la trajectoire • recalculer l’orientation et la vitesse que nous donnons au robot

La figure ci-dessous représente la différence entre le modèle initial, les lignes pointillées, et le nouveau modèle, les lignes pleines. Les forces de mouvement sont en noir alors que la résultante est représentée en rouge. Si nous comparons les deux modèles, nous voyons que le modèle initial va diriger le robot en bleu vers une impasse où il sera entouré par la bande et deux robots. Il aura alors beaucoup de difficultés à ressortir de cet endroit. À l’inverse, avec notre méthode révisée, le robot est maintenant capable de se diriger vers un chemin libre a priori. La nouvelle résultante obtenue va le diriger vers une cible intermédiaire qui lui permettra à moyen terme d’atteindre sa cible.

Figure 16 : Révision de la cible afin d’éviter les obstacles

De plus, il n’y a plus d’algorithme de recouvrement car notre méthode révisée, grâce au balayage permettant de trouver un chemin libre, nous assure que le robot ne se retrouvera jamais coincé. Dans le pire des cas, celui où il ne trouverait aucun chemin de libre, le robot ferait du surplace jusqu’à ce qu’un chemin se dégage. Résultats et discussion La programmation étant un travail dont le temps requis pour mener une tâche à bien peut varier énormément pour des détails, il nous reste quelques bogues dans notre méthode révisée. Les tests faits en simulation ont montré que nos robots ne comprenaient pas encore très bien la démarche que nous souhaitons les voir appliquer. Néanmoins, dans certains cas, les résultats semblent intéressants quoique tout jugement à ce stade soit sans doute prématuré.

Pour revenir sur l’ensemble des résultats, si nous analysons en détails les performances des simulations, nous avons remarqué qu’il est difficile de bien gérer la vitesse des robots afin qu’il puisse jouer efficacement dans les coins tout en évitant la bande. De plus, la navigation à haute vitesse est souvent dangereuse car les robots peuvent atteindre des vitesses de 2 m/s dans un terrain qui ne fait que 3 mètres par 6 mètres ce qui demande donc une distance de freinage importante. Dans presque tous les cas lors de collisions, les robots ont eu le temps de se voir mais ils ont manqué de temps pour freiner. Par ailleurs, faire les simulations sur une plate-forme qui n’est pas faite pour le temps réel, soit Windows 2000, est une source de problèmes puisque le calcul des forces en action est supposé se faire à chaque 20 ms ce qui n’est pas toujours le cas. En effet, il peut arriver qu’il s’écoule plus de 0.3 secs entre deux itérations ce qui représente une distance appréciable lorsque deux robots roulent l’un vers l’autre à une distance de 1 m/s! Lorsqu’ils se verront, il sera sans doute trop tard pour freiner.

4 Résultats expérimentaux

De nombreux essais ont pu être effectués en simulation et sur le système réel. Les deux prochaines sections présentent les principaux résultats de ces essais.

4.1 Simulation

Les essais en simulation sont très utiles pour ajuster les paramètres de la méthode développée. Les ajustements se font effectivement beaucoup plus rapidement que sur le système réel. C’est pourquoi la simulation a été utilisée afin d’ajuster les paramètres pour différentes vitesses de référence désirées. Les paramètres ainsi déterminés peuvent alors être utilisés sur le système réel avec un bon niveau de confiance. Les premiers ajustements ont été faits avec une vitesse de référence de 0,5m/s pour ensuite augmenter graduellement cette vitesse. Pour l’instant, une vitesse de pointe de 1m/s est acceptable et les résultats obtenus sont bien acceptables. Pour des vitesses plus élevées, un ajustement sera nécessaire puisque le nombre de collisions observées augmente avec la vitesse. Compte tenu du fait que les robots offrent une vitesse maximale de près de 2,8m/s, il sera intéressant de bénéficier prochainement d'une vitesse de pointe plus élevée. Le terrain de jeu étant toutefois restreint (3m x 6m) et les accélérations des robots n’étant pas infinies, il devient difficile d’éviter toutes les collisions. Les derniers ajustements ont permis de déterminer ce jeu de paramètres qui est valide pour des vitesses inférieures ou égales à 1m/s :

A = 30 , k = 1 , B = 2 , l = 3 , C = 30 , D = 2 m = 2 , E = 2 ,

- 25 -

- 26 -

La figure qui suit présente un exemple d’essai à 6 robots effectué. Pour ces essais, différents cerveaux peuvent être utilisés pour générer les mouvements des robots. Par exemple, un robot peut simplement se diriger sur le ballon, ou encore évoluer sur le terrain à des positions déterminées aléatoirement, ou encore utiliser les algorithmes de plus haut niveau comme ceux décrits dans quelques paragraphes. Dans l’exemple de la figure qui suit, les 6 robots utilisent les algorithmes de jeu.

Figure 17 : Essai du système en simulation, algorithmes de jeu, 1m/s

4.2 Système réel

Plusieurs essais ont également été effectués sur le système réel. Ces essais demandent toutefois beaucoup de préparation (ajustement du système de vision, mise à jour des robots avec la dernière version du logiciel de contrôle, etc.) et sont beaucoup plus longs à effectuer que les essais en simulation. C’est pourquoi il est préférable de développer et d’ajuster le système en simulation et ensuite de simplement valider ces ajustements grâce à quelques essais sur le système réel. Ainsi, pour le présent projet, nous avons regroupé la majorité de nos essais sur une journée complète de travail, journée au cours de laquelle plusieurs séquences vidéos ont été tournées. Ces séquences accompagnent d’ailleurs la version électronique de ce rapport. Ces essais ont donc permis de valider la fonctionnalité des différents éléments développés et de remarquer quelques caractéristiques propres au système réel qui méritent d’être considérés lors des développements futurs. Voici un résumé de ces caractéristiques :

• Imprécisions du système de vision : le système de vision, toujours en développement, fonctionne plus que convenablement mais non parfaitement. Ainsi, il lui arrive de donner des mesures erronées ou imprécises. Par exemple, il lui arrive de rater l’identification des robots d’une même équipe et de les mélanger. À ce moment il faudrait traiter ces erreurs, soit au sein même du système de vision ou encore au sein du serveur et du logiciel de contrôle, en considérant une certaine zone dans laquelle peut se trouver un robot en fonction

- 27 -

de sa position précédente et de sa vitesse tout en rejetant une position trouvée à l’extérieur de cette zone.

• Retard dans les mesures du système de vision : les données du système de vision proviennent aux robots avec un certain retard, dû à l’acquisition et au traitement de l’image ainsi qu’à la transmission de ces données au serveur et aux robots. Il est possible de prédire les valeurs actuelles déterminées par le système de vision à partir des données retardées reçues. Il faut toutefois connaître avec une précision suffisante la valeur du retard. Ce retard peut être une valeur constante déterminée ou mesurée, ou encore une valeur mesurée en temps réel par le serveur de jeu (cette mesure demande toutefois une base de temps commune des différents éléments). En ce moment le serveur mémorise le temps de mise à jour du système de vision, donnée qui peut être récupérée par les robots.

• Erreur d’odométrie suite à une collision importante : il a été observé qu’un robot peut montrer une erreur importante au niveau de son positionnement due à l'odométrie suite à une collision importante. Cette erreur peut s’expliquer en partie par le dérapage des roues qui a lieu lors de ce type de collision. Ce dérapage est toutefois minime et n’explique pas l’amplitude importante de l’erreur observée. Ce problème demeure donc en partie inexpliqué.

5 Applications de la solution

Suite aux essais effectués, la méthode développée peut être considérée comme étant suffisamment robuste et efficace pour l’utiliser dans des algorithmes de contrôle de plus haut niveau. Il devient donc beaucoup plus simple de développer ces algorithmes puisqu’il suffit de se choisir, en temps réel, une cible désirée à atteindre sur le terrain et de transmettre cette cible à la méthode développée (module MotionControl), qui se charge alors de déplacer le robot vers cette cible. Voici donc quelques exemples d’utilisation de la méthode.

5.1 Algorithmes de jeu

Puisque l’architecture mécanique des robots évoluera de façon importante dans les mois qui suivront la remise de ce rapport, les algorithmes de jeu présentés ici ont été développés en visant un objectif principal, soit de développer des algorithmes suffisamment efficaces mais qui sont très simples et qui demandent peu de lignes de programmation.

5.1.1 Gardien de but

L’algorithme du gardien présente trois caractéristiques principales : • Prédiction de la position du ballon • Positionnement dans la zone de recouvrement en fonction de la position prédite

- 28 -

• Dégagement du ballon lorsque jugé opportun La prédiction du ballon utilise une méthode développée dans le module Brain, utilisée pour prédire la position du ballon lorsque le système de vision n’a pas effectué de mise à jour. Puisque cette méthode reçoit le temps désiré de la prédiction, elle peut être utilisée pour un temps arbitraire. Ainsi, le gardien utilise cette méthode dans une boucle au sein de laquelle le temps de prédiction est incrémenté (l’incrément est de 20ms). Cette boucle s’arrête lorsque la vitesse du ballon devient nulle (le ballon finit par s’arrêter puisqu’une certaine friction est modélisée) ou que le ballon pénètre le but du gardien. Cette prédiction permet alors de prendre une décision sur le positionnement à effectuer. Lorsque la prédiction indique que le ballon va s’arrêter sans pénétrer le but du gardien, ce dernier suivra la coordonnée X actuelle du ballon et se positionnera en Y sur sa ligne de référence (40cm à l’avant de sa ligne de but). Cette situation est illustrée dans le schéma de jeu no.1 de la figure qui suit. Lorsque la prédiction indique cependant que le ballon va pénétrer le but, le gardien se positionne toujours sur sa ligne de référence en Y, mais il va se positionner à la position à laquelle la trajectoire du ballon intercepte cette ligne de référence. Cette situation est résumée dans le schéma de jeu no.2 de la figure qui suit.

Figure 18 : Positionnement du gardien en fonction de la trajectoire du ballon

Le gardien est également en mesure de dégager le ballon de son territoire lorsqu’il le juge opportun. La condition qui lui permet de dégager est simplement que le ballon doit être suffisamment près de la ligne de but en Y (à moins de 1,5m de la ligne du fond) et qu’il montre une vitesse suffisamment faible. À ce moment, le gardien se dirige directement sur le ballon de façon à le frapper et le dégager de son territoire. La condition de dégagement pourra éventuellement être raffinée pour, par exemple, tenir compte de la position des robots adverses afin de s’assurer de ne pas leur offrir de chances de marquer. Résultats Malgré sa simplicité, l’algorithme développé a démontré son efficacité en simulation tout comme sur le système réel. Évidemment, la réponse du gardien sur le système réel dépend en grande partie de la réponse du système de vision (de la vitesse et de la précision à laquelle il fournit la position du ballon). De plus, les essais ont permis de

1

2

- 29 -

confirmer une faiblesse du gardien au niveau des dégagements. Cette faiblesse est due à la structure circulaire du robot, puisque lorsque le ballon se retrouve dans un coin du terrain, il devient à peu près impossible de dégager le ballon. Cette lacune sera comblée lorsque les robots seront équipés de leur module de contrôle du ballon.

5.1.2 Attaquant

L’algorithme de l’attaquant présente trois caractéristiques principales : • Jeu d’équipe : le robot d’une même équipe le plus près du ballon joue un rôle

offensif, l’autre joue un rôle défensif • Rôle offensif : séquence de positionnements du robot en fonction de sa position

relative à celle du ballon • Rôle défensif : positionnement de façon à éviter la pénétration du ballon dans la

zone du gardien Le jeu d’équipe se justifie par le fait qu’une équipe est constituée de deux attaquants (trois à la RoboCup) et qu’il est donc possible d’utiliser en tout temps un robot en rôle défensif et un en rôle offensif. Le critère de décision pour le rôle joué est simplement la distance du ballon. Le robot le plus près prendra le rôle offensif et l’autre robot le rôle défensif. Cette décision se fait en temps réel et indépendamment pour chacun des robots. Pour le rôle offensif, l’objectif est bien sûr de marquer des buts. Pour ce faire, une séquence de positionnements a été développée de façon à permettre au robot de pousser le ballon vers le but. Cette séquence est résumée à la figure qui suit. Dans un premier temps, le robot vérifie si sa position en Y est correcte, car le ballon doit se trouver entre le robot et le but adverse. Si elle ne l’est pas le robot recule derrière le ballon en s’assurant de ne pas le frapper. Ensuite, le robot va se placer derrière le ballon, mais de façon à intercepter la droite formée par le centre du but et le centre du ballon. Finalement, une fois cette position atteinte, il se dirige sur cette droite en direction du but adverse, ceci lui permettant de pousser le ballon en direction du but.

Figure 19 : Séquence de positionnements du robot en rôle offensif

Pour le rôle défensif, le robot se positionne simplement sur une droite de référence en Y (1,5m devant le but de l’équipe) et à la position actuelle du ballon en X. Cette méthode simple permet au robot jouant le rôle défensif d’empêcher le ballon de pénétrer dans la zone du gardien. Il joue en quelque sorte le rôle d’un second gardien. Résultats Des essais ont été effectués en simulation comme sur le système réel afin de valider cet algorithme. Premièrement, des essais avec un seul robot sur le terrain ont été effectués afin de valider la séquence de positionnements du rôle offensif. Ces essais ont donc permis de valider la séquence mais également d’observer que les légères imprécisions du système font en sorte que le ballon n’est jamais exactement lancé vers le centre du but, mais plutôt à une position aléatoire entre (la grande majorité du temps!) les extrémités du but. Il serait donc préférable de compter sur une précision accrue pour mieux prédire et contrôler le jeu. Néanmoins, ces imprécisions ajoutent un certain degré de difficulté pour les gardiens adverses. De plus, il a été observé qu’en situation de jeu normale (avec tous les robots sur le terrain), la stratégie offensive est très peu efficace puisque la défensive de l’équipe est beaucoup trop performante. En effet, il est dans un premier temps difficile d’éviter le robot jouant le rôle défensif et il est encore plus difficile de déjouer le gardien adverse. Il faudrait évidemment développer une manipulation du ballon beaucoup plus évoluée pour déjouer les joueurs défensifs mais il est préférable d’attendre l’installation des modules de contrôle du ballon pour le faire.

5.2 Contrôle assisté

Il est également possible d’utiliser la méthode développée dans des applications où un contrôle assisté peut être nécessaire. Par exemple, lorsqu’un robot mobile évolue dans un environnement hautement dynamique et qu’il est manipulé par un opérateur. À ce moment, la méthode développée pourrait permettre d’atteindre des vitesses possiblement plus grandes que celles atteintes par l’opérateur seul lorsqu’il tente d’éviter les collisions. Ce type de contrôle a d’ailleurs été validé au laboratoire puisqu’il est à la fois possible de contrôler un robot footballeur par une manette de jeu et d’éviter les collisions grâce au module MotionControl. À ce moment, il suffit de transposer la commande manuelle de la manette à une cible désirée et de transmettre cette cible au module MotionControl.

6 Discussion et recommandations

Pour palier aux difficultés rencontrées, nous avons encore beaucoup de travail. Malgré tout, nous avons déjà plusieurs idées à tester pour améliorer le fonctionnement de notre algorithme. Par exemple, nous avons pour idée présentement d’ajouter une variable de niveau de sécurité au joueur. Ainsi, selon la situation de jeu, le rôle du robot et la présence de robots obstacles dans son entourage, son niveau de sécurité pourrait être

- 30 -

- 31 -

changé en temps réel. Ce niveau de sécurité serait lié à un ensemble prédéfini de coefficients qui nous permettrait donc d’ajuster le comportement du robot en cours de match et donc d’obtenir des performances intéressantes malgré l’évolution de la situation. De plus, un changement que nous voulons étudier est celui de calculer le module de la vitesse finale non pas à partir de la force résultante mais à partir de la somme des forces qui ont un impact sur le robot. La vitesse du robot serait inversement proportionnelle à la somme des forces. Ainsi, cela éviterait qu’un robot puisse rouler à haute vitesse près de d’autres robots parce que plusieurs forces de répulsion se sont partiellement annulées. Nous pensons que ce changement pourrait se révéler bénéfique pour éviter plusieurs collisions. Néanmoins, une borne inférieure serait programmée afin d’assurer une vitesse minimum au robot. De plus, nous avons imaginé également d’autres formules pour le calcul des forces de répulsion. Ces formules seraient basées sur un rapport entre la vitesse et la distance d’un obstacle relativement au robot considéré. Par ailleurs, il est intéressant de mentionner que ces tests sont effectués sur un terrain dimensionné pour le laboratoire. Si nous devions participer à la RoboCup, le terrain pourrait avoir des dimensions atteignant 6 m par 12 m ce qui, même avec l’ajout d’un robot par équipe, fournirait beaucoup plus d’espace pour manœuvrer. Atteindre des vitesses de 2 m/s par seconde tout en étant sécuritaire ne serait donc plus aussi risqué. C’est pourquoi nous tentons de développer les robots pour des vitesses élevées malgré les dimensions réduites de notre terrain d’essai. Finalement, les nombreux résultats que nous avons obtenus, tant sur le système réel qu’en simulation, nous permettent d’espérer obtenir en bout de ligne une solution performante et somme toute assez simple. Il nous reste un peu de programmation pour la méthode révisée et nous allons aussi devoir travailler à la mise au point du système de vision et de l’odométrie afin de pouvoir obtenir un verdict final sur les performances de notre algorithme.

7 Développements futurs

Voici la liste des principaux développements qui auront lieu au Laboratoire de mécatronique dans les mois qui suivront la remise de ce rapport :

• Fusion des données du système de vision et de l’odométrie par filtre de Kalman : afin de pouvoir compter sur un positionnement précis sur une échelle de temps suffisamment longue, il est nécessaire de fusionner l’information relative de l’odométrie à celle absolue du système de vision.

• Développement du module de contrôle et de lancement du ballon : ce module est essentiel au développement des capacités individuelles des robots.

• Développement du système de vision embarqué : afin de se conformer aux règles de la RoboCup, le système de vision devra éventuellement être embarqué sur chacun des robots.

- 32 -

• Évolution des algorithmes de jeu : la première approche plutôt simple s’est montrée efficace mais il faudra tout de même développer des algorithmes plus évolués.

• Développement de l’architecture de communication et de coopération multi-robots : une fois les capacités individuelles des robots suffisamment développées, il devient possible de permettre aux robots d’une même équipe de communiquer et de coopérer.

8 Bibliographie

[1] DeSantis, R.M., Dynamique des systèmes mécaniques sous contraintes holonomes et non holonomes (cours ELE6207) , École Polytechnique de Montréal, 2001, pp.48-55. [2] Latombe, J.-C., Robot Motion Planning, Kluwer Academic Publishers, 1991. Bowling, M. Veloso, M., Motion Control in Dynamic Multi-Robot Environments, Carnegie Mellon University, 1999. Sacks, B., Using improved detection in robocup soccer for collision avoidance and recovery, Williams College, 2002. Site officiel de la compétition RoboCup : http://www.robocup.org

- 33 -