-
Notifications
You must be signed in to change notification settings - Fork 426
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
TRI is considering investing in FCL development #97
Comments
This is excellent news! |
Yeah, it's great news! I'm glad to hear that FCL is going to have more development support.
I agree. Here is a short list from my experience and other's feedback:
There would be more items I can't come up with at this moment. I can help writing unit tests that reproduce the issues. |
Excellent news indeed! I am more of a user than a developer of FCL. On the motion planning front, sampling-based planners could probably do more with the information that FCL can provide (such as penetration depth / separation distance or vector to closest point). It might also be good to send emails to key researchers (Jia Pan @panjia1983, Dinesh Manocha, others?) who were/are involved in developing the algorithms behind FCL to make sure that FCL continues to be a library of state-of-the-art collision detection algorithms. |
Hmmm ... I still can't see teams. Could be a delay, or maybe I have to be a member of the organization? Would you mind adding me to a team? |
That's odd, it should be visible (I checked again just now). In any case, I On Fri, Mar 18, 2016 at 10:16 PM, Michael Sherman [email protected]
|
Thanks, Ioan -- that worked. |
My team and myself use fcl for path planning. A while ago we forked our own branch (https://github.com/humanoid-path-planner/hpp-fcl) to develop features that require to modify many interfaces. As the project was not very active at that time, we did not submit any pull request. The main modifications are the following
Point 1 is required for dynamic collision checking along paths and costs a negligible overhead in terms of computation, compared to computing exact distance. I think it is a good idea to take fcl as a basis for an open-source project supported by TRI. It could be an opportunity for us to merge our modifications. However, I would start the TODO list by
|
Hello, Regarding the contact point computation, we found the same issue to occur when colliding objects of different types, which results from the fact that methods are found in a diagonal look up table, which sometimes require inverting parameters (though the Collision results do not take this inversion into account). Our quick and dirty fix is here (our objective was to have a minimal impact of the code, Similarly the triangle ids resulting from a collision with an octree were wrong: |
Thanks Michael for asking. I can not speak from the perspective of an user or developer. From my perspective as the Debian/Ubuntu maintainer would be nice:
Ubuntu has recently change the policy to introduce changes in already released distributions, it is called microreleases. The changes I'm proposing above will help to maintain If the software is designed to be multi-platform, it would be good to implement CI also in Windows and Mac. |
@j-rivero, did you mean fcl or libccd above? |
Sorry I meant fcl, yes. Although the comments can be applied for both. |
+1 for merging changes from https://github.com/humanoid-path-planner/hpp-fcl and for removing the articulated model part. |
@sherm1 I agree FCL is an excellent base, and have also found that its contact location and vectors are inconsistent for various shape pairs. A general contact solution is needed, in my opinion, for robust simulation. My thought is to define the contact location to be the centroid of the overlaping shape, the orientation to be the plane normal to its major and minor axes, and the length to be proportional to the overlap volume. A fast general solution may be possible using this library, https://www.math.ucdavis.edu/~latte/ , which "has the ability to directly compute integrals of polynomial functions over polytopes and in particular to do exact volume computations"; in plain language, given a faceted 3-D shape, the library may efficiently calculate its centroid, axes, and volume. Analytic shapes could be even faster, and offer an interesting research project to develop formulas for each pair of shapes. cc/ @jslee02 , @stonneau |
@gdbadw -- characterization of the overlap volume would be great and would allow use of volumetric contact models like those from John McPhee's group at Waterloo. I'm not sure that can be done practically though. Latte looks cool but I don't think it could work here -- the limitation to convex polytopes might be solvable by decomposition but the viral GPL license is a fatal flaw! I'll add in Evan Drumwright @edrumwri in case he has a comment about this. |
@sherm1, I've been using a volumetric description of the intersecting geometries in Moby for convex polyhedra. One nice thing about this is that the volume is also convex, so point samples represent the intersection completely. I can show at least one compelling example where characterizing the volume is useful (perhaps necessary) for constraint stabilization between convex polyhedra in multi-body simulations. For generic shapes, even defining an API will be challenging. And I'm unaware of an example where such a volumetric representation is useful for two spheres contacting in multi-body simulations. I'll claim that the determination of whether a volumetric intersection for specific pairs of geometries is useful for such simulations is an open problem. |
@sherm1 - Interesting research you reference. In accordance with McPhee's method, each localized contact is characterized as one vector with position. A generalized approach to this characterization, while only partially supported by his limited experiments, would facilitate robust simulation independent of object shape. However, Bullet Collision and FCL [ and Moby ?] often represent localized impacts as multiple vectors (box on box for example). Localized impact forces of course resolve into a single differentiable vector, so why shouldn't this resolution originate with a single differentiable collision vector based on a reasonable general geometric theory? cc/ @edrumwri |
The answer to the question I think you're asking, @gdbaldw, is that a single point of contact is generally insufficient to prevent interpenetration even though equipollent forces/impulses at the two centers of mass can be found that correspond to forces/impulses applied at multiple contact points. The exception is that if the objects are contacting at their centers-of-mass. |
@edrumwri - Interpenetration is fundamental to McPhee's method, with each impact force "expressed in terms of the volume of interference between the undeformed geometries", independent of mass distribution and for each interference/interpenetration. At the instant two objects touch and share just one point, the calculated impact force is zero. As an extension, I ask if it reasonable that the direction and location for each of McPhee's impact forces also be expressed in terms of its interpenetration geometry, perhaps characterized as centroid and major and minor axes. Ideally we'd have a generalized approach to calculate a differentiable collision vector with position for each interpenetration, useful for calculating each differentiable impact vector, resulting in robust simulation. |
@gdbaldw, the volumetric contact model from McPhee's lab does make use of the volume, centroid, and geometric inertia of the overlap volume although that might not be clear from the Boos 2010 reference which was mostly about validation I think. Gonthier's 2007 thesis is probably a better place to look. Here's a quote from pg 53:
|
@sherm1 - Excellent! One might hope that Gonthier's 2007 mathematical formulation has already been instantiated for simple analytical shapes into a library useful to FCL, which could then be validated against/correlated with experiments using a general multibody solver, followed by validation of a faceted model implementation (e.g. ico-sphere vs analytic sphere). |
Yeah, one could hope! But when I asked about it I was told by McPhee lab ex-pats that it is an extremely difficult calculation except for the simplest of shapes. There is apparently a Canadian company that offers a GPU-implemented numerical method for calculating the necessary volumes but they are doing it by sampling so probably can't deliver smooth derivatives. @edrumwri, how are you able to do it? |
Any plans to fix Question: mesh and box collision check? #78? |
Have you guys looked at the Bullet collision implementation? I switched to that instead of FCL since I have the issue with ignored collision when an object is within a mesh, |
What does Bullet do in that case? Are you looking for just yes/no collision info or penetration depth? |
@stonneau, you mentioned what sound like some important bug fixes in the hpp fork:
Are there issues describing these problems, and if not do you want to open some? You said you're not satisfied with the first fix but how about the second one? If that's good do you want to submit a PR for it? Is there a test case that you could add that would show the problem and verify the fix? |
Adding Dinesh Manocha to this thread in case he wants to add anything. Sorry, there has already been a lot going on here, Dinesh! /cc @manocha1 |
Thanks for all the feedback on FCL. The input provided by different folks is very useful and we should all work together to extend the capabilities of FCL in terms of contact point computations, penetration depth (esp. global PD computations) and supporting higher order analytic shape representations. |
I'm currently just looking for yes/no collision and bullet reports that. Cheers, Michael
|
@sherm1 and raised an issue for the first one. Three others modifications of fcl were performed in hpp-fcl, as mentionned by @florent-lamiraux: These modifications are less trivial that the previous one, because they required a significant modification of the code. We would like to integrate them to fcl (at least the first 2 points), which would allow us to use fcl in our projects rather than our fork. However, since this require significant work from us, we need confirmation that the fcl leaders are actually interested in those, and that they will be indeed included. Thanks Steve |
Not sure if I count as an fcl leader, but these sound like very useful additions. |
Hi @sherm1 , do you have any information about the progress of the high-performance open source collision library by TRI. Thank you! |
@mirsking: we have just recently added staff for computational geometry so are really just getting started on this now. We have been working on FCL integration but not yet on new code for it except for some minor build things. Adding @SeanCurtis-TRI to this thread -- Sean is our main go-to person for computational geometry. |
Hello @sherm1, @SeanCurtis-TRI, I'm curious to know about the status of the development interest now that we're a couple years down the line. Has much development happened and are there plans for further development? Thanks! |
Best laid plans of mice and men... Lots of distractions. The intent is very much to do so. And we've got a couple of patches that need vetting to release into the wild. Things should begin to accelerate in the next few months. |
in the end did you backport any of the modifications you previously mentioned from Thanks!
|
@arocchi |
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:
Thanks and regards,
Sherm
/cc @hsu, @scpeters, @jslee02, @panjia1983, @isucan, @j-rivero, @mfelis, @mamoll
The text was updated successfully, but these errors were encountered: