hpp-fcl 2.4.4

An extension of the Flexible Collision Library

HPP-FCL — An extension of the Flexible Collision Library

FCL was forked in 2015. Since then, a large part of the code has been rewritten or removed (for the unused and untested part). The broad phase was reintroduced by J. Carpentier in 2022 based on the FCL version 0.7.0.

New features

Compared to the original FCL library, the main new features are:

• a dedicated and efficient implementation of the GJK algorithm (we do not rely anymore on libccd)
• the support of safety margins for collision detection
• an accelerated version of collision detection à la Nesterov, which leads to increased performances (up to a factor of 2). More details are available in this paper
• the computation of a lower bound of the distance between two objects when collision checking is performed, and no collision is found
• the implementation of Python bindings for easy code prototyping
• the support of height fields, capsule shapes, etc.
• the fix of various bugs

This project is now used in many robotics frameworks such as Pinocchio, an open-source software that implements efficient and versatile rigid body dynamics algorithms and the Humanoid Path Planner, an open-source software for Motion and Manipulation Planning.

A high-performance library

Unlike the original FCL library, HPP-FCL implements the well-established GJK algorithm and its variants for collision detection and distance computation. These implementations lead to state-of-the-art performances, as depicted by the figures below.

On the one hand, we have benchmarked HPP-FCL against major software alternatives of the state of the art:

1. the Bullet simulator,
2. the original FCL library (used in the Drake framework),
3. the libccd library (used in MuJoCo).

The results are depicted in the following figure, which notably shows that the accelerated variants of GJK largely outperform by a large margin (from 5x up to 15x times faster).

On the other hand, why do we care about dedicated collision detection solvers like GJK for the narrow phase? Why can't we simply formulate the collision detection problem as a quadratic problem and call an off-the-shelf optimization solver like ProxQP)? Here is why.

One can observe that GJK-based approaches largely outperform solutions based on classic optimization solvers (e.g., QP solver like ProxQP), notably for large geometries composed of tens or hundreds of vertices.

Acknowledgments

The development of HPP-FCL is actively supported by the Gepetto team @LAAS-CNRS, the Willow team @INRIA and, to some extend, Eureka Robotics.