APLICACIÓN DE LA PLANIFICACIÓN ABSTRACTA EN LOS SISTEMAS DE ROBOTS AUTÓNOMOS

1.     Introducción

Los robots móviles autónomos se han estado desarrollando con el objetivo de llevar a cabo tareas complejas en diferentes ambientes, tanto en hábitats humanos como lugares menos amigables, tales como planetas distantes y regiones bajo el agua. 

Para entornos interiores, se proyecta la posibilidad de crear robots móviles autónomos que lleven a cabo tareas solicitadas por los residentes de un edificio o los trabajadores de una planta, tales como: la entrega de correo, guiar visitantes, ir a buscar café, recoger una impresión, o simplemente entregar un mensaje u objeto de un lugar a otro.

En este trabajo se presenta una primera aproximación a la situación planteada donde se centrará la atención en la planificación de tareas, como el nivel superior de abstracción del sistema. Esta abstracción se hace necesaria dado que el uso de planes de muy bajo nivel implicaría ejecutar varios cientos de pasos para resolver cierto problema de navegación donde el espacio de planes de esta magnitud sería tan grande que aun las técnicas de planificación más sofisticadas probablemente no llegarían a una solución en una cantidad razonable de tiempo.

Se presenta a continuación la arquitectura del sistema que integra una capa de planificación de tareas, una capa de planificación de movimientos y por último el ejecutor, que para este caso es un robot lego NXT.

A grandes rasgos el funcionamiento se resume en 4 pasos:

·         El usuario ingresa la descripción del mundo accediendo a la interfaz gráfica
      El usuario especifica los objetivos que debe llevar a cabo el robot

·         El programa genera los archivos Domain.PDDL y Problem.PDDL

·         El planificador arroja una solución, para cumplir los objetivos minimizando la distancia recorrida

·         El programa captura dicha solución y se comunica con la aplicación AppCells para que esta se encargue de ejecutar cada uno de los pasos planteados en el plan.

2.     Descripción del mundo

Se implemento una sección en la que el usuario pueda describir el entorno en el cual trabajará el robot, para ello se consideraron tres aspectos principales:


La inclusión de las áreas.
La inclusión de puntos de conexión entre áreas
La inclusión de los obstáculos al interior de las áreas. 

Un área queda completamente determinada especificando:

• el punto del extremo superior izquierdo y el extremo inferior derecho, en un plano coordenado (x,y)

Para la especificación de los puntos de conexión entre áreas se requiere de:

• la dupla de áreas conectadas
• la ubicación del punto de conexión, en el mismo plano coordenado (x,y)

 

La inclusión de los obstáculos hace parte de la última etapa, donde se hace necesario especificar:

• El área donde está ubicado
• Los nodos, es decir puntos (x,y) que determinan el obstáculo.

3.Creación del Domain.PDDL y  Problem.PDDL

A esta instancia el robot tiene conocimiento del entorno de trabajo pero aún no se asignan las tareas para empezar un proceso de planificación.

El estandar para llevar a cabo dicho procedimiento es dividir la información en dos archivos que recibe el planificador LPG  como entradas, que consisten de un dominio y un problema, en el dominio se establece el conjunto de estados y el conjunto de acciones, por lo que es estático, es decir, no varía con un problema u otro.

Por otro lado el problema hace referencia a un caso específico y en él está contenida toda la información correspondiente al estado inicial y el estado final.

Con el fin de ilustrar la aplicabilidad de la planificación de tareas a un problema de navegación cotidiano se presenta un mapa que puede corresponder a la distribución de un espacio de trabajo, posteriormente la especificación del dominio y el problema  representarán dicho espacio.

Suponga un espacio distribuido como el de la figura, en él se encuentran 6 áreas, con conexiones definidas solo entre algunas de ellas, además de la inclusión de obstáculos en las áreas 1, 3, 5 y 6.

El proceso de composición del dominio no requiere mayores esfuerzos, se definirán los tipos de objetos que se pueden crear que son: sitio y robot, las funciones recorrido, para almacenar la distancia recorrida por el robot y la función distancia, para almacenar el costo del viaje de un área a otra.

Se crearán además predicados para denotar la ubicación actual del robot, marcar un área como visitada y puntualizar  la existencia de una conexión entre áreas. Por último se creará la acción viajar, que le permitirá al robot desplazarse, siempre y cuando se cumplan la restricciones planteadas.

Usando la sintaxis PDDL el archivo Domain tiene la siguiente forma.

Por otro lado la composición del Problem se convierte en la traducción de la información ingresada por el usuario a la sintaxis PDDL, se puede notar que se crearon 6 objetos de tipo sitio y un objeto de tipo robot.

Se procede a definir los términos en los que se encuentra el estado inicial, definiendo: ubicación inicial, conexiones entre áreas y distancia entre las mismas.

Consecuentemente son agregadas las condiciones del estado final, es decir los objetivos, que consisten para este caso en visitar las 6 áreas definidas y por último se establece una métrica, la cual tiene la finalidad de determinar la calidad de un plan respecto a la minimización del recorrido.

Usando la sintaxis PDDL el archivo Problem tiene la forma expuesta en el siguiente codigo

5.     Proceso de planificación Abstracta

El problema descrito anteriormente solo contiene seis salas dado que por cuestiones de espacio tener un problema más grande supone un archivo muy extenso para presentar en este artículo, en la práctica, la utilidad de este proceso muestra sus bondades con una situación de quince áreas o más, donde no es siquiera apreciable una solución observando un mapa o la descripción del mundo.

La ejecución del planificador bajo el Domain y Problem descrito anteriormente presenta una solución como se muestra en la siguiente imagen:

6.     Proceso de planificación de movimientos

Para la ejecución del plan se procede a leer el archivo generado por el planificador, extrayendo la información necesaria para componer un archivo .txt que sea interpretable por la aplicación appcells.

El archivo generado deberá estar compuesto por:

è El punto inicial y el punto final

è Dos puntos que determinan la margen del entorno de trabajo

è Cantidad de obstáculos

è Nodos por cada obstáculo

è Nodos del obstáculo

Como se muestra en la siguiente imagen:  

AppCells comprenderá cada uno de estos archivos como una instrucción y procederá a encontrar la ruta al interior de la sala que le permita viajar del punto inicial al punto final evitando los obstáculos, en la siguiente imagen se presenta el mapa generado, incluidos los obstáculos y los puntos inicial y final.

El programa para cumplir el objetivo, tal y como se plantea en el dibujo es enviado al robot lego NXT usando el protocolo Bluetooth.

Para este propósito, el procedimiento fue crear un “NXT Project” y el main se corre como : “LeJOS NXT program”.

7.     Conclusiones

Los resultados de la planificación para estos entornos ha resultado ser satisfactoria en el sentido de que siempre retornará una solución si esta existe, y el proceso asegura entregar la mejor de ellas para la ejecución.

Dado que el proceso de planificación será ejecutado por un computador y luego son enviadas  instrucciones específicas al robot, el costo computacional puede elevarse conforme crezcan las dimensiones del problema disponiendo solo de las capacidades del computador, que para estas aplicaciones es bastante aceptable.

Aunque la planificación abstracta propone un modelo muy ideal, el planificador de movimientos AppCells debe lidiar con aspectos del entorno que afectan el desempeño, estos son debidamente tomados en consideración por un módulo de corrección de errores, pero su exactitud absoluta no se puede asegurar, por lo que asignarle al robot un plan extenso, supone acumulación de errores y una diferencia considerable entre la trayectoria teórica y la real.

Los avances en el campo de la visión artificial serian de gran utilidad en un sistema autónomo como el que aquí se expone, dado que puede dotar al robot de una visualización del entorno en tiempo real, haciéndolo tolerante a ambientes dinámicos.

Escrito por: Andrés Felipe Gutiérrez Salazar. Grupo SINTELWEB. Universidad Nacional de Colombia Sede Medellín.

Experiencia en la integración de sensores para la estimación de la posición de un robot móvil en la ejecución del algoritmo Dist-Bug.

En este trabajo se realiza la integración de sensores   para disminuir el error en la  estimación de la posición de un robot móvil teniendo en cuenta su geometría, el robot móvil  en este caso el LEGO Mindstorm NXT 2.0  ejecuta el algoritmo DistBug para la construcción de rutas de navegación.  El propósito de esta integración, consiste en que el robot tenga una ubicación más precisa mientras construye una ruta de navegación en tiempo real y libre de colisiones, que lo lleve desde un punto inicial a un punto final considerando la geometría del robot, mientras percibe la información del mundo, el cual asume como incierto, excepto su posición inicial y su posición de final. Para esta tarea, el robot  utiliza sensores de sonar como elemento de detección a fin de  identificar la distribución de los obstáculos y el sensor de compass para identificar la dirección de la posición actual del robot mediante la estimación de la posición relativa, bajo estos parámetros comparar el error que se ha generado al utilizar o no estos sensores sobre la localización en el espacio.

En esta aplicación  el algoritmo DistBug se muestra con un modelo geométrico claro que permita seguir el comportamiento de este algoritmo, dejando claro que el robot tiene una geometría y que ya no es un punto como se establece en trabajos anteriores. 

Geometría del Robot

Para aplicar cualquiera de los sensores se debe conocer como utilizarlo y cuales son sus características técnicas ya que  la gran mayoría de los sensores se deben calibrar para obtener una medida o un dato mas preciso porque de eso también depende el manejo de la incertidumbre o el error en la localización. 

Calibración sensor de sonar

Calibración del sensor de compas (Brújula)




Análisis de Resultados

Para iniciar el análisis de resultados primero se creó un modelo ideal de la ruta del algoritmo DistBug, para tener criterio de una baja incertidumbre y poder hacer el comparativo entre todos los resultados. Fig.1 y Tabla.1. 

Fig.1.

Tabla.1.

Los resultados que se obtienen a través de las pruebas realizadas se ilustran en las tablas de datos. En primer lugar se  analiza los datos obtenidos de la tabla.2, Con respecto a la tabla.1, se revisa la desviación estándar entre  estas y se obtiene una gran diferencia en relación con los puntos obtenidos, verificando que existe incertidumbre y que es necesario aplicar o integrar otro método de estimación de la posición como solución  para disminuir la incertidumbre, sin embargo aunque es bajo el error se demuestra que se ha incrementado por la misma rotación de las ruedas.

Tabla.2.

Luego para el análisis de resultados de la tabla.2, y la tabla.3, se muestra que hay una diferencia  entre las incertidumbres ya que la comparación se hace entre los datos adquiridos por un solo método de localización como es el de odometria que sugiere que se le aplique otro método de localización para mejorar y disminuir esa diferencia, al observar la tabla.3,

Tabla.3.

se muestra que hay una incertidumbre menor que la de la tabla.2, ya que en esta se utilizó dos métodos de localización y por lo tanto mejora los resultados obtenidos.    

Finalmente se debe comparar los resultados obtenidos entre el modelo ideal y el modelo de fusión de datos, en este se aprecia que hay una diferencia menor del error entre los datos por lo que se considera que son resultados esperados y que muestran que es necesario integrar varios métodos de localización para llegar a un modelo ideal en la estimación de la posición. Fig.2.

Fig.2.

Teniendo en cuenta los resultados obtenidos, la desviación estándar muestra que el error es significativo si no se hace una fusión de datos, por lo tanto las rutas generadas por la información adquirida no  será confiable  y más aún en un mundo real se presentara colisiones entre el robot móvil y obstáculos por lo que es obligatorio la inclusión de nuevos sensores en los robots para obtener un mejor resultado en ubicación o localización en el espacio.

Lo siguiente indica que los errores en la rotación se incrementan si solo dependen de pocos sensores. Fig.3.

Fig.3.

Esto se demuestra por la orientación que tiene el error debido al desplazamiento del robot móvil, que las ruedas son un factor importante en la localización por lo que existirá un error constante si no se realiza una fusión de datos más amplia ósea se incluyan más sensores para mejorar la estimación de la posición relativa.  

Conclusiones

• Se debe tener en cuenta los dos tipos de errores como los son los errores sistemáticos y no sistemáticos para la localización de un robot móvil. Esto se tiene solo en cuenta en modelos reales con obstáculos donde todo tiene incertidumbre y lo cual genera estimadores de posición muy poco confiables por lo que es necesario la inclusión de nuevos sensores para tener otros sistemas de referencia que puedan disminuir la incertidumbre o el error en la ubicación del robot móvil en el espacio.

• Existirá por más sensores o métodos de localización integrados o fusionados siempre un error sistemático y no sistemático, que no se puede manejar pero si disminuir, por lo anterior se puede definir que la estimación de la posición es un tema muy amplio para tratar y no es fácil de implementarlo debido a las diferentes variables que afectan el mundo real.

• Bajo este criterio se indica que un trabajo futuro debe enfocarse más en elaborar un estudio más detallado de las variables que afectan  robot en su desplazamiento, teniendo en cuenta que estas variables son errores  los cuales, se les debe brindar una solución adecuada para optimizar esa ruta generada. 

 En el siguiente video veremos el Algoritmo DistBug en ejecución con la integración de lo hablado anteriormente: 

Escrito por: Diego Fernando Marquez Betancur. Grupo SINTELWEB. Universidad Nacional de Colombia Sede Medellín.

Conectar un Robot NXT y un PC vía Bluetooth usando Icommand

1.    Primero tenemos que descargar icommand:

                      http://sourceforge.net/projects/nxtcommand/files/

                      http://code.google.com/p/bluecove/downloads/list

 

2.   Creamos un nuevo proyecto de JAVA en este caso usaremos  Netbeans:

 3.   Agregamos al proyecto los archivos icommand.jar y bluecove.jar, Para esto le damos click    derecho al proyecto >> “Properties”  >> “Libraries” >> “Add JAR/Folder” y Buscamos los dos archivos jar.

4.     En la carpeta del icommand.jar hay un archivo llamado "icommand.properties". Este es el archivo que tiene la configuración del la conexión del NXT con el PC. Lo Abrimos y cambiamos los valores de "nxt.btaddress" y  "nxtcomm".

 Conectamos via bluetooth el PC con el Robot NXT.  No importa si falla la conexión, lo que importa es que el PC reconozca el NXT. se veran algo asi:

 

Para  ENCONTRAR nuestro nxt.btaddress y nxtcomm:

           Buscamos los dispositivos bluetooth. y buscamos nuestro NXT le damos click derecho >> "Propiedades". 

En la pestaña "Bluetooth" y encontramos el campo que dice "Identificador único" ese es nuestro nxt.btaddress. (Ejemplo: 00:16:53:10:fb:46 )

                  

En la pestaña "Servicios" encontramos los puertos y el Puerto que diga "DEV B" sera nuestro nxtcomm. (Ejemplo: COM 75)

   

 Borramos todo lo que tenga el icommand.properties y escribimos lo siguiente.

 nxtcomm.type=bluecove
 nxtcomm.type=sun
 nxtcomm=COM79

 nxt.btaddress=00:16:53:10:fb:46

Listo, Ya solo falta agregar la libreria en java "import icommand.nxt.comm.NXTCommand;" y en el Main agregar la siguiente instrucción   "NXTCommand.open();" 


EJEMPLO:

Si saca error verifica la ruta del "icommand.properties" y rectifica si quedo bien escrito, Porque a veces el icommand crea su propiedades en otra carpeta. 

LISTO, YA SE CONTROLA EL  NXT  POR BLUETOOTH. Explora la API de Icommand para ver los diferentes usos que puede generar.


http://lejos.sourceforge.net/p_technologies/nxt/icommand/api/index.htmlhttp://lejos.sourceforge.net/p_technologies/nxt/icommand/api/index.html

 

       

Generación de Trayectorias con Mapas de Visibilidad y Comparación entre los Algoritmos genético y Dijkstra en la Búsqueda de la Ruta Óptima

Pruebas de Descomposición Exacta y Adaptativa para la Navegación de Robots Móviles

Se implementó, con ayuda de Jeferson David Ossa, las técnicas de descomposición de celdas exacta y adaptativa (o aproximada) [1][2][3][4][5], para planificación de movimientos en la navegación de robots móviles, que consideran un mundo cerrado, estático y conocido. La siguiente es la arquitectura propuesta.

Los planificadores suelen considerar al robot como un punto, lo cual es irreal. Una de las soluciones (aunque no es exacta), es agrandar todos los obstáculos con respecto al radio del robot.

Teniendo a un robot móvil tipo diferencial con las siguientes dimensiones:

En las pruebas realizadas se compararon las dos técnicas implementadas en dos diferentes escenarios (uno de ellos se puede apreciar en la siguiente figura).

Adicionalmente, en cada escenario, se realizaron dos pruebas distintas, una en la que el robot pudiera pasar exactamente (según la implementación) a través del espacio que dejaban los dos obstáculos entre sí, y otra donde el robot, a pesar de que sí pudiera pasar con cierta configuración, le tocara dar una vuelta alrededor de algún obstáculo.  Así pues, se hicieron cuatro pruebas para cada uno de los dos algoritmos. Las secuencias de puntos generadas por los planificadores se pueden apreciar a continuación.

Escenario 1. Descomposición adaptativa con trayectoria ineficiente

Escenario 1. Descomposición adaptativa con trayectoria eficiente

Escenario 2. Descomposición adaptativa con trayectoria ineficiente

Escenario 2. Descomposición adaptativa con trayectoria eficiente 

Escenario 1. Descomposición exacta con trayectoria ineficiente

Escenario1. Descomposición exacta con trayectoria eficiente

Escenerio 2. Descomposición exacta con trayectoria ineficiente

Escenario 2. Descomposición exacta con trayectoria eficiente

A continuación, se puede apreciar un video de algunas de estas pruebas, las cuales, en promedio, arrojaron un error del 3,4% como se ve en la siguiente tabla.

[1]     Jean-Claude Latombe, Robot Motion Planning. Kluwer Academic Publishers, 1991.

[2]     H. Choset, et al., Principles of Robot Motion: Theory, Algorithms, and Implementations. Boston: MIT Press, 2005.

[3]     S. LaValle, Planning Algorithms. Cambridge: Cambridge University Press, 2006.

[4]     Roland Siegwart, Illah R. Nourbakhsh, Introduction to Autonomous Mobile Robots. The MIT Press, 2004.

[5]     Robin R. Murphy, Introduction to AI Robotics. Massachussetts: The MIT Press 2000.

Arquitectura Subsumption

Creación y Aplicación de la Arquitectura Subsumption Orientada a Comportamientos, para controlar un robot Lego NXT bajo el ambiente Java-LeJOS

 

Algunas Arquitecturas Orientadas a comportamientos:

Basada en esquemas:

Permite que cada elemento pueda ser instanciado o finalizado en cualquier momento, de acuerdo con la tarea a realizar y el estado del entorno, lo que dota a la arquitectura con una capacidad importante. Cada comportamiento es implementado como un conjunto de esquemas. Ver mas...

Redes de  activación:

En esta arquitectura, un agente es visto como un conjunto de competencias (comportamientos) módulos, y la selección de acciones se modela como una propiedad emergente de una dinámica de activación / inhibición entre estos módulos. El método de coordinación es competitivo, un solo módulo puede estar activo en cualquier momento. Ver mas...

Distribuida para navegación móvil:

Incluye un modulo de coordinación basado en votación. Cada comportamiento arroja un número de votos a favor o en contra de un conjunto predefinido de acciones. Los comportamientos tienen un peso asignado. La acción con más votos se selecciona y los actuadores se ajustan convenientemente. Cada grado de libertad (es decir, de giro y velocidad) tiene su propio árbitro, lo que aumenta la modularidad. Ver mas...

Acerca de la Arquitectura Subsumption: 

Rodney Brooks desarrolló la arquitectura Subsumption. La arquitectura Subsumption se presentó en 1986 en el documento "A Robust Layered Control System for a Mobile Robot”. La idea era conectar directamente la percepción y la acción, descartando los modelos internos. El controlador debe ser descompuesto de forma simultánea y asíncrona en capas orientados a tareas, capas que trabajan en distintos objetivos (caminar, evitar los obstáculos, etc.).

Componentes de la Arquitectura Subsumption:

• Comportamientos o capas: Para implementar un algoritmo de control para un robot usando la arquitectura subsumption, se debe descomponer o separar en módulos cada una de las diferentes tareas, objetivos o incluso sensores en comportamientos diferentes. Cada uno de estos comportamientos, debe tener una condición de inicio, algo que se debe satisfacer para determinar el instante en el cual dicho comportamiento tome el control del robot, también se debe definir alguna acción a ejecutar en cuanto el robot termina de ejecutar el comportamiento, esta acción deberá ser lo más corta posible, generalmente se utiliza para cambiar el estado de algún indicador, por último se debe definir la acción a ejecutar en el momento en que el comportamiento toma el control del robot. Adicionalmente a esto, se debe pensar en la importancia o relevancia de cada comportamiento con respecto a los demás, permitiendo saber cuáles comportamientos predominan sobre los otros y cuáles no.
• Árbitro: Este componente, es el encargado de iniciar la ejecución de los comportamientos y  de dar el control del robot a cierto comportamiento en el momento en que la condición de inicio indicada en un este se cumpla. En caso de que dos o más comportamientos cumplan sus condiciones de inicio en un instante dado, solo el comportamiento de mayor importancia será el que tome el control.

 Saber mas...

Acerca de Java-LeJOS:

LeJOS es un entorno de desarrollo basado en Java, que permite programar robots Lego NXT bajo el firmware LeJOS, con gran facilidad . Saber mas...

 La Arquitectura Subsumption en Java-LeJOS:

Java-LeJOS ofrece la librería Subsumption que hace parte del paquete lejos.robotics.subsumption. Dicho paquete contiene la clase Arbitrator y la interfaz Behavior, útiles para la gestión de los comportamientos y la creación de estos con cada uno de sus componentes  respectivamente.

  

La interfaz Behavior:

Esta interfaz, es la cual nos va a permitir crear cada uno de los módulos que representarán los diferentes comportamientos que componen nuestro algoritmo de control. Esta interfaz está compuesta por tres métodos abstractos que nos permitirán definir todas las características de un comportamiento. Estos son:

• boolean takeControl(): Este método retorna un valor de tipo booleano, de acuerdo al valor de verdad de este, el comportamiento toma el control. Es decir en el momento en que tome un valor verdadero, el árbitro le sede el control del robot a este comportamiento, siempre y cuando no exista otro comportamiento de prioridad mayor que cumpla también su condición de inicio.
• void action(): El código contenido en este método, es el que será ejecutado en cuanto el comportamiento tome el control del robot, representa la tarea a ejecutar por el robot en ese momento, en cuanto la ejecución del código termina, el método retorna.
• void suppress(): Este método debe ser lo más corto posible, es ejecutado en cuanto el método action() termina su ejecución, es usado generalmente para establecer el valor de alguna variable de control del propio comportamiento o de otros, por ejemplo una “flag”.

Para crear un comportamiento solo basta con implementar la interfaz Behavior y los métodos abstractos.

Ilustración 1 Creación de un comportamiento en Java-LeJOS

En cuanto se tengan creadas las clases correspondientes a cada comportamiento, se deben crear las instancias correspondientes, y posteriormente un arreglo de comportamientos ordenados según su importancia, siendo el de menor índice el menos importante.

Ilustración 2 Instanciación de comportamientos en Java-LeJOS

 Saber mas...

La Clase Arbitrator: 

La clase Arbitrator es encargada de gestionar los comportamientos según su importancia y dar el control a cada uno en cuanto se cumplan las condiciones de inicio. Esta clase posee un único método:

• Public void start(): Este método comienza el ciclo de gestión de los comportamientos, hasta que el programa termine en la ejecución de algún comportamiento o todos los comportamientos estén inactivos.

La clase Arbitrator posee dos constructores, para poder instanciar y dar inicio a la ejecución, ambos reciben como argumento el arreglo de comportamientos ordenado según su relevancia:

Ilustración 3 Constructor Clase Arbitrator

El segundo constructor recibe un argumento adicional:

Ilustración 4 Constructor Clase Arbitrator con dos argumentos

Si el valor del segundo argumento es verdadero, el árbitro finalizará su ejecución en el momento en que no exista algún comportamiento activo. Si se enviara este argumento con valor falso, sería idéntico a utilizar el primer constructor.

Saber mas... 

Implementación en un ejemplo real: 

Este algoritmo es un evasor de obstaculos, consiste en hacer que el robot este avanzando constantemente hacia adelante hasta encontrar un obstaculo, en ese momento girará a la izquierda y seguira avanzando hasta encontrar otro. Mientras el boton escape no sea presionado.

Ilustración 5 Implementación de un ejemplo real.

Videos:

A continuación pondré dos videos con la implementación de este algoritmo linealmente y con la arquitectura Subsumption.


Implementación con Arquitectura Subsumption 

Implementación Lineal

Se puede apreciar una diferencia notable en los tiempos que le lleva al robot llegar al final en cada video, sin embargo esta diferencia no tiene nada que ver con la implementacion del algoritmo, sino a factores externos a esto como son friccion, impresicion en los giros, etc.

En la siguiente grafica, se muestran cinco eventos en los que se tomaron los tiempos de cada algoritmo, los tiempos son bastante dispersos, sin embargo el promedio de estos tiempos es muy cercano:

Arquitectura Subsumption VS Algoritmo Lineal:
 

Conclusiones:

• La arquitectura Subsumption orientada a comportamientos, es una muy buena práctica al momento de programar robots, permitiendo generar buen código, comprensible y modular.
• Implementar un algoritmo controlador en arquitectura Subsumption, abre las puertas a múltiples posibilidades al momento de programar, sin embargo no ofrece mayores cambios en eficiencia con respecto a un algoritmo implementado linealmente.
• En el momento de programar un robot, lo ideal es hacerlo desde un comienzo con una arquitectura orientada a comportamientos y no realizar una implementación lineal para ser transformada luego en dicha arquitectura.
• Al implementar algoritmos en la arquitectura subsumption, es muy posible que no se obtengan mejoras a nivel de eficiencia, sin embargo es importante pensar si esta implementación permitiría llegar a un desempeño más eficaz del robot, permitiendo llevar a cabo tareas que antes no era posible.
• Implementar un algoritmo con la arquitectura Subsumption, permitirá a futuro aumentar la cantidad de comportamientos existentes con gran facilidad, pudiendo así mejorar el alcance y desempeño del robot o incluso eliminar comportamientos que ya no sean útiles.
• Al tener la posibilidad de tener múltiples comportamientos, se podría pensar en la posibilidad de tener un repositorio de comportamientos, que puedan ser utilizados por el robot, dadas ciertas condiciones.

   

Escrito por: Juan David Meza Gonzalez. Grupo SINTELWEB. Universidad Nacional de Colombia Sede Medellín.