I previously asked about modeling a 2-finger gripper as a 1-DOF system in Drake:
How to make a gripper with two fingers (2DOF) have 1 DOF making one finger symmetric to the other.

My gripper had two fingers (each with a prismatic joint) and I wanted to represent it as a 1-DOF system in Drake. The answer provided indicated to use the <mimic> tag in an SDF file to achieve this. However, this approach does not reduce the num_positions() in the plant, meaning both finger joints are still considered in the configuration space.

Now, I am working with C-IRIS to generate convex polytopes and need to ensure that the gripper fingers are treated as having only 1 DOF in configuration space while still considering collisions correctly.

The right finger is not an independent variable and should move symmetrically to the left finger. C-IRIS should account for collisions involving the right finger, even though it is not explicitly controlled.

How can I make C-IRIS ignore the redundant DOF when computing convex polytopes?

At the same time:

How can I ensure that collisions involving the right finger are still considered, even though it follows the left finger's motion?

Any guidance on handling this in Drake would be greatly appreciated!

I am using the python bindings with Pydrake version 1.35.0

I previously asked about modeling a 2-finger gripper as a 1-DOF system in Drake:
How to make a gripper with two fingers (2DOF) have 1 DOF making one finger symmetric to the other.

My gripper had two fingers (each with a prismatic joint) and I wanted to represent it as a 1-DOF system in Drake. The answer provided indicated to use the <mimic> tag in an SDF file to achieve this. However, this approach does not reduce the num_positions() in the plant, meaning both finger joints are still considered in the configuration space.

Now, I am working with C-IRIS to generate convex polytopes and need to ensure that the gripper fingers are treated as having only 1 DOF in configuration space while still considering collisions correctly.

The right finger is not an independent variable and should move symmetrically to the left finger. C-IRIS should account for collisions involving the right finger, even though it is not explicitly controlled.

How can I make C-IRIS ignore the redundant DOF when computing convex polytopes?

At the same time:

How can I ensure that collisions involving the right finger are still considered, even though it follows the left finger's motion?

Any guidance on handling this in Drake would be greatly appreciated!

I am using the python bindings with Pydrake version 1.35.0

• python
• drake

• We discuss a similar problem here: stackoverflow/a/78799095 I don't think we'll be able to make C-IRIS support the "subspace" machinery that allows us to grow regions in minimal coordinates, but you could still grow regions in the full configuration space and then intersect with the subspace where the two joints match each other. – Thomas Cohn Commented Mar 18 at 15:28

1 Answer 1

It is doable inside C-IRIS (well, not out-of-the-box).

What C-IRIS does is that it certifies the following problem

∀s ∈ {s | C*s <= d}, ∃ a(s), b(s), such that the separating plane a(s) * x + b(s) = 0 separates the geometries A and B in the Cartesian space.

Normally we search for the parameter C and d in the polytope {s | C*s <= d}. In your case, you want to say that your s variable also live in a subspace (specifically, to enforce symmetry of the joints, you probably want s_left + s_right = 0, which are two additional rows in the constraint C * s <= d). And then you can ask whether this polytope {s | C*s <= d} (which includes the constraint s_left + s_right = 0 ) is collision free (for example, using FindSeparationCertificateGivenPolytope ). So given a polytope C * s <= d (which lives in the subspace s_left+s_right=0 ), you can query the no-collision certificate.

Searching for C and d is harder, as now you need to impose the additional constraint on C and d, such that it includes s_left + s_right <= 0 and -s_left - s_right <= 0. You could call InitializePolytopeSearchProgram and then impose additional constraints on C and d (for example, some entries in C needs to be 1 or -1, some corresponding entries in d need to be 0). And then solve the returned optimization problem with the right objective function. You can refer to FindPolytopeGivenLagrangian function in cspace_free_polytope for an implementation.