Architecture de l'agent

L'architecture utilisée pour notre agent est de type horizontale (voir la section ). Nous avons notamment défini des modules indépendants pour l'ordonnancement des tâches, pour la représentation du monde (tableau noir). Les récepteurs ainsi que les effecteurs sont distincts du reste de l'agent. La figure résume l'architecture utilisée.

Figure: Architecture de notre implémentation

Le déroulement de l'exécution de l'agent est conditionné par l'exécution de plans. Les plans sont des modules dont chaque instance possède des informations sur sa représentation graphique ainsi que sur sa propre validité. Une instance de plan est capable de générer une autre instance de plan, dédiée à l'atteinte des conditions nécessaires à son exécution. À chaque cycle d'exécution, déterminé par une « horloge » et calqué sur le cycle d'exécution du serveur de simulation (voir la section , cha:simulation-effecteurs), un « top d'horloge » (un signal UNIX) est envoyé au programme, ce qui déclenche une action de l'ordonnanceur. L'ordonnanceur est l'organe chargé de choisir le plan à exécuter. Dans l'implémentation actuelle il choisit le plan le plus urgent, c'est-à-dire celui qui se trouve en première position de l'agenda. La conservation de l'état du monde est, quant à elle, assurée par un mécanisme de « tableau noir » décrit dans la section .

Le serveur de simulation de la RoboCup interagit avec les clients de manière asynchrone, c'est-à-dire sans synchronisation de leurs interactions. Le serveur communique par l'émission à intervalles réguliers de messages sensitifs ou informatifs ainsi que par l'évaluation régulière des requêtes des clients. La programmation d'un agent simulé de la RoboCup nécessite donc d'implémenter une boucle basée sur la réception de messages et sur leur traitement. À chaque fois que l'agent reçoit des informations sensorielles, il met à jour l'état du monde qu'il avait maintenu jusque là, réévalue son action actuelle en fonction du nouvel état obtenu et exécute une action en fonction de ses buts mis à jour. Il s'agit d'une contrainte de programmation assez forte, qui oblige à maintenir d'un cycle à l'autre des informations dans un contexte global. Ainsi, les méthodes utilisées pour accomplir une action doivent se passer au maximum de résultats intermédiaires, être réentrantes (pouvoir s'exécuter plusieurs fois dans des conditions différentes) autant que possible. Cette problématique est particulièrement cruciale et limitante pour le mécanisme d'extension basé sur l'inclusion d'un interpréteur Scheme (voir la section ), que nous avons développé au sein de notre agent. Cependant, elle peut être limitée par l'utilisation de variables d'instances afin de sauvegarder les états intermédiaires des plans de l'agent et ainsi limiter les problèmes de l'exécution sans état.