[Question] FORGE Implementation and Performance

[franka2024]

Hi,

I have been playing around with the existing FORGE implementation in Isaac Lab for some time and I had a few questions about its implementation and its behavior that I was hoping someone could help answer. I also intend on deploying the agent onto a real robot. Here are my questions:

1. How do external forces in simulation compare to the ones obtained from the real franka robot (in other words which franka robot state property from the franka API corresponds to the get_link_incoming_joint_force()[..] method used in the simulation code?
2. In the null-space regulator in simulation, q* seems to be fixed? How is this feasible when the robot attempts to perform insertion from different joint poses?
3. During simulation I always notice that the robot continues to rotate the peg even after it is fully inserted. Why does this occur? Is it because the agent has not predicted a termination action yet?

Your help would be greatly appreciated!

[RandomOakForest]

Thank you for posting these questions. This post is a great conversation for our Discussions section. I'll move it there for follow up. Here is a summary to consider though.

Simulation vs Real Franka: External Forces

In Isaac Lab's simulation, the method get_link_incoming_joint_force() retrieves the forces or torques acting on a joint, typically at the interface where the environment interacts with the robot’s links (for example, the force felt at the end-effector due to contact) .

For a physical Franka Emika Panda robot (using libfranka's RobotState), the most relevant property corresponding to incoming joint forces is:

• tau_J — measured torque at each joint, caused by external and internal effects
• tau_ext_hat_filtered — the torque inferred as being exerted by external contacts, which is probably what you seek as the equivalent to “external force” in simulation

Thus, the Isaac Lab simulation’s get_link_incoming_joint_force() values most closely match tau_ext_hat_filtered from the Franka API, as both represent estimates of externally applied efforts at the joints .

Note that the method get_link_incoming_joint_force is not part of the high-level Isaac Lab public API, but it is a function available through Isaac Lab's underlying PhysX integration, accessible via the root_physx_view for articulated assets (such as robot arms) in simulation. It can be used internally within custom Isaac Lab or Isaac Sim code, particularly when working directly with physics tensors or simulation state at a low level.

Null-Space Regulator: Constant q* Feasibility

In Isaac Lab, the null-space regulator (which keeps the robot away from singularities or joint limits using a secondary objective) typically uses a fixed reference configuration for q* (desired joint positions for null-space control) .

This is feasible for simulation benchmarks where trials often start from a standardized initial configuration. If the robot starts from a different joint position (e.g., for randomization or domain transfer), a fixed q* may cause the controller to bias the robot back toward that fixed pose, regardless of task requirements.

• For real-world deployment, dynamically update q* to match the initial pose before each insertion episode, or set q* to the starting pose for each run. This ensures the null-space goal is consistent with the current context .

Persistent Peg Rotation After Insertion

The continued peg rotation after full insertion is expected behavior in current FORGE implementations and is a consequence of both the policy and how episode terminations are handled .

• In simulation, the agent rotates because it has not yet predicted a termination (i.e., a “done” signal or a stop action), often due to sparse or delayed rewards.
• If termination conditions are not set or if the agent learns to maximize reward by continuing rotation (possibly due to reward structure), the behavior persists .

Action: Ensure the environment provides timely and accurate termination signals—for example, an explicit check for insertion success. Adjust reward shaping or add early termination criteria on successful insertion to mitigate this behavior for both sim2real transfer and realistic evaluation.