Navegación Visual: “viendo” obstáculos

Una de las aplicaciones interesantes de la navegación visual es la detección de obstáculos que no son detectados por el láser, dado que están en el suelo por debajo de este.

Veamos cómo se traduce esto en nuestro esquema.

El obstáculo utilizado es una puerta que he tirado (bueno, más bien ha sido el robot guiado por mi malicia) como terapia anti-stresss, tras pasar una hermosa tarde de verano frente al ordenador sin solucionar los problemas del movimiento (os lo recomiendo, te deja relajado y feliz!).

Bueno, vamos al tema. Os dejo una imagen donde podéis comprobar cómo el láser no detecta ningún obstáculo, mientras que el mapa me muestra el segmento que me impide pasar:

Anuncios

Navegación Visual: problemas con el movimiento

Es hora de darle movimiento a nuestro robot y afinar el diseño para que pueda navegar de forma autónoma, basándose en los datos extraidos de las imágenes capturadas. Y con esto llegaron más problemas…

Resulta que al iniciar la marcha, parar, acelerar, frenar o bien girar (aunque un poco menos en este último caso), la cámara sufre un movimiento que hasta ahora no había considerado importante y que está produciendo segmentos basura en el mapa construido por el robot.

Al cambiar la posición de la cámara, las coordenadas de los puntos detectados no son exactas, lo que genera errores.

Esto podemos intentar solucionarlo acelarando/frenando de forma progresiva… algo así como el controlador PID programado para la práctica del siguelíneas (en este punto me encuentro trabajando).

Otro problema lo encontramos cuando detectamos segmentos pero a una gran distancia del robot. Al acercarse, la posición de estos no coincide, quedando generalmente por detrás del nuevo detectado:

Por último, otro efecto negativo del movimiento es la imprecisión de los puntos detectados al aumentar la velocidad, lo cual nos lleva a definir segmentos incorrectos… ¿solución? tendremos que pensarlo…

Navegación Visual: cambio de estrategia

Como dice Juanes en una de sus canciones, “It’s time to change”… ¿y por qué?. Porque después de complicar cada vez más el código intentando mantener la detección de la “frontera” descrita en los posts anteriores, me he dado cuenta de que para comprobar si existen obstáculos en el suelo se complica todo tanto que el código generado se ha vuelto demasiado ineficiente (da demasiadas vueltas).

Por ello he dado marcha atrás y he puesto a funcionar mi cabecita en busca de una solución mejor y…. ¡eureka! la encontré.

El nuevo método para obtener tanto la frontera como los obstáculos es el siguiente:

La idea es recorrer la imagen por columnas, de izquierda a derecha y de abajo hacia arriba. De esta forma buscamos el primer punto que no coincida con el color del suelo.

También comprobamos si detrás de ese primer punto encontrado, en la siguiente fila, hay suelo.  En ese caso el punto detectado no se corresponde con un límite, si no más bien con una esquina que no me deja ver lo que hay detrás…

Con ello estamos simulando, mejor que con el método anterior, el funcionamiento del laser, obteniendo un total de 340 puntos.

Realmente hemos reducido a una cuarta parte el código tanto del escaneado de la pantalla como de la construcción de segmentos.

Resultados:

Y un detalle de una esquina:

Construcción de mapas (final)

… o eso espero!

Por indicación de José María (el profe 😉 ), os muestro un último vídeo para que se pueda comprobar con detalle la eliminación de segmentos no válidos.

Para saber si un segmento es o no válido, por cada punto del laser detectado, comprobaremos si el segmento formado por la posición del robot y este punto tiene intersección con cualquiera de los segmentos que tenemos almacenados. En ese caso, si el segmento es “pequeño” lo eliminanos, mientras que si es grande lo acortamos por el punto de intersección.

Pero lo mejor es verlo:

Como podéis comprobar, al avanzar el robot azul, el rojo va detectando lo que había detrás de este, fusionando con los segmentos que ya teníamos e, igualmente, eliminando los segmentos “no válidos” (donde estaba el robot azul).

La calidad del video es peor que la de los anteriores, pero es que mi recordmydesktop se niega a trabajar (no se si es porque es fin de semana, porque no aguanta el player con los dos jde de cada robot, …) y he tenido que hacer uso de la cámara del móvil.

Hasta otra!

Construcción de mapas (parte I)

Ya estoy de vuelta,

después de una larga temporada sin escribir en este foro vuelvo para compartir mis nuevos logros en el campo de la robótica.

En este caso os muestro la práctica en la que me encuentro trabajando: contrucción de mapas a través de la interpretación de la información recibida del laser.

Lo que en un principio parece sencillo se complica cuando se quiere afinar el diseño.

En nuestro caso, lo que vamos a intentar es interpretar las 180 distancias recibidas del laser (una por cada grado), de forma que si es esta es menor de 7500 (realmente el laser llega hasta los 8000)  sabemos que existe un obstáculo.

La primera mejora es ir interpretando los puntos para agruparlos en segmentos, de manera que evitamos almacenar mucha información. Para cada segmento tan solo necesitaremos un punto inicial y otro final.

Tras conseguir realizar un escaneado de todos los puntos y agruparlos por segmentos, almacenándolos en la memoria, tendremos que volver a realizar otra pasada, pero en este caso, cada vez que se detecte un segmento comprobaremos si existe ya en memoria. Puede ocurrir que se detecte el mismo segmento (el robot no se ha movido), o bien que se pueda fusionar con alguno los que están en memoria.

En la siguiente imagen podéis ver cómo se interpretan los 180 puntos, construyendo 8 segmentos.

fusion2

Ahora tendremos que implementar un procedimiento que elimine los segmentos de memoria no válidos. Estos se detectan en el caso de que el segmento formado entre la posició del robot y el punto interpretado intersecte con alguno de los almacenados en memoria.

Un saludo!