My understanding has been that in IMU calibration, the output of the accelerometer subject to gravity pull is set to 1 ( or -1 ) and the others to zero so theoretically the bias of the X-axis accelerometer should be removed. no ?
I don't actually know what the IMU calibration accomplishes. Maybe my view that a calibration won't fix this is a sublimated form of confirmation bias. I've not seen a case where there is compelling evidence that a calibration fixed a problem. This is the first time I've seen an accelerometer bias this large. It's be interesting to see if that bias is removed or reduced.
About 4 years ago I did some experiments with my P3A. At the time many people thought an absolutely level surface was required for calibration. In my experiments the calibration was performed on a surface that was 5° off level. The subsequent flight tests did not show any drifting or erratic flight. With present day Mavics it's hard to even know what an absolutely level orientation would be.
Some accelerometer bias shouldn't be a problem. E.g., hovering isn't achieved by getting the X and Y accelerometers to show 0.0. The present flight illustrates this. Not withstanding the wind calcs problem there was no drifting, erratic flight, etc. The uncommanded altitude changes are a bit suspicious though.
It's possible that a calibration determines the noise profile of the accelerometers. Knowing this could be used to set the gains in the Kalman filters being used by the Flight Controller.
In the DAT log csv I find 7 columns with titles that contain the word "tilt"
1) IMU_ATTI(0):tiltInclination:C .............which I guess is the overall angle of tilt irrespective of direction.
2) IMU_ATTI(0):tiltDirectionBodyFrame:C .......which I guess it the direction of greatest tilt with respect to possibly the fore aft line
for a randomly chosen line I see the following values for the next four tilts
3) CtrlAllocation:raw_tilt_x -10.374107
4) CtrlAllocation:raw_tilt_y 13.112455
5) CtrlAllocation:fix_tilt_x -5.0767117
6) CtrlAllocation:fix_tilt_y 6.4167595
7) CtrlAllocation:tilt_scale .............I haven't a clue about
I assume "x" refers to the fore aft direction (pitch) and "y" the side to side (roll). are my guesses etc. correct?
I am curious why 5) is approximately half 3) and why 6) is approximatley half 4)? (in other places the pairings seem equal to one another)
I have just had a look at one of my logs and 5) & 3) are consistantly fairly equal as are 4) & 6).
I looked at the CtrlAllocation data back when the MM uncommanded descent was a hot issue. Check out
Mavic Mini uncommanded descent tests
Fix_tilt_x = raw_tilt_x * tilt_scale. Normally, tilt_scale is 1.0. My theory is that it gets set lower when the FC decides that lateral movement should have a lower priority than altitude control.
The same can be said for raw_tors, fix_tors and tors_limit_scale.
Raw_lift and fix_lift are a little different. The bound_max and bound_min seem to be somehow related differences between raw_lift and fix_lift but that's as far as I got. There is no lift_scale. But, DatCon computes a lift_diff (which really should have a :C suffix).
The IMU:tilt data are computed by DatCon - note the :C suffix on those data.
www.phantomhelp.com
