-
Notifications
You must be signed in to change notification settings - Fork 78
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
Support initial_pose in openvslam node #11
Comments
Further analysis is in progress. Any ideas about it are welcoming! |
I think it would be better to find a keyframe (or keyframes) closest to initial_pose and run https://github.com/OpenVSLAM-Community/openvslam/blob/00cdcc6d5c979c0ebd461f59974b4aa43e3c1a2b/src/openvslam/module/relocalizer.cc#L40-L147 with the keyframe as a candidate. If you simply rewrite the current position, I don't think it will be stable. |
Thanks for the idea! Honestly, since all 3 tracking approaches are tied to current and previous frame, just changing the camera position might be unstable. So, re-localization at key-frame position should be better solution. However, what should we do, if we have no keyframe nearby (e.g. in radius of preset threshold): still move robot to nearest keyframe seems not to be a good idea, if, say, it is located at a distance of 2 meters from the requested position. Probably is it better in this case to add a new frame with an |
How does the pure localization mode handle starting up (does it take in an initial pose estimate to seed the initial matching?) Why not just in the |
There seems to be a misunderstanding: relocalizer computes the relative position from the keyframe to the current frame by solving a PnP problem. Without being able to solve the PnP problem, OpenVSLAM cannot start tracking. |
OpenVSLAM performs the search from all of the keyframes (by bag of visual words). When it finds a similar scene, it computes the relative position from that keyframe. |
That seems to be problematic that we can't give it an initial pose seed to use instead of purely global localization. Especially in dynamic worlds where objects move from the original map, being able to seed in repetitive spaces is necessary for a robust enough solution to rely on. Else, you're kind of "sorry out of luck" if it doesn't match correctly on the first pose which the user could potentially provide information about for a general area. So there seems to be 2 issues:
Is there a way to support this feature? Issue 2 on that list seems like the more pertinent problem, if that's solved, the first one could make use of the same solution. |
It is possible with multi-session Visual SLAM; you can add a keyframe to initial_pose and SLAM from there. OpenVSLAM does not support multi-session at now. rtabmap and ORB_SLAM2 include functions for multi-session/multi-map. |
We're just talking about the pure localization mode right now, not really interested in multi-session continue mapping. Do you disagree that it would be useful (and probably necessary to use openVSLAM localization in production) to have a way to set the initial pose on startup of pure localization to seed the match? I'm not saying add a keyframe there, just to look at that point and the region around it rather than searching the entire map for the initial pose match -- if an initial pose estimate is given |
If that's the case, I think what I wrote in #11 (comment) is sufficient. What other information do you want? |
Added work-in-progress PR to |
This ticket is about adding the support of initial_pose (
geometry_msgs::msg::PoseWithCovarianceStamped
) topic containing robot/camera pose to set. The algorithm should set the robot pose in localization mode immediately to the pose taken from input message. This is the "golden standard" for other SLAM-s, like AMCL or SLAM_Toolbox, so OpenVSLAM node should also support this, I suppose.This should be supported on openvslam_ros side as initial_pose topic subscriber plus
base_link->camera_link
TF converter. Additionally, setting a forced pose should be supported on openvslam side too. Thesystem
class hastracker_
tracking module which contains current frame (curr_frm_
). This frame has the pose, as preliminary analysis shown which is used bytracking_module::track_current_frame()
to set the camera(robot) position. The change of thecurr_frm_
to required position should forcibly move the robot to that pose.The text was updated successfully, but these errors were encountered: