Closed brightproject closed 1 month ago
xioTechnologies
commented
1 month ago 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.
brightproject
commented
1 month ago 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.
xioTechnologies
commented
1 month ago 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.
brightproject
commented
1 month ago 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?
xioTechnologies
commented
1 month ago 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.
brightproject
commented
1 month ago 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 / 100on line 37 for a sample rate of 100 Hz. You need to change this to1 / 26.36to 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?
xioTechnologies
commented
1 month ago 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.
brightproject
commented
1 month ago 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
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 secondsThe 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.008fAnd 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.
xioTechnologies
commented
1 month ago 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.
brightproject
commented
1 month ago 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 HzThus, a SAMPLE_PERIOD of 0.0340 seconds corresponds to a frequency of approximately 30 Hz.
Could you convert this issue into a discussion?
xioTechnologies
commented
1 month ago 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:
I was expecting you to confirm the actual sample rate, verified in such a way that previously reported values could be discounted.
brightproject
commented
1 month ago 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
https://github.com/xioTechnologies/Fusion/issues/99#issuecomment-1513751508
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 secondsAs 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.
xioTechnologies
commented
1 month ago I want to help you but you refuse to engage with the process. I am leaving the discussion. Good luck.
brightproject
commented
2 weeks ago I want to help you but you refuse to engage with the process. I am leaving the discussion. Good luc
@xioTechnologies If may, I ask a question?
I managed to collect data from the flight, I filtered this data and put it into an advanced filter example.
I first rotated the X and Y axes of the gyroscope, because The reference system of the aircraft isNED, but for the example you need ENU.
The filtered data file is below.
real__flight_data_filtered.csv
The filter parameters are as follows.
ahrs.settings = imufusion.Settings(imufusion.CONVENTION_ENU, # convention
0.7, # gain
0.8, # gyroscope range
0.8, # acceleration rejection
10.5, # magnetic rejection
# 5 * sample_rate) # recovery trigger period = 5 seconds
600) # recovery trigger period = 5 secondsResult
It's impossible to figure this out without your help.
Thank you.
Thanks to the team @xioTechnologies I succeeded to test a simple implementation of the
xioTechnologiesfusion sensor. I'm getting raw gyroscope angular velocity and accelerometer acceleration data from theFlightGearflight simulator. Background here. I managed to compile a simple example forstm32f411, for compilation I used the Arduino platform(using a combination of arduino-cli + visual studio. Raw data sampling from avia simFlightGear- acceleration inm/s/s, gyro rates inrad/sec. I convert the data into thexioTechnologies.performed at about 30-40 Hz.
I set these values:
#define SAMPLE_PERIOD (0.04f) // 40Hz.I tried also the following values:#define SAMPLE_PERIOD (0.005f) // replace this with actual sample periodWith the last value of 0.005 the algorithm is more efficient. Perhaps I think this meaning is wrong? Example code I'm using.I tried different parameters from, but did not notice any significant differences.
I get the following values for calculating orientation angles for a prolonged right roll. It can be seen that in the presence of gyroscopic speed around the
X axis, the right roll angle begins to increase. When the roll angle reaches+19.135degrees, the roll angle begins to decrease, although the angular velocity of rotation around the X axis is still there. The smallest angular velocity around theX axiswill begyro_x: 0.000190and then the plane begins to turn left along the roll and levels out. It seems as if the algorithm calculates the roll angle normally at first, but then the acceleration factor along theZ axisbegins to influence prematurely and the acceleration value exceeds1G.Pythonscript for drawing graphs. Initially, the plane makes a right bank, then descends, then gains altitude and makes a left bank. At the very bottom, the orientation angles produced by the simulator are drawn in green; the remaining angles are calculated by the algorithmxioTechnologies. The only thing that coincided was the yaw...albeit a 140-degree shift.But in video more visual representation compared to text output. https://www.youtube.com/watch?v=cWlsb3izkYQ
GUIon Processing from here with minor modifications. At rolls of up to 10 degrees, the algorithm handles the evolutions quite well. But if a prolongedrollbegins, then the roll value calculated using thexioTechnologiesalgorithm first advances ahead of the real roll angle, which is displayed by thePFD Airbus A320, and then begins to return to zero. And when the real roll angle (on thePFD) begins to move in the opposite direction, i.e. the plane levels out in the horizon, the roll value calculated by thexioTechnologiesalgorithm begins to move in the opposite direction, aggravating the situation. The reason for this is centrifugal acceleration, which cannot be distinguished from gravity. The situation with thepitchangle is approximately the same. I deliberately do not try to use an advanced example because I want to practice the basic settings of the algorithm with a simple example. How can I tell if the algorithm was initialized based onaccelerometerandgyroscopedata? How to correctly use algorithm flags and how to activate them?Perhaps this behavior of the roll angle during a long turn is typical and normal for an algorithm that uses only a gyroscope and an accelerometer as input data? Can you please tell me how to configure the algorithm to work acceptable with the data obtained from the flight simulation on
FlightGear. Or do you recommend going straight to the advanced example and already working on its settings? I need some time, several experiments and tips from(if it is possible) the authors of the algorithm to understand and configure the code properly, first using a simulator, then I want to introduce some noise to simulate realMEMSsensors, and then try the configured algorithm in a real flight with sensors, likeBNO055.