David-Estevez
commented
6 years ago Avances en el algoritmo:
También, y para simpificar el sistema, estaría bien trabajar primero con imágenes estáticas, que se nos olvidó tomar en la última reunión, pero que tomaremos en la próxima.
He añadido código para emular una "cámara falsa" que funcione exactamente igual que una webcam pero que tome las imágenes desde un archivo. Así se pueden usar las imágenes que tomamos y que están puiblicadas en Sourceforge para probar / desarrollar el algoritmo aunque no tengamos la mesa de air hockey a mano.
1 . La posición del disco (y su velocidad, si puede ser).
Esto ya estaba prácticamente hecho, así que he cogido ese código que teníamos y lo he integrado con el código de calibración, y ahora ya tenemos la posición x, y del disco y su radio. La velocidad se podría calcular a partir de la posición en dos frames consecutivos y el framerate de forma sencilla.
Esta macroissue se centrará en el desarrollo del algoritmo de visión. Aquí iremos documentando nuestros progresos (y posiblemente abriendo sub-issues para tareas derivadas de esta issue).
El objetivo final es obtener, a partir de una cámara, la información suficiente para que el controlador / agente sea capaz de jugar contra una persona. Para ello, necesitamos principalmente conocer tres elementos:
En la reunión del día 20 de Octubre de 2017, estuvimos jugando con GRIP para la detección de elementos rojos en la imagen, con los que se podría obtener el punto 1. Para obtener la velocidad habría que usar la información de varios frames.
En la reunión del día 24 de Octubre de 2017, @jorgercobo y yo estuvimos pensando cómo resolver los puntos 2 y 4. Para el punto 2, y dado que la mano del jugador tapa gran parte del golpeador al jugar, propongo el uso de un sistema similar al empleado para detectar puños cerrados en GECKO. Para el punto 4 se nos ocurrió la idea de detectar las 4 marcas azules que tiene la mesa de air hockey, y realizar una transformación homográfica para obtener la proyección plana de la mesa y la escala de la imagen. Esto es necesario por dos razones: la primera es evitar la calibración del sistema cada vez que se quiera usar, y la segunda es porque la cámara no está ubicada de forma paralela sobre la superficie de la mesa, sino colocada en un trípode en el lugar en el que se colocaría un jugador humano. A continuación dejo un par de imágenes que ilustran tanto las marcas de la mesa como la transformación homográfica:
Como primera aproximación hasta que la parte mecánica funcione (#6), se nos ha ocurrido hacer un contador de puntos, que necesita mucha de la información que tenemos que extraer de la imagen para funcionar.
También, y para simpificar el sistema, estaría bien trabajar primero con imágenes estáticas, que se nos olvidó tomar en la última reunión, pero que tomaremos en la próxima.