Eureka!!! ... Continued
Reabro un nuevo post, como dice Rober porque me da la gana y considero que algo que tiene 6 comentarios a partir del cuarto, nadie los sigue leyendo. Dado que esto ha tocado mi fibra sensible, la inventiva, y que además considero un tema bonito de discusión, y no sobre resultados de fútbol voy a continuar con lo que de momento denominaremos "el aparato"...
Primero, el hardware ya lo tenéis ...
Logitech MouseMan Dual Optical Wired Mouse, un poco antiguo pero seguro a buen precio.
Con doble lector óptico, una resolución de 800ppp, sólo un problema, no es cordless.
De comentarios anteriores ...
"no serían necesarios dos lectores"
Es de momento lo único que tengo claro, que si hacen falta dos. Suponiendo que un ratón tiene la capacidad de escaneo de 800ppp, y su area de aplicación es de 1 cm2 en reposo (y ya es mucho suponer), disponemos de una imagen de referencia de 315x315, a un tiempo de reloj de 1/16 de segundo.
¿Como podemos relativamente determinar una rotación? si los puntos centrales, o referencia, describe una curva de desplamiento.
Premisas,
a) La referencia no es un punto, es una matriz cuadrada de 32x32 (unos 4mm^2) para evitar el errores de lectura, de superficie o velocidad de desplazamiento.
b) Cada ciclo de reloj se determina el cambio XY por el desplazamiento de la cuadridula referencia, una vez realizado el cálculo, se envia el cambio relativo, y la nueva matriz referencia es cargada.
asi que, para diferenciar un movimiento rotacional de uno traslacional, deberiamos almacenar los cambios de posición e analizalor para determinar los puntos de una curva, y eso presenta dos problemas a corto plazo:
- o cambiamos el sistema de funcionamiento de un ratón, o si hemos realizado ya cada movimiento como traslacional, que hacemos cuando ya tenemos tres puntos (mínimo para identificar la curva), y por lo tanto ya se han realizado dos movimientos XY, ¿los borramos?, ¿nos vamos hacia atras y lo reconsideramos?. Un planteamiento es trabajar con un sistema desplazado, es decir, no hacer nada y sólo comunicar los resultados ajustando el "timing".
- ¿Quien almacena la serie? y ¿qué punto o zona consideramos centro de la curva para el estudio rotacional?
"es perfectamente factible, y además es fácil de hacer"
No, si facil de hacer es, vamos chupao diría yo (de hecho, el que os menciono podría servir), el problema es que funcione.
Pensamientos, style Brainstorming
Vale, voy a partir de la base que me lo han dado como proyecto de fin de carrera, y hay que sacarlo pá lante.
Hasta ahora tengo claro que podemos partir de:
- Dos lectores, mejor que uno.
- Ambos separados lo máximo posible.
- Uno de ellos, lo más cercano posible a la muñeca, que denominaré lector R, y que controlará las rotaciones, aunque parezca mentira es mejor que el lector de mayor recorrido se encarge de la traslación XY, a esté le llamaré lector XY.
¿Porqué asi y no al reves?
porque a pesar de lo que pensáis el movimiento del ratón actual se produce empleando la muñeca como eje de giro de la mano, a veces, apoyado brevemente por un movimiento del codo. Si cambiaramos su ubicación, la traslación (que consideramos el movimiento más utilizado) que necesita de mayor definición exigiría de un ejercicio físico y mental superior. En definitiva, es mejor culear (con respecto a la muñeca) el ratón para rotar, implicando a más articulaciones que al reves usando sólo la muñeca. ¡Probadlo!.
- El cálculo sería simple, cuando el módulo vectorial (para el que se necesita sólo dos puntos, y por lo tanto se puede realizar relativamente) del lector XY sea inferior al del lector R, el usuario ha movido el brazo o culeado el ratón, y por lo tanto, ha tomado la decisión de giro, en el resto de los casos, se trata de un simple movimiento XY (tanto para módulos iguales, como para cuando el módulo XY sea superior).
- Si lo hacemos de esta manera, NO necesitamos, ni superficie de referencia, ni freno de rotación, ni memoría de desplazamiento.
- La programación vendria a ser algo asi ...
partiendo del estandar de un ratón donde el driver recibe del hardware X,Y -en absoluto- o +/-X/,+/-Y -en relativo- (mayoritariamente más la segunda) por lector via PS2/USB
*** lector 1 -> XY / lector 2 -> R
x1=origen X1;y1=origen Y1;x2=origen X2;y2=origen Y2;
x1'=y1'=x2'=y2'=0
for TRUE
{
read(stdin1); x1'=movimiento relativo x1; y1'=movimiento relativo y1;
read(stdin2); x2'=movimiento relativo x2; y2'=movimiento relativo y2;
moduloXY=sqrt(x1'^2+y1'^2);
moduloR=sqrt(x2'^2+y2'^2);
if (moduloR>moduloXY then rotacion(~) else traslacion(x1',y1');
};
la traslación tan simple como mantener lo ya implementado, la rotación os la dejo para los comentarios.
Ahora, sólo queda patentarlo ...
¿Que os parece?
Primero, el hardware ya lo tenéis ...
Logitech MouseMan Dual Optical Wired Mouse, un poco antiguo pero seguro a buen precio.
Con doble lector óptico, una resolución de 800ppp, sólo un problema, no es cordless.
De comentarios anteriores ...
"no serían necesarios dos lectores"
Es de momento lo único que tengo claro, que si hacen falta dos. Suponiendo que un ratón tiene la capacidad de escaneo de 800ppp, y su area de aplicación es de 1 cm2 en reposo (y ya es mucho suponer), disponemos de una imagen de referencia de 315x315, a un tiempo de reloj de 1/16 de segundo.
¿Como podemos relativamente determinar una rotación? si los puntos centrales, o referencia, describe una curva de desplamiento.
Premisas,
a) La referencia no es un punto, es una matriz cuadrada de 32x32 (unos 4mm^2) para evitar el errores de lectura, de superficie o velocidad de desplazamiento.
b) Cada ciclo de reloj se determina el cambio XY por el desplazamiento de la cuadridula referencia, una vez realizado el cálculo, se envia el cambio relativo, y la nueva matriz referencia es cargada.
asi que, para diferenciar un movimiento rotacional de uno traslacional, deberiamos almacenar los cambios de posición e analizalor para determinar los puntos de una curva, y eso presenta dos problemas a corto plazo:
- o cambiamos el sistema de funcionamiento de un ratón, o si hemos realizado ya cada movimiento como traslacional, que hacemos cuando ya tenemos tres puntos (mínimo para identificar la curva), y por lo tanto ya se han realizado dos movimientos XY, ¿los borramos?, ¿nos vamos hacia atras y lo reconsideramos?. Un planteamiento es trabajar con un sistema desplazado, es decir, no hacer nada y sólo comunicar los resultados ajustando el "timing".
- ¿Quien almacena la serie? y ¿qué punto o zona consideramos centro de la curva para el estudio rotacional?
"es perfectamente factible, y además es fácil de hacer"
No, si facil de hacer es, vamos chupao diría yo (de hecho, el que os menciono podría servir), el problema es que funcione.
Pensamientos, style Brainstorming
Vale, voy a partir de la base que me lo han dado como proyecto de fin de carrera, y hay que sacarlo pá lante.
Hasta ahora tengo claro que podemos partir de:
- Dos lectores, mejor que uno.
- Ambos separados lo máximo posible.
- Uno de ellos, lo más cercano posible a la muñeca, que denominaré lector R, y que controlará las rotaciones, aunque parezca mentira es mejor que el lector de mayor recorrido se encarge de la traslación XY, a esté le llamaré lector XY.
¿Porqué asi y no al reves?
porque a pesar de lo que pensáis el movimiento del ratón actual se produce empleando la muñeca como eje de giro de la mano, a veces, apoyado brevemente por un movimiento del codo. Si cambiaramos su ubicación, la traslación (que consideramos el movimiento más utilizado) que necesita de mayor definición exigiría de un ejercicio físico y mental superior. En definitiva, es mejor culear (con respecto a la muñeca) el ratón para rotar, implicando a más articulaciones que al reves usando sólo la muñeca. ¡Probadlo!.
- El cálculo sería simple, cuando el módulo vectorial (para el que se necesita sólo dos puntos, y por lo tanto se puede realizar relativamente) del lector XY sea inferior al del lector R, el usuario ha movido el brazo o culeado el ratón, y por lo tanto, ha tomado la decisión de giro, en el resto de los casos, se trata de un simple movimiento XY (tanto para módulos iguales, como para cuando el módulo XY sea superior).
- Si lo hacemos de esta manera, NO necesitamos, ni superficie de referencia, ni freno de rotación, ni memoría de desplazamiento.
- La programación vendria a ser algo asi ...
partiendo del estandar de un ratón donde el driver recibe del hardware X,Y -en absoluto- o +/-X/,+/-Y -en relativo- (mayoritariamente más la segunda) por lector via PS2/USB
*** lector 1 -> XY / lector 2 -> R
x1=origen X1;y1=origen Y1;x2=origen X2;y2=origen Y2;
x1'=y1'=x2'=y2'=0
for TRUE
{
read(stdin1); x1'=movimiento relativo x1; y1'=movimiento relativo y1;
read(stdin2); x2'=movimiento relativo x2; y2'=movimiento relativo y2;
moduloXY=sqrt(x1'^2+y1'^2);
moduloR=sqrt(x2'^2+y2'^2);
if (moduloR>moduloXY then rotacion(~) else traslacion(x1',y1');
};
la traslación tan simple como mantener lo ya implementado, la rotación os la dejo para los comentarios.
Ahora, sólo queda patentarlo ...
¿Que os parece?
Comentarios
Pero efectivamente, calcular rotación y traslación a un tiempo es harto difícil, pero no imposible ni mucho menos. Es la clase de cosas que una red neuronal resuelve fácilmente, porque hecho "a pelo" habría que "probar" muchas combinaciones para extraer la que más se ajuste o así.
A mí lo que me llama la atención de un único lector es que es algo sobre lo que puedo probar sin meterme en zarandajas de haedware ni de firmware: teoría pura y dura que es lo que me mola. Pero me apunto a lo que sea.