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

5

Quería comenzar un hilo separado concentrándose en suavizar el filtrado y la detección de baches y baches con un Arduino y mi Acelerómetro. Estoy usando un acelerómetro analógico configurado a 50 Hz de muestreo de ancho de banda a 100 Hz. Estoy trazando datos con MegunoLink (GRAN 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 implementarlo en el filtro que no afectará la frecuencia de muestreo ... Además, no estoy seguro de si 100 Hz es suficiente para muestrear, parece que capta los eventos bump bastante bien. (gráficos publicados).

El acelerómetro es un KXPS5-3157

Convierto la salida del acelerómetro a Gforce, debo usar Gforce, o debo usar voltaje bruto 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 del bache es obvio, luego hubo un golpe sutil después. El otro gráfico es la misma información, pero se amplió ligeramente

No estoy seguro de cómo detectar el evento de bache real, si pudiera usar FFT, ¿umbral de desviación estándar, promedio de carrera?

¡Cualquier consejo, sugerencia, entrada, sabiduría es muy apreciada!

EDIT

Ajusté la frecuencia de muestreo y bajé el LPF en el acelerómetro a 15 Hz. He obtenido mejores datos, veo los picos negativos y positivos en un bache, parece que oscilan y se amortiguan con el tiempo haciendo un patrón tipo "beat". Me pregunto cómo el patrón podría ser un aliado programático.

Sé que la derivada de la aceleración sería "imbécil". Me pregunto si los datos del bache podrían ser reconocidos por una serie de idiotas decrecientes. Sin embargo, el patrón también es negativo, tiene que haber una firma para buscar el bache y contarlo. La única vez que habrá G negativo en el eje Z de un automóvil es si el neumático se introduce en un agujero, o si el automóvil está en el aire por un breve momento y toca el suelo, por lo que un "tirón" negativo sería un buen derecho de firma ?

AquíestánlosDATOSSINPROCESARpara1SEGUNDAventanadegolpearunbache

ParecequemiejeZestáalrevésO.o?lol

LosDATOSserecopilaronutilizandosoloel25HZRCLPFalfinaldelasalidadelacelerómetrodelejeZsinfiltradodesoftware

DATOSSINPROCESARPARALAIMAGENABAJO:

ZACCEL,TIME,GFORCEZ,0.01,-0.01Z,0.02,0.02Z,0.03,0.06Z,0.04,0.02Z,0.05,0.04Z,0.06,0.09Z,0.07,0.07Z,0.08,0.00Z,0.09,-0.10Z,0.10,-0.04Z,0.11,-0.03Z,0.12,-0.05Z,0.13,-0.13Z,0.14,-0.12Z,0.15,-0.19Z,0.16,-0.16Z,0.17,-0.09Z,0.18,-0.17Z,0.19,-0.18Z,0.20,0.04Z,0.21,0.20Z,0.22,0.04Z,0.23,-0.12Z,0.24,-0.25Z,0.25,-0.15Z,0.26,-0.17Z,0.27,0.03Z,0.28,0.08Z,0.29,-0.09Z,0.30,-0.26Z,0.31,-0.30Z,0.32,-0.04Z,0.33,0.20Z,0.34,0.36Z,0.35,0.04Z,0.36,-0.20Z,0.37,-0.38Z,0.38,-0.40Z,0.39,-0.25Z,0.40,-0.17Z,0.41,0.40Z,0.42,0.93Z,0.43,0.69Z,0.44,0.01Z,0.45,-0.17Z,0.46,-0.42Z,0.47,-0.54Z,0.48,-0.21Z,0.49,0.22Z,0.50,0.83Z,0.51,0.65Z,0.52,0.18Z,0.53,-0.15Z,0.54,-0.12Z,0.55,-0.25Z,0.56,-0.49Z,0.57,0.01Z,0.58,-0.04Z,0.59,0.37Z,0.60,0.36Z,0.61,-0.29Z,0.62,-0.27Z,0.63,0.04Z,0.64,0.06Z,0.65,-0.09Z,0.66,-0.04Z,0.67,0.01Z,0.68,0.01Z,0.69,0.28Z,0.70,-0.08Z,0.71,-0.18Z,0.72,-0.11Z,0.73,-0.10Z,0.74,0.11Z,0.75,0.15Z,0.76,0.01Z,0.77,-0.11Z,0.78,-0.33Z,0.79,-0.14Z,0.80,0.12Z,0.81,0.04Z,0.82,0.01Z,0.83,0.17Z,0.84,0.09Z,0.85,-0.02Z,0.86,-0.07Z,0.87,-0.04Z,0.88,0.04Z,0.89,0.04Z,0.90,0.02Z,0.91,0.09Z,0.92,0.05Z,0.93,-0.01Z,0.94,0.01Z,0.95,0.01Z,0.96,-0.07Z,0.97,0.07Z,0.98,0.08Z,0.99,0.12Z,1.00,0.01

IMAGENCRUDA:

Versión EXCEL:

FFTenestoparecetenerunpicodeenergíaa12.5HZ.¿Seríaestaunabuenafrecuenciaparafiltrar?:

AQUÍ ESTÁN LOS DATOS SIN PROCESAR PARA conducir a una velocidad constante, golpeando entre 6 y 9 baches y algunos lugares difíciles en la carretera:

enlace

    
pregunta zacharoni16

2 respuestas

3

No podrá distinguir los baches claramente de otros eventos de pico corto, además de poder distinguir entre un bache creciente en la carretera y un agujero (la dirección inicial será opuesta) pero ciertamente puede capturarlos bastante fácilmente.
Determine una dirección inicial (p. Ej., XYZ negativo / positivo según cómo esté montado su dispositivo), un nivel de umbral y un tiempo máximo que la lectura debe estar por encima de este nivel (determinado por el ancho del bache). Si se ajusta a tu característica bache.
El dispositivo ya contiene un LPF interno de 1 kHz, por lo que podría agregar un HPF de, por ejemplo, 50-200Hz 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 por vibración, sin embargo, filtre. Sin embargo, eso no es un problema siempre que el evento pot hole sea grande en comparación con el ruido. Parece que los datos están bien tal como están, simplemente muestrear un poco más rápido para evitar el alias (por ejemplo, > 2kHz) o agregar un LPF al existente interno como se describe en la hoja de datos . Ya que está tratando de capturar eventos rápidos de tiempo de subida, me quedaría con el primero (muestreo más rápido, posiblemente con HPF)

Para compensar un cambio en la inclinación, puede tener un valor promedio de ejecución 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, así 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:

\ $ C2 = C3 = C4 = \ dfrac {4.97 \ times 10 ^ {- 6}} {f_ {BW}} \ $

entonces tu cálculo de:

\ $ \ dfrac {4.97 \ times 10 ^ {- 6}} {10Hz} = 497nF \ $ es correcto.

    
respondido por el Oli Glaser
2

Parece que todo lo que necesita es un filtro de paso bajo para brindarle una mejor relación señal / ruido. Tomaría muestras tan rápido como podría salirme con la micro. 100 Hz (cada 10 ms) suena bastante lento, pero aun así, parece que estás obteniendo datos útiles.

Los datos sin procesar tienen mucha muestra para muestrear ruido. Sin embargo, usted sabe que pasar por un bache es un evento de frecuencia mucho más baja. Aplique un filtro de paso bajo de 2-3 polos con una caída de aproximadamente 10 Hz y vea cómo se ve. Desafortunadamente, solo está muestreando 5 veces más rápido que el mínimo para soportar 10 Hz, así que nuevamente, lo haría más rápido. Probablemente empiece a muestrear cada ms, luego aplique el filtrado de paso bajo. Eso da un rango mucho más dinámico para que funcione el filtro de 10 Hz, aproximadamente 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 kernel de 256 puntos a una velocidad de muestreo de 1 kHz debería funcionar bien. Un dsPIC 33F puede ejecutarse a 40 MIPS, lo que equivale a 40000 instrucciones / ms. Una convolución de 256 puntos por 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 indeseables de todos modos. Algo como un cuadrado gaussiano o coseno debería ser bueno. Esto debería producir un resultado un poco mejor que unos pocos polos de LPF simples de un solo polo, 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 antes y después en el tiempo de forma simétrica, lo que no hacen los filtros IIR de un solo polo.

Puede ser útil capturar tal vez 5 segundos de datos que rodean un evento bache y publicar los números en un archivo CSV o algo así. En realidad, los datos en bruto para su seguimiento superior serían un buen comienzo.

    
respondido por el Olin Lathrop

Lea otras preguntas en las etiquetas