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.
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