-
Notifications
You must be signed in to change notification settings - Fork 20.2k
AP_NavEKF: report active EKF source sets and lanes #31154
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
base: master
Are you sure you want to change the base?
Conversation
1-based numbering to be consistent with MAV_CMD_SET_EKF_SOURCE_SET and parameters. Non-EKF AHRS report dummy values since they also emit EKF_STATUS_REPORT.
|
You can't assume extensions are passed as anything but zero, so using 1-based indexing is good. |
|
I've just realised that this is somewhat in opposition to an alternate proposal I had many years ago allowing for each EKF lane (and, indeed, each estimator on the system) to emit I don't think that should block this PR, but is information. |
|
@peterbarker I kind of assumed it was already the case before I even started on this 😓 I think the approaches aren't mutually exclusive, if you want all the lanes to emit a packet you still want to tell the lanes apart. Sounds like an idea for iterating on this, but as to other estimators I am not sure. The packet already is EKF inspired so we pass a bunch of zeroes for DCM and external nav for example. Maybe it can be reworked a bit? (In future ofc) |
d254dea to
707d6cd
Compare
|
As per devcall, added an estimator type enum as well as a few tweaks. I realized that DCM actually does not send
Please review and tell if this is fine (or should we maybe include DCM? to know that the system has degraded from EKF3 to DCM for example). I also reordered the attributes a bit so that we can safely send zeroes for cores/souce sets EAHRS (if it has cores/source sets it shouldn't not be our concern and we probably don't have that info) and for the source sets for EKF2 which didn't have them back then. |
Reordered fields in the mavlink message allows not to pass inapplicable data, e.g. an external AHRS by definition has neither lanes nor source sets.
707d6cd to
cc238b1
Compare
Adds the indication of currently active EKF source set (and core/lane for good measure). 1-based indices because it's how the source switch message was coded. I'm not entirely sure about whether to keep it or to change the switch message to 0-based scheme, both have pros and cons, can do as the reviewer decides.
mavlink PR: ArduPilot/mavlink#428
Works for me in SITL. Marking as WIP to get comments about the index domain.
CC @peterbarker