EA2012 Langages et Canevas pour la robotique de service

From air
Revision as of 17:09, 24 December 2012 by ElizabethPaz (talk | contribs) (→‎ROS)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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"