I am developing a prototype attitude indicator.
I use a board LSM6DS3 as accel + gyro sensors + STM32 as microcontroller for mathematics and ESP32 for graphics generation.
I do not enter the values of the magnetometer axes, and according to the library code
in the case of mx = 0, my = 0, mz = 0 the filter will only take the value of accelerations and angular velocities of the gyroscope.
On the ground this filter works great.
What is being measured is not gravity, but centripetal acceleration.
Accordingly, you need to compensate for this somehow.
I found only theoretical materials, but no one implemented it in code, except perhaps iNavFlight.
What do these coefficients give?
#define sampleFreqDef 512.0f // sample frequency in Hz
#define betaDef 0.1f // 2 * proportional gain
My knowledge of programming is not very good, and I cannot implement any ideas in the program, although there are many different options for solving the problem.
As far as I understand this process - it is necessary, at the beginning of a right or left roll, to give priority to the data from the gyroscope, and “mute” the accelerometer data, when the turn ends, the data from the accelerometer again takes priority over the angular velocity data from the gyroscope.
Can anyone explain whether it is possible to implement compensation for centrifuge forces in MadgwickAHRS or is this filter not capable of working in flight?
I found and use a more “advanced” filter, which adds the magnetometer signal.
I haven't tested it in flight yet.
I wanted to refine and test the MadgwickAHRS filter.
After all, even filtering only using an accelerometer and magnetometer gives the roll, pitch and yaw angles.
Actually, the sum of the two. The filter uses the measured direction of gravity as the vertical reference, which is not correct when any acceleration other than that due to gravity is present. There is nothing you can do about that.
The magnetometer will tell you the direction of North, which does not help.
Many places have come across information that it is impossible to compensate for centrifugal force without data on speed, and GPS is used for this.
In an article that talks about noise measurement matrix .
But there we are talking about Kalman filtration, and on Madgwik it is impossible to compensate for centrifugal forces?
In this code, can the coefficients make it possible to adjust the "weight" of the accelerometer or gyroscope in the merge?
Can you tell me in what units acceleration, angular velocity and data from the magnetometer should be supplied to the input?
I tried to submit accelerations in G, angular velocity in degrees/sec (because I saw that inside the library the angular velocity is converted to rad/sec), I tried the magnetic field strength in Gauss.
I also tried to submit accelerations in m/s/s, and the magnetic field strength in microTesla.
But I didn’t notice much difference in the filter’s performance.
In what units is it more correct to submit the original input data?
The Madgwick filter assumes that the accelerometer data represent the direction of gravity, which is violated by a component due to centripetal acceleration.
The algorithm requires the accelerometer and magnetometer data to be normalized: a vector of length 1. Many implementations of the filter do that internally, with code that looks something like this, so if you supply data in some units, those units will be automatically removed.
// Normalise accelerometer measurement
recipNorm = invSqrt(ax * ax + ay * ay + az * az);
ax *= recipNorm;
ay *= recipNorm;
az *= recipNorm;
// Normalise magnetometer measurement
recipNorm = invSqrt(mx * mx + my * my + mz * mz);
mx *= recipNorm;
my *= recipNorm;
mz *= recipNorm;
sampleFreqDef must be the actual sample frequency.
In this code , can the coefficients make it possible to adjust the "weight" of the accelerometer or gyroscope in the merge?
No. You are probably thinking of the complementary filter. That approach might be useful for approximately level flight, but the gyro will drift during slow turns.
Finally, the Kalman filter is general and can fuse any data, (you have to provide a "system model") but GPS adds only position data, not orientation data.
Thank you for your answers.
It seemed to me that you could help me, but you simply respond with some kind of “textbook”” answers that I already know.
I understand filtration and its task, I am now interested in the issue of compensation for centrifugal forces, i.e. adding to the filter a function for determining the magnitude of the centrifugal force and subtracting it from the acceleration force determined as a result of the turn.
Or weakening the value of data from the accelerometer, and strengthening the gyroscopic component.
It seemed to me that you are the author of the AKhRS library, and perhaps you have more skills than me.
Some are able to compensate for centrifugal forces; above I provided materials on this work.
Why such an AHRS that does not show its position in flight?
Maybe you have enough skills to add a centrifugal force compensation function to the Arduino AHRS library - as an experimental one, for example?
