nomoSDK : les bancs d'essais

Les bancs d'essais intégrés dans nomoSDK correspondent à deux environnements prédéfinis auxquels est associé réciproquement un modèle nomo. Ces environnements servent à tester des unités nomo avec un modèle de base imposé, ainsi que de support au tutoriel :

• l'environnement monde de dalles qui est plus adapté pour tester des comportements,
• l'environnement nuage de points qui est plus adapté pour tester l'évolution dynamique des règles dans une problématique de classification.

Le monde de dalles correspond à un univers composé d'un nombre fini de dalles sur une surface plane. Un fichier décrivant un monde de dalles a pour extension ”.map”.

Les dalles sont toujours de couleur et sur lesquelles peuvent flotter une sphère noire. Les agents se placent nécessairement sur une dalle. Les agents sont représentés par un parallélépipède rectangle similaire à une dalle mais de couleur gris-noir et dont la direction est signalée par un triangle de couleur différente pour chaque agent. Dans cet univers, les agents se déplacent de dalle en dalle. Deux agents ne peuvent se positionner sur une même dalle mais une sphère et un agent peuvent se trouver sur une même dalle.

La figure ci-dessous illustre une carte possible dans environnement du type monde de dalles :

L'envoie des événements est synchronisé sur les cycles d'interprétations. Après chaque cycle d'interprétation et après avoir assumé les éventuelles commandes, tous les états sensoriels de chaque agent sont envoyés, sauf la perception de l'échec d'une action qui dépend au préalable du déclenchement d'une action. Selon l'intensité des commandes envoyées aux agents, un délai à l’exécution de commande existe :

• entre 1 et 2/3, la commande est directement effectuée,
• entre 2/3 et 1/3, la commande est différée d'un cycle,
• entre 1/3 et 0, la commande est différée de deux cycles.

L'arrivée d'une commande supprime toutes les commandes ayant délais supérieurs à celle qui vient d'arriver.

Tous les programmes nomo décrivant les systèmes décisionnels des agents reposent sur un modèle ayant pour modèle de base worldsquare.

Le modèle de base, worldsquare, décrit les structures perceptives et les types de commandes communs à tous les agents d'un monde de dalles. Ce modèle servira de base pour tout modèle utilisé par un programme destiné au banc d'essai de type monde de dalle. Dans un programme destiné à un monde de dalles, il doit y avoir autant d'instances de modèles dérivant de worldsquare que d'agents.

Dans le monde de dalles, un agent peut faire deux types d'actions : les actions motrices et les actions sonores. Les actions sonores étant liés à la structure perceptive dédiée au son, elles seront décrites ultérieurement.

Les actions motrices sont modélisées par le type de commande nommé motor, son ensemble de définition correspond aux quatre actions motrices que peut effectuer un agent :

• turn_left commande de tourner à gauche de 45° par rapport à la direction de l'agent qui correspond à la valeur sortie output 0,
• turn_right commande de tourner à droite de 45° par rapport à la direction de l'agent qui correspond à la valeur sortie output 1,
• advance commande d'avancer d'une case dans la direction de l'agent qui correspond à la valeur sortie output 2,
• capture commande de capturer la sphère se trouvant au même endroit que l'agent qui correspond à la valeur sortie output 3,
• depose commande de déposer une sphère au même endroit où se trouve l'agent qui correspond à la valeur sortie output 4.

Les commandes advance, capture, depose peuvent ne pas aboutir. La commande d'avancer advance n’aboutit pas s'il y a déjà un agent sur la dalle ou une absence de dalle. De même, s'il n'y a pas de sphère, la commande capture ne peut aboutir. Dans ces cas-là, l'agent perçoit une résistance à accomplir sa tâche. Cette résistance est modélisée par la structure perceptive nommée strength et possède uniquement l'item failed et n'a pas vocation à être étendue ici puisque la résistance est traduite par une unique valeur.

Contrairement aux événements de type strength et de type sound qui surviennent de manière apériodique, les autres événements de types relatifs aux entrées sont envoyés après chaque cycle d'interprétations.

Il existe au total six autres structures perceptives, chacune modélisant une modalité perceptive :

• La perception de la teinte (nombre entier entre 0° et 360°) de dalle sur laquelle se trouve l'agent qui est modélisée par la structure perceptive nommée hue,
• La perception du nombre sphères possédées par l'agent qui est modélisée par la structure perceptive nommée spheres_number,
• La perception d'une variable aléatoire entre 0 et 1 qui est modélisée par la structure perceptive nommée random,
• La perception d'un son (traduit par un nombre entier entre 0 et 360) qui est modélisée par la structure perceptive nommée sound,
• La détection binaire de la présence de dalles connexes (1 dalle, 0 rien) dans les quatre directions (left, front, right back) qui est modélisée par la structure perceptive nommée bumper,
• La détection binaire d'une sphère ou d'un agent (1 quelque chose, 0 rien) dans les quatre directions quelle que soit la distance (left, front, right back) qui est modélisée par la structure perceptive nommée sonar.

La structure perceptive sound contient un type de commande. Le son correspond à la somme de tous les sons produits par les autres agents.

Les valeurs de commande reçues par le monde de dalle sont converti en nombre entier auquel un modulo idoine est appliqué de sorte que les commandes sont toujours applicables dans la limite du calcul numérique.

Ci-dessous le modèle de base worlsquare :

worldsquare.mod

<?xml version="1.0" encoding="utf-8"?>
<model name="worldsquare"
       xmlns="http://www.nomoseed.org/model"
       xmlns:project="http://www.nomoseed.org/project">
  <project:header>
    <project:author>
      Cédric Coussinet
    </project:author>
    <project:copyright>
      <project:mention xml:lang="en">
        Copyright - Cédric Coussinet (2011) - All rights reserved
      </project:mention>
    </project:copyright>
    <project:license name="GPL">
      <project:mention xml:lang="en">GNU GENERAL PUBLIC LICENSE</project:mention>
    </project:license>
  </project:header>
  <definition>
    <command_type name="motor">
      <items>
        <item name="advance"/>
        <item name="turn_left"/>
        <item name="turn_right"/>
        <item name="capture"/>
        <item name="depose"/>
      </items>
      <components>
        <component name="value"/>
      </components>
    </command_type>
    <perceptive_structure name="hue">
      <items/>
      <components>
        <component name="value"/>
      </components>
    </perceptive_structure>
    <perceptive_structure name="spheres_number">
      <items/>
      <components>
        <component name="value"/>
      </components>
    </perceptive_structure>
    <perceptive_structure name="strength">
      <items>
        <item name="failed"/>
      </items>
      <components>
        <component name="value"/>
      </components>
    </perceptive_structure>
    <perceptive_structure name="random">
      <items/>
      <components>
        <component name="value"/>
      </components>
    </perceptive_structure>
    <perceptive_structure name="sound">
      <command_type/>
      <items/>
      <components>
        <component name="value"/>
      </components>
    </perceptive_structure>
    <perceptive_structure name="sonar">
      <items/>
      <components>
        <component name="left"/>
        <component name="front"/>
        <component name="right"/>
        <component name="back"/>
      </components>
    </perceptive_structure>
    <perceptive_structure name="bumper">
      <items/>
      <components>
        <component name="left"/>
        <component name="front"/>
        <component name="right"/>
        <component name="back"/>
      </components>
    </perceptive_structure>
  </definition>
</model>

A l'ouverture ou à la création d'une carte, seule celle-ci est présente dans une fenêtre représentant le banc d'essai comme l'illustre la figure ci-dessous. La création d'une nouvelle carte qui se compose par défaut d'une dalle vierge.

A gauche se trouve le nom de la carte, il est possible de sélectionner une nouvelle carte en cliquant sur ce nom. L'ouverture d'une unité s'effectue en cliquant sur “sélectionner une unité”. Comme illustré ci-dessous, la carte éditée peut être modifiée.

La création d'une dalle s'effectue en cliquant sur un emplacement. En cliquant sur une dalle ou un agent, une fenêtre de contrôle apparaît. Cette dernière permet de modifier : * la teinte de la dalle et qui deviendra la teinte par défaut, * le nombre de sphère de l'agent représente le nombre de sphère par défaut à la création d'un nouvel agent, * la configuration de la dalle (sans rien, avec agent ou avec sphère), la configuration d'une dalle avec une sphère et un agent est obtenue en cliquant sur chacune de ces configurations)

La suppression d'un élément peut s’effectuer par un double clic sur ce dernier.

Les agents peuvent être déplacés par un cliquer/glisser. Les modifications de la carte peuvent être opérées en cliquant sur l’icône de sauvegarde en haut à gauche.

La sélection d'une unité fait apparaitre une interface de contrôle permettant de configurer les essais. L'unité sélectionnée est compilée et prête à l'emploi. En même temps, une vérification sur le nombre d'agents géré par l'unité est effectué : les agents supplémentaires se trouvant sur la carte sont transformés en blocs immobiles blancs que les autres agents ne peuvent franchir, comme l'illustre la figure ci-dessous. Les actions d'agents non représentés sur la carte ne sont pas prises en compte et aucune information sensorielle n'est envoyée. Une carte reste modifiable en dehors des phases d'essais.

Les flèches circulaires respectivement à gauche et à droite du nom de la carte et celui de l'unité permettent en cliquant dessus de recharger la carte ou l'unité.

Comme l'illustre la figure ci-dessous, l'interface de contrôle des essais se décompose en deux parties, l'une consacrée aux à la gestion de la journalisation et l'autre consacrée à l'ordonnancement de l'essai.

La journalisation de l'essai peut concerner les règles sélectionnées ou toutes les règles et peut être partielle ou complète. La journalisation s'effectue soit avant la sélection ou après la sélection. Enfin, il est possible de créer un nouveau fichier de journalisation au début de l'essai.

Dans la partie ordonnancement, le nombre de pas de l'essai est précisé. Si l'option avec animation est choisie, alors les pas se rouleront à une fréquence de 2Hz, aucune modification de la carte n'est permise pendant le déroulement de l'essai. Lorsque l'essai s'effectue sans animation, le cadencement se fait au plus rapide mais nomoInterpreter continuera à considérer que le cadencement est à 2Hz de sorte qu'une exécution avec ou sans animation produira un résultat identique. A la fin d'un essai, il est possible, comme le propose l'interface avec nomoInterpreter, de réinitialiser ou non nomoInterpreter et, de sauvegarder dans le répertoire se trouvant l'unité ou de mettre à jour la base de règles.

Pour lancer l'essai, il faut cliquer sur la flèche en bas à gauche de la zone d'affichage de la carte. Lorsque le nombre de pas est à un, cliquer successivement sur la flèche revient à un mode d’exécution pas à pas. Dans les deux bancs d'essai, les actions sont assumées au début du pas suivant.

Le banc d'essai de type nuage de points permet de tester des méthodes de classification dont les principales familles sont présentées dans le tutoriel.

L'objectif de ce banc d'essai est d'obtenir un aperçu qualitatif de la classification, pour une étude quantitative il faut s'orienter vers le module d'analyse de la journalisation.

Le banc d'essai lit un fichier contenant les données à envoyer au moment indiqué puis reçoit du nomoInterpreter le label associé à la donnée ainsi que le centroïde de la règle perceptive l'ayant capturée.

La base de donnée initiale est définie dans un fichier au format CSV qui a pour extension ”.pts”.

Ce fichier définit pour chaque vecteur de données : le pas d'envoi (time), un label (label), et les valeurs pour chaque composante du vecteur de données. Les pas d'envoi et les labels doivent être un nombre entier non nul. Les labels vont de 1 jusqu'au nombre de classes. Les données doivent également être triées en ordre croissant selon les pas d'envoi. Il ne doit pas y avoir de pas d'envois identiques.

Par exemple, les données iris-acp.pts proviennent de la projection de la base de données de référence iris dans un espace déterminé par une Analyse en Composantes Principales (ACP). La base de données iris¹⁾ regroupe les mesures effectuées en centimètre de la longueur et de la largeur des pétales et des sépales de 50 fleurs pour chacune des trois espèces d'iris suivante : setosa, versicolor, et virginica ²⁾.

Respectivement au trois espèces d'iris setosa, versicolor et virginica, les labels correspondent à 1,2,3. Le nom des composantes est à la discrétion de l'utilisateur. Voici les quatre premières lignes du fichier iris-acp.pts :

time,label,Comp.1,Comp.2,Comp.3,Comp.4
3,1,-2.684125626,-0.319397247,-0.027914828,0.002262437
6,2,1.284825689,-0.68516047,-0.406568025,0.018525288
9,3,2.531192728,0.009849109,0.760165427,-0.029055573
...

Lorsque le nombre de pas dépasse celui de la dernière donnée, alors il est appliqué un modulo plus un sur celui-ci. Autrement dit, le système reprend le cycle d'envoi depuis le début du fichier en considérant qu'il est au premier pas.

A noter que pour une visualisation cohérente, le nombre de pas séparant l'envoi de deux donnée doit correspondre au nombre de pas nécessaires pour effectuer la classification.

Par ailleurs, il est possible de sauvegarder le fichier avec les valeurs déjà parcourues et les derniers centroïdes pour chaque classe rencontrée, cela se traduit respectivement par une valeur négative du pas et d'une valeur nulle du pas. Attention, cela ne concerne que l'affichage, la mémorisation de l'état des règles est évoquée ultérieurement.

Les labels constituent un type d'entrée à part entière. Ils sont synchronisés sur les données, c'est-à-dire qu'ils sont envoyé en même temps. Évidemment, l'utilisateur peut s'en servir ou non dans son programme.

Réciproquement, le banc d'essai de nuage de points recueille deux type de messages de la part de nomoInterpreter : un label et un vecteur de données correspondant aux moyennes de la prémisse d'entrée de la règle sélectionnée.

Selon que les données d'entrée aient une dimension ou plusieurs dimensions, l'affichage diffère. Par exemple, avec la base de données iris après ACP, voici ci-dessous, la visualisation avant essai d'un fichier contenant les quatre dimensions et à droite le cas avec un fichier uniquement la première. Les couleurs des labels sont ad hoc.

Les commandes de l'agent permettent soit de colorier l’intérieur du cercle désignant le dernier point selon sa classification, soit d'afficher une croix (ou segment vertical pour la représentation 1D) désignant un point issu de la distribution de probabilité définie par la prémisse d'entrée de la règle perceptive associée à la commande si le nombre d'ajustement maximal n'est pas atteint, sinon le point correspond aux moyennes de la prémisse d'entrée.

Dans la représentation des données à une dimension, l'aire de histogramme vaut 1, l'axe des ordonnées correspond à la densité de probabilité. Dans les deux cas, se rajoutent à la visualisation des données le point envoyé ainsi que le résultat de l’étiquetage des précédentes.

Dans les deux cas, il est possible de zoomer à l'aide de la molette de la souris et de déplacer la visualisation grossie par un tirer/glisser. Un retour à la position initiale peut-être obtenu directement en double cliquant dans la zone contenant le graphique.

Ainsi, comme l'illustrent les figures ci-dessous, les points apparaissant au début d'un pas sont indiqués par une zone noire transparente. Les données initiales sont représentées par des petits traits ou des cercles. Dans les deux cas, ces glyphes sont complétés lors de leurs classifications et la couleur du complément dépend de la couleur du label de la classification.

Dans la représentation de données à une dimension, lorsque le système identifie 20 points appartenant à la même classe, une courbe estimant la densité de probabilité de la classe est affichée.

Tous les programmes nomo décrivant des méthodes de classification dans le cadre de ce banc d'essai reposent sur un modèle ayant pour modèle de base poinsscatter.

Le modèle de base décrit uniquement le type d'entrée et de sortie correspondant au label. Le type d'entrée et de sortie des données à traiter doivent être définis entièrement puisque les composantes ne peuvent pas être prédéfinies. Toutefois pour le bon fonctionnement de ce banc d'essais, il est nécessaire de définir l'entrée et la sortie de données au sein d'une structure perceptive de manière similaire à la structure perceptive du label défini ci-dessous.

pointsscatter.mod

<?xml version="1.0" encoding="utf-8"?>
<model name="pointsscatter"
       xmlns="http://www.nomoseed.org/model"
       xmlns:project="http://www.nomoseed.org/project">
  <project:header>
    <project:author>
      Cédric Coussinet
    </project:author>
    <project:copyright>
      <project:mention xml:lang="en">
        Copyright - Cédric Coussinet (2012) - All rights reserved
      </project:mention>
    </project:copyright>
    <project:license name="GPL">
      <project:mention xml:lang="en">GNU GENERAL PUBLIC LICENSE</project:mention>
    </project:license>
  </project:header>
  <definition>
    <perceptive_structure name="label">
      <command_type />
      <items/>
      <components>
        <component name="value"/>
      </components>
    </perceptive_structure>
  </definition>
</model>