get_pose¶

Runs at once Any mode Open to every client

Return the measured pose of the tool centre point. The robot computes the pose every control tick from the measured joint angles, with the arm's model and the gripper in use. It is the tool centre point's position and orientation in the robot's base frame, the form move_pose() and move_linear() take.

The orientation is three angles, R = Rx(rx) Ry(ry) Rz(rz): rx about the base X axis, then ry about the tool's new Y axis, then rz about the tool's own Z axis, its spin. rx and rz lie within -180 to 180 degrees, ry within -90 to 90 degrees.

Syntax¶

robot.get_pose(*, angle_unit='rad')

Arguments¶

Name	Type	Default	Description
`angle_unit`	`str`	`'rad'`	`"rad"` or `"deg"`: the unit of the three angles returned.

Returns¶

list[float]

[x, y, z, rx, ry, rz]: the position in metres, then the angles in radians, or degrees with angle_unit="deg".

Examples¶

robot.get_pose(angle_unit="deg")
x, y, z, rx, ry, rz = robot.get_pose()
robot.move_linear(x, y, z + 0.02, rx, ry, rz)
robot.wait_idle()

Further details¶

Note

A tool pointing straight down reads rx near 180 or -180 degrees, and can jump between the two on a tiny motion: the same orientation. With the tool's Z axis along base X or -X (ry at 90 or -90 degrees), rx and rz turn about the same axis: the robot then reports rz as 0 and the whole turn in rx.

Usage restrictions 1 code

This command runs at once; it is not queued. The robot accepts it in any mode and state, from every client.

It answers with one of these codes when it does not carry the command out:

[6025] RTI not running or not answering — the control loop (RTI) has not run for over 0.5 s, or the robot is in flashing mode, where it reads no drive: the pose in its memory would be old

In Python, a code above raises CommandRejected; its number is the code. The call raises:

CommandRejected: The robot refused it: its control loop is not running, or it is in flashing mode.
RobotTimeout: The robot did not answer within 5 s.
RobotConnectionError: The client is not connected.
ValueError: angle_unit is neither "rad" nor "deg".

If the connection drops while the call waits for the robot's answer, it raises CommandRejected with the code CONNECTION_LOST (DISCONNECTED after disconnect()); while it waits for the robot's status, RobotConnectionError.

Like every immediate command, it also answers BAD_ARGS when a raw client sends a value the robot cannot read at all, and INTERNAL when it fails inside the robot.