WWWoT (Wiki Wiki WoT)

innorobo

admin Medini Lionel () (lmedini@undisclosed.example.com) — 2014-03-10T11:03:50+00:00

Réunion de préparation Innorobo

Date : 10 mars 2014 Participants : L. Médini, M. Mrissa, A. Boukhlif, H.M. Diallo, R. Desmargez, J. Martin, J. Taws.

Objectif de la réunion

Préparer la/les démonstrations Innorobo.

Décisions

On fait deux démos :

Jordan + Jonathan : Démo de fonctionnalité identique pour deux robots (NXT, EV3), communication en BT, serveur Jetty + Websockets. Interface : une partie contrôle et une partie visualisation (canvas).
Alexandre + Hady + Rémy : Découverte et invocation de fonctionnalités. La pf et l'avatar tourneront sur la même machine.

Déroulement

Alexandre, Hady et Rémy reprennent l'interface client + le serveur en WebSockets de Jordan et Jonathan.

Dates des démos (à confirmer)

Mercredi 19 (avant 15h), jeudi 20 à partir de 10h.

start - [Documents (in French)]

admin Medini Lionel () (lmedini@undisclosed.example.com) — 2013-04-22T15:18:26+00:00

Page principale du projet WoT du LIRIS / Homepage of the LIRIS WoT project

Membres du projet / Project members

Lionel Médini (LIRIS/UCBL)
Michael Mrissa (LIRIS/UCBL)
Jean-Paul Jamont (LCIS/INP)
Jean-Patrick Gelas (LIP/UCBL)

Description du projet / Project description

En construction / More about the WoT project very soon…

Documents (in French)

Présentation faite à Imaginove pour la labellisation du projet ANR ASAWoO (29/01/2013)
Présentation faite au workshop ROS d'Innorobo 2013 (21/03/2013)
Vidéo de présentation des résultats du projet de recherche de Thibaud Houel et Tanguy Raynaud-Gallonet (étudiants de master informatique de Lyon 1), à Innorobo 2013 (21/03/2013)
Présentation faite aux journées SEmba 2013 (04/04/2013)

carac

jpgelas (jpgelas@undisclosed.example.com) — 2011-04-22T14:42:45+00:00

Caractérisation des protocoles de communication

A TERMINER

Bien que les réseaux de l'Internet repose exclusivement sur le protocole IP et qu'une grande majorité des  applications s'appuient sur le protocole TCP (réf?), il existe dans la littérature, des protocoles de communication pour tous les critères d'exigence qu'une application communicante puisse souhaiter.

Internet tel qu'il a été conçu il y a bientôt 30 ans permet aujourd'hui encore de supporter un grand nombre d'applications (ex: transfert de fichier fiable, téléphonie, visioconférence, jeux en ligne, etc). Chacune de ces applications ont des exigences particulières en terme de performance et de tolérance aux critères inhérent aux réseaux de transport de données (ex: Débit, délai, taux de perte, taux d'erreurs, gigue, …). Aujourd'hui il est nécessaire d'adapter les protocoles de transport de données pour mieux exploiter les caractéristiques du réseaux physique actuels, mieux répondre aux exigences des applications et mieux s'adapter a un contexte de transport susceptible d'évoluer au cours du temps (mobile ou réseaux hétérogènes).

Dans le cadre de ce projet, nous souhaiterions que le choix du mode de transmission (canal et protocole) entre l'agent et l'objet soit sélectionné de façon autonome par le système. Ces choix seront fait en fonction des critères d'exigences de l'application et de la disponibilité des technologies de communication disponible. Ce choix ne sera pas définitif. On autorise le passage d'un mode de transmission à un autre, en fonction de l'évolution de l'environnement ou des services disponibles en cours de fonctionnement.

— Jean-Patrick Gelas 2011/04/22 14:41

jean-patrick_gelas - créée

jpgelas (jpgelas@undisclosed.example.com) — 2011-04-22T14:39:16+00:00

Pour me contacter :

email : jpgelas@ens-lyon.fr
Ph (ENS) : 04 7272 8228
Ph (UCB) : 04 2623 4451
Mobile : 06 80 48 86 93

Liens vers mes contributions sur ce Wiki :

— Jean-Patrick Gelas 2011/04/22 14:29

cr_18_avril_2011

jpgelas (jpgelas@undisclosed.example.com) — 2011-04-22T14:21:28+00:00

Réunion du 18 avril 2011

Participants : JP Gelas, L. Médini, M. Mrissa

Excusé : JP Jamont

Discussion sur les problématiques de chacun

JPG : choix des protocoles de haut niveau (niveau transport, mais a priori, on resterait sur de l'IP). Il s'agit de choisir à la volée le protocole le plus adapté à une situation donnée (types de données à transférer¹⁾, environnement²⁾, qualité de service…).

MM : monitoring des échanges de données (récupération de données sur les échanges, l'environnement, la QoS) ; adaptation de la SOA au multi-protocole. Notion de service adaptatif (protocol switching).

LM : moteur d'adaptation sémantique à partir de “connaissances contextuelles” (informations + sémantique) issues de différentes sources (agent : tâche ; objet : ressources et contexte spécifique de l'objet ; environnement : contexte plus général) ; application de règles utilisant les connaissances issues du service de monitoring ; certaines règles d'adaptation pourront être distribuées pour être traitées à la source de la donnée (objet ou avatar) et seule la “connaissance utile” est envoyée au moteur d'adaptation.

* JPJ : à faire…

Discussion sur l'architecture et sur la communication entre l'avatar et l'objet

Choix d'architecture : le moteur d'adaptation peut être centralisé (une instance pour tous les couples avatar ; objet)) ; dans ce cas, l'architecture est de type ESB. À l'inverse, une instance de moteur peut être définie pour chaque couple : plus proche du P2P. De façon à avoir une architecture plus flexible, on s'orienterait plutôt vers la seconde alternative.

Cette solution permettrait de “distribuer” le moteur d'adaptation avec un traitement local des règles concernant les données recueillies par l'objet et un envoi des résultats de ces traitements à l'avatar pour ne faire circuler entre l'objet et l'avatar que les informations intéressantes au regard de la situation courante.

Il faut donc définir un moyen de transmettre les règles, les connaissances d'adaptation, [éventuellement le code de traitement de ces connaissances,] les commandes de [négociation et de] changement de protocole, et l'“acknowledgement”. Au final, il s'agit donc de déterminer un protocole d'échange de connaissances d'adaptation et de contrôle du protocole de communication entre avatar et objet.

Figure 1. détail d'une architecture de communication entre avatar et objet discutée le 18 avril 2011.

¹⁾

contrôle, vidéo…

²⁾

alimentation disponible

archi_18_avril_2011.png

admin Medini Lionel () (lmedini@undisclosed.example.com) — 2011-04-18T18:43:40+00:00

schema_gros_grain_de_l_architecture_de_l_application_visee.png

admin Medini Lionel () (lmedini@undisclosed.example.com) — 2011-04-11T13:24:10+00:00

archi.png

admin Medini Lionel () (lmedini@undisclosed.example.com) — 2011-04-11T13:24:01+00:00