MPU-9250 Accelerometer "at-rest values"

[Kryzzalid]

Hi!
I have got some awkward values when the IMU returns to the rest state. At rest, the accelerometer's values should be ideally ax = 0, ay = 0 and az = 0 (or g) when calibrated. The problem is that the rest values changes each time the module is moved. On the following picture, the problem can be noticed:

At the beginning, the rest value is -0.62 ms⁻² for the acceleration on x-axis. Following that, the module is moved for about 1s which leads to a rest value of -0.3 ms⁻². After an other displacement, it becomes -0.43 ms⁻² and finally -0.21 ms⁻².
The gyroscope doesn't have that problem. It always returns to the same rest values (+ noise). It feels like that the accelerometer's registers stop updating too early. I didn't enable Wake on Motion. I don't use the FIFO (at least, I didn't enable it). I have got an other module with run also with an MPU-9255 and it is victim of the same phenomena. I have been looking at the register map for a while and I don't know what I should change to stop that. Here is the initialization of the module:
I2CSend(MPU9250_ADDRESS, 2, PWR_MGMT_1, 0x00); // Clear sleep mode Delay; I2CSend(MPU9250_ADDRESS, 2, PWR_MGMT_1, 0x01); // Clock Source Delay; I2CSend(MPU9250_ADDRESS, 2, CONFIG, 0x06); // Gyroscope Filter BW = 5Hz, delay = 33,48ms, Fs = 1kHz Delay; I2CSend(MPU9250_ADDRESS, 2, PWR_MGMT_2, 0x00); // Enable Accelerometer and gyroscope Delay; I2CSend(MPU9250_ADDRESS, 2, GYRO_CONFIG, 0x00); // +-250dps Delay; I2CSend(MPU9250_ADDRESS, 2, ACCEL_CONFIG, 0x00);// +-2G Delay; I2CSend(MPU9250_ADDRESS, 2, ACCEL_CONFIG_2, 0x05); // Accelerometer Filter BW = 10Hz, delay = 35,70ms, Fs = 1kHz Delay; I2CSend(MPU9250_ADDRESS, 2, INT_PIN_CFG, 0x02); // Bypass for the magnetometer enable Delay; I2CSend(MPU9250_ADDRESS, 2, I2C_MST_CTRL, 0x00); // I2C speed at 358 kHz Delay; I2CSend(MAG_ADDRESS, 2, MAG_CNTL_1, 0x00);// Power down magnetometer Delay; I2CSend(MAG_ADDRESS, 2, MAG_CNTL_1, 0x16); // sampling rate 100Hz and word is 16-bit Delay;
I read all the registers from ACCEL_XOUT_H to GYRO_ZOUT_L in one sequence with clock stretching.

Has anyone any idea of what did I do wrong? Thank you very much for your time.

[Kryzzalid]

I think I figured out why. It's due to the board not being perfectly horizontal. So, the values were due to the gravitational acceleration vector not being perpendicular to the board. It took me a while to think of that...

[slowrunner]

due to the board not being perfectly horizontal. ... due to the gravitational acceleration vector not being perpendicular to the board.

Are you able to get consistent heading values? (my robot is never going to be pitch and roll free, but I really need an accurate heading change reading)

oh just noticed this is 7 years old...my bad

[kriswiner]

Yes. Just calibrate the accel/gyro sensors when the robot is at rest, then the mag when it is moving all around in 3D space (if it is small enough to manipulate it so). You should be able to get accurate heading to ~4 degrees rms heading error using the MPU9250. If your robot is too big to pick up and move around by hand, try something like this <https://www.tindie.com/products/onehorse/usfsmax-module-and-carrier/>.

…

On Mon, Oct 9, 2023 at 8:49 AM slowrunner ***@***.***> wrote: due to the board not being perfectly horizontal. ... due to the gravitational acceleration vector not being perpendicular to the board. Are you able to get consistent heading values? (my robot is never going to be pitch and roll free, but I really need an accurate heading change reading) — Reply to this email directly, view it on GitHub <#101 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTDLKQP6QULGQMFDOJQY7LX6QMIHAVCNFSM4C26IOJ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZVGMZDKOJXHA4A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>