https://air.imag.fr/api.php?action=feedcontributions&user=Nicolacm&feedformat=atomair - User contributions [en]2024-03-29T07:03:42ZUser contributionsMediaWiki 1.35.13https://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10221PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T10:46:48Z<p>Nicolacm: /* Prise de décision */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membres du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
<br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Les types de données qui peuvent être récupérés sur Android sont : une abscisse, une ordonnée et un temps d'acquisition. La pression n'est pas récupérable sur Android. La période d'acquisition n'est pas constante.<br />
Après une durée de non activité (sans toucher l'écran) de 3 sec de la part de l'utilisateur, la signature est considérée comme terminée<br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Nous ne sommmes basé sur le travail des années précédantes et avons choisi [http://fr.wikipedia.org/wiki/Weka_(apprentissage_automatique) Weka ]comme logiciels d'apprentissage automatique.<br />
<br />
Le premier problème que nous avons rencontré que le Weka n'est pas compatible avec android. Nous avons utilisé une version "strippé" de weka présent sur le lien gitHub suivant [https://github.com/rjmarsan/Weka-for-Android https://github.com/rjmarsan/Weka-for-Android].<br />
<br />
Notre prise de décision utilise les données suivantes<br />
* Angle formé un triplé de point <br />
* l'accélération entre les points de saisie<br />
<br />
Nous avons pu ainsi mettre en place dans un premier temps un système d'authentification.<br />
[[Image:WekaSchema_authentification_2013.png|thumb|center|upright=3|WekaSchema_authentification_2013]]<br />
<br />
Pour obtenir une identification nous avons repris le système de l'authentification que nous itérons sur chacun des profils<br />
<br />
[[Image:WekaSchema_identification_2013.png|thumb|center|upright=3|WekaSchema_identification_2013.png]]<br />
[[File:WekaSchema_identification2_2013.png|thumb|center|upright=3|WekaSchema_identification2_2013.png]]<br />
<br />
Le profil obtenant le meilleur score est considéré comme le profil identifié.</div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10220PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T10:45:40Z<p>Nicolacm: /* Etude de faisabilité */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membres du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
<br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Les types de données qui peuvent être récupérés sur Android sont : une abscisse, une ordonnée et un temps d'acquisition. La pression n'est pas récupérable sur Android. La période d'acquisition n'est pas constante.<br />
Après une durée de non activité (sans toucher l'écran) de 3 sec de la part de l'utilisateur, la signature est considérée comme terminée<br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Nous ne sommmes basé sur le travail des années précédantes et avons choisi [http://fr.wikipedia.org/wiki/Weka_(apprentissage_automatique) Weka ]comme logiciels d'apprentissage automatique.<br />
<br />
Le premier problème que nous avons rencontré que le Weka n'est pas compatible avec android. Nous avons utilisé une version "strippé" de weka présent sur le lien gitHub suivant [https://github.com/rjmarsan/Weka-for-Android https://github.com/rjmarsan/Weka-for-Android].<br />
<br />
Notre prise de décision utilise les données suivantes<br />
* Angle formé un triplé de point <br />
* l'accélération entre les points de saisie<br />
<br />
Nous avons pu ainsi mettre en place dans un premier temps un système d'authentification.<br />
[[Image:WekaSchema_authentification_2013.png|thumb|center|upright=3|WekaSchema_authentification_2013]]<br />
<br />
Pour obtenir une identification nous avons repris le système de l'authentification que nous itérons sur chacun des profils<br />
<br />
[[Image:WekaSchema_identification_2013.png|thumb|center|upright=3|WekaSchema_identification_2013.png]]<br />
[[File:WekaSchema_identification2_2013.png|thumb|center|upright=3|WekaSchema_identification2_2013.png]]<br />
<br />
Le profil obtenant le meilleur score est considéré comme le profils identifié.</div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10202PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T10:16:28Z<p>Nicolacm: /* Prise de décision */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membre du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Nous ne sommmes basé sur le travail des années précédantes et avons choisi [http://fr.wikipedia.org/wiki/Weka_(apprentissage_automatique) Weka ]comme logiciels d'apprentissage automatique.<br />
<br />
Le premier problème que nous avons rencontré que le Weka n'est pas compatible avec android. Nous avons utilisé une version "strippé" de weka présent sur le lien gitHub suivant [https://github.com/rjmarsan/Weka-for-Android https://github.com/rjmarsan/Weka-for-Android].<br />
<br />
Notre prise de décision utilise les données suivantes<br />
* Angle formé un triplé de point <br />
* l'accélération entre les points de saisie<br />
<br />
Nous avons pu ainsi mettre en place dans un premier temps un système d'authentification.<br />
[[Image:WekaSchema_authentification_2013.png|thumb|center|upright=3|WekaSchema_authentification_2013]]<br />
<br />
Pour obtenir une identification nous avons repris le système de l'authentification que nous itérons sur chacun des profils<br />
<br />
[[Image:WekaSchema_identification_2013.png|thumb|center|upright=3|WekaSchema_identification_2013.png]]<br />
[[File:WekaSchema_identification2_2013.png|thumb|center|upright=3|WekaSchema_identification2_2013.png]]<br />
<br />
Le profil obtenant le meilleur score est considéré comme le profils identifié.</div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10201PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T10:15:29Z<p>Nicolacm: /* Prise de décision */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membre du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Nous ne sommmes basé sur le travail des années précédantes et avons choisi [http://fr.wikipedia.org/wiki/Weka_(apprentissage_automatique) Weka ]comme logiciels d'apprentissage automatique.<br />
<br />
Le premier problème que nous avons rencontré que le Weka n'est pas compatible avec android. Nous avons utilisé une version "strippé" de weka présent sur le lien gitHub suivant [https://github.com/rjmarsan/Weka-for-Android https://github.com/rjmarsan/Weka-for-Android].<br />
<br />
Notre prise de décision utilise les données suivantes<br />
* Angle formé un triplé de point <br />
* l'accélération entre les points de saisie<br />
<br />
Nous avons pu ainsi mettre en place dans un premier temmps un système d'authentification.<br />
[[Image:WekaSchema_authentification_2013.png|thumb|center|upright=3|WekaSchema_authentification_2013]]<br />
<br />
Pour obtenir une identification nous avons repris le système de l'authentification que nous itérons sur chacun des profils<br />
<br />
[[Image:WekaSchema_identification_2013.png|thumb|center|upright=3|WekaSchema_identification_2013.png]]<br />
[[File:WekaSchema_identification2_2013.png|thumb|center|upright=3|WekaSchema_identification2_2013.png]]<br />
<br />
Le profil obtenant le meilleur score est considéré comme le profils identifié.</div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10199PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T10:12:13Z<p>Nicolacm: /* Prise de décision */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membre du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Nous ne sommmes basé sur le travail des années précédantes et avons choisi [http://fr.wikipedia.org/wiki/Weka_(apprentissage_automatique) Weka ]comme logiciels d'apprentissage automatique.<br />
<br />
Le premier problème que nous avons rencontré que le Weka n'est pas compatible avec android. Nous avons utilisé une version "strippé" de weka présent sur le lien gitHub suivant [https://github.com/rjmarsan/Weka-for-Android https://github.com/rjmarsan/Weka-for-Android].<br />
<br />
Notre prise de décision utilise les données suivantes<br />
* Angle formé un triplé de point <br />
* l'accélération entre les points de saisie<br />
<br />
Nous avons pu ainsi mettre en place dans un premier temmps un système d'authentification.<br />
[[Image:WekaSchema_authentification_2013.png|thumb|center|upright=3|WekaSchema_authentification_2013]]<br />
[[Image:WekaSchema_identification_2013.png|thumb|center|upright=3|WekaSchema_identification_2013.png]]<br />
[[File:WekaSchema_identification2_2013.png|thumb|center|upright=3|WekaSchema_identification2_2013.png]]</div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10198PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T10:11:01Z<p>Nicolacm: /* Prise de décision */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membre du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Nous ne sommmes basé sur le travail des années précédantes et avons choisi [http://fr.wikipedia.org/wiki/Weka_(apprentissage_automatique) Weka ]comme logiciels d'apprentissage automatique.<br />
<br />
Le premier problème que nous avons rencontré que le Weka n'est pas compatible avec android. Nous avons utilisé une version "strippé" de weka présent sur le lien gitHub suivant [https://github.com/rjmarsan/Weka-for-Android https://github.com/rjmarsan/Weka-for-Android].<br />
<br />
Notre prise de décision utilise les données suivantes<br />
* Angle formé un triplé de point <br />
* l'accélération entre les points de saisie<br />
<br />
Nous avons pu ainsi mettre en place dans un premier temmps un système d'authentification.<br />
[[Image:WekaSchema_authentification_2013.png|200px|thumb|center|upright=5|WekaSchema_authentification_2013]]<br />
[[Image:WekaSchema_identification_2013.png|200px|thumb|center|upright=5|WekaSchema_identification_2013.png]]<br />
[[Image:WekaSchema_identification2_2013.png|200px|thumb|center|upright=5|WekaSchema_identification2_2013.png]]</div>Nicolacmhttps://air.imag.fr/index.php?title=File:WekaSchema_authentification_2013.png&diff=10193File:WekaSchema authentification 2013.png2013-03-22T10:05:49Z<p>Nicolacm: </p>
<hr />
<div></div>Nicolacmhttps://air.imag.fr/index.php?title=File:WekaSchema_identification2_2013.png&diff=10191File:WekaSchema identification2 2013.png2013-03-22T10:04:16Z<p>Nicolacm: </p>
<hr />
<div></div>Nicolacmhttps://air.imag.fr/index.php?title=File:WekaSchema_identification_2013.png&diff=10190File:WekaSchema identification 2013.png2013-03-22T10:03:14Z<p>Nicolacm: uploaded a new version of "File:WekaSchema identification 2013.png"</p>
<hr />
<div></div>Nicolacmhttps://air.imag.fr/index.php?title=File:WekaSchema_identification_2013.png&diff=10189File:WekaSchema identification 2013.png2013-03-22T10:02:15Z<p>Nicolacm: </p>
<hr />
<div></div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10188PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T10:01:30Z<p>Nicolacm: tion</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membre du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Nous ne sommmes basé sur le travail des années précédantes et avons choisi [http://fr.wikipedia.org/wiki/Weka_(apprentissage_automatique) Weka ]comme logiciels d'apprentissage automatique.<br />
<br />
Le premier problème que nous avons rencontré que le Weka n'est pas compatible avec android. Nous avons utilisé une version "strippé" de weka présent sur le lien gitHub suivant [https://github.com/rjmarsan/Weka-for-Android https://github.com/rjmarsan/Weka-for-Android].<br />
<br />
Notre prise de décision utilise les données suivantes<br />
* Angle formé un triplé de point <br />
* l'accélération entre les points de saisie<br />
<br />
Nous avons pu ainsi mettre en place dans un premier temmps un système d'authentification.</div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10187PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T09:56:46Z<p>Nicolacm: /* Prise de décision */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membre du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Nous ne sommmes basé sur le travail des années précédantes et avons choisi [http://fr.wikipedia.org/wiki/Weka_(apprentissage_automatique) Weka ]comme logiciels d'apprentissage automatique.<br />
<br />
Le premier problème que nous avons rencontré que le Weka n'est pas compatible avec android. Nous avons utilisé une version "strippé" de weka présent sur le lien gitHub suivant [https://github.com/rjmarsan/Weka-for-Android https://github.com/rjmarsan/Weka-for-Android].<br />
<br />
Notre prise de décision utilise les données suivantes<br />
* Angle formé un triplé de point <br />
* l'accélération entre les points de saisie</div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10181PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T09:48:44Z<p>Nicolacm: /* Prise de décision */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membre du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Nous ne sommmes basé sur le travail des années précédantes et avons choisi [http://fr.wikipedia.org/wiki/Weka_(apprentissage_automatique) Weka ]comme logiciels d'apprentissage automatique.<br />
<br />
Le premier problème que nous avons rencontré que le Weka n'est pas compatible avec android. Nous nous avons utilisé une version "strippé" de weka présent sur le lien gitHub suivant [https://github.com/rjmarsan/Weka-for-Android https://github.com/rjmarsan/Weka-for-Android].</div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10172PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T09:41:41Z<p>Nicolacm: /* Prise de décision */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membre du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Nous ne sommmes basé sur le travail des années précédantes et avons choisi [http://fr.wikipedia.org/wiki/Weka_(apprentissage_automatique) Weka ]comme logiciels d'apprentissage automatique.</div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10155PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T09:25:45Z<p>Nicolacm: /* Prise de décision */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membre du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Par la suite il faudra implémenter un petit module de prise de décision, c'est celui-ci qui décidera, en fonction d'un seuil, si une signature est acceptée ou pas. Ainsi d'autre critères d'acceptations pourront être rajoutés.</div>Nicolacmhttps://air.imag.fr/index.php?title=PAGE_WIKI_ETUDIANTS_2012-13_SIGNATURES&diff=10142PAGE WIKI ETUDIANTS 2012-13 SIGNATURES2013-03-22T08:21:01Z<p>Nicolacm: /* Etude de faisabilité */</p>
<hr />
<div>=Projet reconnaissance de signature 2012-2013=<br />
==Description du projet==<br />
===Membre du projet===<br />
Florian FOURURE - RICM5 - Polytech Grenoble - ffourure@free.fr<br />
<br />
Qikai GU - RICM5 - Polytech Grenoble - qikai.gu88@gmail.com<br />
<br />
Rolly NGOUALA - RICM5 - Polytech Grenoble - rollyngouala@gmail.com<br />
<br />
[[User:Nicolacm |Mickaël NICOLACCINI ]] - RICM5 - Polytech Grenoble - m.nicolaccini@gmail.com<br />
<br />
Soriya PRAK - RICM5 - Polytech Grenoble - soriya-prak@hotmail.fr<br />
<br />
Joachim SEGALA - RICM5 - Polytech Grenoble - joachim.segala@gmail.com<br />
<br />
=== Description du projet===<br />
Ce projet consiste a créer une application Android de reconnaissance de signature. Pour cela, nous devons utiliser le projet de reconnaissance de signature réalisé l'année d'avant (2011/2012) [[PAGE_WIKI_ETUDIANTS_2011-12_SIGNATURES|Page wiki du projet de reconnaissance de signature 2011/2012]]. Ce projet utilise une tablette graphique et un écran de DS3. Nous devons donc changer le code pour l'adapter à Android.<br />
<br />
===Gantt prévisionnel===<br />
Voici le gantt prévisionnel que nous avons réalisé. Il se compose de deux diagrammes. Le Gantt en lui même pour voir les différentes taches ainsi que leur durée. Le diagramme de ressources, pour voir la répartition des taches.<br />
[[File:Gantt_prev.png|thumb|center|upright=3|alt=Gantt prévisionnel|Gantt prévisionnel]]<br />
[[File:Ressource_prev.png|thumb|center|upright=3|alt=Distribution des ressources prévisionnel|Distribution des ressources prévisionnel]]<br />
<br />
===Description des taches===<br />
<br />
====Interface Homme Machine====<br />
Pour réaliser l'Interface Homme machine une pré-étude des l'IHM du projet de 2011/2012.<br />
Ensuite cette étape ce décomposeras en 4 parties :<br />
<br />
=====Réalisation des interfaces abstraite =====<br />
Pas encore réalisé.<br />
<br />
Développeur : Rolly / Florian(à 50%)<br />
<br />
=====Arbres des taches=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
=====Réalisation des interfaces concrètes=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
===== Implémentation=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Rolly / Florian (à 50%)<br />
<br />
====Noyau====<br />
En plus de réaliser la portabilité de l'application sur Android, le projet prévois en plus de modifié les méthodes de calcul des distances entre deux signatures.<br />
<br />
=====Prise en main de l'ancien noyau=====<br />
L'année dernière, la comparaison des signatures reposait sur les coordonnées dans le plan de chaque point ainsi que le temps d'acquisition et la pression exercée. Nous n'avons pas repris cette méthode car elle nécessite une normalisation des signatures qui consiste à faire pivoter les signatures afin qu'elles aient la même orientation, puis modifier la taille pour qu'elles aient la même. Sans cette normalisation, les 2 signatures ne peuvent pas être comparées car elles sont considérées comme étant différentes. <br />
<br />
Cette année, nous avons décidé de basé nos calculs sur les angles formés entre 3 points et l'accélération entre 2 points. Nous n'avons ainsi pas besoin d'effectuer une normalisation car les angles sont conservés quelque soit la forme de la signature. <br />
<br />
Comme l’année précédente nous effectuons un traitement sur les données acquises afin d’obtenir un nombre de point fixe, dans notre cas 1000 points par signature issus de l’interpolation.<br />
La classe Vecteur permet de calculer l’angle formé par un triplet de points et l’accélération entre 2 points.<br />
<br />
Le calcul des angles pose un problème : pour des valeurs comprises entre 0° et 360° les angles proches de 0° (la ligne droite) génère une erreur. Pour des mesures allant de -180° à 180° c’est le demi-tour qui génère une erreur. Nous avons décidé de garder la seconde solution car il et rare de faire un demi-tour dans une signature, contrairement à la ligne droite.<br />
<br />
=====Calcul de distance===== <br />
<br />
Après avoir récupérer tous les points, nous calculons la liste des angles générés et l'accélération, chaque signature compte 1000 points, ces points sont générés par interpolation de la méthode B-Spline. Nous construisons 2 courbes pour chaque signature, une courbe sur les angles et une courbe d'accélération. <br />
<br />
Pour le calcul de distance, nous disposons d'une courbe modèle et nous construisons les autres courbes grâce aux acquisitions. La méthode du Dynamic Time Warping nous permet de calculer la distance entre nos 2 séries de données, ici nos courbes. Plus la distance retournée est faible, plus les courbes sont similaires. A l’inverse, un résultat élevé indique des courbes différentes. <br />
<br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Diagramme de classes/Diagramme de séquence=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
=====Implémentation Android=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Joachim / Soriya<br />
<br />
====Acquisition====<br />
Vue que le projet change de support d'acquisition, toutes les données enregistrées ne sont pas forcément accessible. Par exemple la pression d'un point n'est pas forcément récupérable sur Android. Cependant d'autre données peuvent, peut-être, être récupérées.<br />
Il faut donc faire une étude de faisabilité afin de savoir quelles données notre application va capter.<br />
Ensuite un prototype (non relié au reste de l'application) doit être réalisé afin de l'intégrer ensuite à l'application. <br />
<br />
=====Etude de faisabilité =====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai / Rolly<br />
<br />
=====Prototype=====<br />
Pas encore réalisé. <br />
<br />
Développeur : Mickaël / Qikai<br />
<br />
====Prise de décision====<br />
Par la suite il faudra implémenté un petit module de prise de décision, c'est celui-ci qui décideras, en fonction d'un seuil, au autre, si une signature est accepter ou pas. Ainsi d'autre critères d'acceptation pourrons être rajouté.</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=10102RobAIR2013-RICM5-Suivi2013-03-21T18:45:32Z<p>Nicolacm: /* 21/03/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=6|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=3|alt= Architecture ROS - Draft]] <br />
<br />
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.<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=3|alt=Robair_2013_clients_jitsi]]<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/03/13 ===<br />
* Création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* '''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.<br />
* Mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** Changement mineur dans l'API<br />
** Utilisation du JabberID dans le processus de réservation<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/03/13 ===<br />
* Test de visio via http<br />
* '''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.<br />
* 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:<br />
** Gestion du cyle de vie du process gstreamer (Quand le le lancer, l'arreter proprement)<br />
** Sécurité : le flux video ne doit pas être facilement interceptable<br />
<br />
server = HttpStreamer()<br />
# lancer le serveur<br />
server.start()<br />
<br />
url = server.url_for_stream <br />
<br />
# arreter le serveur explicitement<br />
server.stop()<br />
<br />
<br />
=== 13/03/13 ===<br />
<br />
Utiliser un proxy pour mettre en place RPC. <br />
<br />
'''Qu'est qu'un objet proxy?''' : C'est un objet qui se fait passer pour un autre objet. Exemple<br />
<br />
<br />
class Model(object):<br />
def add(self, *args):<br />
return sum((int(i) for i in args))<br />
<br />
<br />
class MyProxy(object):<br />
def __init__(self, model):<br />
self.model_ins = model()<br />
<br />
def __getattr__(self, name):<br />
return self.model_ins.__getattribute__(name)<br />
<br />
<br />
a = MyProxy(Model)<br />
print a.add(3, 5)<br />
# 8<br />
<br />
<br />
=== 14/02/13 ===<br />
<br />
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.<br />
<br />
Exemple de fonctionnement : <br />
<br />
'''Coté serveur :'''<br />
class RobotManager(ClientXMPP):<br />
@remote<br />
def add(self, *args):<br />
return sum((int(i) for i in args))<br />
<br />
'''Coté client :'''<br />
class Client(ClientXMPP):<br />
pass<br />
<br />
client = Client(jid, passwrd)<br />
# Creation d'un proxy pour appeler les methoded distanted<br />
robot_proxy = client.get_proxy("remote_robot@jabber.com")<br />
<br />
assert robot_proxy.add(5, 6, 4, -5) == 0<br />
<br />
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)<br />
<br />
==Semaine : 18/03/13 - 22/03/13==<br />
<br />
=== 18/03/13 ===<br />
* Création d'un noeud de capture des événements WiiMote (utilisation de cwiid)<br />
$ > sudo apt-get install python-cwiid] )<br />
<br />
* Exemple d'utilisation de cwiid avec python<br />
<br />
import cwiid<br />
<br />
# Pair with any present wiimote (can take a wiimote MAC addr as a parameter)<br />
wm = cwiid.Wiimote()<br />
<br />
# Enable button and accelerometer data reception<br />
wm.rpt_mode = cwiid.RPT_BTN | cwiid.RPT_ACC<br />
<br />
# Access a button state<br />
button_A_pressed = wm.state['buttons'] & cwiid.BTN_A<br />
<br />
# Rumble<br />
wm.rumble=True<br />
<br />
# Access accelerometer values of 3 wiimotes axis<br />
# Values are bounded in the [95,155] interval, ~125 is « straight »<br />
wiiX = wm.state['acc'][0]<br />
wiiY = wm.state['acc'][1]<br />
wiiZ = wm.state['acc'][2]<br />
<br />
# end using wiimote<br />
wm.close()<br />
<br />
* Tutoriel pour graver le bootloader sur Wild Thumper Controller avec une Arduino Uno : [http://air.imag.fr/mediawiki/index.php/RobAIR2013-RICM5-Suivi/BurnBootloader voir ici]<br />
<br />
=== 21/03/13 ===<br />
* '''Soutenance''' [[Media:Projet_RobAIR2013_diapo.pdf |Transparents]] - [[Media:Flyer-RobAIR.pdf|Flyer]] - [[Media:Poster-RobAIR.pdf|Poster]] - [http://youtu.be/-3mbR5M8lzw Video] - [http://robair.quicker.fr/ Site web]<br />
<br />
<br />
Nous léguons le flambeau aux RICM4, et aux étudiants des années futures</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=10101RobAIR2013-RICM5-Suivi2013-03-21T18:44:48Z<p>Nicolacm: /* 21/03/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=6|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=3|alt= Architecture ROS - Draft]] <br />
<br />
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.<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=3|alt=Robair_2013_clients_jitsi]]<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/03/13 ===<br />
* Création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* '''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.<br />
* Mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** Changement mineur dans l'API<br />
** Utilisation du JabberID dans le processus de réservation<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/03/13 ===<br />
* Test de visio via http<br />
* '''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.<br />
* 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:<br />
** Gestion du cyle de vie du process gstreamer (Quand le le lancer, l'arreter proprement)<br />
** Sécurité : le flux video ne doit pas être facilement interceptable<br />
<br />
server = HttpStreamer()<br />
# lancer le serveur<br />
server.start()<br />
<br />
url = server.url_for_stream <br />
<br />
# arreter le serveur explicitement<br />
server.stop()<br />
<br />
<br />
=== 13/03/13 ===<br />
<br />
Utiliser un proxy pour mettre en place RPC. <br />
<br />
'''Qu'est qu'un objet proxy?''' : C'est un objet qui se fait passer pour un autre objet. Exemple<br />
<br />
<br />
class Model(object):<br />
def add(self, *args):<br />
return sum((int(i) for i in args))<br />
<br />
<br />
class MyProxy(object):<br />
def __init__(self, model):<br />
self.model_ins = model()<br />
<br />
def __getattr__(self, name):<br />
return self.model_ins.__getattribute__(name)<br />
<br />
<br />
a = MyProxy(Model)<br />
print a.add(3, 5)<br />
# 8<br />
<br />
<br />
=== 14/02/13 ===<br />
<br />
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.<br />
<br />
Exemple de fonctionnement : <br />
<br />
'''Coté serveur :'''<br />
class RobotManager(ClientXMPP):<br />
@remote<br />
def add(self, *args):<br />
return sum((int(i) for i in args))<br />
<br />
'''Coté client :'''<br />
class Client(ClientXMPP):<br />
pass<br />
<br />
client = Client(jid, passwrd)<br />
# Creation d'un proxy pour appeler les methoded distanted<br />
robot_proxy = client.get_proxy("remote_robot@jabber.com")<br />
<br />
assert robot_proxy.add(5, 6, 4, -5) == 0<br />
<br />
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)<br />
<br />
==Semaine : 18/03/13 - 22/03/13==<br />
<br />
=== 18/03/13 ===<br />
* Création d'un noeud de capture des événements WiiMote (utilisation de cwiid)<br />
$ > sudo apt-get install python-cwiid] )<br />
<br />
* Exemple d'utilisation de cwiid avec python<br />
<br />
import cwiid<br />
<br />
# Pair with any present wiimote (can take a wiimote MAC addr as a parameter)<br />
wm = cwiid.Wiimote()<br />
<br />
# Enable button and accelerometer data reception<br />
wm.rpt_mode = cwiid.RPT_BTN | cwiid.RPT_ACC<br />
<br />
# Access a button state<br />
button_A_pressed = wm.state['buttons'] & cwiid.BTN_A<br />
<br />
# Rumble<br />
wm.rumble=True<br />
<br />
# Access accelerometer values of 3 wiimotes axis<br />
# Values are bounded in the [95,155] interval, ~125 is « straight »<br />
wiiX = wm.state['acc'][0]<br />
wiiY = wm.state['acc'][1]<br />
wiiZ = wm.state['acc'][2]<br />
<br />
# end using wiimote<br />
wm.close()<br />
<br />
* Tutoriel pour graver le bootloader sur Wild Thumper Controller avec une Arduino Uno : [http://air.imag.fr/mediawiki/index.php/RobAIR2013-RICM5-Suivi/BurnBootloader voir ici]<br />
<br />
=== 21/03/13 ===<br />
* Soutenance<br />
[[Media:Projet_RobAIR2013_diapo.pdf |Transparents]] - [[Media:Flyer-RobAIR.pdf|Flyer]] - [[Media:Poster-RobAIR.pdf|Poster]] [http://youtu.be/-3mbR5M8lzw Video] - [http://robair.quicker.fr/ Site web]<br />
<br />
Nous léguons le flambeau aux RICM4, et aux étudiants des années futures</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=10100RobAIR2013-RICM5-Suivi2013-03-21T18:40:50Z<p>Nicolacm: /* 18/03/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=6|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=3|alt= Architecture ROS - Draft]] <br />
<br />
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.<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=3|alt=Robair_2013_clients_jitsi]]<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/03/13 ===<br />
* Création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* '''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.<br />
* Mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** Changement mineur dans l'API<br />
** Utilisation du JabberID dans le processus de réservation<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/03/13 ===<br />
* Test de visio via http<br />
* '''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.<br />
* 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:<br />
** Gestion du cyle de vie du process gstreamer (Quand le le lancer, l'arreter proprement)<br />
** Sécurité : le flux video ne doit pas être facilement interceptable<br />
<br />
server = HttpStreamer()<br />
# lancer le serveur<br />
server.start()<br />
<br />
url = server.url_for_stream <br />
<br />
# arreter le serveur explicitement<br />
server.stop()<br />
<br />
<br />
=== 13/03/13 ===<br />
<br />
Utiliser un proxy pour mettre en place RPC. <br />
<br />
'''Qu'est qu'un objet proxy?''' : C'est un objet qui se fait passer pour un autre objet. Exemple<br />
<br />
<br />
class Model(object):<br />
def add(self, *args):<br />
return sum((int(i) for i in args))<br />
<br />
<br />
class MyProxy(object):<br />
def __init__(self, model):<br />
self.model_ins = model()<br />
<br />
def __getattr__(self, name):<br />
return self.model_ins.__getattribute__(name)<br />
<br />
<br />
a = MyProxy(Model)<br />
print a.add(3, 5)<br />
# 8<br />
<br />
<br />
=== 14/02/13 ===<br />
<br />
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.<br />
<br />
Exemple de fonctionnement : <br />
<br />
'''Coté serveur :'''<br />
class RobotManager(ClientXMPP):<br />
@remote<br />
def add(self, *args):<br />
return sum((int(i) for i in args))<br />
<br />
'''Coté client :'''<br />
class Client(ClientXMPP):<br />
pass<br />
<br />
client = Client(jid, passwrd)<br />
# Creation d'un proxy pour appeler les methoded distanted<br />
robot_proxy = client.get_proxy("remote_robot@jabber.com")<br />
<br />
assert robot_proxy.add(5, 6, 4, -5) == 0<br />
<br />
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)<br />
<br />
==Semaine : 18/03/13 - 22/03/13==<br />
<br />
=== 18/03/13 ===<br />
* Création d'un noeud de capture des événements WiiMote (utilisation de cwiid)<br />
$ > sudo apt-get install python-cwiid] )<br />
<br />
* Exemple d'utilisation de cwiid avec python<br />
<br />
import cwiid<br />
<br />
# Pair with any present wiimote (can take a wiimote MAC addr as a parameter)<br />
wm = cwiid.Wiimote()<br />
<br />
# Enable button and accelerometer data reception<br />
wm.rpt_mode = cwiid.RPT_BTN | cwiid.RPT_ACC<br />
<br />
# Access a button state<br />
button_A_pressed = wm.state['buttons'] & cwiid.BTN_A<br />
<br />
# Rumble<br />
wm.rumble=True<br />
<br />
# Access accelerometer values of 3 wiimotes axis<br />
# Values are bounded in the [95,155] interval, ~125 is « straight »<br />
wiiX = wm.state['acc'][0]<br />
wiiY = wm.state['acc'][1]<br />
wiiZ = wm.state['acc'][2]<br />
<br />
# end using wiimote<br />
wm.close()<br />
<br />
* Tutoriel pour graver le bootloader sur Wild Thumper Controller avec une Arduino Uno : [http://air.imag.fr/mediawiki/index.php/RobAIR2013-RICM5-Suivi/BurnBootloader voir ici]<br />
<br />
=== 21/03/13 ===<br />
* Soutenance</div>Nicolacmhttps://air.imag.fr/index.php?title=Soutenances_Projet_RICM_5_2012-2013&diff=10004Soutenances Projet RICM 5 2012-20132013-03-21T09:50:25Z<p>Nicolacm: /* Planning */</p>
<hr />
<div>==Planning==<br />
<br />
{|class="wikitable alternance"<br />
|+ Planning Jeudi 21/03 P257 ([[Polytech Grenoble]])<br />
|-<br />
|<br />
!scope="col"| Horaire<br />
!scope="col"| Projet<br />
!scope="col"| Encadrant(s)<br />
!scope="col"| Etudiant(s)<br />
!scope="col"| Documents<br />
|-<br />
!scope="row"| 1<br />
| 13H00-13H45<br />
| [[RobAIR2013]]<br />
| [[User:Donsez|Didier Donsez]]<br />
| NICOLACCINI MICKAEL , ALEXANDRE ARTHUR, Salem HARRACHE , PAZ HERNANDEZ ELIZABETH<br />
| [http://air.imag.fr/mediawiki/index.php/RobAIR2013-RICM5-Suivi Fiche suivi RobAIR] - [[Media:Projet_RobAIR2013_diapo.pdf |Transparents]] - [[Media:Flyer-RobAIR.pdf|Flyer]] - [[Media:Poster-RobAIR.pdf|Poster]] [http://youtu.be/-3mbR5M8lzw Video] - [http://robair.quicker.fr/ Site web]<br />
|-<br />
!scope="row"| 2<br />
| 13H45-14H30<br />
| Armind<br />
| Renaud Blanch, Nicolas Glade, Nicolas Vuillerme, Didier Pradon (APHP Garches)<br />
| CHEVALLIER MARIE (PL), FALL YACINE, LU XIAO<br />
| [http://air.imag.fr/mediawiki/index.php/Armind Fiche de suivi Armind] & [[Media:presentationArmind.ppt|transparents]] & [[Media:flyersArmind.ppt|flyers]] & [[Media:posterArmind.jpg|poster]]<br />
|-<br />
!scope="row"| 3<br />
| 14H30-14H45<br />
| Pause<br />
|-<br />
!scope="row"| 4<br />
| 14H45-15H15<br />
| [[Fusion multi-capteurs pour table tactile]]<br />
| Renaud Blanch, Renaud Collin<br />
| RAOUX MAXENCE (PL), DAUVERGNE LEOPOLD<br />
| [http://air.imag.fr/mediawiki/index.php/Fusion_multi-capteurs_pour_table_tactile fiche suivi] & [[transparents ...]] & [http://air.imag.fr/mediawiki/images/0/07/FliyerSonarTable.pdf Flyer] & [http://air.imag.fr/mediawiki/images/thumb/2/2f/PosterSonarTable.jpg/600px-PosterSonarTable.jpg Poster] & [http://www.youtube.com/watch?v=8VKd9UdPNmc Video]<br />
|-<br />
!scope="row"| 5<br />
| 15H15-16H00<br />
| [[Projet Réseaux de Capteurs]]<br />
| Bernard Tourancheau<br />
| CARAMELLI NOE-JEAN (PL), LEVEQUE FLORIAN, HO MINH QUAN<br />
| [[fiche suivi ...]] & [[transparents ...]] & [[Media:Coconode_flyer.pdf | Flyer]] & [[Media:Coconode_poster.pdf | Poster]] & [[video ...]]<br />
|-<br />
!scope="row"| 6<br />
| 16H00-16H30<br />
| [[OAR Cloud Computing 2013]]<br />
| Olivier Richard<br />
| MERCIER MICHAEL (PL)<br />
| [[Proj-2012-2013-OAR-Cloud | fiche suivi]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|}<br />
<br />
<br />
<br />
{|class="wikitable alternance"<br />
|+ Planning Vendredi 22/03 P249 ([[Polytech Grenoble]])<br />
|-<br />
|<br />
!scope="col"| Horaire<br />
!scope="col"| Projet<br />
!scope="col"| Encadrant(s)<br />
!scope="col"| Etudiant(s)<br />
!scope="col"| Documents<br />
|-<br />
!scope="row"| 1<br />
| 14H30-15H15<br />
| [[Projet 2013 : Interactive Digital Signage]]<br />
| [[User:Donsez|Didier Donsez]]<br />
| FOURURE FLORIAN, BISCH SIMON (PL), CLAVELIN AURELIEN<br />
| [[fiche suivi ...]] & [http://air.imag.fr/mediawiki/index.php/File:-BISCH-FOURURE-CLAVELIN--RICM5-IDS-Presentation.pdf transparents] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|-<br />
!scope="row"| 2<br />
| 15H15-16H00<br />
| [http://www.cervin.org/wiki/index.php?title=Prototype_SmartPhone Projet CERVIN de "Rehab Lab"]<br />
| Renaud Blanch, Francois Letellier de l'association [http://www.aconit.org/ ACONIT], le [http://www.ccsti-grenoble.org/ CCSTI Grenoble]<br />
| OSWALD CAMILLE, WIRTH CLÉMENT, PRAK SORIYA, GNATTO-BAHIE CHRISTOPHER<br />
| [http://www.cervin.org/wiki/index.php?title=Prototype_SmartPhone Wiki projet Cervin] & [[Media:cervinPres.ppt]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|-<br />
!scope="row"| 3<br />
| 16H00-16H45<br />
| [[Développement d'une appli mobile pour urgentistes en Afrique utilisant la synthèse vocale]]<br />
| Laurent Besacier, F. Camara et la [http://voxygen.fr/ société Voxygen]<br />
| ELOY FABIEN, NGOUALA ROLLY, VIGIER SYLVAIN, GU QIKAI, SEGALA JOACHIM<br />
| [[fiche suivi ...]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|}<br />
<br />
==Recommandations==<br />
* Prévenez vos tuteurs de votre horaire de passage pour qu'ils assistent à votre soutenance (ainsi que des éventuels changements).<br />
* La durée des soutenances est STRICTEMENT 45 minutes (et 30 minutes pour Michael Mercier)<br />
* Chaque soutenance comporte 20 minutes de présentation, 15 minutes de démonstration suivi de 10 minutes de questions/réponse<br />
* La présentation doit aborder l'ensemble des aspects du projet (contexte, technique, gestion, ...)<br />
* Les transparents doivent être ajoutés à cette page avant le Jeudi matin<br />
* Des ''flyers'' (3 volets d'un A4) et un poster (A4 ou 2*A4 ou A3) devront être apportés puis laissés dans la salle AIR.<br />
<br />
==Conseils==<br />
* Le chef de projet orchestre<br />
* Répétez plusieurs fois et chronométrez vous !<br />
* Répartissez vous la parole pendant la présentation et la démo<br />
* Attention à l' ''effet démo'' : prévoyez une vidéo de secours</div>Nicolacmhttps://air.imag.fr/index.php?title=Soutenances_Projet_RICM_5_2012-2013&diff=10003Soutenances Projet RICM 5 2012-20132013-03-21T09:49:28Z<p>Nicolacm: /* Planning */</p>
<hr />
<div>==Planning==<br />
<br />
{|class="wikitable alternance"<br />
|+ Planning Jeudi 21/03 P257 ([[Polytech Grenoble]])<br />
|-<br />
|<br />
!scope="col"| Horaire<br />
!scope="col"| Projet<br />
!scope="col"| Encadrant(s)<br />
!scope="col"| Etudiant(s)<br />
!scope="col"| Documents<br />
|-<br />
!scope="row"| 1<br />
| 13H00-13H45<br />
| [[RobAIR2013]]<br />
| [[User:Donsez|Didier Donsez]]<br />
| NICOLACCINI MICKAEL , ALEXANDRE ARTHUR, Salem HARRACHE , PAZ HERNANDEZ ELIZABETH<br />
| [http://air.imag.fr/mediawiki/index.php/RobAIR2013-RICM5-Suivi Fiche suivi RobAIR] - [[File:Projet_RobAIR2013_diapo.pdf |Transparents]] - [[Media:Flyer-RobAIR.pdf|Flyer]] - [[Media:Poster-RobAIR.pdf|Poster]] [http://youtu.be/-3mbR5M8lzw Video] - [http://robair.quicker.fr/ Site web]<br />
|-<br />
!scope="row"| 2<br />
| 13H45-14H30<br />
| Armind<br />
| Renaud Blanch, Nicolas Glade, Nicolas Vuillerme, Didier Pradon (APHP Garches)<br />
| CHEVALLIER MARIE (PL), FALL YACINE, LU XIAO<br />
| [http://air.imag.fr/mediawiki/index.php/Armind Fiche de suivi Armind] & [[Media:presentationArmind.ppt|transparents]] & [[Media:flyersArmind.ppt|flyers]] & [[Media:posterArmind.jpg|poster]]<br />
|-<br />
!scope="row"| 3<br />
| 14H30-14H45<br />
| Pause<br />
|-<br />
!scope="row"| 4<br />
| 14H45-15H15<br />
| [[Fusion multi-capteurs pour table tactile]]<br />
| Renaud Blanch, Renaud Collin<br />
| RAOUX MAXENCE (PL), DAUVERGNE LEOPOLD<br />
| [http://air.imag.fr/mediawiki/index.php/Fusion_multi-capteurs_pour_table_tactile fiche suivi] & [[transparents ...]] & [http://air.imag.fr/mediawiki/images/0/07/FliyerSonarTable.pdf Flyer] & [http://air.imag.fr/mediawiki/images/thumb/2/2f/PosterSonarTable.jpg/600px-PosterSonarTable.jpg Poster] & [http://www.youtube.com/watch?v=8VKd9UdPNmc Video]<br />
|-<br />
!scope="row"| 5<br />
| 15H15-16H00<br />
| [[Projet Réseaux de Capteurs]]<br />
| Bernard Tourancheau<br />
| CARAMELLI NOE-JEAN (PL), LEVEQUE FLORIAN, HO MINH QUAN<br />
| [[fiche suivi ...]] & [[transparents ...]] & [[Media:Coconode_flyer.pdf | Flyer]] & [[Media:Coconode_poster.pdf | Poster]] & [[video ...]]<br />
|-<br />
!scope="row"| 6<br />
| 16H00-16H30<br />
| [[OAR Cloud Computing 2013]]<br />
| Olivier Richard<br />
| MERCIER MICHAEL (PL)<br />
| [[Proj-2012-2013-OAR-Cloud | fiche suivi]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|}<br />
<br />
<br />
<br />
{|class="wikitable alternance"<br />
|+ Planning Vendredi 22/03 P249 ([[Polytech Grenoble]])<br />
|-<br />
|<br />
!scope="col"| Horaire<br />
!scope="col"| Projet<br />
!scope="col"| Encadrant(s)<br />
!scope="col"| Etudiant(s)<br />
!scope="col"| Documents<br />
|-<br />
!scope="row"| 1<br />
| 14H30-15H15<br />
| [[Projet 2013 : Interactive Digital Signage]]<br />
| [[User:Donsez|Didier Donsez]]<br />
| FOURURE FLORIAN, BISCH SIMON (PL), CLAVELIN AURELIEN<br />
| [[fiche suivi ...]] & [http://air.imag.fr/mediawiki/index.php/File:-BISCH-FOURURE-CLAVELIN--RICM5-IDS-Presentation.pdf transparents] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|-<br />
!scope="row"| 2<br />
| 15H15-16H00<br />
| [http://www.cervin.org/wiki/index.php?title=Prototype_SmartPhone Projet CERVIN de "Rehab Lab"]<br />
| Renaud Blanch, Francois Letellier de l'association [http://www.aconit.org/ ACONIT], le [http://www.ccsti-grenoble.org/ CCSTI Grenoble]<br />
| OSWALD CAMILLE, WIRTH CLÉMENT, PRAK SORIYA, GNATTO-BAHIE CHRISTOPHER<br />
| [http://www.cervin.org/wiki/index.php?title=Prototype_SmartPhone Wiki projet Cervin] & [[Media:cervinPres.ppt]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|-<br />
!scope="row"| 3<br />
| 16H00-16H45<br />
| [[Développement d'une appli mobile pour urgentistes en Afrique utilisant la synthèse vocale]]<br />
| Laurent Besacier, F. Camara et la [http://voxygen.fr/ société Voxygen]<br />
| ELOY FABIEN, NGOUALA ROLLY, VIGIER SYLVAIN, GU QIKAI, SEGALA JOACHIM<br />
| [[fiche suivi ...]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|}<br />
<br />
==Recommandations==<br />
* Prévenez vos tuteurs de votre horaire de passage pour qu'ils assistent à votre soutenance (ainsi que des éventuels changements).<br />
* La durée des soutenances est STRICTEMENT 45 minutes (et 30 minutes pour Michael Mercier)<br />
* Chaque soutenance comporte 20 minutes de présentation, 15 minutes de démonstration suivi de 10 minutes de questions/réponse<br />
* La présentation doit aborder l'ensemble des aspects du projet (contexte, technique, gestion, ...)<br />
* Les transparents doivent être ajoutés à cette page avant le Jeudi matin<br />
* Des ''flyers'' (3 volets d'un A4) et un poster (A4 ou 2*A4 ou A3) devront être apportés puis laissés dans la salle AIR.<br />
<br />
==Conseils==<br />
* Le chef de projet orchestre<br />
* Répétez plusieurs fois et chronométrez vous !<br />
* Répartissez vous la parole pendant la présentation et la démo<br />
* Attention à l' ''effet démo'' : prévoyez une vidéo de secours</div>Nicolacmhttps://air.imag.fr/index.php?title=Soutenances_Projet_RICM_5_2012-2013&diff=10002Soutenances Projet RICM 5 2012-20132013-03-21T09:49:03Z<p>Nicolacm: /* Planning */</p>
<hr />
<div>==Planning==<br />
<br />
{|class="wikitable alternance"<br />
|+ Planning Jeudi 21/03 P257 ([[Polytech Grenoble]])<br />
|-<br />
|<br />
!scope="col"| Horaire<br />
!scope="col"| Projet<br />
!scope="col"| Encadrant(s)<br />
!scope="col"| Etudiant(s)<br />
!scope="col"| Documents<br />
|-<br />
!scope="row"| 1<br />
| 13H00-13H45<br />
| [[RobAIR2013]]<br />
| [[User:Donsez|Didier Donsez]]<br />
| NICOLACCINI MICKAEL , ALEXANDRE ARTHUR, Salem HARRACHE , PAZ HERNANDEZ ELIZABETH<br />
| [http://air.imag.fr/mediawiki/index.php/RobAIR2013-RICM5-Suivi Fiche suivi RobAIR] - [File:Projet_RobAIR2013_diapo.pdf |Transparents]] - [[Media:Flyer-RobAIR.pdf|Flyer]] - [[Media:Poster-RobAIR.pdf|Poster]] [http://youtu.be/-3mbR5M8lzw Video] - [http://robair.quicker.fr/ Site web]<br />
|-<br />
!scope="row"| 2<br />
| 13H45-14H30<br />
| Armind<br />
| Renaud Blanch, Nicolas Glade, Nicolas Vuillerme, Didier Pradon (APHP Garches)<br />
| CHEVALLIER MARIE (PL), FALL YACINE, LU XIAO<br />
| [http://air.imag.fr/mediawiki/index.php/Armind Fiche de suivi Armind] & [[Media:presentationArmind.ppt|transparents]] & [[Media:flyersArmind.ppt|flyers]] & [[Media:posterArmind.jpg|poster]]<br />
|-<br />
!scope="row"| 3<br />
| 14H30-14H45<br />
| Pause<br />
|-<br />
!scope="row"| 4<br />
| 14H45-15H15<br />
| [[Fusion multi-capteurs pour table tactile]]<br />
| Renaud Blanch, Renaud Collin<br />
| RAOUX MAXENCE (PL), DAUVERGNE LEOPOLD<br />
| [http://air.imag.fr/mediawiki/index.php/Fusion_multi-capteurs_pour_table_tactile fiche suivi] & [[transparents ...]] & [http://air.imag.fr/mediawiki/images/0/07/FliyerSonarTable.pdf Flyer] & [http://air.imag.fr/mediawiki/images/thumb/2/2f/PosterSonarTable.jpg/600px-PosterSonarTable.jpg Poster] & [http://www.youtube.com/watch?v=8VKd9UdPNmc Video]<br />
|-<br />
!scope="row"| 5<br />
| 15H15-16H00<br />
| [[Projet Réseaux de Capteurs]]<br />
| Bernard Tourancheau<br />
| CARAMELLI NOE-JEAN (PL), LEVEQUE FLORIAN, HO MINH QUAN<br />
| [[fiche suivi ...]] & [[transparents ...]] & [[Media:Coconode_flyer.pdf | Flyer]] & [[Media:Coconode_poster.pdf | Poster]] & [[video ...]]<br />
|-<br />
!scope="row"| 6<br />
| 16H00-16H30<br />
| [[OAR Cloud Computing 2013]]<br />
| Olivier Richard<br />
| MERCIER MICHAEL (PL)<br />
| [[Proj-2012-2013-OAR-Cloud | fiche suivi]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|}<br />
<br />
<br />
<br />
{|class="wikitable alternance"<br />
|+ Planning Vendredi 22/03 P249 ([[Polytech Grenoble]])<br />
|-<br />
|<br />
!scope="col"| Horaire<br />
!scope="col"| Projet<br />
!scope="col"| Encadrant(s)<br />
!scope="col"| Etudiant(s)<br />
!scope="col"| Documents<br />
|-<br />
!scope="row"| 1<br />
| 14H30-15H15<br />
| [[Projet 2013 : Interactive Digital Signage]]<br />
| [[User:Donsez|Didier Donsez]]<br />
| FOURURE FLORIAN, BISCH SIMON (PL), CLAVELIN AURELIEN<br />
| [[fiche suivi ...]] & [http://air.imag.fr/mediawiki/index.php/File:-BISCH-FOURURE-CLAVELIN--RICM5-IDS-Presentation.pdf transparents] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|-<br />
!scope="row"| 2<br />
| 15H15-16H00<br />
| [http://www.cervin.org/wiki/index.php?title=Prototype_SmartPhone Projet CERVIN de "Rehab Lab"]<br />
| Renaud Blanch, Francois Letellier de l'association [http://www.aconit.org/ ACONIT], le [http://www.ccsti-grenoble.org/ CCSTI Grenoble]<br />
| OSWALD CAMILLE, WIRTH CLÉMENT, PRAK SORIYA, GNATTO-BAHIE CHRISTOPHER<br />
| [http://www.cervin.org/wiki/index.php?title=Prototype_SmartPhone Wiki projet Cervin] & [[Media:cervinPres.ppt]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|-<br />
!scope="row"| 3<br />
| 16H00-16H45<br />
| [[Développement d'une appli mobile pour urgentistes en Afrique utilisant la synthèse vocale]]<br />
| Laurent Besacier, F. Camara et la [http://voxygen.fr/ société Voxygen]<br />
| ELOY FABIEN, NGOUALA ROLLY, VIGIER SYLVAIN, GU QIKAI, SEGALA JOACHIM<br />
| [[fiche suivi ...]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
|}<br />
<br />
==Recommandations==<br />
* Prévenez vos tuteurs de votre horaire de passage pour qu'ils assistent à votre soutenance (ainsi que des éventuels changements).<br />
* La durée des soutenances est STRICTEMENT 45 minutes (et 30 minutes pour Michael Mercier)<br />
* Chaque soutenance comporte 20 minutes de présentation, 15 minutes de démonstration suivi de 10 minutes de questions/réponse<br />
* La présentation doit aborder l'ensemble des aspects du projet (contexte, technique, gestion, ...)<br />
* Les transparents doivent être ajoutés à cette page avant le Jeudi matin<br />
* Des ''flyers'' (3 volets d'un A4) et un poster (A4 ou 2*A4 ou A3) devront être apportés puis laissés dans la salle AIR.<br />
<br />
==Conseils==<br />
* Le chef de projet orchestre<br />
* Répétez plusieurs fois et chronométrez vous !<br />
* Répartissez vous la parole pendant la présentation et la démo<br />
* Attention à l' ''effet démo'' : prévoyez une vidéo de secours</div>Nicolacmhttps://air.imag.fr/index.php?title=File:Projet_RobAIR2013_diapo.pdf&diff=9998File:Projet RobAIR2013 diapo.pdf2013-03-21T09:45:53Z<p>Nicolacm: </p>
<hr />
<div></div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9622RobAIR2013-RICM5-Suivi2013-03-13T09:16:24Z<p>Nicolacm: /* 07/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=6|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=3|alt= Architecture ROS - Draft]] <br />
<br />
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.<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=3|alt=Robair_2013_clients_jitsi]]<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/02/13 ===<br />
* Test de visio via http</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9621RobAIR2013-RICM5-Suivi2013-03-13T08:59:04Z<p>Nicolacm: /* Architecture ROS détaillée */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=6|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|left|upright=3|alt= Architecture ROS - Draft]] [[File:Robair_2013_clients_jitsi.png |thumb|right|upright=3|alt=Robair_2013_clients_jitsi]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/02/13 ===<br />
* Test de visio via http</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9620RobAIR2013-RICM5-Suivi2013-03-12T22:31:08Z<p>Nicolacm: /* Architecture ROS détaillée */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=7|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|left|upright=3|alt= Architecture ROS - Draft]] [[File:Robair_2013_clients_jitsi.png |thumb|right|upright=3|alt=Robair_2013_clients_jitsi]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/02/13 ===<br />
* Test de visio via http</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9619RobAIR2013-RICM5-Suivi2013-03-12T22:30:35Z<p>Nicolacm: /* Architecture ROS détaillée */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=8|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|left|upright=3|alt= Architecture ROS - Draft]] [[File:Robair_2013_clients_jitsi.png |thumb|right|upright=3|alt=Robair_2013_clients_jitsi]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/02/13 ===<br />
* Test de visio via http</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9618RobAIR2013-RICM5-Suivi2013-03-12T22:30:00Z<p>Nicolacm: /* Architecture ROS détaillée */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=6|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|left|upright=3|alt= Architecture ROS - Draft]] [[File:Robair_2013_clients_jitsi.png |thumb|right|upright=3|alt=Robair_2013_clients_jitsi]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/02/13 ===<br />
* Test de visio via http</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9617RobAIR2013-RICM5-Suivi2013-03-12T22:29:13Z<p>Nicolacm: /* Semaine 5: 04/03/13 - 08/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|left|upright=3|alt= Architecture ROS - Draft]] [[File:Robair_2013_clients_jitsi.png |thumb|right|upright=3|alt=Robair_2013_clients_jitsi]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/02/13 ===<br />
* Test de visio via http</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9616RobAIR2013-RICM5-Suivi2013-03-12T22:28:45Z<p>Nicolacm: /* 12/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|left|upright=3|alt= Architecture ROS - Draft]] [[File:Robair_2013_clients_jitsi.png |thumb|right|upright=3|alt=Robair_2013_clients_jitsi]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/02/13 ===<br />
* Test de visio via http</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9615RobAIR2013-RICM5-Suivi2013-03-12T22:25:10Z<p>Nicolacm: /* 07/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|left|upright=3|alt= Architecture ROS - Draft]] [[File:Robair_2013_clients_jitsi.png |thumb|right|upright=3|alt=Robair_2013_clients_jitsi]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/02/13 ===</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9614RobAIR2013-RICM5-Suivi2013-03-12T22:23:57Z<p>Nicolacm: /* 07/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=3|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=3|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
* Pistes sur le problème de la carte: le bootloader [http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader]<br />
<br />
=== 12/02/13 ===</div>Nicolacmhttps://air.imag.fr/index.php?title=Soutenances_Projet_RICM_5_2012-2013&diff=9613Soutenances Projet RICM 5 2012-20132013-03-12T21:41:19Z<p>Nicolacm: /* Planning */</p>
<hr />
<div>==Planning==<br />
'''Jeudi 21/03 Salle A Confirmer'''<br />
<br>13H00-13H45 Armind (Renaud Blanch, Nicolas Glade, Nicolas Vuillerme) --> CHEVALLIER MARIE (PL), FALL YACINE, LU XIAO [[fiche suivi ...]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]]<br />
<br>13H45-14H30 RobAIR2013 (Didier Donsez) --> NICOLACCINI MICKAEL , ALEXANDRE ARTHUR, HARRACHE SALEM, PAZ HERNANDEZ ELIZABETH [[RobAIR2013-RICM5-Suivi| fiche suivi]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
<br>14H30-14H45 Pause<br />
<br>14H45-15H15 Fusion multi-capteurs pour table tactile (Renaud Blanch, Renaud Collin) --> RAOUX MAXENCE (PL), DAUVERGNE LEOPOLD [[fiche suivi RobAIR2013-RICM5-Suivi]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
<br>15H15-16H00 Développement d'une appli mobile pour urgentistes en Afrique utilisant la synthèse vocale (Laurent Besacier, F. Camara et la société Voxygen) --> ELOY FABIEN, NGOUALA ROLLY, VIGIER SYLVAIN, GU QIKAI, SEGALA JOACHIM [[fiche suivi ...]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
<br>16H00-16H30 Projet Cloud Computing Middleware (Olivier Richard) --> MERCIER MICHAEL (PL) [[fiche suivi ...]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
<br />
'''Vendredi 22/03 Salle A Confirmer'''<br />
<br>14H30-15H15 Projet CERVIN de "Rehab Lab" (Renaud Blanch, Francois Letellier d'ACONIT, le CCSTI) en commun avec 3I5 --> OSWALD CAMILLE, WIRTH CLÉMENT, PRAK SORIYA, GNATTO-BAHIE CHRISTOPHER [[fiche suivi ...]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
<br>15H15-16H00 Projet 2013 : Interactive Digital Signage (Didier Donsez) --> FOURURE FLORIAN, BISCH SIMON (PL), CLAVELIN AURELIEN [[fiche suivi ...]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
<br>16H00-16H45 Projet Réseaux de Capteurs (Bernard Tourancheau) --> CARAMELLI NOE-JEAN (PL), LEVEQUE FLORIAN, HO MINH QUAN [[fiche suivi ...]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]<br />
<br />
==Recommandations==<br />
* Prévenez vos tuteurs de votre horaire de passage pour qu'ils assistent à votre soutenance (ainsi que des éventuels changements).<br />
* La durée des soutenances est STRICTEMENT 45 minutes (et 30 minutes pour Michael Mercier)<br />
* Chaque soutenance comporte 20 minutes de présentation, 15 minutes de démonstration suivi de 10 minutes de questions/réponse<br />
* La présentation doit aborder l'ensemble des aspects du projet (contexte, technique, gestion, ...)<br />
* Les transparents doivent être ajoutés à cette page avant le Jeudi matin<br />
* Des ''flyers'' (3 volets d'un A4) et un poster (A4 ou 2*A4 ou A3) devront être apportés puis laissés dans la salle AIR.<br />
<br />
==Conseils==<br />
* Le chef de projet orchestre<br />
* Répétez plusieurs fois et chronométrez vous !<br />
* Répartissez vous la parole pendant la présentation et la démo<br />
* Attention à l' ''effet démo'' : prévoyez une vidéo de secours</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9584RobAIR2013-RICM5-Suivi2013-03-12T09:50:29Z<p>Nicolacm: /* 11/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
<br />
=== 12/02/13 ===</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9583RobAIR2013-RICM5-Suivi2013-03-12T09:49:34Z<p>Nicolacm: /* 11/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte: http://letsmakerobots.com/files/Wild_Thumper_Diagnostic.zip<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* Noeud de capture de clavier terminé<br />
* mise à jour du Portail de réservation: [https://github.com/SalemHarrache/robair-resource-manager#test]<br />
** enrichissement de l'api<br />
<br />
=== 12/02/13 ===</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9581RobAIR2013-RICM5-Suivi2013-03-12T09:47:04Z<p>Nicolacm: /* 08/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS_v2.png |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
Les différents scenarios du projet RobAIR sont dans le fichier suivant:<br />
[[File:Scenarios.pdf]]<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence (entre systèmes) projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
<gallery caption="Diagramme de séquence (entre noeuds et topics) projet RobAIR"><br />
Image:DiagrammesSequence-avancer-details.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto-details.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo-details.png|Obtention d'information supplémentaires <br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot Wild Thumper : http://www.generationrobots.com/dagu-wild-thumper-chassis-robotique-6x6,fr,4,6x6-Dagu-Wild-Thumper.cfm<br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte: https://www.sparkfun.com/products/11057<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)<br />
<br />
<br />
=== 08/02/13 ===<br />
* Developpement du bot XMPP, en particulier d'un mecanisme d'appel de function via XMPP<br />
<br />
[[Image:Robair2013_RPC_XMPP_Echo_Add.png|200px|thumb|right|ROBAIR RPC XMPP]]<br />
<br />
<br />
class RobBot(BotXMPP):<br />
<br />
@botcmd<br />
def echo(self, message):<br />
return message<br />
<br />
@botcmd<br />
def add(self, *args):<br />
return sum([int(i) for i in args])<br />
<br />
* Calibrage des moteurs de la carte<br />
<br />
[[Image:Calibrage.jpg|200px|thumb|right|ROBAIR Calibrage Wild Thumper]]<br />
<br />
* Erreur lors du chargement du programme sur la carte<br />
<br />
avrdude: stk500_recv(): programmer is not responding<br />
<br />
==Semaine 6: 11/03/13 - 15/03/13==<br />
<br />
=== 11/02/13 ===<br />
* création du noeud ClientVisio (affichage de flux video http via pyside)<br />
* mise à jour du Portail de réservation<br />
<br />
=== 12/02/13 ===</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9406RobAIR2013-RICM5-Suivi2013-03-06T10:45:00Z<p>Nicolacm: /* 06/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS.jpg |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
=== Spécifications ===<br />
<br />
==== Scénarios ====<br />
<br />
==== Cas d'utilisation ====<br />
<br />
<gallery caption="Cas d'utilisation projet RobAIR"><br />
Image:UseCase-Scenario.jpg|Cas d'utilisation du Système Robair<br />
Image:Usecase.jpg|Cas d'utilisation du Système Robair (en détails)<br />
Image:UseCase-Portail.jpg|Cas d'utilisation Portail de réservation<br />
</gallery><br />
<br />
==== Diagramme de séquence ====<br />
<br />
<gallery caption="Diagramme de séquence projet RobAIR"><br />
Image:DiagrammesSequence-avancer.png|Déplacement du robot (avancer)<br />
Image:DiagrammesSequence-goto.png|Déplacement du robot vers un point spécifique<br />
Image:DiagrammesSequence-moreinfo.png|Obtention d'information supplémentaires <br />
Image:DiagrammesSequence-portail.png|Portail de réservation<br />
</gallery><br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* Séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot <br />
* Récupération de la batterie pour le robot et alimentation pour la carte<br />
* Début des tests avec la carte<br />
<br />
=== 06/02/13 ===<br />
* Rédaction Dossier management de projets: estimation des couts & matrice de risque<br />
* Prototype de pickle (librairie de serialisation)</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9379RobAIR2013-RICM5-Suivi2013-03-05T20:43:49Z<p>Nicolacm: /* Equipe */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto:ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS.jpg |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot <br />
* '''à completer par Elizabeth et Arthur'''<br />
<br />
=== 06/02/13 ===<br />
* Prototype de pickle (librairie de serialisation)</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013&diff=9378RobAIR20132013-03-05T20:42:52Z<p>Nicolacm: /* Fiches de suivi des Groupes d'étudiants */</p>
<hr />
<div>[[Image:wifibot-configuration.jpg|300px|thumb|right|Configuration 1]]<br />
[[Image:robair-configuration2.png|300px|thumb|right|Configuration 2]]<br />
<br />
==Contexte==<br />
La robotique de service se différencie de la robotique industrielle par sa prise en compte de l'humain. Le robot de service cohabite et collabore avec et pour des humains. Pour l'Europe, ce domaine est au cœur d'enjeux sociétaux très importants avec le vieillissement de la population. Le marché de la robotique de service est estimée à 14 milliards d'euro en 2017. Les robots de télé-présence est un type de robot de service permettant à son pilote de participer à distance à des visites et des réunions. Un robot de télé-présence est essentiellement un système de visioconférence monté sur un châssis robotique mobile dont le pilotage peut être plus ou moins assisté (suivi d'un guide, d'un chemin prédéfini, ...) ou bridé (zone interdite, ...)<br />
<br />
Préalablement imaginé pour permettre à un collaborateur distant d'utiliser un robot pris dans un pool comme un avatar lors de la réunion et lors des offs, les applications des robots de télé-présence ne se limitent pas à la collaboration en entreprise. A titre d’exemple, ils peuvent servir à l’intervention d'experts à distance sur site sensible (salle blanche, nucléaire, fablabs ...), aux travailleurs à domicile pour continuer à garder le lien social dans l’entreprise (participation aux pause-cafés), visite de musée pour personnes âgées ou fragiles isolées (campagne, banlieue, MAD, HAD, ...), insertion sociale des enfants bulles (participation aux anniversaires de copains, fêtes de famille, ...), visite familiale des personnes âgées en maison de retraite, … Plusieurs fabricants se sont positionnés sur ce marché: Texai de Willow Garage, Ava de iRobot, Jazz de Gostai, QB de Anybots.<br />
<br />
==Description==<br />
Le projet RobAIR propose le développement d'une plateforme de robotique de téléprésence ouverte destiné à la fois à l'enseignement de l'intelligence ambiante et à l’expérimentation à faible coût (ie très en dessous du prix des plateformes du marché) de la robotique de service dans des environnements réels. Cette plateforme se veut extensible et libre source (open software, open hardware, open design, open data) et d'un coup abordable.<br />
<br />
Pour plus d'information, '''voir [[RobAIR]].'''<br />
<br />
<br />
En 2013, le projet RobAIR sera l’occasion de collaborations transversales inter-département Polytech, inter-composantes, inter-établissements (Polytech, ENSIMAG, Pole Design de Villefontaine) et même internationales (relations en cours avec l'Université Fédérale de Rio Grande do Sul, Porto Alegre, Brésil). Plusieurs équipes mixtes d'étudiants et l'élèves ingénieurs collaboreront à la réalisation des différents volets de robot de télé-présence (mécanique, automatique, électronique, capteurs, chaine d'acquisition, gestion d'énergie, programmation robotique Urbi et ROS, guidage, visio immersive, SLAM, réservation, roaming wifi, qos réseau, ihm pilotage …).<br />
Plusieurs expérimentations sont prévues notamment pour la visite de musée (CCSTI la Casemate) et la collaboration inter-fablab grenobloises.<br />
<br />
La plateforme robotique de RobAIR sera constituée de 2 configurations de robot de télé-présence<br />
* La configuration #1 est destinée à réaliser la preuve de concept d'extensions logicielles et matérielles du robot. Elle se base sur un châssis mobile de type LynxMotion A4WD1 (400 euros) équipé de capteurs variés en fonction de l'application et sur lequel est « docké » une tablette Wifi 7 à 9 pouces. Sa hauteur ne dépasse pas les 50 cms de hauteur et son poids ne dépasse pas 5 kgs. La configuration #1 est similaire au wifibot (vendu 5000 euros) ou au Turtlebot (vendu 1500 euros)<br />
* La configuration #2 est destinée à l'expérimentation en environnement réel (musée, fablab, maison de retraite). D'une hauteur d'1m30 et d'un poids de 25kg, le châssis mobile se base sur un système de propulsion Devantech RD03 (800 euros avec les batteries mais hors matériaux châssis et capteurs) et sur laquelle est « docké » une tablette Wifi 11 pouces. La configuration #2 est similaire au Jazz (vendu 10000 euros).<br />
<br />
==Matériels==<br />
===Configuration 1 pour les preuves de concept===<br />
<br />
* Base robot LynxMotion A4WD1 Aluminium http://www.robotshop.com/eu/productinfo.aspx?pc=RB-Lyn-400&lang=fr-CA<br />
* Kinect for Windows<br />
* Caméras fixes ou PTZ USB<br />
* Lidar (http://www.robotshop.com/eu/capteur-distance-laser-urg-04lx-ug01-hokuyo-eu-2.html)<br />
* Tablette Atom 7 poouces (wifi, bluetooth)<br />
* Carte embarqué ARM9 + capteurs (Snowball, ...) Linux +/- Android<br />
* Pince robotique http://www.robotshop.com/eu/kit-little-grip-lynxmotion.html<br />
* Chargeurs de batteries LiPo<br />
* Clavier Logitek K400<br />
<br />
===Configuration 2 pour l'expérimentation===<br />
* Système de Propulsion de Robot 24V Devantech RD03 (http://www.robotshop.com/eu/systeme-propulsion-robot-24v-devantech-rd03.html)<br />
* Kinect for Windows<br />
* Caméra stéréoscopique USB<br />
* Lidar (http://www.robotshop.com/eu/capteur-distance-laser-urg-04lx-ug01-hokuyo-eu-2.html)<br />
* Tablette Atom 11 pouces (wifi, bluetooth)<br />
* Carte embarqué ARM9 + capteurs (Snowball, ...) Linux +/- Android<br />
* Clavier Logitek K400<br />
* Batteries séches au Plomb 12V : [http://www.power-sonic.com/ Power Sonic] [http://www.power-sonic-fr.com/files/PS-1270.French.pdf PS1270] 7 Ah (25 euros) et [http://www.power-sonic-fr.com/files/PS-12120.French.pdf PS12120] 12 Ah (49 euros)<br />
* Chargeurs de batterie 12V<br />
<br />
===Extra===<br />
* 2 x Contrôleur de Moteur Regénératif Sabertooth R / C 2 X 10A 6V-24V Dimension Engineering http://www.robotshop.com/eu/productinfo.aspx?pc=RB-Dim-43&lang=fr-CA<br />
<br />
==Logiciels==<br />
* [[Robot Operating System|ROS]]<br />
* [[Urbi]]<br />
* [[JITSI]]<br />
* [http://voxygen.fr Synthèse Vocale Voxygen]<br />
<br />
[[Image:DiagDeploymentRobAIR.png|Diagramme de déploiement RobAIR]]<br />
<br />
==Sous-projets d'étudiants==<br />
* Recalibrage SLAM par marqueur lumière visible (horizontaux, verticaux)<br />
* SLAM par fusion multi-capteurs<br />
* Pilotage semi automatique en présence de foules<br />
* Pilotage automatique sur un parcours pré-programmmé<br />
* Portail de réservation de robots<br />
* Continuité réseaux (roaming entre robots dans les lieux partitionnés (escaliers, …)<br />
* IHM pilotage --> depuis son canapé avec une tablette et déport d'interface sur la TV (3D)<br />
* Expérimentation dans une exposition en Musée<br />
* Expérimentation dans un cours à distance<br />
* ...<br />
<br />
==Projets connexes==<br />
* Pilotage du robot avec un casque cérébral (voir [[Armind]])<br />
* Création de parcours avec la [[Trodomètre]]<br />
<br />
==Acteurs==<br />
* Polytech Grenoble<br />
* ENSIMAG<br />
* Pole Supérieur de Design de Villefontaine, Agence Monkey Mistake [[RobAIR2013-PSDV|fiche de suivi]]<br />
* CCSTI Grenoble<br />
<br />
==Fiches de suivi des Groupes d'étudiants==<br />
* [[RobAIR2013-3I4-Suivi|3I4]]<br />
* [[RobAIR2013-RICM4-Groupe1-Suivi|RICM4 Groupe1 : Groupe Réseau]]<br />
* [[RobAIR2013-RICM4-Groupe2-Suivi|RICM4 Groupe2 : Groupe Réseau]]<br />
* [[RobAIR2013-RICM4-Groupe3-Suivi|RICM4 Groupe3 : Groupe multimedia]]<br />
* [[RobAIR2013-RICM5-Suivi|RICM5]]<br />
<br />
==Projets antérieurs==<br />
* [[RobAIR]]<br />
* [[RobAIR-Wifibot]]<br />
<br />
==Projets exterieurs et Produits==<br />
* Projet Beaming : infiltrez-vous dans un robot pour le contrôler à distance http://dailygeekshow.com/2012/11/23/projet-beaming-infiltrez-vous-dans-un-robot-pour-le-controler-a-distance/<br />
*[http://www.informationweek.com/byte/personal-tech/mobile-applications/attack-of-the-telepresence-robots/240146106 attack-of-the-telepresence-robots] : Une revue de 4 robots de téléprésence<br />
* un robot de télé surveillance http://www.informationweek.com/byte/personal-tech/science-technology/this-299-robot-can-keep-your-house-safe/240146239<br />
<br />
==Sponsors==<br />
* UJF Polytech, fablab AIR<br />
* ENSIMAG fablab<br />
* Labex Persyval<br />
* Intel Software<br />
<br />
Si vous souhaitez nous aider, envoyez nous vos dons natures ou autres. Merci d'avance.<br />
<br />
==Compétitions et Challenges==<br />
* Third EvAAL Competition (Evaluating AAL Systems through Competitive Benchmarking) http://evaal.aaloa.org Deadline : March 5, 2013</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9377RobAIR2013-RICM5-Suivi2013-03-05T20:40:52Z<p>Nicolacm: /* Equipe */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: [mailto://ricm5-robair2013@googlegroups.com ricm5-robair2013@googlegroups.com]<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS.jpg |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot <br />
* '''à completer par Elizabeth et Arthur'''<br />
<br />
=== 06/02/13 ===<br />
* Prototype de pickle (librairie de serialisation)</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9376RobAIR2013-RICM5-Suivi2013-03-05T20:39:59Z<p>Nicolacm: /* Context */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: ricm5-robair2013@googlegroups.com<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS.jpg |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot <br />
* '''à completer par Elizabeth et Arthur'''<br />
<br />
=== 06/02/13 ===<br />
* Prototype de pickle (librairie de serialisation)</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9375RobAIR2013-RICM5-Suivi2013-03-05T20:39:31Z<p>Nicolacm: /* Context */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: ricm5-robair2013@googlegroups.com<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancées des équipes ENSIMAG ici [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS.jpg |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot <br />
* '''à completer par Elizabeth et Arthur'''<br />
<br />
=== 06/02/13 ===<br />
* Prototype de pickle (librairie de serialisation)</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9374RobAIR2013-RICM5-Suivi2013-03-05T20:38:48Z<p>Nicolacm: /* Context */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: ricm5-robair2013@googlegroups.com<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]], vous aussi suivre les avancer de l'équipe ENSIMAG ici [http://fablab.ensimag.fr/index.php/RobAIR ici ]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS.jpg |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot <br />
* '''à completer par Elizabeth et Arthur'''<br />
<br />
=== 06/02/13 ===<br />
* Prototype de pickle (librairie de serialisation)</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013&diff=9373RobAIR20132013-03-05T20:34:50Z<p>Nicolacm: /* Fiches de suivi des Groupes d'étudiants */</p>
<hr />
<div>[[Image:wifibot-configuration.jpg|300px|thumb|right|Configuration 1]]<br />
[[Image:robair-configuration2.png|300px|thumb|right|Configuration 2]]<br />
<br />
==Contexte==<br />
La robotique de service se différencie de la robotique industrielle par sa prise en compte de l'humain. Le robot de service cohabite et collabore avec et pour des humains. Pour l'Europe, ce domaine est au cœur d'enjeux sociétaux très importants avec le vieillissement de la population. Le marché de la robotique de service est estimée à 14 milliards d'euro en 2017. Les robots de télé-présence est un type de robot de service permettant à son pilote de participer à distance à des visites et des réunions. Un robot de télé-présence est essentiellement un système de visioconférence monté sur un châssis robotique mobile dont le pilotage peut être plus ou moins assisté (suivi d'un guide, d'un chemin prédéfini, ...) ou bridé (zone interdite, ...)<br />
<br />
Préalablement imaginé pour permettre à un collaborateur distant d'utiliser un robot pris dans un pool comme un avatar lors de la réunion et lors des offs, les applications des robots de télé-présence ne se limitent pas à la collaboration en entreprise. A titre d’exemple, ils peuvent servir à l’intervention d'experts à distance sur site sensible (salle blanche, nucléaire, fablabs ...), aux travailleurs à domicile pour continuer à garder le lien social dans l’entreprise (participation aux pause-cafés), visite de musée pour personnes âgées ou fragiles isolées (campagne, banlieue, MAD, HAD, ...), insertion sociale des enfants bulles (participation aux anniversaires de copains, fêtes de famille, ...), visite familiale des personnes âgées en maison de retraite, … Plusieurs fabricants se sont positionnés sur ce marché: Texai de Willow Garage, Ava de iRobot, Jazz de Gostai, QB de Anybots.<br />
<br />
==Description==<br />
Le projet RobAIR propose le développement d'une plateforme de robotique de téléprésence ouverte destiné à la fois à l'enseignement de l'intelligence ambiante et à l’expérimentation à faible coût (ie très en dessous du prix des plateformes du marché) de la robotique de service dans des environnements réels. Cette plateforme se veut extensible et libre source (open software, open hardware, open design, open data) et d'un coup abordable.<br />
<br />
Pour plus d'information, '''voir [[RobAIR]].'''<br />
<br />
<br />
En 2013, le projet RobAIR sera l’occasion de collaborations transversales inter-département Polytech, inter-composantes, inter-établissements (Polytech, ENSIMAG, Pole Design de Villefontaine) et même internationales (relations en cours avec l'Université Fédérale de Rio Grande do Sul, Porto Alegre, Brésil). Plusieurs équipes mixtes d'étudiants et l'élèves ingénieurs collaboreront à la réalisation des différents volets de robot de télé-présence (mécanique, automatique, électronique, capteurs, chaine d'acquisition, gestion d'énergie, programmation robotique Urbi et ROS, guidage, visio immersive, SLAM, réservation, roaming wifi, qos réseau, ihm pilotage …).<br />
Plusieurs expérimentations sont prévues notamment pour la visite de musée (CCSTI la Casemate) et la collaboration inter-fablab grenobloises.<br />
<br />
La plateforme robotique de RobAIR sera constituée de 2 configurations de robot de télé-présence<br />
* La configuration #1 est destinée à réaliser la preuve de concept d'extensions logicielles et matérielles du robot. Elle se base sur un châssis mobile de type LynxMotion A4WD1 (400 euros) équipé de capteurs variés en fonction de l'application et sur lequel est « docké » une tablette Wifi 7 à 9 pouces. Sa hauteur ne dépasse pas les 50 cms de hauteur et son poids ne dépasse pas 5 kgs. La configuration #1 est similaire au wifibot (vendu 5000 euros) ou au Turtlebot (vendu 1500 euros)<br />
* La configuration #2 est destinée à l'expérimentation en environnement réel (musée, fablab, maison de retraite). D'une hauteur d'1m30 et d'un poids de 25kg, le châssis mobile se base sur un système de propulsion Devantech RD03 (800 euros avec les batteries mais hors matériaux châssis et capteurs) et sur laquelle est « docké » une tablette Wifi 11 pouces. La configuration #2 est similaire au Jazz (vendu 10000 euros).<br />
<br />
==Matériels==<br />
===Configuration 1 pour les preuves de concept===<br />
<br />
* Base robot LynxMotion A4WD1 Aluminium http://www.robotshop.com/eu/productinfo.aspx?pc=RB-Lyn-400&lang=fr-CA<br />
* Kinect for Windows<br />
* Caméras fixes ou PTZ USB<br />
* Lidar (http://www.robotshop.com/eu/capteur-distance-laser-urg-04lx-ug01-hokuyo-eu-2.html)<br />
* Tablette Atom 7 poouces (wifi, bluetooth)<br />
* Carte embarqué ARM9 + capteurs (Snowball, ...) Linux +/- Android<br />
* Pince robotique http://www.robotshop.com/eu/kit-little-grip-lynxmotion.html<br />
* Chargeurs de batteries LiPo<br />
* Clavier Logitek K400<br />
<br />
===Configuration 2 pour l'expérimentation===<br />
* Système de Propulsion de Robot 24V Devantech RD03 (http://www.robotshop.com/eu/systeme-propulsion-robot-24v-devantech-rd03.html)<br />
* Kinect for Windows<br />
* Caméra stéréoscopique USB<br />
* Lidar (http://www.robotshop.com/eu/capteur-distance-laser-urg-04lx-ug01-hokuyo-eu-2.html)<br />
* Tablette Atom 11 pouces (wifi, bluetooth)<br />
* Carte embarqué ARM9 + capteurs (Snowball, ...) Linux +/- Android<br />
* Clavier Logitek K400<br />
* Batteries séches au Plomb 12V : [http://www.power-sonic.com/ Power Sonic] [http://www.power-sonic-fr.com/files/PS-1270.French.pdf PS1270] 7 Ah (25 euros) et [http://www.power-sonic-fr.com/files/PS-12120.French.pdf PS12120] 12 Ah (49 euros)<br />
* Chargeurs de batterie 12V<br />
<br />
===Extra===<br />
* 2 x Contrôleur de Moteur Regénératif Sabertooth R / C 2 X 10A 6V-24V Dimension Engineering http://www.robotshop.com/eu/productinfo.aspx?pc=RB-Dim-43&lang=fr-CA<br />
<br />
==Logiciels==<br />
* [[Robot Operating System|ROS]]<br />
* [[Urbi]]<br />
* [[JITSI]]<br />
* [http://voxygen.fr Synthèse Vocale Voxygen]<br />
<br />
[[Image:DiagDeploymentRobAIR.png|Diagramme de déploiement RobAIR]]<br />
<br />
==Sous-projets d'étudiants==<br />
* Recalibrage SLAM par marqueur lumière visible (horizontaux, verticaux)<br />
* SLAM par fusion multi-capteurs<br />
* Pilotage semi automatique en présence de foules<br />
* Pilotage automatique sur un parcours pré-programmmé<br />
* Portail de réservation de robots<br />
* Continuité réseaux (roaming entre robots dans les lieux partitionnés (escaliers, …)<br />
* IHM pilotage --> depuis son canapé avec une tablette et déport d'interface sur la TV (3D)<br />
* Expérimentation dans une exposition en Musée<br />
* Expérimentation dans un cours à distance<br />
* ...<br />
<br />
==Projets connexes==<br />
* Pilotage du robot avec un casque cérébral (voir [[Armind]])<br />
* Création de parcours avec la [[Trodomètre]]<br />
<br />
==Acteurs==<br />
* Polytech Grenoble<br />
* ENSIMAG<br />
* Pole Supérieur de Design de Villefontaine, Agence Monkey Mistake [[RobAIR2013-PSDV|fiche de suivi]]<br />
* CCSTI Grenoble<br />
<br />
==Fiches de suivi des Groupes d'étudiants==<br />
* [[RobAIR2013-3I4-Suivi|3I4]]<br />
* [[RobAIR2013-RICM4-Groupe1-Suivi|RICM4 Groupe1 : Groupe Réseau]]<br />
* [[RobAIR2013-RICM4-Groupe2-Suivi|RICM4 Groupe2 : Interface Réseau]]<br />
* [[RobAIR2013-RICM4-Groupe3-Suivi|RICM4 Groupe3 : Interface multimedia]]<br />
* [[RobAIR2013-RICM5-Suivi|RICM5]]<br />
<br />
==Projets antérieurs==<br />
* [[RobAIR]]<br />
* [[RobAIR-Wifibot]]<br />
<br />
==Projets exterieurs et Produits==<br />
* Projet Beaming : infiltrez-vous dans un robot pour le contrôler à distance http://dailygeekshow.com/2012/11/23/projet-beaming-infiltrez-vous-dans-un-robot-pour-le-controler-a-distance/<br />
*[http://www.informationweek.com/byte/personal-tech/mobile-applications/attack-of-the-telepresence-robots/240146106 attack-of-the-telepresence-robots] : Une revue de 4 robots de téléprésence<br />
* un robot de télé surveillance http://www.informationweek.com/byte/personal-tech/science-technology/this-299-robot-can-keep-your-house-safe/240146239<br />
<br />
==Sponsors==<br />
* UJF Polytech, fablab AIR<br />
* ENSIMAG fablab<br />
* Labex Persyval<br />
* Intel Software<br />
<br />
Si vous souhaitez nous aider, envoyez nous vos dons natures ou autres. Merci d'avance.<br />
<br />
==Compétitions et Challenges==<br />
* Third EvAAL Competition (Evaluating AAL Systems through Competitive Benchmarking) http://evaal.aaloa.org Deadline : March 5, 2013</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9372RobAIR2013-RICM5-Suivi2013-03-05T20:27:58Z<p>Nicolacm: /* Semaine 5: 04/03/13 - 08/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: ricm5-robair2013@googlegroups.com<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS.jpg |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
* Mise au point avec les différentes équipe RICM4<br />
* définition du format des<br />
<br />
=== 05/02/13 ===<br />
* Test d'alimentation du robot <br />
* '''à completer par Elizabeth et Arthur'''<br />
<br />
=== 06/02/13 ===<br />
* Prototype de pickle (librairie de serialisation)</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9360RobAIR2013-RICM5-Suivi2013-03-05T09:01:59Z<p>Nicolacm: /* Tâches communes */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: ricm5-robair2013@googlegroups.com<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS.jpg |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
**attributs du message commande<br />
***Speed : [-3 – 3] (négatif == reculer ; positif == avancer)<br />
***Angles [0-180°] : 2bits rotation + 1 bit direction >> 8 valeurs possibles<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
<br />
=== 05/02/13 ===<br />
* Prototype de pickle (librairie de serialisation)</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9335RobAIR2013-RICM5-Suivi2013-03-04T15:57:28Z<p>Nicolacm: /* Semaine 5: 04/03/13 - 08/02/13 */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: ricm5-robair2013@googlegroups.com<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS.jpg |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches<br />
<br />
=== 05/02/13 ===<br />
* Prototype de pickle (librairie de serialisation)</div>Nicolacmhttps://air.imag.fr/index.php?title=RobAIR2013-RICM5-Suivi&diff=9334RobAIR2013-RICM5-Suivi2013-03-04T15:55:59Z<p>Nicolacm: /* Avancement du projet */</p>
<hr />
<div>= Equipe =<br />
Nous sommes 4 étudiants de [http://www.polytech-grenoble.fr Polytech Grenoble ] de la filière [http://www.polytech-grenoble.fr/ricm.html RICM5]<br />
* Arthur Alexandre<br />
* [[User:Nicolacm |Mickaël Nicolaccini]]<br />
* Elizabeth Paz<br />
* [http://salem.harrache.info Salem Harrache]<br />
<br />
Contacter le groupe: ricm5-robair2013@googlegroups.com<br />
<br />
= Sources du projet =<br />
<br />
Le code source du projet est disponible sur github<br />
<br />
== Portail de réservation ==<br />
<br />
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.<br />
<br />
Website : https://github.com/SalemHarrache/robair-resource-manager<br />
<br />
== ROS PKG ==<br />
<br />
Le projet ROS PKG contient l'ensemble des noeuds ROS du projet. <br />
<br />
Website : https://github.com/SalemHarrache/robair-ros-pkg<br />
<br />
== Ros2xmpp ==<br />
<br />
Ros2xmpp est un sous projet qui fait le pont entre ROS et XMPP. Il permet a deux noeuds ROS de communiquer à travers XMPP<br />
<br />
Website : https://github.com/SalemHarrache/robair-ros2xmpp<br />
<br />
[http://im.apinc.org/inscription/?apinc=1&server=im.apinc.org inscription pour un compte Jabber]<br />
<br />
= Context =<br />
Projet en lien avec le Projet [[RobAIR2013]]<br />
== RobAIR ==<br />
<br />
=== Architecture ROS globale ===<br />
<br />
[[File:Architecture_04_02.jpg |thumb|center|upright=5|alt= Architecture RobAir et repartion des groupes|Architecture RobAir et repartion des groupes au 04/02/13]]<br />
<br />
<br />
=== Architecture ROS détaillée ===<br />
<br />
[[File:ArchitectureROS.jpg |thumb|center|upright=5|alt= Architecture RobAir détaillée|Architecture RobAir détaillée au 22/02/13]]<br />
<br />
=== Liste des tâches ===<br />
<br />
==== Tâches communes ====<br />
<br />
* XMPP to ROS : faire un bot qui est capable de sérialiser/désérialiser et envoyer/recevoir des messages ROS à travers XMPP<br />
* Mécanismes de souscription à des topics en lecture et en écriture. Permet au bot XMPP de savoir quel message il doit transférer.<br />
* Faire le noeud HTTPStream :<br />
** Qui encode la vidéo et le son avec un codec adapté au streaming (compromis entre qualité et latence) : utiliser GStreamer.<br />
** 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.<br />
* Topic/cmd : Définir format des messages « commande »<br />
<br />
==== Tâches Système SmartTV ====<br />
<br />
* Noeud Ros clavier (Keyboard) : écoute les événements claviers et dépose des commandes dans le topic/cmd<br />
<br />
* Noeud ROS Android (Android_receiver) :<br />
** Communication Web Socket (Tablette <=> Serveur)<br />
<br />
* Interface Tablette<br />
** Interface Connexion/Réservation<br />
** Interface Contrôle (ex : commandes de mouvement, d’information, etc.)<br />
<br />
* Noeud ROS Wiimote : reprendre les fonctionnalités du noeud Keyboard en utilisant les spécifications de la Wiimote (joystick, boutons, …)<br />
<br />
* Client Manager :<br />
** Intégrer le bot XMPP<br />
** Intégrer les mécanismes de connexion/réservation/contrôle (au sens check) avec le bot<br />
** Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session <br />
<br />
==== Tâches Système Robair ====<br />
<br />
* Noeud RobotManager : son rôle est de recevoir les messages et vérifier si l’utilisateur est autorisé.<br />
** Intégrer le bot XMPP<br />
** Module Vérification sur le portail<br />
<br />
* Intégrer l’envoi de flux vidéo : lancer HTTPStreamer en début de session jabber<br />
<br />
* Noeud MotionControl :<br />
** Interpréter les commandes (« avancer », « reculer »...) haut niveau en une suite de commandes bas niveau (contacter les bons noeuds)<br />
<br />
* Noeud Engine : voir avec les 3i comment utiliser les fonctions de mouvement du robot.<br />
<br />
* Noeud Network : intégrer les scripts de roaming dans ce noeud ROS<br />
<br />
* Noeud Battery : diffuse régulièrement les statistiques de la batterie<br />
<br />
* Noeud PowerControl : ce noeud désactive certains composants en fonction du niveau de la batterie.<br />
<br />
* Navigation automatique<br />
** Noeud Lidar : Voir comment utiliser le lidar (lien série ? api constructeur ?) et également déterminer le format de la map.<br />
** Noeud KinectManager : Permet d'établir à l'aide de la map statique, une map dynamique pour l'évitement des obstacles.<br />
** 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).<br />
** Noeud AutoPilot : Noeud qui reçoit des commandes de très haut niveau.<br />
<br />
* Noeuds prévus pour des projets futurs :<br />
** Noeud Speech_synthesis : pour la reconnaissance vocale<br />
<br />
==== Portail de Réservation ====<br />
<br />
* Développer Portail Réservation simple (renvoie toujours « oui »)<br />
* Utiliser les adresses Jabber pour identifier les utilisateurs et les robots<br />
* Mettre en place un mécanisme d’authentification lors de la réservation<br />
<br />
= Avancement du projet =<br />
<br />
==Semaine 1: 28/01/13 ==<br />
<br />
=== 29/01/13 ===<br />
* Réunion avec Didier Donsez: définition du cadre du projet<br />
<br />
=== 30/01/13 ===<br />
<br />
* Prise de contact avec les autres équipes (RICM4 et 3I4)<br />
* Analyse de l’architecture<br />
** Repartions des recherches architecturales entre les membres de l'équipe RICM5<br />
<br />
=== 01/02/13===<br />
<br />
* Point sur les technologies à utiliser<br />
<br />
<br />
'''Websocket ou Comet'''<br />
<br />
On à décider de partir sur les websockets car c'est un techno plus récente et plus simple à utiliser.<br />
<br />
Voici deux exemples en python:<br />
* [https://github.com/SalemHarrache/websocket_echo_example Serveur echo] avec les websockets ([http://robair.quicker.fr:5000/ DEMO])<br />
* [https://github.com/SalemHarrache/flask_chat_eventsource MultiChat] utilisant le protocole [http://dev.w3.org/html5/eventsource/ Server-Sent Events] ([http://robair.quicker.fr:5001/ DEMO])<br />
<br />
<span style="color:red">À tester en JAVA</span><br />
<br />
'''LibJingle ou libJitsi ou autres ?'''<br />
<br />
<br />
<br />
'''ROS ou Urbi+ROS'''<br />
<br />
==Semaine 2: 04/02/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Réunion avec RICM4.<br />
* mise à jour de l'architecture: Clarification des Rôles<br />
<br />
=== 07/02/13 ===<br />
* Proposition de nouvelle architechture et répartion des taches.<br />
<br />
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)<br />
<br />
Du coup on a essayé de voir comment résoudre autrement le problème qu'a soulèvé Didier Donsez.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Comme un schéma vaut mieux qu'un long discours : (c'est un exemple...)<br />
<br />
[[File:ROS_tunnel_xmpp.png |thumb|center|upright=5|alt= Architecture ROS - Draft]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
[[File:Robair_2013_clients_jitsi.png |thumb|center|upright=5|alt=Robair_2013_clients_jitsi]]<br />
<br />
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).<br />
<br />
<br />
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. <br />
<br />
On respecte ainsi le patron de conception *Faible couplage/Forte cohésion*<br />
<br />
=== 08/02/13 ===<br />
* Reunion 14h: Discution de la nouvelle architecture avec Didier Donsez et présentation des étudiants du Pôle Supérieur de Design de Villefontaine<br />
[https://www.dropbox.com/s/s1fuly1bfbeodcw/presentation_08_02_2013.pdf Présentation Pôle Supérieur de Design]<br />
* Validation de la nouvelle architecture ROS<br />
<br />
==Semaine 3: 11/02/13 - 15/02/13==<br />
=== 11/02/13 ===<br />
* abandon de libjitsi: trop peu d'exemple d'utilisation.<br />
* Jitsi mit de coté pour l'instant<br />
* Etude de libjingle, résultat de recherche encourageant pour l'instant.<br />
<br />
=== 12/02/13 ===<br />
* séance génie Logicielle<br />
<br />
=== 13/02/13 ===<br />
<br />
<br />
* 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<br />
* Test de telepathy-python : http://cgit.freedesktop.org/telepathy/telepathy-python/<br />
<br />
=== 14/02/13 ===<br />
<br />
==== Lib opensource et Jingle ====<br />
<br />
<br />
* <u>Libjingle</u> : malgré tout nos effort, la vidéo ne marche pas.<br />
* <u>Telepathy-python</u> : telepathy-python should be considered deprecated and should not be used for new projects. It is recommended to use pygobject and telepathy-glib<br />
* <u>Telepathy-glib</u> : Tres difficile et trop bas niveau. J'ai pas trouvé comment l'utiliser.<br />
* <u>Psimedia</u> : Lib utiliseé par le client IM Psi. Ne gère que l'audio (de façon experimental) et ne compile pas (projet abondonné ?)<br />
<br />
<br />
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é.<br />
<br />
==== WebRTC ====<br />
<br />
<br />
'''''à compléter par Salem'''''<br />
<br />
==Semaine 4: 18/02/13 - 23/02/13==<br />
<br />
=== 18/02/13 ===<br />
* Création d'un bot se connectant à compte Jabber, réagissant à la reception d'un message: https://github.com/SalemHarrache/libjingle_builder<br />
* Travail en cour sur Jitsi, problème de mise en place d'ipojo.<br />
<br />
=== 19/02/13 ===<br />
* Réunion avec les étudiants de l'ENSIMAG<br />
*sujet abordés<br />
** manipulation kinect (problème de pilote sous linux)<br />
** liste des capteurs necessaire pour SLAM<br />
<br />
=== 20/02/13 ===<br />
* réunion interne: <br />
**videoConf via XMPP mis de coté, utilisation d'échange video via http<br />
* amélioration du Bot XMPP + nettoyage du code<br />
** rajout de la gestion des plugin XMPP<br />
** fonction de connection/déconnection <br />
** envoie de message<br />
** interpretation basique des messages reçu<br />
<br />
=== 21/02/13 ===<br />
* Point sur les differentes taches à effectuer avant la fin du projet.<br />
* Amélioration de l'archicture ROS.<br />
<br />
=== 22/02/13 ===<br />
* Attribution de des taches à différents prototypes de l'architecture globale.<br />
* Repartion des differents prototype des temps, mise en place d'un planning de réalisation des differents prototype.<br />
<br />
==Semaine 5: 04/03/13 - 08/02/13==<br />
<br />
=== 04/02/13 ===<br />
* Création des sprints à partir de la liste des taches</div>Nicolacmhttps://air.imag.fr/index.php?title=User:Alexandre.Corso&diff=9115User:Alexandre.Corso2013-02-23T14:46:30Z<p>Nicolacm: </p>
<hr />
<div>Je suis élève ingénieur en RICM à [http://www.polytech-grenoble.fr Polytech Grenoble].</div>Nicolacmhttps://air.imag.fr/index.php?title=User:Alexandre.Corso&diff=9114User:Alexandre.Corso2013-02-23T14:45:54Z<p>Nicolacm: </p>
<hr />
<div>Je suis élève ingénieur en RICM à [http://www.polytech-grenoble.fr | Polytech Grenoble].</div>Nicolacm