RobAIR2013-RICM5-Suivi
Equipe
Nous sommes 4 étudiants de Polytech Grenoble de la filière RICM5
- Arthur Alexandre -- arthuralexe@gmail.com
- Salem Harrache -- salem.harrache@gmail.com
- Mickaël Nicolaccini -- m.nicolaccini@gmail.com
- Elizabeth Paz -- elizabeth.pazh@gmail.com
Sources du projet
Le code source du projet est disponible sur github
Portail de réservation
Le portail de réservation est une application web de gestion des resources. Le serveur est developpé en python, et le format des données de communication est en JSON.
Website : https://github.com/SalemHarrache/robair-resource-manager
ROS PKG
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet.
Website : https://github.com/SalemHarrache/robair-ros-pkg
Ros2xmpp
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP
Website : https://github.com/SalemHarrache/robair-ros2xmpp
Context
Projet en lien avec le Projet RobAIR2013
RobAIR
Avancement du projet
Semaine 1: 28/01/13
29/01/13
- Réunion avec Didier Donsez: définition du cadre du projet
30/01/13
- Prise de contact avec les autres équipes (RICM4 et 3I4)
- Analyse de l’architecture
- Repartions des recherches architecturales entre les membres de l'équipe RICM5
01/02/13
- Point sur les technologies à utiliser
Websocket ou Comet
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.
Voici deux exemples en python:
- Serveur echo avec les websockets (DEMO)
- MultiChat utilisant le protocole Server-Sent Events (DEMO)
À tester en JAVA
LibJingle ou libJitsi ou autres ?
ROS ou Urbi+ROS
Semaine 2: 04/02/13 - 08/02/13
04/02/13
- Réunion avec RICM4.
- mise à jour de l'architecture: Clarification des Rôles
07/02/13
- Proposition de nouvelle architechture et répartion des taches.
Notre idée : C'est de pas (trop) mélanger les technos et de pas avoir un client java d'un côté, des noeuds ROS de l'autre. ROS est également parfait pour faire des GUI(QT), des listeners, du traitement, du service etc...Donc il est préférable de miser sur ROS aussi bien coté robot que smartTV ! Ça a plus de consistance et c'est d'autant plus "facile" car on se base que sur le modèle de comunication de ROS (les topics entre-autre)
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.
En effet, Donsez nous avait dit qu'il souhaite que les communications entre le robot et la smartTV passent par XMPP pour des problématiques de réseau (XMPP passe mieux en 3G, moins bridé sûrement etc.) mais également pour avoir de la vidéo et un annuaire : au lieu d'avoir une adresse IP pour contacter le robot, ce dernier aura une adresse jabber/gmail.
Pourquoi pas, c'est original... Maintenant qu'est-ce qui nous empêche d'utiliser Jitsi comme étant juste un outil réseau pour transiter des packets. En gros pourquoi ne pas créer un tunnel XMPP dans lequel on passe nos données, et connecter ainsi deux bouts ROS. ROS c'est fait pour être réparti sur différentes machines et c'est vraiment dommage de pas profiter de ça.
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)
En gros il s'agit de faire du miroring de topics ROS. On peut faire passer de la vidéo et du texte (les messages ROS sont sérialisés en String) par XMPP, donc c'est faisable. Le challenge c'est de faire qu'on puisse lire un topic ROS en java (et écrire également). Mais c'est un sous projet à part entière et surtout indépendant ! J'ai vu pas mal de projet faire du tunneling XMPP pour outrepasser des limitations du réseau, c'est pas si extravagant/insensé que ça.
De cette façon les développeurs ROS (qui seront bien plus nombreux) n'auront pas à se soucier de joindre les deux bouts (^^") et peuvent commencer à bosser sur l'architecture.
On a déjà découper les différentes phases pour cette partie (Je vous envoie dans un prochain mail un récapitulatif) mais rapidement, je dirais qu'il faut se concentrer d'abord sur l'extraction des lib/bundles Jitsi des methodes d'envoi de flux vidéo et de messages dans un premier temps.
Ensuite créer un bot (de chaque coté) qui va se connecter automatiquement à une adresse donnée (robot-robair@gmail.com par exemple) et vérifie mutuellement la présence d'une personne à l'autre bout. La dernière phase c'est de surveiller un certain nombre de topic ROS et de les copier tel quel à l'autre bout. (c'est plus délicat pour la vidéo mais c'est jouable).
Du coté ROS (python), on peut déjà commencer sans passer par Jitsi dans un premier temps, et plus tard intégrer cette composante au fur et à mesure de son avancement.
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*
08/02/13
- Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez
- Validation de la nouvelle architecture ROS (liens vers schéma à insérer)
Semaine 3: 11/02/13 - 15/02/13
11/02/13
- abandon de libjitsi: trop peu d'exemple d'utilisation.
- Jitsi mit de coté pour l'instant
- Etude de libjingle, résultat de recherche encourageant pour l'instant.
12/02/13
- scéance génie Logicielle
13/02/13
- Test compilation libjingle : La compilation est plutot difficile, nous avons créer un petit script pour l'automatiser sur unbuntu : https://github.com/SalemHarrache/libjingle_builder
- Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/
14/02/13
Lib opensource et Jingle
Libjingle : malgré tout nos effort, la vidéo ne marche pas. Telepathy-python : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib Telepathy-glib : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.
Psimedia : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)
Après autant d'echecs à trouver une lib utilisable de Jingle, nous commençons à revenir en arrière sur le choix de XMPP/Jingle comme protocole de communication. Meme si son utilisation serait séduite, ce dernier manque cruellement d'implantation au sein de projet open source. Toutes les solutions opensource de messageries sont d'ailleurs également en standby, et attendent une avancé majeure de l'implantation de XMPP pour proposer de la vidéoconférence de qualité.
WebRTC
Dans no