-
Notifications
You must be signed in to change notification settings - Fork 18.7k
EKF3 velocity divergence pre-arm #29384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Replay of the log with EK3_MAG_CAL=4 (always use 3-axis fusion) eliminates the instability so I am now investigating the yaw fusion process. |
I don't know if this is related, but I had a strange rollover on auto takeoff on a Fixed Wing yesterday. One thing I noticed is that it was pointing almost directly North just before the takeoff. This was on a very recent master. This is the previous flight with the same plane. The only change was a new battery: Sorry if this is not related. |
if using GPS and our horizontal velocity innovation is high then mark the filter as unhealthy, which causes an arming failure this helps with ArduPilot#29384
if using GPS and our horizontal velocity innovation is high then mark the filter as unhealthy, which causes an arming failure this helps with ArduPilot#29384
if using GPS and our horizontal velocity innovation is high then mark the filter as unhealthy, which causes an arming failure this helps with ArduPilot#29384
if using GPS and our horizontal velocity innovation is high then mark the filter as unhealthy, which causes an arming failure this helps with #29384
if using GPS and our horizontal velocity innovation is high then mark the filter as unhealthy, which causes an arming failure this helps with ArduPilot#29384
Uh oh!
There was an error while loading. Please reload this page.
We had a divergence of EKF3 velocity pre-arming on the ground which caused a roll over on takeoff of a quadplane.
GPS velocity looks fine, EKF3 velocity is very bad. Normalised innovations were low.
Replay log here:
http://uav.tridgell.net/tmp/00000082.BIN
replays nicely, no log packet loss
firmware is 4.6.0-beta4, but master replay shows the same issue.
old versions tested:
you can use replay with EKF2 on this log with this PR:
#29405
and --force-ekf2
Using EKF2 the velocity does not diverge, so this looks to be an EKF3 only issue, and one that has been in EKF3 for a very long time
Apart from the divergence, the other worrying part of this log is that the scaled innovations presented to the EKF failsafe code and to the user over MAVLink do not show any health issues with the EKF. Same goes for the lane switching error scores. So no fail-safes, no GCS warnings, no arming check failures.
Other notes:
update:
The text was updated successfully, but these errors were encountered: