Need some help setting up the algorithm. about fusion

[xioTechnologies]

I'm afraid that there is just too much in the post for me to effectively answer. I suggest you start from the simple example which does not require any configuration or setup, and then post your questions or issues so that we deal with them one at a time.

[xioTechnologies]

As I said, I cannot offer a useful response to your original post. I suggested a way we could proceed but if that does not work for you then I probably won't be able to help.

[xioTechnologies]

The CSV columns should be: Time (s),Gyroscope X (deg/s),Gyroscope Y (deg/s),Gyroscope Z (deg/s),Accelerometer X (g),Accelerometer Y (g),Accelerometer Z (g). Your gyroscope and accelerometer columns look ok.

The difference between the first two time values in your CSV file corresponds to a sample rate of 26.36 Hz. simple_example.py includes the expression 1 / 100 on line 37 for a sample rate of 100 Hz. You need to change this to 1 / 26.36 to match your data.

I do not understand the sentence, "The number of samples is still 28 Hz".

I wrote this reply before you edited your post. You have since added allot more your post, confusing the discussion. I can't help you if this is how you are going to communicate.

[xioTechnologies]

Your questions about configuration, features, and expected behaviour are all moot until you can get the basics working. It sounds like you are not sure what your sample rate is, or even if it is fixed.

Before you do anything else, you need to determine your sample rate and/or the timestamps of measurements.

[xioTechnologies]

I have asked that we tackle issues one at a time, and I identified the unknown sample rate as being the critical issue that must be solved before anything else. I can't support you unless you engage with what I am saying.

[xioTechnologies]

The first step is for you to run simple_example.py with valid data. This means using the correct sample rate and timestamps. I am not confident that the latest sample rate you have reported is correct because you have reported numerous other conflicting values:

• "The number of samples is still 28 Hz"
• sensor_data_v4.csv - The timestamps in this file correspond to 26.36 Hz.
• "Here's a 35 Hz sample"
• "from the simulator greater than 40 Hz, then I propose to assume that my samples are at this frequency"
• sensor_data_v7.csv - The timestamps in this file correspond to 10 Hz.
• "Frequency ≈ 29.4118 Hz"
• "frequency of approximately 30 Hz"

I was expecting you to confirm the actual sample rate, verified in such a way that previously reported values could be discounted.

[xioTechnologies]

I want to help you but you refuse to engage with the process. I am leaving the discussion. Good luck.

[brightproject]

I'm afraid that there is just too much in the post for me to effectively answer. I suggest you start from the simple example which does not require any configuration or setup, and then post your questions or issues so that we deal with them one at a time.

Thank you for your answer, I really appreciate your support and nothing bad will happen if you can’t help me.
Using a simple example, in the post above I slightly changed the output data, if you look at the graphical plotting of the orientation angles obtained from the simulator and calculated by the algorithm.
What could be the reason for this manifestation?

Left roll, descent, right roll, climb.
Blue line - the algorithm calculates, green line - I receive angle data from the simulator.

[brightproject]

As I said, I cannot offer a useful response to your original post. I suggested a way we could proceed but if that does not work for you then I probably won't be able to help.

I recorded data without a magnetometer.
sensor_data_v4.csv
Ran a simple example, the result is this:

The video shows the flight itself
https://www.youtube.com/watch?v=AN81DyVbvak

Have I prepared the gyroscope and accelerometer data correctly for input into the algorithm?
The number of samples is still 28 Hz.
In the example file sensor_data I see a sampling rate of 100 Hz.
Unfortunately, getting raw data from the simulator at a high enough frequency is a big problem.
Here's a 35 Hz sample
sensor_data_v5.csv

Which is the maximum I can get from FlightGear, despite telling the simulator to output 100 samples per second.
C:\Program Files\FlightGear 2020.3\bin>fgfs --generic=serial,out,100,\\.\COM15,230400,insgns-imu2 --aircraft=A320neo-PW
I also tried the advanced example, again without a magnetometer, for this I slightly modified the example code by changing these lines:

data = numpy.genfromtxt("sensor_data_v5.csv", delimiter=",", skip_header=1)

sample_rate = 30 # 30 Hz

timestamp = data[:, 0]
gyroscope = data[:, 1:4]
accelerometer = data[:, 4:7]
# magnetometer = data[:, 7:10]
# magnetometer = [1, 1, 1]
magnetometer = [0, 0, 0]
# Convert the list to a numpy array
magnetometer_array = numpy.array(magnetometer)

# Instant algorithms
offset = imufusion.Offset(sample_rate)
ahrs = imufusion.Ahrs()

ahrs.settings = imufusion.Settings(imufusion.CONVENTION_NWU, # convention
 0.5, #gain
 2000, # gyroscope range
 #250, #gyroscope range
 #10, #acceleration rejection
 0, # acceleration rejection
 #10, #magnetic rejection
 0, # magnetic rejection
 5 * sample_rate) # recovery trigger period = 5 seconds

# Process sensor data
delta_time = numpy.diff(timestamp, prepend=timestamp[0])

euler = numpy.empty((len(timestamp), 3))
internal_states = numpy.empty((len(timestamp), 6))
flags = numpy.empty((len(timestamp), 4))

for index in range(len(timestamp)):
 gyroscope[index] = offset.update(gyroscope[index])

 # ahrs.update(gyroscope[index], accelerometer[index], magnetometer[index], delta_time[index])
 ahrs.update(gyroscope[index], accelerometer[index], magnetometer_array, delta_time[index])

The result is as follows:

As far as I understand, the actual roll angle, which the plane was turning towards, was 30 degrees and lasted from x=64 to x=110.
For some reason, the algorithm calculated the roll at 88 degrees at the beginning, then decreased to 0, and then became -48 degrees and then returned to 0 again.
The situation is similar with the left roll.
I would be very grateful for clarification, although it seems to me that the algorithm works fine, and this is apparently its limits.
Or am I setting it up incorrectly?

[brightproject]

I do not understand the sentence, "The number of samples is still 28 Hz".

This means that I made the first data sample and calculated that I get 28 samples/rows per second, and concluded that the sampling rate is 28 Hz.
After that, I made a second data sample, and in this I received 35 samples/rows of data per second.

The difference between the first two time values in your CSV file corresponds to a sample rate of 26.36 Hz. simple_example.py includes the expression 1 / 100 on line 37 for a sample rate of 100 Hz. You need to change this to 1 / 26.36 to match your data.

Thanks, I changed the divisor number and got this result.

I play with the parameters of the algorithm, not yet understanding its operation well enough.
But I couldn’t get it to hold the bank angle in a turn for long enough.
And the main question here is - the algorithm does not allow you to compensate for centripetal acceleration during rolls and turns, or do I need to study the operation of the algorithm better and adjust it?

[brightproject]

Your questions about configuration, features, and expected behaviour are all moot until you can get the basics working. It sounds like you are not sure that your sample rate is, or even if it is fixed.

Before you do anything else, you need to determine your sample rate and/or the timestamps of measurements.

Unfortunately, after writing one question, I continue to search for a solution to the problem, and certainly additional questions arise, and I update/edit/supplement the original request, and can’t do anything about it, please understand and forgive me.
Regarding the sample rate issue, because... I use a flight simulator, and for objective reasons I cannot get a sampling frequency from the simulator greater than 40 Hz, then I propose to assume that my samples are at this frequency.
Collected data in file

sensor_data_v7.csv

Running a simple example shows that the orientation angles are not stabilized and the roll quickly decreases (this is not even a roll, but a sawtooth movement), although the roll angles are long in nature

Advanced example used with the following settings

ahrs.settings = imufusion.Settings(imufusion.CONVENTION_NWU,  # convention
# ahrs.settings = imufusion.Settings(imufusion.CONVENTION_ENU,  # convention
                                   # 0.01,  # gain
                                   # 0.05,  # gain
                                   # 0.6,  # gain
                                   0.008,  # gain
                                   # 0.00000,  # gain
                                   0,  # gyroscope range
                                   # 2000,  # gyroscope range
                                   # 250,  # gyroscope range
                                   1,  # acceleration rejection
                                   # 0,  # acceleration rejection
                                   1,  # magnetic rejection
                                   # 0,  # magnetic rejection
                                   # 5 * sample_rate)  # recovery trigger period = 5 seconds
                                   1)  # recovery trigger period = 5 seconds

The result is as follows

It can be seen that the bank angle became longer, however, immediately after the right bank, the return to straight flight was not at 0 degrees.
And then I noticed some strange things if you specify the parameter
0.00000, # gain
Then the picture will be as follows

It turns out with zero sensitivity, roll angles almost always return to zero degrees, although in fact the lines just narrowed a little along the Y axis and jumped up a little.
I also don’t quite understand the following - the plane in the simulator rotated in the bank angle by +-30 degrees.
But the simple and advanced example, for unknown reasons, show roll angles of 5 degrees - could you please comment on this?
I already looked at the example code, I thought maybe the scaling was wrong somewhere ... but with the test data sensor_data.csv all the angles are normal.
My python self-code shows excellent results from the collected data

The parameters of the C++ code algorithm are as follows:

const FusionAhrsSettings settings = {
// info about convention
// https://github.com/xioTechnologies/Fusion/issues/117#issuecomment-1677998150
        .convention = FusionConventionNwu,
        // .convention = FusionConventionEnu,
        // .convention = FusionConventionNed,
        // .gain = 1.5f,
        // .gain = 0.6f,
        .gain = 0.008f,
        // .gain = 0.0079f,
        .gyroscopeRange = 0.0f, /* replace this with actual gyroscope range in degrees/s */
        // .gyroscopeRange = 250.0f,
        // .gyroscopeRange = 500.0f,
        // .gyroscopeRange = 1000.0f,
        // .gyroscopeRange = 2000.0f,
        // .accelerationRejection = 5.0f,
        .accelerationRejection = 0.0f,
        // .accelerationRejection = 0.6f,
        // .magneticRejection = 90.0f,
        .magneticRejection = 0.0f,
        // .recoveryTriggerPeriod = 0.0f,
        // .recoveryTriggerPeriod = 0.14,
        // .recoveryTriggerPeriod = 0.142,
        // .recoveryTriggerPeriod = 5 * SAMPLE_PERIOD, /* 5 seconds */
        // .recoveryTriggerPeriod = 37500 * SAMPLE_PERIOD, /* 5 seconds */
};

These are quite acceptable results for me and there are plans to improve them using a magnetometer.
I verified that the algorithm could maintain roll and pitch angles despite prolonged tilts, ascents, and descents.
I was able to tune the algorithm only by selecting the SAMPLE_PERIOD and .gain coefficients
Based on the results of searching for coefficients, I settled on the following

SAMPLE_PERIOD (0.0342f)
.gain = 0.008f

And again, I noticed some strangeness, or rather a pattern, which in no way relates to the fusion algorithm.
The pattern applies to my code, which is executed on STM32F411 and it is as follows - when I execute the code without collecting data samples, then with the SAMPLE_PERIOD coefficient indicated above, the fusion algorithm is not bad, it maintains the roll and pitch angles without errors for 30-60 seconds.
But if I want to collect data samples, then I introduce an additional load into the microcontroller code, and the microcontroller executes the program, including
FusionAhrsUpdateNoMagnetometer(&ahrs, gyroscope, accelerometer, SAMPLE_PERIOD);
A little longer and I have to change the SAMPLE_PERIOD factor.
I also thought that this notorious SAMPLE_PERIOD coefficient is similar to the sample_rate coefficient from an extended example in Python.
But it turned out that the sample_rate coefficient cannot even be given a fractional value.
I probably still don’t fully understand the magic of the settings of the fusion algorithm, but I understand that the operation of the algorithm greatly depends on the quantity, i.e. frequency of data from the gyroscope and accelerometer, as well as selection of coefficients in the code section:
imufusion.Settings
I hope another long text did not confuse you.
Thank you.

[brightproject]

I have asked that we tackle issues one at a time, and I identified the unknown sample rate as being the critical issue that must be solved before anything else. I can't support you unless you engage with what I am saying.

My SAMPLE_PERIOD is 0.0340 seconds, then:

Frequency = 1 / 0.0340
Frequency ≈ 29.4118 Hz

Thus, a SAMPLE_PERIOD of 0.0340 seconds corresponds to a frequency of approximately 30 Hz.
​
Could you convert this issue into a discussion?

[brightproject]

I was expecting you to confirm the actual sample rate, verified in such a way that previously reported values could be discounted

Now I have conducted a series of tests, and I realized that the sample frequency that the simulator produces is not a constant, this is precisely a simulation problem, because the sampling frequency is tied to the FPS of the simulator itself.
Still, I managed to run the eighth version of the collected data samples:
sensor_data_v8.csv
Simple example:

Here I also tried to output the quaternion mapping, but I couldn't solve the issue with this line of code
quaternion[index] = ahrs.quaternion.array

#99 (comment)

Advanced example

Advanced example used with the following settings

ahrs.settings = imufusion.Settings(imufusion.CONVENTION_NWU,  # convention
                                   0.0001,  # gain
                                   0,  # gyroscope range
                                   50,  # acceleration rejection
                                   0,  # magnetic rejection
                                   10)  # recovery trigger period = 5 seconds

As far as I understand the setting of the algorithm, SAMPLE_PERIOD sets the rate of change of the orientation angle, and GAIN sets how long during the roll the angle will not decrease while the roll itself is in progress.
I have already begun to understand a little about the operation of the algorithm, the only thing that is not clear is how to enable acceleration when the plane is in horizontal flight, so that gravity corrects the position of the bank angle.
Now, with a roll of -+30 degrees, the roll is calculated accurately, and the roll lasts a long time, but when the plane levels out into horizontal flight, the roll becomes not 0 degrees, but -+5.
This changes the pitch angle.
As if there is no calculation of the gravity vector or it is not used.