PFC – Resumen semana #4 y #5

Como cuesta actualizar esto.  Bueno hago un pequeño resumen de estas dos semanas.  Estas dos semanas han estado llenas de problemas.  Para empezar mi relación odio/odio con Windows.  Después de solucionar este asunto, volví de nuevo a ponerme manos a la obra.

Estaba con el tema del dibujado del área de visión de cada wiimote, pero no acabé de solucionar este problema.  El tema del dibujado es bastante problematico cuando tienes que dibujar capas.  Dibujas todo, y luego cuando el usuario cambia algún dato como alguno de los ángulos o la altura del mando, tiene que volver a redibujarse en base a los nuevos datos de entrada, pero al mismo tiempo borrar lo que había antes.  Y esto lo hacía bien, pero al cambiar luego el código para poder dibujar el área del wiimote diera igual el valor del ángulo alfa, me encontré con problemas que de momento no logré resolver.

Es por ello que decidí cambiar de tarea, lo he dejado aparcado para un tiempo más conveniente.  Me puse directamente con el código de la calibración de los wiimotes.  Para explicar esto de la calibración usaré una imagen que encontré en otro blog y me sirve para explicar brevemente el asunto.

Vision distorsionada de un wiimote. 1

El tema son las perspectivas.  Si os fijáis, cuando el wiimote, en la mayoría de los casos, nunca verá de frente el área donde se encuentra nuestro objeto.  De tal forma que siempre lo verá en perspectiva.  Necesitamos crear un código, en el que marcamos cuatro puntos de calibración.  De forma secuencial, iremos iluminando un led infrarrojo en cada uno de esos puntos de calibración para decirle al programa cuáles son los márgenes del área que queremos visionar.  Una vez hecho esto, tenemos que tener presente que lo que ha visto el wiimote no es un cuadrado, tal y como nosotros le hemos marcado, sino un trapecio, por estar viendo todo en perspectiva.

Es por ello que hay que utilizar una serie de cálculos matemáticos para transformar la perspectiva de la imagen obtenida.  Así obtenemos un cuadrado.  Podemos decir que cada uno de los puntos que existen en el trapecio, tiene un equivalente en el cuadrado, asi que convirtiendo las coordenadas x e y del punto infrarrojo cada vez que el wiimote lo vea, estaremos corrigiendo el problema de la perspectiva. Esto se conoce como Homografía. Quizás con esta imagen se vea mejor.

Matriz de homografía. 2

Pues bien, estos cálculos ya están hechos en el código fuente que compartió Johnny Lee, por lo tanto solo hay que aplicarlos.  El caso es que he tenido problemas, y no por los cálculos, sino por la versión del Visual Studio.  Resulta que en la versión 2005 si accedes a un control desde un hilo distinto al que se creó todo funciona bien.  En cambio en la versión 2008 pues el programa da error.  Hasta que encontré que el fallo se debía a esto, pues tarde varios días, más de los que yo quería.

El caso es que ya lo he resuelto.  Encontré dos formas de solucionarlo, una elegante y otra no.  De momento uso la no elegante, más adelante ya veré como puedo implementar la forma elegante.  Ahora seguiré con el tema del código de calibración y coordenadas.  Claro el mando ve el objeto, y para ese objeto tiene unas coordenadas x e y.  Pero dichas coordenadas son relativas al wiimote.  Lo que tengo que hacer es transformar dicha coordenadas relativas a unas absolutas, que me indiquen las coordenadas x e y del objeto respecto de la sala y no del wiimote.  A ver qué consigo :P

Saludos!

P.D: A ver si logro perder menos tiempos con estos problemas… y despertarme más temprano tambien xD

Fuente imágenes: [1] y [2]

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s