-
Notifications
You must be signed in to change notification settings - Fork 124
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
Intended logic in updateKeyframes() #8
Comments
Ah -- the entire "check for nearby keyframes" statement should not be there. There were originally some additional checks in that block from our new DLIOM algorithm that I removed when open-sourcing this code (e.g., slippage), but I should have just removed that entire block. I'll push a new update in a bit. Thanks for the catch. Regarding whether keyframes should be updated after a large rotation -- that largely depends on the FOV of the LiDAR. If the sensor is 360 degrees, then yes, keyframes are rotation-invariant. There are some sensors (i.e., Intel L515 or some older Livox sensors) that have a limited FOV, so keyframes are rotation-dependent. Even with modern mechanical LiDAR, they are only 360 FOV in the x-y direction, so tilting up or down would provide more information (and hence need a new keyframe). If I recall correctly, this exact scenario can be seen in the beginning of one of the LIO-SAM datasets. |
Understood. DLIOM being available some day would be awesome :)
Makes perfect sense! |
Updated! Thanks again for the catch. |
…-workday-3-2 add timestamp param to localization subscribers
I have some questions about this section of
updateKeyframes()
:direct_lidar_inertial_odometry/src/dlio/odom.cc
Lines 1572 to 1589 in a524000
To my understanding, there are some possible issues here:
rotational exploration keyframing
is always overwritten by
num_nearby
has no effectIf this statement
is true (from the second condition),
this statement doesn't change
newKeyFrame
, even ifnum_nearby
is larger than 1. At this point,abs(dd) <= this->keyframe_thresh_dist_
is always true, given thatabs(dd) > this->keyframe_thresh_dist_
was false in the condition before.Intended logic
What is the intended logic here? I couldn't find much about this in your papers, except the adaptive thresholding distance to account for tight spaces.
Without the rotational exploration keyframing, the logic is clear to me (roughly):
Now, I don't quite understand why the keyframe are updated when a large rotation was registered. In a scenario where, let's say, the robot stays in the same spot, but turns 180deg. Why do I have to update keyframes? The map is rotation invariant, so to speak, so I have gained no new information about the environment just be turning. I guess this is what was meant with the following statement in the DLO-paper?
Thanks for you help, happy to discuss
The text was updated successfully, but these errors were encountered: