DokuWiki

You've loaded an old revision of the document! If you save it, you will create a new version with this data.

<h1>Modification de luminosité dans une pièce: Découverte de pattern sensorimoteur par deux objets</h1>
<div class="level1">

<p>
Ce scénario reprend le principe de <em>flux d'instances d'évènements</em> entre
les différents avatars définit dans <a href="/doku.php?id=scenario-nocaptor" class="wikilink1" title="scenario-nocaptor" data-wiki-id="scenario-nocaptor"> une réflexion
sur la création de pattern pour un objet sans capteur</a>.
</p>

</div>

<h2>Introduction</h2>
<div class="level2">

</div>

<h3>Les objets</h3>
<div class="level3">

<p>
Dans une même pièce se trouve :
</p>
<ul>
<li class="level1"> Un système d'éclairage (lampe), avec interrupteur et capteur de luminosité.</li>
<li class="level1"> Une fenêtre équipée d'un store électrique, avec un interrupteur permettant de faire monter ou descendre plus ou moins le store (pas de capteur de luminosité).</li>
</ul>

</div>

<h3>Les variables</h3>
<div class="level3">

<p>
Au départ de ce scénario, les avatars n'ont pas encore identifiés de pattern 
récurrents, il n'existe donc pas encore de variables internes (ou de <b>flux 
d'instances</b>), uniquement des variables d'entrées continues correspondant aux
capteurs et actionneurs des objets.
</p>
<ul>
<li class="level1 node"> Pour le système d'éclairage les variables d'entrées sont :<ol>
<li class="level2"> l'état de l'interrupteur du système d'éclairage, que nous nommeront V<sub>1:1</sub>.</li>
<li class="level2"> l'intensité lumineuse de la pièce, nommée V<sub>1:2</sub>.</li>
</ol>
</li>
</ul>
<ul>
<li class="level1 node"> Pour la fenêtre équipée d'un store électrique :<ol>
<li class="level2"> l'état de l'actionneur de store, nommée V<sub>2:1</sub> (-1 : descendre le store, 1 : monter le store, 0 : sinon).</li>
<li class="level2"> Pourcentage d'ouverture du store, nommée V<sub>2:2</sub> (allant de 0, le store est fermé, et 1 le store est ouvert).</li>
</ol>
</li>
</ul>

</div>

<h2>Scénario</h2>
<div class="level2">

<p>
L'action se déroule dans le bureau de notre utilisateur, Billy,
et ce durant plusieurs semaines. 
</p>

</div>

<h3>Point de vue de l'utilisateur</h3>
<div class="level3">

<p>
Billy, notre utilisateur, se lève et se rend dans son bureau. Faisant encore
nuit, Billy allume la lumière, il est 6h.
</p>

<p>
Vers 8h Billy sait qu'il fait jour dehors, il éteint donc la lumière et ouvre
en grand les stores électrique de sa fenêtre.
</p>

<p>
Ceux-ci reste ouvert jusqu'à ce que, vers 19h, Billy se rende compte
que le soleil se couche. Billy allume donc la lumière de son bureau,
puis ferme les stores.
</p>

<p>
Billy reste ensuite dans son bureau jusqu'à 22h, il éteint alors la lumière
avant de partir.
</p>

<p>
(oui, Billy travaille beaucoup plus qu'il ne le devrait).
</p>

</div>

<h3>Point de vue du système d'objets connectés</h3>
<div class="level3">

<p>
En se basant sur les actions de Billy, décrites précédemment, 
nous pouvons supposer que les variables d'entrée du système
d'objets connectés varieraient, plus ou moins, comme présenté 
sur les graphiques ci-dessous.
</p>

<p>
<a href="/lib/exe/fetch.php?media=wiki:rplot_all_scenario_lum.png" class="media mediafile mf_png" title="wiki:rplot_all_scenario_lum.png (19.4 KB)">rplot_all_scenario_lum.png</a>
</p>

<p>
Le but étant de voir comment le système
d'éclairage et le store pourraient arriver
à faire la relation entre la levée du store
et l'augmentation de luminosité, via leurs échanges.
</p>

<p>
<a href="/lib/exe/fetch.php?media=wiki:rplot_v12_v22_relation.png" class="media mediafile mf_png" title="wiki:rplot_v12_v22_relation.png (26.1 KB)">rplot_v12_v22_relation.png</a>
</p>

</div>

<h3>Point de vue du système d'éclairage (Orienté description du modèle)</h3>
<div class="level3">

<p>
Si nous prenons le point de vue du système d'éclairage,
celui-ci sera capable de découvrir, dans un premier temps,
des motifs liés à ses propres capteurs et actionneurs (puisque
aucun <em>flux</em> n'est disponible pour le moment). 
</p>

<p>
Puis dans un second temps de faire le lien entre ses motifs et
ceux découvert par les autres objets de la société.
</p>

<p>
Nous allons voir plus en détail dans cette partie le fonctionnement
du système d'apprentissage de l'avatar du système d'éclairage.
</p>

</div>

<h4>Découverte d'évènements</h4>
<div class="level4">

<p>
La découverte de motifs récurrents à partir des entrées continues
que sont V<sub>1:1</sub> et V<sub>1:2</sub> est fait les couples
formés par des agents Découper et des agents Similarité paramétrés
de diverses manières.
</p>

</div>

<h5>Découpe</h5>
<div class="level5">

<p>
Comme dit précédemment, le système d'apprentissage doit commencer
par essayer d'extraire des informations liés à ses variables d'entrées
avant d'essayer de les relier à un quelconque évènement "extérieur" 
(de plus, à cette étape du scénario aucun flux n'est disponible pour
l'autre objet).
</p>

<p>
Ce travail de découpe est effectué par les agents Découper du système
d'apprentissage. Ceux-ci, suivant divers paramètres, vont "déplacer"
une fenêtre de découpe le long de la variable. Ces fragments de
variables sont décrit à l'aide d'histogrammes par les agents Découper.
</p>

<p>
<a href="/lib/exe/fetch.php?media=wiki:decoupe.png" class="media mediafile mf_png" title="wiki:decoupe.png (21.1 KB)">decoupe.png</a>
</p>

<p>
Ces fragments de variables sont évaluer via un feedback <em>d'intérêt</em>,
aidant ainsi à la sélection des paramètres de découpe par l'agent Découper.
</p>

</div>

<h5>Création de Flux</h5>
<div class="level5">

<p>
La découverte d'évènements récurrents se fait à l'aide d'un couple
d'agent Découper et Similarité. L'agent Découper faisant varier
ses paramètres de découpe et l'agent Similarité faisant varier
ses paramètres de différenciation, les deux en fonction de la
variable d'entrée à laquelle ils sont associés.
</p>

<p>
La qualité des paramètres, évaluée à partir d'un feedback <em>d'intérêt</em>,
est sauvegardé dans un <b>espace de marquage</b> à trois dimensions
(la variable sélectionné, les paramètres de l'agent Découper et
les paramètres de l'agent Similarité).
</p>

<p>
Cet espace de marque sert à garder, dans un espace commun de recherche
de paramètres à tous les couples d'agents, la trace de l'utilisation de
certains paramètres et leurs qualités.
</p>

<p>
<a href="/lib/exe/fetch.php?media=wiki:hemis_marquage.png" class="media mediafile mf_png" title="wiki:hemis_marquage.png (55.4 KB)">hemis_marquage.png</a>
</p>

<p>
Une fois qu'un couple, ou plutôt l'agent Similarité d'un couple d'agent,
aura déterminé qu'un <em>concept d'évènement</em> est assez récurrent il créera
un <em>flux d'instances d'évènements</em> dans lequel il fera passer les <em>instances</em>
correspondants au <em>concept d'évènement</em> du flux, et auxquels pourra se connecter
les agents Association du système d'apprentissage, mais aussi les agents 
Association des autres systèmes d'apprentissage. 
</p>

<p>
<a href="/lib/exe/fetch.php?media=wiki:flux_creation.png" class="media mediafile mf_png" title="wiki:flux_creation.png (108.4 KB)">flux_creation.png</a>
</p>

<p>
Pour connaitre la similarité, ou plutôt le pourcentage de similarité, entre deux 
instances d'évènement, l'agent Similarité utilise une fonction d'intersection des
histogrammes représentants les instances.
</p>

<p>
<a href="/lib/exe/fetch.php?media=wiki:similarite.png" class="media mediafile mf_png" title="wiki:similarite.png (21.6 KB)">similarite.png</a>
</p>

</div>

<h4>Partage d'évènements</h4>
<div class="level4">

<p>
A peu près même moment que le système d'apprentissage de l'éclairage
créé ses <em>flux d'instances</em>, des <em>flux d'instances externes</em> font
leur apparitions.
</p>

<p>
Une notation possible est présentée ci-dessous. Noté <b>F</b>, un flux est
identifié par l'ip de l'objet fournissant le flux et l'id de ce flux.
De la même manière sont notés <b>e</b> les <em>concepts d'évènements</em> associés
à un flux, il sont donc identifiés de la même manière que les flux, avec
id et ip.
</p>

<p>
<a href="/lib/exe/fetch.php?media=wiki:flux_notation.png" class="media mediafile mf_png" title="wiki:flux_notation.png (13.9 KB)">flux_notation.png</a>
</p>

<p>
Pour simplifier la notation pour le scénario, l'ip du système d'éclairage
sera 1 et l'ip du store électrique sera 2. L'ip 0 est considéré comme un
"localhost", se sont les flux identifiés comme personnels par l'objet,
le fait de donner un ip 0 pour identifié le "moi" est totalement
arbitraire, un flux pourrait garder l'ip de l'objet apprenant, cependant
les agents du système d'apprentissage, en particulier les agents Découper,
devraient être capables de différencier les flux personnels et les flux 
extérieurs.
</p>

<p>
Ainsi le système d'apprentissage voit apparaître, à peu près au même moment,
des flux d'instances <em>interne</em> (avec un ip 0) et des flux d'instances
<em>externes</em> (avec un ip différent de 0).
</p>

<p>
Les couples d'agents formés par des agents Association et Similarité vont
alors rechercher différentes Association de concepts d'évènements possibles
et pertinents.
</p>

<p>
<a href="/lib/exe/fetch.php?media=wiki:flux_association.png" class="media mediafile mf_png" title="wiki:flux_association.png (92.6 KB)">flux_association.png</a>
</p>

<p>
Les Associations vont être faites en prenant prioritairement en références
les flux internes du système d'apprentissage. Cet aspect "égoïste" de
l'apprentissage est nécessaire pour éviter une redondance de l'apprentissage
dans tous les avatars de la société, et permet aussi une spécialisation
de ces mêmes avatars. En effet, les avatars d'objets possédant peu de 
capteurs et d'actionneurs seront plus enclin a tenter d'associer des évènements
provenant de flux externes; à l'inverse des avatars d'objets possédant beaucoup
de capteurs et d'actionneurs seront plus enclin à se concentrer uniquement sur
le découpage de leur variables d'entrées et sur la découverte de concepts d'évènements
"intéressants".
</p>

</div>

<h3>Point de vue du store électrique (Orienté Scénario)</h3>
<div class="level3">

<p>
Dans le point de vue précédent, l'accent a été mis sur le fonctionnement
globale du modèle. De ce point de vue, au contraire, nous allons nous
concentré, pas à pas, sur les suites logiques d'évènements pouvant arriver
à un système d'apprentissage.
</p>

</div>

<h4>Variables d'entrées et Découpe</h4>
<div class="level4">

<p>
Reprennons à partir de la découpe d'une variable d'entrée, 
par exemple V<sub>2:2</sub>.
</p>

</div>

<h5>Couple Découper - Similarité (D-S)</h5>
<div class="level5">

<p>
L'apprentissage de la découpe d'une variable
d'entrée est implémenté par un couple D-S. Leurs
intéractions, dont nous allons voir le fonctionnement,
permet de connaître la "pertinence" du découpage
d'une variable en particulier. Ils font varier leurs
paramètres en explorant l'espace de marquage vu précédemment.
</p>

</div>

<h5>Découpe</h5>
<div class="level5">

<p>
L'agent Découper d'un couple D-S associé à la variable V<sub>2:2</sub>
a pour paramètre un Δt qui est la taille de la fenêtre de découpe.
</p>

<p>
<a href="/lib/exe/fetch.php?media=wiki:decoupe.png" class="media mediafile mf_png" title="wiki:decoupe.png (21.1 KB)">decoupe.png</a>
</p>

<p>
L'agent Découper va alors parcourir la variable d'entrée en faisant
"glisser" sa fenêtre de découpe le long des variations. La fenètre
peut être simplement glissante, ou bien glissante et suivant les 
variations de la variable d'entrée, comme sur l'image ci-dessus.
</p>

<p>
La portion découpée par l'agent Découper est alors représenté sous
la forme d'un histogramme.
</p>

</div>

<h5>Similarité et Différenciation</h5>
<div class="level5">

<p>
Les histogrammes produit par l'agent Découper sont alors récupéré
par l'agent Similarité qui lui associé. 
</p>

<p>
Celui ci compare les nouvelles instances d'évènement avec ceux qu'il
a stocké précédemment, ou plutôt avec l'histogramme représentant la moyenne
de chaque groupe d'instances similaires. Cette "moyenne" peut être considéré
comme un pré-concept d'évènement.
</p>

<p>
La fonction de comparaison utilisée pour différencier les instances découpées
en une fonction d'intersection entre les deux histogrammes représentant les
instances.
</p>

<p>
<a href="/lib/exe/fetch.php?media=wiki:similarite.png" class="media mediafile mf_png" title="wiki:similarite.png (21.6 KB)">similarite.png</a>
</p>

<p>
Ainsi l'agent Similarité du couple D-S "rangera" les nouvelles instances
d'évènements avec celles qui lui sont le plus similaire, modifiant par la
même la moyenne de ce groupe d'instance. Si aucun groupe n'est trouvé pour
une instance, alors un nouveau lui correspondant sera créé.
</p>

<p>
n.b: le paramètre de l'agent Similarité serait sont seuil d'acceptation
de similarité, mais cela reste à confirmer. 
</p>

</div>

<h5>Feedback et sélection de concept</h5>
<div class="level5">

<p>
Avant que la moyenne d'un groupe d'instance soit considérée comme un réel
concept d'évènement, l'agent Similarité d'un couple D-S va calculer l'intérêt
de chaque pré-concept, et marquer le maximum de ces intérêts dans l'espace de
marquage des couple D-S.
</p>

<p>
Le feedback d'intérêt d'un pré-concept d'évènement est calculé à partir de la 
spécificité de cet évènement, c'est à dire si l'évènement "sort du lot", et 
de la récurence de cet évènement. Pour faire simple, parmis tous les évènements
"rare", celui qui aura le plus fort intérêt sera celui qui arrive le plus souvent,
donc potentiellement le moins dû au hasard.
</p>
<pre class="code">
    TODO: equation with MathJax

</pre><p> </p>

<p>
C'est lorsqu'un couple D-S de type <em>Exploiteur</em> se positionnera, dans l'espace
de marquage, sur les paramètres de découpe de V<sub>2:2</sub> que la création de
Flux d'instance se fera pour les concept ayant la plus haute spécificité.
</p>

</div>

<h5>Conception de flux d'instances</h5>
<div class="level5">

<p>
Comme dit précédemment, les couples D-S vont extraire
des <em>concepts d'évènements</em> et créer des <em>flux d'instances d'évènements</em>.
Ces flux pourraient correspondre à des flux RSS (ou tout autre outils permettant
le partage d'un "fil d'évènements"), ils seront ainsi mis à jour part l'agent
Similarité du couple associé, à chaque fois que l'agent Découper extrait une
nouvelle <em>instance d'évènement</em> correspondant au <em>concept d'évènement</em>
du flux.
</p>

<p>
Supposons qu'à partir de V<sub>2:2</sub> deux concepts d'évènements soient
créés.
</p>

<p>
TODO : image
</p>

<p>
Il y aura donc de flux de créé par le couple D-S affecté à cette variable
d'entrée. Ces flux étant internes du point de vue du store et externe
du point de vue du système d'éclairage.
</p>
<pre class="code">Exemple de description d'un flux en JSON-LD :

{
  "@context": "http://www.w3.org/ns/activitystreams",

"@type": "Activity",

"published": "2016-01-25T12:34:56Z"

"author": {
    "@type": "Object",

"@id": "URI de l'objet / URI du flux"
  }

"orderedItems": [
    {
      "@type": "Event"

...
    },
    {
      "@type": "Event"

...
    }
  ]
}

</pre><p> </p>

<p>
n.b: Le fonctionnement de l'API de notification et de partage de flux n'est pour
l'instant pas clairement définie.
</p>

</div>

<h4>Flux d'instances et Association</h4>
<div class="level4">

<p>
Reprennons à partir du moment où tous les flux (internes et externes) 
de tous les objets de la société soient créés et accessible par le store.
</p>

</div>

<h2>Problèmes</h2>
<div class="level2">
<ul>
<li class="level1"> Supposons que dans cette pièce nous rajoutons un chauffage électrique connecté, comment faire en sorte que les échanges entre les objets se "spécialisent" ?</li>
</ul>

<p>
Les évènements proposé par les flux d'instances du chauffage sont en effet peu utile pour le
système d'éclairage (peut être un peu moins pour le store),
le but ici serait qu'au flux externes d'un système, voir à tout l'objet proposant ces flux, 
soit associé un feedback "d'utilité". Puisque les systèmes
d'apprentissage cherche prioritairement des associations avec pour référence leurs
flux d'instances internes, nous pouvons facilement l'imaginer évaluer l'utilité
d'un flux d'instances externes lui ayant permis ou non de trouver des motifs
avec pour références ses concepts personnels.
</p>
<ul>
<li class="level1"> Supposons maintenant que dans une autre pièce un système d'éclairage identique au notre soit installé, comment permettre que ce nouveau système d'éclairage apprenne plus vite avec l'aide de notre système d'éclairage ?</li>
</ul>
<ul>
<li class="level1"> En plus du feedback d'intérêt, il est censé il y avoir un feedback prédictif, comment un motif pourrait passer un "mode prédictif" s'il prend en compte des flux externes ?</li>
</ul>
<ul>
<li class="level1"> Comment les avatars pourrait arriver, de manière émergente, à un consensus concernant un motif, pour que celui soit "commun" à la société ou à un groupe ?</li>
</ul>

</div>

Enable Complex Tables Editor Height px Turn supplementary image paste support on

Edit summary: Minor changes

Please fill all the letters into the box to prove you're human. T G N U X Please keep this field empty:

DokuWiki

Site Tools

Page Tools