Quería comenzar un hilo separado concentrándome en suavizar el filtrado y detectar baches y baches con un Arduino y mi acelerómetro. Estoy usando un acelerómetro analógico configurado para un muestreo de ancho de banda de 50 HZ a 100 HZ. Estoy trazando datos con MegunoLink (EXCELENTE herramienta, por cierto). Mi problema es que las lecturas del acelerómetro son muy ruidosas, especialmente en un automóvil con el motor en marcha y el ruido de la carretera. ¿Cuál sería la mejor manera de filtrar el ruido? Estoy muestreando a 100 HZ. No estoy seguro de cómo implementar un filtro que no afecte la frecuencia de muestreo... Además, no estoy seguro de si 100 HZ es suficiente para muestrear, aunque parece captar los eventos de choque bastante bien. (gráficos publicados).
El acelerómetro es un KXPS5-3157
Convertí la salida del acelerómetro a Gforce, ¿debería usar Gforce, o debería usar voltaje sin procesar o no importa para la aplicación de baches?
Aquí está mi código hasta ahora:
#include <GraphSeries.h>
GraphSeries g_aGraphs[] = {"Z"}; //Z acceleration graph label for Meguno
// GLOBALS
long previousMillis = 0;
long interval = 10; // interval in milliseconds (10ms => 100Hz)
int data = 0;
//CALIBRATION DATA FOR ACCELEROMETER
float one_G = 647.0; // OFFSET OF 1G Z axis
float neg_G = 372.0; // OFFSET OF -1G Z axis
// Our ZERO G Reference should be in the middle of these two readings
float mZ = (one_G + neg_G) / 2.0; // ZERO_G REFERENCE FOR Z AXIS
// Estimate Z axis specific sensitivity difference of 2G between readings
float senZ = (one_G - neg_G) / 2.0;
float sensitivity = 440.0; // FROM DATASHEET TYPICAL SENSIVITIY 440mV/G
void setup()
{
// The data is sent via the serial port. Initialize it.
Serial.begin(115200);
analogReference(EXTERNAL); // ACCELEROMETER IS 3.3VOLT
}
void loop()
{
ReadAccelerometer();
}
void ReadAccelerometer()
{
unsigned long currentMillis = millis();
if((currentMillis - previousMillis) > interval) {
previousMillis = currentMillis;
// Read values from the ADC converter and send them out the serial port.
data = analogRead(2); // READ ANALOG PIN 2 100uS
//float GForceG = ((float)data - mZ) / senZ; // Convert ADC value to G force with gravity
float GForce = ((float)data - (one_G)) / senZ; // ZERO BASE WITHOUT GRAVITY
g_aGraphs[0].SendData(GForce); // SEND Z AXIS G FORCE
}
}
Tengo dos gráficos a aproximadamente 25 MPH, el evento de bache es obvio, luego hubo un bache sutil después El otro gráfico son los mismos datos, pero se acercaron ligeramente
No estoy seguro de cómo detectar el evento de bache real, si pudiera usar FFT, umbral de desviación estándar, promedio móvil.
¡Cualquier consejo, sugerencia, aporte, sabiduría es muy apreciado!
EDITAR
Ajusté la frecuencia de muestreo y bajé el LPF en el acelerómetro a 15HZ. He obtenido mejores datos, veo los picos negativos y positivos en un bache, parece oscilar y amortiguarse con el tiempo haciendo un patrón tipo "beat". Me pregunto cómo se podría encontrar el patrón programáticamente.
Sé que la derivada de la aceleración sería "tirón". Me pregunto si los datos del bache podrían reconocerse por una serie de tirones decrecientes. El patrón también es negativo, aunque también, tiene que haber una firma para buscar para encontrar el bache y contarlo. La única vez que habrá G negativas en el eje Z de un automóvil es si la llanta entra en un agujero, o si el automóvil está en el aire por un breve momento y golpea el suelo, por lo que un "tirón" negativo sería una buena firma, ¿verdad? ?
Aquí están los DATOS SIN PROCESAR durante 1 SEGUNDO lapso de tiempo en que se topó con un bache
Parece que mi eje Z está al revés Oo? jajaja
Los DATOS se recopilaron utilizando solo el RC LPF de 25 HZ en el extremo de la salida del eje Z del acelerómetro sin filtrado de software
DATOS SIN PROCESAR PARA LA IMAGEN A CONTINUACIÓN:
ZACCEL,TIME,GFORCE
Z,0.01,-0.01
Z,0.02,0.02
Z,0.03,0.06
Z,0.04,0.02
Z,0.05,0.04
Z,0.06,0.09
Z,0.07,0.07
Z,0.08,0.00
Z,0.09,-0.10
Z,0.10,-0.04
Z,0.11,-0.03
Z,0.12,-0.05
Z,0.13,-0.13
Z,0.14,-0.12
Z,0.15,-0.19
Z,0.16,-0.16
Z,0.17,-0.09
Z,0.18,-0.17
Z,0.19,-0.18
Z,0.20,0.04
Z,0.21,0.20
Z,0.22,0.04
Z,0.23,-0.12
Z,0.24,-0.25
Z,0.25,-0.15
Z,0.26,-0.17
Z,0.27,0.03
Z,0.28,0.08
Z,0.29,-0.09
Z,0.30,-0.26
Z,0.31,-0.30
Z,0.32,-0.04
Z,0.33,0.20
Z,0.34,0.36
Z,0.35,0.04
Z,0.36,-0.20
Z,0.37,-0.38
Z,0.38,-0.40
Z,0.39,-0.25
Z,0.40,-0.17
Z,0.41,0.40
Z,0.42,0.93
Z,0.43,0.69
Z,0.44,0.01
Z,0.45,-0.17
Z,0.46,-0.42
Z,0.47,-0.54
Z,0.48,-0.21
Z,0.49,0.22
Z,0.50,0.83
Z,0.51,0.65
Z,0.52,0.18
Z,0.53,-0.15
Z,0.54,-0.12
Z,0.55,-0.25
Z,0.56,-0.49
Z,0.57,0.01
Z,0.58,-0.04
Z,0.59,0.37
Z,0.60,0.36
Z,0.61,-0.29
Z,0.62,-0.27
Z,0.63,0.04
Z,0.64,0.06
Z,0.65,-0.09
Z,0.66,-0.04
Z,0.67,0.01
Z,0.68,0.01
Z,0.69,0.28
Z,0.70,-0.08
Z,0.71,-0.18
Z,0.72,-0.11
Z,0.73,-0.10
Z,0.74,0.11
Z,0.75,0.15
Z,0.76,0.01
Z,0.77,-0.11
Z,0.78,-0.33
Z,0.79,-0.14
Z,0.80,0.12
Z,0.81,0.04
Z,0.82,0.01
Z,0.83,0.17
Z,0.84,0.09
Z,0.85,-0.02
Z,0.86,-0.07
Z,0.87,-0.04
Z,0.88,0.04
Z,0.89,0.04
Z,0.90,0.02
Z,0.91,0.09
Z,0.92,0.05
Z,0.93,-0.01
Z,0.94,0.01
Z,0.95,0.01
Z,0.96,-0.07
Z,0.97,0.07
Z,0.98,0.08
Z,0.99,0.12
Z,1.00,0.01
IMAGEN CRUDA:
Versión EXCEL:
FFT en esto parece tener un pico de energía @ 12.5HZ, ¿sería esta una buena frecuencia para filtrar?:
AQUÍ ESTÁN LOS DATOS SIN PROCESAR PARA conducir a una velocidad constante, golpear entre 6 y 9 baches y algunos baches en la carretera:
No podrá distinguir claramente los baches de otros picos cortos, aparte de poder distinguir entre un bache ascendente en la carretera y un agujero (la dirección inicial será opuesta), pero sin duda podrá capturarlos con bastante facilidad.
Determine una dirección inicial (por ejemplo, XYZ negativo/positivo dependiendo de cómo esté montado su dispositivo), un nivel de umbral y un tiempo máximo en que la lectura debe estar por encima de este nivel (determinado por el ancho del bache) Luego mida la altura/ancho máximo y vea si se ajusta a su característica de bache.
El dispositivo ya contiene un LPF interno de 1 kHz, por lo que podría agregar un HPF de, por ejemplo, 50-200 Hz para los baches, ya que tendrán un tiempo de subida rápido. No soy un experto en frecuencias de vibración de automóviles, pero probablemente obtendrá algo de ruido de la vibración sin importar cómo filtre. Sin embargo, eso no es un problema siempre que el evento del bache sea grande en comparación con el ruido; parece que los datos están bien tal como están, solo tomaría muestras un poco más rápido para evitar el aliasing (por ejemplo,> 2kHz) o agregar un LPF al interno existente como se describe en la hoja de datos . Dado que está tratando de capturar eventos de tiempo de subida rápidos, optaría por el primero (muestreo más rápido, posiblemente con HPF)
Para compensar un cambio en la inclinación, puede tener un valor promedio móvil que se puede usar para poner a cero el eje (uno para cada eje). Además, tenga en cuenta que un HPF ignorará el nivel de CC, por lo que (siempre que no se salga del final de la escala) un gradiente lento no hará ninguna diferencia.
De acuerdo con la hoja de datos (parte inferior de la página 7 en el enlace de arriba), la fórmula para la capacitancia externa es:
por lo que su cálculo de:
es correcto.
Parece que todo lo que necesita es un filtro de paso bajo para obtener una mejor relación señal/ruido. Tomaría muestras tan rápido como pudiera hacerlo en el micro. 100 Hz (cada 10 ms) suena bastante lento, pero aun así, parece que obtienes datos útiles.
Los datos sin procesar tienen mucho ruido de muestra a muestra. Sin embargo, usted sabe que pasar por encima de un bache es un evento de frecuencia mucho menor. Aplique 2-3 polos de filtrado de paso bajo con una atenuación de quizás 10 Hz y vea cómo se ve. Desafortunadamente, solo está muestreando 5 veces más rápido que el mínimo para admitir 10 Hz, así que nuevamente, lo haría más rápido. Probablemente comenzaría muestreando cada ms, luego aplicaría el filtrado de paso bajo. Eso da mucho más rango dinámico para que funcione el filtro de 10 Hz, alrededor de 50x.
Para obtener los mejores datos, probablemente haría esto en un DSP de gama baja como un dsPIC y aplicaría una convolución. Un núcleo de 256 puntos a una frecuencia de muestreo de 1 kHz debería funcionar bien. Un dsPIC 33F puede funcionar a 40 MIPS, que son 40000 instrucciones/ms. Una convolución de 256 puntos cada 40000 instrucciones solo tomará una pequeña fracción del tiempo del procesador.
No me volvería demasiado elegante con el filtro. No hay necesidad de una sincronización, por ejemplo, y eso tendría efectos no deseados de todos modos. Algo como gaussiano o coseno al cuadrado debería ser bueno. Esto debería producir un resultado un poco mejor que unos pocos polos de LPF de un solo polo simple, ya que la convolución es simétrica. Dicho de otra manera, para cada punto de salida, la convolución tiene en cuenta los puntos de entrada tanto antes como después en el tiempo de forma simétrica, lo que no hacen los filtros IIR de un solo polo.
Podría ser útil capturar unos 5 segundos de datos relacionados con un bache y publicar los números en un archivo CSV o algo así. En realidad, los datos sin procesar para su seguimiento superior serían un buen comienzo.
el fotón
zacharon16
el fotón
Shashank de Chintalagiri
toby lorenzo
zacharon16