Lula RRT: Support for orientation targets and mesh collision avoidance

Omniverse Isaac Sim
1

Hello Team,

We wish to use the Isaac Motion Planning interface, specifically the Lula RRT motion planning feature in Isaac 2022.2
However, there are two key features currently missing:

  1. The ability to use task-space orientations. Currently, the Lula RRT only considers task-space positions and not orientations.
  2. The ability to avoid collisions with arbitrary meshes. Currently, the planner only avoids collisions with primitive types, such as cubes and spheres, not meshes.

When do you think these functionalities will be added? Will they be available in the next release?

2

Hi Snehal,

While we’re planning to add both features in the future, they are not currently planned for the next release. The earliest they might be available is late this year.

3

Hello team,

In that case, is it currently possible to use the LulaIK solver in a collision-aware manner?

We need some fast, collision-free behaviour from the robot. Just an IK solution is also enough for us but we need it to be collision-aware

Regards,
Snehal Jauhri

5

Hi Snehal,

We don’t provide collision-aware IK out of the box, unfortunately. One option would be to use RMPflow to roll out a trajectory to your desired end-effector pose.

If your robot happens to be 6-DOF, another might be to implement your own collision-aware IK by:

  1. solving IK starting from a random set of 100-1000 seeds uniformly distributed in c-space.
  2. filtering the resulting solutions for uniqueness (e.g., by looking at L2 distance between solutions in c-space).
  3. rejecting solutions that are in collision. To do this, you’d have to manually loop through the collision spheres representing the robot and call WorldView.in_collision() for each. See API doc here.

A similar approach might work even if your robot is 7-DOF, but since the space of solutions is continuous, I fear that step (1) wouldn’t do a good job of sampling the space.

My suggestion would be to try RMPflow first, since that should be easiest. Note that after rolling out a trajectory with RMPflow, you could discard the time information and just use the resulting path in the same way you might use a (smoothed, densely-sampled) path from RRT.