PSoC 5, 3 & 1 MCU

[Anonymous]

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.

[JoMe_264151]

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

[Anonymous]

Thank you Bob

[Anonymous]

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²

[JoMe_264151]

rad/s, as I posted earlier.

       

Bob

[Anonymous]

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?

[JoMe_264151]

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

[Anonymous]

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?

[JoMe_264151]

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

[Anonymous]

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

   

[JoMe_264151]

Mine looks different.

       

Bob

   

[Anonymous]

Sorry but maybe my mistake, you posted the "Robert Mahony nonlinear complementary filter" rewritten with Quaternions from S. Madgwick. (R. Mahony: https://hal-univ-tlse3.archives-ouvertes.fr/hal-00488376/document)

   

The Filter of S. Madgwick use Quaterninos and the "gradient descent algorithm" (see my post - block Diagram) ..... (S. Madgwick: https://www.samba.org/tridge/UAV/madgwick_internal_report.pdf)