Player/Stage/Gazebo

Objetivos

Estudiar el conjunto de programas Player/Stage/Gazebo para ser utilizado con RoMAA en el control y simulación

Introducción

Player, Stage y Gazebo son tres piezas de software originalmente desarrollado en el laboratorio de investigación de robótica de la University of Southern California (USC). Ahora es un proyecto activo de SourceForge.net, usado por un gran número de investigadores alrededor del mundo.

When Shakespeare wrote that "All the world's a stage, and all the men and women merely players," he couldn't have forseen that he was giving a name to a type of open source robotics software that wouldn't be invented for another 400 years or so.

Player

Player es un servidor de red para control de robots que corre abordo del robot, es una capa de abstracción de hardware (HAL) para dispositivos robóticos. Provee un medio simple de interfaz entre los actuadores y sensores del robot sobre redes IP. El programa cliente se comunica con Player sobre un socket TCP, leyendo datos de los sensores, escribiendo comandos a los actuadores, y configurando los dispositivos en operación.

Puesto que Player usa el modelo cliente/servidor basado en sockets TCP los programas de control de robots se pueden escribir en cualquier lenguaje de programación y puede ser ejecutado en cualquier computadora con conectividad a la red del robot, además Player soporta múltiples conexiones concurrentes de clientes a dispositivos, creando nuevas posibilidades de control y sensado distribuido y colaborativo. Originalmente Player fue creado para la plataforma de familia de robot ActivMedia Pioneer2 pero ha ido creciendo para soportar un gran conjunto de plataformas robóticas. Player requiere un entorno con POSIX threads (pthreads), un stack TCP, y C/C++. Los scripts de configuración necesitan un shell bash (tal como el de Linux).

Player es una interfaz de bajo nivel, provee una interfaz estandar pero no hace ninguna asunción sobre el programa de control del robot. Soporta múltiples dispositivos sobre una única conexión y puede soportar cualquier número de clientes. Los drivers de Player no siempre son una interfaz que representa controles básicos tales como moviemiento y sensores, algunos drivers proveen características "inteligentes" tales como path-planning, Vector Field Histogram (VFH+), Adaptive Monte Carlo Localization (AMCL) entre otros.

Los programas de aplicación se linkean con las librerias Player cliente que proveen una conexión al servidor Player. El servidor Player generalmente reside en el robot y se conecta a los drivers de dispositivo de Player. Los drivers de dispositivos mapean un dispositivo lógico, generando una abstracción de lo que el cliente ve.

La ventaja de esta metodología es la misma que cualquier arquitectura cliente/servidor haciendolo fácil de comprender y probar. Hay suficiente dispositivos simulados y robots para utilizar con Stage y Gazebo así el usuario puede experimentar facilmente con Player. Escribir drivers de dispositivos para un nuevo robots y sus periféricos es relativamente directo. Como con cualquier driver de dispositivos de un sistema operativo, un único driver puede manejar cualquier número de dispositivos físicos. Por ejemplo, el driver estándar para el sensor laser rangefinder SICK LMS200 disponible se corresponde a la interfaz abstracta "laser". Una conexión se podría especificar como localhost:6665:laser:0 para el puerto 6665, con la interfaz lógica laser 0.

Estructura de Player

Player trabaja creando varias capas de abstracción, ocultando el control de alto nivel del cliente (que contiene la lógica) con la implementación de bajo nivel específica del hardware. Al hacer esto se puede crear código modular, intercambiable entre hardware y proyectos. Esto se logra utilizando conceptos tales como clientes, server, proxies, y drivers. (player_struct.odg)

Arquitectura de Player (player_arch.odg)

Interfaces, Drivers y Dispositivos

En Player hay 3 conceptos claves:

• Interface: Es una especificación de como interactuar con cierta clase sensores, actuadores o algoritmos de robots. Las intefaces definen la sintaxis y semántica de los mensajes que se puede intercambiar con entidades de la misma clase.

• Driver: Es una pieza de software (generalmente escrita en C++) que se comunica con los sensores, actuadores o algoritmos del robot, traduciendo sus entradas y salidas para adaptarse a una o mas interfaces. El driver esconde la especificación de cualquier entidad haciendolo parecer el mismo para cualquier otra entidad de su misma clase.

• Dispositivo: Un driver limita con una interface. Todos los mensajes en Player ocurren entre dispositivos, a través de las interfaces. Los drivers, aunque realizan la mayoría del trabajo, nunca se acceden directamente.

Player incluye muchas interfaces predefinidas para los dispositivos o algoritmos. La tarea del driver plugin es de crear un enlace entre el dispositivo o el algoritmo y la(s) interface(s) predefinidas que mejor lo representa.

Player Server

A partir de la versión 2.0 Player esta dividido en dos mitades, el core y el transport layer. Player core está dividido en las librerías core libplayercore, y la librería de driver libplayerdrivers. La capa de transporte está implementada en una combinación de dos librerías: libpleyaertcp y libplayerxdr.

Player Cliente

Las librerías clientes están disponibles en varios lenguajes para facilitar el desarrollo de programas clientes TCP.

Probablemente uses una de estas librerías para desarrollar los programas de control de robot si se utiliza el servidor Player ya sea con un hardware o simulado.

Las librerías disponibles por el proyecto son:

• libplayerc Librerías clientes C para el servidor Player

• libplayerc_py Librerías clientes python para el servidor Player

• libplayerc++ Librerías clientes C++ para el servidor Player

Existen otras librerias de contribución.

Compilar

$ g++ -o example0 pkg-config --cflags playerc++ example0.cc pkg-config --libs playerc++

Stage

Stage es un simulador de múltiples robots del proyecto Player. Stage simula una población de robots, sensores y objetos en un entorno bitmap 2D. Stage provee de robots virtuales de modo que Player interactue con el entorno simulado en lugar de dispositivos físicos, dispone de varios modelos de sensores incluyendo sonares, sensores laser rangefinder, cámaras pan-tilt-zoom con detección de blobs de color y odometría. Stage es adecuado para investigaciones de sistemas autónomos multi-agente, puesto que provee de un modelo simple de bajo requerimiento computacional de múltiples dispositivos en lugar de emular cada dispositivo con gran fidelidad.

Gazebo

Gazebo es un simulador de múltiples robots en entornos exteriores. Tal como Stage, es capaz de simular una población de robots, sensores y objetos pero en un entorno tridimensional. Gazebo genera realimentación realista de sensores e interacción física entre objetos, incluyendo simulación precisa de la física de cuerpos rígidos con su dinámica.

Gazebo svn

svn info https://playerstage.svn.sourceforge.net/svnroot/playerstage/code/gazebo/trunk

Ejecutar Gazebo

Ir al directorio donde esta construida la aplicación (gazebo) y ejecutar

./gazebo world/archivo_mundo.world"

cargando el archivo del mundo a visualizar.

Gazebo con Player

• en una terminal ejecutar: =./gazebo world/pioneer2dx.world=

• en otra terminal: player player/gazebo.cfg

• en otra terminal: playerv, playerjoy, etc, para manejar el robot en el entorno simulado 3D.

Publicaciones que utilizan Player/Stage

• SLAM: Wolf, D., & Sukhatme, G. (2005, Jul). Mobile robot simultaneous localization and mapping in dynamic environments.

  • Autonomous Robots, 19(1), 53–65. Ver

• Learning: Provost, J., Kuipers, B., & Miikkulainen, R. (2004). Self-organizing perceptual and temporal abstraction for robot

  • reinforcement learning. In AAAI-04 workshop on learning and planning in markov processes. Ver

• Education: Matari ́ , M. (2004, Mar). Robotics education for all ages. In Proceedings, AAAI spring symposium on accessible, hands-on AI and robotics education. Ver

• HRI task allocation: Tews, A., Matari ́ , M., & Sukhatme, G. (2003, Sep). A scalable approach to human-robot interaction. In IEEE international conference on robotics and automation (p. 1665-1670). Taipei, Taiwan Ver

• Multi-robot sensing: Jung, B., & Sukhatme, G. (2002, Nov). Tracking targets using multiple robots: The effect of environment occlusion. Autonomous Robots, 13(3), 191–205. Ver

• Multi-robot exploration: Howard, A., Matari ́ , M., & Sukhatme, G. (2002). An incremental self-deployment algorithm for mobile sensor networks. Autonomous Robots Special Issue on Intelligent Embedded Systems, 13(2), 113–126. Ver

• Multi-robot mapping: Howard, A., Parker, L., & Sukhatme, G. (2004, Jun). The SDR experience: Experiments with a large-scale heterogenous mobile robot team. In 9th international symposium on experimental robotics 2004. Singapore. Ver

• Multi-robot localization: Howard, A., Matari ́ , M., & Sukhatme, G. (2003, Sep). Putting the ‘I’ in ‘Team’: An ego-centric approach to cooperative localization. In IEEE international conference on robotics and automation (pp. 868–892). Taipei, Taiwan. Ver

• Multi-robot coordonation: Jones, C., & Matari ́ , M. (2004, Sep). Automatic synthesis of communication-based coordinated multi-robot systems. In IEEE/RSJ international conference on intelligent robots and systems (pp. 381–387). Sendai, Japan. Ver

• Multi-robot formation: Fredslund, J., & Matari ́ , M. (2002, Oct). A general, local algorithm for robot formations. IEEE Transactions on Robotics and Automation, Special Issue on Multi-Robot Systems, 18(5), 837–846.

• Multi-robot task allocation: Gerkey, B., & Matari ́ , M. (2002, Oct). Sold!: Auction methods for multi-robot coordination. IEEE Transactions on Robotics and Automation, Special Issue on Multi-Robot Systems, 18(5), 758–768. (Also Technical Report IRIS-01-399). Ver

Links

General

• The Player project

• Player History

• Player/Stage Tutorial

• Player/Stage Slides

• Player/Stage/Gazebo forum

• A review of robotics software platforms

• Tapia 2009 Robotics Competition

Instalación

• Instalación de player/stage/gazebo en Debian

• Player 2.1.1 / Gazebo 0.8 SVN rev. 6886

• Player 2.1.1 / Stage 3.0.1

• Player/Stage/Gazebo software installation

• Troubleshoot

Referencias

• [1] - "Really reused robot code from the player/stage project". Richard T. Vaughan and Brian Gerkey. In Davide Brugali, editor, Software Engineering for Experimental Robotics. Springer, 2007. Descargar

• [2] - "Player 2.0: Toward a Practical Robot Programming Framework" Toby H.J. Collett, Bruce A. MacDonald, and Brian P. Gerkey. In Proc. of the Australasian Conf. on Robotics and Automation (ACRA 2005), Sydney, Australia, December 5-7, 2005. Descargar

• [3] - "On Device Abstractions For Portable, Resuable Robot Code". Richard T. Vaughan, Brian P. Gerkey, and Andrew Howard. In Proc. of the IEEE/RSJ Intl. Conf. on Intelligent Robots and Systems (IROS 2003), pages 2121-2427, Las Vegas, Nevada, October 27 - 31, 2003. (Also Technical Report CRES-03-009) Descargar

• [4] - "The Player/Stage Project: Tools for Multi-Robot and Distributed Sensor Systems". Brian P. Gerkey, Richard T. Vaughan, and Andrew Howard. In Proc. of the Intl. Conf. on Advanced Robotics (ICAR 2003), pages 317-323, Coimbra, Portugal, June 30 - July 3, 2003. Descargar

• [5] - "Most Valuable Player: A Robot Device Server for Distributed Control". Brian P. Gerkey, Richard T. Vaughan, Kasper Støy, Andrew Howard, Gaurav S Sukhatme, and Maja J Mataric´. In Proc. of the IEEE/RSJ Intl. Conf. on Intelligent Robots and Systems (IROS 2001), pages 1226-1231, Wailea, Hawaii, October 29 - November 3, 2001. Descargar

• [6] - "Player Robot Server". Brian P. Gerkey, Kasper Støy and Richard T. Vaughan. Technical Report IRIS-00-392, Institute for Robotics and Intelligent Systems, School of Engineering, University of Southern California, November 2000. Descargar