RobAIR2013-RICM5-Suivi

From air
Revision as of 18:40, 13 February 2013 by Salem (talk | contribs) (→‎07/02/13)
Jump to navigation Jump to search

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 noeud 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 noeud ROS de comuniquer à travers XMPP

Website : https://github.com/SalemHarrache/robair-ros2xmpp

Context

Projet en lien avec le Projet RobAIR2013

RobAIR

Architecture RobAir et repartion des groupes
Architecture RobAir et repartion des groupes au 04/02/13

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:

À 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...)

08/01/13

Semaine 3: 11/02/13 - 15/02/13

11/01/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