Skip to content

Upgrade IrisInConfigurationSpace to IRIS-NP2 #21822

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

Open
RussTedrake opened this issue Aug 20, 2024 · 7 comments · May be fixed by #23001
Open

Upgrade IrisInConfigurationSpace to IRIS-NP2 #21822

RussTedrake opened this issue Aug 20, 2024 · 7 comments · May be fixed by #23001
Assignees
Labels
component: planning and control Optimization-based planning and control, and search- and sampling-based planning priority: medium type: feature request

Comments

@RussTedrake
Copy link
Contributor

In our latest paper submission, @cohnt , @rhjiang , and @wernerpe made major improvements to IRIS-NP (the algorithm currently implemented in IrisInConfigurationSpace). Regions can be computed order(s) of magnitude faster, they tend to be bigger, and tend to have less faces!

We should upgrade our Drake implementation to this latest version of the algorithm.

One question is whether we should make the new code use the CollisionChecker interface (#18830). My understanding is that there was one remaining sticking point, which was discussed in this slack thread.

@cohnt
Copy link
Contributor

cohnt commented Aug 20, 2024

Two quetsions from me...

  • Re CollisionChecker, does that provide sufficient information to solve the counterexample programs? Or would that be given in addition to the plant?
  • Do we want to replace IRIS-NP altogether, or does it make sense to keep the old version in for backwards-compatibility (and for replicating previous results)?

@RussTedrake
Copy link
Contributor Author

  • The goal would be to use CollisionChecker directly, instead of using MultibodyPlant. It is more general.
  • I think we should replace IRIS-NP altogether. Git remembers.

@cohnt
Copy link
Contributor

cohnt commented Aug 21, 2024

Extending IRIS-NP to support CollisionChecker seems somewhat orthogonal to upgrading to IRIS-NP2. A lot of the features that CollisionChecker supports need to be taken into account by the counterexample search programs. Negative padding seems particularly complicated to implement. Maybe we can keep these as separate TODOs?

@RussTedrake
Copy link
Contributor Author

My understanding is that @rhjiang already has a version that works, except not for the blocker discussed in the slack thread I linked above. If that's not the case, then i agree we can/should separate them.

@rhjiang
Copy link
Contributor

rhjiang commented Aug 21, 2024

The version I have uses CollisionChecker only for querying points in collision. Not sure I fully understand Tommy's comment, but, the version I have formulates the closest collision program the same way IRIS-NP did, not involving the CollisionChecker.

@RussTedrake
Copy link
Contributor Author

In that case, I'm ok deferring #18830. But I guess you construct the SceneGraphCollisionChecker inside the iris call? (the user doesn't have to pass it in?)

@RussTedrake
Copy link
Contributor Author

Plan is to not upgrade in place, but to make a new entry point (behind the new common interface from #21821).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: planning and control Optimization-based planning and control, and search- and sampling-based planning priority: medium type: feature request
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

3 participants