Autoresearch on relocalization#2137
Draft
leshy wants to merge 79 commits into
Draft
Conversation
More candidates to choose from; 4x per-frame budget headroom on 60-frame eval.
Finer descriptors → new candidate diversity. Previously timed out at 60s/frame budget; now we have 240s/frame on 48 cores.
60 frames over ~48 cores leaves huge per-frame headroom even at 90s wall budget.
0.15m hit 171s — too slow for 90s budget. Back to [0.2, 0.3, 0.5, 0.8] with 7 restarts.
Map coverage near trajectory start is too sparse for meaningful evaluation — all algorithms fail on these. 58 frames remaining.
Down-weights inliers beyond k=RERANK_DIST. Misaligned wall fragments contribute less; aligned ones drive the solution more.
0.8m is coarse anchor scale; needs fewer restarts than the finer scales where most candidate diversity lives.
❌ 2 Tests Failed:
View the top 2 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First pass but pretty good, sub 1s alignment on a CPU from 5s of lidar data
Next steps
better data - needs lidar frames collected from multiple independant loop closed runs. We can use this same relocalzation to align them, or use fiduciary markers for ground truth. With multiple recordings we can validate relocalization with unique never seen lidar frames into a global map.
Global mapper will try to align what it can see to a loaded map. When do we know we are ready to import loaded map into current ground truth? we need match confidence measure
better confidence measure autoresearch - we need a match confidence measure that corresponds to ground truth match quality - this way we can keep ever expanding local map, until we find a way to insert it into a lodaded global map
How does amount of lidar points affect our alignment quality / exec time?
graph runtime or numbers of points collected vs alignment quality
autoresearch on a better dataset that includes different pc sizes
Continuous alignment
We could still incorrectly align local map into a loaded global map - can we keep those permanently separate? always search for a better match? Can mapper change it's mind about where the loaded map should sit? How do we deal with env updates in that case?