-
Notifications
You must be signed in to change notification settings - Fork 540
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
Relocation after 'kidnap'? #73
Comments
No, it's a keyframe odometry, not a SLAM system. IMU might allow it to track for a short while without usable camera input though. |
Thank you! Understood. I might try to add this function in. Would you have any pointers on where to start? Also, does this mean that the application doesn't store a local map? It is literally just frame-to-frame? |
I suggest to read and understand the related publications. IMHO it is not obvious how to extend the marginalization sliding window to include old keyframes after loop closure or relocalization. What might work is having a two-layer system. The current sliding window as a front-end odometry and then after that a mapping module with relocalization, loop closure detection, pose graph optimization and possibly bundle adjustment (similar to orbslam, possibly with stereo and IMU error terms in the BA). However, the mapping module would never directly influence the frontend odometry, but instead only update it's "reference frame". Overall it seems like a quite involved project to me. |
Does okvis handle relocation if tracking is lost? For example, if the sensor is blocked and moved, when it is unblocked, will it localize correctly in the map? (if it is still in the pre mapped region, obviously).
Thanks!
The text was updated successfully, but these errors were encountered: