Pruebas desde matlab
A continuación se describen las pruebas desarrolladas en matlab.
Desde Matlab se armaron pruebas de concepto de las ideas que iban surgiendo para varios aspectos del procesamiento.
Desarrollo de la Solución
Armado de ambiente
A continuación se describe el ambiente utilizado para desarrollar.
El ambiente que se usó para desarrollar fue el propuesto por la documentación que se presenta en el [link] y el armado del proyecto Android en los tutoriales que presenta Opencv4Android en su documentación. Para las pruebas de conceptos se usó Matlab con OpenCV, luego al crear el proyecto Android para la aplicación se probó en dispositivos físicos, dado que el emulador es muy lento. También se hicieron algunas pruebas en C/C++ dado que es más fácil pasar luego lo programado al lenguaje Java.
Además de esto se genero un repositorio donde el equipo versionó en todo momento el desarrollo de la aplicación, la dirección del mismo se encuentra en esta sección.
Descripción general de módulos
bla bla bla ...
-
Modulo de
Adquisición
En este módulo se emplean técnicas para el acondicionamiento de la imagen. Se tiene la clase Adquisición que dentro posee una lista de clases que implementan la interface XXXXX en la cual solo posee el método ZZZZZ, dicho método es llamado por el módulo de adquisición en cada clases que tiene dentro de la lista, la idea por detrás es que el frame adquirido pase por cada una de esta clases que implementan la interface XXXXX aplicando una técnica de acondicionado obteniendo al final una imagen para ser procesada por el resto de los módulos.
ver codigo -
Modulo
Manager
El módulo se encarga de manejar los estados de la aplicación y conocer en cada momento si se debe analizar la partida o no a partir de la imagen obtenida. Tambien posee informacion del estado de la partida y es el encargado de enviar la partida al sistema externo.
ver codigo -
Modulo de
Calibración
Este módulo es el encargado de calibrar el sistema antes de empezar la partida, busca el tablero y genera información para el resto del sistema.
ver codigo -
Modulo
Modelador
Este módulo es el encargado de a partir de una imagen obtener información de cada escaque y reconocer si existe una ficha o no en el mismo.
ver codigo
-
Modulo
Oclusión
Se encarga de detectar si en la imagen obtenida se encuentra estable para ser procesado o si por el contrario un jugador está realizando un movimiento, por lo cual no debe de procesarse el tablero.
ver codigo -
Modulo
Lógica
Este módulo contiene la lógica de las reglas de Ajedrez y se encarga de procesar las matrices de Modelador para saber qué fichas se movieron y a donde y generar algún tipo salida para que sea procesada por el modulo Comunicacion. Actualmente se encarga de validar los tableros para saber cuando se hizo un movimiento de piezas.
ver codigo -
Modulo
Comunicación
En este módulo debería de estar implementado todas las posibles salidas que se quiere obtener de la partida, quizás a partir de una interfaz que recibe el movimiento y se implementa un tipo de salida (persistencia en archivo, enviar a un servidor, texto a voz,etc). Por temas de tiempo en este módulo sólo se implementó una clase que se encarga de enviar la matriz de las fichas a un servidor conocido.
ver codigo -
Modulo
Activity
Este módulo es la actividad Android que se encarga de hacer la presentación, pooling de la cámara y pasársela al módulo Manager, también posee una máquina de estados para modelar si se está Calibrando o Jugando.
ver codigo
Técnicas empleadas
A continuación se describen las tecnicas empleadas.
Primeramente se emplea, para la calibración, una detección de esquinas usando el metodo XXXchescorners. De esta manera se obtienen las esquinas interiores del tablero de ajedrez. Con las esquinas detectadas se calcula una homografía para enderezar el tablero, recortarlo para solo tener el tablero en la imagen para procesar y colocarlo en una posición conocida. Con este proceso también se obtiene el tamaño de los escaques y de todo el tablero.
Luego de acondicionar la imagen se utiliza un proceso de supresión de fondo para detectar cuando se esta haciendo el movimiento de las fichas, para esto se utiliza los métodos DDDDDDD de la librería OpenCV.
Para la detección de fichas se obtienen de cada frame la sub imagen correspondiente al área central de cada escaque, se le hace un filtro de Sobel para la detección de bordes, a su vez se binariza una imagen a partir de cierto umbral. Luego para eliminar ruido se hace un erode, y un dilate para acrecentar los pixeled donde hay fichas. Si la cantidad de pixeles blancos pasan cierto umbral se puede decir que se encuentra una ficha en el escaque.
Para el envío de la partida a un servidor externo, como ya se comento, solamente se envía un tablero con unos y ceros, los cuales representan el tablero y las fichas. Dicho servidor es dedicado a esta aplicación y se encuentra dentro del repositorio del proyecto. Para usarlo se debe de levantar el mismo en un pc con java, y luego antes de calibrar, configurar la ip y el puerto (actualmente es el 5556) en la aplicación.
Igualmente la aplicación permite una jugabilidad importante (siempre dentro de partidas lentas), luego de calibrar, la misma aplicación detecta cuando esta todo el tablero armado y emite un pitido, de ahi en mas, espera a que se hagan movimientos y detecta cambios de fichas.
Es importante tener en cuenta cómo se debe de armar el tablero, dado que la detección es automática. Se ha de poner una ficha en el medio del tablero (no importa de qué jugador) y colocar el resto de las piezas en su lugar, cuando esten todo pronto para empezar la partida, se coloca la pieza que se encuentra en el medio del tablero en su lugar, y se espera a que el dispositivo emite un pitido, indicando que se puede comenzar a jugar.
Consideraciones sobre la Solución
A continuación se describe el ambiente utilizado para desarrollar.
La solución que se llegó fue más acotada de lo que se planteó en un inicio, dado que se hizo énfasis en el procesamiento de las imágenes y no tanto en el problema, es que actualmente (Julio 2014) la aplicación solo detecta donde hay fichas y luego de cada movimiento de un jugador manda una matriz 8x8 binaria indicando donde hay o no fichas si hubo un movimiento efectivo.
Otra consideración importante para el uso de la aplicación es la iluminación, la misma debe de ser uniforme. Dado que era una de las precondiciones del proyecto, no se tuvo en cuenta en ninguno de los algoritmos de procesamiento de imágenes.
Otro hecho a tener en cuenta para el uso de la aplicación es el tamaño del tablero y la altura donde debe de estar el dispositivo para poder ver todo el tablero.
La calibración no es automática, se debe de decirle a la aplicación que debe de calibrar para detectar el tablero, luego de detectarlo emite un pitido y el dispositivo no puede ser movido de esa posicion, asi como tampoco se permite la re-calibración luego de iniciada la partida. Es importante apreciar que el plano de la cámara debe de ser paralelo al plano del tablero y que éste más una margen de un escaque han de aparecer en la imagen de la aplicación. No importa de què lado van a estar las fichas con respecto al dispositivo, pero si la rotación del tablero con respecto al mismo, lo ideal es que las líneas del tablero sean paralelas a los bordes de la imagen, aunque la aplicación puede soportar una pequeña rotación del mismo con respecto a esta alineación, siempre que se consideren los márgenes antes mencionados.