Grabbed, CheckSelfCollision, and unordered grabbed bodies issues. #1436
Assignees
Comments
Reproduction for Issues
How to run Issue1 test
How to run Issue2 test
How to run Issue3 test
How to run Issue4 test
|
snozawa
pushed a commit
that referenced
this issue
Sep 25, 2024
- Issue - This commit tries to improve the reported issue1, issue2, and issue3 : #1436 - Previously, _listNonCollidingLinksWhenGrabbed is asymmetric : the results obtained from grabbedBody1 is not same as the results obtained from grabbedBody2. - However, many codes in CheckSelfCollision assumes it's symmetric. The assumption was broken. In addition, such breakage was amplified after #1421. - Resolution - Instead of store the target link like the previous _listNonCollidingLinksWhenGrabbed_, store the information about the link pairs. This is more accurate and the same methodologies as non-adjacent-links in self colision checking. - Separate grabbed-grabber link pair and inter-grabbed link pair. - grabbed-grabber link pair, e.g. object-robot link pair, still exists in the Grabbed class as before. - inter-grabbed link pair now exists in the KinBody class, since if it's held in Grabbed, it becomes inconsistent and asymmetric. - Following the same methodologies in #1421, inter-grabbed link pairs are stored as unordered_map, and its key is combined env body indices of two grabbed bodies.
snozawa
pushed a commit
that referenced
this issue
Oct 19, 2024
… it means pOtherGrabbed is grabbed later than 'this'. Thus, pOtherGrabbed did not exist when 'this' was grabbed. The results of lazy computation should be same as the result of non-lazy computation. Therefore, we should not compute the inter-grabbed collision checking with pOtherGrabbed. This resolves Issue4 in #1436.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
GrabbedandCheckSelfCollisionoriginally had a problem, but it's quite amplified when we introducedunordered_setfor grabbed bodies in Optimize IsGrabbing / ResetGrabbed #1421.Issue1
How to run Issue2 testin Grabbed, CheckSelfCollision, and unordered grabbed bodies issues. #1436 (comment)grabbedBody1andgrabbedBody2. These are grabbed by different links, e.g. the robot needs to care about the self collision between these two.CheckSelfCollisionassumes that the collision checking is symmetric, e.g. order ofgrabbedBody1andgrabbedBody2does not matter. Also, the code is optimized by utilizing this assumption, for example:forloop :openrave/src/libopenrave/kinbodycollision.cpp
Lines 151 to 152 in 8b196c7
_listNonCollidingLinksWhenGrabbed:openrave/src/libopenrave/kinbodycollision.cpp
Line 174 in 8b196c7
openrave/src/libopenrave/kinbodycollision.cpp
Line 181 in 8b196c7
GrabbedforgrabbedBody1might containgrabbedBody2in_listNonCollidingLinksWhenGrabbed. But,GrabbedforgrabbedBody2mignt not containgrabbedBody1. So, the internal data are asymmetric.nonCollidingLinks1andnonCollidingLinks2are symmetric. But, if it's not symmetric, likenonCollidingLinks1=[]andnonCollidingLinks2=[grabbedBody1], the code does not entercontinue, and thus, it check collision betweengrabbedBody1andgrabbedBody2. But in the next iteration here, it started checking aboutgrabbedBody2, and since it containsgrabbedBody1in the list, it checks the collision betweengrabbedBody1andgrabbedBody2again. I confirmed that same collision paris are checked twice from print message.in some caseandmight, since the whole situation is governed by the ordering byunordered_set. Thus, the overall behavior looks quite undeterministic, and checking result might be flaky according to the situation.unordered_setfor grabbed bodies as it is, and fix the problems in other part, like the followings:CheckSelfCollision._listNonCollidingLinksWhenGrabbedsymmetric.CheckSelfCollision, and it might increase the computation. Instead, I guess 2 might be reasonable and now I'm trying 2.Issue2
How to run Issue1 testin Grabbed, CheckSelfCollision, and unordered grabbed bodies issues. #1436 (comment)AandB. Both of them are grabbed by differetn links, and both of them has two links (A1, A2andB1, B2). Also, initiallyA2andB2are colliding.A'sComputeListNonCollidingLinksis called first:A's_listNonCollidingLinksWhenGrabbedbecomes[]related to the asymmetricity inIssue1.B's_listNonCollidingLinksWhenGrabbedcontains[A1], sinceA1is only collision free link.CheckSelfCollision, inB's iteration, it iterates withB1andB2. So, the considered pairs are(A1, B1)and(A1, B2).A's iteration does not check anything sice_listNonCollidingLinksWhenGrabbedis empty.B'sComputeListNonCollidingLinksis called first:B's_listNonCollidingLinksWhenGrabbedbecomes[]related to the asymmetricity inIssue1.A's_listNonCollidingLinksWhenGrabbedcontains[B1], sinceB1is only collision free link.CheckSelfCollision, inA's iteration, it iterates withA1andA2. So, the considered pairs are(A1, B1)and(A2, B1).B's iteration does not check anything sice_listNonCollidingLinksWhenGrabbedis empty.CheckSelfCollision.(A1, B2)is skipped.Issue1.unordered_set._listNonCollidingLinksWhenGrabbed, we computelink vs bodycollision, instead oflink vs linkcollision. Thus, the information about the pairs are not preserved. This also causes another kind of asymmetricity._listNonCollidingLinksWhenGrabbed, it's reasonable.AandBhave collision, these are not added to_listNonCollidingLinksWhenGrabbed. Thus, bothA's_listNonCollidingLinksWhenGrabbedandB's_listNonCollidingLinksWhenGrabbedare empty. I think this case is consistent.AandB._listNonCollidingLinksWhenGrabbedstores the pair ofLinkConstPtrin some way. The result of the picture is,_listNonCollidingLinksWhenGrabbed=[(1, B1), (A1, B2), (A2, B1)]and we can make it symmetric betweenAandB._listNonCollidingLinksWhenGrabbed. Might take time to compute inComputeListNonCollidingLinks.Policy 2and make it symmetric somehow.Issue3
How to run Issue3 testin Grabbed, CheckSelfCollision, and unordered grabbed bodies issues. #1436 (comment)CheckSelfCollisioncall, the contents of_listNonCollidingLinksWhenGrabbedmight be different from the laterCheckSelfCollisioncall.Grabbed::ComputeListNonCollidingwill remove the otherGrabbed's information inRelease.Issue4
How to run Issue4 testin Grabbed, CheckSelfCollision, and unordered grabbed bodies issues. #1436 (comment)_ListNonCollidingLinksWhenGrabbedis introduced in Lazy Computation of List Non-Colliding Links #1038Grabbedis constructed, list is computed. After that,Grabbedconstructor do nothing, and when we callCheckSelfCollisionat the first time, list is computed, byComputeListNonCollidingLinks.ComputeListNOnCollidingLinks. However, it's changing.grabbedBody1, and thengrabbedBody2,GrabbedforgrabbedBody1should not know about thegrabbedBody2, since it was not there whengrabbedBody1is grabbed. However, when we postpone the computation,grabbedBody1might consider the collision checking withgrabbedBody2.unordered_map.cc @Puttichai @rschlaikjer @yoshikikanemoto @kanbouchou @rdiankov
The text was updated successfully, but these errors were encountered: