Clarification request: `franka_ik` relative-mode orientation semantics, gripper closure limit, and `cube_goal_pose` baseline

[shaoxiang]

Hi Arena team,

We're working on the cube_goal_pose task using the Docker evaluation setup and have run into a few controller/embodiment questions that we think are best answered by you. We have found a local workaround, but we'd like to confirm whether it aligns with the intended design.

1. franka_ik relative-mode orientation action semantics

The default franka_ik embodiment uses:

DifferentialInverseKinematicsActionCfg(
    command_type="pose",
    use_relative_mode=True,
    scale=0.5,
)

with a 7-D action [delta_pos_x, delta_pos_y, delta_pos_z, rot_x, rot_y, rot_z, gripper].

Observed behavior: after fixing an orientation sensor-reading bug on our side, we see that action[..., 3:6] does rotate the end-effector, but the mapping to world roll/pitch/yaw is heavily cross-coupled. In particular:

action axis	dominant observed world motion
rot_x	large yaw
rot_y	large multi-axis rotation
rot_z	large roll, almost no yaw

Questions:

• What is the exact mathematical interpretation of action[..., 3:6]? (quaternion delta, rotation vector, body-frame axis-angle, etc.)
• Is this cross-coupled response expected, or does it indicate a configuration mismatch?
• Is franka_ik relative mode intended to support clean world-yaw control for cube_goal_pose?

2. Absolute-pose mode as a workaround

We created a new franka_ik_abs embodiment with:

DifferentialInverseKinematicsActionCfg(
    command_type="pose",
    use_relative_mode=False,
    scale=1.0,
)

and an 8-D action [pos_x, pos_y, pos_z, quat_x, quat_y, quat_z, quat_w, gripper] in the robot base frame. With incremental quaternion targets, this gives us clean yaw authority and we can solve cube_goal_pose consistently.

Questions:

• Is adding a custom absolute-pose IK embodiment the recommended way to get orientation control?
• Is there an official franka_ik_abs-like embodiment we should use instead?
• Are absolute-pose commands expected to be expressed in the robot base frame (panda_link0) or the world frame?

3. Gripper closure limit

Observed behavior:

• Empty close reaches gripper_pos ≈ 0.00012.
• Cube-blocked close stops at gripper_pos ≈ 0.024 and cannot go lower.

Questions:

• Is 0.024 the expected joint value when fingers are blocked by a 0.05 m thick cube?
• Is gripper_pos defined as 0 = fully closed, 0.04 = fully open?
• How can we increase gripper closure force for long-duration holds?

4. Long-duration hold instability

After ~1600 steps of holding the cube, the object starts to slip/rotate inside the gripper even though gripper_pos remains at the blocked value (~0.024). Physics ablations (higher friction, smaller/lighter cube) did not eliminate it.

Questions:

• Is this a known limitation of the current gripper/contact model?
• Which parameter should be tuned first: gripper force limit, finger friction, object friction, solver iterations, or contact stiffness?

5. Task / success metric

For GoalPoseTask, success appears to require object_z ∈ [0.2, 1.0] and yaw error < 0.2 rad.

Questions:

• Does the task also require the object to be stationary for some duration?
• Is the target yaw π/2 measured in world frame or object frame?
• What are the exact values of success_threshold and orientation_threshold?

6. Object asset

dex_cube is not available in our Docker runtime; we fall back to procedural_cube with size (0.05, 0.1, 0.1) m and mass 0.2 kg.

Questions:

• Is the procedural fallback consistent with the intended dex_cube?
• What are the official dex_cube size, mass, inertia, and friction parameters?

Thanks!