Caída transitoria en la lectura de gravedad del acelerómetro cuando está en movimiento

Estoy usando el acelerómetro de Pololu AltIMU-10 v4 para monitorear la aceleración de mi sistema. Entiendo que cuando el sensor se coloca en posición vertical sobre la mesa, debe medir 1g en el eje z +ve. Sin embargo, cuando lo coloco sobre la mesa y lo deslizo sobre la mesa en las direcciones x e y, veo que esto mide 1 g en el eje z cae durante el movimiento y vuelve a 1 g después de que finaliza el movimiento. Este cambio en las lecturas del eje z siempre tiene la forma de una caída, independientemente de que el movimiento real sea en las direcciones +ve o -ve x o y.

En el siguiente gráfico, realicé la siguiente secuencia de movimiento:

  1. Deslizamiento de movimiento en -ve eje x sobre la mesa.
  2. Movimiento de deslizamiento en el eje + ve y sobre la mesa.
  3. Movimiento ascendente manual en el eje z +ve en el aire.
  4. Movimiento manual hacia abajo en el eje z -ve en el aire.
  5. Movimiento deslizante en el eje y sobre la mesa.
  6. Movimiento deslizante en el eje x +ve sobre la mesa.
  7. Rotaciones aleatorias del sensor para ver el cambio en la gravedad medida.

Lecturas del acelerómetro y la magnitud calculada (norma)

Se ve que aunque se mide la aceleración esperada en el eje de movimiento, la gravedad medida cae durante el movimiento. ¿Es este el comportamiento esperado para un acelerómetro?

En caso afirmativo, ¿cómo puedo eliminar esta caída transitoria de mis lecturas? Entiendo que el componente de gravedad puede eliminarse al referir el vector global [0 0 1] al marco del sensor y restarlo de la medición del sensor. Pero eso no ayuda con esta caída transitoria.

Has hecho una buena prueba, parece que el sensor no funciona muy bien. Estoy seguro de que los pequeños acelerómetros MEMS tienen todo tipo de problemas de ejes ortogonales npn no lineales que se solucionan en el software. ¿Existe quizás una biblioteca actualizada para el dispositivo?
Realice la misma prueba con su teléfono y una aplicación de monitor de acelerómetro como Physics Toolbox. No veo el efecto que describes, pero puedo simularlo inclinando el teléfono hacia la dirección del movimiento . ¿Es posible que no mantenga el dispositivo plano sobre la mesa mientras lo desliza?
@tomnexus En cuanto a las lecturas del sensor, no estaba usando ninguna biblioteca, estaba escribiendo/leyendo directamente los registros de acuerdo con la hoja de datos del sensor (usando BeagleBone Black). Pero creo que Pololu proporciona una biblioteca de sensores para usuarios de Arduino. Voy a tratar de ver si se hacen ajustes adicionales allí.
@tomnexus En cuanto a la inclinación del sensor. Definitivamente es posible que haya inclinado ligeramente el sensor durante el movimiento, ya que lo estaba haciendo a mano. Pero creo que el ángulo habría sido muy pequeño (¿1 o 2 grados tal vez?). También es inusual que para todos los movimientos en xey, el cambio en la medición del eje z sea en la misma dirección (-ve) y con una magnitud similar (~0.4-0.5g, que es bastante grande). Intentaré confirmar esto usando un brazo robótico, para mantener el sensor lo más plano posible durante el movimiento.
¿Cuál es el chip giroscópico del dispositivo utilizado?
@Andyaka, el chip giroscópico en Pololu AltIMU-10 v4 es L3GD20H, y el chip acelerómetro + magnetómetro es LSM303D.
Puede ser que, durante la fabricación, se hubiera colocado el mecanismo sensor interno, ligeramente inclinado. Y así, el eje Z que estaba considerando en función de la carcasa exterior, podría no ser el eje Z del sensor interno. Por lo tanto, para obtener solo lecturas del eje Z, para el movimiento del eje Z (sin X, Y), las coordenadas deben rotarse para alinear el eje Z interno con el eje Z externo... Componentes distintos de cero en el eje X, Y para el eje Z el movimiento podría ser, 1g sen (\theta) y 1g cos (theta)
Le sugiero que muestre esos resultados a las personas en forum.pololu.com o support@pololu.com.
¿Ha revisado para ver si su suministro es constante? Parece que el eje Z cae cuando se cambian los otros dos ejes, sin importar en qué dirección. Si su riel de alimentación está haciendo eso (debido a una potencia insuficiente, sobrecargando el riel de transmisión del chip u otras razones), probablemente sea por eso que el eje Z está cambiando.
Secundo el monitoreo de la tensión de alimentación y la posible capacitancia de suavizado adicional. También una prueba más sería ver si el error es una caída o un pico si el sensor está invertido en la dirección Z antes de la prueba. ¿La polaridad del pico también cambiará? Si es así, respaldaría la teoría de =stiebrs. Si la dirección de la punta permanece igual, apoyaría la teoría de =Cristobol P.

Respuestas (1)

Podría ser inherente a la tecnología de sensores utilizada. Si utilizan una masa cargada por resorte para la detección, es de esperar que el vector de fuerza se desplace hasta cierto punto durante el movimiento lateral. Si asume que la longitud total del resorte es limitada, entonces se recorta en el eje Z a la longitud restante permitida para el movimiento.

Por ejemplo, la suma de fuerzas E es constante 1 (o algo ligeramente superior). Si solo tiene la gravedad trabajando en él, "consume" la mayor parte. Si introduce un movimiento lateral en el eje +X con una magnitud > 1, entonces Z cae a 0, porque está "superado". Si introduce un movimiento en el eje +X con una magnitud inferior a 1 (por ejemplo, 0,5), obtendrá una caída mucho menor en Z, pero seguirá presente. Lo cual parece ser el caso.

Maldición, es difícil de explicar, pero lo tengo en algún lugar de mi cabeza :) Esta imagen debería ilustrarlo un poco: ingrese la descripción de la imagen aquíexcepto que aquí los resortes son ideales, mientras que en realidad tienen coeficientes de rigidez y elasticidad, que limitan el "techo"

No he usado este sensor STM en particular, pero otros de ellos (LIS2/3) no parecen exhibir tales propiedades.

Bien explicada la posible no linealidad del sistema de suspensión cuando se aleja de la posición de descanso. Espero que estos efectos sean pequeños, pero es una fuente potencial de error.
Esperaba una magnitud de error muy pequeña de tales no linealidades, por lo que ciertamente fue una sorpresa para mí ver tal nivel de distorsiones. De todos modos, lo solucioné a través de la detección y el rechazo de las distorsiones en mi programa de software (la rutina de detección/rechazo es muy específica para mi aplicación). Lo siento, me tomó un tiempo para responder!
Caída transitoria en la lectura de gravedad del acelerómetro cuando está en movimiento
RespuestasAquíPolítica de privacidad1y, 1v