You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the Line 2669, we get a pose from _optimizedPoses without inverting it, and assign it into the currentPoseInv. Are all the poses in _optimizedPoses actually the inverse of poses? In the Line 2679, we multiply it with another pose to calculate distance, which makes sense only if this currentPoseInv is truly the inverse of a pose, rather than the pose itself.
Or, might it simply be a typo that we forgot to have .inverse() on the Line 2669?
Thanks!
The text was updated successfully, but these errors were encountered:
I think that most of the time it is rare that we get exact same likelihood for 2 nodes in the same proximity path, so the distance check after is ignored in general. I'll make the change though, as when it happens, the result is probably wrong.
EDIT: actually this would happen all the time in lidar-only SLAM (where there would be no likelihood). It doesn't matter too much which node on the proximity path is the main node for the link, though it is preferable to be the closest one. I t should be fixed by 7c601bb
Hi, first I want to thanks a lot for this great software library!
When I'm reading the code for proximity detection by space, I have one place that I could not understand:
rtabmap/corelib/src/Rtabmap.cpp
Lines 2669 to 2679 in 2a840fe
In the Line 2669, we get a pose from
_optimizedPoses
without inverting it, and assign it into thecurrentPoseInv
. Are all the poses in_optimizedPoses
actually the inverse of poses? In the Line 2679, we multiply it with another pose to calculate distance, which makes sense only if thiscurrentPoseInv
is truly the inverse of a pose, rather than the pose itself.Or, might it simply be a typo that we forgot to have
.inverse()
on the Line 2669?Thanks!
The text was updated successfully, but these errors were encountered: