System Info
- OS: Ubuntu 22.04.5 LTS
- Python: 3.14.7 (uv venv)
- Isaac Sim: 6.0.1-rc.7 (PhysX and Newton) and 5.1
- isaacsim-mcp-server: 0.6.1
- GPU: NVIDIA GeForce RTX 3090, Driver 580.173.02
Component
Scene Management Tools
Reproduction
get_prim_info returns transform.position in the prim's parent frame, but
neither the tool description nor the response says so. For a prim under a
transformed parent the number is not where the object is.
# build a child at local (0.25, 0, 0) under a parent at (1, 2, 0.5)
import omni.usd
from pxr import Gf, UsdGeom
stage = omni.usd.get_context().get_stage()
parent = UsdGeom.Xform.Define(stage, "/World/FrameProbe")
UsdGeom.Xformable(parent).AddTranslateOp().Set(Gf.Vec3d(1.0, 2.0, 0.5))
child = UsdGeom.Cube.Define(stage, "/World/FrameProbe/Child")
child.GetSizeAttr().Set(1.0)
cx = UsdGeom.Xformable(child)
cx.AddTranslateOp().Set(Gf.Vec3d(0.25, 0.0, 0.0))
cx.AddScaleOp().Set(Gf.Vec3f(0.1, 0.1, 0.1))
get_prim_info(prim_path="/World/FrameProbe/Child")
Reproduces every time: 9 attempts, 9 reproductions, three per runtime:
| Runtime |
Attempts |
Reproduced |
| 5.1 (V5 adapter) |
3 |
3 |
| 6.0.1-rc.7 PhysX (V6) |
3 |
3 |
| 6.0.1-rc.7 Newton (V6) |
3 |
3 |
Expected behavior
Either a world position, or a documented statement that the position is local
(ideally a position_frame field, matching how position_source already labels
joint and Newton position reads).
Actual behavior
get_prim_info position : [0.25, 0.0, 0.0]
world would be [1.25, 2.0, 0.5]
read_transform in adapters/transforms.py uses the local matrix:
matrix = xformable.GetLocalTransformation()
translation = matrix.ExtractTranslation()
The tool description documents the rotation convention in detail ("rotation
[rx, ry, rz] in degrees (XYZ order, the same convention transform_object
accepts)") and the actual_size semantics, but says nothing about the frame of
position.
Additional context
Two things make this easy to walk into.
actual_size in the same response is world-scale-aware, and
get_prim_actual_size documents its bbox as world-space, so one response mixes
a local position with world-space size.
The tools that make nested prims are the ones where it bites: a robot's links
are addressed as /World/Franka/fr3_hand_tcp. Isaac's FR3 USD happens to be a
flat hierarchy rooted at the articulation, so if the robot is created at the
origin — the default — local and world coincide and the tool looks correct. Put
the robot anywhere else and the same call silently returns base-relative
coordinates. I read an end-effector position this way while debugging a grasp
and started reasoning from it before noticing.
Worth noting the neighbouring behaviour is good: on Newton, a rigid body under
the same parent returned position_source="usd" together with a
position_warning explaining the value was the authored pose. That labelling is
exactly what is missing here — the frame just needs the same treatment.
System Info
Component
Scene Management Tools
Reproduction
get_prim_inforeturnstransform.positionin the prim's parent frame, butneither the tool description nor the response says so. For a prim under a
transformed parent the number is not where the object is.
Reproduces every time: 9 attempts, 9 reproductions, three per runtime:
Expected behavior
Either a world position, or a documented statement that the position is local
(ideally a
position_framefield, matching howposition_sourcealready labelsjoint and Newton position reads).
Actual behavior
read_transforminadapters/transforms.pyuses the local matrix:The tool description documents the rotation convention in detail ("rotation
[rx, ry, rz] in degrees (XYZ order, the same convention transform_object
accepts)") and the
actual_sizesemantics, but says nothing about the frame ofposition.Additional context
Two things make this easy to walk into.
actual_sizein the same response is world-scale-aware, andget_prim_actual_sizedocuments its bbox as world-space, so one response mixesa local position with world-space size.
The tools that make nested prims are the ones where it bites: a robot's links
are addressed as
/World/Franka/fr3_hand_tcp. Isaac's FR3 USD happens to be aflat hierarchy rooted at the articulation, so if the robot is created at the
origin — the default — local and world coincide and the tool looks correct. Put
the robot anywhere else and the same call silently returns base-relative
coordinates. I read an end-effector position this way while debugging a grasp
and started reasoning from it before noticing.
Worth noting the neighbouring behaviour is good: on Newton, a rigid body under
the same parent returned
position_source="usd"together with aposition_warningexplaining the value was the authored pose. That labelling isexactly what is missing here — the frame just needs the same treatment.