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'').
• Patrones de Software, dado que esta propuesta hace uso y rediseña patrones existentes, se evita perder tiempo en la generación de nuevos diseños o reingeniería de malos diseños.
• Enfoque hace una arquitectura de componentes, y no hacia una arquitectura de sistema.
Figura 2.11 Arquitectura del LAAS [28].
En la arquitectura LAAS, el nivel de decisión es el responsable de supervisar los planes o procedimientos de ejecución al mismo tiempo que se encarga de reportar el estado que guardan esos planes a un operador. En este nivel se incluyen las capacidades deliberativas de la arquitectura como la producción de planes y de tareas, razonamiento, aprendizaje, etc. El nivel de ejecución funciona como un procesador de peticiones y respuestas que son enviadas desde el nivel de decisión hasta el nivel funcional. El nivel de ejecución actúa como filtro de esas peticiones que son enviadas desde el nivel de decisión al nivel funcional habilitando o deshabilitando peticiones de acuerdo al estado de carga del sistema. Por último, en el nivel funcional se incluyen todas las características básicas de percepción y movimiento encapsuladas en
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.
Dentro de estos dos grupos que existen en la capa intermedia, interactúan los módulos que realizan las tareas correspondientes para llevar a cabo la misión o plan. Éste es entregado por la sección de más alto nivel a través de un módulo de planeación, el cual es alimentado a través de un manejador encargado de traducir las salidas de los módulos, en entradas para el planeador; estas entradas representan el modelo del mundo.
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.
En la tabla 2.3 se describe una comparación de nuestra arquitectura respecto a las arquitecturas de referencia tomando como puntos de evaluación los mencionados en la sección 2.4.
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.