Conversation
|
Pre-commit errors fixed in: |
Cool! But... this is entirely independent from this PR, right? (Fixing typos in files this doesn't touch.) @cclauss tagging you just in case there's a typo in a PR number or something. 🤷 |
No worries for minor turbulence. Hurray for automation! Should the instructions mention pre-commit? If they do, I missed them. If not, no worries, I imagine that will come in time. |
Suggestions made in PR form 😄 |
| If affinity for that sensor-type is disabled, each lane uses the system's "primary" instance of the sensor. | ||
| (Affinity being disabled for every sensor-type is the conventional/default choice.) | ||
| The initial primary sensor instance is selected by a user-modifiable parameter. | ||
| The system may change which sensor instance is its primary, even in-flight, for example in case of a sensor fault. |
There was a problem hiding this comment.
This line is a bit confusing in this context. Yes, the lane can possibly change its primary sensor for some sensors mid-flight, for example, a compass. But I don't think that's true for all sensors.. for example a barometer
There was a problem hiding this comment.
I had details like this in mind with the note-box "This page [...] is not perfect on the details."
Do you think it's worth describing and then maintaining all the details on this page? If yes, additional commit(s) to fix them & remove the "this page is not perfect on the details" are welcome.
On the flip side: Do you think the page is better as it was before? That path forward also makes sense: Reject this PR and keep the content as it was.
| The system may change which sensor instance is its primary, even in-flight, for example in case of a sensor fault. | ||
|
|
||
| Because modern-day vehicles may have redundant good quality sensors installed, "affinity" provides a way to have some EKF lanes prefer sensor instances which are not the system-wide primary. | ||
| For sensors with affinity enabled, lane-switching should be thought of as sensor-switching. |
There was a problem hiding this comment.
I think this is over-simplification. It's possible that not all IMUs present in a flight controller perform equally well. Which means lane-switching with affinity enabled isn't just "sensor-switching". If a user hasn't tested all lanes (or at least checked logs for all lanes), they might switch to a worse lane.
There was a problem hiding this comment.
I agree it is a simplification. (I hoped "should be thought of" would communicate that... maybe it did?)
Over-simplification suggests it might be worse than some alternative... help me understand what you have in mind?
Also, I think there's no gap in my understanding of the topic, it's merely a discussion about what wording is appropriate. This PR is my attempt to find the right balance, but I'm glad to take it in the direction(s) you'd like!
Do you know github's "Suggest Changes" feature? That would be a great way to specifically communicate what differences you'd like to see, and my "Accept Suggestion" would confirm my agreement/understanding.
| Because modern-day vehicles may have redundant good quality sensors installed, "affinity" provides a way to have some EKF lanes prefer sensor instances which are not the system-wide primary. | ||
| For sensors with affinity enabled, lane-switching should be thought of as sensor-switching. | ||
| The lane error score (used to make a switching decision) takes into account innovations from all sensors used by a lane. | ||
| Thus in the case of noisy-but-not-broken non-IMU sensors, affinity might avoid a mishap by simply EKF lane-switching to a less-noisy IMU+sensor combination. |
There was a problem hiding this comment.
The language here is a bit confusing.
There was a problem hiding this comment.
I'm guessing you're flagging the over-hypenation 😄. Yeah, I didn't have good user-facing language for "misbehaving but not faulted". Suggestions?
I also tried to stay close to the original sentence (language like "avoid a mishap by lane-switching") which might contribute to the confusion. That was primarily motivated by a desire to make a minimum-necessary change, I'm happy with broader rewording if you are.
|
Please rebase to pick up the typo fixes. |
hunt0r
force-pushed
the
clarify-ekf3-affinity
branch
from
543c994 to
61a4457
Compare
3 participants
EKF3 affinity is difficult to understand from our wiki docs. This (hopefully!) improves it's clarity.
Reviewers: I determined this from source-diving. Please carefully examine this PR's content for mistakes.
Summary of significant points:
The first commit switches to one-sentence-per-line. I find this style much easier for future reviews/changes. (I did not fix the whole file. That has the downside of leaving us with mixed style in a single file. IMO, any movement towards one-sentence-per-line is improvement.) I will revert this to preserve the "one paragraph per line" style if any reviewer objects.
The second commit fixes some trailing whitespace. I'll drop it if any reviewer objects.
Testing:
Built locally, renders as expected.