Pre-arm errors “EKF2 Yaw inconsistent” & "Gyros inconsisten”

Cube Autopilot
#1

I’m experiencing pre-arm errors “EKF2 Yaw inconsistent” and in some instances also “Gyros inconsisten”. I’m running AC 4.0.3 and 4.0.4-rc1 in a CubeBlack for these tests.

I have posted the problem first on the ardupilot forum, but I will also post it here because I think it may be a specific CubeBlack problem. #51701

If I plot AHR2.Yaw, NKF1.Yaw and NKF6.Yaw, I can see that over time NKF6.Yaw begins to differ causing these pre-arm messages.

YAW 4
YAW 41241×451 35.7 KB
YAW 5
YAW 51241×456 19.6 KB

I’ve been looking into the logs a little and I noticed is that the reading of IMU.GyrZ from the IMU number 2 of the CubeBlack begin to drift slightly, reaching a maximum difference of 0.1 with respect to the IMU 1 and 2 in a period of about 9 minutes. Then I tried disabling IMU number 2, recalibrating the gyros and doing more tests. In these new tests with only the IMU number 1 and 3, the problem is completely solved and the output of the EKF no longer differs. The pre-arm messages no longer appear.

Later I realized that this deviation from the IMU2.GyrZ reading correlates perfectly with the change in temperature of the IMU while it is heating up. Furthermore, in some cases the temperature does not remain constant when it reaches the target temperature of 45ºC and continues to increase slightly over time.

IMUGyrZ and Temp 4
IMUGyrZ and Temp 41708×542 129 KB
IMUGyrZ and Temp 5
IMUGyrZ and Temp 51705×546 81.5 KB

Any idea how to solve the problem? Could it be a hardware problem only?

I leave here a link to all the LOGs and captures I have used in these tests: https://drive.google.com/drive/folders/12JvCLcb2hqlQimb0XHczLAsdjT-5_tzB?usp=sharing

#2

Is that problem also exist after reboot of Cube when the IMUs have higher temperature ?

#3

Yes, for example, the last capture I put corresponds to a log in which the IMU was already heated since it had just been rebooted.

#4

I have finally concluded that it is a hardware defect specific to this board. I had hoped that it could be a configuration or software problem but it is not. This board simply performs much worse in this regard than the rest of the CubeBlacks I have owned.

I will try to RMA it if possible for this reason…

#5

I had a yaw error on a large octocopter that only happened if I used LiIon batteries. A LiPo battery worked fine. I am assuming that one of the metal cases of the batteries had been inadvertently magnetized.

#6

It is known that li-ion batteries cause significant magnetic problems compared to li-po, due to the composition and internal structure of the packs. Just the fact of rotating the battery 90º inside its housing in the drone, can cause great mangenetic variations that generate problems and require a re-calibration of the compasses. I personally have been using li-ion batteries for a long time and if you take into account these factors during the design of the equipment they are no problem to use.

But in summary, these problems that can be generated by this type of batteries are magnetic problems that affect the compasses therefore affecting yaw calculations. But this case has nothing to do with that since the problems I have are related to the gyroscope readings which are accumulating a large ofsets with temperature changes.

#7

Hi there. Just checking if there has been any progress with this issue. I have 3 Cubeblacks all having this exact problem. And it’s not a good look to have customers plug-in power to preheat and then have to power cycle before the flight. Its easily forgotten and prevents rearming after landing. Can the second IMU be safely disabled?

2 Likes