I just got same yaw inconsistency on a plane build I am making. I think due to controller 180 deg rotation and compass 225 deg rotation on a final build. On a bench with 0 rotation on both it did not show that error. So, switch to ekf3 is a workaround for now?
It says inconsistent by 172 deg. IMU and compass are all calibrated.
Yes, ekf3 was discussed in this topic in march I believe. Does it always say inconsistent by 172 deg, or just random numbers randomly? Because if it is always similar you might have a different issue. I would check your board and compass rotation parameters.
so, what i found so far is this - because i work on the plane, i fitted in the air sensor. air sensor produces ‘noise’ - it constantly deviates from 0 to 2.7 m/s and back. if ‘use’ for the sensor is set to 1 - it assumes AS data as the GS - ground speed, and that means during board startup and init it makes it think the model is in motion. model then goes into the long failsafe that switches code into the RTL mode. that seems to be invoking an imaginary WP vector - in the MP screen it shows as an orange line - i presume that it actually points to the north, and the actual yaw - correct yaw deviates from that WP vector. the ‘inconsistency’ message shows an exact value of the angle between the actual yaw and that vector.
solution was not to set modes in the way that RTL or any auto mode ever invokes during power-up with no controller attached, and, for now, use of the airspeed sensor is disabled - so it shows its values but not setting them for the ground speed - so code does not presume anymore the model is in motion during the initialization. that is my current assumption that may not be totally correct, i will try to look more into it.
switch to EKF3 did not fix any of that - behavior was precisely the same.
Paul I am curious. I have my controller rotated 180 deg. Like I mentioned above mine always works perfectly on startup but after a 2-3min flight once I land I get an “inconsistent error” of 22-28deg consistently (and cannot takeoff again unless I wait 2min or reboot). While it makes no sense this would be related to controller rotation I am tempted to try flipping my controller around (which isn’t easy…). Or do you think yours may have seemed to work at a 0deg setup just because your other sensors or what not were being plugged in? Did you actually trying flying with a 0deg setup?
Does anyone else get this error when they use a setup where the controller and GPS are all facing forward (0deg)?
i am not positive yet if it has anything o do with any hardware.
the situation i see is the EKF deviation from the WP vector ‘Direct to current WP’ that points to some imaginary bogus. the response value in the ‘inconsistent error’ - the value is the EXACT difference from that WP vector and the factual yaw.
my issue may not be same as your issue but they seem to be similar. do you see after the landing - do you go into the long failsafe?
Not sure what you mean by long failsafe?
I take it back. i am unable to replicate what i did last night. i get message every time now - as can be seen on the screen. i presumed it was related to the invoked RTL mode. it is not happening anymore, but deviation still shows. orange line still shows. if i rotate the model to align those 2 lines - it goes away. i do not know what that is and why anymore - but i did not try to make it into locking the gps correctly. this happens now with no gps lock.
As a temporary work around it may be useful to disable all compasses except for the primary one.
COMPASS_USE2 = 0
COMPASS_USE3 = 0
I have tried disabling the internal compasses in the past like you described but this does not seem to have any effect.
I believe the issue has to do with deviation between the Gyro and Compasses (not deviation between the compasses). Does anyone know the answer to this question?
If it is gyro drift, it is often related to the temperature of the IMU package. Some IMU’s are more sensitive than others to temperature variation. Can you preform a “PREFLIGHT_CALIBRATION” using the Mission Planner actions menu the next time the error occurs? This will re-calibrate the gyros to zero, just as happens during the boot process.
If the IMUs are unusually temperature sensitive there are a few options. One would be to replace the flight controller for another one that is not as sensitive. Another option, if the flight controller has an IMU heater like a Cube flight controller, you can preheat the IMU package by powering on a few minutes before flight. Then preform the preflight_calibration action or a reboot once it has reached operating temperature. If it does not have a heater you could try adding some amount of insulation to the flight controller compartment to reduce the temperature changes during flight caused by the airflow.
If you can provide a dataflash log of the event with log_disarmed enabled that could help identify the problem.
I too though it may have to do with Gyro temp so I tried to do some tests insulating the flight controller (and then removing the insulation). There seems to be no correlation between IMU temp consistency and to the issue unfortunately.
It seems that longer and faster I fly, the greater the “-” variance value is about 60 sec after I land.
The graph below depicts the variance issue. What does NKF8 IYAW actually mean though? Does this have to do with different compass variations? Does it have to do with gyro variations?
The warning is given when the variance the value seems to go over -/+20deg.
Here is the log: https://www.dropbox.com/s/069qx245i3y4qbz/log_15_2020-5-9-18-27-18.bin?dl=1
Looking at the log those gyros look healthy and temperature does not appear to be a factor. However the NKF8.GSZ (z-axis gyro scale factor of the second EKF2 instance) does have some rather large values. The second compass has some unusual drift in readings of the Z axis compared to the others as well.
NKF8.IYAW is vehicle yaw innovations in the second EKF2 instance. My understanding of the EKF is pretty surface level but I believe these values are essentially the size of the error in the EKF prediction that is fed back in as a correction. The ArduPlane wiki has a good list of dataflash message meanings. Many apply to copter like the EKF information. https://ardupilot.org/plane/docs/logmessages.html For messages about the EKF2 instances NKF1-4 is for the first instance, NKF6-9 are for the second instance.
We had the problem too, as mentioned before, after switching the cube on two drones, the problem did not occur anymore after many testflights.
After spending way to much time on this I finally figured it out. CM, like you point out, the issue in my case is Gyro drift on the Z-axis on IMU1. It’s a subtle drift at about 0.5/sec after I land but this is enough to create an EKF2 warning. Over 60 sec of time this cause 20+ deg of drift deviation. Anyways a work around for me to set EK2_IMU_MASK so that I use IMU 0 and IMU 2 (instead of IMU 0 and 1) and all my warnings are gone. I tried flying on IMU1 alone and it still works (although it’s noisy), but it just drifts to much to use in EK2.
Thanks for all the help!
Hi there, sorry to be absent for so long on this issue.
We’re preparing to release Copter-4.0.4-rc1 for beta testing this week and I’d like to ensure we get the right fix (if necessary) included.
The basic check is that the two EKF cores and DCM are all reporting the same attitude. I think we have a couple of different failures reported above:
So if you’re seeing these types of errors:
@Bobmarr kindly provided logs above. I’ve had a look and in the 11.BIN log it looks like DCM is off, in the 12.BIN log it appears the 2nd EKF lane is off. I’ll discuss this with Tridge and others.
If it helps, here is a logfile from a flight today, after calibration, with the same problem:
Hello everyone.
I have this problem ek2 yaw inconsistent by (x) degres (always different degrees), but in my case it is in Arduplane, with PH4 and PH4 Mini, I am using the latest version of firware, but loading previous versions the problem persists, problems that for true before they did not exist.
I’ve been reading this for days and trying all the multirotor solutions on my plane and nothing works. At the beginning of the year I had this problem in multirotors and I wrote to Holybro to find a solution, they told me to load the firmware manually, but it was not solved, suddenly one day the problem ceased to exist and I have never had it in multirotor again. . But this problem continues in Plane now. Someone can think of why this happens, in my case before in multi and just not now but in plane?
In PX4 firmware doesn’t have this problem.
Kind regards to all
Did you re-calibrate the magnetometer? Outside in an open field away from metal structures and with a GPS Fix?
no, but reading all about this, it looks its an IMU problem not the compass, Am i right or not?
