Madgwick coordinate system

[x1y9]

from ahrs.filters import Madgwick
import numpy as np

madgwick = Madgwick()
q = np.array([1.0, 0.0, 0.0, 0.0])  

acc_device = [0.08853444, 0.009571291, -9.856036]  
gyro_device = [6.8720314E-4,1.5271181E-4,6.8720314E-4]
mag_device=[34.912502, -0.84375006, 53.531254]

from scipy.spatial.transform import Rotation
for i in range(0,10000):
    q = madgwick.updateMARG(q, gyr=gyro_device, acc=acc_device, mag=mag_device) 
euler = Rotation.from_quat([q[1], q[2], q[3], q[0]]).as_euler('xyz', degrees=True)
print(euler) 

The value of the acc/gyro/mag sensor in the above code is read from an Android phone with NED attitude, I thought the output would be three Euler angles of 0, but the actual output is [-59.91242581 -56.71604791 6.81958275], why?

[Mayitzin]

Hi. Your intuition is correct. With no angular motion and with the accelerometer reading basically [0, 0, -9.8] the result should be basically zeros for the angles.

However, the magnetometer is also included here and this will change the estimation of the orientation, as the true geomagnetic north varies depending on your location on the planet.

Try computing the orientation again, but without using the magnetic values.

[x1y9]

I found that if I reverse the accelerometer reading, everything is correct, i.e. change it to [-0.08853444, -0.009571291, 9.856036],
The final output Euler angle is [-0.02000953 0.5136326 1.2706243 ]

Is the accelerometer in the Madgwick implementation the opposite of the Android sensor?

[Mayitzin]

This might be. Some manufacturers reverse the position of their sensors either physically or on Firmware.

You can check NXP's technical documentation about their own Sensor Fusion Library:

https://www.nxp.com/docs/en/data-sheet/NSFK_DS.pdf

On page 19 there is a table comparing some IMU configurations, and how their reference frames are different from each other.

Something similar might be happening with the configuration of your sensor.

[rneilson]

Just poking in to mention that I've been having a similar problem -- with the accelerometer in NED coordinates, a reading of [0, 0, -9.8] results in Euler angles indicating the sensor is inverted. Roll and pitch change opposite to the expected direction, and yaw is rotated 180 deg. Inverting the accelerometer reading vector when inputting to Madgwick seems to correct the orientation. Also, interestingly, I saw the same behavior with the lower-level ecompass() function from ahrs.common.orientation. Maybe a sign's flipped somewhere?

[surajbijjahalli]

I have just noticed something similar with the EKF where pitch and roll behave opposite to what is expected. Switching to the 'ENU' frame fixes it or alternatively manually flipping the sign of a_ref. This basically flips the direction of expected gravity vector. Im still thinking my way through this.
Update: Unless there is a flipped sign lurking somewhere, perhaps this has something to do with how the specific force measurement from the accelerometer is defined (?) A thought experiment to see if im on the right track : The specific force measurement would be f = a - g. This would be defined in the IMU (body) frame. So in the absence of vehicle acceleration and the vehicle being level, the sensor would report -9.8 m/s^2. This measurement is then compared against an expected measurement, which we get by taking g in the nav frame and rotating into body frame. However to convert this to an expected specific force measurement (as opposed to an expected gravity value in body frame), should the rotated value be made negative ? Does this make sense ? @Mayitzin

[rneilson]

@surajbijjahalli It's trickier than that, I'm afraid. On an NED (north-east-down) frame, with the z-axis pointing down, the -9.8 reading means the gravity vector is pointing up -- which is, counterintuitively, correct for an accelerometer. A good explanation is here:

An accelerometer is a device that senses deviation from freefall.

On a (level) table, accelerometer oriented NED, the table is pushing in the opposite direction as the z-axis, thus a -9.8 m/s^2 reading.

@Mayitzin I noticed the same behavior with the Tilt filter too, fwiw. I tried to look through the implementation, but didn't see anything obviously flipping the expected gravity vector there. But it does seem consistent with gravity being the opposite orientation than expected?

[rneilson]

@Mayitzin Maybe this is linked to #92 ?

[Mayitzin]

Maybe it is. I will start a review of the acceleration-based tilt estimations. We have to find the point where accelerations yield different angle results. Then, a standardization has to come out of it.