Bitcraze Forums

Dear All,

I have ran into a problem with the accelerometer and thus controlling the drone. In the picture below you can see two graphs with logged data from a flight. On the left graph you can see the wanted linear acc (orange) and the measured linear acc (blue) in x direction. The right graph shows the position in x, with orange the command en blue the state. As you can see during the command the position is almost constant, but the accelerometer data shows a value of around 0.4g. Both the accelerometer data is in the inertial NED frame.

So it thinks it has a forward acceleration but in the end the drone is not moving forward. What can cause this? Is there a way to re-calibrate the accelerometer? Due do working with the INDI controller which is not stable yet the drone endured some crashes, can that cause a shift in accelerometer data?
I hope someone can help!

Greetings
Max

Do you have a bias after restarting the CF and letting it sit on the floor as well?

No when looking into the cfclient, and plotting the variables you see in the plots. There is no bias when not moving and resting on the floor. Thus this might imply that the accelerometer is doing its job but the INDI code is causing it?

The controller is out of my knowledge but I know something about the accelerometer though. We do not do any calibration of it other then what is done in the factory and we assume it is sitting pretty flat, which I'm pretty sure is the case.

• The Alignment error in the data sheet says typical: 0.5 deg
• Zero-g offset 20mg
• Zero-g offset temp drift: <0.2mg/K
• Nonlinearity: 0.5 %FS
• Cross axis sensitivity: 0.5%.

So if it is 0.4g off there is most likely a bug somewhere or a hardware problem with the IMU. Crashes should not cause a drift in the accelerometer data so most likely not this. If it is integrated though a crash might saturate it but this not the case here right?

No it is not integrated, and after a crash I always restart the drone. Will update with a post when I find the cause.

Thanks!

Hey,

I am not sure, if this is really helpful but: Keep in mind, that looking onto the acceleration in the ned/lab frame the attitude error is coupled into the translational states.
When sitting on the ground (or not moving, hovering) the accelerometer measures 1 g of acceleration in z direction which has to be accounted for in the navigation - and this is definitely accounted for in the firmware. At least this is in the order of magnitude of your phenomenon. If the attitude is for some reason affected (e.g. not aligning the CF with the global/Lab x-axis when using an LPS) this could lead to wired couplings. However, it appears to be unlikely how the body-axis z-component could appear so "strong" in the horizontal global states.

Good luck!

tobias wrote: ↑Tue May 11, 2021 8:03 am The controller is out of my knowledge but I know something about the accelerometer though. We do not do any calibration of it other then what is done in the factory and we assume it is sitting pretty flat, which I'm pretty sure is the case.

• The Alignment error in the data sheet says typical: 0.5 deg
• Zero-g offset 20mg
• Zero-g offset temp drift: <0.2mg/K
• Nonlinearity: 0.5 %FS
• Cross axis sensitivity: 0.5%.

So if it is 0.4g off there is most likely a bug somewhere or a hardware problem with the IMU. Crashes should not cause a drift in the accelerometer data so most likely not this. If it is integrated though a crash might saturate it but this not the case here right?

Hello, you said you do not do any calibration for IMU, and does that mean indeed there is some bias in accelerometer and gyroscope? "Zero-g offset 20mg" means the range of the offset is around [-0.1962, 0.1962] m/s^2(20*10^-3*9.81 = 0.1962 m/s^2)?

Does the your ekf estimator can estimate the bias and eliminate it?

Today the bias for the gyro and accelerometer is taken during startup.

As far as I know the EKF is tracking the gyro bias but not the acc.