URScript: Calculating TCP Pose in Tool Coordinates

Jason IP2 min read
Other ManufacturerRoboticsTechnical Reference
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

get_actual_tcp_pose() reports the current tool center point (TCP) pose in the robot base frame. Expressing that same TCP pose in its own current coordinate system produces the identity pose: [0,0,0,0,0,0]. Therefore, converting the TCP itself into tool coordinates cannot determine whether it has crossed a spatial boundary.

Why the Tool-Space TCP Pose Is Always Zero

The current TCP coordinate system is attached to the TCP and follows its position and orientation. Its origin expressed relative to itself has zero translation and zero rotation. A bounding box that also follows this same frame does not define a stationary workspace boundary; the TCP remains at the box coordinates [0,0,0].

Choose a Common Frame for the Boundary Test

Define the box relative to a frame that does not move with the current TCP, or obtain the box pose relative to the base. Then compare the TCP and box in one common coordinate system. If the box is specified in another reference frame, use the transformation between that frame and the base rather than requesting the TCP pose in its own frame.

Quantity Expression frame Result or use
Actual TCP pose Base Returned by get_actual_tcp_pose()
TCP pose Current TCP [0,0,0,0,0,0]
Box limits Base or fixed reference Use for the boundary comparison

Transform and Test the Position

Represent the base-to-TCP relationship and the box relationship as transformations. Convert either the TCP position into the box frame or the box limits into the base frame. The evidence does not identify specific URScript transformation functions, so select the available pose or transformation operations for the deployed controller without assuming an unsupported function identifier.

  1. Read the TCP pose in the base frame with get_actual_tcp_pose().
  2. Establish the box pose relative to the base, directly or through the known base-to-reference transformation.
  3. Transform the TCP position into the box frame.
  4. Compare each transformed position component against the corresponding box minimum and maximum.
  5. Verify the result at known inside and outside positions, including each box face.
# Symbolic frame calculation, not literal URScript syntax
T_box_tcp = inverse(T_base_box) * T_base_tcp
p = translation(T_box_tcp)
inside = (x_min <= p.x and p.x <= x_max) and
         (y_min <= p.y and p.y <= y_max) and
         (z_min <= p.z and p.z <= z_max)

Resolve the Frame Ambiguity

The phrase “box defined in the coordinate system of the tool” is ambiguous. If it means the current moving TCP frame, the TCP never moves relative to the box. If it means a separately taught tool-oriented frame that remains fixed during the test, retain that frame’s pose relative to the base and perform the transformation before checking the limits.

FAQ

What does get_actual_tcp_pose() return in URScript?

It returns the actual TCP pose expressed in the base frame.

What is the actual TCP pose in its own tool coordinate system?

It is always [0,0,0,0,0,0] because the TCP frame’s origin and orientation are being expressed relative to themselves.

How do I check whether a UR10 TCP is outside a 3D box?

Express the TCP and box in one common frame, transform the TCP position into the box frame if required, and compare its three position components with the box minimum and maximum limits.

Back to blog