Mi Tacómetro High-Tech para Máquinas Herramienta.

[Valen]

Filtro Paso-bajo software, para eliminar las oscilaciones en la medida de la velocidad.

Introducción.
Para que un tacómetro se tenga por bueno, ha de filtrar la velocidad que obtiene a partir de la lectura del sensor, ya que esta variará algo en cada medida.
Las causas de dicha oscilación son variadas, pero principalmente se deben a características mecánicas de las propias máquinas. Si no se corrige este efecto, la lectura mostrada variará constantemente, dificultando su lectura y produciendo un efecto molesto para el operario (nosotros...)

Para realizar el filtrado, se ha de pasar la medida obtenida a través de un filtro paso-bajo, implementado en software. El resultado de su filtrado es lo que se mostrará en la pantalla.

Su proceso de diseño es el siguiente:

Conocimientos Previos.
Para aquellos que quieran refrescar sus conocimientos sobre la "Transformada en S" (llamada también Transformada de Laplace) y la "Transformada en Z", así como la relación que guardan los sistemas continuos con los sistemas discretos, se pueden dirigir a estos enlaces:

Transformada de Laplace.
http://es.wikipedia.org/wiki/Transformada_de_Laplace

Transformada Z.
http://es.wikipedia.org/wiki/Transformada_Z

(Como se puede ver en el contenido de esos enlaces (y en contra de los que algunos defienden en este foro), la tecnología actual es muy compleja, y no es fruto de la acumulación de experiencias anteriores, sino de la investigación pura y dura...)


Implementación del filtro Paso-Bajo para nuestro tacómetro
La operación de filtrado mediante el modelo de ‘Respuesta Impulsional Infinita’ (IIR) se realiza ‘discretizando’ la función de transferencia del filtro analógico equivalente, mediante la Transformada de Laplace.



A partir de la ecuación en ‘s’ se realiza el cambio que ‘discretiza’ la ecuación diferencial (Transformada en Z).



---> de donde:








Coeficientes del filtro

[troll]

Valen como siempre pedazo de trabajo usando circuitos de tipo abierto o general.

Duda: Merece la pena usar el "pro mini" y hacer la placa pcb o usar el nuevo "UNO" y pasar de la placa usando pines directos en las salidas /entradas de este dispositivo. lo digo por el tema de la pcb.

Enhorabuena que nivel que teneissssssssss

[Valen]

@troll:
yo he hecho el desarollo en un Arduino Uno, y a continuación lo he migrado a un Ardunio Mini.

Las razones son varias, por ejemplo, que la placa PCB de diseño propio me permite agrupar los conectores a mi gusto, lo que reduce el cableado a la mínima expresión.

Hay muchos problemillas (no graves) al utilizar un Arduino Uno con los cables enganchados a él. Por ejemplo, la placa solo tiene un terminal (+) al que conectar los sensores, displays, etc, por lo que al final acabas montando un tinglado de cables.
Eso se junta con que las entradas del puerto serie están a un lado de la placa, mientras que los terminales (-) y (+) están al otro lado. Resultado: El cableado del display queda horroroso. Lo mismo le pasa al conexionado de los sensores.

También está el tema del espacio: El Arduino Pro Mini 328 - 5V/16MHz que yo he usado es igual de potente y mide la cuarta parte. Y cuesta más barato...!

Para obtener acabados profesionales, parece lógico prototipar en el Arduino Uno o unArduino Nano 3.0 (ATMEGA328):
http://www.gravitech.us/arna30wiatp.html
junto con esta placa:
http://www.gravitech.us/teadforarna.html
y luego desarrollar una placa PCB propia, que simplifique el conexionado.

(También tengo ese conjunto, y es muy cómodo poder atornillar los cables).

Yo no llamaría al Arduino y a la pantalla OLED, dispositivos de uso general.
En realidad, son dispositivos muy sofisticados, que gracias a la miniaturización y a la reducción de los costes de producción, pueden dar la apariencia de ser productos genéricos. Pero no lo son, ni mucho menos.
Como indico en el hilo, solo la pantalla cuesta 50 Euros, es decir, más que tres Arduino Pro Mini 328 - 5V/16MHz....!

[fausto]

Hola Valen, muchas gracias por contestar a mi pregunta, (con el trabajo que tienes!)
cuando termines todos los estudios y pruebas, cuenta con migo para adquirir una maravilla de estas,
sobre todo tómate el tiempo que necesites (no hay prisa) ya dirás el importe, etc.
Muchas grácias 

[Valen]

Sobre el número de pulsos que ha de generarse por cada revolución del eje.

Para que un tacómetro pueda medir con precisión la velocidad de giro de un eje, es necesario que el microprocesador reciba el mayor número posible de pulsos, por cada vuelta.

Como sabemos, la solución más sencilla para generar dichos pulsos, consiste en pegar un pequeño imán al eje, y emplear como sensor, un sensor de efecto hall, que se caracteriza por entregar un pulso cada vez que el imán pasa por delante de él.

Esta solución es muy sencilla de instalar, y funciona razonablemente bien. Sin embargo, vemos que sólo suministra un pulso por cada vuelta. Eso es también es un problema, porque si hay un error en la media, por ejemplo, un solo pulso más, la velocidad instantánea que estaremos leyendo será el doble...!

Primer caso práctico: Un imán.

* La máquina está girando a 500 rpm, (nosotros no lo sabemos, claro...por eso la vamos a medir)
* En el eje hemos montado un solo imán.
* Cada 600 milisegundos calculamos la velocidad de la máquina, para mostrarla en pantalla.

A esa velocidad, en los 600 milisegundos que dura la toma de la muestra, el tacómetro habrá recibido: (500/60sg) * 0.6 Sg = 5 impulsos desde el sensor.

Si el tacómetro lo tenemos bien calibrado, la velocidad a mostrar será  Velocidad (rpm) = 5 * 100 = 500 rpm

Es decir, una constante de valor 100 es la que nos ajusta los pulsos recibidos, a la velocidad de la máquina. Dicho de otra forma, cada impulso que recibe el tacómetro "vale" 100rpm.

Por tanto, si hay un error, y leemos un pulso de más, la medida sufrirá un gran falseamiento, ya que entonces Velocidad (rpm) = 6 * 100 = 600 rpm ...!!

Vemos que un solo impulso de más o de menos, introduce un gran error en la medición.

También esto nos dice cuál es la resolución de este tacómetro: Es 100 rpm, ya que el incremento mínimo que podemos contar es un solo impulso (lógicamente).

Como conclusión a este ejemplo, diremos que es sencillo de implementar, pero de precisión limitada.


Segundo caso práctico: Cinco imanes.

* La máquina está girando a 500 rpm, (nosotros no lo sabemos, claro...por eso la vamos a medir)
* En el eje hemos montado cinco imanes.
* Cada 600 milisegundos calculamos la velocidad de la máquina, para mostrarla en pantalla.

A esa velocidad, en los 600 milisegundos que dura la toma de la muestra, el tacómetro habrá recibido: (500/60sg) * 0.6 Sg * (5 imanes) = 25 impulsos desde el sensor.
Si el tacómetro lo tenemos bien calibrado, la velocidad a mostrar será.  Velocidad (rpm) = 25 * 20 = 500 rpm

Es decir, una constante de valor 20 es la que nos ajusta los pulsos recibidos, a la velocidad de la máquina. Dicho de otra forma, cada impulso que recibe el tacómetro "vale" 20 rpm.

Por tanto, si hay un error, y leemos un pulso de más, la medida sufrirá un menor falseamiento, ya que entonces Velocidad (rpm) = 6 * 20 = 120 rpm

Vemos que un solo impulso de más o de menos, introduce un menor error en la medición que en caso anterior.

También esto nos dice cuál es la resolución de este tacómetro: Es 20 rpm, ya que el incremento mínimo que podemos contar es un solo impulso (lógicamente).


Como conclusión a estos dos ejemplos, vemos que un pequeño incremento en la complejidad, nos aporta un gran incremento de la precisión.


¿Y cómo funciona nuestro tacómetro?

Como cada uno de nosotros es un mundo, y tiene sus preferencias, he preferido incluir tres "micro-switch" debajo del procesador. Las posibles combinaciones, servirán para indicar al microprocesador si estamos usando un sistema que proporciona un pulso, o dos, o cinco, etc.

Leída esta información, el tacómetro reajusta sus parámetros de cálculo, para adaptarse a cada caso, en aras de ofrecer la medida más fiel posible.

En estas fotos vemos un tacómetro montado, y a al lado, otra placa sin el procesador. De esta forma, se aprecian los tres "micro-switch" de configuración.

[fausto]

Ost... Valen eres un genio!!!, con qué facilidad lo explicas todo, leyéndote parece fácil (que no lo es).

Aunque no creo que nunca podré realizar un trabajo como este se agradecen las explicaciones.

Muchas gracias

[jzurbitu]

Hola valen, me ha encantado todo el proyecto y todo lo que sabes....

Yo en mi trabajo desarrollo el software de los reguladores que controlan los motores de maquina herramienta, asi que tal vez pueda aportar alguna idea a tu proyecto.

Una simplificación de toda la teoría del filtro de primer orden sería : (para los que se hayan perdido con las funciones de transferencia)

 VelocidadEntrada= Lo que hayamos leido en este ciclo del captador
 VelocidadSalida = VelocidadAnterior + (VelocidadEntrada-VelocidadAnterior)*K;
 VelocidadAnterior = VelocidadSalida;
 VelocidadSalida seria lo que hay que mandar a la pantalla

Todo el truco esta en el calculo de la K. Y es relativamente simple:
K = Ts / T;
Siendo Ts = periodo de ejecucion del filtro
            T = tiempo del filtro
Por ejemplo si el periodo de muestreo del micro es de 10 ms y queremos hacer la media de los ultimos 500 ms, K = 10/500;

Respecto al captador, tal vez podria valerte el sensor de posicion de los ratones de bola. (aunque sera mas dificil de acoplar a la mecanica). Funcionan con un diodo infrarojo, un circulo con muchas ranuras (no se, unas 64 o mas) y un fototransistor al otro lado, asi que tendrias 64 pulsos por vuelta. Es una idea... Si te vale es muy muy barato y mucho mas preciso que el iman.

Para el calculo de la velocidad, creo que deberias analizar esta opción.
1) Cuando llegue un pulso guarda en un contador el ciclo en el que ha llegado.
2) Cuando llegue el siguiente pulso, calcula la velocidad como 1 vuelta / (tiempo ahora - tiempo ultimo pulso)
Con esto aumentas la precision del calculo de velocidad, y si lo juntas con un periodo de muestreo mas rapido. Por ejemplo 10 milisegundos (al arduino le sobra cpu) tienes un calculo de velocidad muchisimo mejor.

Ejemplo : (para 600 milisegundos de periodo de muestreo)
0 ms -> No llega pulso -> Velocidad 0
600 ms -> Llega pulso, guardo tiempoUltimoPulso=600ms -> Velocidad=0 (realmente no podemos calcular la velocidad)
1200 ms-> No llega pulso -> Velocidad 0
1800 ms -> Llega Pulso -> Velodidad = 1 / (1.800-0.600) * 60 = 50 rpm
2400 ms -> No llega pulso -> Velocidad = Velocidad Anterior = 50 rpm
3000 ms -> LLega pulso -> Velocidad = 1/(3.000-1.800)*60 = 50 rpm

Lo mismo seria para un pulso cada 12 ciclos por ejemplo y leeriamos velocidad = 100rpm/12 = 8.33 rpm

Esto es una explicacion muy sencilla y si lo vas a implementar te surgiran un monton de dudas. Ya contarás...

[Valen]

Posibles estrategias a la hora de medir la velocidad.

A partir del interesantísimo post de jzurbitu, he decidido a añadir este post con diferentes formas de medir la velocidad, a partir de un sensor y un microprocesador, para que evaluemos sus ventajas e inconvenientes.

(Sorry, como lo he escrito del tirón, todavía lo tengo que revisar... a ver si en un par de días queda bien pulido)

Método 1: Se mide el tiempo entre pulsos.

Opción A:
Condiciones de partida:
Sensor que genera gran cantidad de pulsos.

Cada pulso provoca una interrupción externa, que permite al procesador calcular el tiempo que ha transcurrido desde el pulso anterior.
Sabiendo el número de pulsos/vuelta que generamos, sabemos qué ángulo hemos girado, por lo que podemos calcular la velocidad instantánea.
A continuación filtramos la medida, de forma que se eliminen los puntos atípicos.
Finalmente, cada 600 miliSg (por ej.), realizamos una lectura a la salida del filtro, y lo presentamos en pantalla.

Ventajas: Elevada precisión en la velocidad, al basarse en medidas instantáneas, incluso durante los incrementos y reducciones de la misma. Útil en velocidades muy bajas.
Inconvenientes: Es necesario montar un sensor capaz de trabajar a alta frecuencia, y un sistema que lo active muchas veces en cada vuelta. Las medidas serán en general diferentes, al no estar mediadas, por lo que es necesario filtrarlas.

Opción B:
Condiciones de partida:
Sensor que genera pocos pulsos por vuelta.

Se calcula de la misma forma, pero varían sus ventajas e inconvenientes:

Ventajas: Sencillez. Útil en velocidades muy bajas.
Inconvenientes: A velocidades bajas, la precisión se resiente. Se genera mucho ruido en las mediciones, es decir habrá una gran variabilidad en el valor de las medidas, ya que no son fruto de un mediado. No es un buen diseño para un tacómetro de visualización, si no va acompañado de un filtrado.


Método 2: Muestrear a frecuencia elevada pero constante (por ej, cada 20 mili Segundos).

Opción A:
Condiciones de partida:
Sensor que genera gran cantidad de pulsos (al menos varias decenas por vuelta)

A pesar de que el tiempo de la toma de la muestra es muy pequeño, se leerán varios pulsos en cada muestra, lo que nos permite realizar un cálculo mediado de buena calidad.

A continuación realizamos algún tipo de filtrado a las medidas, de forma que se eliminen los puntos atípicos.
Finalmente, cada 600 mili Sg realizamos una lectura a la salida del filtro, y lo presentamos en pantalla.

Inconvenientes: Es necesario verificar que el sensor es capaz de trabajar a esa frecuencia, y montar un sistema que lo active muchas veces en cada vuelta.
Ventajas: Permite obtener medidas de gran precisión, que siguen fielmente las variaciones que le indiquemos al control, incluso cuando accionamos rápidamente el potenciómetro de control.

Opción B:
Condiciones de partida:
Sensor que genera pocos pulsos.

En un gran rango, puede ocurrirnos que se lea un número insuficiente de pulsos por vuelta, como para medir con la precisión mínima necesaria. Esto limita el rango de medición del tacómetro.

Inconvenientes: No es preciso, es un diseño mal calculado.
Ventajas: ----



Método 3: Muestrear a frecuencia media pero constante (por ej, cada 400 mili Segundos).

Opción A:
Condiciones de partida:
Sensor que genera muchos pulsos.

Obtiene lecturas mediadas correctas, ya que el periodo de muestreo es grande, y hay muchos pulsos por vuelta, por lo que la muestra es de buena calidad. Aún así, conviene filtrarlas.
Dependiendo del número de pulsos, la visualización puede no seguir con tanta rapidez las variaciones bruscas provocadas cuando accionamos rápidamente el potenciómetro de control. (Algo por otro lado, poco relevante en una visualización).

Inconvenientes: El montaje del sensor y su accionamiento es algo más complicado, pero abordable por el aficionado de nivel medio.
Ventajas: Sencillo de implementar con un micro modesto. Es el caso ideal, para un tacómetro de visualización. (En mi opinión).


Opción B:
Condiciones de partida:
Sensor que genera pocos pulsos.

Compensa la falta de pulsos por vuelta con un mayor periodo de muestreo. Como contrapartida, será perezoso a la hora de actualizar los cambios producidos al accionar el mando del motor para subir o bajar la velocidad. Sin embargo, en un tacómetro para visualización, las frecuencias de las que estamos hablando pueden llegar a ser suficientes para que el operario obtenga una lectura correcta.

Inconvenientes: Pocos, si el número de pulsos es de al menos cuatro o cinco. Pero al disminuir el número de pulsos, disminuye la precisión y la resolución, de manera muy apreciable.
Ventajas: El montaje del sensor es muy sencillo.



¿Y qué hacemos con velocidades extremadamente bajas, digamos 15 rpm?
Existe una aplicación realmente importante para el método de medir tiempo entre pulsos, y es la medida de velocidades de giro extremadamente bajas.
(Si lo hiciéramos muestreando durante periodos de tiempo fijos, podría ocurrir que en ese tiempo no se recibiese ningún pulso).
Esta forma de trabajar genera mucho ruido, ya que cada medición será algo diferente, por lo que es imprescindible un filtrado.

También existen estimadores software especializados para máquinas que giran muy lentamente. El estimador emplea un modelo matemático del motor a controlar, que previamente habremos tenido que caracterizar con precisión. Una vez obtenido, se puede inferir la velocidad de giro a partir del consumo de corriente.



¿Y qué hacemos con velocidades extremadamente altas, digamos 25.000 rpm?
Es más complicado de lo que pueda parecer, ya que los sensores habituales no son capaces de trabajar con frecuencias tan elevadas como sería necesario para generar varios pulsos por vuelta. Por ejemplo, el sensor de efecto hall de las fotos es capaz de trabajar hasta 15.000 pulsos, por lo que se quedaría muy corto.

Una solución habitual es utilizar estimadores software. El estimador emplea un modelo matemático del motor a controlar, que previamente habremos tenido que caracterizar con precisión.
A partir del consumo de corriente, se puede inferir la velocidad con una precisión que llega al 5% de error. Más que suficiente para muchos casos.



¿Y qué hacemos si necesitamos un amplísimo margen de lectura?
Como hemos visto en las explicaciones anteriores, disponer de un amplísimo margen de lectura es más complicado de lo que pueda parecer a primera vista. Se recomienda combinar estrategias, de forma que velocidades bajas se midan con una técnica específica, mientras que para velocidades altas, se mida con otra adaptada a ese caso.


Más información:
Aquellos que quieran aprender un poco más sobre métodos de muestreo para velocidades muy bajas, puede leerse la página 10 (entre otras) de este documento de Texas Instruments:
http://focus.ti.com.cn/cn/lit/ug/sprug05a/sprug05a.pdf
 

[jzurbitu]

Ya veo que tanto tu hermano como tu sois unos profesionales en este campo.
El diseño que yo considero ideal y que normalmente se usa en sistemas de alta gama.

1) Un hardware que cuente los pulsos (al ser hardware, su periodo de muestreo es casi 0). La mayoría de micros diseñados para este mundillo tienen ese hardware incluido. (el hardware cuenta los pulsos y el tiempo en el que ha llegado el ultimo pulso)
2) Un software que entra a un periodo de muestreo fijo, no importa que sea rapido o no. El limite sería que no rebose el contaje de pulsos del hardware entre medidas.
Cada periodo de muestreo leerias los pulsos y el tiempo del hardware y calculariamos la velocidad como incremento de pulsos entre incremento de tiempo (medido por el hardware, porque es el tiempo real entre pulsos)
3) Para pintar en la pantalla, evidentemente no se debe pintar muy rapido porque el ojo y las pantallas tienen una persistencia, que harían que se viesen mal. Hay que refrescar la pantalla como muy rapido cada 100 ms, pero medio segundo casi mejor.
4) Ademas el valor a pintar debe estar filtrado, para esto hay multitud de técnicas, la mas común y sencilla es usar un filtro pasa bajos como proponías. Pero también se puede usar una histeresis, redondear la velocidad de 10 en 10 rpms por ejemplo. La idea de tener una velocidad mas precisa, ayuda a que el filtro filtre mejor...

De todas formas ya nos enseñaras con casos reales que te ha funcionado mejor.

Un saludo
Julio

[Valen]

En general, estamos de acuerdo con lo que es mejor y peor para este tipo de diseños. Yo quizás apuntaría un par de cosas más:

La fidelidad en la medida mostrada sí depende de la frecuencia de muestreo, cuando estamos hablando de seguir en tiempo real las variaciones que se producen al accionar el potenciómetro de mando. Un muestreo demasiado lento hace perezosa la actualización del dato en la pantalla. Aunque la verdad es que no tiene mayor importancia.

La actualización demasiado frecuente de la pantalla produce efecto de parpadeo.
Para minimizarlo, se refresca a menos frecuencia, pero sobre todo, se realiza lo que se llama una "virtualización" de la pantalla.

Por ejemplo, si mostramos los datos en un PC, entonces se construye en memoria una imagen exacta de lo que se ve en la pantalla. Sobre ese bitmap, se realizan los cambios que sean necesarios en cada actualización. Solo al final, se vuelca el contenido a la pantalla, para actualizarla.

A veces, si los cambios son pequeños, en áreas muy localizadas, se construyen bitmaps de esa zona. A continuación se actualiza el bitmap, y finalmente se vuelca a pantalla.
Como el volcado de un mapa de bits es rapidísimo, se elimina prácticamente el parpadeo.  (el truco está en la enorme velocidad del volcado de memoria RAM sobre memoria de vídeo)
En el caso de pantallas muy pequeñas, como la mía, se trabaja igual, pero con menos medios. A escala, jajaja

Si vemos funcionar mi pantalla, que funciona con virtualización (básica), tiene cero parpadeo, incluso cuando las cifras cambian muy rápidamente.


En cuanto a los métodos de filtrado, creo que has puesto el orden de complejidad al revés. El método más sencillo es truncar, después redondear, y el más elaborado es filtrar (como es lógico...)

Finalmente no hay que perder de vista que este proyecto pretende ser un gran tacómetro, mucho más avanzado que las cosas chinas que se ven en eBay, pero todavía con un coste accesible a personas.

[Valen]

Caso práctico de filtro paso bajo.

Como veo que el tema del filtro paso bajo software no ha quedado claro, incluyo a continuación el código de ejemplo en C, para el que lo quiera emplear.....
En realidad es la transcripción directa de la demostración que incluí más arriba en este hilo, pero con valores reales, aplicados a un determinando caso:

Ejemplo: Frecuencia de muestreo de 5KHz, y F corte del filtro de 10Hz.

El código está completamente parametrizado, así que cambiando la Frecuencia de muestreo a nuestro caso particular, el resto vale tal y como está.
(la F de corte es mejor no tocarla....)


En el archivo de cabecera (header):

/*--------------------------------------------------------------------------------------*/
// FRECUENCIA DE MUESTREO  DE NUESTRO EQUIPO
//(actualizarlo a cada diseño...!! en este ejemplo se muestrea a 5KHz)         
                                             
#define f                            (float)5000                                                     
#define T                           1.0/f

/*--------------------------------------------------------------------------------------*/
// COEFICIENTES del filtrado de la velocidad                                                     

// Hemos definido  para el filtro una frecuencia de corte de 10Hz, es decir, baja, pero no demasiado,
// ya que lo haría lento en la respuesta.
#define fcorte                  10.0                                   
#define w0                      2.0*3.14159265*fcorte
#define a0                      w0*T/(2.0+w0*T)
#define a1                      w0*T/(2.0+w0*T)
#define b0                      (2.0-w0*T)/(2.0+w0*T)

/*--------------------------------------------------------------------------------------*/
/* Variables empleadas en el FILTRO Paso bajo*/
float Veloc_filtr_k       = 0.0;    // velocidad filtrada                                                 
float Veloc_filtr_k_1   = 0.0;    // velocidad filtrada, estado anterior.                                                   
volatile float Veloc_k  = 0.0;    // velocidad aún sin filtrar
float Veloc_k_1          = 0.0;    // velocidad aún sin filtrar, estado anterior.
/*--------------------------------------------------------------------------------------*/


En el cuerpo de main():

  // Calculamos la velocidad filtrada.
  Veloc_filtr_k = a0*Veloc_k + a1*Veloc_k_1 + b0*Veloc_filtr_k_1;

  // Los valores actuales pasan a ser los valores anteriores.
  Veloc_k_1 = Veloc_k;                // Velocidad aún sin filtrar
  Veloc_filtr_k_1 = Veloc_filtr_k;    // Velocidad filtrada         



La velocidad que acabamos de leer es Veloc_k, y el valor ya filtrado es Veloc_filtr_k, que mostraremos en el display...... El ejemplo es totalmente funcional.

Esta asesoría tan especializada vale mucho dinero....!   

[Valen]

@troll:

Este es el cablerío que se monta al usar un Arduino Uno, durante el desarrollo. Eso sí, es mucho más cómodo para trabajar, porque conecta directamente al puerto USB (el mini necesita un conversor usb-serie, que a veces se cuelga...)

[Octavio]

Me está gustando el tema de este hilo, puede que ahora y gracias a Valen comprenda como funcionan los filtros por software.

Saludos: Octavio

[Valen]

¿Por qué es así un filtro Paso Bajo software?

El problema de los filtros software, a la hora de explicarlos justificadamente, es que no es posible hacerlo evitando las transformadas de Laplace y las transformadas en Z.

Es decir, no es posible explicar su diseño con las matemáticas que usamos todos los días. Lo que les hace tan especiales, es que la salida del filtro depende de la entrada, y de lo que hubo a la entrada y a la salida en el pasado...! ¡Nada menos..! El problema no parece sencillo de modelizar.....

De hecho, este tipo de diseños no se pudo abordar hasta mediados del siglo XX, cuando los matemáticos descubrieron que determinados problemas que no se podían resolver en el campo de los números reales (los que usamos todos los días), sí admitían, sin embargo, una solución en un campo de números imaginarios (como cambiarte a otra dimensión, vaya), y una vez resuelto con las reglas que rigen ese campo imaginario, entonces traerte la solución al campo de los números reales. ¡Y funciona!

Si nos fijamos en la demostración que incluí un poco más arriba, veremos que hemos pasado a un campo de números imaginarios continuos (mediante la Transformada de Laplace) y desde él, hemos pasado a uno imaginario de valores discretos  (Transformada en Z)..... Entonces hemos resuelto el problema en ese campo imaginario, y finalmente nos hemos traído el resultado al campo de los números reales. Estos chicos de Matemáticas son la pera...!


Sin embargo, al ser totalmente equivalentes a una R y un C en un circuito eléctrico, podemos hacer ese paralelismo, que es totalmente válido:



es decir, este paralelismo no es una cosa aproximada, sino que es exactamente lo mismo, un filtro recibiendo datos, y el otro señal eléctrica...


Por otro lado, es curioso como la ecuación del filtro software:

Veloc_filtr_k = a0*Veloc_k + a1*Veloc_k_1 + b0*Veloc_filtr_k_1;

Puede parecer la ecuación de una recta, ya que no hay términos al cuadrado o al cubo. Uno puede pensar "Bah... ya ves, es un polinomio de toda la vida...tanta transformada en Z y de Laplace, para esta cosa tan sencilla, jajaja."

Sin embargo, esto no es así, ya que el "truco del almendruco" está en que los datos que se emplean son, tanto los actuales como los de la medida anterior, es decir, el valor filtrado actual depende de 3 variables, cuyos valores usados no coinciden en el tiempo...!

Bien pensado, es una maravilla....

[Valen]

Bueno, y ya estamos haciendo gráficas, para comparar el tacómetro de Optimum, con el nuestro.

La principal diferencia es que Optimum emplea 5 pulsos por vuelta, mientras que nosotros estamos haciendo estas pruebas con un solo pulso por vuelta, es decir con solo un imán (para la gente que no quiere complicarse la vida montando un sensor con tantos imanes...), aunque nuestro dispositivo se puede configurar para emplear bastantes más.

Nosotros tenemos nuestras armas de última generación, jajaja, ya que a bajas velocidades estamos midiendo la longitud temporal entre pulsos, en vez de muestrear pulsos cada cierto tiempo. Esto nos permite una precisión muy elevada, que luego se pasa por el filtro paso-bajo para eliminar las oscilaciones en el valor final.
En este margen de medidas, es la duración del propio ciclo del programa -fijada por nosotros a un valor constante mediante una interrupción interna- el que nos proporciona el periodo de muestreo constante (T), necesario para calcular los parámetros del filtro.

Los resultados que obtenemos son muy buenos, y su calidad será aún mucho mejor a medida que pongamos más imanes (y configuremos los micro-switch del tacómetro para decírselo).

Estamos calibrando la zona baja de velocidad (rpm), digamos entre 0 rpm y 800-1000rpm, que es la más difícil. (Digo baja velocidad, porque con un solo imán, todavía se generan pocos pulsos por segundo).

Las diferencias en las mediciones de ambos tacómetros son pequeñas, aunque el tacómetro de Optimum es muy "conservador" y le cuesta mucho decidirse a actualizar una medida que ha variado. Creo que esto es porque emplea tiempos de muestreo grandes, con una cantidad enorme de pulsos. El resultado es que montan un tacómetro que me resulta perezoso, que no actualiza frecuentemente las variaciones de rpm, pero que a cambio es muy estable, claro.

Tengo todavía que pedir prestado un tacómetro de alta resolución (como el nuestro) para cotejar los resultados obtenidos. Por ahora he estado comprobando diferentes valores para la frecuencia de corte del filtro paso-bajo software, la resolución máxima con la que la pantalla no está modificándose todo el tiempo (y que en este tramo de rpm irá del 1 al 3%,  como mucho, creo yo), etc.

Fotos:
En la primera se ve la placa usada durante el desarrollo, una Arduino Uno, que es mucho más grande y fea que la que vamos a montar en nuestro producto..... pero es muy buena para prototipar, hacer pruebas, calibraciones, etc.
Al final, el software ya ajustado se carga en la placa Arduino Mini pro, y con eso ya tendremos el tacómetro acabado.




En esta foto, el sensor está peligrosamente cerca de la guía del torno.... ummmmmm.