-
Notifications
You must be signed in to change notification settings - Fork 88
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
Incorrect Sphere Collision Detection: Spheres handled as Points in tesseract_gjk_pair_detector.cpp #949
Comments
Would you have time to add a unit test which shows it failing and possible a patch to fix the problem? |
@JayanthSuresh So I started to investigate this by create a unit test disabling calculate_distance shown in this PR #954 but was unable to recreate the issue. I did find a bug in FCL's handling of the calculate_distance which the PR fixes. Can you take a look and see what might be different between your setup and the unit test? |
@Levi-Armstrong Thanks for taking a stab at it. I am on an older version and I ran into a few issues trying to upgrade. I want to test it with the latest version to ensure the issue still persists. If it does, I will create a unit test. Will get back to you in a couple of days. |
If you have any questions upgrading to the latest let me know; I am happy help. |
This is my catkin config: robot@robot:~/tesseract_ws$ catkin build tesseract_collisionProfile: default
|
If I don't pass |
@Levi-Armstrong Looks like the Issue exists only in the older version. The PR #954 includes unit test that captures sphere collision checking, thanks for that! |
During discrete collision detection while using Bullet physics engine with calculate distance set to false, spheres are incorrectly treated as points, leading to inaccurate collision results. The issue originates in the
btComputeSupport
function withintesseract_gjk_pair_detector.cpp
, where the support vertex is calculated without considering the shape's margin. ForbtSphereShape
, the margin is essentially the radius of the sphere, meaning the function tends to return the origin (0,0,0) instead of an accurate point on the sphere's surface.The function should calculate the support vertex taking into account the sphere's radius, thereby returning a point on the actual surface of the sphere, not the origin.
To address this issue, the calculation of
pInANoMargin
andqInBNoMargin
should be adjusted based on the shape type. If the shape type isSPHERE_SHAPE_PROXYTYPE
, the functionlocalGetSupportVertexNonVirtual
should be used instead oflocalGetSupportVertexWithoutMarginNonVirtual
. See proposed change below:btVector3 pInANoMargin = (convexA->getShapeType() == SPHERE_SHAPE_PROXYTYPE) ? convexA->localGetSupportVertexNonVirtual(separatingAxisInA) : convexA->localGetSupportVertexWithoutMarginNonVirtual(separatingAxisInA);
btVector3 qInBNoMargin = (convexB->getShapeType() == SPHERE_SHAPE_PROXYTYPE) ? convexB->localGetSupportVertexNonVirtual(separatingAxisInB) : convexB->localGetSupportVertexWithoutMarginNonVirtual(separatingAxisInB);
The text was updated successfully, but these errors were encountered: