search

flexible-collision-library / fcl

Flexible Collision Library
https://flexible-collision-library.github.io/
Other
1.39k stars 417 forks source link

Segmentation fault in INDEP's GJK / distance implementation #313

Open wxmerkt opened 6 years ago

wxmerkt commented 6 years ago

We run a lot of distance queries using fcl::distance where both o1 and o2 are primitive shapes (OT_GEOM). Very frequently (every few minutes), we receive a segmentation fault when using GST_INDEP (not for GST_LIBCCD):

#0  0x00007ffff0be4c2b in fcl::detail::GJKSolver_indep<double>::S 
fcl::distance<fcl::detail::GJKSolver_indep<double> >
(fcl::CollisionGeometry<fcl::detail::GJKSolver_indep<double>::S> const*, 
Eigen::Transform<fcl::detail::GJKSolver_indep<double>::S, 3, 18, 0> const&, 
fcl::CollisionGeometry<fcl::detail::GJKSolver_indep<double>::S> const*, 
Eigen::Transform<fcl::detail::GJKSolver_indep<double>::S, 3, 18, 0> const&, 
fcl::detail::GJKSolver_indep<double> const*, 
fcl::DistanceRequest<fcl::detail::GJKSolver_indep<double>::S> const&, 
fcl::DistanceResult<fcl::detail::GJKSolver_indep<double>::S>&) () from 
/home/wxm/dev/exotica_ws/devel/lib/libfcl.so.0.6

Unfortunately, I do not have a working reproduction use case yet, although, this happens frequently enough to open this issue to document it - in case someone has any insights. The primitives used are boxes, cylinders, and spheres. Based on our logic, we can conclude that the objects are either at a distance (fcl::collide does not return any contacts) or perhaps in the ill-defined touching contact case.

guduzhe123 commented 3 years ago

Hi, wxmerkt. I have the same problem when I use fcl::distance to get the min_distance to the octomap tree (fcl:collide runs well). So have you ever solved the problem? Thanks.

wxmerkt commented 3 years ago

I switched to LIBCCD for most queries. There are still issues with the quality of the nearest points at distance though.

sherm1 commented 3 years ago

@wxmerkt: Drake uses FCL for many of its geometric queries. @SeanCurtis-TRI recently ran precision experiments and tabulated the results for various query types in Drake's documentation. For example, see ComputePointPairPenetration() and ComputeSignedDistancePairwiseClosestPoints(). If I may editorialize, you can see that many of the results from FCL are very inaccurate. The high-precision results in the tables are mostly cases we handle ourselves rather than pass to FCL. Our roadmap is to fill that table with high precision results over time. In the meanwhile, user beware!

SeanCurtis-TRI commented 3 years ago

Are these distance queries signed or unsigned? Generally, they are different code paths. We've put a fair amount of energy to improving the signed distance queries for the libccd solver (and, even then, there are still occasional artifacts that come up that we use to improve further). We have less experience and less insight into either libindep or the separation distance query.

SeanCurtis-TRI commented 3 years ago

Also, it's worth noting, the tables that @sherm1 linked to above do not strictly represent FCL behavior or potential. In some cases, a cell in the table is filled in by Drake code (and not FCL code). In other cases, particularly the signed distance query, we haven't exposed the iteration tolerance, so we're using the default 1e-6 value that dominates the observed precision. So, don't look at that as an observation of FCL's state, per se.