Modèle d’instance et processus
ont lieu simultanément : l’application finale est parallélisée en s’appuyant notamment sur les pro-positions d’implémentations de [Wil12].
5.1 Modèle d’instance
Les instances sont définies comme des réalisations physiques de concepts sémantiques. Le mo-dèle d’instance est donc ainsi un momo-dèle intermédiaire permettant de faire le pont entre données sen-sorielles et connaissances sémantiques. De plus, il n’est pas seulement intermédiaire qu’en termes d’abstraction mais également en termes temporels. En effet, le modèle de perception travaille à la fréquence d’acquisition des capteurs (ie un point dans le temps) alors que le modèle de connais-sance travaille sur un espace de temps "infini". Le modèle d’instance, lui, n’est valide que sur un intervalle de temps fini. Cette propriété devient apparente lorsque l’on cherche à estimer des quan-tités nécessitant la notion de temps (ou de façon équivalente des séquences temporelles de données) comme par exemple les relations cinématiques entre objets (cf section 2.1.2). Dans le cadre de la robotique de manipulation, ce genre d’information est crucial et difficilement accessible par des données perceptuelles statiques1. De même, l’analyse de bases de connaissance comme Wikipedia ne peut donner au mieux qu’une vague description du type de relation cinématique : la page concer-nant le mot"Door"nous donne par exemple[...]Doors normally consist of a panel that swings on hinges on the edge[...]. Cette information est trop abstraite pour pouvoir être exploitée en vue d’un modèle orienté robotique.
La plupart des travaux précédents qui se basent sur des représentations multi-couches (section 2.3.3) ont tendance à considérer les instances et les concepts au sein d’une même couche. Dans notre modèle, nous séparons clairement les concepts des instances par cette différence fondamentale : un concept est"intemporel" et générique alors qu’une instance est spécifique au contexte courant du robot ettemporaire. Dans la suite nous définissons formellement notre modèle d’instance.
5.1.1 Définition d’une instance
Une instanceI est définie selon la figure 5.2. Elle est composée d’une description sémantique représentée par un graphe partageant le formalisme de notre modèle de connaissance (section 3.2.2).
A cela peut s’ajouter des types d’arêtes et de nœuds spécifiques aux instances. Actuellement, nous considérons les personnes et la relation d’appartenance belong-toreliant une instance à son pro-priétaire eg. belong-to(my_cup,John). La représentation explicite des utilisateurs et des relations
1. Sous-entendu sans données d’entraînement extérieures
My cup#001
Perception Sémantique
. . .
Poses Ht KeyFrames KFt
Figure 5.2 – Définition d’une instance
d’appartenance permet, entre autres, de contraindre l’espace de recherche d’instances dans une requête. Si un utilisateurusereffectue la requêteBring me my cup, le système va tout d’abord cher-cher les instances se nommantmy_cuppuis va étendre sa recherche aux instances héritant decup. La recherche d’instance commence par filtrer selon l’adéquation des descriptions sémantiques. On se limitera donc à la recherche d’instanceIvérifiant :
isA(I, cup)∧belong-to(I, user) (5.1) On verra également dans la section 5.1.3 d’autres utilisations envisageables de ces relations.
A l’aspect sémantique s’ajoute une description perceptuelle. Celle-ci est constituée des diffé-rentes observations de l’instance. Plus précisément, une observation est constituée d’une position, d’une date et d’une image correspondant à la détection. De ces images sont extraits des descripteurs images (chapitre 4) formant les lignes d’une matrice qui "résume" l’aspect visuel de l’instance.
Formalisation
Nous formalisons la définition d’une instance donnée précédemment. Une instanceIest définie par
I ={OI, GI} (5.2)
oùOI est un ensemble d’observations etGI un graphe de description sémantique.
Une observationo∈OIest de la forme :
o ={t, H, R, φ(R)}avec
t∈R H ∈SE(3) R∈Rw×h×3 φ(R)∈Rd
(5.3)
avectla date d’observation,Hla matrice de transformation euclidienne représentant la position de l’instance,Rla régionw×h de l’image correspondant à l’instance etφ(R)le descripteur image de dimensiond. On construit une matriceM constituée des descripteurs de l’ensemble des obser-vations :
M =hφ(R)1. . . φ(R)|OI|iT (5.4) avec|OI|le cardinal deOI.
Le grapheGI ={VI, EI}relie l’instance aux concepts du modèle de connaissance sémantique.
Les nœudsVI ∈VK∪VIPcorrespondent aux mêmes catégories que le graphe ontologique (voir table 3.1) avec l’ajout des nœuds "personne"VIP. Le nœud racinevrdu graphe, représentant le "concept"
de l’instance, est considéré comme appartenant àVKC,O (nœuds représentant des concepts objets).
De même, les arêtesEI peuvent représenter les relations de l’ontologie avec en plus une nouvelle relationbelong-to.
5.1.2 Définition du modèle d’instance
Maintenant que nous avons vu comment décrire une instance, nous allons aborder la définition du modèle d’instance en lui-même. Il consiste en un graphe illustré à la figure 5.3. Les nœuds de ce graphe sont constitués des instances mais également des requêtes. En effet, elles sont faites par un utilisateur et font intervenir des instances. Il est donc naturel de représenter explicitement les liens les reliant. Cela permet :
− d’obtenir des relations (indirectes) entre les utilisateurs et les instances, et entre les instances elles-même. Comme les instances n’ont intrinsèquement pas de lien entre elles (hors relation spatiale), les requêtes servent d’intermédiaires.
− d’augmenter la capacité d’inférence du robot. En effet, en incluant ces relations sous forme de clauses Prolog, le robot peut "raisonner" sur ce que lui ont demandé les utilisateurs pré-cédemment.
La gestion interne des requêtes sous forme de tâche est traitée à la section 5.5 et nous ne rentrerons pas plus dans les détails ici.
My cup#001
spoon#001
fork#001 fork#002
Task_1
Bring me my cup behind the fork
Task_2 Bring me this spoon
requestedBy isObjectiveOf isRelatedTo relation spatiale (temporaire) behind
Figure 5.3 – Schéma du modèle d’instance
Dans l’exemple de la figure 5.3, la requête Bring me the cup behind the fork. fait référence à deux instances : my_cupetfork, contraints par une relation spatiale. Les arêtes du graphe vont essentiellement relier les tâches aux instances. On considère trois types de relations :
− requestedBy: indique l’auteur de la requête eg.requestBy(task_1,john).
− isObjectiveOf : indique un objectif de la requête. Par exemple, l’objectif de la requêteBring me the cup behind the fork est l’instancemy_cupet en conséquence on aura la relation isOb-jectiveOf(my_cup,task_1). A noter qu’une requête peut avoir plusieurs objectifs comme dans Bring me a knife and a fork. Dans ce cas, on aura simplement les deux relations isObjecti-veOf(knife,task_1)etisObjectiveOf(fork,task_1).
− isRelatedTo: indique une instance, autre qu’un objectif, intervenant dans une requête. Avec notre exemple de requête, on aisRelatedTo(fork,task_1).
− behind/in_front_of, to_the_left/right_of, under/above : ensemble de relations spatiales entre instances. Celles ci sont particulières car elles sont temporaires. En effet, on verra à la section 5.5 qu’elles sont estimées à la volée lorsqu’une requête nécessite ce genre d’in-formation.
Formalisation
Le modèle d’instance est défini par un grapheGM I ={VM I, EM I}. Les nœudsVM I =Vinst ∪ Vmse regroupent en deux types :
− les nœuds instances Vinst ∈ VI qui correspondent aux nœuds racinevr des graphesGIi des instances et aux nœuds représentant les personnes (utilisateurs).
− les nœuds tâchesVm qui correspondent aux tâches générées par les requêtes utilisateurs.
Les arêtesEinst représentent les quatre relations décrites précédemment, à savoirrequestBy, isOb-jectiveOf,isRelatedToet les relations spatiales temporaires. La table 5.1 regroupe ces relations et les types de nœuds qu’elles relient.