You are here

Madgwick IMU Filter: Define the Sample Rate / Freq. correctly | Cypress Semiconductor

Madgwick IMU Filter: Define the Sample Rate / Freq. correctly

Summary: 11 Replies, Latest post by Stahldroid on 11 Oct 2016 10:46 AM PDT
Verified Answers: 2
Last post
Log in to post new comments.
joh9_1534041's picture
User
61 posts

Hello,

can someone explain me if Is it possible that the GyroRate and AccelerometerRate are larger than the updateIMU-Rate (i do not mean the readSensorData-Rate, this is equal to the updateIMU-Rate) or does the algorithm / code than not work?

Thank you.

 

 

General Implementation of the "Madgwick Open Source IMU algorithm" (http://x-io.co.uk/open-source-imu-and-ahrs-algorithms/)

Pseudocode:

1. Init IMU-Hardware () 

- IMU Factory Reset

- Set IMU-ACC/GYRO "LOW-PASS-FILTER" 

- Set IMU-ACC/GYRO "Scale Range"

- Set IMU-ACC/GYRO "Sample Rate"

- Activate IMU-FIFO Buffer

- Set/calibate IMU-ACC/GYRO "OffSet "

 

2. While () //Limited to Madgwick() Sample Rate

- get IMU Raw Data

- calculate ACC-G-Values and GYRO-Rad/s-Values

- MadgwickAHRSupdateIMU

- calculate Angle

 

Note: 

-It is not strictly necessary for Accelerometer and Magnetometer measurements to be synchronised with Gyroscope measurements

-You can find on Github (https://github.com/xioTechnologies/Fusion) the new "xioTechnologies-AHRS-Lib" from 8.10.2016.

 

user_1377889's picture
User
9608 posts

Yes the rate can be larger. Some of the sensors offer measuring at high frequency in the background and a transmit of data in a short time. To confirm to the algorithm you need to average (acc / s) or sum (degrees /s). There are some time constants within the Madgwick algorithm. Care that you deliver your value in the expected format which is rad/s and m/s²

 

Bob

joh9_1534041's picture
User
61 posts

Thank you Bob

joh9_1534041's picture
User
61 posts

Last short Question:

Should the Function transfer values "GX, GY, GZ" of MadgwickAHRSupdateIMU() in Degrees/sec or Radians/sec? - Or does this not matter ....

- "AX, AY, AZ" = Gravity = m / s²

 

user_1377889's picture
User
9608 posts

rad/s, as I posted earlier.

 

Bob

joh9_1534041's picture
User
61 posts

Thank you, my Mistake.

I'm right, with the assumption that the "bias drift compensation", in the Madgwick Open Source IMU algorithm (http://x-io.co.uk/open-source-imu-and-ahrs-algorithms/), is missing?

user_1377889's picture
User
9608 posts

I did a pre-flight calibration by averaging 500 sensor values at start of program assuming the device was in a standstill. I used those values to compensate for errors.

 

Bob

joh9_1534041's picture
User
61 posts

With averaging sensor (MPU6050) values at start of program (standstill),

1. this compensate the Offset-Bias,

2. warm-up/Temperature-Bias and 

3. switch-on to switch-on-Bias.

The internally DLFP of the Sensor (MPU6050)

4. compensate shock-Bias and

5. noise.

With averaging sensor values before any Madgwick-update, through the internal MPU6050-Fifo,

6. compensate or slow down the not-rotation-Bias and

7. compensate or slow down the recalculated temperature-bias, before every time using.

My Question is,

-is Nr. 1, 2, 3, 4, 5, 6, 7 true?

-Should 6 not better compensate, through recognition that the IMU is standstill and the ACC should than be more taken into account than the gyro, for position determination?

-Should 7 not better compensate, through take into account the temperature in every Madgwick-update?

user_1377889's picture
User
9608 posts

Cannot answer those questions. I would suggest you to roughly get the algorithm to work. Then fine-tune the PI-controller by setting the correct Kp and Ki. Any deviations remaining  are usually a lot smaller than the PI correction

 

Bob

joh9_1534041's picture
User
61 posts

Thats the point, the Code has no Ki ..... !? 

user_1377889's picture
User
9608 posts

Mine looks different.

 

Bob

Log in to post new comments.