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