The end!!

Hola a todos,

Una vez realizada presentación del proyecto el tribunal decidió que el trabajo realizado se merecía la máxima puntuación: ¡¡¡Matrícula de Honor!!!.

La verdad es que he trabajado duro en el proyecto, pero también tengo que reconocer que he pasado muy buenos momentos y que he aprendido muchísimo.

Además, como ya redactaba en la memoria del proyecto, me gustaría agradecer en este último post a toda la gente que en cierta medida ha contribuido, de una manera o de otra, a que todo esto haya sido posible:

En primer lugar me gustaría agradecer a toda mi familia y en especial a mis padres por su apoyo incondicional en todo momento.

También quería agradecer a mis tutores José Pascual y Arturo por haber confiado en mí para realizar un proyecto de estas características y por el tiempo que me han dedicado dentro de sus apretadas agendas.

A todos los amigos que he hecho durante mi estancia en Albacete por todos los buenos momentos que hemos pasado juntos y por ser tan geniales.

A mis compañeros del club .Net por lo bien que lo he pasado con ellos aprendiendo y trasteando con las nuevas tecnologías.

A la gran mayoría de los profesores/as que he tenido, por la formación que me han dado y sobre todo por hacer que si ya me gustaba la informática cuando empecé la carrera, hoy en día sea una de mis pasiones.

Y en especial a ti, Bego, por los cuatro años maravillosos que hemos compartido.

Casos de Estudio

Buenas,

una vez finalizado el desarrollo se han propuesto una serie de casos de uso a fin de mostar el funcionamiento y verificar el cumplimiento de los objetivos. Aquí se comentan de manera resumida:

MODO 1: NAVEGACIÓN MEDIANTE ODOMETRÍA

Se pretende que el robot navegue sobre una ruta predefinida haciendo uso del odómetro para ilustrar el la situación de la que se parte. En el vídeo se puede observar cómo el robot acaba chocándose con la puerta, mientras que según la información odométrica debería estar saliendo por la puerta.

MODO 2: OBTENCIÓN DE DATOS DE LAS MARCAS

Situando una marca en diferentes posiciones (a 1, 2, 3 y 4 metros) y diferentes ángulos en cada posición (0º, 15º, 30º, 45º, 60º, y 75º) se han llevado a cabo los siguientes estudios:

• Error en la estimación con respecto a la distancia:

Como se observa en la figura siguiente el error en la estimación de la posición pierde precisión de forma casi exponencial, por tanto interesa realizar calibraciones de la posición sólo cuando la marca se encuentre en una distancia relativamente pequeña.

• Error en la estimación del ángulo

A la vista de los resultados de la siguiente figura se aprecia que la estimación del ángulo en ocasiones acumula un error importante, sobre todo en distancias más lejanas. También se observa que a partir de un metro de distancia, no es posible reconocer la marca cuando se orienta a 75º debido a que su inclinación es demasiado grande. En conclusión, calibrar el giro del robot mediante la inclinación de la marca es en ocasiones peligroso, ya que si se comete un error, por pequeño que sea, y posteriormente se avanza una distancia significativa, el robot se irá alejando cada vez más de la trayectoria que debía seguir.

• Tamaño de las marcas visuales

En la gráfica siguiente se puede apreciar que existe una relación prácticamente lineal. Analizando los resultados, se observa que con 53mm el campo de acción es muy limitado, mientras que con 106mm se obtiene un rango de uso de casi 4 metros, lo cuál será suficiente para este tipo de aplicación, teniendo en cuenta que la información a distancias grandes comente un error mayor, y por tanto se desprecia. En caso de necesitar un rango de acción mayor se recurrirá a marcas de 160mm de ancho.

MODO 3: NAVEGACIÓN USANDO CALIBRACIÓN MEDIANTE MARCAS

Sobre el mapa que se muestra a continuación realizado con la herramienta Mapper3Basic se ha definido una ruta donde el robot debe usar la información de las marcas para calibrarse en determinados momentos.

En el vídeo se observa cómo apoyando la navegación con marcas el robot puede navegar por entornos muy restingidos con gran precisión, completando la ruta propuesta en este caso de estudio.En determinados momentos del vídeo se realiza zoom sobre el mapa para observar la diferencia entre la posición calibrada y la odométrica.

MODO 4: NAVEGACIÓN SOBRE UNA RUTA DEFINIDA POR MARCAS

En este vídeo se muestra cómo colocando determinadas marcas por el entorno se puede transmitir cierta semántica al robot, en este caso le indican el orden que debe seguir. Cuando alcanza una marca se aprecia cómo realiza la búsqueda del la siguiente marca hasta alcanzar el final de la ruta.



MODO 5: NAVEGACIÓN REACTIVA AL MOVIMIENTO DE UNA MARCA

En este caso se observa cómo el robot sigue una marca mediante el movimiento de la cámara, rotaciones y translacioines.

MODO 6: CONTROL MANUAL

En este modo de funcionamiento se observa cómo el robot responde a los comandos que le envía un teleoperador remoto.

Esto es todo por ahora,

espero que os haya gustado!

Diseño de la aplicación

Buenas,

a fin de que el lector obtenga una idea mental del funcionamiento de ARBOT añadiré algunos diagramas.

La aplicación esta compuesta por un cliente (la interfaz de usuario) y un servidor (ejecuta los modos de funcionamiento sobre el robot), como se muestra en el dagrama de despliegue.

Entre ellos intercambian los siguientes mensajes:

En el diseño del diagrama de clases se utiliza la técnica de especialización, de forma que conforme se va bajando en la jerarquía se van definiendo clases abstractas más específicas hasta la implementación de cada modo de forma concreta. Esta propiedad, aparte de dar una visión clara de la clasificación de cada uno de los modos de funcionamiento dentro de la jerarquía, permite extender las clases de forma sencilla, lo que facilita implementar futuros modos. Por otro lado también permite una mayor reutilización del código, ya que se evita tener métodos repetidos en varias clases. A continuación se muestra el diagrama desarrollado:

Esto es todo por ahora,

saludos!!

Estado del arte: posibilidades de la realidad aumentada

Buenas,

al documentarme sobre el estado del arte para la memoria me he topado con proyectos alucinantes que usan realidad aumentada. Puesto que no estaban en relación con el tema del proyecto (videovigilancia y robots) no los incluí en la memoria, pero como me llamaron la atención no podía evitar mencionarlos por aquí. Seguro que agradan la vista a los interesados en el tema:

Eye Of Judgement: juego de rol para playstation, donde a partir de unas cartas generan todo un escenario de batalla con criaturas en 3D aumentando la realidad.



Camspace: proyecto que a partir de diferentes objetos recrea toda serie de dispositivos para jugar a cualquier juego (vídeo muy recomendado).



PARIS (Personal Augmented Reality Immersive System): proyecto en el que generan todo un sistema de realidad virtual a partir de ralidad aumentada para implantes de prótesis:



Augmented Reality and Information Visualization: un sistema de visualización de gráficos estadísticos en 3D con realidad aumentada:



Living Augmented Reality: todo el interior de una habitación generado con realidad aumentada:



Neon Racer: juego de naves sobre una pantalla-tablero:



Genesis: proyecto donde se genera un escenario aumentado haciendo uso de un proyector y marcas visuales. El argumento es un juego que emula ser "Dios" y construir un mundo.



ARlego: guia de autoayuda para el montaje de diferentes prototipos con el Lego Mindstorm mediante realidad aumentada.



Y como estas, hay muchísimas aplicaciones vistosas hechas con realidad aumentada. En mi opinión, hoy por hoy la mayoría de proyectos son de investigación, pero solo es cuestión de tiempo que esta tecnología se empleé en el uso cotidiano de determinadas tareas, ya que como habréis visto, tiene infinidad de posibilidades. El primer campo sin duda será el mundo de los videojuegos por ser el más comercial, pero para mí lo más impactante son las nuevas formas de interacción persona-ordenador que se pueden plantear a partir de proyectos como Camspace.

Saludos y espero que os haya gustado.

Ha nacido ARBOT!!!

Salvo pequeños detalles, ya se puede dar por concluida la implementación de este proyecto que he bautizado como ARBOT (Augmented Reality roBOT).



En esta última versión, se han añadido las siguientes características:

En el cliente:

- Loading y pintado de mapas, actualizando sobre éste la posición del robot en tiempo real y la posición según el odómetro para observar visualmente la desviación que corrige el uso de calibración por marcas visuales.

- Añadidos dos botones de ZoomIn y ZoomOut para agrandar el mapa.

- Añadida una sección de estadísticas, donde se muestra: nº frames que se han observado, nº frames usados para recalibrar, distancia (en mm) que se ha recalibrado, rotación (en grados) que ha recalibrado. (Actualmente en esta parte calculo esta información en el cliente, pero tengo que cambiarlo al servidor y enviarla dentro de los paquetes de información, pues hay frames que el servidor procesa pero no llegan al cliente, ya que tiene una tasa de frames más baja para no saturar la red.)

En cuanto al servidor, se han probado las estrategias el uso de marcas para navegar sobre mapas daba diversos problemas inexplicables, y tras darle vueltas y vueltas he dado con solución: "en cambiar las ArActions (GoTo(x,y)) por comandos a bajo nivel(move(), setVel, setHeading()...) para tener un mayor control y conocimiento de los comandos que se le están mandando al robot en todo momento" y ahora funciona correctamente.

En mi opinión esta quedando bastante chulo, en cuanto pueda subo unas capturas y algunos vídeos para que lo podáis ver y opinar.

Como comentaba, salvo pequeños detalles, en breve empezaré con la memoria cerrando el ciclo de implementación, pero eso no significa que vaya a olvidar el blog, si no que realizaré artículos con información interesante o curiosa que me vaya encontrando en la redacción de la memoria, ya que la idea de hacer este blog tiene como objetivos:

-Que mis tutores (u otros interesados) puedan hacer un mejor seguimiento de los avances.
-Compartir el conocimiento adquirido con el mundo.
-Que esta información quede inmortalizada por si en el futuro pudiera ayudar a otros proyectos sobre la materia, ya que son varios los que me han escrito preguntando dudas, o comentandome que les ha encantado la iniciativa y la aplicarán a proyectos futuros.

Por cierto, os podeis suscribir a las RSS si estais interesados ;)


Saludos!!

Video en el cliente

Ya tengo el vídeo en la parte del cliente.

Tras hacer pruebas, como cabía de esperar la tasa de frames por segundo es reducida pero aceptable, pues el limitado procesador del robot tiene que realizar a la vez las tareas de manejar el robot, procesar cada frame por Artoolkit plus y comprir cada frame en jpeg para enviarlo. Aun así, se obtiene mayor tasa que las que se obtienen con programas como VCN para conexión remota.

En cuanto a la calidad de imagen, es bastante aceptable, los frames se envian al 60% de su calidad original con una resolución de 640x480 (abajo una muestra de un frame) en escala de grises para minimizar el coste del flip vertical que hay que realizarles y el procesamiento del artoolkit plus. El usar compresión por frames independientes permite obetener un video de calidad, que no se degrada con el movimiento o con los cambios de escena como pasa con formatos de videoconferencia.


Por otro lado, se han añadido 3 radio button para que el cliente pueda elegir el tamaño de frame.

Diseñando la Aplicación Cliente

Buenas,

puesto que en la parte servidora (el corazón de la aplicación) ya estan implementados los 6 modos de funcionamiento, ahora toca diseñar una aplicación cliente que se conecte y lance el modo seleccionado o en caso del control manual pueda enviar los comandos.

Para esto, estoy planteando una aplicación MFC basada en un cuadro de dialogo que contiene el control. Un boceto de la interfaz de usuario sería algo similar a esto:


Aunque a primera vista parecía sencillo, aparte de tener que casi aprender MFC en unos dos dias, la cosa se pudo bastante fea al toparme con el término de "functores". Los functores son plantillas de punteros a funciones (que ya suena a chungo) que se han inventado la gente de Aria y que básicamente sirven para llamar a la función que apuntan en determinados momentos. En este caso servirá para manejar las respuestas del servidor a las peticiones del cliente.

Otro problema fue, la actualización de los componentes del dialogo cuando escribe el método de callback (la llamada del functor), ya que este es invocado por un hilo (el cliente, que se ejecuta de manera asíncrona, y este no puede usar la función UpdateData(bool), que actualiza los componentes con sus variables asignadas, y en este caso se usaría para, por ejemplo, actualizar la información del log con la información que recive de los mensajes. Para esto en vez de usar UpdateData hay que usar "SetWindowText" que escribe directamente sobre el componente y no da problemas con el Threading.

Por último, comentar que he diseñado un icono para aplicación que representa al robot y una marca del Artoolkit

Conversaciones Cliente-Servidor

Buenas,

puesto que se pretente hacer una arquitectura cliente-servidor para iniciar los modos de funcionamiento, obtener los datos y la imagen que el robot captura o para poder controlarlo en el modo manual, nos hace falta definir un protocolo de mensajes para que puedan conversar entre el cliente y el servidor. Para este proposito he definido el siguiente formato de tramas de mensajes que intercambian:

Client-Server Communication

Init robot (TCP):

Client request:

SMS_INIT

Server response confirmation:

SMS_INIT

SMS_ACK

"Server state: INIT"

Server response error:

SMS_INIT

SMS_CRITICAL_ERROR

"server can't init due to call has failed"

Exe Mode N (TCP):

Client request:

SMS_EXE_MODE_N

Server response confirmation:

SMS_EXE_MODE_N

SMS_ACK

“(Server State): Running mode N”

MapaData(*)

(*) Only in modes 1, 2 and 3

Server response error:

SMS_EXE_MODE_N

SMS_CRITICAL_ERROR

1)"server can't run strategy due to the state wasn't ST_INIT" 2) "server can't run strategy due to init function failed"

Robot and Camera commands (only on mode 6) (UDP):

Client request:

SMS_COM_ADVANCE | SMS_COM_GO_BACK | SMS_COM_TURN_RIGHT | SMS_COM_TURN_LEFT | SMS_COM_TILT_UP | SMS_COM_TILT_DOWN | SMS_COM_PAN_RIGHT | SMS_COM_PAN_LEFT | SMS_COM_CAM_RST | SMS_COM_STOP

Cancel active mode (TCP):

Client request:

SMS_CANCEL

Server response confirmation:

SMS_CANCEL

SMS_ACK

"Stopped mode N"

Server response error:

SMS_CANCEL

SMS_WARNING

"Couldn't stop mode due to it wasn's running"

Get data without image (UDP):

Client request:

SMS_RETURN_TEXT

Server response:

SMS_RETURN_TEXT	GoalReached (*)	PosRobotX	PosRobotY	RobotTh
idMark	posMarkX	posMarkY	MarkTh	UseMarkInfo (**)
“date and time”

(*) Some modes finished when reach one goal: 0 or 1

(**) 0 or 1 if use or not the position estimation.

Get data with image (UDP):

Client request:

SMS_RETURN_IMAGE

Server response:

SMS_RETURN_IMAGE	GoalReached (*)	PosRobotX	PosRobotY	RobotTh
idMark	posMarkX	posMarkY	MarkTh	UseMarkInfo (**)
“date and time”	ImageData

(*) Some modes finished when reach one goal: 0 or 1

(**) 0 or 1 if use or not the position estimation.

Saludos!!

Modos de funcionamiento implementados

Una vez con los datos que nos proporcionan las marcas se han implementado los siguientes modos de funcionamiento:

1) Seguimiento de una ruta planificada sobre un mapa sin asistencia de marcas
2) Seguimiento de una ruta planificada sobre un mapa recogiendo información aportada por las marcas del entorno.
3) Seguimiento de una ruta planificada sobre un mapa usando la información que considera de utilidad de la información aportada por las marcas del entorno.
4) Seguimiento de una ruta que es establecida solo por marcas visuales, sin el uso de mapas.
5) Seguimiento de una marca en movimiento.

Por otro lado también tengo pensado (si me diera tiempo) hacer un modo manual, donde un usuario controla remotamente el robot y la cámara.

Ahora la aplicacion esta corriendo directamente sobre el robot, pero se intentara implementar una aplicacion cliente que inicie el servicio haciendo uso de la librería ArNetworking, escoja el modo que quiere ejecutar y pueda ver la imagen que el robot esta capturando. Este ultimo punto puede crear un cuello de botella en el procesamiento al tener que comprimir la imagen y enviarla en tiempo real.

Hasta pronto!

Obteniendo la posicion mediante marcas

Buenas,

tras probar el caso anterior, en la negación sin marcas se observa que la odometria comente ciertos errores de medición.

Ahora, se plantea un caso de estudio, donde el robot va navegando normalmente y cuando se encuentra una marca calcula su posición en el mapa con respecto la posición global de la marca en el mapa. Aparte, cada vez que detecta una marca muestra la información por pantalla y añade una entrada en un log con la siguiente información:

-Fecha y hora en que se ha encontrado la marca
-Posición del robot en el mapa que se estima mediante el odómetro y el giroscopio.
-Posición del robot en el mapa que estima mediante la información que le aporta la marca.

Con esto, aparte de poder depurar de forma visual en tiempo de ejecución, se proporciona un log que se puede consultar a posteriori para hacer comparaciones. En la siguiente figura se puede observar lo comentado anteriormente.



Para la prueba se ha situado la marca a un metro del robot y el error aproximado según se observa en las entradas del log es de unos 30-50 milímetros como máximo Lo cual parece un resultado positivo para trabajar en futuros modos de funcionamiento que usen esta información para tomar determinadas decisiones.

Como comentario, cabe anotar que se ha sustituido el uso de jpegLib por OpenCV [1], ya que tiene una mayor funcionalidad y en nuestro caso nos permitirá operaciones como:
-Añadir información al frame(como texto o formas básicas)
-Realizar diferentes transformaciones (lo que se ha usado para realizarle un flip vertical a la imagen, pues la capturadora la proporciona invertida)
-Guardar un frame en diferentes formas (aparte del jpeg).
-Mostrar la imagen en una ventana de forma sencilla.

[1] http://sourceforge.net/projects/opencvlibrary/

Moviendo a Don Pioneer 3AT

Buenas,

una vez asentadas las bases del funcionamiento de Artoolkit, Aria, etc... me dispongo a implementar un caso de estudio para comprobar la funcionalidad que podría tener el uso de marcas para conseguir un posicionamiento del robot más robusto y fiable.

Para este objetivo he creado un mapa de la segunda planta del I3A con la herramienta Mapper3Basic [1].

Primeramente se intentó hacer una implementación de un algoritmo de navegación híbrida que se componía de un algoritmo de planificación global basado en rejillas (que divide el mapa en casillas y calcula la mínima distancia de un origen a un destino) para calcular por qué puertas debía pasar y un algoritmo de navegación local (en concreto se usó el algoritmo Vector Field Histograms [2]) para esquivar obstáculos inesperados que se pudieran presentar durante la navegación.

Tras la implementación del algoritmo se probó que la navegación local es impracticable debido a las fluctuaciones de los sonares (quizá con la herramienta del láser se obtendría mayor precisión y sería aplicable).

A la vista de esto, como el desarrollo de un algoritmo de navegación no es parte del objetivo del proyecto (aunque si me hubiera gustado que funcionara, aunque fuera por probar alguna cosa más) se ha opatado por definir una ruta preestablecida en el mapa (como se puede ver en la siguiente figura) para empezar observar el error de odometría cometido y probar diferentes estategias en las cuales las marcas podrían aportar cierta semántica al entorno para mejorar el posicionamiento en la navegación.




[1] http://robots.mobilerobots.com/Mapper3Basic/
[2] http://www-personal.umich.edu/~johannb/vff&vfh.htm