Changing meters per unit breaks PhysX

Please provide all relevant details below before submitting your post. This will help the community provide more accurate and timely assistance. After submitting, you can check the appropriate boxes. Remember, you can always edit your post later to include additional information if needed.

Isaac Sim Version

4.5.0
4.2.0
4.1.0
4.0.0
4.5.0
2023.1.1
2023.1.0-hotfix.1
Other (please specify):

Operating System

Ubuntu 22.04
Ubuntu 20.04
Windows 11
Windows 10
Other (please specify):

GPU Information

  • Model: RTX 4090 Mobile
  • Driver Version: 570.133.07

Topic Description

Detailed Description

I am not sure this is a bug, but this is something I noticed while I was playing with some URDF imports using Isaac Sim. I am importing some URDF files using the URDF Importer extension v2.3.10 and I’d like to use millimeters for the ā€œmeters per unitā€ setting.

The following screen recording shows the change in robot when I change the ā€œmeters per unitā€ setting of the current stage.

Why do I need to change ā€œmeters per unitā€? I am developing an Omniverse-based app which needs to use millimeter for the ā€œmeters per unitā€ setting. I’d like to use the USD files imported from URDFs. I did some quick testing by changing the units under Isaac Sim settings, but since URDF is using meters as default units, the USD file is also generated in meters. The metrics assembler extension fixes the visual issues and automatically scales and rotates the robot when the robot is added to the scene, but looks like I need some additional work for the PhysX side.

I’d really appreciate any suggestions here.

Steps to Reproduce

I cannot share the URDF files I am using due to NDAs.

Error Messages

No error messages.

Do you notice any error messages? Could you provide the logs?

I don’t see any error messages on the console. Logs are attached below.

isaac-sim.log (50.1 KB)

For the session with the logs shared above, I used the same robot shown on the screen capture, of my first post which was already converted to USD from URDF using the URDF importer (the details are on my first post) and added the robot to the scene as a payload. First, I used 1.0 ā€œmeters per unitā€ setting, pressed play button, waited a couple of seconds. Then, I switched to 0.001 ā€œmeters per unitā€ setting and repeated the steps. I can also share a sample of the URDF file too

  <link name="link_3">
    <visual>
      <origin xyz="0.0 0.0 -0.2" rpy="1.5708 3.14 1.5708"/>
      <geometry>
        <mesh filename="./meshes/visual/link_3.STL"/>
      </geometry>
    </visual>
    <inertial>
    <mass value="5.0"/>
    <inertia
      ixx="0.01" ixy="0.0" ixz="0.0"
      iyy="0.01" iyz="0.0"
      izz="0.01"/>
    </inertial>
    <collision>
      <geometry>
        <cylinder length="1.7" radius="0.2"/>
      </geometry>
      <origin xyz="0.0 0.0 0.0" rpy="1.57 0 0.0"/>
    </collision>
  </link>

  <link name="link_4">
    <visual>
      <origin xyz="0.0 0.0 0.0" rpy="0.0 1.5708 -1.5708"/>
      <geometry>
        <mesh filename="./meshes/visual/link_4.STL"/>
      </geometry>
    </visual>
    <inertial>
    <mass value="5.0"/>
    <inertia
      ixx="0.01" ixy="0.0" ixz="0.0"
      iyy="0.01" iyz="0.0"
      izz="0.01"/>
    </inertial>
    <collision>
      <geometry>
        <cylinder length="0.05" radius="0.2"/>
      </geometry>
      <origin xyz="0 0 0.0" rpy="0 0 0.0"/>
    </collision>
  </link>

  <joint name="joint_4" type="revolute">
    <parent link="link_3"/>
    <child link="link_4"/>
    <origin xyz="0.0 0.0 0.0" rpy="0.0 1.5708 0.0"/>
    <axis xyz="0 0 1"/>
    <limit lower="-6.2832" upper="6.2632" effort="8800" velocity="1.2217"/>
  </joint>

I also have another URDF file for a rail assembly. In this case, the URDF file has 1 prismatic joint. The above robot and the rail load and work perfectly on RViz2, which I use to verify URDF files and the joint motion.

Let me share the screen recording for the rail assembly first.

and the logs are attached. The logs also include the URDF import of the rail assembly whereas the screen recording does not.

isaac-sim-2.log (51.0 KB)

The screen capture illustrates the change of ā€œmeters per unitā€ from 1.0 to 0.001 and shows the unexpected movement on the prismatic joint. While keeping ā€œmeters per unitā€ at 0.001, I move the ground plane on the negative Z axis and that seems to fix the unexpected joint movement issue. This issue does not exist when ā€œmeters per unitā€ is set to 1.0.

For the URDF import, I select ā€œCreate collisions from visualsā€ and convex decomposition options.

Edit: It looks like changing the contact and rest offset of the collider on the GroundPlane/CollisionPlane fixes this issue. Attached is the screenshot for the illustration of what needs to be updated.

I am not sure this would make any change to the robot on the first post.

@VickNV did you have a chance to take a look at the logs and partial URDF file I shared?

Hi @ml-thousandlakes, changing meters per unit is not a well supported feature in Isaac Sim at the moment and this is a bug we are working on. For our understanding of user needs, can you elaborate more on the need to specify other units of measurement? Would you be able to convert measurements to meters before setting them?

Hi @michalin,

I solved it by using a single linear unit, in this case meters, in all USD files I am referencing.

I don’t think this is particularly an Isaac Sim problem. I am working on an Omniverse app with has stage linear units set to millimeters. CAD and URDF imports are in meters. Using millimeters is a convenience for me as the users use millimeters on the physical system they are using. After converting the app to use meters, all the linear units are shown in meters in the app, and I had to develop additional UIs to help users use millimeters directly.

It is generally not a problem to divide by 1000 to get to the millimeters, but it is the convenience, especially when you are working on something else and typing to somewhere else. I hoped that the metrics assembler and its physics extensions would handle what I was trying to achieve, but it didn’t work.

That is great you found a solution! We are tracking this error for future references, but there is a chance the team chooses to not support non-SI scales. I will close the issue for now, but feel free to make a new post if you encounter other issues.