A computationally inexpensive filter for IMUs

I found this video a few months ago and asked the author for a copy of his paper as soon as it was available.  Just received it today.  Here are links to both.

PDF report with source code:

http://www.scribd.com/doc/29754518/A-Efficient-Orientation-Filter-for-IMUs-and-MARG-Sensor-Arrays

Video:

https://www.youtube.com/watch?v=fOSTOnQzZCI

Intro to report:

This report presents a novel orientation filter applicable to IMUsconsisting of tri-axis gyroscopes and accelerometers, and MARG sensor
arrays that also include tri-axis magnetometers. The MARG implementation
incorporates magnetic distortion and gyroscope bias drift compensation.
The filter uses a quaternion representation, allowing accelerometer and
magnetometer data to be used in an analytically derived and optimised
gradient-descent algorithm to compute the direction of the gyroscope
measurement error as a quaternion derivative. The benefits of the filter
include:

(1) computationally inexpensive; requiring 109 (IMU) or277 (MARG) scalar arithmetic operations each filter update,

(2)effective at low sampling rates;e.g.10Hz,and

(3) contains 1(IMU) or 2 (MARG) adjustable parameters defined by observable system
characteristics.

Description from YouTube video:

A real-time demonstration of an efficient orientation filtercapable of providing an estimate of the sensor arrays orientationrelative to the earth through the fusion of tri-axis gyroscope, tri-axisaccelerometer and tri-axis magnetometer data. Unlike an IMU, theinclusion of the magnetometer mean that the filter is not subject to anyaccumulating errors. The filter also incorporates magnetic distortioncompensation to overcome soft-iron disturbances and gyroscope bias driftcompensation. The algorithm is an alternative to more computationallyexpensive Kalman based solutions that are commonly used in thisapplication. The total computation requirement of this filter is 278scalar arithmetic operations per sample.

Hardware used in video: Sparkfun6DOF IMU Razor (ADXL335, LPR530 and LPY530) with gyroscope RC HP filtersremoved, Sparkfun HMC5843 breakout board (low ESR cap replacement),x-io Board with .NET interface library



You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Hi, I have a question about magnetic disturbances. It is said that the calculation of the Reference direction of Earth's magnetic field makes sure that the disturbance only effects heading. Though when a sensor is close to a radiator or metal chair, effecting 'only' heading is still quite an issue.


    As far as I can see, this algorithm does not have any checks for magnetic deviances? And if a magnetic disturbance is detected, the only way to decrease the effect is to decrease beta, which means that accelerometer update is falsely less 'trusted' ?


    I am used to using Kalman filters where there is a covariance matrix holding both accelerometer and magnetometer trust, separated, but even there, detecting the magnetic disturbances have been as issue. In the end, I simply check for deviance in magnitude (~0.5 Gauss), and magnetic dip angle (~70 deg), which is of course subject to where on Earth you are...

    Would appreciate some thoughts on this!

    Rikard

  • Dear Seb Madgwick,

    I'm happy to see your code working on 9DoF-Razor IMU from Sparkfun, but have some problems. I have the following problems.

    1.In normalization , when norm =0, there will be "divide by zero" problem. if we place a if statement{ if (norm>0) } at acceleration normalization upto end of the filterupdate code, there is drift( fluctuation) can be seen in graphical 3D object, though the +ve rotations about all axes are ok. 

    2. I use the sensors reading code same, as it is provided by Sparkfun. offset reading from gyro's , raw readings from accelerometer, compass. Should there be any changes ?

    3. Sensors axis sign {w_x,w_y,w_z, a_x,a_y,a_z,m_x,m_y,m_z}={ 1, -1, -1, 1,1,1, -1, 1, 1} . Board axes are as it is from sparkfun.

    Present,I'm working on implementation of good Quaternion based algorithm for my research work since the DCM may be very good for UAV's, but may be a problem for motion tracking in CG & Virtual Reality applications.

    ( This statement is from book, "Strapdown INS Technology by D.H.Titterton & J.L.Weston )

    If someone here would like to have a look at my arduino code for 9DOF-Razor board for possible mistakes, i can email if you provide email ID.

    Thanks

     

  • I am the author of the paper and thought I could clear a few things up.

    RE: "I am not sure what he means when he says "Unlike an IMU..."
    I mean this literally: an IMU (Inertial Measurement Unit) consists of only inertial sensors and so may only estimate an orientation according to gravity and angular rate; therefore the 3D orientation (considered as a single state) will be subject to an accumulating error. If you wish to consider the an orientation as decoupled Euler angles then you could more accurately say that only the yaw is subject to the accumulating error. If you add a magnetometer, GPS, or anything other than an ‘inertial’ sensor then it is no longer an IMU; it is an IMU + something.

    RE: “Any idea how this compares in performance with the DCM”
    I had done as many tests as I could to try and show that my algorithm performs better than Mahoney’s or vice versa. I could not. I can only conclude that performance is equal. This is more obvious once one considers how the algorithms actually work (next point).

    RE: “difference between his approach”
    Mayhony’s [quaternion version], Bachman’s, and my algorithm are the 3 most efficient I know of, and all work in fundamentally the same. They are essentially a complementary (A.K.A. composite) filter. The difference is in the calculation of the feedback error. Bachman’s computes an error using a Gauss-Newton approach, I compute an error using a Normalised Gradient decent approach, and Mayhoy computes an error using a simple dot product. As a result, all three algorithms perform almost identically but each is computationally less expensive respectively. There are other subtle differences that may be of use to certain applications or implementations but I will not discuss them here.

    My paper does present what I believe to be a notable unique feature (as identified by Michael Zaffuto): the computation of a reference direction of magnetic flux. This (1) eliminates the need for the designer to predefine this, and (2) prevents magnetic distortions (soft-iron errors) from corrupting pitch or roll.

    Conclusion:
    Mayhony’s algorithm is computationally less expensive and more ‘elegant’. In my own work, I now use Mayhony’s for these reason but I combine it with my ‘magnetic distortion compensation’ algorithm for the reasons given above.
  • T3
    Chris and Bill,

    I am familiar with the author of the paper. While he was finishing up his work, and completing the list of references for his paper, he stumbled across the DCM work, and contacted me. Up until that time, he was not aware of ArduImu, or the work of the UAV DevBoard team or Robert Mahoney.

    He and I exchanged a few emails and concluded that his algorithm and DCM used approximately the same amount of CPU loading, and that performance was comparable.

    I am not sure what he means when he says "Unlike an IMU, the inclusion of the magnetometer mean that the filter is not subject to any accumulating errors."

    The DCM algorithm is not subject to accumulating any errors. You can use acclerometers and GPS or magnetometer to keep it from doing that.

    Best regards,
    Bill Premerlani
  • 3D Robotics
    Any idea how this compares in performance with the DCM, which is the computationally inexpensive algorithm we already use on that hardware? The paper doesn't discuss it.
This reply was deleted.

Activity