Lula target position is in world coordinates, but orientation is relative to robot base

Hello,

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.

Kind regards

Axel

By the way, I have noticed an issue with the quat_to_euler_angles function from omni.isaac.core.utils.rotations. It appears that this function only works correctly for certain value ranges.

During my experiments, I tested different gripper orientations by changing the orientations in 90-degree steps, ensuring that every value is a multiple of 90. The orientations are represented in quaternion format and then converted to euler angles using the quat_to_euler_angles function.

For most orientations, the conversion is correct. However, when dealing with certain quaternion values, such as [7.0688874e-01, 1.3515353e-04, 7.0732468e-01, 1.2603216e-04], I get euler angles of [149.0697702, 89.95882564, 149.0692288] (in degrees).

In comparison, when using a rotation converter from the internet ( 3D Rotation Converter (andre-gaschler.com)), I obtain the following values: [x: 0.0211482, y: 89.965736, z: 0], which definitely makes more sense.

As I am not a mathematician, I am unsure if there are any constraints or limitations in converting quaternions to euler angles, but these are my observations.

Kind regards

Axel