Application Questions
AndreyDiDev opened this issue · comments
Hi,
First, would like to thank you for sharing this algorithm and all your work!
We plan to fly the filter on our rocket, given that, I wanted to ask if you have any advice pertaining to the algorithm tuning for that purpose? For example, changing the settings to better fit the higher acceleration. I read that we should monitor the acceleration recovery flag and our IMUs do support the Gs they will experience. But I am wondering if I would need to modify the gain or any other settings? I also read that 10 is the acceleration rejection threshold for most applications, but do you think this will hold for our case?
Thank you in advance!
I expect your highest priority will be good gyroscope calibration and as higher sample rate as possible. If possible, I suggest you also log the raw data so that you can reprocess everything through Fusion after the fact to explore different configurations.
The gyroscope offset correction algorithm could be very valuable here. It would use the stationary period (ideally 5 seconds or more) just before take off to ensure your gyroscope bias is as small as possible.
The gain would not really be relevant to this application so leave it at 0.5. The accelerometer will be unusable as a reference of orientation while the rocket accelerates up. The algorithm should identify this and reject accelerometer measurements during this period. You should monitor the acceleration rejection timeout flag, as you have said. A acceleration rejection threshold of 10 degrees is a good starting point. Ideally it would be reduced but only if the accuracy of your sensors permit.
Thank you for the quick reply and help!
So once we get the calibration parameters, at the start we use the offset initialise, and after we use the gyroscope offset update function every measurement ?
You mentioned that the threshold for rejection should ideally be reduced, would that be the sensor's sensitivity on the datasheet?
Additionally, would the corner frequency I found on the datasheet be the same cutoff frequency for this algorithm?
Lastly, are the settings and gyro measurements all in dps and g, and are the input and output units of the acceleration in m/s^2 ?
The acceleration rejection setting is described in the README as follows. This has nothing to do with accelerometer sensitivity.
Threshold (in degrees) used by the acceleration rejection feature. A value of zero will disable the feature. A value of 10 degrees is appropriate for most applications.
The operation of the acceleration rejection feature is described in this section.
I'm not sure what you mean by the "cutoff frequency for this algorithm" . The bandwidth of the system is the bandwidth of the sensor data you provide. The algorithm is agnostic to this.
All measurement units are in the code documentation. From Ahrs.c:
* @param gyroscope Gyroscope measurement in degrees per second.
* @param accelerometer Accelerometer measurement in g.
* @param magnetometer Magnetometer measurement in arbitrary units.
* @param deltaTime Delta time in seconds.
I understand, thank you once again!
The last problem I am having is with running our own flight data. This is the raw data graph
I ran it with the C files and it produced this
But when I run the same data with the python API it outputs a different graph,
I dont know which one is the right one, which I would need to know to debug my own version of the algorithm and cross-reference the correct filtered values. My algorithm gives a different graph from the previous two as well.
Given their Earth Acceleration is similar and close to Altimeter data, I am confused why the Euler angles, internal states and flags graphs look different?
If its possible, I can send you the data to see which one is correct? The only addition I've made to the C and Python versions is creating my own tests but tried to make them the same.
Thank you for your time and help!
I think there is an error in your units. Those gyroscope values don't look like "milli-deg/s", and "milli-G/s^-2" is just a distance of 9.81 mm. I expect you mean mg.
The Python plot appears to be more accurate because the acceleration error is lower, indicating greater agreement between the gyroscope and accelerometer.
I checked with our team and they said it should be milli-gs and milli-dps, we are not entirely sure though. Also, I dont know the exact difference between mg and milli-G? What do you think is the right number to divide the values to get the best results?
I reran the graphs and once I divide all values by 10000 instead of 1000 my graph looks same as the Python API one. But I only divided the Python ones by 1000.
But then the acceleration is messed up
Assuming Python is the best one, the graph doesnt seem correct? Because I don't think our rocket should be rotating to these extremes in all axes (parachute deploy ruins it after the 30 seconds)? But before that, at best, it could be rolling a lot ?
mg (Milligram): mg stands for milligram, a standard unit of mass in the metric system. It represents one-thousandth (1/1000) of a gram (g).
Milli-G (milligee): written with a capital G to distinguish it from milligram (mg), is a unit of acceleration equal to one-thousandth of the standard acceleration due to gravity.
Milli-gs: "gs" is not a recognized unit abbreviation. could potentially stand for several things, like grams (g) or giga-seconds (Gs). However, "milli-gs" wouldn't be a common way to express a thousandth of either. It's possible it's a custom unit used in a specific field, but without context, it's impossible to say for sure.
(My guess it is one-thousandth (1/1000) of standard gravity (G), Milli-G (milligee):)
Milli-dps: "dps" is not a recognized unit abbreviation. It's possible it's a custom unit used in a specific field, but without context, it's impossible to say for sure.
(My guess it is one-thousandth (1/1000) of a degree every second)
| Unit | Description | Standard Unit |
|---|---|---|
| mg | one-thousandth (1/1000) of a gram (g) | Yes (mass) |
| milli-G | one-thousandth (1/1000) of standard gravity (G) | Yes (acceleration) |
| milli-gs | Unknown | No |
| milli-dps | Unknown | No |
If you encounter milli-gs or milli-dps, ask for clarification on the specific field or context where they are used.
Also if you are using C including definition FUSION_USE_NORMAL_SQRT in FusionMath.h will slow down execution speed for a small increase in accuracy.
I see, thank you for the thorough explanation.
Forgive me for all my questions. But, does the "Filtered-My Version" Acceleration in the first graph seem good, shouldn't it be closer to the Altimeter's acceleration graph ? I am just worried if I translated the algorithm properly in cpp and correctly integrated it in our systems, somewhere along the way I could've made a mistake ?
In this context, g, mg, μg, etc. refers to g ,the acceleration due to gravity equal to approximately 9.81 m/s/s. dps is often used in place of °/s. These units and written expressions are well established in the industry. Upper-case G is never used to refer to g and I suggest you avoid it.
Why did you "translated the algorithm" to C++? The algorithm is already in C and should already compile within a C++ project?
I had to condense it into a cpp and a hpp files and encase it in a class so we can call it for our complementary filter.
My main concern is the encasing, the pointers for the different objects could've messed up. Since I made some functions members of the class and the ones that didnt need to be I left them non-members. Also, had to properly connect the AHRS, flags and states objects to the single instance of the encapsulating class. As far as I can tell, for this data it seems similar to the originals. Just want to confirm
If you need a specific C++ interface layer then I suggest you only wrap the C calls, and leave the library unmodified.
That is a good idea.
Also, for the axes swap, I would need to call it on every measurement before I call the update, right?
For calibration, we would only need to do it if the gyro reads non-zero values while stationary and drifts? The accelerometer is the same idea but with 9.81 for one of the axis and should be zeros for the other axes?
I saw that you said in #96 that they had "high gyroscope offset errors", where did you see that?
You would call FusionAxesSwap whenever you want to swap axes, in the same way you would call FusionRadiansToDegrees whenever you wanted to convert radians to degrees.
I suggest you search online to learn about calibration. There are plenty of resources and they will far more useful to you than any comments I would share here.
In #96 I said "You appear to have extremely high gyroscope offset errors." in response to their graph. I could see the high gyroscope offset errors in the graph.
I am curious how you could tell from just the graphs? Do the Gyro X and Y need to be almost 0 ? Or you could tell since the acceleration error is very high?
You also said that on ascension the accelerometer should be ignored, but from the graph it isnt for most of it. Does that mean I need to increase the acceleration rejection or that the IMUs we have are sufficient for the application (I checked and they do support the gs they experienced) ?
If a gyroscope is stationary then it should measure 0 dps. I expect your main issue is poor sensor calibration. The acceleration rejection feature will be of little use, and may only make things worse, if your raw sensor data is unreliable.
We are running tests right now.
But the first 10 seconds is when the rocket is accelerating, so shouldn't the accelerometer be ignored for all of that, as you said? Also, the acceleration error starts high but then is low during the first 10 seconds, shouldn't it be higher?
My original comments assumed that you were providing calibrated sensor measurements. Your comments since suggest that this not the case. I am not able to comment on the behaviour of the algorithm while the quality of the inputs is so unclear.
I apologize for not clarifying that. When we are done calibrating, I will keep your advice in mind.
Just to make sure, when you said that the gyroscope offset correction algorithm would be useful, you mean to have the loop that calls the correction and then the update start before launch for at least 5 seconds ? Also, is the longer, the better for the initialization period ?
I appreciate your help in answering all my questions!
You should call FusionOffsetUpdate every update as per the example. The gyroscope offset correct algorithm is intended to run continuously in the background without the user needing to worry about it. I suggest you treat it like that just proceed as normal.
I've seen a few times that this library is not for calibration. However, I've looked at a few calibration libraries, in particular for the gyroscope as you said, and I just wanted to confirm that most ones are compatible with the calibration model you are using? For example, https://www.mathworks.com/help/nav/ref/gyroparams.html seems good where,
Measurement Range -> gyroscopeRange ?
Constant Bias -> Fusion Offset ?
Axes Misalignment -> Fusion Misalignment ?
Bias Instability -> Fusion Sensitivity? or the Datasheet sensitivity ?
I dont know if those are correct, and where the AccelerationBias would go since that is all for gyroscope calibration?
I would also like to know what software do you use for calibration
I cannot comment on "most" calibration tools because I am only aware those discussed in #103. Your example is a gyroscope simulation model, not a calibration tool.
x-io products are calibrated using specialist equipment and priority software. There are no public resources for these priority solutions.
Would leaving it stationary on a table and averaging the zero-offset be better than nothing ? And would that be the offset in the Fusion algorithm, and everything else is kept the same (identities and zero vectors for the other ones) ?
I suggest you search online to better understand calibration. You've said a few things in this thread which suggest you are not familiar with some engineering fundamentals and I do not want to share comments that risk being misunderstood.
I understand. We are students, so we are still learning these things. Nevertheless, I appreciate all your help