Entornos de Desarrollos para Robots

Objetivos

Analizar la necesidad y disponibilidad en el mundo del software libre de entornos de desarrollo de robots.

Introducción

Históricamente los desarrollos de robots eran únicos y no se producian en serie, por lo que los programas de control se construían utilizando directamente los drivers para acceder a los dispositivos sensoriales y de actuación. El sistema operativo del robot era el mínimo necesario que consistia en una colección de drivers con rutinas para leer datos de los sensores y enviar comandos a los actuadores. En este contexto, el programa de aplicación utilizaba las funciones de librería que ofrecía el fabricante en sus drivers. Las aplicaciones se situaban encima del sistema operativo, figura 1.

Con el asentamiento de los fabricantes y el trabajo de muchos grupos de investigación han ido apareciendo plataformas de desarrollo que simplifican la programación de aplicaciones robóticas. Estas plataformas ofrecen acceso más sencillo a sensores y actuadores, suelen incluir un modelo de programación de software y permite manejar la creciente complejidad del código cuando se incrementa la funcionalidad del robot. El diseñador programa sus aplicaciones robóticas finales sobre esa plataforma de desarrollo, figura 2.

Software de robots

Requisitos específicos

Escribir programas para robots móviles es una tarea complicada, ya que los robots son sistemas complejos

• Los programas de robots móviles están directamente conectados a la realidad física a través de sensores y actuadores. Los sensores obtienen información de esta realidad y los actuadores la modifican.
• Las aplicaciones de robots móviles deben estar pendiente de varias fuentes de actividad y objetivos a la vez, y el programa debe atenderlas en forma simultanea: recoger nuevos datos de varios sensores, refrescar la interfaz gráfica, enviar periódicamente consignas a los motores, enviar o recibir datos por la red a otro proceso de apllicación, etc. Por ello estas aplicaciones suelen ser concurrentes. En este sentido, los sistemas operativos para robots incorporan mecanismos de multitarea y comunicación interprocesos.
• Otra cuestión relevante es la interfaz gráfica. Si bien no es indispensable para generar el comportamiento autónomo del robot, resulta útil como herramienta de depuración.
• El software de robots es cada vez mas distribuido. Es usual que las aplicaciones de robots tengan que establecer alguna comunicación con otros procesos ejecutándose en la misma máquina o en una diferente.
• Los programadores de robot se enfrentan a una creciente heterogeneidad, en distintos sentidos. En cuanto al hardware, existe una gran diversidad de dispositivos sensoriales y de actuación, así como de interfaces. En cuanto al software, las aplicaciones de robot no cuentan con un marco estable, no hay estándares abiertos que propicien la colaboración.

Lenguajes

Aunque han existido intentos de establecer lenguajes específicos para programar robots, como Task Description Language (TDL) o Reactive Action Packages (RAP), no han sido nunca de uso general.

La plataforma de desarrollo suele obligar a que las aplicaciones se escriban en el lenguaje en que ellas mismas está programada, para que puedan acceder a la funcionalidad ofrecida. No obstante, cada vez hay más plataformas que no imponen un lenguaje determinado. Por ejemplo, en Player/Stage/Gazebo (P/S/G) la funcionalidad se ofrece a través de mensajes de red a un servidor, la aplicación puede estar escrita en cualquier lenguaje siempre que respete el protocolo. Existen librerías hechas en C, C++, Tcl, Python, Java y Common Lisp que encapsulan ese diálogo en el cliente.

Actualmente el lenguaje más extendido para robots es C. Supone un buen compromiso entre potencia expresiva y rapidez. Recientemente se puede observar un crecimiento en los desarrollos y aplicaciones en C++. Por ejemplo, el entorno ARIA (ActivMedia, 2002) para programar robots de ActivMedia, el entorno OPEN-R (Sony, 2003) de programación del perrito Aibo de Sony, la plataforma Miro, Mobility, etc.

Simuladores

Una herramienta particular, muy útil en la programación de robots son los simuladores, los cuales ofrecen un entorno virtual en el que emular las observaciones de los sensores y los efectos de las órdenes a los actuadores. Sirven para la evaluación, depuración y ajuste del programa de control antes de ser llevado al robot real.

Los primeros simuladores eran pocos realistas pero han ido ganando en realismo, incorporando ruido en los sensores y en las actuaciones. Hoy en día se tienen simuladores tridimensionales, como Gazebo y JMR, capaces de simular sensores tan complejos como visión.

Muchos fabricantes incluyen un simulador para sus robots (ej. EyeSim para el robot EyeBot, Webots para Kephera y Koala), aunque también existen muchos desarrollos libres (Stage, Gazebo, JMR, etc.). Los simuladores libres tratan de incluir soporte para los robots de diversos fabricantes. La configuración concreta del conjunto de robots a simular, la disposición y parámetros de sus sensores se suelen especificar en un fichero de configuración. Dos de los simuladores más relevantes de hoy en día son el SRIsim de Kurt Konolige, que se emplea en los robots de "ActivMedia y los simuladores Stage y Gazebo de software libre orientados a multirobots (Stage soporta 2D y colonias numerosas de robots, y Gazebo soporta 3D).

Plataformas de desarrollo

Las aplicaciones con robots presentan cada vez mayor complejidad y ofrecen mayor funcionalidad. En muchos campos del software se ha ido implantando middleware que simplifica el desarrollo de nuevas aplicaciones en esas áreas. Este middleware proporciona contextos nítidos, estructuras de datos predefinidas, bloques muy depurados de código de uso frecuente, protocolos estándar de comunicaciones, mecanismos de sincronización, etc. Del mismo modo, a medida que el desarrollo de software para robot móviles ha ido madurando han ido apareciendo diferentes plataformas middleware.

Hoy en día los fabricantes más avanzados incluyen plataformas de desarrollo para simplificar a los usuarios la programación de sus robots. Por ejemplo, ActivMedia ofrece la plataforma ARIA (ActivMedia, 2002) para sus robots Pioneer, PeopleBot, etc.; iRobot ofrecía Mobility (RWI, 1999) para sus B14 y B21; Evolution Robotics vende sus plataformas ERSP; y Sony ofrece OPEN-R para sus Aibo.

Además de los fabricantes, muchos grupos de investigación han creado sus propias plataformas de desarrollo. Varios ejemplos son la suite de navegación CARMEN de Carnegie Mellon University, Orocos, P/S/G, Miro, JDE, etc.

Abstracción de hardware

Normalmente las plataformas ofrecen un acceso a sensores y actuadores más abstracto y simple que el proporcionado por el sistema operativo. Por ejemplo, si se dispone de un robot Pioneer equipado con un sensor láser SKICK, la aplicación puede acceder a sus medidas a través de las funciones de la plataforma ARIA o pedirlas y recogerlas directamente a través del puerto serie.

El acceso abstracto también se ofrece para los actuadores. Por ejemplo, en vez de ofrecer comandos de velocidad para cada una de las dos ruedas motrices de un robot Pioneer, la plataforma Miro ofrece una sencilla interfaz de V-W (velocidad de tracción y de giro) para la actuación motriz, la cual se encarga de hacer las transformaciones oportunas, de enviar a cada rueda las consignas necesarias para que el robot consiga esas velocidades comandadas de tracción y de giro.

Plataformas de software libre

Player/Stage/Gazebo (P/S/G)

La plataforma P/S/G fue creada inicialmente en la Universidad de South California [1]. Está formada por los simuladores Stage y Gazebo, y por el servidor Player al que se conecta el programa de aplicación para recoger los datos sensoriales o comandar las órdenes a los actuadores. El soporte a robots variados y simuladores que incorpora la convierten en una plataforma muy completa. Además, cuenta con una creciente comunidad de desarrolladores, muy activa, que continuamente añade nuevas capacidades y amplía el hardware soportado.

En P/S/G los sensores y actuadores se contemplan como si fueran ficheros [2], dispositivos de modo carácter al estilo de Unix, que se manipulan con cinco operaciones básicas: abrir, cerrar, leer, escribir y configurar. Para usar un sensor, las aplicaciones tienen que abrir el dispositivo, configurarlo y leer de él, cerrándolo al final. De manera análoga se utilizan los actuadores. Cada tipo de dispositivo se define en P/S/G con una interfaz, de manera que los sensores sonar de algún robot en particular son instancias de la misma interfaz. El conjunto de posibles interfaces presenta una máquina virtual, con toda suerte de sensores y actuadores. El robot concreto instancia las interfaces relativas a los dispositivos realmente existentes.

P/S/G tiene un diseño cliente/servidor: las aplicaciones establecen un diálogo por TCP/IP con el servidor Player, que es el responsable de proporcionar las lecturas sensoriales y materializar los comandos de actuación. Además de permitir acceso remoto, este diseño proporciona a las aplicaciones construidos sobre P/S/G gran independencia de lenguaje y mínima imposiciones de arquitectura. La aplicación puede escribirse en cualquier lenguaje, y con cualquier estilo, simplemente respetando el protocolo de comunicaciones con el servidor.

P/S/G se orienta principalmente a ofrecer una interfaz abstracta de hardware de robots y no a la identificación de bloques comunes de funcionalidad. No obstante, se puede incorporar cierta funcionalidad adicional con nuevos mensajes del protocolo, y servicios añadidos a Player. Por ejemplo, la localización probabilística se ha añadido como una interfaz más, localization, que proporciona múltiples hipótesis de localización. Esta nueva interfaz supera a la tradicional, position, que acarrea la posición estimada desde la odometría.

ARIA

Una plataforma de software libre muy utilizada es ARIA (ActivMedia Robotic Interface for Applications). ARIA está impulsada y mantenida por la empresa ActivMedia Robotics como interfaz de acceso al hardware de sus robots, pero se distribuye con licencia GPL y por tanto su código fuente está accesible. ARIA ofrece un entorno de programación orientado a objetos, que incluye soporte para la programación multitarea y para las comunicaciones a través de la red. Las aplicaciones han de escribirse forzosamente en C++. ARIA está soportada en Linux y en Win32 OS, por lo que una misma aplicación escrita sobre su API puede funcionar en robots con uno u otro sistema operativo. Es un claro ejemplo de portabilidad.

En el bajo nivel, ARIA tiene un diseño de cliente-servidor: el robot está gobernado por un microcontrolador que hace las veces de servidor. Ese servidor establece un diálogo a través del puerto serie con la aplicación, escrita utilizando ARIA, que actúa como cliente. En ese diálogo se envían al cliente las medidas de ultrasonido, odometría, etc. y se reciben las órdenes de actuación a los motores.

Miro

Miro [4] es una plataforma basada en objetos distribuidos para la creación de aplicaciones para robots, desarrollada en la Universidad de Ulm y publicada bajo licencia GPL. En cuanto a la distribución de objetos, Miro sigue el estándar CORBA, empleando la implementación TAO de CORBA, así como la librería ACE.

CARMEN

CARMEN (Carnegie Mellon Robot Navigation Toolkit) es una colección de software de control de robots (móviles) open source escrita en lenguaje de programación C cuyo proposito es proveer una interfaz consistente y un conjunto básico de primitivas para la investigación en robótica. Orientado al control de un único robot, utiliza una arquitectura agente de tres capas, en la cual la primer capa es la interfaz hardware, que provee control a bajo nivel e integración con sensores y datos de movimiento, la segunda capa se relaciona con las tareas básicas de robot tales como la navegación, localización, tracking de objetos, y planificación de trayectoria, y la tercer capa es la aplicación definida por el usuario, que se basa en primitivas de las capas inferiores. La modularidad es un concepto primordial, soportado por el protocolo/software de comunicación Inter-Process Communication System (IPC). Además de soportar varias plataformas robots (incluyendo MobileRobots, Nomadic Technologies Scout y XR4000, Segway, iRobot ATRV, ATRVjr, y !B21R) y primitivas de navegación (map-making, Monte-Carlo particle filter localization, and Markov decision process path planning), CARMEN también provee de herramientas de configuración, un simulador, un editor y display gráfico.

IPC provee soporte de alto nivel para conectar procesos usando sockets TCP/IP y enviar datos entre procesos, incluyendo abrir y cerrar un socket, registrarlo, enviar, y recibir mensajes, los cuales pueden ser comunicaciones de tipo anónimos publish/subscribe o client/server.

Los componentes de CARMEN generalmente toman la forma de simples ejecutables, tales como pioneer (para robots MobileRobots Pioneer), láser (para range láser SICK), o localize (para localización de robot utilizando un mapa pre-hecho). Las definiciones de una plataforma particular están contenidas en especificaciones bases, que son las abstracciones a configuraciones genéricas de robot que incluyen parámetros básicos como el largo y el ancho de la carrocería, offset de sonar, velocidad máxima, etc. Los parámetros para cada componente se almacenan en repositorios de archivos de texto legibles, pero se puede utilizar un editor gráfico para modificarlos en tiempo de ejecución.

Referencias

[1]- Gerkey, Brian P., Richard T. Vaughan and Andrew Howard (2003). The Player/Stage project: tools for multi-robot and distributed sensor systems. In: Proceedings of the 11th International Conference on Advanced Robotics ICAR'2003. Coimbra (Portugal). Descargar

[2]- Vaughan, Richard T., Brian P. Gerkey and Andrew Howard (2003). On device abstractions for portable, reusable robot code. In: Proceedings of the 2003 IEEE/RSJ International Conference on Ingelligent Robots and Systems (IROS-03). Vol. 3. Las Vegas (USA). Descargar

[3]- ActivMedia. ARIA reference manual. Technical Report. ActivMedia Robotics.

[4]- Utz, Hans, Stefan Sablatnog, Stefan Enderle and Gerhand Kraetzschmar (2002). Miro - middleware for mobile robot applications. IEEE Transactions on Robotics and Automation, Special Issue on Object-Oriented Distributed Control Architectures 18(4), 493-497. Descargar