You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I was working on the OperationalSpaceController (#913), the new commit about clip ranges (#1476 ) caught my attention. Based on the commit message, this clipping mechanism appears to be intended for all actions, regardless of whether they are joint-based or task-based. This is not yet integrated into OperationalSpaceControllerAction. Moreover, I foresee challenges in extending it to task-space controller actions and a potential error with its current implementation for DifferentialInverseKinematicsAction.
For reference, here is how the clipping is currently implemented in DifferentialInverseKinematicsAction:
The issue lies in the way the clip is defined (i.e., using a dictionary) and constructed (i.e., modification based on joint indices), which strongly implies that the clip values correspond to joint limits, while the actions themselves are in task space. I suspect that L118 could already raise an error if self.action_dim does not equal the number of joints. Even if they are equal, applying joint limits to task-space actions is misleading and could lead to unintended behavior.
To address this, I propose the following hotfix:
Move the clip attribute of ActionTermCfg to JointActionCfg.
Update the documentation to explicitly state that clipping only applies to joint actions.
Remove the clipping logic from DifferentialInverseKinematicsAction.
Alternatively, if clipping for task-space actions is still required, additional considerations need to be addressed due to the variability in action definitions and specific implementations. These include:
Coordinate Naming: If a dictionary is used for partial clipping, what would the names of the task-space coordinates be? These can vary depending on the action type (e.g., absolute pose, relative pose, pos/pose/wrench).
Clipping Rotations: For task actions involving an absolute pose, how should the rotation component be clipped, given that it is defined as a quaternion?
Redundant Clipping: Some task-space action parameters (e.g., the impedance parameters of OperationalSpaceControllerAction) are not coordinate-related or are already subject to clipping. Should they be clipped again under the umbrella clip setting?
In my opinion, the responsibility for clipping task-space actions should remain with individual implementations, as the definitions and requirements for task-space actions vary significantly across different controllers and configurations.
Please let me know your thoughts. Thank you in advance.
Thanks for raising the issue! It does look like there are some flaws in the dictionary logic for non-joint actions. It was actually originally implemented for JointAction, but we wanted to extend it towards all actions so we moved it to ActionTermCfg. I think there are still benefits to supporting clipping, but we'll need to reevaluate the dictionary representation. Seems like it might make sense to have more action-specific namings for the dictionary keys and the action class will then have to interpret it based on the action type.
Hello IsaacLab Team,
While I was working on the
OperationalSpaceController
(#913), the new commit about clip ranges (#1476 ) caught my attention. Based on the commit message, this clipping mechanism appears to be intended for all actions, regardless of whether they are joint-based or task-based. This is not yet integrated intoOperationalSpaceControllerAction
. Moreover, I foresee challenges in extending it to task-space controller actions and a potential error with its current implementation forDifferentialInverseKinematicsAction
.For reference, here is how the clipping is currently implemented in
DifferentialInverseKinematicsAction
:IsaacLab/source/extensions/omni.isaac.lab/omni/isaac/lab/envs/mdp/actions/task_space_actions.py
Lines 111 to 120 in fc6042f
IsaacLab/source/extensions/omni.isaac.lab/omni/isaac/lab/envs/mdp/actions/task_space_actions.py
Lines 159 to 166 in fc6042f
The issue lies in the way the clip is defined (i.e., using a dictionary) and constructed (i.e., modification based on joint indices), which strongly implies that the clip values correspond to joint limits, while the actions themselves are in task space. I suspect that L118 could already raise an error if
self.action_dim
does not equal the number of joints. Even if they are equal, applying joint limits to task-space actions is misleading and could lead to unintended behavior.To address this, I propose the following hotfix:
Alternatively, if clipping for task-space actions is still required, additional considerations need to be addressed due to the variability in action definitions and specific implementations. These include:
In my opinion, the responsibility for clipping task-space actions should remain with individual implementations, as the definitions and requirements for task-space actions vary significantly across different controllers and configurations.
Please let me know your thoughts. Thank you in advance.
System Info
Checklist
Acceptance Criteria
The text was updated successfully, but these errors were encountered: