As a simple example, let’s say I had an iiwa manipulator asset, and I wanted to place both of these arms on same table.
/World
|
– /Table
|
– /iiwa1 ← articulation root here
|
– /iiwa2 ← articulation root here
If I create fixed joints between the base of both iiwa arms and the table, and I have articulation roots at the base of each iiwa arm, then one of the articulation roots is ignored and I get this error: “Failed to refresh articulation /World/iiwa2”.
I want to avoid removing the articulation roots from the arms and putting it on the table xform. This is because isaac sim will then complain about having duplicate joint names (since the robot models are identical except for the top level name).
How can I go about having two articulation roots in this scenario? Or if this is not feasible, how can I approaching rigging in such a way that when I import my manipulators, I do not have to remove the articulation root from it or have to rename any joints within it.
A while ago, I discovered that you can create “fixed joints” between the table and the base_link of the robot arms that can be “excluded from the articulation”. In order to get Isaac Sim to recognize both articulation roots on the arms, you have to select to exclude from articulation for these “fixed joints”. I have quotes here because while the these fixed joints are connecting the table and the arm, when you exclude them from the articulation, they become a maximal coordinate joint as specified here:
Excluding joint from articulation causes some issue - Omniverse / Isaac Sim - NVIDIA Developer Forums
It is not ideal, but it seems to be doing the job for now. The original question still stands though with the constraint of having a true fixed joint between the arm and the table.
@alex.perez1 - your discovery is correct, you need an exclude from articulation flag on the fixed joint between arm base and table. But that will create a floating-base arm that is connected to the table through additional constraints in the solver, which is not ideal as you may have found.
I assume that the table is static and not a dynamic object in the simulation. If that assumption is correct, what I would do if I were you is to add the articulation roots to the fixed joints and make the fixed joints connect the arm base to world, i.e. leave the body rel empty. That will create two fixed-base articulations that will simulate more efficiently and stably.
So, in my prompt, I used a static table for simplicity. However, in my actual implementation, the “table” is a vehicle which is a dynamic object. @philipp.reist, how would this change your approach?
If the table is dynamic, the excluded fixed joints are the solution indeed. If you see simulation issues, I would try reducing the time step size and/or increasing position solver iterations.