Hi Everyone,
I'm currently using Madgwick's popular filter for my own AHRS project. After some experimentation with sensors and adjusting the beta gain, I've noticed some unpredictable behavior of the filter. For example, euler angles computed from the quaternion changed unexpectedly to 20 degrees off the reference angle (in a static scenario!).
After setting the magnetometer input to (0,0,0) the problem stayed the same. Then I removed the gyroscope inputs (0,0,0) and the problem stayed the same. My conclusion was that it must have been related to the accelerometer inputs.
After experimenting with real sensors I moved to artificial ACC input data and set up a test bed for Madgwick's algorithm (MadgwickTests on GitHub). I've figured out that in Madgwick's algorithm the fast inverse square root leads to huge instabilities when noisy measurements are applied. As an example, consider the pitch and roll angles shown in the following image:
The input for the filter was: gyro = (0,0,0), acc = (2.5, 2.5, 9.15) +- 0.1 uniform noise (see test.c for details). As you can see, the pitch and roll angles (red/green, in degrees) of the original implementation show unacceptable variations.
Remarkably more stable and accurate pitch/roll angles (blue/magenta) were achieved by exchanging the inverse square root implementation. I used the following code from Accurate and Fast InvSqrt for computing the inverse square root of float x:
unsigned int i = 0x5F1F1412 - (*(unsigned int*)&x >> 1);
float tmp = *(float*)&i;
float y = tmp * (1.69000231f - 0.714158168f * x * tmp * tmp);
Cheers, Tobias
Replies
Hi Thomas:
I have fixed my error by changing the part where I calculate the orientation angles. It turns out I was estimating dT for accelerometer and magnetometer while it should only have been applied to gyroscope. I'll leave it at that for now...
Thomas Guldborg said:
Serge,
I can't give the details or the data, as I'm under an NDA---but suffice to say, in our testing here at PAS we encountered similar scaling defects to the positional data (due to accelerometer scaling, perhaps?), which was unable to be resolved from either open-source nor from manufacturer (Interstil)-given calibration instructions. Please feel free to message me directly to discuss this in more detail; we are still at something of a loss, and are considering a custom hardware-software solution.
Hello!
I'm using free-running IMU device based on LSM6DS3 (gyro and accelerometer) and LIS3MDL (magnetometer).
LSM6DS3 are configured for 2000 °/s (gyro) and 16G (accerometer). LIS3MDL are configured for 4 gauss range.
Magnetometer are calibrated using Magneto algorithm.
Data from chips are collected and saved to flash memory with high speed (up to 250 samples/s). After data reading I calculate trajectory using some Madgwick algorithm (MadgwickAHRSupdate (gyro, accelerometer and magnetometer) or MadgwickAHRSupdateIMU (gyro, accelerometer only). For all cases I'm using for factor Beta=0.041 value.
Below I apply the screenshots for same device trajectory.
The first trajectory path was built usung gyro and accelerometer data.
The second trajectory path was built using gyro, accelerometer and magnetometer data with using magnetometer calibration correction.
The third trajectory path was built using gyro, accelerometer and magnetometer data without magnetometer correction.
The device path are created on the small place inside a tower building (concrete, steel and glass construction) on high floor.
I have done the experiment some times and have got the similar results. I confused this results and I can't understand why Madgwick algorithm using magnetometer data (MadgwickAHRSupdate) works so bad.
I have applied all last changes in the algorithm except listed below (_bx and _bz are single not a half). Hovever I have tried both variants (my variant are better fit).
_bx = sqrt(hx * hx + hy * hy);
_bz = -_2q0mx * q.y + _2q0my * q.x + m1.z * q0q0 + _2q1mx * q.z - m1.z * q1q1 + _2q2 * m1.y * q.z - m1.z * q2q2 + m1.z * q3q3;
I'm simply an engineer not a scientist, and I can't understand Mangwick original article algorihm for checking.
Could anybody help me or explain at least where I'm do wrong. I have checked the formulas some times in the source code and not found any differens (except notation above).
PS: The calibration magnetometer sphere (after correction using matrice calulated using Magneto program) posted below.
SY, Serge B.
Hello Paven Chinta
Have you calibrated your magnetometer?
Hi Jeroen van de Mortel:
I'm trying to implement the Magdwick filter on on my android glasses; however, I see a VERY large overshoot in the output when the glasses are subject to external acceleration... Here's what I have done so far:
i) Ensured all three axes are aligned
ii) Corrected the equations for s0 s1 s2 s3 based on the error you had found in the C-code
iii) Changed the inverse square root to a regular math function
Here's my code from Android. If there are ANY pointers you can give me, I would really really appreciate it. I was about to subtract the static error from the sensor data (which I didn't in the code I posted)...
Indeed the 6DOF C code is correct, but the C code of the 9DOF not. I found there was a difference between the matlab code an the optimized C code of the 9DOF.
I don't know anything about the invsqrt.
Keith Laidlaw said:
Let me see if I have this correctly.
If we want to use SM's C code for 6DOF (Mahony algorithm as I understand), the existing code is just fine.
If we want to use his C code for 9DOF (his algorithm as I understand), the code has two known bugs:
1. the two quoted in this reply (magnetometer and quaternion calcs)
2. the one much earlier about invsqrt.
Am I correct on both counts?
Are there any other issues?
Jeroen van de Mortel said:
The code was indeed never updated by sebastian, I found there was an optimization error in de code which is opensource when using the compass version. There was only an error in the quaternion part.
Thomas Solley said:
You mention there has been some change to the code----yet two years later, it seems the source code has not been updated. In the versions of this C-code you claim to have found, was there any change to the Gyroscope Heading code? Your reference and samples discuss the Quaternion aspects of his code and not the Heading results...
Jeroen van de Mortel said:
Hi everyone,
I am applying Madgwick AHRS filter in Android in order to get the phone orientation (I used the source code in the published report). However, the output result seems to be not correct. For me it seems like there is a 90 degree rotation around the z axis (I just consider the yaw angle). I think the cause of this problem is the difference of used coordinate system.
The coordinate system described in Android phone is as follow (as attached picture). Assume that a device is held in its default orientation, the X axis is horizontal and points to the right, the Y axis is vertical and points up, and the Z axis points toward the outside of the screen face.
Android also provide function
getOrientation()
that represent device motion or device position relative to the earth. However, the output is too unstable. That the reason, I want to use Madgwick filter. But, I could not find any information about the coordinate system used in this filter. Could you please tell me the coordinate system (sensor frame) using in Madgwick and the Earth output coordinate from converting quaternion to Euler angles as formula mentioned in the report.Sorry for this basis question. I appreciate for any input