RobAIR2013-RICM5-Suivi

Equipe

Nous sommes 4 étudiants de Polytech Grenoble de la filière RICM5

• Arthur Alexandre
• Mickaël Nicolaccini
• Elizabeth Paz
• Salem Harrache

Contacter le groupe: ricm5-robair2013@googlegroups.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

Context

Projet en lien avec le Projet RobAIR2013, vous aussi suivre les avancées des équipes ENSIMAG ici

RobAIR

Architecture ROS globale

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

Architecture ROS détaillée

Architecture RobAir détaillée au 22/02/13

Liste des tâches

Tâches communes

• XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP
• Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.
• Faire le noeud HTTPStream :
  • Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.
  • Et propose une interface Qt (PySide) pour afficher le flux http dans la TV et dans la tablette Robot. Cette interface permettra d’afficher le flux vidéo.
• Topic/cmd : Définir format des messages « commande »
  • attributs du message commande
    • Speed : [-3 – 3] (négatif == reculer ; positif == avancer)
    • Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles

Tâches Système SmartTV

• Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd

• Noeud ROS Android (Android_receiver) :
  • Communication Web Socket (Tablette <=> Serveur)

• Interface Tablette
  • Interface Connexion/Réservation
  • Interface Contrôle (ex : commandes de mouvement, d’information, etc.)

• Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)

• Client Manager :
  • Intégrer le bot XMPP
  • Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot
  • Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session

Tâches Système Robair

• Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.
  • Intégrer le bot XMPP
  • Module Vérification sur le portail

• Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber

• Noeud MotionControl :
  • Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)

• Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.

• Noeud Network : intégrer les scripts de roaming dans ce noeud ROS

• Noeud Battery : diffuse régulièrement les statistiques de la batterie

• Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.

• Navigation automatique
  • Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.
  • Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.
  • Noeud SLAM : noeud permettant la navigation automatique en fonction de la map statique + « map dynamique » qui correspond à la foule qui se déplace (donnée récoltée par Kinect).
  • Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.

• Noeuds prévus pour des projets futurs :
  • Noeud Speech_synthesis : pour la reconnaissance vocale

Portail de Réservation

• Développer Portail Réservation simple (renvoie toujours « oui »)
• Utiliser les adresses Jabber pour identifier les utilisateurs et les robots
• Mettre en place un mécanisme d’authentification lors de la réservation

Spécifications

Scénarios

Les différents scenarios du projet RobAIR sont dans le fichier suivant: File:Scenarios.pdf

Cas d'utilisation

• Cas d'utilisation projet RobAIR
• 

  Cas d'utilisation du Système Robair

• 

  Cas d'utilisation du Système Robair (en détails)

• 

  Cas d'utilisation Portail de réservation

Diagramme de séquence

• Diagramme de séquence (entre systèmes) projet RobAIR
• 

  Déplacement du robot (avancer)

• 

  Déplacement du robot vers un point spécifique

• 

  Obtention d'information supplémentaires

• 

  Portail de réservation

• Diagramme de séquence (entre noeuds et topics) projet RobAIR
• 

  Déplacement du robot (avancer)

• 

  Déplacement du robot vers un point spécifique

• 

  Obtention d'information supplémentaires

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 et présentation des étudiants du Pôle Supérieur de Design de Villefontaine

Présentation Pôle Supérieur de Design

• Validation de la nouvelle architecture ROS

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

• Sé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

à compléter par Salem

Semaine 4: 18/02/13 - 23/02/13

18/02/13

• Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder
• Travail en cour sur Jitsi, problème de mise en place d'ipojo.

19/02/13

• Réunion avec les étudiants de l'ENSIMAG
• sujet abordés
  • manipulation kinect (problème de pilote sous linux)
  • liste des capteurs necessaire pour SLAM

20/02/13

• réunion interne:
  • videoConf via XMPP mis de coté, utilisation d'échange video via http
• amélioration du Bot XMPP + nettoyage du code
  • rajout de la gestion des plugin XMPP
  • fonction de connection/déconnection
  • envoie de message
  • interpretation basique des messages reçu

21/02/13

• Point sur les differentes taches à effectuer avant la fin du projet.
• Amélioration de l'archicture ROS.

22/02/13

• Attribution de des taches à différents prototypes de l'architecture globale.
• Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.

Semaine 5: 04/03/13 - 08/02/13

04/02/13

• Création des sprints à partir de la liste des taches
• Mise au point avec les différentes équipe RICM4
• définition du format des

05/02/13

• Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm
• Récupération de la batterie pour le robot et alimentation pour la carte
• Début des tests avec la carte: https://www.sparkfun.com/products/11057

06/02/13

• Rédaction Dossier management de projets: estimation des couts & matrice de risque
• Prototype de pickle (librairie de serialisation)

08/02/13

• Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP

ROBAIR RPC XMPP

class RobBot(BotXMPP):
    
    @botcmd
    def echo(self, message):
        return message

    @botcmd
    def add(self, *args):
        return sum([int(i) for i in args])

• Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip

ROBAIR Calibrage Wild Thumper

• Erreur lors du chargement du programme sur la carte

avrdude: stk500_recv(): programmer is not responding

Semaine 6: 11/03/13 - 15/03/13

11/03/13

• Création du noeud ClientVisio (affichage de flux video http via pyside)
• Noeud de capture de clavier terminé : Le noeud permet de poster des commandes dans le topic command grâce au touche de direction du clavier.
• Mise à jour du Portail de réservation: https://github.com/SalemHarrache/robair-resource-manager#test
  • Changement mineur dans l'API
  • Utilisation du JabberID dans le processus de réservation
• Pistes sur le problème de la carte: le bootloader [1]

12/03/13

• Test de visio via http
• Idée : Utiliser gstreamer pour générer un flux, choisir le bon codec, bitrate, qualité et taille pour réduire au maximum la latence.
• Utiliser un process python http_streamer qui récupérer le flux du process gstreamer (par PIPE, TCP ou UDP) et renvoi ces données par http. Le process python sert à deux chose:
  • Gestion du cyle de vie du process gstreamer (Quand le le lancer, l'arreter proprement)
  • Sécurité : le flux video ne doit pas être facilement interceptable

server = HttpStreamer()
# lancer le serveur
server.start()

url = server.url_for_stream  
 
# arreter le serveur explicitement
server.stop()

13/03/13

Utiliser un proxy pour mettre en place RPC.

Qu'est qu'un objet proxy? : C'est un objet qui se fait passer pour un autre objet. Exemple

class Model(object):
    def add(self, *args):
        return sum((int(i) for i in args))


class MyProxy(object):
    def __init__(self, model):
        self.model_ins = model()

    def __getattr__(self, name):
        return self.model_ins.__getattribute__(name)

a = MyProxy(Model)
print a.add(3, 5)
# 8

14/02/13

Première version opérationel de RPC. C'est un mecanisme haut niveau, c'est à dire qu'il ne se base pas sur la spécifité de XMPP mais juste sur le contenu des message. Ce qui permet d'assurer une independance vis à vis des libs/xep XMPP.

Exemple de fonctionnement :

Coté serveur :

class RobotManager(ClientXMPP):
    @remote
    def add(self, *args):
        return sum((int(i) for i in args))

Coté client :

class Client(ClientXMPP):
    pass

client = Client(jid, passwrd)
# Creation d'un proxy pour appeler les methoded distanted
robot_proxy = client.get_proxy("remote_robot@jabber.com")

assert robot_proxy.add(5, 6, 4, -5) == 0

Ce qu'il reste à faire, c'est de créer un contexte (proxy) accessible lors de l'éxecution des méthodes @remote pour donner des informations supplémentaires (l'adresse du client par exemple) et pouvoir ainsi distinguer les clients lors des executions distante (typiquement l'authentification et vérification des droits du client sur le robot)

Semaine : 18/03/13 - 22/03/13

18/03/13

• Création d'un noeud de capture des événements WiiMote (utilisation de cwiid)

$ > sudo apt-get install python-cwiid] )

• Exemple d'utilisation de cwiid avec python

import cwiid

# Pair with any present wiimote (can take a wiimote MAC addr as a parameter)
wm = cwiid.Wiimote()

# Enable button and accelerometer data reception
wm.rpt_mode = cwiid.RPT_BTN | cwiid.RPT_ACC

#  Access a button state
button_A_pressed = wm.state['buttons'] & cwiid.BTN_A

# Rumble
wm.rumble=True

# Access accelerometer values of 3 wiimotes axis
# Values are bounded in the [95,155] interval, ~125 is « straight »
wiiX = wm.state['acc'][0]
wiiY = wm.state['acc'][1]
wiiZ = wm.state['acc'][2]

# end using wiimote
wm.close()

• Tutoriel pour graver le bootloader sur Wild Thumper Controller avec une Arduino Uno : voir ici

21/03/13

• Soutenance Transparents - Flyer - Poster - Video - Site web

Nous léguons le flambeau aux RICM4, et aux étudiants des années futures