Skip to content

Conversation

@landswellsong
Copy link
Contributor

@landswellsong landswellsong commented Sep 24, 2025

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

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.
@peterbarker
Copy link
Contributor

You can't assume extensions are passed as anything but zero, so using 1-based indexing is good.

@peterbarker
Copy link
Contributor

peterbarker commented Sep 27, 2025

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 EKF_STATUS_REPORT.

I don't think that should block this PR, but is information.

@landswellsong
Copy link
Contributor Author

@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)

@landswellsong
Copy link
Contributor Author

As per devcall, added an estimator type enum as well as a few tweaks. I realized that DCM actually does not send EKF_STATUS_REPORT (which is reasonable), but it's SIM and EAHRS that do (which is less so). I therefore have set up the enum in such a way:

  • 0 ⇒ External AHRS
  • n ⇒ NavEKFn
  • 255 ⇒ SIM

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.

@landswellsong landswellsong changed the title [WIP] AP_NavEKF: report active EKF source sets and lanes AP_NavEKF: report active EKF source sets and lanes Sep 30, 2025
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants