La planification

Figure: Exemple de plans hiérarchiques

Nous définissons une architecture d'agents basée sur l'exécution de plans, conçus sous la forme de modules spécifiques. Leur exécution est autonome mais contrôlée par un ordonnanceur. Ces plans sont des objectifs à atteindre pouvant contenir à leur tour et de manière hiérarchique des sous-plans intermédiaires: nous représentons ainsi l'enchaînement des étapes nécessaires à l'exécution d'un plan (voir la figure ). Les plans sont représentés par des objets de classes dérivant de la classe Plan (par exemple, PlanTakeBall ou PlanWatch), comportant toutes les données attachées à un plan, notamment les données nécessaires à la visualisation. Nos plans possèdent un mécanisme de contrôle d'exécution et sont capables de tolérer des états inattendus (pannes) ou de déclencher des actions intermédiaires pour arriver à leurs fins.

Nous considérons que les plans définis doivent prendre le plus d'initiatives qu'ils peuvent et qu'ils doivent contrôler le déroulement de leur action, car ils sont en effet les plus à même de le faire. Déléguer le contrôle de l'exécution d'une action à un autre organe équivaut à transporter une partie de la symbolique du plan vers ce dernier afin qu'il soit capable de modéliser et de comprendre le déroulement de cette action. De même, cela nécessite la mise en place d'un mécanisme de contrôle par un organe superviseur. La complexité induite est sensible aux pannes et alourdit le traitement du contrôle des actions entreprises alors qu'elle n'est pas nécessaire. Nous considérons les plans de notre architecture comme des effecteurs complexes et non atomiques, leur exécution asynchrone étant très similaire à celle d'un effecteur atomique.

L'initialisation de l'agent et l'assignation d'un plan de démarrage est assuré par le biais d'un script Scheme. Nous avons défini une primitive Scheme (add-plan) permettant d'ajouter un plan dans les motivations d'un agent. Par exemple, « (add-plan "find-ball") » permet d'ajouter dans l'agenda la volonté de localiser la balle sur le terrain. À l'initialisation de l'agent, une option permet d'évaluer un script pouvant comporter des initialisations globales à l'équipe et des branchements conditionnels (« utiliser ce plan uniquement pour tel agent »). Ainsi, les procédures de tests sont facilitées par l'évaluation de scripts tels celui présenté dans l'exemple . Ce dernier permet de mettre en place deux joueurs, dont l'un tentera de s'emparer de la balle et dont l'autre observera le terrain et tentera d'analyser le plan du premier agent.

Figure: Exemple de script d'initialisation

Chacun des plans possède une clause d'invalidation qui est propre à une instance. Il s'agit d'une condition qui invalide le plan et le rend obsolète. L'obsolescence d'un plan peut être déclenchée par deux conditions: sa réussite (par exemple, atteindre la balle pour le plan take-ball) ou l'existence de conditions rendant impossible son exécution (par exemple, un autre joueur possède la balle pour le plan take-ball). Nous considérons en effet qu'un plan doit être rendu obsolète et abandonné dès qu'une clause rend son exécution difficile, quelle que soit la motivation existante à l'exécuter. Cependant, les plans doivent être responsables de la maintenance ou de la création des conditions nécessaires à leur bon fonctionnement: par exemple, le plan take-ball est responsable de la maintenance de la connaissance de la position de la balle en mémoire via l'exécution de plans intermédiaires. Les clauses d'invalidation sont des méthodes évaluées à chaque cycle avant l'exécution de chaque instance de plan.

Figure: Proposition de modélisation d'agents simulés

Les plans développés contiennent de plus une clause de validité. Cette clause permet de déterminer si une instance de plan est valide pour un joueur ou non, en se basant sur son comportement apparent. Le mécanisme que nous proposons tente de vérifier de manière asynchrone et par hypothèse si une instance de plan correspond au comportement d'un joueur connu, c'est à dire si son état actuel correspond à une phase du plan (par exemple, si un joueur est le plus proche de la balle et qu'il est orienté vers elle, il peut être en train d'exécuter le plan take-ball). Ce mécanisme est imparfait en plusieurs points: il est sans état, c'est-à-dire qu'il ne tient pas compte des actions passées d'un joueur (ce qui interdit donc de dégager une intentionalité d'un processus) et de plus, il nécessite une heuristique distincte de celle de l'exécution du plan. Nous proposons une solution, qui serait d'abandonner la modélisation actuelle des autres agents, incluse actuellement dans la base des croyances et accessible par le biais de méthodes facilitatrices, au profit de la simulation de ces agents via une représentation mémoire similaire à celle de l'agent « réel » (l'agent exécuté par le processus et communiquant avec le serveur de la RoboCup) et une exécution en parallèle des modèles simulés. Voir par exemple la figure qui détaille le mécanisme de modélisation proposé. L'agent réel s'interfacerait avec les agents simulés par des canaux de communication semblables et un protocole identique à celui utilisé pour communiquer avec le serveur et se chargerait d'envoyer des informations sensorielles aux agents simulés en se basant sur ses croyances propres. Ainsi, l'agent réel simulerait par ce biais le comportement de ses partenaires en utilisant les heuristiques même de leur comportement réel. Les actions des agents simulés seraient perçues via leurs effecteurs et permettraient à l'agent réel de déterminer les actions probables de ses coéquipiers et adversaires en se basant sur les heuristiques et la représentation mêmes de leur exécution. La communication entre de tels agents n'étant pas soumise à des contraintes de bande passante, elle pourrait se faire de manière privilégiée et pourrait permettre de s'échanger des plans et d'estimer le comportement de ses coéquipiers (cette hypothèse assume cependant que la structure de tous les agents simulée est connue et reproductible).

Les plans actuellement implémentés sont orientés vers la manipulation et le maintien de la balle, mais l'implémentation de plusieurs plans sensitifs complexes simplifie le traitement des informations par l'agent. Les plans dont nous disposons sont pour le moment:

• face_ball: trouver la localisation de la balle sur le terrain et se tourner vers elle lorsqu'elle se déplace ;
  

• find_ball: trouver la localisation de la balle sur le terrain. Cela peut impliquer des mouvements pour l'obtenir dans son champ de vision ;
  

• find_teammate: trouver la localisation d'un de ses coéquipiers sur le terrain. Cela peut impliquer des mouvements pour l'obtenir dans son champ de vision. Une des ambiguïtés simulées par le serveur de la RoboCup est d'ailleurs l'incapacité de déterminer le numéro de maillot d'un coéquipier visible mais éloigné, ce qui peut amener à une situation de dead-lock. Il s'agit typiquement d'un cas où un plan sera le plus à même de contrôler l'échec de son action ;
  

• pass_ball: passer la balle à un partenaire. Cela implique de se rapprocher de la balle puis de la tourner en direction d'un partenaire et enfin de lui imprimer un mouvement afin de la déplacer jusqu'à ce dernier ;
  

• take_ball: aller à la position de la balle (plus précisément, s'en rapprocher jusqu'à ce qu'elle soit à portée). Si elle n'est pas dans le champ de vision, ce plan déclenche un plan find_ball pour la localiser ;
  

• watch: observer le déroulement du jeu de son point de vue (notamment, fixer la balle) et tenter de déterminer les plans des joueurs.
  

Chacune des instances de plan possède une représentation graphique propre, qui utilise la couche graphique développée pour notre implémentation (voir la section , cha:implem-visualisation pour plus de détails sur l'implémentation graphique). Les instances de plans utilisent une table de hachage pour stocker les objets graphiques utilisés et affichés à chaque cycle. À chaque exécution asynchrone du plan, les objets graphiques sont mis à jour par l'instance elle-même afin qu'ils soient les plus proches possible de la réalité et des symboles contenus dans l'état du monde.