Medir distancias con un ratón de bola

En el futuro quiero publicar un experimento para el que necesito tomar muestras de sonido a intervalos regulares durante una distancia de, pongamos, un metro. Así que estoy buscando una forma de medir distancias que sea automática y, a ser posible, que tenga menos error que si la distancia la mido a mano.

La primera forma que probé fue usando un motor paso-a-paso: un PIC iba transmitiendo en cada momento el número de pasos y así el PC tendría información sobre la distancia recorrida. A primera vista es buena idea, el problema es que los motores paso-a-paso son muy ruidosos, y ese ruido lo captaba el micrófono e invalidaba la prueba. No sirve.

El siguiente método que pensé es moviendo el micrófono a velocidad constante a lo largo del recorrido, por el tiempo transcurrido se podría deducir la posición. ¿Habéis intentado alguna vez mover un brazo a velocidad lenta y constante durante metro y medio? Me puse a pensar en otros métodos: empleando un sensor de ultrasonidos, por ejemplo, como el que se usa en los robots; grabando con una cámara al mismo tiempo que movía el micrófono...

Lo mejor sería con un encoder óptico, que es muy sensible y no hace ruido ninguno. El problema es que son componentes muy pequeños y ópticos, por lo que la alineación es muy importante y por eso son difíciles de construir. Fue entonces cuando caí en la cuenta de que podía conseguir muy fácilmente un dispositivo con dos encoders perfectamente funcionales ya montados, con un driver estándar para PC y con una botonera de tres botones como extra.

Ratón de Paco, gracias Paco



El hardware

Casi nadie quiere ya un ratón de bola. Después de mendigar por el departamento de sistemas, Paco Centollo -nombre ficticio, por supuesto- donó amablemente y para beneficio de este blog y de toda la humanidad, no sólo un ratón de bola calidad suprema, sino también un práctico conversor PS2 a USB.

Antes de meterme en faena os voy a contar cómo funcionan los ratones mecánicos. La explicación también sería válida para un servo, porque lleva un mecanismo parecido; y también para una impresora, aunque en ese caso el encoder es casi siempre lineal, no rotativo.

El encoder -y yo uso la palabra encoder aunque en español debería decirse "codificador óptico"- consta de un led y un fotodiodo, como podéis ver en esta imagen. El led es el componente de color claro, casi translúcido, y el fotodiodo es negro.


Entre los dos hay una rueda que tiene ranuras muy finas, las cuales van interrumpiendo la luz que llega al receptor. A más velocidad, más veces por segundo se interrumpe el rayo luminoso.



El truco está en que el fotodiodo es doble. Lleva un fotodiodo arriba y otro igual debajo. Así puede no deducir la velocidad a partir de la frecuencia con que se interrumpe la luz, sino también la dirección del movimiento: si primero se corta la luz en el fotodiodo inferior y luego en el superior, ese lado de la rueda está subiendo. Si primero se corta arriba y luego abajo, entonces está bajando ese lado de la rueda.

Hay dos sensores iguales y perpendiculares, uno para cuando el ratón se mueve en la mesa siguiendo el eje X (izquierda/derecha) y otro para el eje Y (arriba/abajo). Como la rueda está fijada a un rodillo en contacto con la bola, cuando el ratón se desplace se podrá saber la dirección y velocidad del movimiento.

El circuito integrado que incorpora transforma los impulsos de luz en pulsos digitales y los envía al PC en forma de eventos. Más abajo hablaremos de la forma de interpretar dichos eventos.

Mi intención es abrir el ratón, quitar la bola y hacer pasar un hilo por uno de los rodillos, por ejemplo el del eje vertical. Tal que así:

Detalle del hilo que usaremos para medir

Con el ratón sujeto o atornillado a la tabla, en un extremo del hilo anudaremos la punta de un destornillador pequeño y del otro colgaremos un contrapeso ligero. Al mover el destornillador una distancia determinada, arrastrará el rodillo y registraremos la posición con un programa.



El software

En general, cuando un ratón -o cualquier dispositivo de entrada- tiene algo que decir, envía un código. Este código queda en una cola de eventos a la espera de ser recogido. El driver recoge la señal y la pasa al sistema operativo, y el sistema operativo tiene una interfaz donde los programas interesados pueden recibir los eventos que se generan. En Linux los eventos se componen de tres variables: tipo de evento, código del evento y valor. Para un ratón los eventos con los que vamos a trabajar son:

Movimiento relativo (EV_REL): Indica movimiento relativo del ratón. Se llama relativo porque su valor indica el desplazamiento en una dirección u otra. Hay otros dispositivos señaladores que tienen el evento de posición absoluta, como por ejemplo una tableta gráfica. Pero en el caso de los ratones siempre es movimiento relativo. Este evento tiene como subtipo (o código) el eje al que se refiere. Generalmente los ratones tienen dos ejes llamados X e Y. El desplazamiento de la rueda puede considerarse otro eje, aunque tradicionalmente se considera como dos botones más. El valor de este evento indica cuantos pulsos se han contado en el desplazamiento. Este valor depende del diseño del ratón y es la causa de que unos ratones sean más rápidos o más sensibles que otros. Puede ser negativo o positivo según sea el sentido del desplazamiento.

Pulsación de botón (EV_KEY): Se envía cuando cambia el estado de alguno de los botones, es decir, cuando se pulsa o se libera un botón. Su código corresponde al botón que se ha pulsado. Y su valor puede ser 1 o 0. Es 1 si el botón está presionado, y es 0 si lo que hemos hecho es liberarlo.

Sincronismo (EV_SYN): En ocasiones se pueden dar varios eventos simultáneamente. Por ejemplo mientras movemos el ratón en ambos ejes (diagonalmente) y con un botón pulsado (arrastrando), movemos la rueda con el otro dedo. El evento de sincronización se envía cuando han terminado de enviarse todos los eventos que el dispositivo tuviera en cola en ese momento.

Ejemplo 1:
Si apretamos el botón izquierdo con el ratón quieto se generará un evento EV_KEY, cuyo código (subtipo) será BTN_LEFT y cuyo valor será 1. Seguido inmediatamente por un evento EV_SYN indicando el fin de la transmisión.

Ejemplo 2:
Si movemos el ratón lentamente en diagonal se generarán eventos EV_REL.
Primero con subtipo X y luego con subtipo Y cuyo valor será un número bajo normalmente 1 o -1 dependiendo de la dirección. Y tras ellos un evento EV_SYN. Es decir la secuencia sería:
EV_REL REL_X 1
EV_REL REL_Y 1
EV_SYN
EV_REL REL_X 1
EV_REL REL_Y 2
EV_SYN
EV_REL REL_X 1
EV_REL REL_Y 1
EV_SYN

Ejemplo 3:
Si hacemos clic con el botón derecho sin mover el ratón tendríamos la secuencia:
EV_KEY BTN_RIGTH 1
EV_SYN
(pausa)
EV_KEY BTN_RIGTH 0
EV_SYN.


Sabiendo esto he escrito un programita que lee los eventos y reacciona de la siguiente manera:
  • Antes de nada deshabilita el ratón en Xorg, para que los movimientos y los clics no actúen sobre la interfaz gráfica.
  • Cuando recibe un clic del botón derecho reinicia las coordenadas a 0, crea un nuevo fichero de log y comienza el modo grabación. Al siguiente clic detiene la grabación y cierra el fichero.
  • Cuando recibe un clic con el botón izquierdo inserta una marca en el log, indicando la hora y la posición actual.
  • Cuando recibe eventos de movimiento relativo actualiza las coordenadas X e Y en función del valor recibido.
  • Si el modo grabación está activo, escribe las coordenadas actuales en el fichero a razón de 10 veces por segundo.

El código es el siguiente. No creo que merezca la pena comentar nada a excepción quizá de las constantes para los tipos de eventos de las que ya hemos hablado y las líneas 112 y 117 que habilitan y deshabilitan el ratón en Xorg. También es interesante leer la documentación de Linux::Input en http://search.cpan.org/~beppu/Linux-Input-1.03/lib/Linux/Input.pm.


#!/usr/bin/perl 
#===============================================================================
#
#    FILE:  odometer.pl
#
#   USAGE:  ./odometer.pl id_event id_xinput
#
#  DESCRIPTION:  Medidor de distancias con el ratón.
#
#
#    OPTIONS:  ---
# REQUIREMENTS:  ---
#    BUGS:  ---
#   NOTES:  Consultar la documentación de Linux::Input
#  AUTHOR:  Reinoso G.
#    COMPANY:
#    VERSION:  2.0
#    CREATED:  28/12/13 17:25:49
#   REVISION:  01/07/15 18:10:12
#===============================================================================

use strict;
use warnings;
use Linux::Input;
use Switch;
use Time::HiRes;


use constant {
 EV_SYN    => 0x00,
 EV_KEY    => 0x01,
 EV_REL    => 0x02,
 EV_ABS    => 0x03,
 EV_MSC    => 0x04,

 REL_X    => 0x00,
 REL_Y    => 0x01,

 ABS_X    => 0x00,
 ABS_Y    => 0x01,

 BTN_LEFT   => 0x110,
 BTN_RIGHT  => 0x111,
 BTN_MIDDLE => 0x112,
};

my $polltime = 0.001; # segs
my $X = 0;
my $Y = 0;
my $logprefix = "/tmp/log_odometer";
my $logtimer  = 0.1; # segundos entre cada registro de estado


my $logfile;
my $logfh;
my $rec = 0; # indica si estamos grabando los movimientos

# --- Bucle ---
$| = 1;
my $id_event  = $ARGV[0] || usage();
my $id_xinput = $ARGV[1] || usage();

my $device = Linux::Input->new("/dev/input/event$id_event");

x_disable_device($id_xinput);
$SIG{INT} = \&ordered_exit;

print "Pulsa Ctrl+C para terminar la ejecución.\n";

my $t0 = Time::HiRes::time;

while (1) {
 foreach my $ev ($device->poll($polltime)) {
  switch($ev->{type}) {
   case EV_KEY { on_key($ev) }
   case EV_REL { on_rel($ev) }
   case EV_SYN { on_syn($ev) }
  }
 }

 my $t1 = Time::HiRes::time;
 if ($t1 - $t0 >= $logtimer) {
  $t0 = $t1;
  $rec and printf $logfh "%.3f\t%d\t%d\n", $t0, $X, $Y;
 }
}

sub usage {
 print "
Uso: $0 id_dev id_x
  id_dev   número de fichero /dev/input/eventX
  id_x     identificador de dispositivo en Xorg

Para averiguar id_dev basta ejecutar 'evtest.pl /dev/input/event<X>' hasta
dar con el fichero del dispositivo.

Para averiguar id_x basta ejecutar xinput y buscar el id= correspondiente.
";
 exit;
 
}

sub ordered_exit {
 x_enable_device($id_xinput);
 print "\n";
 close $logfh;
 exit; 
}

sub x_disable_device {
 my $id = shift or return;
 `xinput disable $id`;
}

sub x_enable_device {
 my $id = shift or return;
 `xinput enable $id`;
}

# Evento de botón (press or released)
sub on_key {
 my $ev = shift;
 switch ($ev->{code}) {
  case BTN_RIGHT  { on_btn_right($ev)  }
  case BTN_LEFT   { on_btn_left($ev)   }
  case BTN_MIDDLE { on_btn_middle($ev) }
 }
}

# Evento de movimiento relativo
# Los ratones no tienen movimiento absoluto, las tabletas sí
sub on_rel {
 my $ev = shift;
 switch ($ev->{code}) {
  case REL_X { on_rel_x($ev) }
  case REL_Y { on_rel_y($ev) }
 }
}



# --- Funciones de usuario ---
sub on_rel_x {
 my $ev = shift;
 $X += $ev->{value};
}

sub on_rel_y {
 my $ev = shift;
 $Y += $ev->{value};
}

sub on_syn {
 my $ev = shift;
 if ($rec) {
  printf "%.3f\t%d\t%d\n",
   $ev->{tv_sec} + $ev->{tv_usec} * 1E-6,
   $X,
   $Y;
 }
}

# Reinicia las coordenadas
sub on_btn_right {
 my $ev = shift;

 return if $ev->{value} == 0; # sólo actuar en la pulsación

 $rec = 1 - $rec;

 if ($rec) {
  my $rand = int(100 + 900*rand);
  $logfile = $logprefix ."_". $rand . ".log";
  open $logfh, ">>", $logfile or die;
  print STDERR "Grabando: $logfile\n";
  $X = 0;
  $Y = 0;
 }
 else {
  print STDERR "Grabacion terminada: $logfile\n";
  close $logfh;
 }
}

sub on_btn_left {
 my $ev = shift;
 return if $ev->{value} == 0; # sólo actuar en la pulsación
 printf $logfh "%.3f\t%d\t%d\t-mark-\n", Time::HiRes::time, $X, $Y;
 printf STDERR "%.3f\t%d\t%d\t-mark-\n", Time::HiRes::time, $X, $Y;
}

sub on_btn_middle {
 my $ev = shift;

 print "btn_middle not assigned\n";
}



Para invocar el programa hay que proporcionar dos parámetros, ambos numéricos. El primero es el identificador de dispositivo del kernel. En función de este parámetro el programa leerá los eventos del fichero /dev/input/eventX. El segundo es el identificador del dispositivo en Xorg, y servirá para habilitarlo y deshabilitarlo durante la ejecución.

Para esta prueba tendremos dos ratones, el ratón habitual que usaremos como siempre, y el de bola para las medidas. Sucede que los ratones y los teclados pertenecen a una clase especial de dispositivos USB llamados HID (Human Interface Devices). VMWare crea un único dispositivo de entrada virtual con todos los HID que encuentra en el sistema anfitrión y los unifica. Nos viene mal porque para este experimento necesitamos tener un ratón funcional y otro dedicado a medir que no mueva el cursor ni haga clics donde no debe. Para que VMWare trate los dispositivos HID como cualquier otro USB y nos deje conectarlos y desconectarlos a nuestro antojo hay que añadir estas dos líneas al fichero de configuración de la máquina virtual:

usb.generic.allowHID = "TRUE"
usb.generic.allowLastHID = "TRUE"


Medir distancias

Como habíamos descrito al principio, tenemos un hilo que pasa por el rodillo vertical y está atado a una punta delgada, un destornillador pequeño en nuestro caso.

Lo que vamos a hacer es comenzar la grabación y, con ayuda de un metro fijo a la mesa, ir moviendo el destornillador cada centímetro y poniendo una marca en el log. Cuando hayamos recorrido ya varios centímetros terminaremos la grabación y procesaremos el log. Este es el resultado:


Medida a intervalos de 1cm (clic para ampliar)

Calculando la pendiente de la recta de regresión resulta que se avanzan 146 pulsos por cada centímetro recorrido. En una segunda prueba el resultado es 145, es normal que la medida varíe un poco. Para tener más precisión repetimos la misma prueba pero esta vez de 10 en 10cm.


Medida a intervalos de 10cm (clic para ampliar)

El resultado es 1451 pulsos cada 10cm. Concretamente el intervalo de confianza al 95% está entre 1446 y 1456. Nos quedaremos con la media que para nuestros fines es suficiente. Esto es 145.1 pulsos por cm. O sea ¡un pulso cada 0.07mm!

Y esta es otra ocasión propicia para resaltar, una vez más, la diferencia entre precisión y exactitud. Usando un ratón la medida es muy precisa, notaremos cuando haya un cambio de tan sólo 0.07mm. Y al calcular la posición a partir del número de pulsos son saldrán hasta tres cifras decimales. Muy preciso todo.

Ahora bien, del ajuste se puede deducir el error promedio y según parece las medidas se desvían en promedio alrededor de 1mm por arriba o por abajo de la medida real. Cierto es que este error es tan pequeño que bien podría estar causado por nosotros mismos al situar la punta un milímetro antes o después. Y, por supuesto, ni que decir tiene que variar 1mm a lo largo de un recorrido de 70cm es un resultado muy bueno.

Si embargo la clave aquí está en que sólo podemos fiarnos de la medida hasta el orden de los milímetros, por mucho que la precisión sea de menos de una décima.


Posiciones y velocidades

Ahora que sabemos que cada centímetro vienen a ser 145 pulsos vamos a graficar una de las pruebas de 10cm. El primer gráfico será de la posición respecto al tiempo.


Gráfico posición/tiempo (clic para ampliar)

Se ve que al aproximarse a un múltiplo de 10cm hay una pausa, se pone la marca y se continúa hasta el siguiente punto. Se aprecia muchísimo mejor en un gráfico de velocidad/tiempo. Recordad que la velocidad instantánea se calcula como la derivada de la posición respecto al tiempo.


Gráfico velocidad/tiempo (clic para ampliar)

Aquí se ve que al salir de un punto salimos con mucha velocidad, llegando a alcanzar una velocidad media de 2 - 2.5 cm/s. Y al aproximarnos al siguiente punto paramos haciendo pequeños ajustes, que son los picos que se ven en las pendientes descendientes. A medida que avanza la prueba tenemos más confianza y por eso las velocidades medias van siendo mayores.


Velocidad máxima

Ya os he contado antes cómo se sabe si hay movimiento y hacia dónde. Si primero se interrumpe la luz abajo y luego arriba, pues es en un sentido; si ocurre al revés, en el otro.

¿Sabéis eso que pasa en el cine con las ruedas de los coches que a veces parece que van al revés? Los ingleses lo llaman Wagon Wheel Effect (https://en.wikipedia.org/wiki/Wagon-wheel_effect) y se debe a la velocidad de muestreo. Pues lo mismo va a pasar con nuestra rueda del ratón. Si aumentamos la velocidad llegará un momento en que el sensor óptico, por la velocidad de muestreo que usa, verá la ruda girar en sentido contrario, y de repente la distancia recorrida empezará a decrecer en lugar de ir aumentando. Algo así:


Gráfico posición/tiempo excediendo la velocidad máxima (clic para ampliar)

La imagen anterior está hecha tirando del hilo cada vez más deprisa. Y sabido este hecho cabe preguntarse cuál es la velocidad máxima para tenerlo en cuenta. Si en lugar de la posición, graficamos la velocidad en función del tiempo, llegará un momento en que se invierte y de ser positiva pasa a ser negativa bruscamente. Ese punto nos indicará claramente cuál es la velocidad máxima. En este caso ronda los 50cm/s.


Al exceder la velocidad máxima, esta cambia de signo (clic para ampliar)



Atwood

Aprovechando el montaje, esta vez en lugar de tirar yo del hilo con la mano, voy a atar un peso en el extremo y lo voy a dejar caer. En los breves instantes hasta que se alcanza la velocidad máxima esperamos un Movimiento Uniformemente Acelerado debido a la fuerza de la gravedad. En este caso, con velocidad inicial nula, la distancia recorrida en función del tiempo sigue la ecuación de una parábola:

\[ s = {1 \over 2} a t^2 \]

Y eso es precisamente lo que obtenemos, los datos se ajustan a una parábola con muy poco error:


Ajuste de MUA a ecuación parabólica (clic para ampliar)

Ahora bien, si calculamos el parámetro a en la ecuación, que sería la aceleración, no va a salir 9.8m/s² como cabría esperar. Y no va a salir eso porque primero, hay un rozamiento bastante grande; y segundo porque no es una caída libre sino que al otro extremo hay un contrapeso.

En 1784 un matemático inglés llamado George Atwood quería comprobar la segunda ley de Newton. Esta ley dice que la aceleración de un cuerpo es directamente proporcional a la fuerza que se le aplica e inversamente proporcional a su masa. La única aceleración constante que tenía a mano era la fuerza de la gravedad. El valor de la aceleración gravitatoria ya estaba bien estudiado por Galileo, que lo había medido muchos años antes dejando caer bolas por planos inclinados y objetos desde cierta altura.

El asunto es que los cronómetros por entonces no eran como ahora y claro, medir el tiempo que tarda algo en caer con una aceleración de casi 10m/s² era complicado. Así que tenía que encontrar la manera de reducirla. Lo que sí estaba más avanzado eran las balanzas. Y lo que hizo fue poner dos pesos atados con una polea:


Esquema de la máquina de Atwood. Wikipedia.

Como medir pesos era por entonces más fácil que medir tiempos, podía regular la aceleración y obtener resultados más exactos. La fórmula concreta para la aceleración en función de los pesos, si os interesa, se puede ver en la Wikipedia: https://en.wikipedia.org/wiki/Atwood_machine



Nada más de este tema por ahora. Espero que os haya gustado. Como siempre, los archivos y programas propios utilizados para la elaboración de este artículo podéis descargarlos de aquí: https://sites.google.com/site/electronicayciencia/ratonbola.zip

Artículo completo >>

Los dominios de la entropía

Hace un montón que no publico un artículo, tanto que casi no me acuerdo de escribir, así que: Hola de nuevo.

Hoy vamos a hablar de uno de esos conceptos que levanta pasiones entre los aficionados a los palabros sin demasiada preocupación por su significado: la entropía. Si conoces este concepto y has visto documentales sobre universos paralelos y viajes en el tiempo lo siento mucho, este artículo no te va a gustar, porque va de estadística.

La entropía es un concepto físico muy fácil de comprender, lo que pasa es que alrededor de él se han escrito tantísimas cosas (con más o menos sentido artístico) que buena parte de lo que se dice es un misterio.

Artículo completo >>

Cómo funcionan las etiquetas magneto-acústicas (o acustomagnéticas)

En esta entrada quiero hablaros de un sistema anti hurtos que casi todos habréis visto. Se utiliza desde hace unos años en muchos establecimientos para productos que antes no contaban con estas medidas de seguridad.


Se trata de las etiquetas magnetoacústicas (o acustomagnéticas) como las de la imagen. Veremos qué tienen por dentro. Os explicaré cómo funciona todo el sistema (activación/detección/desactivación/reactivación) y, como en este blog nunca nos quedamos en la teoría, también construiremos un pequeño arco anti-hurtos casero para probar todo eso.

Os aviso de que esta va a ser una entrada extensa. Quizá la más extensa de todo el blog. Hablaremos de imanes, fenómenos electromecánicos, de resonancia, de circuitos LC sintonizados, construiremos nuestro arco anti-ladrones y terminaremos programando una interfaz en Perl/TK para filtrar y detectar la señal por medio de técnicas sencillas de Procesado Digital (DSP).

De lo que no hablaremos es de cómo burlar los sistemas.

Artículo completo >>

Mezclador de frecuencias con el integrado 4066

Hoy describimos un circuito mezclador o multiplicador de frecuencias. Un circuito relativamente ignorado por muchos aficionados a la electrónica pero muy importante. Tan importante que es una parte fundamental de casi todos los receptores de radio (incluyendo radios, televisores, conversores de satélite, walkie-talkies, etc): receptor heterodino .

La finalidad de estos esquemas es tomar una señal de entrada -cuya portadora estará en una frecuencia elevada- y multiplicarla por una señal proveniente del oscilador local -cuya frecuencia podemos variar fácilmente-. De forma que al multiplicar dos frecuencias, como ya vimos en la entrada anterior La Distorsión Armónica Total (THD), el resultado son otras dos frecuencias: la suma y diferencia de las anteriores.

Vamos a utilizar este circuito, no para hacer un receptor de RF, sino para un propósito más sencillo: poder captar con la tarjeta de sonido señales por encima de 20KHz que es el límite ultrasónico.

Artículo completo >>

La Distorsión Armónica Total (THD)

Cualquier aficionado a la música o a la electrónica conoce lo que es la distorsión. En este artículo hablaremos de la importancia de la no linealidad en la distorsión y de cómo se mide si un amplificador distorsiona más o menos que otro.

Haremos un recorrido empezando por los amplificadores ideales. Llegaremos a los no ideales y ahí encontraremos el desarrollo de Taylor. Veremos qué efecto tienen los términos de orden superior sobre una señal de entrada sinusoidal; primero matemáticamente y luego con un circuito de ejemplo. Compararemos un amplificador bien diseñado con uno mal diseñado y veremos los parámetros que caracterizan un circuito de este tipo, incluida la THD.

No quiero usar matemáticas complicadas en este artículo. Procuraré hacerlo de la forma más básica aunque sea más largo y en ocasiones incorrecto. Si alguna explicación no la pilláis, mirad los gráficos y todo será más fácil de entender. Recordad que haciendo click en una imagen la ampliaréis. Y si queréis verla más grande aún, abridla en una ventana nueva.

Artículo completo >>

Reparación de un cd-radio-casete

He pensado que podría empezar este año publicando una entrada en el blog, que lo tengo algo olvidado desde el verano. Así que feliz año nuevo a todos y mis mejores deseos.

Hoy os presento un caso real de una radio que he estado reparando estas vacaciones. Espero que os resulte curioso, o al menos entretenido.

Artículo completo >>

Análisis de las distribuciones de voto en Filmaffinity

Vamos a hablar de cine, también hablaremos de programación, de estadística y tratamiento de datos, todo ello -te lo aseguro- relacionado con el cine. El gusto es algo muy subjetivo, por supuesto, pero hay gustos más y menos comunes así que, por una vez, me vais a permitir ser vuestro crítico de cine.

¿Conoces la web Filmaffinity? No es nueva, y no tengo nada que ver con ella, pero aún así me gustaría presentártela. Déjame que escriba primero una reseña, para que puedas entender todo este artículo que gira en torno a ella.

Para quien no la conozca digamos que es una web muy bien hecha, ideal para descubrir más películas que te puedan gustar. De manera similar a la idea de Last.fm para música, en función de tus votaciones busca usuarios con gustos similares a los tuyos "almas gemelas" y te los presenta para que puedas ver qué más películas han votado estos. Esta era la idea original hace algunos años, junto con la navegación cruzada (pinchas en un actor y salen su películas, en una película y te lleva a su ficha, entre los datos puedes pinchar en su director y aparecen sus películas, en un género, en una lista, etc). Recientemente han incorporado otras funciones muy interesantes.


Artículo completo >>

Convolución de dos imágenes: Homógrafos UTF

En una entrada anterior os decía que en breve presentaría una aplicación de la transformada de Fourier en dos dimensiones. Pues bien, como decíamos ayer, voy a utilizar la transformada, y más concretamente multiplicar dos transformadas, para encontrar patrones dentro de una imagen. Lo que técnicamente se llama Template Matching.


Artículo completo >>

Estadística de los exámenes tipo test

La semana pasada hice un examen tipo test. Eran 150 preguntas y pedían, para aprobar, el 70%. La pregunta es ¿ese 70% tiene su justificación matemática o es más bien un limite arbitrario? Vamos a hablar de cómo interviene el azar al responder preguntas y de las diferentes formas de compensarlo.

Artículo completo >>

Electrocardiograma y electrorretinograma.

Este es un artículo sobre DSP con un trasfondo de electromedicina. En una entrada anterior ya vimos lo que era una transformada de Fourier y cómo se utilizaba. La Transformada de Fourier no es magia. Para entender mejor lo que sigue te recomiendo que la leas si aún no lo has hecho. Hoy vamos a aplicarla para limpiar una señal todo lo que podamos. Pero ¿qué es limpiar? Pues para nosotros es seleccionar, de todo lo que capten nuestros sensores, sólo aquello que nos interesa; eliminando el ruido y otras interferencias.

Este experimento lo hice en el 2006 y consiste en construir un electrocardiógrafo. Pero ya desde el principio os advierto: si bien captar señales eléctricas en el cuerpo es relativamente sencillo, lo difícil es hacerlo bien. Y con hacerlo bien quiero decir que lo que registremos sirva para algo. Cuando un cardiólogo interpreta un electro, espera que los electrodos estén puestos siempre en el mismo sitio, que el gel tenga una conductividad determinada, que el circuito aplique unos filtros ya tipificados (homologación), etc. Así que la forma de onda que nosotros vamos a obtener no va a pasar de ser una mera curiosidad electrónica pues no tiene, ni mucho menos, valor médico alguno.


Artículo completo >>