miércoles, 30 de noviembre de 2011


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.

lunes, 28 de noviembre de 2011

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

 
       

miércoles, 23 de noviembre de 2011

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.


lunes, 21 de noviembre de 2011

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.

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


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.

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.