Get_actual_tcp_pose() rotation frame

Technical Questions URScript
1

Hello everyone,

I’ve encountered a discrepancy when comparing the output of get_actual_tcp_pose() with the values shown in the Move tab.

The position values match those of the Base frame, but the rotation values do not correspond to the Base frame or any other defined coordinate frame.

Could someone clarify:

  • In which reference frame are the rotation values returned by get_actual_tcp_pose()?
  • And how can I obtain the current TCP rotation relative to the Base frame?

Best regards,
Dmytro

2

Have you tried inputting the values from the script command into the move tab? :slight_smile:
There are more solutions than one to reach a certain orientation.

3

Let me rephrase the issue. During motion, if the normalized rotational vector of the current position exceeds π, the function’s returned rotation values appear to flip, while the rotation values displayed in the Move tab remain consistent and continue beyond π.

Is there a way to align these two behaviors—so they remain consistent—without manually recalculating the rotation values?

4

Hello @dmytro.kharchenko

This behavior is known and stems from the way we calculate and display the rotation information. See this article on the Angle-Axis representation for some further insights.

/Stefan

5

Hello Stefan,

Thank you for your response. I appreciate your input, but it doesn’t fully address the consistency issue I’m encountering.

May I ask for your advice:
If I convert a pose to joint values and then back to a Cartesian position, is it guaranteed that orientations like [0, 0, π] and [0, 0, -π] will consistently return as [0, 0, π]?

Best regards,
Dmytro

6

Hallo @dmytro.kharchenko

Unfortunately, we cannot guarantee that the orientation will always be returned in the same form, even if they represent the same physical rotation. This is due to the inherent non-uniqueness of the axis-angle representation. Both [0, 0, π] and [0, 0, -π] describe the same rotation, and the system may return either depending on internal numerical factors or implementation details of the kinematics solvers.

I personally made some tests , getting always the same consistent result [0, 0, π]. This most likely reflects the current behavior of the controller and PolyScope. But, we cannot formally commit to this behavior being consistent across all versions and potential edge cases.

/Stefan

7

Thank you. I implemented a workaround by normalizing all the rotation data, which resolved the issue in my case.

1 Like