-
Notifications
You must be signed in to change notification settings - Fork 17k
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
EKF: don't reset EKx_GPS_TYPE when GPS has no vertical velocity #15815
Conversation
8392942
to
c3cdf6d
Compare
I'd really like it if we could hold off on EKF3 fixes until my PR has gone in: #14803 |
yep, no problem |
c3cdf6d
to
dfc32dd
Compare
Great to see this. We should be able to completely remove the AP_NavEKF_Source::setVelZSource() call as part of this PR (or as a follow-up). I only added this call because it was needed and I'd rather it didn't exist. I see you didn't use the method of adding an extra boolean to the buffer and then use this to decide whether to fuse or not. I started looking at this a bit yesterday and I also found that there were multiple places where other logic was depending upon whether we had vertical velocities or not so maybe you've decided that going directly to the GPS is the most consistent way. |
a068f58
to
8ad74dc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a log showing how it handles a change in gps.have_vertical_velocity() when the EKF is already using GPS?
no, but I can create one in SITL. I'll add a flag to our NMEA GPS driver to enable/disable GPS vertical velocity |
No pressure but I'm still keen on seeing this one go in.. |
setting the parameter to 1 causes the following issues: - the GPS may not have vertical velocity at the time the parameter set happens, but may get it later when the GPS is fully configured - we may switch between GPS modules which do/don't have vertical velocity - the user may download parameters after the set(1), and end up with incorrect parameters they may later load onto the vehicle, permanently disabling use of vertical velocity
setting the parameter to 1 causes the following issues: - the GPS may not have vertical velocity at the time the parameter set happens, but may get it later when the GPS is fully configured - we may switch between GPS modules which do/don't have vertical velocity - the user may download parameters after the set(1), and end up with incorrect parameters they may later load onto the vehicle, permanently disabling use of vertical velocity
these were unused
these were unused
these were unused
these were unused
these were unused
this adds vertical velocity support
this ensures that we record GPS vertical velocity status for every sample correctly
8ad74dc
to
5217264
Compare
@priseborough and @rmackay9 I've now added the have_vz flag to the GPS buffer data so we get this right on a per sample basis |
Is this commit included by mistake? It seems mostly unrelated to the rest of the PR.
|
setting the parameter to 1 causes the following issues:
I've now extended this PR to also remove the inhibitGPS and inhibitGpsvertVelUse options which were completely unused and just complicated the code. With the EK3 sources PR now merged the recommended way to change the use of GPS is via the sources system.
Log flying this code is here:
http://uav.tridgell.net/DartXL/2020-11-22/00000024.BIN