domingo, 18 de noviembre de 2012

IMPLEMENTACIÓN DE LA ARQUITECTURA PELEA POR MEDIO DE SERVICIOS WEB SEMÁNTICOS PARA LA MANIPULACIÓN REMOTA DE ROBOTS

INTRODUCCION
Este artículo presenta la implementación de la arquitectura PELEA haciendo uso de servicios web para la manipulación remota de robots para simular la construcción de diques. Dichos servicios fueron descritos semánticamente por medio de la ontología OWL-S para facilitar su invocación tanto por maquinas como humanos proporcionando así un sistema capaz de llevar a cabo tareas relacionadas con la construcción de un dique.

2. METODOLOGÍA PROPUESTA  
Para soportar este trabajo se propone una metodología compuesta por los siguientes pasos: la implementación física del robot, la implementación de los servicios web que representan cada modulo de la arquitectura PELEA y que controlan remotamente el robot, la creación del marcado semántico de los servicios y la implementación del módulo para la invocación de los servicios. (Ver Fig. 1).  A lo largo de este artículo se detallarán los pasos de la metodología seguida.
 Fig. 1. Metodología propuesta 

Como resultado de seguir esta metodología se obtuvo un sistema robótico manejado remotamente en el que el robot se comunica con el servicio web, el cual constituye un modulo de la arquitectura PELEA y a su vez, tiene una descripción semántica que hace uso de una ontología del dominio en asocio con una ontología para la descripción de servicios y, finalmente, haciendo uso de las anteriores ontologías se puede invocar cada servicio por medio de una aplicación orientada al manejo de descripciones semánticas de servicios web.


3. DESCRIPCION DEL ESCENARIO PLANTEADO PARA SIMULAR EL PROBLEMA DE CONSTRUIR UN DIQUE

Como problema para este sistema, se propuso un escenario similar al usado en competencias robóticas como la LARC [14] en la categoría de constructor de diques, a continuación se describe el escenario:

Fig. 2 Escenario utilizado para probar el sistema

Tal como se aprecia en la figura 2, el escenario usado consta de 110 celdas, una columna central que representa el rio y una segunda columna que representa el desborde de dicho rio, por lo tanto el objetivo del sistema es conseguir que el robot coloque los pilotes ubicados en el extremo como posición inicial y ponerlos en la posición final alrededor del desborde. Para este problema se considero un desborde simple localizado en el extremo derecho del escenario y se tomó como posición inicial del robot la celda 98.
 




4. DOMINIO Y PROBLEMA PDDL USADOS DESDE UNA ONTOLOGÍA
Uno de los principales módulos de la arquitectura PELEA es el modulo de planificación, el cual recibe un dominio y un problema de alto nivel y genera el plan con las acciones que el robot deberá ejecutar para llevar a cabo el objetivo propuesto.
Dado que se pretende tener un sentido semántico para todos los componentes del sistema, tanto el dominio como el problema PDDL, se encuentran alojados en una ontología accesible desde una dirección remota [15], a continuación se especifican segmentos del dominio y el problema usados para la simulación de un constructor de diques y la representación de estos al interior de la ontología.

Fig. 3 Segmentos del dominio PDDL
Como se aprecia en la figura anterior, se definieron las celdas que el robot deberá recorrer, los objetivos que éste deberá manipular y el robot como tal, adicionalmente se definen las celdas que son contiguas por el norte, sur, este y oeste, cuáles de las celdas están vacías, la localización de los objetivos al interior del escenario, la disponibilidad de un objetivo y la localización actual del robot en el escenario, se definen acciones que el robot puede ejecutar, como son viajar al norte, tomar un pilote ubicado al oeste o soltar un pilote en el norte, se debe advertir que se definieron operaciones para viajar, agarrar y soltar en los cuatro puntos cardinales.


Fig. 4 Segmentos del problema PDDL
Como se aprecia en la figura 4, se describieron las 110 celdas, luego se expresó cuales eran contiguas por el norte, el sur, el este y el oeste, se mostró cuales casillas se encuentran vacías, cuales objetivos estaban disponibles, la ubicación del robot, la ubicación de los objetivos y la meta a alcanzar, según la posición final que debían alcanzar los pilotes.
A continuación se muestra ontología que permite insertar como instancias de este el problema y el dominio PDDL anteriormente descritos.


Fig. 5 Ontología para representar el dominio y el problema PDDL
Tal como se aprecia en la figura 5, se creó una ontología de dominio [16] con nueve clases que corresponden a las diferentes entradas y salidas de los módulos de la arquitectura PELEA, a continuación se muestra la ontología que contiene las instancias especificas del DomainH y Problem, que son usados como parámetros para el modulo ejecutor del sistema.


Fig. 6 DomainH y Problem instanciados




5. PRINCIPALES MODULOS DE LA ARQUIETCTURA PELEA IMPLEMENTADOS CON SERVICIOS WEB

Un servicio web es una aplicación ejecutable en un servidor remoto y es accesible por medio de protocolos de comunicación, independientes de  la plataforma o sistema operativo de quien realiza la comunicación e independiente servidor en el que se encuentra alojado el servicio [10].
Si un servicio web es capaz de establecer una comunicación con un robot y enviarle a éste una acción para ejecutar, es posible conseguir que un robot sea controlado de manera remota. En este punto se puede expresar que los servicios web son un soporte básico de un área actual de investigación llamada robótica en la nube [11].
A continuación se exponen los principales módulos de la arquitectura pelea que se implementaron por medio de servicios web para la manipulación remota del robot:
·         Modulo Ejecutor:

Fig. 7 Modulo ejecutor como servicio web
El modulo ejecutor recibe principalmente el DomainH y el Problem, directamente como instancias de la ontología, por esta razón se le hace un tratamiento a estas entradas para obtener directamente los contenidos de estos y enviarlos posteriormente al monitor. Luego lo recibido por el monitor (PlanL), es enviado por medio de un proceso externo [17] al robot.


·         Modulo de bajo nivel:

Fig. 10 Modulo de bajo nivel como servicio web
El modulo de bajo nivel, es el encargado de convertir el plan de alto nivel enviado por el monitor a un conjunto de acciones de bajo nivel que el robot sea capaz de comprender, en este caso se determinó que el plan se debería traducir a una serie de números que varía según la localización actual del robot en cada paso ejecutado y en la que se consideró la siguiente correspondencia entre las acciones y los valores generados: Para la acción girar a la izquierda, se escribiría un 1 en la secuencia, para girar a la derecha un 2, para avanzar un 3, para retroceder un 4, para agarrar un pilote un 5 y para soltarlo un 6, quedando así:
Acción
Valor traducción
Giro Izquierda
1
Giro Derecha
2
Adelante
3
Atrás
4
Agarrar
5
Soltar
6
Tabla 1 Valores de traducción para el plan.

De este modo, el plan de alto nivel es llevado a una serie de números que son enviados posteriormente al robot y ejecutados por este según la acción asociada.



7. DESCRIPCION SEMANTICA DE LOS SERVICIOS WEB IMPLEMENTADOS

Con el fin de que las máquinas puedan entender inequívocamente lo que hace cada servicio, se optó  para cada uno de los servicios implementados en la sección anterior realizar su respectiva descripción semántica con el uso de ontologías [9]. La descripción semántica de todos los servicios ha sido creada de manera similar, a continuación se muestra la descripción semántica del modulo ejecutor, lo cual permite su invocación posteriormente:


Fig. 12 Descripción semántica del servicio web ejecutor
Como se puede apreciar en la figura, el servicio web hace un importe de la ontología que contiene la descripción de las entradas y salidas de los módulos de la arquitectura PELEA, al igual que de la ontología que contiene las instancias del DomainH y el Problem, esto es con el fin de facilitar la obtención de estos en el momento de la invocación del servicio web, enviando como parámetros dichas instancias. También se puede apreciar que tanto las entradas y salidas del servicio web, están descritas como tipos de datos complejos pertenecientes a la ontología Domain.owl.


8. INVOCACION DE LOS SERVICIOS A PARTIR DE SU DESCRIPCION SEMANTICA

Al tener una descripción semántica de los servicios,  su invocación se puede realizar por medio de la API de OWL-S [8]. Esta API, permite crear una base de conocimiento soportada por las instancias de las ontologías de los servicios web y del dominio. Esta API, basada en la descripción semántica de cada servicio web, permite obtener una instancia del servicio y del proceso asociado con éste, se definen las entradas (complejas o primitivas), las salidas requeridas por estos servicios y también permite la ejecución del proceso asociado con cada servicio. En la Fig. 13 se muestran apartes del código en Java que, cuando se ejecuta mediante la API OWL-S, hace la invocación del servicio ejecutor del sistema.



Fig. 13 Invocación del modulo ejecutor del sistema
 

 

9. CONCLUSIONES Y TRABAJO FUTURO

El uso de la arquitectura PELEA facilita la modularización del sistema implementado facilitando la sostenibilidad y mantenimiento del mismo, dicha modularidad permite su implementación de diferentes formas como servicios web en este caso.

Con la implementación del prototipo del sistema de manipulación remota de robots por medio de servicios web semánticos, los usuarios, tanto humanos como las máquinas, pueden tener acceso al robot desde cualquier parte siempre y cuando se tenga un punto de acceso a la web. Además, como se contempla una descripción semántica de los servicios que manipulan el robot, es posible realizar tareas de manera automática ya que las máquinas entienden la funcionalidad de los servicios que abren opciones interesantes como el descubrimiento automático de tareas que hace el robot, al igual que componer automáticamente nuevas tareas que combinen los servicios asociados con las tareas que hace el robot.


REFERENCIAS

[1]    Lafuente, A. Larrea, M, “Sistemas Distribuidos. Introducción”, Dpto.ATC UP/EHU, Jul. 10. 2009, Universidad del País Vasco. [en línea], Disponible en: http://www.sc.ehu.es/acwlaalm/sdi/introduccioi-slides.pdf. 2009.
[2]    Cavanaugh, E, “Web services: Benefits, challenges, and a unique, visual development solution”, white paper, Feb. 10. 2006, Sitio web de Altova. [en línea], Disponible en: http://www.altova.com/whitepapers/webservice.pdf. 2006.
[3]    Paul d. Hestand, a service oriented architecture for robotic platforms, university of massachusetts lowell, 2011
[4]    Willow Garage, “Personal Robot 2 (PR2),” [en línea], Disponible en: www.willowgarage.com.
[5]    Vaculin, R. Sycara, K, “Semantic Web Services Monitoring: AN OWL-S based Approach”, 2007.
[6]    Martin D, Paolucci M, McIlraith S, Burstein M, McDenitt D, McGuinness D, Parsia B, Payne T, Sabou M, Solanki M, Srinivasan N & Sycara K. “Briging Semantic to Web Services: The OLW-S Approach”, 2004.
[7]    Boyce, S., & Pahl, C. Developing Domain Ontologies for Course Content. Educational Technology & Society, 10 (3), 275-288. 2007.
[8]     Sirin E & Parsia B. “The OWL-S Java API”, 2004.
[9]     Gruber, T, “What is an Ontology”, 2007.
[10]   Gunzer H, "Introduction to Web Services", 2002
[11]   Hu, G. Tay, W P. Wen Y, "Cloud Robotics: Architecture, Challenges and Applications", 2011.
[12]  Alcázar V, Guzmán C, Prior D, Borrajo D, Castillo L, Onaindía E. “PELEA: Planning, Learning and Execution Architecture”. 2010
[13]  Ghallab M, Howe A, Knoblock C, McDermott D, Ram A, Veloso M, Weld D, Wilkins D. “PDDL-The Planning Domain Definition Language”. 2003
[14]  IEEE, “Concurso Latinoamericano de Robótica para Estudiantes”, [en línea], Disponibe en: http://ewh.ieee.org/reg/9/robotica/Reglas/reglas_eng2011.htm
[15]  Ceravolo P, Damiani E, Fugazza C. “A Transfusion Ontology for Remote Assistance in Emergency Health Care”, On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops, pp.1044–1049. 2006.
[16]  Brusa G, Caliusco L, Chiotti O. “A Process for Building a Domain Ontology: an Experience in Developing a Government Budgetary Ontology”. 2006
[17]  Linglom, “How to run command-line or execute external application from Java”, [en línea], Disponible en: http://www.linglom.com/2007/06/06/how-to-run-command-line-or-execute-external-application-from-java/
[18]  Gerevini A, Serina I. "LPG: a Planner based on Local Search for Planning Graphs". Sixth International Conference on Artificial Intelligence Planning and Scheduling (AIPS'02), AAAI Press, Toulouse, France, 2002.
[19]   Mortiz, T. Ulrich, K. Dejan, P & Micheale, B., “Web-enabled Robots that use the Web as an Information Resource”, 2011.
[20]   Arkin, R., “Motor schema-based mobile robot navigation”, In Proceedings of the IEEE International Conference on Robotics and Automation, pp.264–271. 2007.
[21]   Hogan, A. Harth, A. y Polleres, A., “Scalable authoritative OWL reasoning for the web”, Information Systems, pp.49–90. 2008.
 

 

No hay comentarios:

Publicar un comentario