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.
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
Thank you Bob
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²
rad/s, as I posted earlier.
Bob
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?
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
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?
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
Thats the point, the Code has no Ki ..... !?
Mine looks different.
Bob
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)