En la asignatura de robótica del posgrado de inteligencia artificial de la Uned me he puesto a trastear con Player/Stage, uno de los entornos de robótica propuestos para hacer las prácticas. De entre los entornos que nos han sugerido, este era el que me parecía más interesante: open source, basado en linux, con entorno de simulación y ejecución y muy usado en diferentes robots y concursos.
En un primer momento, player/stage resulta un poco frustrante: la interfaz de usuario no es muy usable y la documentación no es demasiado completa. La curva de aprendizaje es un poco alta, pero con ponerse manos a la obra y hacer muchas pruebas se consegue que funcione.
El sistema se compone de 3 partes:
- player: es el controlador del robot, se trata de un servidor tcp que ejecuta sobre el robot y sirve interfaces para controlarlo. La tarea del desarrollador es hacer un cliente que interactúe con player.
- stage: se trata de un simulador de robots en 2D. No es demasiado detallado, pero al ser simple puede incluir un número alto de robots simultáneamente.
- gazebo: es un simulador en 3D más realista, lo que hace que sea más lento y no apto para un número alto de robots.
Sólamente he tratado con el entorno player/stage para simulaciones en 2D, así que sólo comento estos módulos, nada sobre gazebo por ahora.
En cuanto a player, es el módulo que define la arquitectura del sistema. Cómo arquitectura de desarrollo es muy interesante: por un lado hay un entorno servidor que se ejecuta sobre el robot (real o simulado) que recibe peticiones tcp. Por otro hay un cliente que accede a ese robot, para lo que nos dan unas librerías cliente que nos evitan trabajar a bajo nivel. Para controlar un robot a través del servidor player existen una serie de interfaces (por ejemplo position2d para mover un robot en 2 dimensiones) que son implementadas por unos drivers (por ejemplo, un driver para el robot pioneer que implemente la interfaz position2d).
El desarrollador sólo necesita escribir un programa cliente que haga uso de los interfaces, normalmente a través de librerías cliente implementadas en diversos lenguajes de programación (C, C++, python, java). Las librerías se encargan del trabajo sucio de contactar con el servidor y enviar mensajes, y sólo necesitamos usar los interfaces para controlar nuestro robot. Con esta arquitectura, un mismo cliente que use unos interfaces, puede controlar diferentes robots que tengan los drivers apropiados para implementar los interfaces (incluso aunque el hardware sea muy diferente).
El servidor se configura de forma bastante sencilla con unos ficheros que definen dispositivos (devices): son asociaciones entre interfaces y drivers. Por ejemplo, el interfaz laser define el api para interactuar con un medidor de distancia láser (laser ranger). Un programa cliente sólo usa ese interfaz. Sin embargo tenemos un robot equipado con un sensor SICK LMS 200 que implementa el interfaz laser a través del driver sicklms200. En nuestro fichero de configuración, debemos definir un dispositivo que asocie el interfaz laser y el driver sicklms200:
driver
(
name "sicklms200" # The driver's name
provides ["laser:0"] # The device address
)
Si tenemos un programa cliente, este accedería al dispositivo «laser:0» que implementa el interfaz «laser», usando el driver «sicklms200».
Siguiendo esta sencilla arquitectura de drivers/interfaces/dispositivos podemos controlar nuestro robot. En mi caso, he hecho pruebas con python que, aunque no está totalmente documentado, se puede usar intuitivamente con la documentación de la librería cliente de C. Player se trata de una especie de sistema operativo para la robótica, definiendo los interfaces básicos para controlar un robot, pero que se ejecuta sobre tcp, lo que lo hace bastante flexible.
Ahora vamos con stage. Se implementa cómo un driver para player, así que necesitamos configurar un servidor player con un driver stage que se encarga de simular el robot ó robots. Esto difiere de la arquitectura player para un robot físico: para cada robot, deberíamos tener un servidor player diferente. Sin embargo en un entorno simulado con stage, tenemos varios robots simulados en un sólo servidor player. Además el servidor ejecuta una interfaz gráfica para mostrar los resultados de la simulación. El modelo del mundo se define en un fichero de configuración del mundo, donde definimos los objetos y robots que hay en el mundo y el plano del mundo se define en un fichero de imagen (jpg por ejemplo). Al ejecutar la simulación, vemos el plano del mundo con los objetos definidos incluyendo los robots. Si ejecutamos nuestro cliente, se actualiza la posición del robot el plano del mundo. El mismo cliente nos sirve para interactuar con un entorno simulado o real, sin ningún cambio: siempre interactúa con un servidor player.
El problema de esta arquitectura de simulación es que algunos drivers no están implementados en stage, como por ejemplo el driver amcl para localización (que devuelve una estimación de la posición en un mapa). Para usarlo es necesario definir un segundo servidor que utilice los interfaces del robot simulado. Hay ejemplos y es sencillo de realizar (aunque el algoritmo de localización no me terminó de funcionar) pero es enrevesado de configurar.
El conjunto player/stage como entorno de simulación funciona bastante bien, es bastante rápido y creo que lo suficientemente detallado. Podemos acceder a casi todos los interfaces de los robots simulados y he trasteado con sensores láser y sónar para generar mapas a partir de ellos. Me ha faltado probarlo con un robot real, para comparar la calidad de la simulación, pero no tengo acceso a ninguno de los robots reales.
En definitiva, se trata de un entorno bastante completo, con mucho código ya desarrollado y además open source. La parte negativa es que player ejecuta sobre linux, así que necesitaremos un hardware que ejecute el kernel y algunas dependencias, lo que nos limita a efectos prácticos a arquitecturas pc (esto significa robots caros). También hay que tener en cuenta que al ejecutar sobre tcp, la latencia puede darnos problemas.
Por el tipo de módulos existentes (mapas, localización, etc) parece más indicado para sistemas deliberativos o híbridos, pero el el sistema es completamente agnóstico en este aspecto, sólo define interfaces que podemos usar cómo queramos. En este sentido sería interesante desarrollar las librerías cliente, que actualmente se limitan a ofrecer los interfaces sin profundizar en las estructuras de control reactivo o deliberativo.
Por cierto, por falta de tiempo no podré terminar la asignatura a tiempo y probablemente repita el año que viene 🙁 lo bueno es que podré profundizar un poco más en ella.
