[Question] Reliability of get_link_incoming_joint_force()

[tkrish475]

Question

I'm using the PhysX articulation API to simulate a 6-DOF wrist force/torque sensor on a Franka Panda by reading the incoming joint force at the panda_hand link (child of panda_joint7). The goal is to correctly (as much as possible) to measure the external Force/Torque data as this seems to be an only alternative to reproduce an out of the box F/T sensor in isaaclab. The way it is obtained is:

joint_forces = self._robot.root_physx_view.get_link_incoming_joint_force()
wrist_ft = joint_forces[:, self._body_idx, :]  # (num_envs, 6)
force  = wrist_ft[:, 0:3]
torque = wrist_ft[:, 3:6]

I'd like to confirm whether this approach is reliable and correctly implemented.

Build Info

Describe the versions that you are currently using:

• Isaac Lab Version: [2.3.0]
• Isaac Sim Version: [5.1]

[RandomOakForest]

Thank you for your post. Your approach is conceptually the right way to emulate a 6‑DOF wrist F/T sensor in Isaac Lab today, but there are a few important caveats and checks you should apply to make it as reliable as possible.¹²³

What get_link_incoming_joint_force gives you

In PhysX, the “link incoming joint force” is the 6D spatial wrench transmitted by the joint from the parent link to the child link, expressed at the child link frame. Isaac Sim/Isaac Lab expose exactly this via the ArticulationView / PhysX tensor APIs, and the joint-force sensor docs explicitly say that the measured joint forces correspond to link incoming joint forces.²³⁴¹

So the tensor from:

joint_forces = self._robot.root_physx_view.get_link_incoming_joint_force()
wrist_ft = joint_forces[:, self._body_idx, :]  # (num_envs, 6)
force  = wrist_ft[:, 0:3]
torque = wrist_ft[:, 3:6]

is indeed a 6‑D wrench on that link, and using the link that immediately precedes your “sensor” (here, panda_hand as child of panda_joint7) is the standard way to mimic a wrist F/T sensor.³²

Key limitations vs a real F/T sensor

There are two big differences from an ideal physical sensor:

• Internal vs external contributions
  The reported wrench is the total joint wrench: actuator efforts, gravity, Coriolis, inertial terms, contacts, etc., all summed together. A real F/T sensor bolted in the chain also measures the net wrench, so this is physically consistent, but if you want only “external” contact forces you must subtract model-based internal terms (gravity, dynamics) yourself.⁴²
• Frame and sign conventions
  The wrench is in the child link frame with PhysX conventions (spatial vector $[f_x, f_y, f_z, \tau_x, \tau_y, \tau_z]$). You must ensure:¹⁴
  • Your _body_idx is the correct link index for panda_hand in the underlying ArticulationView.
  • Any transformation to another frame (e.g., tool frame) uses the correct rotation/position and preserves the spatial-vector form.

Practical checks to validate reliability

To build confidence that the values behave like a real wrist F/T sensor:

1. Static gravity check
   • Hold the arm in a fixed configuration, no contacts, zero commanded joint efforts.
   • Compute the expected wrench at panda_hand due to gravity (using your dynamics library or a simple mass–COM approximation) and compare against wrist_ft. They should match in direction and approximate magnitude.⁴¹
2. Known test loads
   • Attach a small rigid “tool” to panda_hand and apply a known external force at a known offset using apply_force_at_pos (or equivalent) on the end link.
   • Transform that known wrench to the panda_hand frame and verify the difference in wrist_ft with/without the force matches the expected wrench.¹⁴
3. No-contact sanity
   • With no contacts and the robot disabled (no drive efforts), the measured wrench should correspond primarily to gravity and inertial terms; in quasi-static poses the force should be nearly constant and torques should follow what you’d expect from COM offset.⁴¹
4. Numerical noise and step size
   • At small time steps and with stiff drives, articulation wrenches can be noisy; if you see high-frequency jitter, low-pass filter wrist_ft similarly to how hardware F/T sensors are filtered.²³

Implementation details specific to Isaac Lab 2.3 / Isaac Sim 5.1

• API choice
  In Isaac Sim, the “articulation joint sensors” docs explicitly recommend using the tensor API that returns 6‑D spatial forces to mimic F/T sensors, especially when attached to a fixed joint. Isaac Lab 2.3 wraps this via root_physx_view.get_link_incoming_joint_force(), so your call matches the recommended pattern.⁵³²
• Indexing
  Ensure _body_idx is derived from the underlying ArticulationView, e.g. via get_link_index("panda_hand"), and not from a USD or other ordering, which can differ. A quick debug print of all link names vs indices from the articulation view is worth doing once.³²
• “FT sensor via fixed joint” trick
  If you want a more “sensor-like” separation, you can insert an extra fixed joint between panda_hand and a new “sensor” link and read the incoming force at that joint, as suggested in the Isaac Sim articulation sensor docs; this matches how converted MuJoCo models emulate F/T sensors.⁶²³

Recommendations

• Your code pattern is correct for approximating a 6‑D wrist F/T sensor at panda_hand in Isaac Lab 2.3 / Isaac Sim 5.1.²³¹
• For best “physical” fidelity:
  • Validate with the static and known-load tests above.
  • Document clearly that this is net joint wrench, not “pure external contact force”.
  • Optionally, build a small dynamics-based estimator to subtract modeled internal terms if you need “external-only” forces.

Footnotes

1. https://nvidia-omniverse.github.io/PhysX/physx/5.5.0/docs/Articulations.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. https://docs.isaacsim.omniverse.nvidia.com/5.1.0/sensors/isaacsim_sensors_physics_articulation_force.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

3. https://docs.isaacsim.omniverse.nvidia.com/4.2.0/features/sensors_simulation/isaac_sim_sensors_physics_articulation_force.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

4. https://nvidia-omniverse.github.io/PhysX/physx/5.1.3/docs/Articulations.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

5. https://isaac-sim.github.io/IsaacLab/main/source/setup/quickstart.html ↩

6. https://github.com/isaac-sim/IsaacLab/issues/1725 ↩

[RandomOakForest]

Following up, it seems this issue may have been resolved. I will close this post for now. Let us know if you need further help.