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.
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 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.
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.
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?
I am having the same issue as posted under this link with a cube black running 4.0.5 . I thought is was a problem running blended CAN configured Here 2 gps/compasses but I continue to get prearm IMU mismatch errors for about 3-4 minutes then if I reboot I get a clean prearm immediately with no mismatch. The problem only occurs on cold boot once it warms up for about 3-4 minutes I have no problems. This is very consistent. I tried the above method and disabled IMU2 and then rebooted cold and the problem does not exists. It booted up and immediately I got a clean prearm. Any help with this is greatly appreciated.