I'm seeing some failures of test_fcl_geometric_shapes on OS X (details here). Many of the test failures reference libccd. I'm using libccd 2.0 from homebrew.

The code in include/fcl/knn appears to be unused. Is there any reason to keep it? If not, we might as well remove it.

Hi!
I'd love to use FCL to do continuous collision checking with a cylinder (quadrotor model approximation) and an octree, but get an error about it not being implemented for those two types.
Are there plans to implement octree vs. basic geometric shapes for continuous collisions? Or is it already implemented and I'm doing something wrong?

Thanks so much for the help!

Hello,
please I'd like to know whether the library allows adding and deleting objects dinamically; for example, registering 1000 objects at the beginning and during execution deleting 10 objects and then adding 20 objects and such.

Thanks in advance!

Halfspace is one of primitive shapes of FCL but it's not registered to the collision matrix. So it can't be used through collide(~), which is the main collision interface.

I spent a few hours debugging poor performance of FCL on some mesh models and realized that the broad-phase check wasn't pruning any pairs of geometries. I eventually tracked the problem down to incorrect AABBs on my CollisionObjects. It turns out that I wasn't calling computeAABB after changing the pose of my geometries, so the broad-phase check considered them all to be overlapping at the origin.

It would be helpful if you could add a note about this in the README. The current documentation doesn't mention computeAABB at all and, thus, gives the impression that the CollisionManager takes care of computing everything necessary for the broad-phase check.

(The performance is great now that the broad-phase check works!)

The BVHModel class has a default assignment operator which causes shallow copy of all members. This causes a double free.

std::vector<BVHModel<T> > models(7);
//fill in models like:
BVHModel<T> m;
//populate m ...
models[i] = m;

Suggest either implementing assignment operators, or make operator= private to prevent compilation.

Hi there!

I think I found a bug in sphereTriangleIntersect() in narrowphase.cpp:

Somewhere in the middle of the function

projectInTriangle(P1, P2, P3, center, normal)

gets called in the in if statement. The function however has the interface

bool projectInTriangle(const Vec3f& p1, const Vec3f& p2, const Vec3f& p3, const Vec3f& normal, const Vec3f& p).

So the center and normal argument in the call should be switched. In my simulation, this bug leads to the effect that small spheres fall through large triangles, only colliding with the triangle edges.

Thank you very much for your effort.

Remo

Segfault when colliding a PointCloud with a Mesh/Shape in (traversal_recurse.cpp, line 45):

bool l1 = node->isFirstNodeLeaf(b1);

In collide() from BVHShapeCollider (collision_func_matrix.cpp, line 246):

      initialize(node, *obj1_tmp, tf1_tmp, *obj2, tf2, nsolver, no_cost_request, result);
      fcl::collide(&node);

initialize() returns false when the mesh is of model type BVH_MODEL_POINTCLOUD for most combinations:

  if(model1.getModelType() != BVH_MODEL_TRIANGLES)
    return false;

However, fcl::colide(&node) still runs without acknowledging the initialization problem.

As a suggestion, a boolean check should be done to the initialize() node (with a warning) to prevent fcl::collide from running and causing memory issues (segfault).

Also, is there any other way to check collisions between Pointclouds and other shapes using FCL without octrees?

Thank you in advance.

Hello,

I have experimented integrating the Eigen library and I'm wondering whether you are interested in the resulting code.
Below are more details.

Motivation

The greatest advantage in using Eigen in FCL is that it avoids creating non-necessary temporary matrices (and vectors). The following code:

Vec3f a, b;
Vec3f c = a + b;

is, with FCL vectors, compiled as:

tmp <- a.operator+(b);
c <- tmp

whereas, with Eigen vectors:

c <- a.operator+(b)

This becomes more interesting on more complex expressions. See this for more details on temporary elimination and lazy assignment.

Preliminary results

So far, I have only integrated Eigen in Vec3f and Matrix3f and the improvements are mostly marginal, from 1% to 10% on the basic tests I did. The advantages of the method are:

• No copy required for users needing Eigen in a library which depends on FCL.
• A greater gain can be expected by relying on Eigen for other math classes such as Quaternion3f... I did not do any profiling to check what could be done.

Implementation details

There are very few impacts in the current code. Three parts of the code needs to be changed, whenever the prepocessor variable FCL_HAVE_EIGEN is 1:

• Classes Vec3f and Matrix3f (so far) are declared based on Eigen, with the exact same interface. (the main problem is the inplace transpose in FCL)
• Class TVector3 needs one additional operator*
• Conditional operator ?:; does not work with expressions of matrices. For instance,
  b = (condition)?a:-a; must be changed in if (condition) b = a; else b = -a;

Could we release 0.4.0? It would enable DART to utilize FCL's primitive shape support with the patches applied after 0.3.2. Here is the list of issues and pull requests for 0.4.0.

If possible, it would be nice to submit 0.4.0 to Debian for Ubuntu Xenial.

in 0.3.0 the following two unit tests are broken: test_fcl_broadphase and test_fcl_shape_mesh_consistency. In the first one there might some sort of memory corruption.

create pull request to enable CI currently working in dartsim fork

@jslee02

When checking for collision using Collision Result, the distance to nearest collision is provided as information. However, the normal vector along that distance is not available. This would be valuable information in detecting collisions prior to their occurence.

There are doxygen style comments in the header files.
Could you add a Doxyfile, for example the one that was used to produce
http://gamma.cs.unc.edu/FCL/fcl_docs/webpage/generated/annotated.html

Hy everyone !

I'm working on an application which has for aim to stop a robot if an obstacle appears in the middle of his trajectory during the execution. I use ROS Hydro and MoveIt! .
To do so, I use the planned trajectory to get the future states of the robot, and I check if there are collisions with the environment. If there are I stop the execution.
It works most of the time but sometimes it crash when checking for collisions.
To check if there are collisions I tried with two different functions (available in MoveIt), both of them use the FCL library :

• isPathValid (const robot_trajectory::RobotTrajectory &trajectory, const std::string &group="", bool verbose=false, std::vector< std::size_t > *invalid_index=NULL) const
  from the planning_scene::PlanningScene library
• checkRobotCollision (const CollisionRequest &req, CollisionResult &res, const CollisionRobot &robot, const robot_state::RobotState &state) const
  from the collision_detection::CollisionWorldFCL library

When it crash, it exits with the error code -11 (Seg fault).

I launched it with gdb and I have two different errors (with both the functions isPathValid() and checkRobotCollision() ) :

1 - Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5d3968c in std::string::compare(std::string const&) const ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

2 - Program received signal SIGSEGV, Segmentation fault.
0x00007ffff2d3aa18 in fcl::details::dynamic_AABB_tree::collisionRecurse(fcl::NodeBasefcl::AABB_, fcl::CollisionObject_, void_, bool ()(fcl::CollisionObject, fcl::CollisionObject_, void*)) ()
from /opt/ros/hydro/lib/libfcl.so

Before using these functions, I check if all the variables I give to the functions are well initialized and they are.
I don't have any experience with gdb so I don't really understand the errors I get and I don't know all the options I could use to help myself solving this issue. I tried with valgrind but it slows the execution of my program and it becomes useless.

If someone has any ideas where it can comes from, it would be nice.

Thanks !

Théo

Hi all,
I have the following error. All I did was do find_package(FCL REQUIRED) in my CMakeLists.txt.

CMake Error at /opt/ros/hydro/share/fcl/fcl-config.cmake:103 (message):
Project 'fcl' specifies 'include' as an include dir, which is not found.
It does not exist in 'include'. Ask the maintainer 'Ioan Sucan
[email protected]' to fix it.

Any ideas how to fix this?

Regards
Aswin

'__declspec' should be placed before the function definition in MSVC.

The function isIdentity() in matrix_3f.h returns a false value:
Current:
inline bool isIdentity () const
{
return
data (0,0) == 1 && data (0,1) == 0 && data (0,2) == 0 &&
data (0,0) == 0 && data (0,1) == 1 && data (0,2) == 0 &&
data (0,0) == 0 && data (0,1) == 0 && data (0,2) == 1;
}
Should be:
inline bool isIdentity () const
{
return
data (0,0) == 1 && data (0,1) == 0 && data (0,2) == 0 &&
data (1,0) == 0 && data (1,1) == 1 && data (1,2) == 0 &&
data (2,0) == 0 && data (2,1) == 0 && data (2,2) == 1;
}

Daniel

The file fcl/Makefile is under version control. It should be removed as it gets generated by cmake, and you see differences with it when you call git diff.

There seems to be a bug in the distance computation between capsules and boxes.
I tried to track it but failed to understand what is going on in the internals of gjk_libccd.

I reproduced the bug in a unit test that I will provide in a pull request.

Box-Cylinder, Box-Sphere, Box-Mesh all return incorrect points of collision and incorrect normals.

Box-Cylinder and Box-Sphere occasionally return the correct normal.

I try to build a mesh using the following naive procedure

boost::shared_ptr <fcl::BVHModel< fcl::OBB > mesh
(new (fcl::BVHModel< fcl::OBB >));
mesh->beginModel ();
// Loop over a previously filled vector of vectices
for (std::size_type  i = 0; i<vertices.size (); ++i)
  mesh->addVertex (vertices [i]);
// Loop over a previously filled vector of triangles
for (std::size_type  i = 0; i<triangles.size (); ++i)
  mesh->addVertex (triangles [i]);
mesh->endModel ();

This does not works since method beginModel sets build_state member of mesh
to BVH_BUILD_STATE_BEGUN and method addVertex expects BVH_BUILD_STATE_UPDATE_BEGUN as value for build_state.

I noticed that addVertex is not used in tests. Did I do something wrong ?

When a plane is added to a collision world in moveit (where an octree also exists), fcl segfaults.

(gdb) 
#12 0x00007fffefb2e710 in collision_detection::CollisionWorldFCL::checkRobotCollisionHelper(collision_detection::CollisionRequest const&, collision_detection::CollisionResult&, collision_detection::CollisionRobot const&, robot_state::RobotState const&, collision_detection::AllowedCollisionMatrix const*) const ()
   from /u/moveit/catkin/devel/lib/libmoveit_collision_detection_fcl.so
(gdb) 
#11 0x00007fffebf66ec9 in fcl::DynamicAABBTreeCollisionManager::collide(fcl::CollisionObject*, void*, bool (*)(fcl::CollisionObject*, fcl::CollisionObject*, void*)) const () from /opt/ros/groovy/lib/libfcl.so
(gdb) 
#10 0x00007fffebf6385f in fcl::details::dynamic_AABB_tree::collisionRecurse(fcl::NodeBase<fcl::AABB>*, fcl::CollisionObject*, void*, bool (*)(fcl::CollisionObject*, fcl::CollisionObject*, void*)) () from /opt/ros/groovy/lib/libfcl.so
(gdb) 
#9  0x00007fffefb1f723 in collision_detection::collisionCallback(fcl::CollisionObject*, fcl::CollisionObject*, void*) ()
   from /u/moveit/catkin/devel/lib/libmoveit_collision_detection_fcl.so
(gdb) 
#8  0x00007fffec1ac835 in fcl::collide(fcl::CollisionObject const*, fcl::CollisionObject const*, fcl::CollisionRequest const&, fcl::CollisionResult&) ()
   from /opt/ros/groovy/lib/libfcl.so
(gdb) 
#7  0x00007fffec1acbb4 in unsigned long fcl::collide<fcl::GJKSolver_libccd>(fcl::CollisionObject const*, fcl::CollisionObject const*, fcl::GJKSolver_libccd const*, fcl::CollisionRequest const&, fcl::CollisionResult&) ()
   from /opt/ros/groovy/lib/libfcl.so
(gdb) 
#6  0x00007fffec1aca0e in unsigned long fcl::collide<fcl::GJKSolver_libccd>(fcl::CollisionGeometry const*, fcl::Transform3f const&, fcl::CollisionGeometry const*, fcl::Transform3f const&, fcl::GJKSolver_libccd const*, fcl::CollisionRequest const&, fcl::CollisionResult&) () from /opt/ros/groovy/lib/libfcl.so
(gdb) 
#5  0x00007fffec033001 in unsigned long fcl::ShapeShapeCollide<fcl::Plane, fcl::Cylinder, fcl::GJKSolver_libccd>(fcl::CollisionGeometry const*, fcl::Transform3f const&, fcl::CollisionGeometry const*, fcl::Transform3f const&, fcl::GJKSolver_libccd const*, fcl::CollisionRequest const&, fcl::CollisionResult&) ()
   from /opt/ros/groovy/lib/libfcl.so
(gdb) 
#4  0x00007fffec09b91f in fcl::ShapeCollisionTraversalNode<fcl::Plane, fcl::Cylinder, fcl::GJKSolver_libccd>::leafTesting(int, int) const ()
   from /opt/ros/groovy/lib/libfcl.so
(gdb) 
#3  0x00007fffec1a7eeb in fcl::details::GJKCollide(void*, void (*)(void const*, _ccd_vec3_t const*, _ccd_vec3_t*), void (*)(void const*, _ccd_vec3_t*), void*, void (*)(void const*, _ccd_vec3_t const*, _ccd_vec3_t*), void (*)(void const*, _ccd_vec3_t*), unsigned int, double, fcl::Vec3fX<fcl::details::Vec3Data<double> >*, double*, fcl::Vec3fX<fcl::details::Vec3Data<double> >*) ()
   from /opt/ros/groovy/lib/libfcl.so
(gdb) 
#2  0x00007fffea289b87 in ccdMPRIntersect ()
   from /opt/ros/groovy/lib/libccd.so.2
(gdb) 

The new Toyota Research Institute would like to support development of a robust, accurate, and high-performance open source collision library that would be useful for our needs in high-accuracy simulation and motion planning, as well as for the community at large. Currently we're thinking FCL may be the best place to start.

Questions to FCL maintainers and community:

• do you agree that FCL would be the best open source library to develop from?
• what are the big needs that FCL does not currently address, or problems that need fixing?
• who are the admins and write-access developers currently? (team seems to be private)
• what would be the best way for us to help advance FCL?

Thanks and regards,
Sherm

/cc @hsu, @scpeters, @jslee02, @panjia1983, @isucan, @j-rivero, @mfelis, @mamoll

I am trying to integrate FCL into an existing scenegraph-system, that internally manages multiple levels of object-grouping. In order to use the broadphase algorithms of FCL I fill instances of fcl::DynamicAABBTreeCollisionManager for each grouping.

During the creation of a higher-level grouping I then attempt to add the list of collision objects in the subgroup that is currently empty.

The manager starts a tree traversal for insertion, and the final insertion method HierarchyTree::topdown_0(in file include/fcl/broadphase/hierarchy_tree.hxx, line 353) then tries to touch the first element of the empty list(line 386), causing a segfault.

The method topdown_0 even checks the number of elements before doing the main processing, so I assume it could be a reasonable place to catch the special case of an empty list. However, I can't really assess the affects of setting the root pointer of the tree to NULL (as would be my natural answer to no insertion).

I suspect that similar cases are also currently unhandled by the library, making the usage quite unrelieable.

If you could set a guideline on when special cases should be caught (As early as possible? Or process them until they have to be handled?), I'd be up to fixing issues I find myself and submitting pull requests.

when faces are parallel
http://pastebin.com/XpCH6T4E
penetration depth is correct

Hi,
I'm trying to check if there is a collision between a mesh model and a Box of volume 1 located at specific point,
The problem I'm facing is that when the Box is located inside the mesh, the collision function returns false (no collision).
How can I use fcl to check if there is a collision inside the mesh??

Here is the code used for the collision check:
//loading the mesh.obj
std::vector p1;
std::vector t1;
loadOBJFile("mesh.obj", p1, t1);
BVHModel* m1 = new BVHModel();

m1->beginModel();
m1->addSubModel(p1, t1);
m1->endModel();

Transform3f tf1;
tf1.setIdentity();
tf1.setTranslation(Vec3f(0,0,0));
CollisionObject* obj = new CollisionObject(boost::shared_ptr(m1), tf1);

//creating the Box centered at specific point
boost::shared_ptr Sample(new Box(1));
tf0.setIdentity();
tf0.setTranslation(Vec3f(0 , 0 , -5));
CollisionObject co0(Sample, tf0);
static const int num_max_contacts = std::numeric_limits::max();
static const bool enable_contact = true ;
fcl::CollisionResult result;
fcl::CollisionRequest request(num_max_contacts, enable_contact);
fcl::collide(&co0, obj, request, result);
AABB a = co0.getAABB() ;
Vec3f vec2 = a.center() ;
if (result.isCollision() == true )
{ marker = drawCUBE(vec2,1,2,1) ;//red
std::cout<<"Collision"<<std::endl;
} else {
marker = drawCUBE(vec2, 1, 1,1) ;//blue
std::cout<<"No Collision"<<std::endl;
}

The model used is as shown below

The following is a snap shot of Box and mesh collision ( the mesh is represented as points just for visualization but the model used is as shown in the previous snap shot)

Running cmake . in the fcl root directory
didn't work on Windows as PKG_CONFIG_FOUND is false.
and as find_path ccd.h doesn't find this file (nor did I).

The following files from the fcl-0.3.2 release contain no copyright headers:

# licensecheck -r .  | grep UNKNOW
./src/math/sampling.cpp: *No copyright* UNKNOWN
./src/continuous_collision.cpp: *No copyright* UNKNOWN
./include/fcl/exception.h: *No copyright* UNKNOWN
./include/fcl/math/vec_nf.h: *No copyright* UNKNOWN
./include/fcl/math/sampling.h: *No copyright* UNKNOWN
./include/fcl/ccd/simplex.h: UNKNOWN
./include/fcl/ccd/support.h: UNKNOWN
./include/fcl/continuous_collision.h: *No copyright* UNKNOWN
./include/fcl/learning/classifier.h: *No copyright* UNKNOWN
./test/libsvm_classifier.h: *No copyright* UNKNOWN
./test/general_test.cpp: *No copyright* UNKNOWN
./test/libsvm/svm.cpp: *No copyright* UNKNOWN
./test/libsvm/svm.h: *No copyright* UNKNOWN
./test/test_fcl_utility.cpp: *No copyright* UNKNOWN
./test/test_fcl_simple.cpp: *No copyright* UNKNOWN

Please consider adding proper copyright headers to the aforementioned files.

simplex.h is no longer installed. This header is included by fcl/src/narrowphase/gjk_libccd.cpp. Part of the code in that file seems to have originated in libccd. That code was removed from libccd because it wasn't properly tested (see danfis/libccd@46391af). Maybe gjk_libccd.cpp should be removed from fcl?

Running the MoveIt Setup Assistant on a Netbook segfaults after loading the robot into the planning the scene. The back trace of the crash is traced to FCL. Talking with @isucan we believe the issue is likely a SSE issue that the netbook does not support. What can we do to fix this? Thanks!

gdb backtrace:

#0  0xb4bda739 in fcl::BVHModel<fcl::OBBRSS>::buildTree() () from /opt/ros/groovy/lib/libfcl.so
#1  0xb4bdaaf1 in fcl::BVHModel<fcl::OBBRSS>::endModel() () from /opt/ros/groovy/lib/libfcl.so
#2  0xb5f8ac1b in boost::shared_ptr<collision_detection::FCLGeometry const> collision_detection::createCollisionGeometry<fcl::OBBRSS, robot_model::LinkModel>(boost::shared_ptr<shapes::Shape const> const&, robot_model::LinkModel const*) ()
   from /home/owner/ros/clam_catkin/moveit/devel/lib/libmoveit_collision_detection_fcl.so
#3  0xb5f8b150 in boost::shared_ptr<collision_detection::FCLGeometry const> collision_detection::createCollisionGeometry<fcl::OBBRSS, robot_model::LinkModel>(boost::shared_ptr<shapes::Shape const> const&, double, double, robot_model::LinkModel const*) ()
   from /home/owner/ros/clam_catkin/moveit/devel/lib/libmoveit_collision_detection_fcl.so
#4  0xb5f84b62 in collision_detection::createCollisionGeometry(boost::shared_ptr<shapes::Shape const> const&, double, double, robot_model::LinkModel const*) ()
   from /home/owner/ros/clam_catkin/moveit/devel/lib/libmoveit_collision_detection_fcl.so
#5  0xb5f8c67e in collision_detection::CollisionRobotFCL::CollisionRobotFCL(boost::shared_ptr<robot_model::RobotModel const> const&, double, double) ()
   from /home/owner/ros/clam_catkin/moveit/devel/lib/libmoveit_collision_detection_fcl.so
#6  0xb6b36cc8 in planning_scene::PlanningScene::CollisionDetectionAlloc<collision_detection::CollisionWorldFCL, collision_detection::CollisionRobotFCL>::allocateRobot(boost::shared_ptr<robot_model::RobotModel const> const&) () from /home/owner/ros/clam_catkin/moveit/devel/lib/libmoveit_planning_scene.so
#7  0xb6b29ef0 in planning_scene::PlanningScene::configure(boost::shared_ptr<robot_model::RobotModel> const&) () from /home/owner/ros/clam_catkin/moveit/devel/lib/libmoveit_planning_scene.so
#8  0xb6ceb5b0 in moveit_setup_assistant::MoveItConfigData::getPlanningScene() ()
   from /home/owner/ros/clam_catkin/moveit/devel/lib/libmoveit_setup_assistant_tools.so
#9  0xb7f9b6ca in moveit_setup_assistant::RobotPosesWidget::RobotPosesWidget(QWidget*, boost::shared_ptr<moveit_setup_assistant::MoveItConfigData>) ()
   from /home/owner/ros/clam_catkin/moveit/devel/lib/libmoveit_setup_assistant_widgets.so
#10 0xb7fbab99 in moveit_setup_assistant::SetupAssistantWidget::progressPastStartScreen() ()
   from /home/owner/ros/clam_catkin/moveit/devel/lib/libmoveit_setup_assistant_widgets.so
#11 0x0805cdf0 in moveit_setup_assistant::SetupAssistantWidget::qt_static_metacall(QObject*,

Here is a simple test to show the incorrect contact point computation in mesh-mesh collision I mentioned in #97.

In the test, there are two meshes generated from Box as shown in below figure (rendered by DART). The two meshes are in face contact. We would expect four contact points should be at the four corners of the face of green box touching with the red box (or at least not out of the face). However, the results showed that the contact points (small blue spheres in the figure) are more than four (30 points and some of them are duplicates) and even placed at the corner of the red box. This is the result I got on my computer.

It seems that contact points are always placed at the vertices of mesh triangles rather than the exact contact point of the two colliding triangles.

This bug is crucial and easily results in unrealistic behavior in dynamics simulation. For example, the yellow box in the below figure is hanging in the air because of the ghost contact points at the right bottom corners.

Currently, there is no way to set or update the point cloud in fcl::OcTree since it does not expose the octomap::OcTree interface. The only workaround is to store the octomap pointer externally and pass it as an argument to the ctor of fcl::OcTree during its creation, but that's not practical. I believe a better way would be adding the method getTree() to fcl::OcTree, which would return the private tree member, giving access to the full octomap interface.

FCL causes segfault in building point cloud model as:

boost::shared_ptr<BVHModel<OBB> > model(new BVHModel<OBB>);  // or RSS/kIOS/OBBRSS
model->beginModel();
// Loop over a previously filled vector of vectices
for (std::size_t i = 0; i < points.size(); ++i)
  result = model->addVertex(points[i]);
model->endModel();  // segfault!

The main reason of the segfault is that the bvh models don't handle triangle indices correctly.

Also, some tests for point cloud models are needed since there is none.

Hi,

There is a cython wrapper for FCL, based on cython.
I've forked & extended the project ( the original project has been abandoned / the original author is not very reactive ) such to include BVHModel. The latter makes the wrappers quite useful actually, and performance is excellent.

I'm curious to know whether there's an interest in the wrappers. I think the current state is a reasonable foundation to build upon.

Looking fwd to have your feedback...

PS: if you happen to run OSX / conda, it takes just a minute to check things out

nmake fcl builds fcl.dll but no fcl.lib on Windows/VC++

My guess is that the "declspec export" stuff is missing.
The temporary solution is to build the static version of fcl.

As FCL still doesn't have a logo, I would like to propose one:

The three letters, "FCL", are laid on each invisible layers in a cube. "C" letter is colored by red to emphasize collision and to indicate it is colliding with other two letters.

Hi,

is it possible to compile fcl for OSX. I'm able to cmake but trying to make inside the build folder or includeing the source inside my xcode project gives me duplicate symbols for architecture x86_64 compile error. I used the install_osx.sh script to install the depenndencies.

Versions:
OSX 11.11.3
Boost 1.60.0
cmake 3.4.3
libccd 2.0

duplicate symbol __ZNK3fcl5Joint20getTransformToParentEv in:
    CMakeFiles/fcl.dir/articulated_model/joint.cpp.o
    CMakeFiles/fcl.dir/fcl/articulated_model/joint.cpp.o

...

duplicate symbol __ZN3fcl5tools8Profiler15printThreadInfoERSoRKNS1_9PerThreadE in:
    CMakeFiles/fcl.dir/fcl/profile.cpp.o
    CMakeFiles/fcl.dir/profile.cpp.o
ld: 108 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Hi!

First I'd like to thank you very much for the helpful collision library. I'm using it for a walking robot simulation.

I think there is an error in the capsuleHalfspaceIntersect function in narrowphase.cpp.
In my opinion,

if(cosa < halfspaceIntersectTolerance<FCL_REAL>())

should be replace by

if(std::abs(cosa) < halfspaceIntersectTolerance<FCL_REAL>())

Have a good day and thank you very much!

Is it possible to use fcl to find the surface of contact between to 3D models. To explain a bit more, if I have a 3D mesh for an object, and I simulate the FOV of a sensor similar to kinect at a known position (Quadrahedron with known dimensions, position and orientation) , can I find out which surface on that 3D mesh will be exposed by the FOV ?

For discussion -- boost is a very heavyweight dependency and could be an impediment to FCL adoption. It can also cause problems when FCL is integrated into a larger program that already has a boost dependency, possibly involving a different version of boost (Matlab comes with a version linked in, which caused Drake to have to drop boost).

I'm wondering if the need for boost could be eliminated in favor of C++11 use instead? Are there boost features in use that C++11 can't provide?

Thanks to @scpeters in #100 for this list and idea. Please submit PRs that get rid of one or more of these and then check off the ones that are done until they are all gone. This issue is also a good place to discuss problems that arise.

• boost/test/unit_test.hpp
• boost/filesystem.hpp
• boost/timer.hpp
• boost/array.hpp
• boost/assert.hpp
• boost/assign/list_of.hpp
• boost/bind.hpp
• boost/cstdint.hpp
• boost/date_time/posix_time/posix_time.hpp
• boost/dynamic_bitset.hpp
• boost/foreach.hpp
• boost/function.hpp
• boost/iterator/zip_iterator.hpp
• boost/math/constants/constants.hpp
• boost/math/special_functions/erf.hpp
• boost/math/special_functions/fpclassify.hpp
• boost/noncopyable.hpp
• boost/random/lagged_fibonacci.hpp
• boost/random/mersenne_twister.hpp
• boost/random/normal_distribution.hpp
• boost/random/uniform_int.hpp
• boost/random/uniform_real.hpp
• boost/random/variate_generator.hpp
• boost/shared_array.hpp
• boost/shared_ptr.hpp
• boost/thread.hpp
• boost/thread/mutex.hpp
• boost/unordered_map.hpp
• boost/unordered_set.hpp
• boost/weak_ptr.hpp

Hi,

when positioning a Cone shape at (0,0,0), is the cone's base or apex at (0,0,0)?
when rotating a Cone shape, does it rotate around the base or the apex?

Thanks!

I'm Jeongseok Lee a member of DART development team. DART is powered by FCL for rigid body collision detection. We are trying to fully utilize FCL.

DART is using meshes for primitive shapes and now we want to use FCL's primitive shapes to reduce the computational cost and get analytical contact results. We however have an issue that FCL returns only one contact point for primitive shape collision which is a critical to us.

In some cases, multiple contact points are necessary in dynamics simulation. For example, when we lay a box on the ground (let's assume that the ground is thin box shape), we need at least three contact points to support the box. With one contact point at the center of the box's bottom face, it is unstable and can be fall down through the ground.

FCL gets contact point from GJKSolver_indep::shapeIntersect() or GJKSolver_libccd::shapeIntersect(). The shapeIntersect() function calls boxBoxIntersect() and boxBoxIntersect() gets multiple contact points from boxBox2() but returns the average of the contact points. (see: narrowphase.cpp ln:1350)

bool boxBoxIntersect(const Box& s1, const Transform3f& tf1,
                     const Box& s2, const Transform3f& tf2,
                     Vec3f* contact_points, FCL_REAL* penetration_depth_, Vec3f* normal_)
{
  std::vector<ContactPoint> contacts;
  int return_code; 
  Vec3f normal;
  FCL_REAL depth;
  /* int cnum = */ boxBox2(s1.side, tf1.getRotation(), tf1.getTranslation(),
                           s2.side, tf2.getRotation(), tf2.getTranslation(),
                           normal, &depth, &return_code,
                           4, contacts);

  if(normal_) *normal_ = normal;
  if(penetration_depth_) *penetration_depth_ = depth;

  if(contact_points)
  {
    Vec3f contact_point;
    for(size_t i = 0; i < contacts.size(); ++i)
    {
      contact_point += contacts[i].point;
    }

    contact_point = contact_point / (FCL_REAL)contacts.size();

    *contact_points = contact_point;
  }

  return return_code != 0;
}

It may not easy to decide which set of contact points is correct depend on colliding primitive shape combinations. However, it would be nice if FCL returns multiple contact points and the user enable to select contact points what the user wants.

Please let me know if I'm misunderstanding about FCL, thanks!

I sent some emails about this a long time ago, but I figured it's worth documenting with a ticket :)

In any case, is there (supposed to be) a standard that says, given a contact result between object #1 and object #2, whether the provided normal points from 1 to 2, or from 2 to 1?

In MoveIt!, it seems that robot-robot collision results are ambiguous as to the direction of the normal. This may be a problem in how MoveIt! interprets the FCL result, or it might be in FCL. For example, if I move the right arm into collision with the left arm, it seems to be somewhat non-deterministic whether the reported contact normal points from link 1 to link 2, or from link 2 to link 1.

I am testing collision detection between meshes using a model of PR2 robot with 312 pairs of collision. I am using the main API function

std::size_t collide(const CollisionObject* o1, const CollisionObject* o2,
                    const CollisionRequest& request,
                    CollisionResult& result);

and it takes several seconds for each configuration. I checked using gdb and found that the collision test between two "BVHmodel" seems to

1. copy the meshes (vertices and triangles : BVH_model.cpp:58) and
2. compute the position of each vertex in global frame (traversal_node_setup.h:603).

I am not an expert of collision checking, but it seems to me sub-optimal.
Did I call the right function ?

This is probably a fellow up to
#26

I would like to remove the possibility of assigning non-normalized quaternions, since they are not used in this context anyway, and i am running into rounding errors when running long enough (i.e. quaternions become unnormalized after time and crash my program).

I therefore removed the explicit initiation of a non-normed quaternion, which i think was a crude hack anyway
#34

So now i would like to make them fail-safe, i.e. that quaternions are normed by default. In this way, future bugs concerning the norm would be prevented.

Line 50 of README.md:
typedef BVHModel* Model;

should be:
typedef BVHModel Model;