Estoy tratando de leer los valores de aceleración de un ADXL345 a través de I2C. He configurado con éxito el acelerómetro con una resolución de 16G.
Prueba 1 : rotación de 180° a lo largo del eje y en resolución 16G. La aceleración a lo largo del eje Z se muestra a continuación:
Con una configuración de 16 g, la resolución es demasiado baja. Lo cambié a 2 g para obtener un valor más preciso de la gravedad y realicé la misma prueba.
Prueba 2 : rotación de 180° a lo largo del eje y en resolución 2G. La aceleración a lo largo del eje Z se muestra a continuación:
Como puede ver, es un efecto de rollover causado probablemente por la cantidad de bits utilizados en el registro para guardar el valor. Con el modo 16g, el módulo usa un registro de 13 bits, con el modo 2/4/8g usa un registro de 10 bits.
¿Qué enfoque sugiere para reconstruir el valor de la aceleración?
En esta pregunta, @davidcary mencionó el efecto de vuelco.
EDITAR
Estoy leyendo dos bytes, es el mismo código que usé para el modo 16g
def read_word(self,adr):
high = self.bus.read_byte_data(self.address, adr)
low = self.bus.read_byte_data(self.address, adr+1)
val = (high << 8) + low
return val
def read_word_2c(self,adr):
val = self.read_word(adr)
if (val >= 0x8000):
return -((65535 - val) + 1)
else:
return val
[...]
accel_zout = adx.read_word_2c(0x36)
Aquí hay una captura de pantalla de los registros que contienen los valores de Zaxis
Nota
Aquí hay otro problema, abriré otra pregunta para esto, pero vale la pena señalar el siguiente problema. Por favor, concéntrese solo en el eje Z
Prueba : inclinación de 0° a 180° y vuelta a 0° dos veces, luego de 0° a -180° y vuelta a 0° dos veces.
Figura 1 : Datos sin procesar
Como puede ver, el cambio no es constante. El turno promedio es de alrededor de 58.000, pero a veces es más pequeño que esto. Si aplicamos la misma corrección a todas las ocurrencias de shify, terminaremos con esto:
Figura 2 : Datos desenvueltos
Si no se define correctamente el umbral a partir del cual se debe aplicar la corrección, los datos resultantes no serán precisos. En la Figura 2, la aceleración a lo largo del eje Z después de la prueba es diferente del valor cero inicial, lo que significa un desastre...
La reconstrucción que buscas se llama desenvolvimiento . Implementé esto en C ++ con buenos resultados el año pasado al medir la revolución total de una rueda de automóvil. En matlab: enlace
Q = unwrap(P,tol)
El "vuelco" observado (en realidad, una envoltura ) no es causado por el desbordamiento del registro, sino por el cambio de señal de la aceleración de la gravedad medida. La tolerancia tol debe ser la mitad de la amplitud pico a pico observada.
En C, sería algo como esto (no lo he probado, pero la idea está aquí):
void unwrap(int *P, int tol, int len)
{
for (int index = 1; index < len; index++)
{
// Upwards wrapping
while (P[index-1] - P[index] > tol)
{
P[index] += 2*tol;
}
// Downwards wrapping
while (P[index] - P[index-1] > tol)
{
P[index] -= 2*tol;
}
}
}
uint128_t
UsuarioK
UsuarioK