Práctica 0: Pica 0 Junio

Debido a los problemas que tuve durante la anterior convocatoria tuve que rehacer unas cuantas cosas para asegurarme de que esto funcionase.

La primera fue pasar todo el código de detección de puntos en 3D de la parte de gráficos a la del robot. Con esto se mejora muchísimo en velocidad de computo ademas de que separas dos problemas, el calcular y el mostrar los puntos.

A parte de esto se añadieron unas cuantas restricciones mas a la hora de obtener las correspondencias como son:

• Un punto solo puede tener un equivalente en cada imagen. Así que cuando usamos dos pixels los descartamos para futuras búsquedas.
• El pixel de la cámara derecha no puede estar mas cerca del borde izquierdo de la imagen que el de la cámara izquierda del borde izquierdo izquierdo, ya que sino o los rayos serian paralelos y el punto estaría detrás de la cámara. Lo cual es imposible.
• Se incremento el parche a 17x17 ya que me dio mejores resultados.
• Ademas si en una misma epipolar encontramos dos coincidencias (o los dos pixels con mayor valor no se diferencian mucho) no los tomamos en consideración.
• También probamos que ocurriría si al recorrer la imagen derecha no tuviésemos en cuenta la imagen de bordes. El resultado fue una reconstrucción mas densa a costa de mas errores.

El resultado final que obtuvimos fue el siguiente:

Práctica 2: Pica 0

Esta ultima parte parecía bastante inmediata después de tener las anteriores a punto, pero me trajo bastantes mas problemas de los esperados.

Las partes a añadir eran básicamente las siguientes:

• Detector de bordes: Utilizamos un detector de canny.
• Recorrer los pixels bordes, eliminando los que tienen 8-conectividad.
• Para cada pixel aplicar lo explicado anteriormente
• Mostrar todos los puntos susceptibles de ser buenos.

Cuando proyecté los puntos por primera vez me di cuenta de que muchos de estos puntos aparecían por detrás del robot, esto se debe a fallos a la hora de encontrar el pixel equivalente en la otra imagen, que hace que salga el punto por la parte de atrás. También hay muchos puntos en el suelo, esto se debe a las lineas que hay que no se me ocurrió forma de eliminarlas (también generan muchas falsas coincidencias).

El coste computacional del procesado es muy alto y le cuesta un poco poner los puntos.

Para mostrar los puntos copié la función que había en la api y le reduje el tamaño de las esferas y las puse de color negra para que resaltasen sobre lo demas.

Aquí una imagen con el resultado:

Práctica 2: Pica 1

Anteriormente mostré el Pica 2 en el cual había que hacer click en las dos cámaras para que el programa encontrase el punto 3D del objeto seleccionado.

En esta parte vamos un poco mas allá y solo tendremos que hacer click en la cámara izquierda y esta buscara la correspondencia en el lado derecho. La búsqueda se efectuara unicamente en la zona de la linea epipolar.

Hay que tener en cuenta que la linea epipolar en este caso (dada la distriubución canónica de las cámaras) podría obtenerse recorriendo simplemente la otra imagen a la misma altura, pero en este caso lo que haré sera buscarla como si no supiese esto.

Para esto busco los dos puntos ( como los que obtuve en pica 2) correspondientes a la cámara izquierda, en este caso sera el que me da la función backproject y otro en la misma recta.

Luego estos puntos los proyecto sobre la cámara derecha (con project) y los vuelvo a pasar a las coordenadas gráficas de la cámara (tengo que recalcar que la función opticas2graficas no me funcionaba bien, así que implemente yo lo mismo pero en el código)

Una vez tenia estos dos puntos era tan sencillo como utilizar su ecuación de la recta para recorrer la imagen de izquierda a derecha por la recta que formaban buscando equivalencias de parches.

La equivalencia del parche no es mas que mirar en 7x7 a ver si coinciden los colores de los pixels.

Una vez tengo el pixel mas parecido lo tomo como si fuese el click derecho de antes y listo. El vídeo muestra el resultado.

Practica 2: Pica 2

En esta práctica el objetivo es reconstruir objetos en 3D con el uso de dos cámaras en posición canónica.

Para ello dividimos la practica en tres fases:

• Pica 2: Clickamos en ambas cámaras (en un mismo punto), lanzamos lineas de retro-proyección y buscamos donde se cortan.
• Pica 1: Clickamos en la cámara izquierda y buscamos el correspondiente en la cámara derecha.
• Pica 0: Todo automático, sin click. Reconstruimos la escena entera.

En este primer post hablaremos de la primera parte (Pica 2). Esta es la mas simple ya que la única complejidad que tiene es el aprender a utilizar las funciones de proyección, los diferentes ejes de coordenadas, y el punto mas corto entre dos rectas.

El gran problema de esta primera parte es el "corte" entre lineas, ya que realmente no suelen llegar a cortarse, por lo cual nos tenemos que conformar con el punto mas cercano entre dos lineas.

Para esto busque por internet y encontre tras mucho buscar lo siguiente http://geomalgorithms.com/a07-_distance.html en la que tienen un algoritmo para encontrar la distancia entre dos rectas que calcula primero los dos puntos mas cercanos. Decidí hacer uso de esta función sin utilizar la parte de la distancia y así obtuve los puntos a encontrar.

Después puedes obtener fácilmente el punto medio y en ese punto dibuje una pelota verde.

El vídeo a continuación muestra como funciona.

Practica 1: Recuperación de la linea

Bueno como ya dije antes uno de los pasos que me faltaba por hacer era que el robot encontrase la linea si no la tenia en su campo de visión.

El problema esta dividido en dos subproblemas:

• Empezar sin la linea en el campo de visión.
• El robot pierde la linea durante el seguimiento.

La solución final al problema es añadir un caso al control de giro y velocidades y una nueva variable que sea global a todo el programa. En dicha variable lo que hago es almacenar hacia donde estábamos girando la ultima vez para que siga buscando la linea por donde salió.

Cuando mi robot se enfrenta al primer problema siempre girara en el mismo sentido (hacia la izquierda) por defecto. Mientras que si se enfrenta al segundo problema como sabe por donde se fue la linea la buscara en esa dirección.

Probando a ver en cuanto tiempo acababa si lo aceleraba de tal forma que se saliese de las curvas vi que tarda prácticamente lo mismo ya que en alguna curva pierde demasiado tiempo.

Practica 1: Menos de 3 minutos logrados!

Definitivamente una imagen vale mas que mil palabras. El objetivo basico esta practicamente logrado ya que consigo dar una vuelta en menos de 3 minutos.

ToDo:

• Modulo que cuando pierda la linea la busque, sabiendo por que lado la ha perdido para evitar que cambie de dirección.
• Intentar mejorar la velocidad en rectas y curvas.

Practica 1: Primeros pasos

Como ya se había avanzado el planteamiento principal va a ser encontrar donde esta la linea como primer objetivo. Para ello tiramos 9 lineas en bloques de 3 como se muestra en la imagen.

Con dichas lineas buscaremos donde se cortan con los bordes de la linea "roja" y de ahí obtendremos el centro la linea que es lo que buscamos.

Como novedades es interesante que debido a que OpenCV utiliza BGR en lugar de RGB la linea y el cielo son rojos y no azules como creia en un primer momento. Realmente es algo que da un poco igual pero es curioso.

Una vez tenemos las lineas encontramos el centro de la linea roja. Como se puede ver hay ciertos problemas cuando la linea se sale de la imagen. Esto puede hacer que tenga que replantar mi estrategia o que busque una solución.