Arquitectura de Software para un Sistema Robótico Móvil-Edición Única

PUBLICACIÓN DE TRABAJOS DE GRADO

Las Bibliotecas del Sistema Tecnológico de Monterrey son depositarias de los trabajos recepcionales y de

grado que generan sus egresados. De esta manera, con el objeto de preservarlos y salvaguardarlos como

parte del acervo bibliográfico del Tecnológico de Monterrey se ha generado una copia de las tesis en

versión electrónica del tradicional formato impreso, con base en la Ley Federal del Derecho de Autor

(LFDA).

Es importante señalar que las tesis no se divulgan ni están a disposición pública con fines de

comercialización o lucro y que su control y organización únicamente se realiza en los Campus de origen.

Cabe mencionar, que la Colección de

Documentos Tec,

donde se encuentran las tesis, tesinas y

disertaciones doctorales, únicamente pueden ser consultables en pantalla por la comunidad del

Tecnológico de Monterrey a través de Biblioteca Digital, cuyo acceso requiere cuenta y clave de acceso,

para asegurar el uso restringido de dicha comunidad.

El Tecnológico de Monterrey informa a través de este medio a todos los egresados que tengan alguna

inconformidad o comentario por la publicación de su trabajo de grado en la sección Colección de

Documentos Tec

del Tecnológico de Monterrey deberán notificarlo por escrito a

http://biblioteca.itesm.mx

Arquitectura de Software para un Sistema Robótico

Móvil-Edición Única

Title

Arquitectura de Software para un Sistema Robótico

Móvil-Edición Única

Authors

José Antonio Pacheco Sánchez

Affiliation

Tecnológico de Monterrey, Campus Cuernavaca

Issue Date

2005-01-01

Item type

Tesis

Rights

Open Access

Downloaded

19-Jan-2017 02:45:57

SUPERIORES DE MONTERREY

ARQUITECTURA DE SOFTWARE PARA UN SISTEMA ROBÓTICO MÓVIL

Autor:

José Antonio Pacheco Sánchez

Sometido al Programa de Graduados en Informática y Computación en cumplimiento parcial con los requerimientos para obtener el grado de

Maestro en Ciencias Computacionales

Asesores:

Dr. Roberto Abraham Valdivia Beutelspacher

Dr. Luis Enrique Sucar Succar

ARQUITECTURA DE SOFTWARE PARA UN SISTEMA ROBÓTICO MÓVIL

Presentada por:

José Antonio Pacheco Sánchez

Aprobada por:

Dr. Roberto Abraham Valdivia Beutelspacher Profesor – Investigador del Departamento de Computación

ITESM Campus Ciudad de México Asesor de Tesis

Dr. Enrique Sucar Succar

Profesor – Investigador del Departamento de Computación ITESM Campus Cuernavaca

Asesor de Tesis

Dr. Victor Hugo Zárate Silva

Profesor – Investigador del Departamento de Computación ITESM Campus Cuernavaca

Revisor de Tesis

Dr. Eduardo Morales Manzanarez

Profesor – Investigador del Departamento de Computación ITESM Campus Cuernavaca

RESUMEN

Uno de los principales retos de los sistemas de software es el incremento en el número y la complejidad de los elementos que los componen. El diseño y organización de las estructuras de estos sistemas radica en las especificaciones de mecanismos de control, protocolos de comunicación y aspectos de tolerancia a fallas. A este trabajo, se le conoce como el diseño de arquitecturas de software. En el campo de la robótica móvil, se han realizado diferentes diseños que han ido evolucionando a través de los años, aunque la gran mayoría coincide en un estilo arquitectónico basado en capas y en la organización jerárquica de los componentes que la integran.

En esta tesis se propone un enfoque arquitectónico basado en tres capas para un sistema robótico móvil. Las tres capas son: la capa funcional, la capa de ejecución y la capa de decisión. En la capa funcional se definen las interfaces que se necesitan para controlar los dispositivos físicos del robot. En la capa de ejecución o capa intermedia se ubican los componentes que proveen la funcionalidad que un robot necesita para realizar tareas, por ejemplo la navegación y la interacción humano-robot. En la capa de decisión o de más alto nivel, se proponen coordinadores para manejar los aspectos deliberativos de la arquitectura. Esta capa también contiene un modelo del mundo conformado por diferentes variables de estado, cuya combinación genera una política de acción a efectuar por el robot. Se considera también el modelo como una arquitectura extendida debido a que se sientan las bases para el establecimiento de servicios remotos y su respectiva integración dentro del modelo de capas. El modelo considera el aspecto de tolerancia a fallas analizando situaciones de alto nivel a través de un coordinador y generando una base de datos de los diferentes errores específicos de cada componente, asimismo se establecen caracterizaciones para situaciones de fallas de bajo nivel mismas que están relacionadas con los dispositivos físicos del robot.

La evaluación de la arquitectura consistió en la definición de una aplicación de prueba cuya finalidad fue la de controlar un robot a través de un asistente personal digital donde se integraron cuatro componentes dentro de la capa de ejecución (navegación, localización, planeación e interfaz humano-robot utilizando un asistente personal digital), un coordinador de movilidad y otro de fallas ubicados en el nivel de decisión y la implementación como middleware del proyecto Player/Stage[1], como la capa funcional que proporciona interfaces de acceso a los sensores y

Agradecimientos

Agradezco profundamente el apoyo recibido por parte de la cátedra de robótica móvil para mis estudios de maestría a través de las becas de colegiatura y manutención que me otorgaron. Me siento muy orgulloso de haber pertenecido a este grupo de investigación y de haber aportado una parte para el desarrollo de sus objetivos.

Agradezco de la misma manera, a mi asesor de tesis, el Dr. Roberto Valdivia por sus horas dedicadas a la dirección de esta tesis y por su valiosa amistad que me brindó durante toda mi estancia de estudios de maestría, al Dr. Enrique Sucar, al Dr. Oscar Mayora y al Dr. Eduardo Morales, por los conocimientos que me brindaron y que gracias a ellos pude culminar satisfactoriamente una etapa más en mi vida profesional.

De nueva cuenta, les reitero mi agradecimiento y amistad. La vida nos tiene asignadas metas y proyectos y es por ustedes que este trabajo existe. Muchas Gracias.

Dedicatorias

Dedico este trabajo a Dios por darme la vida y por otorgarme el privilegio de seguir viviendo.

A mi familia por estar al pendiente siempre de mí, y por brindarme sus porras en los momentos precisos. Este logro es un paso más en la vida, la misma vida que ustedes me enseñaron a vivirla mejor que nadie.

Dicen que los últimos serán los primeros, a la señora Magui y al Señor Antonio se les debe el trato de Padres. Ser padres es algo que se gana no de un día para otro, sino de una vida para otra. Ustedes nos han brindado la suya a los cuatro por igual y a través de estar palabras, quiero decirles: ¡Gracias por ser mis padres, que Dios los bendiga siempre!

Tabla de Contenido

RESUMEN ___________________________________________________________ iii CAPÍTULO 1 __________________________________________________________ 1 Introducción __________________________________________________________ 1

1.1Antecedentes ____________________________________________________ 1 1.2Motivación ______________________________________________________ 3 1.3Objetivos del proyecto ____________________________________________ 4

1.3.1 Objetivo General _____________________________________________________ 4 1.3.2 Objetivos Específicos _________________________________________________ 5

1.4Alcances y limitaciones ____________________________________________ 5 1.5Arquitectura propuesta ____________________________________________ 6 1.6Estructura de la Tesis _____________________________________________ 8 CAPÍTULO 2 ________________________________________________________ 10 Arquitecturas de Software _____________________________________________ 10 2.1Descripción del capítulo __________________________________________ 10 2.2¿Qué es una Arquitectura de Software? _____________________________ 10 2.3Enfoques Arquitectónicos Generales _______________________________ 11

2.3.1 Estilos Arquitectónicos. _______________________________________________ 11 2.3.2 Arquitectura cliente-servidor. ___________________________________________ 12 2.3.3 Arquitecturas orientadas a objetos. ______________________________________ 13 2.3.4 Arquitecturas Basadas en Componentes. _________________________________ 14 2.3.5 Arquitecturas orientadas a servicios. _____________________________________ 14 2.3.6 Arquitecturas en capas. _______________________________________________ 15 2.3.7 Arquitecturas de pizarrón. _____________________________________________ 17

2.4Necesidades particulares de una arquitectura en robótica móvil _________ 19 2.5Enfoques arquitectónicos orientados hacia la robótica ________________ 20

2.5.1 Arquitecturas deliberativas ____________________________________________ 20 2.5.2 Arquitecturas reactivas _______________________________________________ 22 2.5.3 Arquitecturas híbridas ________________________________________________ 24 2.5.4 Arquitecturas basadas en responsabilidades ______________________________ 26 2.5.5 Arquitecturas basadas en estados ______________________________________ 27 2.5.6 Arquitecturas basadas en modelos ______________________________________ 29

2.6Arquitecturas de referencia _______________________________________ 32

2.6.1 Arquitectura LAAS ___________________________________________________ 32 2.6.2 Arquitectura del Robot Homer __________________________________________ 34

3.2Arquitectura del Sistema 3+ _______________________________________ 38

3.2.1 Capa funcional ______________________________________________________ 39 3.2.2 Capa de ejecución ___________________________________________________ 39 3.2.3 Capa de decisión ____________________________________________________ 40 3.2.4 Arquitectura Extendida _______________________________________________ 41 3.2.5 Protocolo de comunicación ____________________________________________ 42 3.2.6 Estructura del protocolo de comunicación _________________________________ 43

3.3Tolerancia a Fallas _______________________________________________ 44

3.3.1 Coordinador de Fallas ________________________________________________ 47

3.4Ejemplo de Implementación de la Arquitectura 3+ _____________________ 49

3.4.1 Capa Funcional _____________________________________________________ 55 3.4.2 Capa de Ejecución __________________________________________________ 57 3.4.3 Capa de Decisión ___________________________________________________ 58 3.4.4 Necesidades de infraestructura física ____________________________________ 58

3.5Conclusión del capítulo ___________________________________________ 63 CAPÍTULO 4 ________________________________________________________ 64

Implementación y Pruebas _____________________________________________ 64 4.1Objetivos _______________________________________________________ 64 4.2Evaluación y Pruebas ____________________________________________ 64

4.2.1 Diseño de las pruebas ________________________________________________ 65 4.2.2 Resultado de las pruebas _____________________________________________ 69

CAPÍTULO 5 ________________________________________________________ 72 Conclusiones y trabajo futuro __________________________________________ 72 5.1Conclusiones ___________________________________________________ 72 5.2Trabajo futuro ___________________________________________________ 74 Anexos _____________________________________________________________ 75

Anexo A ___________________________________________________________ 75 Player/Stage _______________________________________________________ 75

Anexo B ___________________________________________________________ 77

Lista de Figuras

Figura 1.1 Robots Industriales --- 2

Figura 1.2 Diagrama de la Arquitectura propuesta (abstracta) --- 6

Figura 1.3 Diagrama de la Arquitectura propuesta (ejemplo de implementación)--- 8

Figura 2.1 Arquitectura Cliente-Servidor --- 13

Figura 2.2 Arquitectura de los sistemas en capas --- 16

Figura 2.3 Diagrama de la arquitectura de pizarrón --- 18

Figura 2.4 Shakey, el primer robot móvil que podía “pensar” y respondía a su entorno --- 20

Figura 2.5 Organización Sensa-Planea-Actúa (SPA), propia del paradigma deliberativo ---- 21

Figura 2.6 Descomposición horizontal de tareas --- 23

Figura 2.7 Descomposición vertical de tareas de tipo sensa-actúa --- 23

Figura 2.8 Esquema de la Arquitectura AuRA --- 26

Figura 2.9 Arquitectura 3T --- 28

Figura 2.10 Arquitectura Saphira --- 30

Figura 2.11 Arquitectura del LAAS --- 33

Figura 2.12 Arquitectura de control del robot Homer --- 35

Figura 3.1 Diagrama de la arquitectura 3+ --- 39

Figura 3.2 Estructura de un mensaje del protocolo de comunicación --- 43

Figura 3.3 División de tolerancia a fallas de alto y bajo nivel en la arquitectura de software 46 Figura 3.4 Capa de decisión con base datos de errores --- 48

Figura 3.5 Diagrama de estados --- 53

Figura 3.6 Diagrama de la arquitectura 3+ para el ejemplo desarrollado --- 55

Figura 3.7 Capa funcional --- 56

Figura 3.8 Capa de Ejecución --- 57

Figura 3.9 Capa de decisión --- 58

Figura 3.10 Arquitectura 3+ distribuida a través de servidores en una red --- 59

Figura 4.1 Escenario de pruebas --- 65

Figura 4.2 Módulos de Localización, Mapas, Coordinador de Movilidad y Navegación --- 66

Figura 4.3 Módulo de PDA --- 67

Figura 4.4 Robot Pioneer 2AT con servidor Player/Stage a bordo --- 67

Figura 4.5 Generación del mapa de laboratorio --- 68

Figura 4.6 Posición del robot mostrada en el módulo de PDA --- 68

Figura 4.7 Trayectoria del robot vista desde la PDA --- 69

Lista de Tablas

Tabla 2.1 Elementos, relaciones y propiedades de la arquitectura cliente-servidor --- 12

Tabla 2.2 _{Interacción de las fases dentro del modelo SPA --- 21}

Tabla 2.3 Comparación de Arquitecturas --- ₃₆

Tabla 3.1 _{Encabezado del protocolo de comunicación --- 44}

Tabla 3.2 _{Variables de estado de la arquitectura 3+ --- 50}

Tabla 3.3 Listado de acciones y componentes --- ₅₁

Tabla 3.4 Tabla de estado: Estado/Acción --- ₅₂

Tabla 3.5 _{Algunos módulos que se ejecutan en la capa funcional, propios de Player/Stage 56} Tabla 3.6 Interfaces del componente de navegación --- ₆₀

Tabla 3.7 Interfaces para el componente de planeación --- ₆₀

Tabla 3.8. Interfaz de comunicación con el componente localización --- ₆₁

Tabla 3.9. Interfaz de comunicación con el componente coordinador --- ₆₁

Tabla 3.10 Interfaz de comunicación para el componente PDA --- ₆₂

Introducción

C

APÍTULO

1

1 Introducción

1.1 Antecedentes

El uso de robots en la vida diaria está dejando de ser una ficción. Los actuales desarrollos en el campo de la robótica alrededor del mundo indican que en una o dos décadas existirá toda una nueva industria puesto que los robots serán artículos de uso común tal como ha sucedido con las computadoras [2]. El surgimiento de este tipo de robots implica que deben operar en ambientes desconocidos, que normalmente son más complejos y dinámicos. Esto trae consigo importantes retos de razonamiento con incertidumbre, planeación, coordinación entre robots y comunicación humano-robot, entre otras.

A partir de este entorno surge la cátedra/proyecto de robótica móvil, formada por un grupo interdisciplinario de investigadores en Campus Cuernavaca y en Campus Ciudad de México del Tecnológico de Monterrey, cuyo fin es lograr avances significativos en éstas áreas y contribuir al desarrollo de los robots del futuro. Dentro de la cátedra de robótica móvil se realizan proyectos de investigación en diversas áreas específicas, entre las que se cuentan:

• Aprendizaje por refuerzo.

• Construcción de mapas y localización de robots.

• Reconocimiento visual de ademanes.

• Interfaz para controlar a un robot a través de un dispositivo móvil

• Sistema de navegación por medio de comandos vocales.

• Detección y evasión de obstáculos.

• Agente emotivo de interfaz para tutores.

Las áreas de investigación mencionadas anteriormente, tienen como finalidad contribuir en el desarrollo de robots de servicio. Actualmente una de las finalidades de la construcción de robots es su intervención en los procesos de manufactura, emergiendo de esta manera lo que se conoce como robots industriales. Estos robots, que no tienen

forma humana en absoluto, son los encargados de realizar trabajos repetitivos en las cadenas de proceso de fabricación, como por ejemplo: pintar, moldear, soldar carrocerías de automóvil, trasladar materiales, etc. En una fábrica sin robots, los trabajos antes mencionados los realizan técnicos especialistas en cadenas de producción. Con los robots, el técnico puede librarse de la rutina y el riesgo que sus labores implican, con lo que la empresa gana en rapidez, calidad y precisión.

Figura 1.1 Robots Industriales.

La IFR ha adoptado también una clasificación provisional de los robots de servicio, por áreas de aplicación:

ƒ Servicio a humanos

o Utilización de robots en casa para apoyo en las labores domésticas, de

protección, entretenimiento, etc.

ƒ Servicio a sistemas de automatización

o Mantenimiento, reparación, limpieza, etc.

ƒ Otras funciones autónomas

o Apoyo en labores de vigilancia, transporte, adquisición de datos y

cualquier aplicación que no se ajuste a las primeras dos clasificaciones.

1.2 Motivación

De la necesidad de conjuntar los diferentes proyectos interdisciplinarios arriba mencionados dentro de un solo proyecto, surge la idea de diseñar y definir una arquitectura de software para un sistema robótico móvil que sea capaz de realizar dicha integración, utilizando una estructura modular y robusta.

Una arquitectura de software, según la visión de Len Bass, Paul Clements y Rick Kazman [4] es “la estructura o estructuras de un sistema formado por elementos de software, sus propiedades externas y las relaciones existentes entre ellos”. Esto significa que una arquitectura de software define elementos y la información de cómo los elementos se relacionan entre sí. A su vez, la arquitectura omite la información específica que no corresponde estrictamente al ámbito de dicha interacción. Esto significa que la arquitectura es más una abstracción de un sistema y se preocupa sólo por la interacción de sus elementos, no por su funcionamiento interno (interfaces y propiedades internas).

personas y lugares que el visitante solicite y que pueda guiarlo a través del campus hasta llegar a su meta. El poder realizar todas estás tareas, podría parecer sencillo y simple para un ser humano, pero un robot necesita del conocimiento e interpretación del medio que lo rodea para poder tomar decisiones y prever lo que sucederá si el medio ambiente cambia constantemente.

Con el fin de lograr lo anterior, el presente trabajo define la creación de un sistema arquitectónico basado en capas bajo un esquema de cómputo distribuido así como la definición de un esquema de tolerancia a fallas que ofrezca operaciones y procedimientos a llevar a cabo en caso de presentarse errores. Algunos trabajos previos sugieren el esquema de descomposición de tareas en capas [5], otros trabajos sugieren la descomposición de tareas bajo ambientes de cómputo distribuido [6]. Sin embargo, al momento de diseñar la arquitectura en nuestro proyecto, se optó por tomar las ideas principales de ambos enfoques, dando como resultado un modelo arquitectónico basado en capas funcionando bajo un entorno de cómputo distribuido; esto nace debido a la heterogeneidad de plataformas de desarrollo y lenguajes de programación que se utilizan dentro de la cátedra de robótica móvil y de un aprovechamiento adecuado de tecnologías para interfaces de control, como Player/Stage[1], cuya funcionalidad se

describe más adelante.

Otro punto importante a considerar, es la inclusión del aspecto de tolerancia fallas, mismo que establece niveles de operación acorde a la información del estado y del rendimiento de los elementos que integran la arquitectura.

1.3 Objetivos del proyecto

1.3.1 Objetivo General

analizando los aspectos de robustez e integridad en los servicios que proporcione la arquitectura, así como también define los datos de intercambio y comunicaciones.

1.3.2 Objetivos Específicos

ƒ Analizar los diferentes enfoques de software arquitectónicos generales y los enfoques arquitectónicos específicos para sistemas robóticos móviles.

ƒ Especificar una arquitectura para robot móviles donde se muestren los componentes y la forma de comunicación entre ellos.

ƒ Crear las especificaciones básicas para que el modelo sea tolerante a fallas y las acciones a realizar en cada caso.

ƒ Probar el diseño de una arquitectura de software para un sistema robótico móvil a través de la interacción de cuatro módulos: Navegación, Localización, Planeación de trayectorias e interfaz con un Asistente Personal Digital.

1.4 Alcances y limitaciones

Esta tesis propone la creación de una arquitectura de software basada en componentes, los cuales tienen su origen en las aplicaciones que cada grupo de investigación realiza dentro de la cátedra. Para verificar el modelo aquí propuesto, se evaluará la arquitectura utilizando cuatro componentes con un coordinador. Los componentes a integrar, son:

ƒ Navegación

ƒ Localización

ƒ Planificación de trayectorias

ƒ Interfaz utilizando PDA (Personal Digital Assistant)

1.5 Arquitectura propuesta

Se propone un modelo arquitectónico basado en capas bajo un ambiente de cómputo distribuido. Las capas que forman parte de la arquitectura son: la capa funcional, o de nivel más bajo, misma que interactúa con los dispositivos físicos del robot a través de interfaces bajo el esquema de Player/Stage, la capa de ejecución, donde se localizan

los componentes de movilidad e interfaz humano-robot que integran la arquitectura y la capa de decisión, misma que se localiza en el nivel superior de esta arquitectura y realiza tareas de coordinación y manejo de fallas. En la Figura 1.2 se muestra un panorama general que describe la arquitectura propuesta.

Como se puede observar en la Figura 1.2, la capa funcional interactúa directamente con el robot, en la capa de ejecución se muestran los componentes que se integrarán en el ejemplo desarrollado y, finalmente, en la capa de decisión se muestra un coordinador, encargado de actualizar el modelo del mundo basado en las salidas de los componentes de la capa de ejecución. Los componentes que conforman el nivel de ejecución pueden estar localizados en diferentes computadoras interconectadas a través de una red. Todos los mensajes enviados desde los componentes, pasarán a través del coordinador, que en el caso de nuestra propuesta estará ubicado en otra máquina y será el encargado de actualizar las variables que conforman el modelo del mundo.

Para realizar las pruebas de esta arquitectura, se procedió en primera instancia a generar los mapas de navegación del escenario del laboratorio, posteriormente, se exportaron esos mapas a GML (Geography Markup Language), un lenguaje de modelado para sistemas geográficos, utilizado para poder presentar de una forma sencilla los mapas en la PDA [7]. Posteriormente, se le asignaba al robot la tarea de ir hacia un lugar determinado por el usuario usando el mapa mostrado en la PDA. De esta forma, cuando el usuario asignaba un lugar en la PDA, el robot navegaba a través del laboratorio hasta llegar al punto indicado por el usuario, donde se detenía a esperar nuevas instrucciones.

Figura 1.3 Ejemplo de implementación de la arquitectura 3+.

En el transcurso de los siguientes capítulos, se realizará un análisis de la arquitectura propuesta y se justificarán los procedimientos de diseño y evaluación que se llevaron a cabo.

1.6 Estructura de la Tesis

Esta Tesis está estructurada en 5 capítulos, mismos que son descritos a continuación.

En el capítulo 2 se establece una definición de arquitectura de software, cuales son sus propiedades y características. Se realiza un análisis de diferentes enfoques arquitectónicos generales y enfoques arquitectónicos orientados hacia la robótica. Se analizan ejemplos concretos de trabajos realizados en esta área y finalmente, se ofrece un vista de la arquitectura del proyecto Player/Stage [1] utilizado en esta Tesis.

Dentro del capítulo 3, se describe a profundidad la arquitectura del modelo propuesto. Se declaran formalmente cada una de las capas que integran la arquitectura y su respectivo esquema de comunicaciones. Se explica el funcionamiento del coordinador y la manera en que éste maneja el estado del robot, actualizando las variables de estado y realizando las acciones correspondientes acorde al modelo. Por último, se detalla el protocolo de comunicación para cada uno de los componentes que integran la arquitectura propuesta. El aspecto de tolerancia a fallas también forma parte de las aportaciones de esta Tesis. En esta parte, se realiza una descripción y categorización de los tipos de fallas que se pueden presentar durante el funcionamiento de la arquitectura, así como también se definen los procedimientos a seguir en caso de presentarse dichos fallos.

El capítulo 4 muestra la fase de implementación y pruebas que se realizaron para la evaluación de este trabajo. En esta sección se muestran los experimentos que se realizaron así como los resultados obtenidos.

En el capítulo 5 se muestran las conclusiones de la Tesis, ofreciendo un panorama general de las evaluaciones obtenidas durante el desarrollo del presente trabajo. De la misma manera, en esta sección se encontrarán propuestas relacionadas con el trabajo futuro a realizarse en diferentes ámbitos del proyecto.

En la sección referida a los anexos se incluye información acerca del proyecto Player/Stage [1] útil para el contexto de la presente tesis y una breve guía para el arquitecto de software.

Arquitecturas

de Software

C

APÍTULO

2

2 Arquitecturas de Software

2.1 Descripción del capítulo

En este capítulo, se presenta un análisis de lo que representa una arquitectura de software y cuáles son las características que identifican a una arquitectura; Se muestran algunos enfoques arquitectónicos generales, que no son de uso exclusivo de entornos robóticos. Sin embargo, dado que el campo de la robótica tiene necesidades especiales, se identifican estas necesidades y se muestran una serie de enfoques arquitectónicos orientados hacía la robótica .

El objetivo de este capítulo, es conocer de cerca el mundo de las arquitecturas de software, ofreciendo un fundamento teórico para el soporte de toma de decisiones en el momento de elegir la que más convenga a nuestro trabajo a través del análisis del estado del arte de las arquitecturas para entornos robóticos.

2.2 ¿Qué es una Arquitectura de Software?

Una arquitectura de software es considerada como: “la organización fundamental de un sistema, formada principalmente por componentes, las relaciones entre ellos y el ambiente, y los principios que gobiernan su diseño y evolución” [8]. De este enfoque se desprenden las características esenciales que identifican a una arquitectura, las cuales vienen dadas en términos de componentes.

pueden encontrar estudios de desarrollo basado en componentes a nivel conceptual y/o metodológico, por ejemplo las arquitecturas basadas en componentes de la sección 2.3.4, en los que fijando la noción de componente, se busca definir la arquitectura lógica de ciertos tipos de sistemas y los pasos para extenderla con componentes [9]. Por otra parte, se encuentran tecnologías que proporcionan plataformas para el desarrollo y ejecución de componentes (o sistemas basados en componentes), por ejemplo Java 2 Enterprise Edition J2EE [10].

A continuación, se presenta una breve descripción de la definición y funcionamiento de diferentes paradigmas de arquitecturas.

2.3 Enfoques Arquitectónicos Generales

En esta sección describiremos los principales estilos arquitectónicos generales. Mary Shaw y Paul Clements [11] identifican los estilos arquitectónicos como un conjunto de reglas de diseño que clasifican los tipos de componentes y conectores que se pueden utilizar para componer un sistema o subsistema, junto con las restricciones locales o globales del estilo arquitectónico.

2.3.1 Estilos Arquitectónicos.

2.3.2 Arquitectura cliente-servidor.

En una arquitectura de tipo cliente-servidor, los componentes que la integran se relacionan entre sí mediante peticiones generadas desde algunos componentes. La comunicación se origina generalmente desde el cliente hacia un servidor. Los servidores ofrecen un conjunto de servicios accesibles para el cliente a través de interfaces previamente establecidas. En sistemas distribuidos, la arquitectura cliente servidor es la arquitectura mayormente citada e históricamente, la más importante.

La arquitectura cliente-servidor contiene elementos, relaciones y componentes [13] los cuales se muestran en la Tabla 2.1.

Elementos Los elementos de esta arquitectura se clasifican en componentes de tipo cliente, quienes realizan las peticiones hacia otros componentes, y componentes tipo servidor, los cuales atienden las peticiones de los clientes a través de los servicios que éste provee.

Relaciones Una relación de unidad, asocia a los componentes clientes con el rol de peticiones, mientras que a los componentes de tipo servidor, se les asigna el rol de proveedor de servicios; asimismo, determina los servicios que un determinado conjunto de clientes puede solicitar.

Propiedades El número y tipo de clientes que pueden ser atendidos, así como parámetros de rendimiento, como el número de transacciones por segundo.

Figura 2.1 Arquitectura Cliente-Servidor [14].

2.3.3 Arquitecturas orientadas a objetos.

Este estilo arquitectónico también se conoce como Arquitecturas Basadas en Objetos, Abstracción de Datos y Organización Orientada a Objectos. Los componentes de este estilo son los objetos, o instancias de los tipos de dato abstractos. En la caracterización clásica de David Garlan y Mary Shaw [15], los objetos representan una clase de componentes que ellos llaman managers, debido a que son responsables de preservar

la integridad de su propia representación. Un rasgo importante de este aspecto es que la representación interna de un objeto no es accesible desde otros objetos. En la semblanza de estos autores curiosamente no se establece como punto importante el principio de herencia. Ellos piensan que, a pesar de que la relación de herencia es un mecanismo organizador importante para definir los tipos de objeto en un sistema concreto, la herencia no cuanta con una función arquitectónica directa. En particular, en dicha concepción la relación de herencia no puede concebirse como un conector, puesto que no define la interacción entre los componentes de un sistema. Además, en un escenario arquitectónico la herencia de propiedades no se restringe a los tipos de objeto, sino que puede incluir conectores e incluso estilos arquitectónicos enteros.

tecnología, el hecho de que los objetos sean locales o remotos, carece de relevancia. El mejor ejemplo de OO para sistemas distribuidos es Common Object Request Broker Architecture (CORBA), en la cual las interfaces se definen mediante un Lenguaje de

Descripción de Interfaces (IDL, por sus siglas en Inglés); un Object Request Broker

maneja las interacciones entre objetos clientes y objetos servidores en ambientes distribuidos.

2.3.4 Arquitecturas Basadas en Componentes.

Las arquitecturas de software basadas en componentes se sustentan en principios definidos por una ingeniería de software específica conocida como CBSE ( Component-Based Software Engineering) [16].

En el estilo de componentes, éstos se valen de CBSE ya que representan las unidades de modelado, diseño e implementación. Las interfaces y sus interacciones se constituyen en el centro del diseño arquitectónico. Los componentes soportan interfaces que permiten acceder a sus contenidos, de modo que su funcionalidad y propiedades puedan ser descubiertas y utilizadas en tiempo de ejecución.

La evaluación de este estilo arquitectónico basado en componentes subraya una mayor versatilidad respecto del modelo de objetos, pero también su menor adaptabilidad comparado con el estilo orientado a servicios, mismo que se describe a continuación. .

2.3.5 Arquitecturas orientadas a servicios.

Este estilo arquitectónico, conocido como SOA (ServiceOriented Architecture), va de la

mano con la expansión de los Web Services basados en XML (Extensible Markup Languaje), en los cuales los formatos de intercambio se basan en XML 1.0 Namespaces

y el protocolo SOAP (Simple Object Access Protocol). SOAP es un formato de

Al principio resultaba difícil encontrar una definición aceptable de Web Service, por lo que el grupo de tareas de W3C, ofreció la primera definición canónica aceptable para enfoques arquitectónicos: “Un Web Service es un sistema de software diseñado para soportar interacción máquina-a-máquina sobre una red. Posee una interfaz descripta en un formato conocido como WSDL (Web Services Description Language). Otros

sistemas interactúan con el Web service de una manera definida por su descripción utilizando mensajes SOAP, típicamente transportados usando HTTP con una serialización en XML en conjunción con otros estándares relacionados a la Web” [18].

En la literatura clásica, las arquitecturas basadas en servicios podrían encajar con lo que Garlan & Shaw definen como el estilo de procesos distribuidos [15]. Otros autores hablan de arquitecturas de componentes independientes que se comunican a través de mensajes. Desde el punto de vista arquitectónico, se puede hacer una caracterización concisa de este estilo. Un servicio es una entidad de software que encapsula funcionalidad de procesos y proporciona dicha funcionalidad a otras entidades a través de interfaces públicas bien definidas. Los componentes del estilo (servicios) están débilmente acoplados. El servicio puede recibir requerimientos desde cualquier origen. La funcionalidad del servicio se puede ampliar o modificar sin afectar a quienes lo requieran. Los servicios son las unidades de implementación y diseño en el contexto de este estilo. Los componentes que requieran un servicio pueden descubrirlo y utilizarlo dinámicamente mediante UDDI (Universal Description, Discovery and Integration) y sus estándares sucesores. En general (aunque hay alternativas) no se mantiene persistencia de estado y tampoco se pretende que un servicio recuerde nada entre un requerimiento y el siguiente.

2.3.6 Arquitecturas en capas.

excepto para algunas funciones cuya exportación se considere indispensable; En estos sistemas, los componentes implementan máquinas virtuales en alguna de las capas de la jerarquía. En la práctica, las capas suelen ser entidades complejas, compuestas de varios paquetes o subsistemas. El uso de arquitecturas en capas, explícitas o implícitas, es muy frecuente, solamente en Pattern Almanac 2000 [19] hay cerca de cien patrones que son variantes del patrón básico de capas.

En un estilo en capas, los conectores se definen mediante los protocolos que determinan las formas de la interacción. Los diagramas de sistemas clásicos en capas dibujaban las capas en adyacencia, sin conectores, flechas ni interfaces; en algunos casos se suele representar la naturaleza jerárquica del sistema en forma de círculos concéntricos, como se muestra en la Figura 2.2. Las restricciones topológicas del estilo pueden incluir una limitación, más o menos rigurosa, que exige a cada capa operar sólo con capas adyacentes, y a los elementos de una capa entenderse sólo con otros elementos de la misma.

Figura 2.2. Arquitectura de los sistemas en capas.

datos, red, transporte, sesión, presentación y aplicación. El estilo de capas también se encuentra en forma más o menos pura en arquitecturas de bases de datos y sistemas operativos, así como en las especificaciones relacionadas con XML.

Las ventajas del estilo en capas son obvias. Primero que nada, el estilo soporta un diseño basado en niveles crecientes de abstracción, lo cual a su vez permite a los implementadores dividir un problema complejo en una secuencia de pasos incrementales. En segundo lugar, el estilo admite optimizaciones y refinamientos. En tercer lugar, proporciona una amplia reutilización de componentes. Al igual que los tipos de datos abstractos, se pueden utilizar diferentes implementaciones o versiones de una misma capa en la medida que soporten las mismas interfaces de cara a las capas adyacentes. Esto conduce a la posibilidad de definir interfaces de capa estándar, a partir de las cuales se pueden construir extensiones específicas.

2.3.7 Arquitecturas de pizarrón.

En esta arquitectura hay dos componentes principales: una estructura de datos que representa el estado actual y una colección de componentes independientes que operan sobre él [21]. En base a esta distinción se han definidos dos subcategorías principales del estilo:

ƒ Si los tipos de transacciones en el flujo de entrada definen los procesos a ejecutar, el repositorio puede ser una base de datos tradicional.

ƒ Si el estado actual de la estructura de datos dispara los procesos a ejecutar, el repositorio es lo que se llama un pizarrón puro o un tablero de control.

Un dato curioso, es que el documento clásico que describe este estilo [22], de gran aceptación en el campo de la inteligencia artificial es anterior en seis años al surgimiento de la idea de estilos en arquitecturas de software. Los estilos de pizarrón se utilizan en exploraciones recientes de inteligencia artificial distribuida o cooperativa, en robótica, en modelos multiagentes, en programación evolutiva, etc. Un sistema de pizarrón se implementa para resolver problemas en los cuales las entidades individuales muestran limitaciones al momento de aproximarse a una solución, o para los que no existe una solución analítica, o para los que sí existe pero es inviable por la dimensión del espacio de búsqueda. Todo modelo de este tipo consiste en las siguientes tres partes (Figura 2.3):

ƒ Fuentes de conocimiento (KS, por sus siglas en inglés), necesarias para resolver el problema.

ƒ Un pizarrón que representa el estado actual de la resolución del problema.

ƒ Una estrategia, que regula el orden en que operan las fuentes.

Figura 2.3. Diagrama de la arquitectura de pizarrón.

2.4 Necesidades particulares de una arquitectura en robótica

móvil

Los paradigmas arquitectónicos mencionados hasta este momento, responden a necesidades más generales que específicas para catalogarlas, per se, como propias

para entornos robóticos; antes se requiere un análisis de las particularidades y factores que deben ser inherentes a una arquitectura para dichos entornos. La funcionalidad y validez de un sistema para que pueda ser considerado como un enfoque orientado hacía la robótica depende de ciertos factores, entre los más importantes destacan [23]:

ƒ Integración: Que se establezcan mecanismos transparentes de comunicación entre los componentes.

ƒ Reactividad: Que los componentes que integran la arquitectura sean capaces de reaccionar apropiadamente ante estímulos específicos y situaciones particulares tomando en consideración los requerimientos de las aplicaciones en tiempo real.

ƒ Robustez y tolerancia a fallas: La capacidad de explotar la redundancia de recursos, fuentes de información y procesos, son tareas que la arquitectura deberá permitir, además de contar con un sistema de tolerancia a fallas, que nos permita recuperar la funcionalidad del robot en entornos semi controlados.

ƒ Seguridad: Se requieren mecanismos que garanticen la seguridad de las aplicaciones robóticas, puesto que algunas veces, el robot puede verse implicado en situaciones donde la seguridad humana es un factor muy importante asimismo desde el punto de vista de garantizar la integridad del robot.

ƒ Extensibilidad: La arquitectura debe permitir agregar nuevas funcionalidades que puedan ser fácilmente adaptables a las existentes.

2.5 Enfoques arquitectónicos orientados hacia la robótica

En esta sección, se analizan algunos enfoques arquitectónicos orientados hacia el campo de la robótica móvil con el fin de determinar cómo se vinculan algunos de los estilos arquitectónicos generales con los factores que una arquitectura debe satisfacer para considerarla adecuada para entornos robóticos.

2.5.1 Arquitecturas deliberativas

Históricamente, el paradigma deliberativo – también conocido como paradigma jerárquico - se considera como el pionero dentro las arquitecturas de control en robótica. Sus inicios datan del año 1967, el año en que fue desarrollado el primer robot con matices de inteligencia artificial: el robot Shakey [24] – Figura 2.4 -. Desarrollado en el Instituto de Investigaciones de Stanford en el periodo comprendido entre los años 1966 y 1970, fue capaz de tomar bloques en una pila utilizando una cámara de video como un sensor visual, y procesando esta información en una pequeña computadora.

Figura 2.5 Organización Sensa-Planea-Actúa (SPA), propia del paradigma deliberativo. En este tipo de organización, el robot sensa su mundo y construye un mapa global de éste. Después planea la secuencia de pasos que se necesitan para alcanzar la meta. Finalmente, el robot ejecuta tales instrucciones. Este es un proceso iterativo, ya que una finalizado el proceso SPA, éste se vuelve a llevar a cabo para evaluar el modelo tomando en cuenta las posibles consecuencias de las acciones anteriores.

Tabla 2.2 Interacción de las fases dentro del modelo SPA.

La percepción es clave en todo robot autónomo, como se puede observar en la Tabla 2.2, ya que para poder influir sobre el entorno, es necesario que exista una manera de percibir el estado actual del mismo. En la fase de planificación el robot decide qué acciones llevar a cabo tomando como base las percepciones recién adquiridas y sus propios objetivos. Para poder efectuar la planificación, las percepciones deberán haber sido preprocesadas y transformadas en una abstracción del entorno. En la fase de acción se llevan a cabo las acciones de alto nivel que se seleccionaron en la fase de planificación, traduciéndolas en movimientos de los actuadores del robot.

mayoría de los algoritmos utilizados en esa época para llevar a cabo tareas de fusión sensorial y planeación eran extremadamente lentos, lo cual significa un cuello de botella dentro del modelo

Los problemas relativos a la planificación hicieron fracasar al paradigma SPA y con él el enfoque netamente jerárquico. Los desarrolladores en este paradigma llegaron a la conclusión de que para poder efectuar la planificación tal y como la plantea el modelo, era necesario que en la capa de percepción pudieran llevarse a cabo complejas tareas de abstracción para proveer a la capa de planificación con los símbolos de alto nivel que este nivel necesita. Esto estaba fuera del alcance de las tecnologías de los años 60-70. Por ello fue necesario buscar otras aproximaciones en las que no fuera imprescindible un preprocesamiento intensivo de las percepciones del robot. De esta manera fue como surgió el paradigma reactivo.

2.5.2 Arquitecturas reactivas

Las arquitecturas reactivas, surgen a fines de la década de los 80’s y su principal aportación al campo de la robótica móvil tiene dos vertientes. La primera se refiere a que en dominios muy limitados, este enfoque sigue siendo la mejor alternativa en cuanto al desempeño requerido para el tipo de tareas simples. En la segunda vertiente, la arquitectura reactiva forma la base para la arquitectura híbrida (arquitecturas reactivo-deliberativas), un enfoque de gran aceptación dentro de los paradigmas robóticos.

vendría dado en el caso de una persona que sufre de algún tipo de pérdida de conocimiento. A pesar de este problema, la persona seguirá respirando normalmente.

Figura 2.6 Descomposición horizontal de tareas.

Figura 2.7 Descomposición vertical de tareas. [5]

La característica fundamental de este tipo de arquitecturas es que todas las acciones están dadas en términos de comportamientos. Un comportamiento está dado por la transformación simple de las salidas de los sensores hacia comandos de los actuadores. El paradigma reactivo, no se ajusta al paradigma deliberativo de Sensa-Planea-Actua, sino que solamente basa su metodología en Sensa-Actua.

comportamientos están organizados en niveles, donde cada nivel posee ciertos comportamientos con características similares. Por ejemplo, el nivel más básico agrupa los comportamientos de supervivencia, como lo es la evasión de obstáculos, mientras que niveles más altos, crean las acciones enfocadas a obtener la meta. Cada uno de estos niveles, puede llegar a suprimir el comportamiento de su nivel inmediato inferior, dependiendo de los procesos que se estén llevando a cabo en ese momento.

El esquema reactivo ha sido ampliamente probado en diferentes implementaciones robóticas, por ejemplo en la arquitectura de subsumisión [5], debido a lo anterior se

considera que cuenta con un grado de robustez muy bueno. La aplicación de esta arquitectura se limita hacia dominios sencillos, debido a la falta de un esquema de razonamiento, lo cual se considera como una limitante en cuanto al factor de extensibilidad de dominios de aplicación.

2.5.3 Arquitecturas híbridas

Si bien es cierto que para fines de los años 80’s las arquitecturas reactivas se convirtieron rápidamente en las de mayor aceptación dentro del campo de la robótica debido a su naturaleza puramente reactiva con procedimientos en tiempo real, se dejaba a un lado el carácter deliberativo y de razonamiento del robot con respecto a su entorno. Esto, por supuesto, significaba que el robot no contara con un coordinador o un planeador que le ayudara a tener una visión amplia y completa del entorno, traduciéndose en no poder generar una trayectoria óptima hacia la meta así como en no contar con un esquema de localización local, mucho menos global, entre otras cosas.

El debate se centró entonces, en cómo incorporar los aspectos deliberativos y de coordinación dentro de una arquitectura, pero a su vez, aprovechando las ventajas que ofrecía un sistema probado y robusto como lo había demostrado ser el paradigma reactivo. Los investigadores empezaron a considerar que la mejor manera de lograr tal objetivo sería llevando el paradigma reactivo, incorporándolo como una capa de control de nivel bajo, a un entorno donde la coordinación de tareas y planeación se realizaría en niveles superiores de la arquitectura, es así como surge el paradigma conocido como híbrido.

ƒ El uso de técnicas asíncronas de procesamiento permiten llevar a cabo procesamientos deliberativos independientes de procesamientos reactivos, por ejemplo, con la ayuda de un planeador, se pueden realizar procesos para planear la siguiente meta, mientras la parte reactiva, navega a través del ambiente para lograr la meta actual.

ƒ Se pueden obtener beneficios extra, considerando la modularidad de algunos sistemas, para intercambiar fácilmente el dominio de aplicación de la arquitectura, recurriendo a la reutilización de componentes.

De tal forma, se puede concluir de forma breve, que el enfoque arquitectónico híbrido es una extensión del paradigma reactivo, con implementaciones deliberativas en niveles superiores de la arquitectura.

Existen varios tipos de arquitecturas híbridas, como lo veremos a detalle un poco más adelante, sin embargo, existen componentes comunes e inherentes que identifican al enfoque híbrido de entre los demás enfoques. Entre los componentes comunes que podemos mencionar se encuentran:

ƒ Planificador.- Genera el conjunto ordenado de comportamientos que se necesitan para completar una tarea.

ƒ Administrador de recursos.- Separa y aparta los recursos que solicitan tales comportamientos.

ƒ Manejador de mapas.- Dedicado a crear, almacenar y actualizar la información de los mapas del sistema.

ƒ Planeador.- encargado de la parte de interacción humano robot cuya finalidad es la de trasladar los comandos dirigidos hacia el robot, en términos que el robot pueda entender y generar la serie de pasos que llevarán al robot hacia la meta.

ƒ Detector y manejador de fallos.- Para integrar el aspecto de tolerancia a fallos dentro del sistema.

deliberativa de un sistema híbrido, en las siguientes secciones, mostraremos las tres variaciones arquitectónicas más importantes y un ejemplo de cada una de ellas.

2.5.4 Arquitecturas basadas en responsabilidades

La característica principal de este estilo arquitectónico radica en su descomposición de responsabilidades, la cual es similar a un estilo ejecutivo de negocios. En la parte superior de esta arquitectura, podemos encontrar la planeación de tareas de alto nivel, después pasa el plan hacia módulos “subordinados”, mismos que generan la planeación de recursos y envían las señales a los “trabajadores”, representando así a los comportamientos reactivos de bajo nivel.

Un ejemplo de esta arquitectura, es la arquitectura para robots autónomos, (AuRA, por sus siglas en inglés) [25]. AuRA consiste de cinco subsistemas; dos de esos subsistemas son los encargados de realizar la parte deliberativa, uno sirve como planeador y el otro como manejador de mapas, los subsistemas de motor y de sensores, son los encargados de realizar la parte reactiva, mientras un quinto subsistema, se encarga de transcribir los pasos enviados desde el planificador hacia los subsistemas reactivos siendo esta parte donde la arquitectura deja de ser deliberativa para dar paso a la ejecución reactiva. En la Figura 2.8, se muestra un esquema detallado del funcionamiento de AuRA.

Las arquitecturas basadas en responsabilidades tienen una marcada dependencia entre niveles, es decir, cuando un comportamiento no puede llevar a cabo su tarea, éste inmediatamente envía un mensaje al nivel inmediato superior, el cual es el encargado de manejar dicha petición.

Debido a este esquema, se genera una alta dependencia entre comportamientos localizados en los diferentes niveles, con lo cual, concluimos que se reduce la capacidad de autonomía entre procesos y el desarrollo de los comportamientos.

2.5.5 Arquitecturas basadas en estados

Este estilo, basa su estructura arquitectónica en un modelo de representación del conocimiento basado en el tiempo. Dicho en otras palabras, la arquitectura muestra un modelo de referencia en donde cada parte de ella se encarga de realizar procesos que tienen que ver con el pasado, presente y futuro.

Este modelo, como gran parte de los modelos híbridos, está basado en tres capas y la forma de organizar las tres capas es muy similar al enfoque basado en responsabilidades, con un diseño de arriba hacia abajo (top down) que establece que la planeación se realiza en la parte más alta de la arquitectura y pasa hacia las demás capas inferiores; dentro de ellas, existen funciones que realizarán las tareas adecuadas para poder cumplir con el plan establecido.

Un ejemplo de estilo de arquitectura, es la conocida como 3-Tiered o 3T [26], usada principalmente por la NASA (Nacional Aeronautic and Spacial Agency). Esta

Figura 2.9 Arquitectura 3T

hasta lograr llevar a cabo el objetivo aunque también necesita conocer la visión del presente y del pasado a través de un esquema de monitoreo, para formar su modelo del mundo.

En el modelo de estados, se denota claramente el enfoque de desarrollo basado en módulos, lo que facilita la propiedad de extensibilidad de la arquitectura. La integración entre procesos tiene una marcada característica temporal en el sentido que la capa de habilidades se maneja en tiempo presente, el secuenciador en tiempo pasado y el planeador en tiempo futuro. En la práctica, en la arquitectura 3T no se aplica un significado temporal a cada una de sus capas, más bien, se asocia un factor de velocidad de actualización para los procesos y es en base a este factor, como se define su ubicación dentro de la arquitectura, entre más rápido muestre ser el factor de actualización, el proceso se ubicará en un nivel mayormente reactivo; de manera contraria, mientras más lento demuestre ser un proceso, se ubicará en un nivel mayormente deliberativo.

El carácter reactivo de esta arquitectura ofrece un esquema de habilidades, siendo una de las principales aportaciones en el aspecto de programabilidad, el desarrollo de herramientas para realizar acoplamientos de conjuntos de habilidades.

2.5.6 Arquitecturas basadas en modelos

Hasta este punto, sólo hemos considerado arquitecturas híbridas cuya base se finca en el modelo reactivo (AuRA y 3T como vimos anteriormente) y que han surgido basadas en este paradigma. La diferencia más importante entre este estilo con los anteriores, radica en que se tiene un concepto de mundo global del entorno y los módulos de la arquitectura giran en torno a este modelo.

La arquitectura Saphira surge de la unión de tres características básicas que toda arquitectura para robots móviles debe presentar: coordinación, coherencia y comunicación. Como se puede observar en la Figura 2.10, los principales componentes de esta arquitectura son el módulo de percepción del mundo o LPS, y un sistema de razonamiento procedural (PRS, por sus siglas en inglés), mientras que los módulos de percepción y acción se ubican alrededor de estos dos componentes principales.

Figura 2.10 Arquitectura Saphira [27].

las rutinas de bajo nivel, respondan adecuadamente y se ajusten al plan para llegar a la meta.

Dentro de esta arquitectura, se introdujo el término de “artefacto”. Un artefacto es una representación interna de objetos o configuraciones de objetos. Los artefactos representan entidades geométricas que ayudan a ciertos comportamientos a realizar sus tareas. Esto lo podemos ejemplificar de la siguiente manera. Si un robot que navega a través de un corredor y sabe que está en un corredor porque las lecturas de sus sonares laterales así se lo marcan, entonces es probable que el robot encuentre una puerta abierta, donde el patrón ya no se ajuste a una línea recta como lo venía observando a través de sus sensores. En este punto, la línea recta se corta y el robot ya no detecta su ambiente como un corredor. La innovación de la idea de artefacto, es que existen a priori, un conjunto de artefactos definidos, de tal forma en que si el robot

detecta una ruptura repentina de su modelo, entonces se genera una hipótesis que propondrá un artefacto a utilizar. En el caso de ejemplo, se asumirá que el robot sigue estando en un corredor y se recurrirá a la hipótesis de la línea recta para darle continuidad a la tarea del robot.

Las actualizaciones de los artefactos en el LPS, están basadas en mecanismos de percepción del robot los cuales son confiables únicamente en distancias cortas. En este sentido, la coherencia es la propiedad de actualizar los artefactos dentro del LPS mientras el modelo de ambiente del robot se construye conforme a los movimientos ejecutados.

Finalmente, la comunicación, otro de los factores importantes considerados al inicio del análisis de esta arquitectura, se refiere a los mecanismos que utiliza para poder realizar la interacción humano-robot, tales como el reconocimiento y procesamiento de voz, gestos, seguimiento de personas, etc.

de la arquitectura Saphira, cuyo módulo de percepción del mundo (LPS) realiza todas las operaciones basados en un esquema deliberativo.

2.6 Arquitecturas de referencia

En la sección anterior, hemos recorrido algunos modelos arquitectónicos propuestos para entornos robóticos. Estas arquitecturas han sido probadas por diferentes universidades y centros de investigación en el mundo. Para el presente trabajo se analizaron diversas implementaciones y se decidió tomar como arquitecturas de referencia a dos modelos específicos. Ambos presentan un enfoque híbrido basado en capas, ambos han sido probados y presentan ventajas técnicas de diseño e implementación, como su facilidad de adaptarse a diferentes tipos de dominios de aplicación. El primer caso es el modelo arquitectónico de LAAS [28], en Francia; el segundo caso es la arquitectura del robot Homer [29], de la Universidad de British Columbia, de Vancouver, Canadá.

2.6.1 Arquitectura LAAS

La arquitectura propuesta por el Laboratory for Analisys and Architecture of Systems, de

Francia [28] se encamina a producir un modelo de trabajo bajo el esquema de código libre, otorgando una base funcional para el control general en robots. El software está diseñado para ser independiente de la plataforma, pero además es planteado como independiente de dominio. Uno de los puntos interesantes es que la arquitectura propuesta tiende hacia la integración de componentes de software. La Figura 2.11 nos

da una idea general de la implementación de esta arquitectura.

Entre las características relevantes que podemos mencionar de esta arquitectura, se encuentran:

• Orientación a objetos, como la base para formar librerías de clases (“módulos'').

• Enfoque hace una arquitectura de componentes, y no hacia una arquitectura de sistema.

Figura 2.11 Arquitectura del LAAS [28].

funciones de procesamiento y ciclos de control de hardware como el procesamiento de imágenes y el control de movimiento.

La arquitectura LAAS posee herramientas de desarrollo propias de su arquitectura para la elaboración de interfaces y módulos; utiliza variadas representaciones de datos, paradigmas de programación y requiere de especificaciones de tiempos de procesamiento para cada nivel. De esta forma el desarrollo de una aplicación utilizando esta arquitectura sería a la par de la utilización de su metodología y herramientas propias.

2.6.2 Arquitectura del Robot Homer

En la Universidad de British Columbia, en Vancouver, Canadá, se desarrolló un esquema arquitectónico híbrido, basado en capas para el funcionamiento del robot Homer [29]. Esta arquitectura, propone la utilización del término módulo en lugar del término comportamiento, donde un módulo es una unidad de software independiente enfocada a la resolución de un problema en particular, por ejemplo, el procesamiento de voz, detección de rostros, navegación, etc.

Tal como lo muestra la Figura 2.12, los módulos están organizados dentro de capas. La capa más baja es la que se encarga de manejar la interacción con el hardware del robot. La capa intermedia realiza diferentes funciones que pueden ser agrupadas en dos grandes grupos: movilidad e interacción humano robot. La comunicación entre esta capa y la capa de más bajo nivel, se lleva a cabo utilizando un esquema de memoria compartida.

Figura 2.12 Arquitectura de control del robot Homer [29].

Una de las características más importantes de esta arquitectura es que lo módulos pueden ejecutarse dentro de un ambiente distribuido, donde la ejecución puede llevarse a cabo en computadoras remotas utilizando como vehículo de comunicación sockets TCP.

Actualmente, esta arquitectura se encuentra en la fase de implementar coordinadores de alto nivel utilizando una técnica denominada MS-MDP’s (Multiply Sectioned Markov Decision Processes) [29], como un mecanismo de alto nivel para aumentar la eficiencia

en la especificación de tareas y la generación y ejecución de políticas.

Característica Arquitectura LAAS Arquitectura HOMER Arquitectura 3+

Integración Es una arquitectura dividida en módulos y utiliza patrones de software pero la tecnología de desarrollo de los módulos es propia y está ligada a la arquitectura de software. Si se quiere utilizar esta arquitectura, se tendrían que utilizar sus herramientas de desarrollo.

Esta arquitectura consiste en un conjunto de funciones encapsuladas que realizan diferentes tareas, como localización, navegación y detección de rostros. Para realizar nuevos componentes, sólo es necesario escribir y encapsular la nueva función por lo que se considera que tiene buena capacidad de integración.

Esta arquitectura nace precisamente de la necesidad de conjuntar proyectos elaborados en plataformas y lenguajes de programación diferentes. Estos proyectos se convirtieron en componentes integrantes de la arquitectura y se pueden usar como ejemplo para futuras implementaciones bajo esta arquitectura.

Reactividad Para cumplir con las especificaciones de reactividad, esta arquitectura soporta la aplicación de funciones síncronas y asíncronas a través de estructuras de datos llamadas “poster” generando con ello un paralelismo operativo.

La capacidad de reactividad de la arquitectura HOMER no se pudo determinar por carecer de información suficiente.

La parte de reactividad la proporciona mayormente el nivel funcional de la arquitectura. En la arquitectura 3+ se propone el uso de librerías del proyecto Player/Stage[1] garantizando de esta manera un buen nivel de reactividad.

Seguridad La seguridad se proporciona en el nivel de ejecución propio de esta arquitectura. Se implementa un módulo donde se controla el flujo de información desde y hacia las capas superiores e inferiores lo que garantiza que esa información sea consistente. La desventaja de este proceso es que genera un “cuello de botella”

en el flujo de información.

La seguridad en la arquitectura de HOMER no se encuentra garantizada dado que aún no presenta un mecanismo robusto para manejar posibles conflictos de recursos que se soliciten en determinadas circunstancias.

La implementación de un coordinador de fallos y de una base de datos de errores, coadyuvan a la seguridad y a la robustez del sistema arquitectónico.

Extensibilidad En este sentido, es relativamente fácil extender la arquitectura hacia diferentes dominios de aplicación. Los módulos ya existentes pueden ser reutilizados para otras plataformas. La desventaja es que el modelo no permite migrar ningún módulo hacia plataformas basadas en el sistema operativo Windows ya que solo trabaja bajo Linux y VxWorks.

La capacidad de expandir el dominio de aplicación de esta arquitectura radica en cambiar el valor de recompensa.

Una de las principales bondades que propone esta arquitectura, radica en la extensibilidad que proporciona el esquema de intercambio de mensajes entre los componentes. Para integrar un nuevo componente, el arquitecto solamente tendrá que definir el protocolo de comunicación y elaborar las posibles acciones dentro de la tabla de relación estado-acción.

Distribución

de tareas

No existe distribución de tareas en esta arquitectura. Cualquier implementación debe ser centralizada. No soporta procesos distribuidos en red.

La distribución de tareas se realiza a través de dispersar ciertas funciones a través de una red de área local. En HOMER, también se utiliza un arreglo de cuatro computadoras colocadas sobre el cuerpo del robot, apegándose más a un diseño de clúster que a un diseño de LAN.

Esta arquitectura propone un alto nivel de distribución de tareas, ya que permite distribuir, si así se considera conveniente, todos los componentes que la integran. De la misma manera, todos los componentes pudieran estar en una misma máquina, salvo que se cumplan las restricciones de recursos para todos y cada uno de ellos.

2.7 Conclusión del capítulo

Desde su definición, una arquitectura de software nos marca la pauta de organización y proporciona ideas de claridad y de armonía entre los componentes que conforman un sistema. En este capítulo se mostraron los principales enfoques arquitectónicos, partiendo de enfoques generales hasta enfoques arquitectónicos orientados hacia los sistemas robóticos móviles. De la misma manera, se expuso el estado del arte en este contexto representado por los desarrollos de LAAS y de la Universidad de British Columbia. Son varias las ventajas que ofrece el estudio y análisis de estas arquitecturas de referencia, entre las más importantes están los enfoques orientados a componentes y su carácter distribuido, así como la organización funcional en tres niveles o capas la cual es la organización mayormente adoptada para arquitecturas diseñadas para sistemas robóticos móviles.

Dentro de nuestra propuesta arquitectónica se contempla reutilizar en forma de componentes las aplicaciones elaboradas en el contexto de desarrollo de aplicaciones y se llevarán hacia servidores remotos aquellas que requieran de características de cómputo intensivo, como el procesamiento de video e imágenes.

Arquitectura 3+

C

APÍTULO

3

3 Arquitectura 3+

3.1 Introducción

En el capítulo anterior se trataron algunos enfoques arquitectónicos que van desde estilos arquitectónicos generales hasta arquitecturas específicas para entornos robóticos. Como pudimos observar, algunos enfoques satisfacen ciertos aspectos particulares de la lista de necesidades que detectamos como indispensables para catalogar una arquitectura como adaptable a entornos de robots móviles. Este estudio de enfoques, sirvió como referencia para el diseño de la arquitectura que más se acercaba a las necesidades de nuestro proyecto.

En el presente capítulo, abordaremos la arquitectura que denominamos 3+, un acrónimo de nuestra propuesta arquitectónica, que consta de tres capas – capa de decisión, capa de ejecución y capa funcional - las cuales coexisten bajo un ambiente distribuido, mismo que extiende el modelo hacia lo que denominamos como servicios robóticos. En los apartados siguientes, veremos más a detalle cada una de las partes que componen la arquitectura 3+.

3.2 Arquitectura del Sistema 3+

Figura 3.1.- Diagrama de la arquitectura 3+.

3.2.1 Capa funcional

Encargada de manejar el control reactivo del robot interactuando directamente con los sensores y actuadores a través de interfaces genéricas para dispositivos. Localizada en el nivel más bajo de la arquitectura, incluye todas las capacidades integradas con los sensores y actuadores del robot. Estas funciones de procesamiento y ciclos de control (procesamiento de imágenes de bajo nivel, control de movimiento, etc.) se encuentran encapsuladas en componentes comunicados entre sí.

3.2.2 Capa de ejecución