ultrazar
commented
1 month ago And regarding my problems with the accelerometer Z drift, I stopped using corrections based on the temperature because it is imprecise and the temp sensors are slow detecting rapidly changing temperatures. Therefore, the method that I use now is basically to smooth navAcc[2] measurements (it should always end up being 0 for most flight manuevers, as the acceleration always tends to go to zero instead of the velocity) and subtract that in final navAcc[2] variable. In this way, there will never be any drift in Z acceleration estimation that can affect other estimations.
I firslty performed tests of this method in Python using real Blackbox data to see how it could manage real flight data:
The red line represents normal navAcc[2], with high level of drift due to temperature changes
The blue line is the estimated drift from navAcc[2], basically applying a simple real-time smoothing algorithm.
The black line would be the final estimated Z acceleration by subtracting the estimated drift from navAcc[2]
I've already implemented this in my INAV fork some months ago and It has been working pretty well actually, I think it even gently improves overall Z position/velocity estimations in fully-functional and calibrated FCs.
I might do a PR on that if there's anyone interested.
mmosca
I saw that it might be useful to have the ability to read the temperature data from the ICM42688P sensor. https://github.com/iNavFlight/inav/pull/10382#issuecomment-2408771001 So I've previously implemented that function back when I was doing the accelerometer temperature compensation. It differs by 3-4ºC from the baro but seems to work well. The implementation is based on the offcial datasheet and following the same code structure used for similar drivers such as the mpu6000 in inav