Detección de baches de filtrado de suavizado de datos del acelerómetro

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
    }
}

bache a 25 mph

bache a 25 mph ampliado

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? ?

Mejores datos

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:

http://img24.imageshack.us/img24/2751/pothole25mphraw.png

Versión EXCEL:

ingrese la descripción de la imagen aquí

FFT en esto parece tener un pico de energía @ 12.5HZ, ¿sería esta una buena frecuencia para filtrar?:

ingrese la descripción de la imagen aquí

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:

http://textuploader.com/?p=6&id=sQlb

Ha dicho qué características le gustaría filtrar de sus datos. Igualmente importante, ¿cuáles son las características que desea conservar? ¿Qué hará con los datos después de eliminar el ruido de la carretera y los baches?
@The Photon Quiero poder detectar eventos de baches y golpes a partir del ruido mientras el sistema está funcionando continuamente. Eventos de caminos irregulares a partir del ruido de caminos suaves Básicamente, estoy haciendo un detector de baches que detectará baches, baches, etc. y calificará qué tan severos son en un mapa GPS, por ejemplo, un mapa de carreteras en el que está viajando. Supongo que cuán "graves" son en una escala sujeta de algún tipo al conductor/pasajero
DE ACUERDO. Luego otra pregunta: ¿Cuáles son otras características en los datos que no desea detectar como baches? Por ejemplo, ¿girar hacia un camino de entrada y pasar por encima de un bordillo? ¿Detenerse abruptamente en un semáforo? ¿Vías del tren? ¿Pasando por encima de la corona de una calle transversal? ¿Cómo aparecen estos eventos en sus datos y en qué se diferencian de los baches? No voy a poder darle una respuesta a su pregunta, pero espero que estas preguntas le ayuden a obtener una respuesta.
Si desea recuperar una señal de 50 Hz, realmente necesitaría una frecuencia de muestreo de más de 100 Hz (como ya expliqué en su otra pregunta). Además, el ADC en sí mismo suele ser ruidoso en los últimos uno o dos bits, dependiendo de qué tan buenos sean el suministro y la placa de circuito impreso. Poner en cortocircuito la entrada adc a tierra y trazarla indicará cuántos bits están fluctuando. Vale la pena descartar estos bits o sobremuestrear y promediar para reducir el ruido de conversión. Además, un filtro de paso bajo de aproximadamente 1 KHz en la entrada del ADC puede ayudar a descartar el ruido de frecuencias más altas. Eso a menudo se llama filtro antialiasing.
Además, ¿cómo se ven los otros ejes alrededor del bache? ¿Hay una protuberancia perceptible en el eje Y correspondiente a golpear un objeto de frente y desacelerar la aceleración por un breve momento? Creo que te estás concentrando demasiado en tratar de hacer que tu gráfico del eje Z se vea como la representación física de lo que le sucede a un automóvil cuando golpea un bache (la rueda sube y baja con un tiempo de subida rápido) ... pero ignorando otros útiles datos que podrían correlacionarse con él para una respuesta más completa.
Gráfico de datos actualizado

Respuestas (2)

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:

C 2 = C 3 = C 4 = 4.97 × 10 6 F B W

por lo que su cálculo de:

4.97 × 10 6 10 H z = 497 norte F es correcto.

Configuré la frecuencia de muestreo en 2KHZ ahora, agregué un capacitor de 0.1uF en la entrada Z para obtener 50HZ en el acelerómetro de acuerdo con la hoja de datos, ¿es ese ancho de banda o está cambiando la atenuación del LPF interno a 50HZ? si el LPF interno es 1000HZ, reflejará frecuencias superiores a 1000HZ, ¿verdad? No entiendo cómo agregar el filtro HPF de 50-200 Hz. Tendría que diseñar uno y alimentar el eje Z antes de que vaya al microcontrolador kanga.gerbilator.org/Sensors/Accelerometers/… sobre el ancho de banda del sensor, ¿debería? estar usando 500HZ o los 50HZ que he estado usando
Agregar el límite externo reducirá la caída del LPF a 50 Hz, por lo que ese es su ancho de banda. Elimine esto si desea ver señales > 50 Hz. Si deja el límite fuera, las señales por encima de 1kHz serán atenuadas/rechazadas, sí.
Entonces, para cambiar la caída a 10HZ como sugirió Olin, ¿dejaría el capacitor y luego diseñaría un filtro con una caída de 10HZ con la salida del eje Z alimentándolo y luego al Arduino?
Creo que @Olin está sugiriendo lo contrario, a LPF hasta 10 Hz, por lo que en este caso usaría el condensador o lo haría digitalmente. Me olvidaría de la tapa y filtraría digitalmente. Mi sugerencia es buscar el tiempo de subida inicial grande/rápido de un evento de bache, la de Olin parece ser buscar todo el evento, lo que tiene la ventaja de eliminar la mayor parte del ruido, aunque puede dificultar la distinción de baches. de, por ejemplo, una curva cerrada o un bache en la carretera. Si filtra digitalmente, sería fácil probar ambas formas y ver cuál funciona mejor para usted.
ah, gracias En mi configuración, la gravedad siempre está trabajando en el acelerómetro y resté su valor con un desplazamiento a "cero" del acelerómetro, sin embargo, acabo de descubrir que si conduce en pendientes y terreno montañoso, la gravedad se dividirá entre dos ejes.... ¿Hay alguna manera de compensar el terreno irregular para corregir el desplazamiento G de conducir cuesta arriba?
Ok, el acelerómetro tiene resistencias de 32k incorporadas que no había visto antes, jaja, eso lo hace fácil, así que puedo diseñar un filtro RC de un solo polo si quiero un corte de 10 HZ C = 1 / [2πRf] C = 1 / (2π * 32000 * 10HZ) = condensador de 497nF?
@ zacharoni16: edité mi respuesta con respecto a sus comentarios.

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.