-
Notifications
You must be signed in to change notification settings - Fork 173
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
fix: Prefer external surface candidates in Navigation #3989
base: main
Are you sure you want to change the base?
fix: Prefer external surface candidates in Navigation #3989
Conversation
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
@benjaminhuth what we briefly discussed |
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.
Looks good!
To me this feels like a thing we should actually make a unittest for, e.g., some telescope geometry which has plane surfaces closer than surfaceTolerance
, where we put one as external into the sequence... But this is tedious of course...
I agree this should be unit tested. Sadly none of this external surface stuff is unit tested and it is very tedious to set it up and verify to do the correct thing. I wondered if this will show up in a physmon diff as we might run into this problem with the ODD already. This change is rather low on my priority list and conflicts with #3449 which is much more important IMO. So I would delay putting this in in any case. |
External surfaces get infinite bounds during navigation and should always be preferred over any other surface in the geometry. This is not the case right now as a surface which is flagged as external might live on the same plane as a standard surface and we might still end up targeting the standard one first.
In this PR I propose to sort surfaces not only by path length but also by the fact if they are external or not. This will prioritize external surfaces over standard ones.
This is important during refitting with for example the KF. In case the estimated trajectory aims for a neighboring surface we would observe holes instead of the actual measurements.