Difference between revisions of "EA2012 Langages et Canevas pour la robotique de service"

From air
Jump to navigation Jump to search
 
(48 intermediate revisions by 2 users not shown)
Line 1: Line 1:
  +
= Présentation =
  +
[[File:Hrp-2-humanoid.jpg|250px|thumb|right|File:Humanoid HRP2]]
  +
 
* Enseignants: Georges-Pierre Bonneau, Didier Donsez
  
* Enseignants: Georges-Pierre Bonneau, Didier Donsez
  +
* Auteurs: Elizabeth Paz <Elizabeth.Paz-Hernandez@e.ujf-grenoble.fr>, Salem Harrache <Salem.Harrache@e.ujf-grenoble.fr>
−
* UE/Module: EAR (HPRJ9R4B) en RICM5
  
  +
* Télécharger (FR):[[Media:Presentation_EA_ROS_URBI_PAZ_%26_HARRACHE.pdf]]
−
* Etudiants: Elizabeth Paz, Salem Harrache
  
   
  +
= Abstract =
−
La version PDF de la présentation est disponible ici : [[File:Presentation_EA_ROS_URBI_PAZ_%26_HARRACHE.pdf]]
  
   
  +
Service robots are robots that assist humans by performing a job. These robots are becoming more and more available to the general public. Those component based complex systems need to interact and communicate one with another. There is an increasing number of middleware that are designed to facilitate the programming of these robots and to make them supported by various machines. In this presentation, we are going to talk about two specific middleware: ROS & Urbi.
−
=Résumé=
  
   
  +
=== Keywords ===
   
  +
robotics development platform, ROS, Urbi, Urbi-script, NXT Mindstorm, WeBots
−
=abstract=
  
   
  +
= Résumé =
   
  +
La robotique de service est la robotique qui rend des services utiles aux personnes. Cette robotique s'étend de plus au plus au marché grand public. Ces systèmes complexes à base de composants (moteur, détecteurs...) ont besoin d'interagir et communiquer entre eux. Il existe de plus en plus de middleware qui tendent à rendre la programmation de ces robots plus facile et compatible entre plusieurs machines.
−
=Introduction=
  
   
  +
Dans cette présentation, nous allons nous intéresser à deux middleware en particulier qui sont ROS et Urbi.
−
=== Principe de la vision : ===
  
   
−
=== Réception des stimuli visuels : ===
  
   
  +
=== Mots Clés ===
−
La vision d'un objet par l’œil se fait par réflexion de la lumière sur un objet puis la réfraction au travers du capteur visuel humain.
 
   
  +
Plateforme de developpement robotique, ROS, Urbi, Urbi-script, NXT Mindstorm, WeBots
−
La lumière est donc focalisée par la lentille avant d'être projetée sur la rétine entièrement inversée, provoquant une réponse des cellules.
  
   
  +
= Synthèse =
−
=== Transcription par l’œil : ===
  
   
  +
La robotique de service peut se définir comme la robotique qui exécute des services utiles
−
[[File:Oeil.jpg|150px|thumb|right|cellules utilisées]]
  
  +
pour le « bien-être » des personnes et des biens. Cette robotique s'étend au marché grand public : cela va du simple robot jouet au robot d’assistance médicale en passant par des “engins” autonomes qui n’assurent que certaines fonctions domestiques (aspirateurs, tondeuses à gazon, etc.).
   
  +
Ces robots sont composés de systèmes complexes à base de composants (moteur, détecteurs...) qui ont besoin d'interagir et communiquer entre eux. Il existe de plus en plus de middleware qui tendent à rendre la programmation de ces robots plus facile et compatible entre plusieurs machines. On peut citer YARP (Yet Another Robot Platform) écrit en C++ et qui permet l’interconnexion entre détecteurs, processeurs et articulation, ou encore l'environnement
−
La rétine est composée de deux catégories de cellule distincte permettant de comprendre certains phénomènes visuels :
  
  +
Microsoft Robotics Developer Studio, qui a l’avantage d’offrir deux types de développement : un SDK classique en C#, mais également la possibilité d'utiliser le VPL (Visual Programming Language) pour modéliser et concevoir les comportements avec des graphes.
   
  +
Nous allons nous intéresser à deux middlware en particulier qui sont ROS et Urbi.
   
  +
== ROS ==
−
les photorécepteurs=>permettent la vision des couleurs et de l'intensité de la lumière.
  
   
  +
=== Introduction ===
   
  +
ROS (Robot Operating System) est un système d’exploitation pour la robotique de service. ROS est un méta système d’exploitation (entre le système d’exploitation et le middleware), il fournit des services proches d’un système d’exploitation (abstraction du matériel, gestion de la concurrence, des processus…) mais aussi des fonctionnalités de haut niveau (appels asynchrones, appels synchrones, base de données centralisée de données, système de paramétrage du robot…).
−
les cellules ganglionnaires=>
  
  +
ROS est développé et maintenu par la société californienne Willow Garage, fondée en 2006 par Scott Hassan, un des premiers employés de Google.
   
  +
=== Principes ===
−
-Les cellules de grande taille associées au contraste et au mouvement ;
  
   
  +
ROS est basé sur 5 principes essentiels :
−
-Les cellules de petite taille pour les formes et détail ;
  
   
  +
*Peer to Peer : ce système permet à chacun des acteurs de dialoguer en direct avec un autre acteur, de manière synchrone ou asynchrone en fonction des besoins.
−
-quelques cellules sont liées au contraste chromatique ;
  
   
  +
*Multi langages : ROS peut être facilement implémenté dans n'importe quel langage, actuellement en Python, C++ et Lisp et en cours en Java et Lua. Les connexions peer to peer sont négociées en XML-RPC qui existe dans un grand nombre de langages.
   
  +
*Basé sur des outils: ROS emploie un design microkernel et utilise de petits outils pour faire le build et le run des différents composants ROS. Chaque commande est en fait un exécutable. L’avantage de cette solution est qu’un problème sur un exécutable n’affecte pas les autres, rendant le système plus robuste et évolutif.
−
Les signaux émis par ces différentes cellules sont distribués dans des zones cérébrales distinctes.
  
   
  +
*Léger : les pilotes et algorithmes soient contenus dans des exécutables indépendants, cela assure la ré-utilisabilité maximale et surtout le maintient d’une taille réduite. Ce mécanisme rend ROS facile d'usage et la complexité se trouve dans les librairies. ROS utilise aussi du code (pilotes et algorithmes) issus d’autres projets open source.
   
  +
*Gratuit et open source: ceci est un moyen d'accélérer les recherches en robotique et rendre les bases plus solides. L'architecture est un reflet de ce choix, ROS passe des données grâce à de la communication interprocess.
−
=== L'interprétation par le cerveau : ===
  
   
  +
=== Fonctionnement ===
−
[[File:Cerveau.jpg|150px |thumb|right|trajet de l'information dans le cerveau]]
  
   
  +
Le principe de base d’un OS robotique est de faire fonctionner en parallèle un grand nombre d’exécutables pour pouvoir échanger de l’information de manière synchrone ou asynchrone. D’autre part, l’OS robotique doit assurer la gestion de la concurrence afin d’assurer l’accès efficace aux ressources du robot.
−
Si l’œil fonctionne toujours de la même manière donc, le cerveau reçoit toujours les mêmes signaux en regardant la même chose. Le cerveau, lui doit interpréter les signaux. Pour comprendre la perception, on peut suivre deux types de parcours :
  
  +
  +
==== ROS File System ====
   
  +
Le « ROS FileSystem » correspond aux concepts statiques.
   
  +
Les ressources de ROS sont organisées dans une structure hiérarchique sur disque. Deux concepts importants:
−
-Le cortex dorsale permet la localisation d'objet ou personne, mobile ou immobile ; il permet aussi les actions comme saisir un objet.
  
  +
* Le package : unité principale d’organisation logicielle de ROS. Un package est un répertoire qui contient les nœuds (voir ci-dessous), les librairies externes, des données, des fichiers de configuration et un fichier de configuration.
  +
*La stack : une collection de packages. Une stack est un répertoire qui contient les répertoires des packages ainsi qu’un fichier de configuration.
   
  +
==== ROS Computation Graph ====
   
  +
Le « ROS Computation Graph » s’agit des concepts utilisés par le système en cours de fonctionnement.
−
-Le cortex ventrale permet l'identification et la reconnaissance des personnes et objets.
  
   
  +
*Les noeuds: un noeud est une instance d’un exécutable. Un noeud peut correspondre à un capteur, un moteur, un algorithme de traitement, de surveillance, etc ... Chaque noeud qui se lance se déclare au Master. Chaque noeud est indépendant.
   
  +
*Le Master: le master est un service de déclaration et d’enregistrement des noeuds qui permet à des nœuds de se connaître et d’échanger de l’information. Il possède
−
La vitesse du traitement de l’information par le cortex inférotemporal est plus lente parce que cela nécessite plus d'intermédiaires.
  
  +
une sous-partie qui est le Parameter Server qui est une base de données centralisée dans laquelle les noeuds peuvent stocker de l'information et partager des paramètres globaux.
   
  +
*Un topic est un système de transport de l’information basé sur le système de l’abonnement / publication (subscribe / publish). Un ou plusieurs noeuds pourront publier de l’information sur un topic et un ou plusieurs nœuds pourront lire l’information sur ce topic. Le topic est bus d’information asynchrone (communication many-to-many asynchrone). Les nœuds envoient ou reçoivent des messages sur des topics.
   
  +
*Le service est un système de communication synchrone entre deux nœuds (communication one-to-one).
−
=== Conclusion : ===
  
   
  +
*Les « bags » sont des formats pour stocker et rejouer les messages échangés.
−
La vision combine à la fois la perception et la connaissance obtenue par l'expérience. Le système visuel semble donc à la fois être dans le code génétique, mais se modifier par l'influence de notre environnement. Ainsi, la perception visuelle de l’environnement est propre à chacun d’entre nous.
  
   
  +
=== Intérêt et avantages ===
−
= De la 2D à la 3D =
  
   
  +
*Éviter de réinventer la roue: avant les OS robotiques chaque concepteur de robot devait passer du temps à concevoir matériellement son robot.
  +
*Proposer des fonctionnalités standardisées pour l'abstraction du matériel: on fait abstraction du matériel
  +
*Rassembler des savoir-faire de différentes disciplines pour gérer le matériel, gérer la mémoire et les processus et
  +
gérer la concurrence et fusion des données (mécanique, électronique, programmation embarquée, ...)
   
−
=== La 3D isométrique ===
 +
== Urbi ==
   
−
[[File:Isometrie.jpg|150px|thumb|right|Illusion de la 3D]]
 +
[[File:Urbi-Logo.png|250px|center]]
−
Le principe naturel de la vision fut pendant longtemps un sujet pour les arts. Bien avant que naisse l'informatique. Les premières traces de 3D trouvée sont des illusions d'optique, qui par le biais de forme géométrique simple, permettent à l’œil humain de voir une image sortante ou entrante.
  
   
−
Exemple : l'anemic cinema de Marcel Duchamp.
  
   
  +
=== Gostaï ===
−
Le principe de ces vues en 3D se base sur la mise en place de la perspective artificielle à l'aide de forme de couleur plus ou moins sombre créant une sorte d'ombre pour le cerveau humain. C'est de cette manière que les bases de la 3D ont été posées dans certains domaines comme l'informatique graphique. Ceci joue seulement sur l'interprétation du cerveau et non sur le fonctionnement des yeux.
  
   
  +
Urbi est une plateforme logicielle de developpement pour la robotique développé par Gostaï [http://www.gostai.com/] en 2006. L'entreprise a été fondé en 2006 par Jean-Christophe Baillie, ancien enseignant chercheur à l'ENSTA ParisPolytech où il a créé le laboratoire de Robotique Cognitive.
−
=== Stéréogrammes ===
  
  +
Le modèle économique de Gostaï repose sur un ensemble de solutions et services d’aide à la création d’applications qui gravitent autour de sa plateforme logicielle opensource (Gostai Lab, Gostai Studio, GostaiNet). Gostaï a été rachetée [http://www.humanoides.fr/2012/08/15/nao-pret-a-gravir-la-marche/] par le français Aldebaran Robotics [http://www.aldebaran-robotics.com/] l’été 2012, et Urbi est passé sous licence BSD depuis octobre 2012 afin de favoriser l'adoption d'Urbi.
   
  +
=== Plateforme logicielle ===
−
[[File:Stereogramme.jpg|150px|thumb|right|Voir au delà de l'image]]
  
   
  +
Urbi permet de s'affranchir d'un grand nombre d'opérations récurrentes et complexes dans le développement pour la robotique. Il est écrit en C++ et est donc compatible avec un grand nombre de plateforme qui compile du C++. Il se base sur une architecture en composants distributés. Ces composants, appelés UObjects, peuvent s’executer en local (sur le robot) ou à distance (sur un serveur de contrôle) pour les robots qui ne disposent pas d’assez de puissance et/ou mémoire. C’est le cas du Minidstorm NXT, qui se contrôle avec Urbi à distance.
   
  +
[[File:Architecture-Urbi.png|250px|center|Architecture client/serveur de Urbi]]
   
  +
=== Urbiscript ===
−
Le principe de la 3D utilisant la vision binoculaire est tout aussi ancien, les stéréogrammes en sont un parfait exemple. Même s’il n'y a qu'une image et aucun instrument nécessaire pour parvenir à distinguer l'image en relief, les stéréogrammes demandent un travail des yeux important en leur demandant de voir "dans" l'image. En effet, pour parvenir à voir un stéréogramme il faut que les deux yeux ne convergent pas vers le dessin, mais au-delà. Ceci crée un décalage dans ce que chacun des deux yeux voit et ainsi l'assemblage des deux images par le cerveau donne un effet de relief. Cependant, les stéréogrammes sont limités à une 3D entrante. L'image ne sort pas, mais se retrouve au fond de l'image.
  
   
  +
L’interêt du C++ vise clairement la performance de l’execution sur des machines qui ne peuvent pas se permettre de gaspiller la moindre ressource. Cependant, pour la partie algorithme, interconnexion et orthestration des composants, Gostaï à mis au point un langage de script plus flexible et plus facile à maintenir : UrbiScript
−
= La 3D stéréoscopique =
  
   
  +
Urbiscript permet entre autre :
−
De nos jours, le nouveau terrain opposant les fabricants d'écrans est la mise en place du système 3D non plus par des perspectives géométriques uniquement, mais par une impression de relief assez importante. Deux branches se distinguent actuellement sur la scène.
  
   
  +
* Execution de script dynamique
−
== 3D avec lunette ==
  
  +
* Programmation événementielle et parallélisme
  +
* Orienté objet pour instancier et manipuler les UObjects
  +
* Coordonne l'ensemble des composants
  +
* Intuitive et asaptés aux débutants comme au developpeurs confirmés
   
  +
=== Démonstration Urbi et NXT Mindstorm ===
−
=== Passive ===
  
   
  +
Pour la démonstration on utilise le [[Lego_Mindstorm_NXT|Lego NXT de Mindstorm]].
−
[[File:Passif.jpg|150px|thumb|right|3D passive=> 2 images en une]]
  
   
   
  +
==== Avancer et reculer ====
   
−
La 3D passive est à l'origine issue du principe de superposition de deux images chacune étant dans une couleur respective par exemple rouge/bleu. Le problème de cette première version était une forte perte de couleur et de l'intensité lumineuse qui résultait de cette séparation des images. De nos jours, la technique utilise la superposition de deux images, mais en plaçant les images sur des rangées de pixels différentes. Cette superposition des images réduit de moitié la résolution verticale.
  
−  
−  
−  
−
=== active ===
  
−  
−
[[File:Actif.jpg|150px|thumb|right|3D Active=> rafraîchir deux fois plus vite]]
  
−  
−  
−  
−
La 3D active fonctionne, elle aussi, sur l'utilisation de deux images légèrement décalées sur le plan horizontal, mais à la différence de la 3D passive la 3D active ne projette pas deux images en simultanées, mais en différées. Les lunettes utilisées ont un système d'obturation qui doit être synchronisé avec l'écran de telle manière que chaque œil puisse voir l'image qui lui est destinée. Ceci implique que les fréquences soient deux fois plus importantes que pour d'autres vidéos puisque chaque œil doit recevoir autant d'information qu'en temps normal ce qui revient a affiché deux fois plus d'images par seconde.
  
−  
−
== La 3D sans lunette ==
  
−  
−
Un nouvel arrivant sur la scène de la 3D est la 3D sans dispositif nécessaire à l’œil pour voir le relief autrement dit l'autostereoscopie.
  
−  
−
=== La barrière de parallaxe ===
  
−
[[File:Parallaxe.jpg|150px|thumb|right|Utilisation du parallaxe]]
  
−  
−  
−
Ce système est composé d’écrans à cristaux liquides où sont intercalés des caches entre la dalle LCD  et le rétro éclairage. Les caches doivent être placés de manière très précise pour que chaque œil reçoive l'information qui lui est destinée. Les images ne sont plus découpées dans le sens vertical, mais dans le sens horizontal, c'est-à-dire que leurs pixels sont alternés suivant les colonnes. Ainsi, grâce au cache et à l'affichage de chacune des images le cerveau n'aura plus qu'à les additionner en créant cet effet de relief.
  
−  
−
De nombreux inconvénients découlent de cette technologie. Premièrement, il faut avoir une position précise ce qui fait que le travail des yeux est plus important, car l'observateur ne peut pas être parfaitement immobile. En plus d'être très fatigant cette technologie ne peut être utilisé que par une personne a là fois, et avec une résolution diminuée dans le sens horizontale.
  
−  
−
Cette technologie est utilisé sur la Nintendo 3DS.
  
−
 
−
=== Alioscopy ===
  
−  
−
[[File:Alioscopie.jpg|150px|thumb|right|utilisation d'un réseau lenticulaire]]
  
−  
−  
−  
−
Français Pierre Allio en 1987
  
−  
−
Cette technologie se base sur le même principe que la 3D passive, cependant pour supprimer l'utilisation des lunettes les pixels sont inclinés suivant l’œil qu'elles doivent affecter pour que les images soient envoyées vers l’œil qui lui correspond. Pour diriger les pixels vers l'oeil qui leur correspond, il faut utiliser un réseau lenticulaire, positionné de manière oblique, il permettra de diriger les rayons lumineux vers différents points de vue.
  
−  
−
Le problème c'est que pour augmenter le nombre de points de vue différents il faut augmenter le nombre de pixels inclinés ; ce qui vient à diviser la résolution verticale proportionnellement au nombre de points de vue à vouloir afficher.
  
−
 
−
=== l’autostéréoscopie Multivue ===
  
−
[[File:Multivue.jpg|150px|thumb|right|3D Multi-spectateur sans lunette]]
  
   
  +
Global.wheels.speed = 50;
  +
sleep (3s);
  +
Global.wheels.speed = −50;
  +
sleep (2s);
  +
Global.wheels.speed = 0;
   
  +
==== Tourner ====
   
  +
L'opérateur '&' permet d'éxecuter deux instructions en même temps. Dans l'exemple ci-dessous, la roue de gauche recule tandis que celle de droite avance, ce qui permet de tourner !
−
L'autostéréoscopie multivue est l'évolution de la 3D active. Pour pouvoir afficher une image en relief, le dispositif affiche les différents points de vue souhaités de manière successive. L'avantage provient du fait qu'il n'y a pas de perte dans la résolution verticale. Cependant, il faut que les images se succèdent dans un très court laps de temps. Ce qui demande un taux de rafraîchissement très élevé de l'ordre de 120 hertz. Cette technique ne perd pas en résolution, mais elle se révèle très fatigante pour les yeux.
  
   
  +
Global.wheelL.speed = - 50 time:1s &
  +
Global.wheelR.speed = 50 time:1s;
  +
  +
Global.wheelL.speed = 0 time:2s &
  +
Global.wheelR.speed = 0 time:2s;
   
  +
==== Explorer ====
−
=== l’autostéréoscopie au cinéma ===
  
−
[[File:Prisme.jpg|150px|thumb|right|Utilisation des prismes pour la 3D]]
  
   
  +
On va utiliser le concept de tag pour encapsuler un comportement particulier, puis controller ce tag directement pour arrêter l'action, la reprendre, ou la mettre en pause.
   
  +
var Global.explorer = Tag.new;
  +
explorer:
  +
{
  +
every(500ms)
  +
wheels.speed = 25;
  +
},
   
  +
Arrêter le robot :
   
  +
explorer.freeze()
  +
wheels.speed = 0;
   
−
Cette technique est uniquement dédiée à la visualisation via un projecteur. En effet, l'écran doit réfléchir les images vers les spectateurs, ceci permet l'utilisation de prismes sur l'écran qui vont renvoyer les images vers les spectateurs même s’ils ne sont pas au centre de la salle. Plus il y a de prismes, plus le nombre de points de vue est élevé. Le grand avantage de cette technique est de garder une résolution importante pour les deux yeux.
  
   
  +
Reprendre l'exploration :
−
= Conclusion =
  
   
  +
explorer.unfreeze()
−
[[File:3Dwar.jpg|150px|thumb|right|cellules utilisées]]
  
   
  +
==== Détecter les obstacles ====
   
  +
La detection des obstacles se fait via le composant sonar (capteur ultrason) qui renseigne sur la distance qui sépare l'obstacle et le robot.
  +
Dès que cette distance passe sous une valeur seuil, on freeze le tag de l'exploration, on fait marche arriere, on tourne legerement, puis on reprend l'exploration.
   
   
  +
var Global.DistanceDanger = 25;
  +
var Global.detecter = Tag.new;
  +
detecter:
  +
{
  +
at (sonar.val < Global.DistanceDanger)
  +
{
  +
explorer.freeze;
  +
// Marche arrièr
  +
wheels.speed = - 50 time:1500ms;
  +
// Tourner
  +
{Global.wheelL.speed = - 50 & Global.wheelR.speed = 50} & sleep(600ms);
  +
stop();
  +
explorer.unfreeze;
  +
},
  +
},
   
  +
==== Contrôler ====
   
  +
Pour contrôler le robot, on utilise le bouton de contact (bumper). A chaque fois que l'on presse sur le bouton, on permute l'etat du robot : Soit on passe en mode exploration, soit on l'arrête.
−
La technologie 3D n'en est qu'à ses débuts dans le domaine du grand public. Cependant, la diversité des dispositifs fait que les écrans se retrouvent dans la même situation qui avait opposé les écrans matriciel et vectoriel. De nouveaux systèmes sont encore à l'étude, tels que l'autostéréoscopie multivue et l'autostéréoscopie au cinéma, qui vont tenter de dominer le marché. Même si certains pensent que la 3D allée se faire progressivement le débat se voit opposer sur un même plan les 3D avec utilisation de lunette et sans l'utilisation de lunette. Nul pour le moment ne peut dire qui remportera ce combat, mais une chose semble évidente, c'est que sans prendre en considération le coût des écrans, l'autostéréoscopie domine le domaine des écrans personnels, tandis que les écrans stéréoscopiques actif ou passif se partagent les écrans des ordinateurs au cinéma.
  
   
  +
var Global.currentState = 0;
−
=Liens=
  
  +
  +
at (bumper.val == 1)
  +
{
  +
if(Global.currentState == 0)
  +
{
  +
echo("On");
  +
Global.currentState = 1;
  +
explorer.unfreeze;
  +
detecter.unfreeze;
  +
}
  +
else
  +
{
  +
echo("Off");
  +
explorer.freeze;
  +
detecter.freeze;
  +
wheels.speed = 0;
  +
Global.currentState = 0;
  +
}|
  +
},
   
  +
= Liens =
−
* Liste des techniques 3D http://www.hdfever.fr/2011/02/04/lautostereoscopie-ou-la-3d-sans-lunettes-retour-sur-la-nouvelle-technologie-du-ces-2011/
  
−
* 3D quelques formats http://stereoscopie.olympe-network.com/autostereoscopie.php
  
−
* La france a l'honneur via Pierre Allio http://www.alioscopy.eu/en/about_us.php
  
−
* La 3D et les tables tactiles http://www.zebulon.fr/actualites/7000-table-multi-touch-multivues-3d-immersion.html
  
−
* 3DTV vizualizer and multiplexer http://3dtv.at
  
−
* [[GStreamer]] et stereoscopy http://gstconf.ubicast.tv/videos/3d-stereoscopic-and-gstreamer/
  
−
* 3D Webcam http://www.minoru3d.com/
  
−
* Lunettes 3D NVidia
  
   
  +
* ROS Website : http://www.ros.org/
−
=Ouvrages=
  
  +
* Gostai website : http://www.gostai.com/
−
* Stereoscopic Cinema. Frederic Devernay and Paul Beardsley. "Image and Geometry Processing for 3-D Cinematography Springer Berlin Heidelberg (Ed.) (2010)11-51"DOI : 10.1007/978-3-642-12392-4.
  
  +
* Wikipedia : http://fr.wikipedia.org/wiki/Urbi
  +
* 2-high : http://www.2-high.info/post/2010/10/08/Installer-URBI-pour-Lego-Mindstorm-NXT
  +
* ardi-rhonealpes : [http://www.ardi-rhonealpes.fr/c/document_library/get_file?uuid=787e7899-9903-4bd7-9e6a-569e032880eb&groupId=10136|la robotique de service et son potentiel en rhone-alpes]

Latest revision as of 19:09, 24 December 2012

Présentation

File:Humanoid HRP2

Abstract

Service robots are robots that assist humans by performing a job. These robots are becoming more and more available to the general public. Those component based complex systems need to interact and communicate one with another. There is an increasing number of middleware that are designed to facilitate the programming of these robots and to make them supported by various machines. In this presentation, we are going to talk about two specific middleware: ROS & Urbi.

Keywords

robotics development platform, ROS, Urbi, Urbi-script, NXT Mindstorm, WeBots

Résumé

La robotique de service est la robotique qui rend des services utiles aux personnes. Cette robotique s'étend de plus au plus au marché grand public. Ces systèmes complexes à base de composants (moteur, détecteurs...) ont besoin d'interagir et communiquer entre eux. Il existe de plus en plus de middleware qui tendent à rendre la programmation de ces robots plus facile et compatible entre plusieurs machines.

Dans cette présentation, nous allons nous intéresser à deux middleware en particulier qui sont ROS et Urbi.


Mots Clés

Plateforme de developpement robotique, ROS, Urbi, Urbi-script, NXT Mindstorm, WeBots

Synthèse

La robotique de service peut se définir comme la robotique qui exécute des services utiles pour le « bien-être » des personnes et des biens. Cette robotique s'étend au marché grand public : cela va du simple robot jouet au robot d’assistance médicale en passant par des “engins” autonomes qui n’assurent que certaines fonctions domestiques (aspirateurs, tondeuses à gazon, etc.).

Ces robots sont composés de systèmes complexes à base de composants (moteur, détecteurs...) qui ont besoin d'interagir et communiquer entre eux. Il existe de plus en plus de middleware qui tendent à rendre la programmation de ces robots plus facile et compatible entre plusieurs machines. On peut citer YARP (Yet Another Robot Platform) écrit en C++ et qui permet l’interconnexion entre détecteurs, processeurs et articulation, ou encore l'environnement Microsoft Robotics Developer Studio, qui a l’avantage d’offrir deux types de développement : un SDK classique en C#, mais également la possibilité d'utiliser le VPL (Visual Programming Language) pour modéliser et concevoir les comportements avec des graphes.

Nous allons nous intéresser à deux middlware en particulier qui sont ROS et Urbi.

ROS

Introduction

ROS (Robot Operating System) est un système d’exploitation pour la robotique de service. ROS est un méta système d’exploitation (entre le système d’exploitation et le middleware), il fournit des services proches d’un système d’exploitation (abstraction du matériel, gestion de la concurrence, des processus…) mais aussi des fonctionnalités de haut niveau (appels asynchrones, appels synchrones, base de données centralisée de données, système de paramétrage du robot…). ROS est développé et maintenu par la société californienne Willow Garage, fondée en 2006 par Scott Hassan, un des premiers employés de Google.

Principes

ROS est basé sur 5 principes essentiels :

  • Peer to Peer : ce système permet à chacun des acteurs de dialoguer en direct avec un autre acteur, de manière synchrone ou asynchrone en fonction des besoins.
  • Multi langages : ROS peut être facilement implémenté dans n'importe quel langage, actuellement en Python, C++ et Lisp et en cours en Java et Lua. Les connexions peer to peer sont négociées en XML-RPC qui existe dans un grand nombre de langages.
  • Basé sur des outils: ROS emploie un design microkernel et utilise de petits outils pour faire le build et le run des différents composants ROS. Chaque commande est en fait un exécutable. L’avantage de cette solution est qu’un problème sur un exécutable n’affecte pas les autres, rendant le système plus robuste et évolutif.
  • Léger : les pilotes et algorithmes soient contenus dans des exécutables indépendants, cela assure la ré-utilisabilité maximale et surtout le maintient d’une taille réduite. Ce mécanisme rend ROS facile d'usage et la complexité se trouve dans les librairies. ROS utilise aussi du code (pilotes et algorithmes) issus d’autres projets open source.
  • Gratuit et open source: ceci est un moyen d'accélérer les recherches en robotique et rendre les bases plus solides. L'architecture est un reflet de ce choix, ROS passe des données grâce à de la communication interprocess.

Fonctionnement

Le principe de base d’un OS robotique est de faire fonctionner en parallèle un grand nombre d’exécutables pour pouvoir échanger de l’information de manière synchrone ou asynchrone. D’autre part, l’OS robotique doit assurer la gestion de la concurrence afin d’assurer l’accès efficace aux ressources du robot.

ROS File System

Le « ROS FileSystem » correspond aux concepts statiques.

Les ressources de ROS sont organisées dans une structure hiérarchique sur disque. Deux concepts importants:

  • Le package : unité principale d’organisation logicielle de ROS. Un package est un répertoire qui contient les nœuds (voir ci-dessous), les librairies externes, des données, des fichiers de configuration et un fichier de configuration.
  • La stack : une collection de packages. Une stack est un répertoire qui contient les répertoires des packages ainsi qu’un fichier de configuration.

ROS Computation Graph

Le « ROS Computation Graph » s’agit des concepts utilisés par le système en cours de fonctionnement.

  • Les noeuds: un noeud est une instance d’un exécutable. Un noeud peut correspondre à un capteur, un moteur, un algorithme de traitement, de surveillance, etc ... Chaque noeud qui se lance se déclare au Master. Chaque noeud est indépendant.
  • Le Master: le master est un service de déclaration et d’enregistrement des noeuds qui permet à des nœuds de se connaître et d’échanger de l’information. Il possède

une sous-partie qui est le Parameter Server qui est une base de données centralisée dans laquelle les noeuds peuvent stocker de l'information et partager des paramètres globaux.

  • Un topic est un système de transport de l’information basé sur le système de l’abonnement / publication (subscribe / publish). Un ou plusieurs noeuds pourront publier de l’information sur un topic et un ou plusieurs nœuds pourront lire l’information sur ce topic. Le topic est bus d’information asynchrone (communication many-to-many asynchrone). Les nœuds envoient ou reçoivent des messages sur des topics.
  • Le service est un système de communication synchrone entre deux nœuds (communication one-to-one).
  • Les « bags » sont des formats pour stocker et rejouer les messages échangés.

Intérêt et avantages

  • Éviter de réinventer la roue: avant les OS robotiques chaque concepteur de robot devait passer du temps à concevoir matériellement son robot.
  • Proposer des fonctionnalités standardisées pour l'abstraction du matériel: on fait abstraction du matériel
  • Rassembler des savoir-faire de différentes disciplines pour gérer le matériel, gérer la mémoire et les processus et

gérer la concurrence et fusion des données (mécanique, électronique, programmation embarquée, ...)

Urbi

Urbi-Logo.png


Gostaï

Urbi est une plateforme logicielle de developpement pour la robotique développé par Gostaï [1] en 2006. L'entreprise a été fondé en 2006 par Jean-Christophe Baillie, ancien enseignant chercheur à l'ENSTA ParisPolytech où il a créé le laboratoire de Robotique Cognitive. Le modèle économique de Gostaï repose sur un ensemble de solutions et services d’aide à la création d’applications qui gravitent autour de sa plateforme logicielle opensource (Gostai Lab, Gostai Studio, GostaiNet). Gostaï a été rachetée [2] par le français Aldebaran Robotics [3] l’été 2012, et Urbi est passé sous licence BSD depuis octobre 2012 afin de favoriser l'adoption d'Urbi.

Plateforme logicielle

Urbi permet de s'affranchir d'un grand nombre d'opérations récurrentes et complexes dans le développement pour la robotique. Il est écrit en C++ et est donc compatible avec un grand nombre de plateforme qui compile du C++. Il se base sur une architecture en composants distributés. Ces composants, appelés UObjects, peuvent s’executer en local (sur le robot) ou à distance (sur un serveur de contrôle) pour les robots qui ne disposent pas d’assez de puissance et/ou mémoire. C’est le cas du Minidstorm NXT, qui se contrôle avec Urbi à distance.

Architecture client/serveur de Urbi

Urbiscript

L’interêt du C++ vise clairement la performance de l’execution sur des machines qui ne peuvent pas se permettre de gaspiller la moindre ressource. Cependant, pour la partie algorithme, interconnexion et orthestration des composants, Gostaï à mis au point un langage de script plus flexible et plus facile à maintenir : UrbiScript

Urbiscript permet entre autre : 

* Execution de script dynamique
* Programmation événementielle et parallélisme
* Orienté objet pour instancier et manipuler les UObjects
* Coordonne l'ensemble des composants
* Intuitive et asaptés aux débutants comme au developpeurs confirmés

Démonstration Urbi et NXT Mindstorm

Pour la démonstration on utilise le Lego NXT de Mindstorm.


Avancer et reculer

 Global.wheels.speed = 50;
 sleep (3s);
 Global.wheels.speed = −50;
 sleep (2s);
 Global.wheels.speed = 0;

Tourner

L'opérateur '&' permet d'éxecuter deux instructions en même temps. Dans l'exemple ci-dessous, la roue de gauche recule tandis que celle de droite avance, ce qui permet de tourner ! 

 Global.wheelL.speed = - 50 time:1s &
 Global.wheelR.speed = 50 time:1s;
 
 Global.wheelL.speed = 0 time:2s &
 Global.wheelR.speed = 0 time:2s;

Explorer

On va utiliser le concept de tag pour encapsuler un comportement particulier, puis controller ce tag directement pour arrêter l'action, la reprendre, ou la mettre en pause. 

 var Global.explorer = Tag.new;
 explorer:
 {
   every(500ms)
     wheels.speed = 25;
 },

Arrêter le robot : 

 explorer.freeze()
 wheels.speed = 0;


Reprendre l'exploration : 

 explorer.unfreeze()

Détecter les obstacles

La detection des obstacles se fait via le composant sonar (capteur ultrason) qui renseigne sur la distance qui sépare l'obstacle et le robot. Dès que cette distance passe sous une valeur seuil, on freeze le tag de l'exploration, on fait marche arriere, on tourne legerement, puis on reprend l'exploration. 


 var Global.DistanceDanger = 25;
 var Global.detecter = Tag.new;
 detecter:
 {
  at (sonar.val < Global.DistanceDanger)
  {
   explorer.freeze;
   // Marche arrièr
   wheels.speed = - 50 time:1500ms;
   // Tourner
   {Global.wheelL.speed = - 50 & Global.wheelR.speed = 50} & sleep(600ms);
   stop();
   explorer.unfreeze;
  },
 },

Contrôler

Pour contrôler le robot, on utilise le bouton de contact (bumper). A chaque fois que l'on presse sur le bouton, on permute l'etat du robot : Soit on passe en mode exploration, soit on l'arrête. 

 var Global.currentState = 0;
 
 at (bumper.val == 1)
 {
  if(Global.currentState == 0)
  {
   echo("On");
   Global.currentState = 1;
   explorer.unfreeze;
   detecter.unfreeze;
  }
  else
  {
   echo("Off");
   explorer.freeze;
   detecter.freeze;
   wheels.speed = 0;
   Global.currentState = 0;
  }|
 },

Liens

Retrieved from "https://air.imag.fr/index.php?title=EA2012_Langages_et_Canevas_pour_la_robotique_de_service&oldid=7403"