Solved my skyrocket issue by adding 2 new features #10308
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Now you can disable the dynamic accelerometer weight to set it to stable 0.3 - Added a temperature compensation for the accelerometer using the baro temperature sensor. (This drastically improved the altHold performance on my quad)
mmosca
reviewed
Aug 18, 2024
| temp_correction_a = 4.834 | ||
| temp_correction_b = -217.53 | ||
| */ | ||
| const float acc_z_offset = ( positionEstimationConfig()->temp_correction_a * ( baroTemperature / 10.0f ) ) + positionEstimationConfig()->temp_correction_b; // f(x) = ax + b |
There was a problem hiding this comment.
You should be using the accelerometer temps, not the baro temps for this. The baro could be very far from the accelerometer and not be exposed to the same local temperature gradients.
mmosca
reviewed
Aug 18, 2024
| @@ -385,7 +388,11 @@ static void updateIMUTopic(timeUs_t currentTimeUs) | |||
| } | |||
| else { | |||
| /* Update acceleration weight based on vibration levels and clipping */ | |||
| updateIMUEstimationWeight(dt); | |||
| if (positionEstimationConfig()->dynamic_acc_weight) { | |||
There was a problem hiding this comment.
Not sure it this is needed. And if it is, it should not be hard coded to 0.3f when off.
|
Sounds like the problem I'm getting related to #10243. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm using the following setup:
I basically solved a skyrocket behavior by applying temperature corrections to the accelerometer measurements. I don't know if this will be helpful for anyone but I'd like to share my story.
Here's the full story:
My drone couldn't maintain a good AltHold (it had a skyrocket behavior) and I tried almost everything to get it to work. After analyzing several times all the data from the Blackbox with the INAV Blackbox Explorer I found the following things:
As you can see in the above image, the navAccel[2] variable which is used to calculate navVel[2] (estimated vertical speed) was just drifted downwards just as if it were badly calibrated (but it was properly calibrated) and therefore the estimated speed was always at a negative value. This caused the drone to think it was always falling down.
Later then I found there was a relationship between that accelerometer drifting and the temperature ( using the integrated temperature sensor of the barometer which is in the FC, where the accelerometer is located ). The thing is that my all-in-one board overheats a lot and it's temperature oscillates more than 30ºC (from 45ºC to 75ºC) and instead of just buying another one I tried to fix this someway
So I performed a test flight hovering stable in the air, took the values of the drifting and the temperature, and put them in a spreadsheet. Therefore I found that the relationship between the accelerometer drifting and the temperature was linear and very precise.
Once I got the values for the relationship I got into programming that compensation and after struggling with the code and debugging for a while (my first time touching INAV source code) I finally made it work and the results were incredible.
As you can see the drone now achives accurate vertical position estimation ( just 10-20cm away from baro readings without adding more baro weight) and there's no accelerometer drifting apparently.
I changed the least lines of code I could and programmed it so that no corrections are made unless you set those settings in the CLI.
Apart from that I also found that the dynamic accelerometer weighting just wasn't pretty helpful as my quad also has severe vibrations and its weight is always at the lowest value except when the drone is falling (the motors are spinning slower). Therefore, the accel weight is only increased when the drone descends and that doesn't help in estimating the vertical position. In the above image the blue line represents the accelerometer weight.
With these changes I created 3 new settings and now you can:
dynamic_acc_weight--> ON/OFF)temp_correction_aandtemp_correction_bas for the f(x) = ax +b formula )