Clarification on OSC Pose Controller Behavior

[TibvG]

Hi IsaacLab team,

I'm currently working with the OSC Pose controller but am encountering some unexpected behaviour, especially compared to other OSC Pose controllers such as in robosuite. For reference, this is how I define the actions in my modified Isaac-Stack-Cube-Franka-IK-Rel-v0 environment:

osc_config = OperationalSpaceControllerCfg(
target_types=["pose_rel"],
motion_control_axes_task=(1, 1, 1, 1, 1, 1),
contact_wrench_control_axes_task=(0, 0, 0, 0, 0, 0),
inertial_dynamics_decoupling=True,
partial_inertial_dynamics_decoupling=False,
gravity_compensation=False,
impedance_mode="fixed",
motion_stiffness_task=(150.0, 150.0, 150.0, 250.0, 250.0, 250.0),
motion_damping_ratio_task=(1.0, 1.0, 1.0, 1.0, 1.0, 1.0),
nullspace_control="none"
)

self.actions.arm_action = OperationalSpaceControllerActionCfg(
asset_name="robot",
 joint_names=["panda_joint.*"],
body_name="panda_hand",
controller_cfg=osc_config,
position_scale=0.05,
orientation_scale=0.5,
)

1. Neutral Position Behavior:
   I noticed that the robot arm can only move a certain distance from the initial position, slowing down as it gets close to that maximum distance (as if it was pulled back by something) and when I stop sending new target poses (e.g. sending [0, 0, 0, 0, 0, 0] as actions), the robot's arm snaps back to its initial configuration. It seems that the controller maintains the initial pose as its "neutral" or default target no matter what. Is this expected behavior?

   • This snapping back does not happen when setting the joint stiffness to 0. (Which makes sense, but it also should not happen with stiffness > 0 imo)
   • Shouldn't the controller update its internal target if the arm has been moved?
   • If not, what's the recommended way to make the controller "hold" the current pose as its new target when the delta-pose actions are just [0, 0, 0, 0, 0, 0]?

2. Joint Stiffness and Neutral Pose:
   How does the OSC controller use joint stiffness/damping in combination with operational space control? Are these parameters used as part of a nullspace projection or only in joint-level regulation? How do they affect the tendency to return to the initial pose?

3. OSC Pose Controller Example:
   In the official documentation example both the stiffness and dampening are set to 0 and gravity is disabled:

   robot = FRANKA_PANDA_HIGH_PD_CFG.replace(prim_path="{ENV_REGEX_NS}/Robot")
   robot.actuators["panda_shoulder"].stiffness = 0.0
   robot.actuators["panda_shoulder"].damping = 0.0
   robot.actuators["panda_forearm"].stiffness = 0.0
   robot.actuators["panda_forearm"].damping = 0.0
   robot.spawn.rigid_props.disable_gravity = True
   

   are these realistic parameters? Why were they chosen like this for the example? Also, are there differences between this more explicit example file and the implementation I am using in my env (defined here and here)?

Sorry, this is a bit much all at once, but any clarification on these would be greatly appreciated, as I feel I have some misunderstanding or am missing something.

Thanks in advance!
Tibor

[songwookim]

From what I know, setting stiffness and damping to zero helps avoid forcing the state to converge to zero under position control ..

[TibvG]

In that case joints would just continue to slide and you would need to counteract the previous actions to be able to stop at a specific pose. The behaviour I am looking for would be to hold the current (not the initial) EEF pose when identity actions ([0, 0, 0, 0, 0, 0]) are being sent.
This is possible when setting the damping to some value larger than zero and stiffness to 0. This is similar to the settings recommended for velocity control here, but I am not sure if this is correct for my usecase as well...