Voici un petit aperçu de l’aspect graphique du simulateur. Cette sortie imagée n’a pour seul but que de visualiser les déplacements du robot en fonction des ordres transmis par l’AI. La vrai simulation n’étant pas directement visible car elle consiste en événements retournés à l’AI sous la forme de callback. Le but final étant de pouvoir simuler différentes stratégies, et donc les déplacements sont “idéaux” et ne prennent pas en compte toutes les contraintes imposées par les moteurs et par la physique.

Une “traînée” jaune permet de visualiser le déplacement du robot depuis son point de départ. Les coordonnées ainsi que l’angle de direction sont visibles à proximité du robot. Les informations détaillées sur les déplacements ne sont par contre visibles que depuis la sortie console du simulateur.

Team programmation

Plusieurs fois dans les articles précédents, il était mentionné l’utilisation de la librairie Ecore/Evas pour le simulateur. Mais les circonstances en ont finalement décidé autrement. Le simulateur étant une application multi-threads ainsi qu’une librairie, deux problèmes surviennent lors de l’utilisation d’Ecore. Tout d’abord, il n’y a pas de fonction main, ainsi la fonction bloquante de “loop” permettant de gérer les événements dont ceux des timers, doit être intégrée à un thread. Mais Ecore n’étant pas complètement thread-safe et re-entrant, des comportements étranges peuvent apparaîtres.

Si vous êtes intéressé par Ecore, je vous invite à télécharger ce petit exemple : www.geexbox.org/~schroeterm/buggy_timer.c que vous pouvez compiler simplement en spécifiant -lecore et -lpthread au linker. Afin de se rendre compte des problèmes, décommentez et commentez les lignes 53 et 54. La sortie console parlera d’elle-même.

Après une petite discussion avec les développeurs d’Evas, le simulateur utilisera donc la fameuse librairie SDL dont la robustesse n’est plus à prouver.

site web : www.libsdl.org

Team programmation 

Afin de pouvoir réaliser correctement le contrôleur IA, il est nécessaire d’avoir un simulateur du robot sous la main pour calculer, voir même visualiser les actions effectuées. Le but final étant de pouvoir tester les différentes tactiques et de les améliorer.

Cet article à pour but de présenter l’architecture interne du simulateur (ou tout du moins le principe). Quatre fonctions (bleu clair) sont disponibles depuis le “wrapper simulator” et permettent donc d’initialiser le simulateur, de traiter le callback pour les événements venant du simulateur, d’envoyer des actions au robot simulé et pour finir, de terminer (uninit) la simulation.

Afin de pouvoir gérer chaque action indépendemment et en parallèle, celles-ci sont traitées dans différents threads. Le graphique suivant ne montre que deux actions (move et turn) ainsi qu’une action “…”. En réalité les “…” veulent simplement dire qu’il y aura plusieurs autre threads mais à l’heure actuel, tous ne sont pas déterminés. Les threads d’actions font les traitements nécessaires puis transmettent un événement en temps voulu, événement qui est ensuite redirigé dans le callback du wrapper (à l’aide du thread event) pour être traité par la librobot puis par l’AI.

Les threads des actions font appelles à d’autres fonctions invisibles dans ce schéma. Ils feront aussi appelles à la librairie Ecore/Evas pour différents outils ainsi que pour une sortie graphique qui représentera le robot évoluant dans son environnement.

Team programmation

Rentrons un peu dans les détails (mais pas trop) du bloc “Artificial Intelligence” et “Main” présenté brièvement dans l’article précédent. L’architecture ci-dessous résume le fonctionnement, les flèches bleus du sommet correspondant aux accès avec la librobot (actions traduites par des fonctions haut-niveaux et les événements en retour sous forme de callback).

Mais commençons par le début. Les tactiques sont écrites dans des fichiers XML. Ainsi plusieurs tactiques peuvent être préparées et même combinées. Il n’est pas nécessaire d’effectuer la moindre manipulation dans le code pour changer le comportement du robot. Puis le (ou les) fichier XML est traduit par un “parser” allégé (cf. xmlparser & xmllexer de la libxine). Et le bloc “Rules loader” se charge de traiter les données pour les rendre compréhensibles par le contrôleur de l’AI “AI Controller”.

Le contrôleur a accès à deux types d’actions pour agir sur le comportement du robot. Tout d’abord il a accès aux actions de haut-niveaux directement compréhensibles par la librobot. Et deuxièmement il a accès à des fonctions que je nommerais de très-haut-niveaux qui utilisent les fonctions de haut-niveaux. Cette séparation entre les deux types de fonctions se fait au niveau du gros bloc “Thread for send actions”. Celui-ci demande une analyse poussée et nous y reviendrons dans un autre article.

Concernant le second gros bloc, il représente le callback pour tous les événements retournés par la librobot.

FIFO & LIFO

Trois piles “stacks” cohabitent dans ce système. Il y a un premier stack dans lequel les actions à exécuter sont stockées à la manière d’un FIFO lorsque l’AI Controller donne un ordre et sous forme de LIFO lorsque le Thread donne également un ordre. La raison est triviale car le thread lit le FIFO et exécute le premier ordre, mais en fonction du niveau de l’ordre celui-ci aura besoin d’actions et donc d’une réponse relativement rapidement. Il est peut-être plus judicieux de séparer ce mécanisme en plusieurs stacks (au moins deux). Si nécessaire cela sera fait en temps voulu.

Concernant les deux stacks rattachés au callback, ici il y a une séparation entre les réponses pour l’AI Controller et celles pour le Thread.

Boucle

La boucle représentée dans le bloc du contrôleur est en fait la boucle principale du programme et surtout celle qui enverra les actions principales au robot. Concernant la boucle du bloc Thread, elle est également principale mais par rapport au thread. Tant que le robot est sous tension, ces deux boucle sont considérées comme infinies même si le robot doit se stopper après les 90 secondes de jeu.

Team programmation

L’architecture logicielle est représentée ci-dessous. Elle consiste en trois grands blocs: le simulateur, l’API librobot ainsi que l’intelligence. Les blocs “Linux HAL” et “Robot HW” ne font pas directement partie du développement, ceux-ci sont uniquement là à titre indicatif.

librobot

Tout le développement du robot reposera sur GNU/Linux et la librobot sert de couche d’abstraction pour l’intelligence. La raison est naturelle car deux cibles sont possibles. Tout d’abord l’intelligence (que j’appellerais AI désormais) doit servir au robot mécaniquement parlant et ensuite elle doit pouvoir être testée et améliorée directement à l’aide d’un simulateur. Physiquement le robot ne sera pas prêt lors du développement de l’AI, le simulateur est donc très important.
La librobot se découpe en trois grands blocs. Il y a la couche d’abstraction qui traitera les commandes de haut-niveaux envoyées par l’AI, puis viennent les deux “wrappers” (un wrapper est en quelque sorte un adaptateur) pour gérer l’une ou l’autre cible. Le wrapper hardware permet donc d’interagir avec la couche d’abstraction hardware de Linux, son but étant bien entendu d’agir finalement sur les éléments mécaniques du robot (moteurs, fin de course, contrôleurs, etc,…). Le wrapper simulateur communiquera directement avec le bloc à travers des fonctions spécifiques à la commande de la simulation.

Simulateur

Le simulateur sera développé à l’aide de la librairie Evas/Ecore de Enlightenment (E17) dont les snapshots sont disponibles à cette adresse : http://download.enlightenment.org/snapshots/LATEST/

Consultez le site de E17 pour plus d’informations. Evas est donc un élément de “Enlightenment Fountation Libraries (EFL)” et est le canvas de E17. Il est très flexible et permet de facilement fonctionner sous différents moteurs comme le Framebuffer, OpenGL, X11, DFB, etc,… Quant à Ecore, il nous simplifiera le travail pour la gestion des événements, timers, etc,.. et est directement lié à Evas.

Intelligence Artificielle

L’intelligence sera indépendante du robot. Celle-ci demande une analyse détaillée ainsi que la présence du simulateur. Rien n’a encore été prévu mais ça ne saurait tarder .

Team programmation