lozano2001-CAEPIA

Entorno Java para simulación y control de robots móviles1

Miguel Ángel Lozano Ortega, Ignacio Iborra Baeza, Domingo Gallardo López Grupo de Visión, Gráficos e Inteligencia Artificial

Departamento de Ciencia de la Computación e Inteligencia Artificial Universidad de Alicante

Carretera San Vicente, s/n 03690 – San Vicente del Raspeig, Alicante

e-mail: [email protected]

Resumen: En este trabajo se describe un entorno Java de simulación y programación de robots móviles basado en la arquitectura Saphira. El entorno permite la comunica-ción cliente-servidor de una aplicación cliente realizada en Java tanto con un servidor Saphira (bien sea un simulador, o un robot real conectado por un puerto serie), como con un simulador 3D propio realizado en Java. También se describe la forma de pro-gramar los robots mediante este entorno, así como un conjunto de librerías de apoyo que se proporcionan junto con el entorno, y un ejemplo se programa realizado para ejecutar sobre un robot.

Palabras clave: Robots autónomos, Programación de robots, Simulador de robots

1 Introducción Para la investigación y el desarrollo de software para robots autónomos es muy impor-tante contar con un entorno de simulación lo más real posible, así como con un software de alto nivel que permita ocultar las problemáticas de bajo nivel de los dispositivos ro-bóticos. Sin embargo, muchas veces es necesario también poder modificar característi-cas de bajo nivel para, por ejemplo, añadir nuevos dispositivos o modificarlos. Es por

1 En la dirección http://www.dccia.ua.es/jmr se encuentra disponible el entorno descrito en este

trabajo, junto con documentación detallada.

Miguel Ángel Lozano, Ignacio Iborra, Domingo Gallardo

CAEPIA 2001

ello fundamental contar con un sistema de control y simulación abierto, portable, esca-lable y reusable.

JMR (Java Mobile Robots) es un entorno Java diseñado para cumplir estas caracte-rísticas. Proporciona un completo software de simulación de robots basado en una ar-quitectura cliente-servidor, que permite estudiar el comportamiento de uno o varios ro-bots sobre un mundo o entorno definido. El sistema dispone de una aplicación cliente, sobre la que se cargan los robots que se desea probar, y de una aplicación servidor que se encarga de llevar un control de los robots conectados, actualizar su situación en el mundo que se haya especificado, y proporcionar al cliente los datos que se soliciten.

Se persiguen con este entorno dos objetivos fundamentales: uno es definir una inter-faz de comunicación de Java con la librería Saphira de control de robots [6]. De este modo, es posible conectar el sistema al simulador de robots de Saphira (Pioneer) y tam-bién a los robots reales que se gestionen con dicha librería. Conviene resaltar aquí la modificabilidad y escalabilidad que permite Java [4], y que hace posible la adaptación del programa a muchas otras librerías de control de robots. También sería muy sencillo definir distintos interfaces Web para controlar el robot, facilitando la implementación de este tipo de sistemas [8,9].

El otro objetivo que se persigue es proporcionar un sistema propio de simulación, escalable y fácilmente portable, que permita sencillas modificaciones o actualizaciones del mismo. La estructura de Java permite definir un esqueleto básico sobre el que ir modificando o ampliando características de forma sencilla, añadiendo nuevas clases que extiendan o sobreescriban a las anteriores. De esta forma, además de la comunicación con Saphira, se dispone de un sistema auto-integrado, que permite la prueba de robots y procesos sobre el mismo sin necesidad de ningún programa adicional, mediante un si-mulador 3D propio.

Para todo lo anterior, se ha desarrollado un programa cliente-servidor que permite la gestión de robots, así como algunas librerías auxiliares, algunas de las cuales son utili-zadas por dichos programas, y otras facilitan la elaboración de procesos en los robots por parte del usuario.

2 Descripción del entorno Como se ha comentado anteriormente, el entorno está basado en una arquitectura clien-te-servidor, cuyo funcionamiento, a grandes rasgos, se pasa a explicar a continuación.

2.1 El cliente

En la parte cliente de la aplicación se tiene un programa para manejar los distintos robots que queramos conectar. El programa está preparado para soportar varios robots

Entorno Java para simulación y control de robots móviles

CAEPIA 2001

simultáneamente (aunque si se está comunicando con Saphira, sólo se permitirá uno, por las limitaciones de Saphira), y se conseguiría con ello el mismo efecto que lanzando varias aplicaciones cliente, una por cada robot.

El cliente dispone de controles para elegir a qué servidor conectarse (actualmente, al simulador Java, al simulador Saphira, o a un robot real a través de Saphira por un puerto serie dado), indicando la dirección donde se encuentra el servidor. Esto permite comu-nicar con un servidor situado en una máquina remota, conociendo su dirección IP.

Además, se permite añadir y quitar robots del servidor, y llevar un control de los da-tos de cada robot (lecturas de sónares, estado actual, parámetros de configuración, ima-gen de la cámara, etc). En la figura 1 podemos ver el aspecto de la aplicación.

Figura 1. Aspecto de la aplicación cliente

2.2 El servidor

En la parte del servidor, se distingue entre el servidor Java y el servidor Saphira. El servidor Java implementa un simulador que permite monitorizar la situación del

mundo, mediante distintas cámaras virtuales colocadas en él o la situación particular de cada robot mediante su propia cámara virtual (ver figura 2).


CAEPIA 2001

Figura 2. Cámaras virtuales del simulador, situadas en el mundo (derecha) y en el robot (izquierda).

Además, cuenta con métodos para obtener los datos de cada robot en cada instante:

detección de colisiones con obstáculos mediante cálculo de intersecciones, toma de lec-turas de los sónares, captura de imágenes mediante un dispositivo de tipo cámara, y to-ma de otros datos de interés, como puedan ser estimaciones de posición mediante otro tipo de dispositivos, filtrado o procesado de imágenes, etc.

Dentro del servidor Saphira se englobarían tanto la conexión con el simulador Pio-neer como la conexión con un robot real a través de un puerto serie utilizando Saphira. Este tipo de servidor no dispone de ninguna aplicación visual de monitorización, sino simplemente de un programa que se deja ejecutando y permite la comunicación con Sa-phira. Para poder comunicar con las funciones de Saphira, se ha empleado JNI (Java Native Interface), una herramienta de Java que permite ejecutar código escrito en otros lenguajes de programación.

Se ha minimizado en la medida de lo posible la parte de tratamiento del robot que hace Saphira, dejando únicamente el reflector de estado, del que tomar los datos del robot, y utilizando algunas funciones para tomar datos y establecer velocidades. Lo que se pretende es dejar que se gestionen todas las estructuras desde Java, y utilizar la API de Saphira para obtener los datos y enviar los comandos básicos de movimiento (velo-cidad lineal y rotacional) al robot.

Para la comunicación de ambas aplicaciones (cliente y servidor), se ha empleado la tecnología RMI (Remote Method Invocation), una tecnología Java que permite ejecutar remotamente comandos de otra máquina, y permitir así la comunicación en sistemas distribuidos.

Por una parte, se tendrá el servidor que se haya elegido (Java o Saphira), ejecutando en una máquina. Dicho servidor estará escuchando por un puerto determinado, a la es-pera de solicitudes de conexión de distintos clientes.


CAEPIA 2001

Por otra parte, se tendrá cada uno de los clientes que se quieran lanzar, que podrán estar en la misma máquina que el servidor o en máquinas distintas. En el cliente, se in-dicará la dirección en la que se encuentra el servidor, y todos los robots que se generen se conectarán con dicha dirección.

Se establecerá así una conexión por cada robot que se añada en la aplicación cliente, que será gestionada de forma independiente. Una vez establecida la conexión, el cliente podrá solicitar datos del robot al servidor ejecutando comandos remotos en el mismo (toma de lecturas de sónares, toma del estado actual, establecimiento de la velocidad del robot, etc).

3 Programación del robot Existen múltiples propuestas de arquitecturas de control y programación de robots mó-viles [1,2,7,10]. En el diseño de JMR hemos seguido la propuesta de Saphira, enrique-ciéndola con las posibilidades de manejo de concurrencia que proporciona Java.

En la librería robots se proporcionan distintos métodos de control del robot. Los clientes podrán controlar el robot mediante el control directo, utilizando comandos de bajo nivel, mediante conductas, mediante actividades, o mediante combinación de cual-quiera de los métodos anteriores.

3.1 Procesos

Los procesos son fragmentos de código que pueden ser ejecutados en el entorno con el fin de controlar el robot. Como características generales, es posible especificar su prio-ridad, su timeout, pudiendo ser iniciados concurrentemente con quien les llama o blo-queando al llamador. Pueden encontrarse en uno de los siguientes estados: inicial, ejecutando, suspendido, detenido o finalizado. Se definen dos subclases de procesos: actividades y conductas.

3.2 Conductas

Todas las conductas definidas se ejecutan concurrentemente de forma síncrona, acce-diendo a las variables que definen el estado del robot y modificando el comportamiento del mismo según el estado leído.

Cuando tengamos varias conductas activas, cada una de ellas podrá estar fijando un movimiento distinto para el robot. En este caso, el movimiento que se establecerá en el robot se calculará combinando los resultados de todas las conductas. Para obtener este movimiento, se facilita la creación de un sistema difuso, aunque se da libertad para uti-lizar cualquier otro método.


CAEPIA 2001

3.3 Actividades

Las actividades son procesos concurrentes y asíncronos. A diferencia de las conductas, no se activan todas de forma síncrona, sino que, de forma procedural, se pueden enviar comandos de movimiento al robot, leer datos de su estado, o invocar otras actividades o conductas.

3.4 Coordinación de conductas y actividades

Se dispone de un manejador de robots, que se encarga de invocar y coordinar activida-des y conductas. La forma en la que se combinan los resultados de las distintas conduc-tas puede ser modificada por el cliente, definiendo subclases de la clase principal que especializan su comportamiento, creando así distintos manejadores de robots.

Este manejador de robots mantiene el estado del robot, de manera que cualquier pro-ceso podrá obtenerlo de él sin tener que realizar una conexión con el robot.

3.5 Librería de robots

Esta librería incluye las interfaces que tendrán los robots, y los dispositivos asociados a ellos, clases que encapsulan el estado y datos del robot, y clases para la creación de dis-tintos procesos y manejador de robots. Además incluye clases de apoyo para visión.

3.6 Visión

Se tiene un módulo dedicado a tratar el problema del procesado de imágenes en el ro-bot. Se definen en él estructuras de datos que permitan al servidor enviar al cliente in-formación sobre la imagen que está viendo en cada momento el robot, y se han definido las estructuras de determinados métodos que se emplearán para procesar y obtener imá-genes.

Además, se ha definido un puente que comunica las imágenes que puedan captarse y procesarse con la herramienta Javavis desarrollada también en el Departamento de Ciencia de la Computación e Inteligencia Artificial de la Universidad de Alicante [3], de modo que se pueden emplear los diversos filtros y funciones que se han desarrollado para dicha librería, y aplicarlos para procesar imágenes en el servidor y enviarlas al cliente.

3.7 Dispositivos

Puede ser útil (e incluso necesario) tener la posibilidad de definir dispositivos sobre el robot, elementos que actúen en el servidor, procesando determinados datos, y propor-cionando mecanismos para que el cliente pueda adquirir dichos datos procesados. Un


CAEPIA 2001

ejemplo puede ser la cámara que pueda tener el robot. Conviene disponer de un meca-nismo que permita definir la cámara, y poder visualizar así en el cliente las imágenes que capture el robot.

Pero no sólo se trata de dispositivos físicos, como puedan ser una cámara, una pinza, o cualquier otro elemento, sino también dispositivos lógicos, como fragmentos de códi-go que preprocesen información en el servidor para ponerla a disposición del cliente cuando lo requiera. Por ejemplo, aplicar un algoritmo para determinar en qué posición puede estar el robot, o un procesado de imágenes que también permita especular sobre dicha posición mediante razonamiento probabilístico.

4 Otras librerías desarrolladas Se han implementado una serie de librerías que, bien serán utilizadas por las aplicacio-nes para algunas tareas auxiliares, bien permitirán al usuario definir procesos y progra-mas Java de forma sencilla. A continuación se comentan brevemente.

4.1 Librería para desarrollo de entornos gráficos: robotGUI

La librería robotGUI se desarrolló para facilitar la elaboración de aplicaciones visuales como el propio cliente. Dispone de una serie de controles específicos que puedan resul-tar interesantes para el control de robots (formados a base de controles Java Swing agrupados), tales como paneles de imágenes, listas de parámetros, etc.

Se ha empleado esta misma librería para construir la propia aplicación cliente, de forma que también puede servir de ejemplo de uso para construir otras aplicaciones si-milares.

4.2 Librería geométrica: javaGL

La librería javaGL contiene una serie de elementos geométricos que facilitan el trata-miento de objetos del mundo en que se mueve el robot, así como del propio robot. Dis-pone de objetos tales como líneas, segmentos, círculos, puntos, posiciones, que permi-ten definir, entre otras cosas, los límites de los muros del mundo, las dimensiones del robot, la posición del mismo, etc.

Se emplea sobre todo en la parte del simulador Java para obtener aproximaciones 2D del mundo 3D que se tiene representado, mantener listas de segmentos para obtener in-tersecciones (y ver con ellas si el robot ha colisionado, o determinar las lecturas de los sónares, etc), definir posiciones, y otras funcionalidades.


CAEPIA 2001

4.3 Librería de lógica difusa: fuzzy

La librería fuzzy contiene un conjunto de clases que permiten emplear lógica difusa en el comportamiento del robot, así como en otras tareas que se quieran realizar. Dispone de elementos para poder definir variables difusas, conjuntos difusos, elaborar reglas difusas que obtengan una serie de consecuentes a partir de unas entradas determinadas para sus antecedentes, etc.

4.4 Librería probabilística: prob

La librería prob se ha definido para mantener, además de una librería para control me-diante lógica difusa (la librería fuzzy vista en el punto anterior), una librería que permite control mediante razonamiento probabilístico, basada en la propuesta de Thrun [11]. Además, proporciona ayuda a la hora de realizar determinadas tareas, como generación de datos aleatorios siguiendo una determinada distribución de probabilidades, etc.

Uno de los aspectos más interesantes de la librería es la implementación de una ver-sión genérica del algoritmo CONDENSATION (CONditional DENSity propagATION) [5], un algoritmo que permite realizar un seguimiento en el tiempo de una función de densidad genérica, posiblemente multimodal, mediante la disposición de un conjunto de muestras en el espacio objeto de estudio, y la evaluación de la probabilidad de cada muestra. Con este algoritmo genérico, se podrán estimar distintas variables que descri-ben el estado del robot, como por ejemplo localizar un robot en un pasillo, evaluar la posición del robot en función de la imagen que capta, etc.

5 Programa de ejemplo El siguiente código fuente presenta un ejemplo de una actividad, FollowRoute, en la que se planifica un recorrido del robot. En ella se define un constructor, en el que se inicializa el vector de puntos de control que determina el recorrido y se sobrescribe el método execute() con el comportamiento de la actividad. En este comportamiento

se activa la conducta AvoidCollision y se va llamando a la conducta GoToPos conforme vamos recorriendo el vector de puntos de control.

Tabla I. Ejemplo de un programa de control.

package user.processes;

public class FollowRoute extends Activity {

Vector points;


CAEPIA 2001

public FollowRoute(String pFile)

{ super("FollowRoute", -1, false, false);

setBlock(false);

points = new Vector(); points.addElement(new Point2D(1000.0, 1000.0));

points.addElement(new Point2D(2000.0, 1000.0));

points.addElement(new Point2D(3000.0, 4000.0)); }

public void execute() throws InterruptedException

{

Point2D p; AvoidCollision ac = new AvoidCollision(200,800,200,800);

GoToPos go;

execute(ac);

for(int i=0;i<points.size();i++)

{ p = (Point2D)points.elementAt(i);

go = new GoToPos((int)p.getX(), (int)p.getY(), 100); execute(go);

}

ac.setState(RobotProcess.iSTOPPED); }

}

6 Conclusiones y trabajos futuros Se ha presentando un entorno de simulación y control de robots móviles basado en la arquitectura Saphira y desarrollado en Java. El entorno proporciona un sistema abierto con el que poder definir aplicaciones cliente-servidor de control de robots. Tanto el ser-vidor como el simulador pueden ser ampliados y modificados fácilmente atendiendo a las necesidades del sistema robótico a implementar. Por ejemplo, si se incorpora un nuevo dispositivo al robot, es muy sencillo añadir en el servidor el controlador Java pa-ra el nuevo dispositivo, así como definir la interfaz de acceso desde el cliente.

Se ha presentado también la arquitectura de clases que permite definir clientes que manejan el robot utilizando procesos, conductas y actividades, así como un conjunto de librerías de apoyo que se proporcionan junto con el entorno.

Como trabajo futuro estamos preparando la coordinación de JMR como un proyecto de código abierto en el que, al estilo Linux, la comunidad robótica y de visión artificial pueda incorporar al entorno nuevas funcionalidades.


CAEPIA 2001

Bibliografía [1] R. C. Arkin. Integrating behavioral, perceptual and world knowledge in reactive

navigation. Robotics and Autonomous Systems, Vol. 6. 1990.

[2] M. Beetz. Structured reactive controllers-a computational model of everyday activity. En Proc. of the Third International Conf. on Autonomous Agents, 1999.

[3] M. Cazorla. Javavis – Librería de procesamiento de imágenes en Java. http://www.dccia.ua.es/~miguel/JavaVis/start.htm

[4] Bruce Eckel. Thinking In Java. Prentice Hall, 1998.

[5] M. Isard y A. Blake. CONDENSATION -- conditional density propagation for visual tracking. International Journal on Computer Vision, Vol. 29, No. 1, pp. 5-28. 1998

[6] K. Konolige y K. Myers K. The Saphira Architecture for Autonomous Mobile Robots. En D. Kortenkamp, P. Bonasso y R. Murphi (Eds.), Artificial Intelli-gence and Mobile Robots, pp. 211-242. AAAI Press/MIT Press. 1998.

[7] D. McDermott. A reactive plan language. Research Report YALEU/DCS/RR-864, Yale University, 1991.

[8] D. Schulz, W. Burgard, A.B. Cremers, D. Fox, y S. Thrun. Web interfaces for mobile robots in public places. IEEE Magazine on Robotics and Automation, Vol. 7, No. 1, pp. 48-57, Marzo 2000.

[9] R. Siegwart and K. Goldberg (eds). Robots on the Web. IEEE Magazine on Ro-botics and Automation (special issue), Vol. 7, No. 1, March 2000.

[10] R. Simmons, J. Fernandez, R. Goodwin, S. Koenig, J. O'Sullivan. Xavier: An Autonomous Mobile Robot on the Web. IEEE Robotics and Automation Maga-zine, Vol. 7, No. 2, pp. 33-39, Junio 2000.

[11] S. Thrun. A Framework for Programming Embedded Systems: Initial Design And Results. Informe Técnico Carnegie Mellon University, Octubre 1998.

lozano2001-CAEPIA

Documents

Transcript of lozano2001-CAEPIA