Numbers, Variables, and Types

In URScript arithmetic expression syntax is standard:

1+2-3

4*5/6

(1+2)*3/(4-5)

2346.44 % 10

"Hello" + ", " + "World!"

In boolean expressions, boolean operators are spelled out:

True or False and (1 == 2)    1 > 2 or 3 != 4 xor 5 < -6

not 42 >= 87 and 87 <= 42

"Hello" != "World" and "abc" == "abc"

Variable assignment is done using the equal sign =:

foo = 42

bar = False or True and  not  False baz = 87-13/3.1415

hello = "Hello, World!" l = [1,2,4]

target = p[0.4, 0.4, 0.0, 0.0, 3.14159, 0.0]

The fundamental type of a variable is deduced from the first assignment of the variable. In the example above, foo is an int and bar is a bool. target is a pose: a combination of a position and an orientation.

The fundamental types are:

  • none
  • bool
  • number - either int or float
  • pose
  • string

Note that strings are fundamentally byte arrays without knowledge of the encoding used for the characters it contains. Therefore some string functions that may appear to operate on characters (e.g. str_len), actually operates on bytes and the result may not correspond to the expected one in case of string containing sequences of multi-byte or variable-length characters. Refer to the description of the single function for more details.

A pose is given as p[x,y,z,ax,ay,az], where x,y,z is the position of the TCP, and ax,ay,az is the orientation of the TCP, given in axis-angle notation.

Orientation Representation in PolyScope

PolyScope and the ROS 2 interfaces both report the robot TCP pose, but they use different orientation representations. This can lead to confusion if the values are compared directly.

PolyScope: rotation vector (axis with angle magnitude)

In the PolyScope user interface, the TCP orientation shown as Rx, Ry, Rz is not an Euler-angle representation. Instead, PolyScope uses a rotation vector (also known as axis–angle with angle magnitude):

The three values ((R_x, R_y, R_z)) form a 3D vector.

ROS 2: actual_tcp topic: quaternion

When subscribing to the actual_tcp state (for example via the ROS 2 web bridge in a URCap):

The pose contains the TCP position and an orientation quaternion.

If you convert this quaternion to Euler angles using a generic converter, the resulting Euler angles will generally not match the Rx, Ry, Rz values shown in PolyScope.

How to verify that orientations actually match

To check that the orientation received from ROS 2 matches what PolyScope shows:

  1. Take the quaternion from the actual_tcp topic.
  2. Convert the quaternion to an axis–angle / rotation vector representation (many math and robotics libraries support this, or you can use online tools such as 3D Rotation Converter).
  3. Compare the resulting rotation vector ((R_x, R_y, R_z)) to the orientation displayed in PolyScope.

Recommendations for developers

When using PolyScope pose values programmatically, always treat Rx, Ry, Rz as a rotation vector, not as Euler angles.

When integrating with ROS 2:

  • Work with quaternions directly where possible.
  • If you need to compare with PolyScope, convert the quaternion to a rotation vector first.
  • Be aware that: Rotation vectors, Euler angles, and quaternions can represent the same physical orientation while having very different numeric values.
  • This is a property of rotation mathematics and not a bug in the PolyScope or ROS 2 implementation.