Rapport Final Travail Personnel Encadré Coordination globale de comportements coopératifs

Institut de la francophonie pour l'informatique (IFI)Bât. D, ruelle 42, rue Ta Quang Buu, Hanoï, Viêtnam

http://www.ifi.auf.org

Rapport Final Travail Personnel Encadré

Coordination globale de comportements coopératifs

Étudiant NGUYEN Thanh Tuan

Promotion 12, IFI Superviseurs Richard CANAL (IFI-MSI)

Yves DUTHEN (IRIT-UT1 Toulouse –France) Hervé LUGA (IRIT-UT1 Toulouse – France)

Hanoï, 2007

http://www.ifi.auf.org/

TPE - Coordination globale de comportements coopératifs

TABLE DES MATIÈRES

INTRODUCTION......................................................................................................3 1. ETAT DE L’ART..............................................................................................5

1.1. SYSTEMES D’EVOLUTION........................................................................5 1.1.1. Historique ..........................................................................................5 1.1.2. Principe général des algorithmes évolutionnistes.........................5 1.1.3. Programmation génétique................................................................7 1.1.4. Les ADFs..........................................................................................12 1.1.5. Paralléliser les algorithmes évolutionnistes.................................13 1.1.6. La bibliothèque ECJ........................................................................15

1.2. Coordination globale de comportements coopératifs..........................16 1.2.1. Introduction .....................................................................................16 1.2.2. GACS................................................................................................16

2. REALISATION...............................................................................................18 2.1. Description du problème ........................................................................18

2.1.1. L’environnement .............................................................................18 2.1.2. Les robots........................................................................................19 2.1.3. Redéfinition du problème ...............................................................19

2.2. Codage pour problème ...........................................................................19 2.2.1. Tableau de Koza..............................................................................19 2.2.2. Parallèlisation..................................................................................21

3. EXPERIMENTATION ....................................................................................25 3.1. Modification des paramètres ..................................................................25

3.1.1. Adaptation au changement d’environnement...............................25 3.1.2. Modification du nombre de robots ................................................26

3.2. Parallèlisation ..........................................................................................27 CONCLUSION ET PERSPECTIVES .....................................................................30 Référence..............................................................................................................31 ANNEXES..............................................................................................................32

A. Fichier paramètre.....................................................................................32 B. Exemple de résultat.................................................................................35

Nguyen Thanh Tuan 2


TABLE DES FIGURES Figure 1 : Schéma général d'un algorithme évolutionniste ......................................6 Figure 2 : Représentation en arbre..........................................................................7 Figure 3 : L'arbre de fonction T1 + T2*T3 ..................................................................7 Figure 4 : 5 étapes préliminaires pour exécuter une application de PG ..................8 Figure 5 : Reproduction .........................................................................................10 Figure 6 : Mutation.................................................................................................11 Figure 7 : Croisement ............................................................................................12 Figure 8 : Un exemple d'ADF ................................................................................13 Figure 9 : La parallélisation globale .......................................................................14 Figure 10 : La parallélisation à gros grain..............................................................15 Figure 11 : L'architecture globale du modèle de synthèse.....................................16 Figure 12 : Un exemple de modèle GACS ............................................................17 Figure 13 : Un exemple de l'environnement ..........................................................18 Figure 14 : Tableau de Koza .................................................................................20 Figure 15 : Le cas : le robot ne porte pas de brique ..............................................20 Figure 16 : Le cas : le robot porte une brique ........................................................21 Figure 17 : Modèle physique « Master-Slave » .....................................................22 Figure 18 : Un exemple .........................................................................................22 Figure 19 : Modèle physique "Islands" ..................................................................23 Figure 20 : Trois types d'environnement : à droite, aléatoire et espacé.................25 Figure 21 : Résultat sans ADF...............................................................................25 Figure 22 : Résultat avec ADFs.............................................................................26 Figure 23 : Graphiques des résultats.....................................................................26 Figure 24 : Résultat d'expérimentation de modification du nombre de robots .......26 Figure 25 : Graphique de résultat de modification .................................................27 Figure 26 : Résultat du modèle "Master-Slave" .....................................................27 Figure 27 : Les paramètres du modèle « Islands »................................................28 Figure 28 : Résultat du modèle "Islands"...............................................................28 Figure 29 : Résultat sur un seul ordinateur............................................................28 Figure 30 : Graphiques de trois modèles selon la note .........................................29 Figure 31 : Graphique de trois modèles selon le temps ........................................29

Nguyen Thanh Tuan 3


INTRODUCTION La simulation des systèmes complexes présente un grand intérêt, mais la recherche en informatique se confronte avec des problèmes difficiles à résoudre dans ce domaine. Un de ces problèmes est la capacité d’un ensemble d’agents mobiles chargés d’exhiber un comportement collectif à se coordonner spatialement. Chaque agent, à chaque moment, doit être capable de se positionner et s’orienter correctement en fonction de la position et du déplacement de tous les autres agents avec qui il interagit. Pour traiter des problèmes de coordination spatiale dans des univers continus et dynamiques, Flacher et Sigaud [FLACHER05] ont choisi une approche ascendante fondée sur la combinaison de forces d’attraction et de répulsion entre tous les agents et les objets pertinents dans leur environnement. Nous nous proposons de résoudre le problème « collecter des briques par des robots dans un environnement » en utilisant ECJ [LUKE02], une bibliothèque de programmation génétique, et mettant en oeuvre les mécanismes utilisés en GACS (Génération ascendante de coordination spatiale). Nous définirons pour chaque robot une combinaison de vecteurs de déplacement construits à partir des perceptions locales qui est en fait une combinaison linéaire de forces d’attraction et de répulsion. Dans le premier chapitre de ce document, nous présentons l'état de l'art des systèmes d'évolution et de coordination globale de comportements coopératifs. Après une brève introduction au principe général de la programmation génétique, fondé sur une imitation de la loi Darwinienne d'évolution des espèces, nous décrivons la programmation génétique. Nous montrons ensuite les modèles parallélisant la programmation génétique. Nous terminons ce chapitre avec l’introduction de la coordination spatiale des agents et du modèle GACS. Le deuxième chapitre est consacré à la réalisation des applications qui mettent en jeu un groupe de robots autonomes devant collecter des briques. La première application est de trouver les meilleurs programmes contrôlant les robots qui vont collecter des briques. La deuxième application sera implémentée avec les systèmes parallèles pour permettre d’améliorer les résultats. Le troisième chapitre décrit l’expérimentation des applications et l’évaluation des résultats.

Nguyen Thanh Tuan 4


Chapitre 1. ETAT DE L’ART

1.1. Systemes d’évolution

1.1.1. Historique Au XIXe siècle, le botaniste britannique Charles Darwin émet sa théorie sur la sélection naturelle. Cette théorie suppose que les espèces évoluent à travers des mécanismes de sélection et que l'individu le mieux adapté à son environnement survit. Basés sur cette théorie, les algorithmes évolutionnistes s'inspirent de l'évolution des populations biologiques. Ils se classent en 4 grandes catégories :

Les algorithmes génétiques développés par J. H. Holland [Holland75] La programmation évolutionnaire de L. J. Fogel [Fogel66] et D. B.Fogel

[Fogel92] La programmation génétique de J. R. Koza [Koza92] Les stratégies d'évolution de H. P. Schwefel et I. Rechenberg

[Rechenberg73] Ces différentes classes d'algorithmes évolutionnistes ne diffèrent que sur les détails d'implantation des opérateurs et sur les procédures de sélection et de remplacement de la population. Bien que leur but soit différent à l'origine, ils sont maintenant surtout utilisés pour résoudre des problèmes d'optimisation.

1.1.2. Principe général des algorithmes évolutionnistes Les algorithmes évolutionnistes (AE) travaillent sur une population d'individus. Ces individus contiennent l'information décrivant la solution qu'ils représentent. Cette information est désignée par le terme de « génotype » par référence à la biologie, alors que la solution qu'ils représentent est nommée « phénotype ». Le génotype est l'information manipulée par les algorithmes évolutionnaires alors que le phénotype en est la traduction après développement, l'ensemble des phénotypes constituant le système dont on cherche à optimiser ou concevoir le comportement. Dans cet objectif, les individus subissent un processus de sélection dont les critères sont définis par le concepteur. Générations après génération, seuls les plus performantes survivent et se reproduisent dans le but de générer des descendants plus performants que leurs parents. L'objectif de la version artificielle de l'évolution est de maximiser une fonction d'adaptation. Cette fonction est représentative de la performance d'un individu dans un problème d'optimisation. Voici le principe d'un algorithme évolutionniste:

Nguyen Thanh Tuan 5


Population initiale

Figure 1 : Schéma général d'un algorithme évolutionniste (1) On commence par générer une première population d'individus de façon aléatoire. (2) On évalue la population à l'aide de la fonction d'adaptation choisie. (3) On sélectionne un sous-ensemble d'individus pour la reproduction à l'aide d'un opérateur de sélection. (4) On modifie les éléments sélectionnés par croisement et mutation afin de compléter la population. - L'opérateur de croisement permet l'échange de matériel génétique - L'opérateur de mutation transforme aléatoirement une partie du génome. (5) On évalue les nouveaux individus et on les insère dans la population pour créer une nouvelle population. (6) On réitère les opérations (2), (3), (4) et (5) jusqu'à ce que le critère d'arrêt défini au préalable soit respecté. Les algorithmes évolutionnistes diffèrent des algorithmes classiques d'optimisation et de recherche essentiellement en quatre points : - Les algorithmes évolutionnistes utilisent un codage des éléments de l'espace de recherche et non pas les éléments eux-mêmes. - Les algorithmes évolutionnistes recherchent une solution à partir d'une population de points et non pas à partir d'un seul point. - Les algorithmes évolutionnistes n'imposent aucune régularité sur la fonction étudiée (continuité, dérivabilité, convexité?).

Évaluation des individus

Sélection Croisement Mutation

Évaluation des individus

Nouvelle Population

Insertion dans la population

Nouvelle itération

Nguyen Thanh Tuan 6


- Les algorithmes évolutionnistes ne sont pas déterministes, ils utilisent des règles de transition probabilistes. Le grand avantage des algorithmes évolutionnistes est le fait que pour parvenir au résultat, on n'a pas besoin de connaître les caractéristiques de la solution du problème, mais seulement de déterminer parmi deux solutions quelle est la meilleure. Par contre ce genre d'algorithme est très coûteux en temps de calcul, difficile à contrôler (les paramètres comme la taille de la population et la fonction d'évaluation sont difficiles à établir).

1.1.3. Programmation génétique La programmation génétique (PG) est une méthodologie pour automatiquement produire des programmes informatiques. PG utilise les concepts de sélection naturelle et de recombinaison génétique dans une manière très semblable à celle utilisée avec les algorithmes génétiques. Plutôt qu'élaborer des populations d’individus de longueur fixée, PG élabore des programmes informatiques de grandeur et de forme variables. PG est fondé sur la prémisse que les programmes informatiques puissent être représentés comme les structures d'arbre, comme montré dans la figure 2.

f

T f

Figure 2 : Représentation sous forme d’arbre

Figure 3 : L'arbre de fonction T1 + T2*T3

Les fonctions (f) opèrent sur les terminaux (T) pour produire un résultat. Les fonctions sont des opérations qui prennent un ou plusieurs arguments. Ils peuvent être séquentiels, (c'est-à-dire, + ET), conditionnels (c'est-à-dire, Si, Quand), ou

T T

+

*T1

T2 T3

Nguyen Thanh Tuan 7


itératif (c'est-à-dire, DoUntil, WhileDo). Les terminaux sont des opérations qui ne prennent aucun argument, mais rendent une valeur (c'est-à-dire, des variables et constantes). La figure 3 montre une fonction arithmétique simple. Si les terminaux que T1, T2 et T3 évaluent à 3, 4 et 5, respectivement, donc le programme rendra la valeur 17 quand il est exécuté. (3 est multiplié à 4 pour une valeur intermédiaire de 12, qui est alors ajouté à 2 pour un résultat final de 14.) Ces diagrammes représentent de simples listes - comme les s-expressions qui s'ensuivent dans une production simple en haut. Dans cette forme la plus simple les fonctions sont tant séquentielles que déterministes, mais les fonctions et les terminaux peuvent être définis pour exécuter l'itération, récursive, le côté effectuant, l'évaluation de mémoire et d'autres opérations complexes. 5 étapes préliminaires pour exécuter une application de PG sont :

• Définissez l'ensemble de terminaux

• Définissez l'ensemble de fonctions

• Définissez la fonction de mesure de qualité (fixness)

• Définissez les paramètres (la taille de population, méthode de probabilité ou sélection, etc)

• Définissez la méthode pour désigner un résultat et le critère terminatif.

PG

Terminaux

Fonctions Fixness

Paramètres

Critère terminative

Une programme informatique

Figure 4 : 5 étapes préliminaires pour exécuter une application de PG

Le programmeur génétique définit un ensemble de fonctions et terminaux appropriés pour le problème à portée de la main. Ceux-ci peuvent inclure des fonctions extrêmement génériques, comme celles mentionnées ci-dessus, ou ils peuvent être spécifiques au domaine du problème. L'ensemble des fonctions et des terminaux définis doit satisfaire deux contraintes : suffisance et fermeture. La

Nguyen Thanh Tuan 8


suffisance exige qu'une solution du problème donné doive exister dans l'espace de tous les programmes informatiques possibles qui peuvent être créés en utilisant l'ensemble indiqué des fonctions et des terminaux. Évidemment, si une solution n'existe pas PG ne sera pas capable de la trouver. La fermeture exige que chaque fonction et terminal rendent une valeur de type compatible et que chaque fonction accepte des arguments de ce même type. Cette contrainte garantit que n'importe quelle combinaison de fonctions et de terminaux qui comprend une structure d'arbre complète (c'est-à-dire, un terminal est placé à chaque noeud de feuille) sera un programme informatique syntaxiquement valide qui peut être évalué. Le programmeur génétique définit aussi un test de condition physique qui quantifie

art un certain nombre de programmes

nt la duplication d'un individu de la génération

la performance d'un programme informatique. La performance d'un programme informatique dans PG peut être une fonction du résultat final qu'il produit, ou il peut être fondé sur une analyse d'un effet indésirable que le programme informatique a produit. Dans le travail présenté ici, la fonction et les jeux terminaux contiennent des opérateurs qui affectent les contenus d'une matrice de mémoire 2 dimensionnelle. L'état final de cette matrice est évalué pour déterminer la santé physique du programme informatique. Le processus de PG crée au dépinformatiques en combinant au hasard des fonctions et des terminaux dans les structures d'arbre complètes. On appelle cette collection de programmes, ou individus, une population. Le moteur PG évalue et alloue une valeur de santé physique à chacun des individus dans la population. La performance des individus dans cette population initiale, créée au hasard, peut être tout à fait faible. Quand même, il y a le désaccord dans les niveaux de performance : certains individus jouent moins faiblement que d'autres. La population est classée selon la santé physique. Une nouvelle population est produite en choisissant des individus parmi la génération précédente pour participer aux opérations créatrices. Les individus sont choisis pour l'inclusion dans le processus créateur basé sur leur santé physique - plus haute la santé physique, plus haute la probabilité d'inclusion. Trois opérations créatrices fondamentales sont utilisées dans PG : la reproduction, le croisement et la mutation (2). La reproduction est simplemeprécédente dans la génération suivante sans aucune modification de sa structure.

Nguyen Thanh Tuan 9


Génération 1 Génération 2

+ +

Figure 5 : Reproduction

La mutation est exécutée en choisissant aléatoirement un noeud dans une structure d'arbre individuelle et en enlevant ce noeud et le sous-arbre qui peut exister au-dessous de lui. Un nouveau sous-arbre est alors produit au hasard et "est greffé dans" la position où le noeud original a été enlevé.

* T1

T2 T3

*T1

T2 T3

Nguyen Thanh Tuan 10


Génération 2

+

1*

x x

+

-

2

*

x x +

x x

Génération 1

f(x) = x*x + 1

f(x) = x*x + x + x -2

Figure 6 : Mutation Le croisement implique de choisir deux individus et de choisir un noeud au hasard dans chacun d'entre eux. Les noeuds choisis, avec les sous-arbres qui existent au-dessous d'eux, sont échangés entre les deux individus.



Génération 1 Génération 2

+ +

Figure 7 : Croisement

Comme les populations successives sont créées en appliquant ces opérateurs génétiques, la performance moyenne de la population a tendance à s'améliorer. La performance du meilleur individu dans la population peut s'améliorer aux niveaux optimaux ou presque optimaux. Il n'y a aucune garantie, évidemment, que PG atteigne une solution optimale (en moins que le temps infini), mais si on réfléchit bien à l'ensemble des fonctions et les terminus avec un test de condition physique raisonnable, PG produira d'habitude de bons résultats.

1.1.4. Les ADFs Dans cette variation les arbres multiples sont élaborés par individu (Koza, 1992 et 1994). Un arbre, comme dans l'exemple de programmation génétique décrit dans les sections 1.1.3, fait les comptes qui sont rendus comme la production du programme. On appelle cet arbre la branche produisant résultat. Les autres arbres définissent des fonctions qui peuvent être appelées par le programme dans le processus de faire ses calculs. Cela permet à l'évolution de décomposer un problème en plusieurs sous-problèmes et de combiner ces unités élémentaires de structure dans la solution complète. Pour la rétrogradation symbolique, par exemple, les ADFs (automatically defined functions) pourraient évoluer qui calculent les termes communs dans une fonction.

x*

x x

**

3x x x

++

-

2

*

x 3 +

x x

-x

+ 2

x x



Dans le résultat produisant la branche, ces ADFs pourraient alors être référés en plusieurs endroits, plutôt qu'exiger l'évolution en duplicata de leur fonctionnalité dans les endroits séparés à l'intérieur d'un arbre. En utilisant des ADFs il est nécessaire de spécifier combien de fonctions seront définies par l'évolution et les nombres d'arguments que chaque ADF exige. Cela peut être fait avant que l’exécution commence, ou pendant l’exécution, par l'adjonction d'opérateurs génétiques qui agissent sur les ADFs (Koza, 1994). De tels opérateurs prennent un individu et ajoutent ou soustraient des ADFs, ou modifient le nombre d'arguments qu'un ADF spécifique prend. Quelle que soit la façon que les ADFs sont dirigés, leur adjonction exige des opérateurs génétiques nouveaux, plus complexes qui respectent la structure de programmes avec les ADFs. Cette complexité supplémentaire, pourtant, a des avantages. Koza a montré que pour les problèmes qui sont décomposable en sous-problèmes, l'adjonction de ADFs peut réduire l'effort quantificatif exigé pour trouver une solution réussie (Koza, 1992, 1994 et 1999).

corps del ’ADF corps du programme

programme

defun log

adf_0

liste des noms des arguments

adf_0

Figure 8 : Un exemple d'ADF

1.1.5. Paralléliser les algorithmes évolutionnistes Nous allons voir rapidement les trois principales méthodes. Une quatrième consiste à construire un AE hybride combinant celles-ci.

• La parallélisation globale: ce type fait évoluer une seule population mais l'évaluation des individus et/ou l'application des opérateurs génétiques se

x

(arg_0) *

arg_0 arg_0

nom de l ’ADF



fait en parallèle (voir figure 8). Le calcul de la qualité des individus de la population qu’il sera chargé d’évaluer. Ce calcul étant indépendant du reste de la population, aucune communication entre les processeurs n’est nécessaire entre le moment où un processeur reçoit ses individus et celui où il renvoie leurs qualités. L’application des opérateurs génétiques peut être faite en parallèle en suivant le même principe, mais elle nécessite de nombreuses communications entre processeurs et il est probable que leur coût compense les gains obtenus.

Maître

Esclaves Esclaves Esclaves

Figure 9 : La parallélisation globale

Comme il n’y a qu’une population, chaque individu est en compétition avec tous les autres et a des chances de participer à la phase de reproduction avec n’importe quel autre. Ainsi, si l’implantation est telle que le processeur maître attend que tous les processeurs esclaves aient terminé leurs calculs avant de passer à la génération suivante (c’est le cas en général), la sélection et la reproduction restent globales et le comportement de l’algorithme séquentiel n’est pas modifié ; on peut donc lui appliquer la théorie de l’algorithme séquentiel. Cette méthode est efficace lorsque l’évaluation des individus nécessite un traitement assez long et que le coût des communication n’est pas trop important.

• La parallélisation à gros grain : la population est divisée en quelques

sous-populations, qui évoluent isolées les unes des autres, mais échangent les individus occasionnellement. Cet échange d’individus est appelé migration. Il existe différentes stratégies pour contrôler la migration. Ces algorithmes introduisent donc des paramètres supplémentaires par rapport à l’algorithme séquentiel : nombre de sous-populations (et donc taille des sous-populations), taux de migration (nombre d’individus échangés), fréquence de migration ; ils nécessitent également des choix de stratégie pour la migration, le replacement de ces individus dans la sous-population



qui accueille (choix des individus remplacés) et le choix d’une topologie pour la migration des individus (déterminant les connections entre les sous-populations). Ces paramètres ont un impact très important sur l’efficacité de l’algorithme, tant du point de vue de la rapidité que de la qualité des solutions, ce qui rend complexe la mise au point de tels algorithmes.

Sous-population Sous-population Migration

Figure 10 : La parallélisation à gros grain

• La parallélisation à grain fin : ce modèle associe à la population totale une structure spatiale. L'GP fait évoluer la population entière, mais la sélection et la reproduction sont locales. En effet, la qualité d’un individu est calculée en fonction des individus se trouvant dans un voisinage restreint (relativement à la structure spatiale de la population) et la reproduction ne se fait qu’entre individus voisins. Cependant, le recoupement des voisinages permet de propager les bonnes caractéristiques dans la population entière. Ce modèle est adapté aux machines massivement parallèles. Ce type d’AE peut être implanté de différentes façons, suivant la structure du voisinage (topologie, rayon) et les stratégies de sélection des meilleurs individus et des couples pour la reproduction. Là encore le fonctionnement de l’algorithme séquentiel est modifié.

1.1.6. La bibliothèque ECJ ECJ est un système de EC (Evolution Computing) écrit en Java. ECJ est développé au ECLab d'Université de George Mason. Il a été conçu pour être extrêmement flexible, avec presque toutes les classes (et tous leurs cadres) dynamiquement déterminées à la durée d'exécution par un fichier de paramètres fourni par l'utilisateur. Toutes les structures dans le système sont arrangées pour être facilement modifiables. Quand même, le système a été conçu avec un oeil vers l'efficacité.

Sous-population Sous-population

Migration Migration

Migration



1.2. Coordination globale de comportements coopératifs

1.2.1. Introduction On peut définir le problème du contrôle de la coordination spatiale : Contrôler la coordination spatiale d'un groupe d'agents nécessite d'être capable à chaque instant de positionner et d'orienter correctement chacun des agents en fonction du déplacement de tous les autres, et ce de manière à satisfaire les objectifs collectifs du groupe. Les propriétés d'un contrôleur coordination spatiale sont :

• Couplage : o Couplé : Le déplacement d'un agent dépend de sa situation par

rapport à l'environnement ainsi que du déplacement des autres agents.

o Découplé : Le déplacement d'un agent se fait sans connaître la réaction de tous les autres.

• Centralisation o Décentralisé : à chaque agent de déterminer individuellement son

propre déplacement o Centralisé : tous les déplacements des agents sont définis à partir de

tous les indices observables de coopération. • Réactivité au sens temps-réel : Sa complexité algorithmique est

suffisamment faible pour que son temps de réaction lui permette de répondre aux changements de l'environnement.

• Flexible : Il suffit de modifier les valeurs de ses paramètres pour qu'il puisse résoudre un problème de coordination spatiale de classe différente.

• Modularité : on peut isoler des sous-parties réutilisables de contrôleur

1.2.2. GACS : conception automatisée de contrôleurs de coordination spatiale

Modèle de synthèse des contrôleurs à base de champs de force :

Figure 11 : L'architecture globale du modèle de synthèse



L’architecture globale du modèle de synthèse : construction en trois étapes (1,2,3) de chaque force Fk à partir du triplet {Pk, Ik, Gk} et détermination finale de la consigne de déplacement (4). Un agent A perçoit dans son environnement λ éléments. La fonction direction dk permet de déterminer la direction de la kième

force en donnant la position du point d’intérêt Pk à partir de la position de certains éléments perçus (1). Ensuite l’intensité Ik de la force Fk est obtenue par la fonction ik quand on lui donne en entrée la distance |APk| de l’agent A au point d’intérêt Pk (2). À partir des λ éléments perçus par l’agent dans son environnement, la fonction gk donne le gain Gk que l’on va multiplier à l’intensité Ik pour obtenir la force Fk (3). Enfin δ triplets sont déterminés de manière similaire et servent à calculer la consigne en déplacement grâce à la fonction de normalisation (4). Les composants d'une force sont : direction, intensité, gain. Les types de fonction de direction sont unitaire, barycentrique et glissante. Les types de fonctions d'intensité constante, linéaire, linéaire par morceaux. Les types de fonctions de gain : constante, relative

Figure 12 : Une exemple de modèle GACS

Force 1 : F1 = (d1,i1,g1) Force 2 : F2 = (d2,i2,g2) Force F : F = F1 + F2

F1

Point d’intérêt

F2

F



Chapitre 2. REALISATION

2.1. Description du problème

2.1.1. L’environnement L’environnement est représenté par une matrice de taille variable contenant 2 parties :

- Une partie correspondant à l’espace de recherche dans lequel les briques sont réparties au début de la simulation (à droite)

- Une zone de dépôt correspondant à l’endroit où les robots doivent entreposer les briques.

Il est possible de modifier différents paramètres de l’environnement : - Le nombre de briques - La répartition des briques dans l’environnement :

- Aléatoirement. - rangées dans la partie droite de l’environnement et fortement

rapprochées. - Rangées dans la partie droite de l’environnement, mais assez distantes

les unes des autres. - Le nombre de robots

Figure 13 : Un exemple de l'environnement



2.1.2. Les robots Les robots ont un but commun : à partir des briques réparties dans l’environnement, ils doivent rechercher les briques et déplacer les briques de leur endroit à la zone de dépôt en nombre de mouvements limité. Chaque robot a les caractéristiques suivantes :

- La distance de vision qui définit les capacités d’exploration des robots. - La vitesse de transport des briques lorsque le robot est chargé

Chaque robot a les capacités suivantes : - Eviter les obstacles et orienter. - Rechercher les briques - Porter les briques - Poser les briques

2.1.3. Redéfinition du problème Maintenant, que nous avons bien défini les caractéristiques initiales du problème de la façon suivante : « connaissant les capacités de chaque robot, quel est le meilleur programme de contrôle des robots pour trouver et rapporter les briques en nombre de mouvements limitée dans un environnement donné ?» Nous voulons de plus étudier les implications d’un changement d’environnement (positionnement initial des briques, taille de l’espace de recherche, nombre de briques ou nombre de robots) ou une modification des caractéristiques des robots sur la répartition des rôles des robots.

2.2. Codage pour problème

2.2.1. Tableau de Koza Le problème peut être présenté avec tableau suivant :

Objectif Chercher une application qui, quand exécuté par une groupe de robots, permet de trouver et rapporter les briques.

Ensemble des terminaux Aller, Orienter, Retourner, Poser, Porter. Ensemble des fonctions Progn, ADF1, ADF2 Cas de Fitness Un fitness Fitness cru Nombre de briques apportées à destination pendant le

temps alloué Fitness normal Nombre de briques moins fitness cru Note Égale au fitness cru pour ce problème



Paramètres M = 500, G = 51. Confirmer succès Une expression a des notes = somme de briques

Figure 14 : Tableau de Koza Tour d’abord, on définit l’ensemble des terminaux. On utilise 4 terminaux : Aller : chercher les briques. Retourner : retourner au dépôt. Poser : poser une brique. Porter : porter une brique. Orienter : orienter, on applique la modèle GACS, les robots sont orientés selon les forces des autres objets. Il y a deux cas : Le cas 1 : Le robot ne porte pas de brique. Il y a deux forces :

• Force 1 : Le robot le plus proche

• Force 2 : La brique la plus proche

F2

F1 F = F1 + F2

Figure 15 : Le cas : robot ne porte pas de brique



Le cas 2 : Il y a trois forces :

• Force 1 : Le robot le plus proche

• Force 2 : La brique la plus proche

• Force 3 : Le dépôt

F2

F1

F = F1+ F2 + F3

F3

Figure 16 : Le cas : robot porte une brique Le cas 3 : Il n’y a pas de force ou somme de force égale 0 : choisir une direction aléatoire. Dans cette application, on utilise une fonction Progn avec (deux arguments) et 2 ADFs. Le fixness est fixé et les paramètres peuvent être définis dans chaque expérimentation.

2.2.2. Parallélisation • Modèle Master-Slave



Master

Slave 2

Slave 1

Slave 3

Figure 17 : Modèle physique « Master-Slave » On utilise 4 ordinateurs. Un ordinateur joue le rôle de serveur (Master), il contrôle l’application (les paramètres, les opérations génétiques…) et envoie les demandes aux autres ordinateurs dans le système. Les autres sont les clients (slaves). Ils exécutent les demandes du serveur. Dans notre expérimentation, le serveur envoie les individus aux clients avec demande d’évaluation de ces individus, et les clients renvoient les « fixness » des individus.

Individu 1 Individu 2 Individu 3 …………

Individu 1

Fixness 1

Individu 2

Fixness 2

Individu 3

Fixness 3

Figure 18 : Un exemple • Modèle « Islands » :



Avec ce modèle, on utilise 4 ordinateurs comme 4 « islands ». Chaque « island » est une sous-population indépendante et côtoie les autres « islands ». Un ordinateur qui a le rôle de serveur contrôle les paramètres et résume le résultat.

Island 1

Island 3

Island 2

Island 4

Serveur + Client Sous-population 1

Client Sous-population 2



Figure 19 : Modèle physique "Islands"

Le modèle “Islands” utilise une topologie arbitraire des individus migrant de l'île (le processus de EC) pour passer sur le réseau. Il y a quelques restrictions pour simplifier:

• Chaque île doit avoir la même sorte de sous-populations et d'espèces. • Chaque sous-population enverra le même nombre de migrants qu'une autre

sous-population. • Les migrants d'une sous-population iront dans la même sous-population.

Chaque île est un client. Supplémentairement une île est désignée comme serveur. Le but du serveur est de synchroniser les clients pour qu'ils soient tous montés correctement et liés l'un à l'autre, ensuite de leur envoyer de petits messages de signal (comme ceux les informant qu'un autre client a découvert l'individu idéal) et les aider à se fermer. A l’exception de ces rares signaux qui sont routés par le serveur ver sles clients, tous les autres renseignements - à



savoir les migrants eux-mêmes - sont envoyés directement de client à client dans un mode peer-to-peer.

Le topologie du réseau est conservée uniquement dans la base de données de paramètrage du serveur. Quand les clients sont pleins, ils remplissent une boîte aux lettres "mail-box" (où les migrants d'autres clients apparaîtront), puis ils vont chez le serveur et lui demandent qu'il les raccorde pour envoyer les migrants. Le serveur leur donne le feu vert et ensuite ils se connectent.

Quand un client a fini de se connecter, il le signale au serveur. Après que chacun s'est connecté, le serveur dit aux clients de commencer l'évolution et ils sont déconnectés et lancés.

Les îles envoient des émigrants à d'autres îles en copiant les bons individus et en envoyant ces bons individus aux boîtes aux lettres de réception des clients. Dès qu'un individu a été reçu, on considère qu’il est non évalué par l'île de réception, bien qu'il ait été auparavant évalué par l'île de l’émetteur.

Le modèle de « Islands » est d'une manière caractéristique asynchrone parce que les migrants peuvent apparaître dans votre boîte aux lettres d'un moment à l'autre; les îles ne s'attendent pas pour accomplir la génération suivante. C'est un usage plus efficace de bande de fréquence de réseau. Quand une île a accompli sa reproduction, elle regarde à l'intérieur de sa boîte aux lettres pour de nouveaux migrants. Elle remplace alors certains de ses individus nouvellement produits (choisis entièrement au hasard) par les migrants (nous pourrions avoir augmenté la grandeur démographique donc nous n'avons pas gaspillé ce temps de reproduction, mais nous étions indolents). Elle fait alors partir la boîte aux lettres et avec patience attend plus d'individus.

On peut aussi donner des temps de début différents aux clients et des modulos pour le fait de migrer. Par exemple, on pourrait dire au client A qu'il commence à envoyer les migrants seulement après la génération 6 et envoie ensuite les migrants toutes les 4 générations à part cela. Le but pour les temps de début et modulos consiste en ce pour que pas chaque client envoie des migrants en même temps; cela utilise aussi mieux la bande de fréquence de réseau.

Quand un client tombe, les autres clients s'en occupent ; ils arrêtent simplement d'essayer de lui envoyer. Mais si le serveur tombe, les clients ne continuent pas l'opération; ils se ferment. Cela signifie qu'en général vous pouvez fermer un réseau de modèle « Islands » entier juste en tuant le processus de serveur. Pourtant, si le serveur arrête parce qu'il manque des générations, il attendra que tous les clients aient quitté avant de s'arrêter finalement.



Chapitre 3. EXPERIMENTATION

3.1. Modification des paramètres Durant ces expérimentations, nous avons voulu étudier la flexibilité de notre système, c'est-à-dire les capacités de celui-ci à s’adapter à une ou plusieurs modifications dans l’environnement. Les sections suivantes exposent les principaux résultats que nous avons obtenus.

3.1.1. Adaptation au changement d’environnement Dans cette première expérience, nous avons voulu tester les capacités de programmation génétique à trouver le meilleur programme possible lorsque l’on répartissait les briques de différentes façons dans l’environnement (aléatoire, à droite, espacées). Pour cela, nous avons placé 7 robots dans un environnement de taille 16x16 contenant 25 briques. Les caractéristiques des robots (visions, vitesse) ont été fixées.

Figure 20 : Trois type d'environnement : à droite, aléatoire et espacé Sans utiliser les ADFs, on a les résultats suivants :

Note Nombre d’individus Temps

Espacées 25 18432 13.743

Aléatoire 20 52224 35.103

À droite 11 52224 38.413

Figure 21 : Résultat sans utiliser ADFs



Et avec les ADFs :

Note Nombre d’individus Temps

Espacées 25 20480 15.608

Aléatoire 19 52224 26.002

À droite 8 52224 27.704 Figure 22 : Résultat avec ADFs

25

20

11

25

19

8

0

5

10

15

20

25

30

Espacées Aléatoire À droite

Non ADFADF

Figure 23 : Graphiques des résultats Dans le cas d’un environnement avec les briques rangées espacées, le nombre de briques collectées est le meilleur.

3.1.2. Modification du nombre de robots Nous avons testé l’effet d’une modification du nombre de robots. Pour cela, nous avons utilisé un environnement de taille 16x16 contenant 25 briques et les briques rangées espacées. Dans cette expérimentation, nous avons utilisé les ADFs. Nous obtenons les résultats décrits dans le tableau suivant:

Nombre de robot Note Nombre de

individu Temps

3 24 52224 44.129

7 25 19456 18.912

11 25 7168 8.042 Figure 24 : Résultat d'expérimentation de modification du nombre de robots

On a le graphique :



20480 19456

7168

0

5000

10000

15000

20000

25000

3 7 11

Nombre d'individus

Figure 25 : Graphique de résultat de modification Dans tous les cas, le nombre de briques collectée est maximum, mais dans le cas où le nombre de robots est égal 11, le nombre d’individu est moindre, c'est-à-dire qu’on obtient le résultat plus rapidement.

3.2. Parallélisation Dans cette expérience, nous avons voulu tester les capacités de programmation génétique parallélisée. Pour cela, nous avons placé 21 robots dans un environnement de taille 100x100 contenant 1089 briques. Les caractéristiques des robots (visions, vitesse) ont été fixées. Les tests sont réalisé sur un réseau contenant 4 ordinateurs : Pentium 4, vitesse 1.8 Gh, mémoire 512 MB. Nous obtenons les résultats décrits dans les tableaux suivants: Avec modèle Master-Slave : Le résultat :

Modèle Note Nombre d’individus Temps

Master-Slave 339 52224 748.547 Figure 26 : Résultat du modèle "Master-Slave"



Avec le modèle « Islands » : Les paramètres :

Islands Nombre d’îles à laquelle cette île envoie des migrants

Nombre de migrants (sur sous-population) que cette île envoie à une autre.

Génération à partir de laquelle cette île commence à envoyer des migrants

Nombre de générations que cette île attend pour envoyer des migrants.

Taille maximum (sur sous-population) de la boîte aux lettres

Hoang Sa 3 40 2 4 200

Truong Sa 3 40 3 4 200

Con Dao 3 40 5 4 200

Phu Quoc 3 40 7 4 200 Figure 27 : Les paramètres du modèle « Islands »

Les résultats :

Islands Note Nombre d’individus Temps (secondes)

Hoang Sa 349 52224 1543.469

Truong Sa 315 52224 2414.608

Con Dao 346 52224 2455.779

Phu Quoc 338 52224 1918.751

Maximum 349 52224 2455.779 Figure 28 : Résultat du modèle "Islands"

Sur un seul ordinateur :

Modèle Note Nombre d’individu Temps (seconds)

Un ordinateur 344 52224 2905.626 Figure 29 : Résultat sur un seul ordinateur



344

339

349

330

335

340

345

350

Un ordinateur Master-Slave Islands

Note

Figure 30 : Graphiques de trois modèle selon la note

2905.626

748.547

2455.779

0500

100015002000250030003500

Un ordinateur Master-Slave Islands

Le temps

Figure 31 : Graphique de trois modèles selon le temps Dans le cas du modèle « Master-Slave », le temps perdu est le plus faible. En effet, ce modèle est meilleur. Dans le cas du modèle « Islands », on peut améliorer le résultat en changeant les paramètres (taux de migration…) ou en ajoutant plusieurs ordinateurs.



CONCLUSION ET PERSPECTIVES Dans ce rapport, nous avons vu un problème de coordination entre robots pour réussir à collecter des briques dans un environnement. Selon les types d’environnement, il y a des résultats différents. Nous avons proposé une approche intéressante qui permet de trouver le meilleur programme de contrôle. Les expérimentations que nous avons mises en place ont montré les capacités d’adaptations de l’application dans la résolution de notre problème. En effet, la modification du nombre de robots permet de déterminer le nombre de robots nécessaires. Pour améliorer les résultats, on a parallélisé l’application. Et les résultats sont vraiment meilleurs. Toutefois, certains points de l’application restent encore à améliorer: On a seulement utilisé un mécanisme le plus simple du modèle GACS. Il y a 36 mécanismes différents. Et on peut déterminer avec les autres mécanismes dans modèle GACS. On peut combiner la bibliothèque ECJ avec une application de simulation pour visualiser les résultats.



Référence [BLANC06] Sylvain CUSSAT-BLANC, Luu Thien DO, Yves DUTHEN,

Hervé LUGA : Constitution d’équipes pour la construction collaborative d’un mur de briques (IRIT - Université Toulouse I, 2006).

[FLACHER05] F. FLACHER: Génération ascendante de coordination spatiale - Vers une conception automatisée du contrôle de coordination spatiale (PhD Thesis, Universitaire Paris 6, 2005).

[GAGNE,03] Christian Gagne,Marc Parizeau,Marc Dubreuil Laboratoirede Visionet Systemes Numeriques(LVSN), Departement de Genie Electrique et de Genie Informatique, Universite Laval, Quebec(QC), Canada, G1K7P4. A Robust Master-Slave Distribution Architecture for Evolutionary Computations,2003

[GOLDBERG89] D.E. GOLDBERG: Genetic Algorithms in Search, Optimization, and Machine Learning (Addison-Wesley, Reading, Mass., 1989).

[HOLLAND75] J.H. HOLLAND: Adaptation in Natural and Artificial Systems (The University of Michigan press, 1975).

[KOZA92,94,99] Koza J. R: Genetic Programming 1,2,3 (MIT Press, 1992,1994,1999).

[LUKE02] Sean Luke, ECJ Evolutionary Computation System, Seen Janaury 07, 2003 at http://cs.gmu.edu/~eclab/projects/ecj/

[LUU06] LUU Tien Dao: Efficacité et coopération (Master 2 Recherche These, Image Information Hypermédia, 2006).

[RECHENBERG73] Rechenberg I., Evolution strategie : Optimierung Technisher System nach Prinzipien des Biologischen Evolution, Fromman Holzboog, Stuttgart , 1973.

[SKOLICKI05] Zbigniew Skolicki, An Analysis of Island Models in Evolutionary Computation. In Proceedings of Graduate Student Workshop, Genetic and Evolutionary Computation Conference -- GECCO-2005. ACM Press.


http://cs.gmu.edu/%7Eeclab/projects/ecj/


L’ANNEXE

A. Un fichier paramètre parent.0 = ../../gp/koza/koza.params # First, we're gonna change the number of trees in # the individual, to accommodate the ADFs # Each of our three trees uses a different tree constraints, # tc0, tc1, tc2 pop.subpop.0.species.ind.numtrees = 3 # "The result-producing branch" (Koza-II p. 245) pop.subpop.0.species.ind.tree.0 = ec.gp.GPTree pop.subpop.0.species.ind.tree.0.tc = tc0 # "ADF0 body" (Koza-II p. 245) pop.subpop.0.species.ind.tree.1 = ec.gp.GPTree pop.subpop.0.species.ind.tree.1.tc = tc1 # "ADF1 body" (Koza-II p. 245) pop.subpop.0.species.ind.tree.2 = ec.gp.GPTree pop.subpop.0.species.ind.tree.2.tc = tc2 # Now, let's define what tc0, tc1, and tc2 are. # Each has a different function set, f0, f1, and f2 gp.tc.size = 3 gp.tc.0 = ec.gp.GPTreeConstraints gp.tc.0.name = tc0 gp.tc.0.fset = f0 gp.tc.0.returns = nil gp.tc.0.init = ec.gp.koza.HalfBuilder gp.tc.0.init.growp = 0.5 gp.tc.0.init.min = 2 gp.tc.0.init.max = 6 gp.tc.1 = ec.gp.GPTreeConstraints gp.tc.1.name = tc1 gp.tc.1.fset = f1 gp.tc.1.returns = nil gp.tc.1.init = ec.gp.koza.HalfBuilder gp.tc.1.init.growp = 0.5 gp.tc.1.init.min = 2 gp.tc.1.init.max = 6



gp.tc.2 = ec.gp.GPTreeConstraints gp.tc.2.name = tc2 gp.tc.2.fset = f2 gp.tc.2.returns = nil gp.tc.2.init = ec.gp.koza.HalfBuilder gp.tc.2.init.growp = 0.5 gp.tc.2.init.min = 2 gp.tc.2.init.max = 6 # Now, let's define the three function sets. gp.fs.size = 3 gp.fs.0.name = f0 gp.fs.0.info = ec.gp.GPFuncInfo gp.fs.0.size = 8 gp.fs.0 = ec.gp.GPFunctionSet gp.fs.0.func.0 = ec.app.contruction.func.Fo gp.fs.0.func.0.nc = nc0 gp.fs.0.func.1 = ec.app.contruction.func.Pb gp.fs.0.func.1.nc = nc0 gp.fs.0.func.2 = ec.app.contruction.func.Aller gp.fs.0.func.2.nc = nc0 gp.fs.0.func.3 = ec.app.contruction.func.Tb gp.fs.0.func.3.nc = nc0 gp.fs.0.func.4 = ec.app.contruction.func.Retourner gp.fs.0.func.4.nc = nc0 gp.fs.0.func.5 = ec.app.contruction.func.Progn gp.fs.0.func.5.nc = nc2 gp.fs.0.func.6 = ec.gp.ADF gp.fs.0.func.6.nc = nc0 # tree 1 (the "ADF0 body") gp.fs.0.func.6.tree = 1 gp.fs.0.func.6.name = 0 gp.fs.0.func.7 = ec.gp.ADF gp.fs.0.func.7.nc = nc1 # tree 1 (the "ADF1 body") gp.fs.0.func.7.tree = 2 gp.fs.0.func.7.name = 1



# It's interesting that in the "ADF0 body", gp.fs.1 = ec.gp.GPFunctionSet gp.fs.1.name = f1 gp.fs.1.info = ec.gp.GPFuncInfo gp.fs.1.size = 6 gp.fs.1.func.0 = ec.app.contruction.func.Fo gp.fs.1.func.0.nc = nc0 gp.fs.1.func.1 = ec.app.contruction.func.Pb gp.fs.1.func.1.nc = nc0 gp.fs.1.func.2 = ec.app.contruction.func.Aller gp.fs.1.func.2.nc = nc0 gp.fs.1.func.3 = ec.app.contruction.func.Tb gp.fs.1.func.3.nc = nc0 gp.fs.1.func.4 = ec.app.contruction.func.Retourner gp.fs.1.func.4.nc = nc0 gp.fs.1.func.5 = ec.app.contruction.func.Progn gp.fs.1.func.5.nc = nc2 # The "ADF1 body" -- see Koza-II p. 245 gp.fs.2 = ec.gp.GPFunctionSet gp.fs.2.name = f2 gp.fs.2.info = ec.gp.GPFuncInfo gp.fs.2.size = 6 gp.fs.2.func.0 = ec.app.contruction.func.Fo gp.fs.2.func.0.nc = nc0 gp.fs.2.func.1 = ec.app.contruction.func.Pb gp.fs.2.func.1.nc = nc0 gp.fs.2.func.2 = ec.app.contruction.func.Aller gp.fs.2.func.2.nc = nc0 gp.fs.2.func.3 = ec.app.contruction.func.Tb gp.fs.2.func.3.nc = nc0 gp.fs.2.func.4 = ec.app.contruction.func.Retourner gp.fs.2.func.4.nc = nc0 gp.fs.2.func.5 = ec.app.contruction.func.Progn gp.fs.2.func.5.nc = nc2 # # We specify our problem here # eval.problem = ec.app.contruction.Robot eval.problem.data = ec.app.contruction.RobotData eval.problem.robot = 7 eval.problem.vision = 1



eval.problem.speed = 1 eval.problem.moves = 400 eval.problem.file = testp.map eval.problem.stack.context.data = ec.app.contruction.RobotData #stat = ec.app.contruction.RobotStatistics

B. Un exemple de résultat Non – ADFs Final Statistics ================ Total Individuals Evaluated: 18432 Best Individual of Run: Evaluated: true Fitness: Raw=0.0 Adjusted=1.0 Hits=25 Tree 0: (Progn (Progn (Progn (Progn (Progn poser-brique porter-brique) (Progn orienter orienter)) (Progn (Progn porter-brique aller-a-brique) (Progn poser-brique poser-brique))) (Progn (Progn (Progn aller-a-brique porter-brique) (Progn (Progn (Progn (Progn (Progn (Progn aller-a-brique orienter) (Progn orienter retourner-a-depot)) (Progn (Progn orienter aller-a-brique) (Progn aller-a-brique retourner-a-depot))) (Progn aller-a-brique porter-brique)) (Progn



(Progn (Progn (Progn orienter retourner-a-depot) (Progn orienter porter-brique)) (Progn (Progn retourner-a-depot retourner-a-depot) (Progn poser-brique retourner-a-depot))) (Progn (Progn (Progn orienter retourner-a-depot) (Progn retourner-a-depot (Progn orienter porter-brique))) (Progn (Progn poser-brique aller-a-brique) (Progn poser-brique aller-a-brique))))) (Progn aller-a-brique porter-brique))) (Progn porter-brique porter-brique))) (Progn (Progn (Progn (Progn retourner-a-depot orienter) (Progn porter-brique poser-brique)) (Progn (Progn aller-a-brique retourner-a-depot) (Progn aller-a-brique poser-brique))) (Progn (Progn (Progn (Progn (Progn aller-a-brique orienter) (Progn aller-a-brique retourner-a-depot)) (Progn (Progn aller-a-brique retourner-a-depot) (Progn porter-brique poser-brique))) (Progn (Progn (Progn porter-brique porter-brique) (Progn orienter retourner-a-depot)) (Progn (Progn porter-brique poser-brique) (Progn aller-a-brique porter-brique)))) (Progn (Progn orienter (Progn (Progn (Progn retourner-a-depot



orienter) (Progn porter-brique poser-brique)) (Progn (Progn aller-a-brique retourner-a-depot) (Progn aller-a-brique poser-brique)))) (Progn poser-brique retourner-a-depot))))) Timings ======= Initialization: 0.194 secs total, 28446 nodes, 146628.86 nodes/sec Evaluating: 10.337 secs total, 1886254 nodes, 182475.97 nodes/sec Breeding: 3.21 secs total, 1857808 nodes, 578756.4 nodes/sec Memory Usage ============== Initialization: 1243.7266 KB total, 28446 nodes, 22.871586 nodes/KB Evaluating: 8535.969 KB total, 1886254 nodes, 220.97714 nodes/KB Breeding: 32284.625 KB total, 1857808 nodes, 57.544666 nodes/KB Avec ADFs Final Statistics ================ Total Individuals Evaluated: 20480 Best Individual of Run: Evaluated: true Fitness: Raw=0.0 Adjusted=1.0 Hits=25 Tree 0:



(ADF1[2] (ADF1[2] (Progn (ADF1[2] (ADF1[2] (ADF1[2] aller-a-brique))) (ADF1[2] retourner-a-depot)))) Tree 1: (Progn porter-brique retourner-a-depot) Tree 2: (Progn (Progn (Progn (Progn (Progn poser-brique orienter) (Progn (Progn retourner-a-depot retourner-a-depot) (Progn aller-a-brique aller-a-brique))) (Progn (Progn aller-a-brique orienter) (Progn retourner-a-depot aller-a-brique))) (Progn (Progn (Progn aller-a-brique porter-brique) (Progn retourner-a-depot retourner-a-depot)) (Progn (Progn poser-brique orienter) (Progn aller-a-brique porter-brique)))) (Progn (Progn (Progn (Progn retourner-a-depot porter-brique) (Progn orienter porter-brique)) (Progn (Progn retourner-a-depot porter-brique) (Progn aller-a-brique retourner-a-depot))) (Progn poser-brique aller-a-brique))) Timings ======= Initialization: 0.165 secs total, 32526 nodes, 197127.27 nodes/sec Evaluating: 13.057 secs total, 1483532 nodes, 113619.664 nodes/sec Breeding: 2.386 secs total, 1451006 nodes, 608133.3 nodes/sec



Memory Usage ============== Initialization: 1413.1016 KB total, 32526 nodes, 23.017454 nodes/KB Evaluating: 8345.3125 KB total, 1483532 nodes, 177.7683 nodes/KB Breeding: 32031.922 KB total, 1451006 nodes, 45.298748 nodes/KB


Rapport Final Travail Personnel Encadré Coordination globale de comportements coopératifs

Documents

Transcript of Rapport Final Travail Personnel Encadré Coordination globale de comportements coopératifs