Futbol de Robots 2014

Introducción

El problema planteado consistía en que un Butiá fuera capaz de resolver los siguientes problemas:

• Encontrar una pelota, fuere donde fuere que se encontrara respecto al robot
• Saber acercarse a la misma
• Saber reconocer el arco
• Saber girar en torno a la pelota hasta tener un buen ángulo al arco
• Patear la pelota, y si lo anterior se hizo de forma correcta, debería dirigirse al arco

Análisis del problema

Principalmente el problema puede descomponerse en dos grandes grupos:

• La ingeniería en el reconocimiento de los objetos ( captura y tratado de imágenes )
• Aspectos mecánicos, tales como el manejo de los motores y el accionamiento del pateador

Vision de Computadora

El problema de la detección del arco y la pelota se decidió resolver puramente utilizando un sensor ya incluido en la Ceibalita: la cámara. La cámara tiene la ventaja de ser un sensor de gran capacidad de captura de información pero requiere de un análisis cuidadoso. En principio, mucha de la complejidad ya viene resuelto por el uso de la librería PyGame aunque no así la algoritmia necesaria para incorporarla ni la calibración pura de un proceso no exacto.

La detección de los objetos se hizo mediante el uso de máscaras. Mediante la aplicación de las mismas, uno es capaz de reconocer las áreas de la imagen capturada que tienen un cierto parecido con la muestra que uno toma como base. Dos funciones sobre las que se basó la implementación fueron pygame.transform.threshold y pygame.mask.from_threshold.

Existen varios modos de manejo de colores. Entre ellos se encuentran RGB, normalmente usado para imágenes visualizadas por un humano, y HSV que descompone el color no en los colores que lo configuran, sino que más bien define un color como una tripleta de propiedades "Tono", "Saturacion" y "Brillo".

Una tapita de refresco es seleccionada por una máscara

Máscaras utilizando RGB

El procesamiento de la imagen en torno a RGB no es tan conveniente como podría parecer. Inicialmente se creyó que podría diferenciarse fácilmente un rojo ( pelota ) y un verde ( pasto ) utilizando el anterior modo, pero ocurrieron inconvenientes.

• Por un lado, las luces. Se observó que los brillos, cuyo color se aproxima al (255, 255, 255), o sea blanco, genera problemas ya que en el caso de la pelota se tendría más verde que el que uno esperaría.
• Por otro lado, y como el robot ha de girar en torno a la pelota, también se tienen sombras, en donde el color de la pelota podría tener menos rojo que el esperado, generando también inconvenientes.

Utilizando RGB no era posible contemplar estos dos aspectos. El primer punto requeriría un criterio como "puede haber mucho verde sólo si hay mucho rojo" y el segundo "si hay poco verde también se puede permitir poco rojo".

Máscaras utilizando HSV

Una fuente de luz es capturada por una cámara en modo HSV. Se visualiza la alta variabilidad.

El uso del modo HSV permitió manejar de forma "nativa" los aspectos que con RGB se intentaban emular. El problema se reformuló, y de esta forma lo que en realidad se quería era seleccionar los colores cuyo tono fuera similar. De esta forma, la tolerancia clave que uno debía considerar era en la primer componente ( tono ), teniendo mayor libertad para la selección de las últimas dos.

HSV probó funcionar bastante bien. También presentó problemas en el sentido de que los colores muy claros o muy oscuros variaban su tono de forma más aleatoria. Esto generó ruido, aunque controlado.

El caso de los colores muy claros o muy oscuros no resultó problemático por dos aspectos. Primero, si bien había ruido, era lo suficientemente aleatorio como para no formar grandes acumulaciones de píxeles similares, por ende manejable. Segundo, el ruido no distorsionaba lo que efectivamente se deseaba reconocer, por lo que tampoco fue un problema en este aspecto.

Post-procesamiento

Incluso con una selección adecuada del modo y una calibración exhaustiva no se podían erradicar con certeza todas las posibles interferencias del medio ni las imprecisiones del dispositivo de sensado. Considerar que todo lo que había pasado la "prueba" de la máscara era lo que se deseaba reconocer no era por tanto factible. De esta manera fue necesario "revisar" el producto que la máscara generaba.

No es posible que la pelota se encuentre representada en la cámara por un área de 4 píxeles dadas las distancias que son factibles y dadas las dimensiones razonables de los esféricos a utilizar. De esta forma se consideraron ciertas cotas que los grupos de píxeles reconocidos deben cumplir. Estas cotas fueron básicamente cotas inferiores en los anchos y altos de los grupos reconocidos. De existir algún grupo de píxeles que las cumpla, se retorna ese como reconocido.

Para lo anterior se utilizó la función get_bounding_rects() que permite obtener, para cada agrupación de píxeles, un rectángulo que lo contiene. De esta forma se puede aproximar el tamaño del objeto reconocido. Las cotas de tamaño se aplican sobre estos rectángulos, más específicamente sobre las propiedades height y width de cada uno de ellos.

Primitivas Paleta FutRob

Al momento se han definido los siguientes primitivas :

• calibrarArco()  : Permite cargar el color del arco a partir de la cámara
• calibrarPelota()  : Permite cargar el color de la pelota a partir de la cámara

• colorArco(r,g,b)  : Establece el color del arco sin usar la cámara
• colorPelota(r,g,b): Establece el color de la pelota sin usar la cámara

• irAPelota()  : Hace que el robot vaya hacia la pelota.(Ver si es útil poner un parámetro para posicionar a determinada distancia de la pelota.)
• alinearArco()  : Alinearse con el arco.
• patear()  : Patea, independientemente de si hay pelota o no.

Y por otro lado:

• bool pelotaVisible()  : Indica si la pelota se encuentra visible en la cámara
• bool arcoVisible()  : Indica si el arco se encuentra visible en la cámara
• float distanciaAlArco(): Retorna la distancia al arco
• float distanciaPelota(): Retorna la distancia a la pelota

Estas ultimas son para dar algo más de flexibilidad. Por ejemplo, podríamos permitir, con las primitivas anteriores, combinado con las de butía de mover el robot, que alguien programara un algoritmo para un uso determinado.

Reuniones y progreso en el proyecto

Lunes 17 de Febrero de 2014

Se definieron varios puntos en esta reunion:

• Se descartó el uso del plugin de marcas dado a que no permitía resolver el problema de la detección frente a variación de los ángulos, además de requerir un fondo particular.
• Se decidió optar por el uso del plugin FollowMe, aunque modificado, para la detección del arco. La idea sería la de distinguir, por lo menos en un principio sólo los dos verticales, de modo de poder apuntar al arco. Las librerías subyacentes ( PyGame ) permiten la detección de múltiples objetos. Se constató que en el caso de FollowMe sólamente se utilizaba el primer objeto encontrado ( índice 0 ), por lo que podría ser un indicio de que es el camino a seguir.
• Si bien se consideró que en un principio se podría considerar el arco como dos verticales ( sin horizontal ) de modo que el objeto a observar se componiera de dos partes conexas para facilitar el reconocimiento, esta idea quedó de lado al considerar que se podría realizar un reconocimiento de los verticales si se intentaba aproximarlos a rectángulos, situación en la que el vertical no debería interferir demasiado.
• Se descartó la simplificación de colorear cada vertical de modo de diferenciarlos entendiéndose que existía una pérdida importante de generalidad.
• Se confirmó la idea de colocar la cámara al costado, para facilitar el alineamiento con el arco. El acercamiento inicial se realizará mediante una espiral, manteniendo siempre en la franja izquierda de la vista de la cámara a la pelota. La distancia con el objetivo se calculará mediante la cantidad de píxeles, y el alineamiento con el arco se realizará manteniendo la pelota en el medio de la pantalla de modo de hacer un movimiento tangencial y mantener la distancia.
• Se sugiere investigar PyGame reconoce figuras
• Se sugiere leer discucion de salimoo, para no repensar cosas

Aspectos a definir

• Zona de ubicacion de la pelota(en determinadas zonas puede tener vision parcial del arco y en pricipio estaría fuera del alance del proyecto)
• Aspectos mecánicos tales como la posición del pateador, si se utilizará algun soporte mecánico adicional y si la precisión de la cámara resulta adecuada o si es necesario utilizar sensores adicionales.

Lunes 3 de Febrero - Ideas

Busqueda - Posicionarse - Patear

Realizar la búsqueda frontal y girar el butiá para posicionarse, al girar el butiá surge la necesidad de girar la pantalla.

Se piensa en utilizar un motor AX12 para realizar el giro de la pantalla.

¿Aplicación a parte o plug-in para TurbleBots?

Contactar a Alan o Nico para el uso del plug-in.