Skip to content
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

Compute multiple contact points/contact surfaces #574

Merged

Conversation

lmontaut
Copy link
Contributor

@lmontaut lmontaut commented May 6, 2024

This solves #144 and #163, i.e. hpp::fcl::computeContactPatch(s1, tf1, s2, tf2, collision_result, patch_request, patch_result) now computes the intersection polygon between the collision pair (s1, tf1) and (s2, tf2), after hpp::fcl::collide(s1, tf1, s2, tf2, collision_request, collision_result) has been called on the collision pair.

The C++ code has been exposed to python.
Example using the python bindings:

    halfside = 0.5
    shape1 = hppfcl.Box(2 * halfside, 2 * halfside, 2 * halfside)
    shape2 = hppfcl.Box(2 * halfside, 2 * halfside, 2 * halfside)

    tf1 = hppfcl.Transform3f()
    tf2 = hppfcl.Transform3f()
    offset = 0.05
    tf2.setTranslation(np.array([0., 0., 2 * halfside - offset]))
    theta = np.pi / 4
    c = np.cos(theta)
    s = np.sin(theta)
    R = np.array([[c, -s, 0.0],
                  [s, c, 0.0],
                 [0, 0, 1.0]])
    tf1.setRotation(R)

    col_req = hppfcl.CollisionRequest()
    col_res = hppfcl.CollisionResult()
    hppfcl.collide(shape1, tf1, shape2, tf2, col_req, col_res)

    patch_req = hppfcl.ContactPatchRequest()
    patch_res = hppfcl.ContactPatchResult()
    hppfcl.computeContactPatch(shape1, tf1, shape2, tf2, col_res, patch_req, patch_res)

This script gives the following result (in purple, the points of the contact patch, in blue the contact patch normal):
Screenshot 2024-05-06 at 18 16 14

Todos:

  • Serialization of ContactPatch, ContactPatchRequest and ContactPatchResult

@lmontaut lmontaut requested review from jorisv and jcarpent May 6, 2024 14:46
@lmontaut lmontaut force-pushed the topic/multi-contact-points branch 2 times, most recently from ada0204 to d82f543 Compare May 11, 2024 17:36
@jcarpent jcarpent force-pushed the topic/multi-contact-points branch from 70554b6 to 1f55279 Compare May 14, 2024 09:50
This function is usefull to have in other tests.
- Comparison operators
- rename `insert` -> `addContactPoint`, `getSize` -> `size`,
  `getMaximumSize` -> `capacity`
- getter for i-th contact point
This is transferred to the `shape_shape_contact_patch.h` file.
This has multiple advantages: it makes the algos simpler to write, and most
importantly, it encodes the fact that points in a contact patch all live
on the same plane. This information is lost when using a 3D representation.
Multiple things:
- There is no reason not to store the GJKSolver cached result in QueryResult.
It's up to the QueryRequest to decide whether or not to retrieve this cached result.
This is why I made the cache fields of QueryRequest mutable, and removed the now useless
function signatures in collision.h and distance.h.
- Fixed cached result in GJKSolver: the result of EPA can be used to warm-start the next GJK.
These conflict with the way the python bindings have been done...
It's fine, these templated functions are not used right now and they are
only very simple helpers. If needed, we can create templated functors in the future
instead of templated functions; these won't cause conflict with python.
This has the effect of setting the base `max_size` of a ContactPatchRequest
to 12 instead of 6.
This is to make sure the box-box case is fully captured.
We only need the polygon representation, not the full support set.
…cases

The SH algo is super easy to understand; however we have to handle the
edge cases carefully. The edge cases are mainly due to degenerate cases
where we have segments and points instead of non-empty convex polygons.
If not handled properly, these edge cases induce redundancies in the
final polygon of SH. For example, if SH is ran on two triangles which
have only one common point, SH will return an intersection polygon
composed of 3 identical points (the common point of the triangles).

We detect these cases by using a tolerance when computing determinants.
This allows us to remove redundant points.
Also, we deal with the special case of the segment-polygon.
This flag needs to be present at the CMakeLists level, as Eigen
is present everywhere in hpp-fcl.
Important for physics simulation where we might want to know in advance
the maximum amount of contact points per contact pair.
HPP-FCL should simply compute the patch and let the user decide
 which point of the contact patch they want to keep.
@lmontaut lmontaut force-pushed the topic/multi-contact-points branch from 1f55279 to 54d242e Compare May 14, 2024 12:55
@jcarpent jcarpent merged commit ca4b94d into humanoid-path-planner:devel May 14, 2024
28 of 34 checks passed
@lmontaut lmontaut deleted the topic/multi-contact-points branch May 15, 2024 05:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants