I experimented with lula kinematics and it appears that the position provided to lula kinematics is in world coordinates, while the orientation is relative to the robot’s base.
Here is the code snippet I’ve been using:
target_joint_positions, success = articulation_kinematics_solver.compute_inverse_kinematics( target_position=command_return_dict['target_position'], target_orientation=command_return_dict['target_orientation']) if success: articulation_controller.apply_action(target_joint_positions) else: carb.log_warn("IK did not converge to a solution. No action is being taken.")
The robot base is shifted and rotated relative to the origin of the world coordinate system.
When I set the target position to: [0, 0, 1.052] and the target orientation to: [0.49999997, 0.49999997, 0.49999997, -0.49999997], the gripper’s world-pose-values after the movement is completed are as follows:
Position: [-1.4839604e-04, -6.5854285e-05, 1.0516999e+00]
Orientation: [6.1856705e-04, -1.1874572e-03, 7.0721060e-01, -7.0700163e-01]
As you can see, the world position matches as expected, but the orientation does not.
To address this issue, I found that subtracting the robot base orientation from the target orientation before sending it to the lula controller results in the correct world-pose-values for the gripper:
Position: [-9.6186996e-05, 4.7650421e-05, 1.0518397e+00]
Orientation: [0.49978912, 0.49992058, 0.50019026, -0.50009996]
This adjustment resolves the problem, but it is pretty confusing.
This inconsistency also applies to rmpflow.