Hello, I I just discovered something with this problem of ek2 yaw inconsistent, if the controller points north the problem does not appear,and I can arm, and the degrees of inconsistency are the degrees expressed in the compass, that’s why I always see a different number.
I do not know if this has been discussed in this post. So if I arm the plane whit 0 degres top the north there is not problem, looks like its going to be ok, but if disarm and try to arm in an other way whit no 0 degrees the mesage appears .
so is the solution arm pionting to the north? or going to have problems flying?
1 Like
I think I’m a little late in this post, but I’m experiencing pre-arm errors “EKF2 Yaw inconsistent” identical to those described in this post. I’m running AC 4.0.3 in a CubeBlack, I attach logs and graphs of the errors, if still useful.
Could someone tell me if there is already a solution to this problem or if this is already fixed in AC 4.0.4-rc1??
Thx!!
1 Like
Yesterday I installed version 4.0.4-rc1 on this drone and I made some bench tests on it. This problem regarding the “EKF2 Yaw inconsistent” persists. I attach logs and graphs of the new errors in 4.0.4-rc1.
@rmackay9 Have there been any fixes to this problem in 4.0.4-rc1 as you said earlier in this post?
On the other hand, I’ve been looking into the logs a little more thoroughly to see if I can get anything more out of them. The first thing 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.
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.
Any idea how we can solve this problem?
I leave here a link to all the LOGs and captures I have used in these tests: https://drive.google.com/drive/folders/19fSzhGjTsZ9sElJWpx0gpcZLffO5pWCq?usp=sharing
Maybe we need IMU temperature compensation. Someone posted about it in a similar IMU drifting thread yesterday.
https://docs.px4.io/v1.9.0/en/advanced_config/sensor_thermal_calibration.html
This would be interesting if it was added to the AP code. We have environmental chambers we use for temp comp of load sensors I could possible get some time on. Huge backlog now though as we just opened that facility back up. And a Kakute F7 and Omni Nano F4 on the bench doing nothing for test.
I have a freezer and heater and plastic bag w/ silica gel :). That should still get the task completed.
I don’t think we could share calibrations. If temperature is causing the issues I’m seeing, each IMU has its own range of being affected by temperature. Because for my leaning issue, basically, some omnibus nanos are much worse than others. Some of my copters get this Yaw Inconsistent message every time I power up, while others are rare, on basically identical vehicles.
Yes, my experience also. I thought I damaged my Omni Nano F4 from a crash and bought another one only to find the same drift problem. And it was worse.
Yes, a feature like that will be very useful in AP to deal with this type of situations. I know that this type of beta-flight boards (Kakute, Omnibus, etc) didn’t perform well in terms of sensor stability, but for the price they do their job very well in most cases.
But now talking about a controller like a CubeBlack. You think this problem is purely hardware related? Is there anything that can be done right now to compensate or calibrate this bias?
I’ve used a multitude of CubeBlack flight controllers and I’ve never come across a case with so many gyro inconsistent errors……
Other than adjusting bias learning, EK2(3)_A(G)BIAS_P_NSE, I don’t think we have other parameters to adjust. And I’m not sure those really help. It does change the rate the bias grows in the logs, but the symptoms I was having didn’t improve.
One thing I’ve always wondered is if the more expensive FC manufacturers test each IMU and throw out (or resell) the ones that are out of spec. If so, and yours is not performing well, maybe they will RMA it. It’s probably worth asking, if you know this one is definitely performing worse than other CubeBlack’s.
From my experience with the cheap boards, it seems to be hardware. They all function at the basic level of reporting angles and velocities. But some constantly build the bias quickly while others don’t. Some lean badly and others don’t. This is testing the same brand FC on the same vehicle, so not many other variables.
1 Like
IMO even CubeBlack has horrible drift, especially on second IMU. Consistently on multiple units.
You can’t do much about it.
I’m eagerly waiting for fmu v5x and v6x which should have more accurately temperature compensated IMU’s.
Yes, most of the units I’ve tried work well in that respect, but right now I have two units that, exactly as you say, accumulate a large offset in the gyro of the IMU2 caused by the changing temperature. I have also realized from researching this problem that temperature control is not very accurate and at least in my case it takes a long time to stabilize despite my efforts to minimize it.
For now with these units what I do is wait for the temperature to stabilize enough and then I force a GyroCal from MP.
What exactly would be the advantages you are talking about with the more accurately temperature compensated IMU’s with fmu v5x and v6x?? Anywhere to read about it?
Just a random thought:
Has anyone tried to calibrate the gyros after temp has stabilized and then disabled INS_GYR_CAL parameter to use the pre-calibrated values each time?
Theoretically it might give you errors on boot until the IMU heats up, but afterwards it should (could) be fine.
I exchanged my 3DR Pixhawk1 with the 1Mbit flash limit bug to a very cheap Ebay device from Happymodel.cn.
The issue is gone.
From what I’ve seen w/ this and a few other issues, it does seem to be related to specific IMU’s.
So, I guess the question is can anything be done about supporting IMU’s with slight issues like this? Which in my experience is most of them…
Someone was going to test px4 with the IMU temperature compensation on his copter w/ some of these issues… I’ll have to send him a PM to see if he got any results.
Hi I updated firmware last week have EKF yaw message…can provide log if still needed…
Forgive my ignorance, does gyro recalibration = Accel Calibration or compass calibration or both?
How do you force a gyro cal in MP?
In MP go to the actions tab located under the HUD, in the first drop down select “Preflight_calibration” and then hit the do action button. That does the trick.
I hope this helps you 
1 Like
I am getting the “EK2 Yaw Inconsistent” message on my Black Cube. It only happens when I use the drone for the first time in the day and it does not happen after I continue using it. It is weird because I am running the same Black Cube in another exact copter and I have never got this message. I see it has something to do with the gyros and I see if you force a gyro calibration it goes away (I have tried it running MP thru the usb connection and that does work), but I am using the Herelink and I cannot find in QGroundControl where I can force a gyro calibration. Anyone have a suggestion? I am also running 4.0.4RC2 as well.
Thank you.
Hi,
The issue of EKF2 yaw inconsistent did not exist in PX4 based firmware (I have tested Copter v3.5.5) on the same piece of hardware. If gyro(s) is drifting, does it mean that this prearm check was not existing in PX4 based firmware?