Arquitectura de software para un sistema robótico móvil

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS 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. Cuernavaca, Morelos, Enero de 2005..

(2) 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 Revisor de Tesis. ii.

(3) 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 actuadores con la finalidad de integrar un robot móvil de servicio. Las pruebas se realizaron utilizando una infraestructura distribuida y se usaron robots reales. Los resultados arrojaron que la arquitectura propuesta cumplió con los requerimientos asignados y las tareas se llevaron a cabo correctamente.. iii.

(4) 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.. Antonio Pacheco.. iv.

(5) 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!. José Antonio. v.

(6) Tabla de Contenido RESUMEN ___________________________________________________________ iii CAPÍTULO 1 __________________________________________________________ 1 Introducción __________________________________________________________ 1 1.1 Antecedentes ____________________________________________________ 1 1.2 Motivación ______________________________________________________ 3 1.3 Objetivos del proyecto ____________________________________________ 4 1.3.1 Objetivo General _____________________________________________________ 4 1.3.2 Objetivos Específicos _________________________________________________ 5. 1.4 Alcances y limitaciones____________________________________________ 5 1.5 Arquitectura propuesta ____________________________________________ 6 1.6 Estructura de la Tesis _____________________________________________ 8 CAPÍTULO 2 ________________________________________________________ 10 Arquitecturas de Software _____________________________________________ 10 2.1 Descripción del capítulo __________________________________________ 10 2.2 ¿Qué es una Arquitectura de Software? _____________________________ 10 2.3 Enfoques Arquitectónicos Generales _______________________________ 11 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7. Estilos Arquitectónicos. _______________________________________________ 11 Arquitectura cliente-servidor. ___________________________________________ 12 Arquitecturas orientadas a objetos. ______________________________________ 13 Arquitecturas Basadas en Componentes. _________________________________ 14 Arquitecturas orientadas a servicios. _____________________________________ 14 Arquitecturas en capas. _______________________________________________ 15 Arquitecturas de pizarrón. _____________________________________________ 17. 2.4 Necesidades particulares de una arquitectura en robótica móvil_________ 19 2.5 Enfoques arquitectónicos orientados hacia la robótica ________________ 20 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6. Arquitecturas deliberativas ____________________________________________ 20 Arquitecturas reactivas _______________________________________________ 22 Arquitecturas híbridas ________________________________________________ 24 Arquitecturas basadas en responsabilidades ______________________________ 26 Arquitecturas basadas en estados ______________________________________ 27 Arquitecturas basadas en modelos ______________________________________ 29. 2.6 Arquitecturas de referencia _______________________________________ 32 2.6.1 Arquitectura LAAS ___________________________________________________ 32 2.6.2 Arquitectura del Robot Homer __________________________________________ 34. 2.7 Conclusión del capítulo___________________________________________ 37 CAPÍTULO 3 ________________________________________________________ 38 Arquitectura 3+ _______________________________________________________ 38 3.1 Introducción ____________________________________________________ 38.

(7) 3.2 Arquitectura del Sistema 3+ _______________________________________ 38 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6. Capa funcional______________________________________________________ 39 Capa de ejecución ___________________________________________________ 39 Capa de decisión ____________________________________________________ 40 Arquitectura Extendida _______________________________________________ 41 Protocolo de comunicación ____________________________________________ 42 Estructura del protocolo de comunicación _________________________________ 43. 3.3 Tolerancia a Fallas _______________________________________________ 44 3.3.1 Coordinador de Fallas ________________________________________________ 47. 3.4 Ejemplo de Implementación de la Arquitectura 3+ _____________________ 49 3.4.1 3.4.2 3.4.3 3.4.4. Capa Funcional _____________________________________________________ 55 Capa de Ejecución __________________________________________________ 57 Capa de Decisión ___________________________________________________ 58 Necesidades de infraestructura física ____________________________________ 58. 3.5 Conclusión del capítulo___________________________________________ 63 CAPÍTULO 4 ________________________________________________________ 64 Implementación y Pruebas _____________________________________________ 64 4.1 Objetivos _______________________________________________________ 64 4.2 Evaluació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.1 Conclusiones ___________________________________________________ 72 5.2 Trabajo futuro ___________________________________________________ 74 Anexos _____________________________________________________________ 75 Anexo A ___________________________________________________________ 75 Player/Stage _______________________________________________________ 75 Anexo B___________________________________________________________ 77 Guía para el arquitecto de software ____________________________________ 77 Referencias __________________________________________________________ 79. vii.

(8) 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 --------------------------------------------------Figura 3.1 Diagrama de la arquitectura 3+ ---------------------------------------------------------------. 35 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 ---------------------------------------------Figura 3.5 Diagrama de estados ----------------------------------------------------------------------------. 48 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 ------------------------------------------------------------------------------Figura 3.9 Capa de decisión ---------------------------------------------------------------------------------. 57 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. Figura A.1 Arquitectura de Player --------------------------------------------------------------------------. 76. viii.

(9) Lista de Tablas Tabla 2.1 Elementos, relaciones y propiedades de la arquitectura cliente-servidor -----------Tabla 2.2 Interacción de las fases dentro del modelo SPA -------------------------------------------. 12. Tabla 2.3 Comparación de Arquitecturas -----------------------------------------------------------------. 36. 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 ----------------------------------------------------------. 51. Tabla 3.4 Tabla de estado: Estado/Acción ----------------------------------------------------------------. 52. 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 --------------------------------------------------. 60. Tabla 3.7 Interfaces para el componente de planeación ----------------------------------------------. 60. Tabla 3.8. Interfaz de comunicación con el componente localización ------------------------------. 61. Tabla 3.9. Interfaz de comunicación con el componente coordinador ------------------------------. 61. Tabla 3.10 Interfaz de comunicación para el componente PDA --------------------------------------. 62. 21. Tabla 4.1 Los estados observados y las acciones tomadas por los coordinadores durante la ejecución de una tarea ----------------------------------------------------------------------------------------. 70. ix.

(10) 1. CAPÍTULO 1 Introducción 1.1 Antecedentes. Introducción. 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.. •. Laboratorio virtual de robótica.. 1.

(11) Introducción. •. 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.. Otra área de la robótica que en los últimos años ha ido creciendo consistentemente es la aplicación de robots de servicio. En la actualidad no existe una definición universal de robot de servicio. A la espera de un acuerdo sobre la misma, la IFR (Internacional Federation of Robotics) ha adoptado la siguiente definición provisional: "Robot de servicio es un robot que opera de forma parcial o totalmente autónoma para realizar servicios útiles para el bienestar de los humanos o sistemas de automatización, excluyendo operaciones de manufactura" [3]. Con esta definición, que tendrá que ir siendo afinada con el tiempo, los robots industriales manipuladores pueden ser considerados robots de servicio si están dedicados a operaciones diferentes de la manufactura.. 2.

(12) Introducción. 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).. Dados los esfuerzos y líneas de investigación anteriormente expuestos y la necesidad de integrar estos elementos dentro de una arquitectura de software, la meta principal de aplicación de la cátedra de robótica móvil, es poder construir un robot de servicio que sirva de anfitrión dentro del campus, que sea capaz de proveer información acerca de. 3.

(13) Introducción. 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 El objetivo de esta Tesis es definir, especificar y probar un modelo arquitectónico para un sistema robótico móvil. Dentro de este modelo, se definirán los servicios y aplicaciones que serán los componentes fundamentales de la arquitectura. Se considera otorgar un sentido de extensión de la arquitectura 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 toma en cuenta el aspecto de tolerancia a fallas,. 4.

(14) Introducción. 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). La integración de los componentes arriba mencionados, definirá la validez de la arquitectura y dejará sentadas las bases para posteriores integraciones conforme se vayan finalizando las aplicaciones que serán convertidas en componentes (e.g. visión, procesamiento de voz, ademanes, etc.). 5.

(15) Introducción. 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.. Figura 1.2 Diagrama de la arquitectura propuesta en su sentido abstracto.. 6.

(16) Introducción. 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.. El componente de navegación fue ubicado dentro de una computadora con sistema operativo Linux utilizando la distribución de Fedora Core 2. El componente de planeación de trayectorias y el de localización fueron colocados en una sola computadora. con sistema operativo Windows XP. La PDA ejecutaba a su vez el. sistema operativo Windows CE. Las pruebas se realizaron con un robot Pioneer 2AT de la compañía constructora ActiveMedia.. En la Figura 1.3 se detalla el ejemplo de. implementación de la arquitectura.. 7.

(17) Introducción. 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 presente capítulo se incluye la introducción y la motivación de la que surge la presente tesis. Lo que se pretende es dar una idea general del contenido y la propuesta de una arquitectura de software para sistemas robóticos móviles.. 8.

(18) Introducció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.. Por último, se incluye el listado de las referencias utilizadas en la elaboración del presente trabajo.. 9.

(19) Arquitecturas de Software. 2. CAPÍTULO. Arquitecturas 2 Arquitecturas de Software. 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. El desarrollo basado en componentes, se encuentra en constante evolución. En particular, dicha evolución se presenta desde dos frentes diferentes. Por un lado, se. 10.

(20) Arquitecturas de Software. 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. Desde los inicios de la arquitectura de software, se observaron ciertas regularidades de configuración que aparecían una y otra vez al momento de diseñar e implementar una arquitectura de software. Muy pronto, a esas regularidades se las llamó estilos, por analogía con el uso del término en arquitectura de edificios. Un estilo describe entonces una clase de arquitectura, o piezas claramente identificables de las arquitecturas. Una vez que se han identificado los estilos, es lógico y natural pensar en reutilizarlos en situaciones semejantes que se presenten en el futuro [12]. Igual que los patrones de arquitectura y diseño, todos los estilos tienen un nombre: cliente-servidor, modelo-vistacontrolador, tubería-filtros, arquitectura en capas, entre otros.. 11.

(21) Arquitecturas de Software. 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. Relaciones. Propiedades. 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. 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. 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.. Tabla 2.1 Elementos, relaciones y propiedades de la arquitectura cliente-servidor.. El ejemplo más representativo de esta arquitectura es Internet. En una típica transacción, un cliente accede a la información de un servidor Web a través de un protocolo de transferencia de hipertexto (HTTP, por sus siglas en inglés). Una conexión HTTP entre un cliente y un servidor termina después de cada respuesta por parte del servidor. Por ejemplo, cuando un cliente origina una petición a un servidor solicitando una página Web, el cliente envía al servidor la especificación del método utilizado por la solicitud y las propiedades del cliente, como el nombre del usuario, tipo de navegador que utiliza y el tipo de documentos que soporta. El servidor, una vez que conoce estas propiedades del cliente, envía los datos solicitados en un formato que el clienta pueda entender. Inmediatamente después de este envío, el servidor termina la conexión. En la Figura 2.1 se muestra un diagrama de la arquitectura cliente-servidor.. 12.

(22) Arquitecturas de Software. 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.. Para mencionar algunas de las características de las arquitecturas OO (Orientadas a Objetos), se podría decir que los componentes de este estilo se basan en principios del paradigma de la POO (Programación Orientada a Objetos): encapsulamiento, herencia y polimorfismo. En este estilo, las interfaces están separadas de las implementaciones. En general, la distribución de objetos es transparente, y en el estado de arte de esta. 13.

(23) Arquitecturas de Software. 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 (ComponentBased 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 (Service Oriented 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 mensajes basados en XML, transmitido sobre HTTP , pero que también pueden ser los protocolos HTTPS, SMTP, FTP o casi cualquier otro. También se. pueden incluir. prestaciones sofisticadas de última generación como WS-Routing, WS-Attachment, WSReferral, etc. [17]. 14.

(24) Arquitecturas de Software. 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. Los sistemas o arquitecturas en capas constituyen uno de los enfoques que aparecen con mayor frecuencia mencionados en la estructura de estilos arquitectónicos. En [15] Garlan y Shaw definen el estilo en capas como una organización jerárquica tal que cada capa proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le brinda la inmediatamente inferior. En algunos ejemplos, las capas internas están ocultas a todas las demás, menos para las capas externas adyacentes, y. 15.

(25) Arquitecturas de Software. 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.. Casos representativos de este estilo se encuentran principalmente en los protocolos de comunicación en capas donde cada capa proporciona un mecanismo para la comunicación hacia los demás niveles, mientras que los niveles más bajos suelen estar asociados con conexiones de hardware. El ejemplo más característico es el modelo OSI de ISO [20], con los siete niveles que especifica este modelo: nivel físico, vínculo de. 16.

(26) Arquitecturas de Software. 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.. Este estilo se ha sido utilizado en aplicaciones que requieren complejas interpretaciones de proceso de señales (reconocimiento de patrones, reconocimiento de habla, etc.), o en sistemas que involucran acceso compartido a datos con agentes débilmente acoplados. También se han implementado estilos de este tipo en procesos en lotes de base de datos y ambientes de programación organizados como colecciones de herramientas en torno a un repositorio común.. 17.

(27) Arquitecturas de Software. 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.. Al comienzo del proceso de resolución, se establece el problema en el pizarrón. Las fuentes tratan de resolverlo cambiando el estado. La única forma en que se comunican entre sí es a través del pizarrón. Finalmente, si de la cooperación resulta una solución adecuada, ésta aparece en la pizarra como paso final.. 18.

(28) Arquitecturas de Software. 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.. . Distribución de tareas: poder emplear un sistema distribuido o centralizado según las necesidades.. 19.

(29) Arquitecturas de Software. 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.4. Shakey, el primer robot móvil que podía “pensar” y respondía a su entorno.. En la Figura 2.5, se muestra el ordenamiento secuencial propio del paradigma deliberativo.. 20.

(30) Arquitecturas de Software. 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.. La ventaja principal de este paradigma es que otorga un orden que deja claramente establecida la relación de las tareas de percepción, planeación y acción. La principal desventaja de este paradigma fue la planeación. En cada iteración del modelo SPA, el robot actualiza el estado global del mundo y lleva a cabo algún tipo de planeación. La. 21.

(31) Arquitecturas de Software. 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 reactivodeliberativas), un enfoque de gran aceptación dentro de los paradigmas robóticos. Se puede considerar a las arquitecturas reactivas como un enfoque diferente al que propone el paradigma deliberativo, en el sentido de que las tareas se realizan con una descomposición vertical en lugar de seguir una descomposición de tareas en forma horizontal, tal como se muestra en las figuras 2.6 y 2.7. Este ordenamiento verticalizado de tareas, se debe principalmente. a sugerencias de la literatura etológica, la cual. propone que la inteligencia está organizada de forma vertical; analógicamente con los seres vivos, un agente comienza con un comportamiento primitivo de supervivencia, a partir de los cuales, comportamientos más avanzados van siendo establecidos de forma paralela. Estos comportamientos, son ordenados de una forma paralela y vertical. de esta manera, si algún comportamiento de alto nivel sufre algún tipo de falla, los comportamientos de bajo nivel, aún seguirán funcionando correctamente. Un ejemplo. 22.

(32) Arquitecturas de Software. 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 SensaPlanea-Actua, sino que solamente basa su metodología en Sensa-Actua. Una de las arquitecturas más representativas de este enfoque, es la llamada arquitectura de subsumisión propuesta por Rodney Brooks [5] En esta arquitectura los. 23.

(33) Arquitecturas de Software. 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. Actualmente se considera al enfoque híbrido como la mejor solución dentro de las arquitecturas robóticas, debido a muchas razones, entre las que podemos mencionar:. 24.

(34) Arquitecturas de Software. . 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.. El modelo de arquitectura híbrida posee los elementos comunes arriba mencionados, pero existen variaciones al momento de realizar la implementación de la parte. 25.

(35) Arquitecturas de Software. 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.. Figura 2.8 Esquema de la Arquitectura AuRA [25].. 26.

(36) Arquitecturas de Software. 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 arquitectura cuenta con tres capas las cuales representan el aspecto deliberativo, la planeación reactiva y el control reactivo, como se puede observar en la Figura 2.9.. 27.

(37) Arquitecturas de Software. Figura 2.9 Arquitectura 3T La capa denominada habilidades, está compuesta por habilidades (una habilidad, es similar a un comportamiento dentro de la arquitectura de subsumisión) manejadas bajo el esquema de agentes que operaran en tiempo presente. Los componentes dentro del secuenciador operan utilizando memoria de secuenciación, es decir, el secuenciador obtiene nociones del pasado y de las tareas que el robot ha realizado con anterioridad, aunque también interactúa directamente con las condiciones del presente. Por último, el planeador se encarga de predecir el futuro, estableciendo los planes y tareas a realizar. 28.

(38) Arquitecturas de Software. 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 planeación deliberativa y la acción reactiva, tienen una diferente forma de coexistir en este modelo. Mientras que en los otros sistemas híbridos, que crean el modelo del mundo en forma totalmente paralela a los comportamientos reactivos, el mundo global en este enfoque permite realizar entradas hacia comportamientos reactivos, introduciendo de esta manera el concepto de “sensor virtual”. Una de las arquitecturas más representativas de este enfoque es Saphira [27] .. 29.

(39) Arquitecturas de Software. 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].. En la Figura 2.11, las rutinas de percepción se encuentran a la izquierda y las rutinas de acción se ubican hacia la derecha. La coordinación del control de esta arquitectura, está a cargo del PRS, el cual es capaz de procesar comandos en lenguaje natural y transformarlos en una secuencia operativa de pasos que involucran desde las tareas de navegación hasta las rutinas para activar los sensores. Visto de otra forma, hacer que. 30.

(40) Arquitecturas de Software. 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.. Este enfoque arquitectónico basado en modelos satisface las necesidades que las arquitecturas para robots móviles deben tener, aunque dejan un poco de lado los enfoques arquitectónicos tradicionales en el sentido de que no manejan una estructura definida en capas y se basan más bien en un esquema centralizado, como es el caso. 31.