**1. Minimal surfaces**

The Weierstrass representation is a generic model for all minimal surfaces. It defines a minimal surface ( ) on a complex plane ( ). Let (the complex plane as the space), we write the Jacobian matrix of the surface as a column of complex entries:

The Jacobian represents the two orthogonal tangent vectors of the surface:

The surface normal is

A point on the complex plane maps to a point on the minimal surface in by

The Weierstrass model yields immersed minimal surfaces; however, it does not address the problem of self-intersections. An important method is using the fundamental patch to construct periodic minimal surfaces. The infinite continuous surface is constructed from copies of the fundamental patch by translation, rotation and reflection. Classical examples include Schwarz surfaces and Scherk’s surfaces.

Fig.1 The affine transformed copies of the fundamental patch span the continuous Triply Periodic Minimal Surfaces (TPMS).

**2. Parameterization with principal directions**

One has to subdivide the infinitely extensible PMS into manageable workpieces for wire-cut machines. Now we focus on the workpiece reparameterization from which the toolpath can be directly derived. Although the surface is smooth across the boundary of fundamental patches, the lines are not smooth across the fundamental patches, which is unacceptable for wire cut (a workpiece usually consists of multiple fundamental patches). Our reparameterization defines a smooth cross field (orthonormal frame field) on the surface. The pair of orthogonal tangents at each position corresponds to the cutting wire’s orientation and its velocity vector (normalized) respectively. The principal directions and the normal span a local orthonormal basis. The lines of curvature are smooth everywhere on the surface except for singular points.

One can relate the new orthogonal coordinates to the original coordinates by a direction field

Because the map (1) from the domain to the 3D surface is conformal, the tangent vectors with respect to the parametrization are given by

and happen to be the principal directions if complies with equation (5).

One principal direction in the complex domain is

Therefore, the two principal directions in the space turn out to be

The cross field identifies the () coordinates according to (4). Consequently, one can compute the principal directions and by (5). One can use Runge-Kutta method to construct two sets of orthogonal streamlines in the 2D field , and the corresponding 3D streamlines (on the surface) as the trajectories of wire cutting (Fig.2).

Fig.2 Lines of curvature (6) make a quadrangulation of the domain.

(6) gives an algebraic expression for the principal direction of any minimal surface, once the holomorphic functions and are given. For instance, the principal direction of Schwarz P surface is

Likewise, Saddle tower’s (Scherk surface ) principal direction is

The principal direction of Costa’s surface is given by

where is constant and denotes Weierstrass’s elliptic function.

The complex domains of the surfaces can be quadrangulated according to the principal directions (Fig.2).

**3. Double-sided cutting scheme**

A family of ruled surfaces can offer an approximation of a minimal surface. A sufficiently long wire cannot cut double-sided surfaces of positive Gaussian curvature without collisions. For instance, wire cutting can approximate the outside surface of a piece of an egg shell; however, it would be impossible to produce the inside surface.

A global quadrangulation (-lines) enables us to complete the wire cutting of a workpiece in three steps (Fig.3):

1) front cut: aligning the wire with when the wire travels along -lines.

2) back cut: aligning the wire with when the wire travels along -lines.

3) side cut: aligning the wire with when the wire cuts the boundary.

Fig.3 The orthogonal double-sided cuts correspond to the orthonormal directions , , and on the surface.

**Orthogonality**: on any point on the surface, the line cutting one side of the surface is orthogonal to that on the other side. Further, the velocity vector (or, the cutting direction) of the line cutting one side of the surface is orthogonal with that on the other side.

**Interchangeability**: swapping the wire’s velocity vector with its orientation (in other words, swapping the values of and ) leads to a mirrored copy of the original workpiece.

Fig.4 Top row: cutting a workpiece (equivalent to two fundamental patches) of Gyroid surface (left), and the assembly of 20 workpieces (right). Middle row: cutting a workpiece (equivalent to four fundamental patches) of the Saddle tower (left), and the assembly of 9 workpieces (right). Bottom row: cutting a workpiece (equivalent to two fundamental patches) of Costa’s minimal surface (left), and the assembly of 4 workpieces (right).

**4. Hot-wire cutting**

Mounting a hotwire tool to a robot arm leads to a flexible cutter. Both position (XYZ) and orientation (ABC: Euler angles) identify the geometric state of the tool (hotwire). Suppose the center of the tool is predefined on the wire (e.g. at the wire’s midpoint), the cutting position for a given point on the streamlines is given by

Where denotes the global scalar for the workpiece, denotes workpiece’s (half) thickness; denotes reflection and rotation for and ; denotes reflection, rotation and translation for the point on the surface.

To specify the wire’s orientation, we first put the local orthonormal vectors and into a unitary matrix

then Z-Y-X Euler angles (ABC) can be found by solving the following equation

where and denote and respectively.

Fig.5 Cutting a “saddle tower” workpiece with the robotic system in our workshop. A hotwire tool is mounted to the flange of the KUKA robot.

A KUKA robot can approximate a continuous cut (following a or line) by a set of linear movements (LIN) or by a spline movement (SPLINE). We implemented KUKA’s spline movement whose key points are specified in the form of

SPL { X_ Y_ Z_ A_ B_ C_ }

As a result, the XYZABC values for SPL commands are directly obtained from the closed-form expression of the toolpath (7)(8).

**Summary**

This application shows a possibly shortest path from a mathematical formulation of workpiece geometry to the data in the robot instructions that result in the geometry. The design & toolpath planning mainly consist of:

(1) Designing and describing the workpiece via a structured family of toolpaths, each of which is defined by a mathematical expression.

(2) Sampling the data points from the mathematical expressions, and feeding them into the robot commands.

Thus we are looking for the geometric & topological fit between the predefined types of robot motions and the workpiece design.

References:

[1] Nitsche, J.C., 1989. *Lectures on minimal surfaces: vol. 1*. Cambridge university press.

[2] Gandy, P.J. and Klinowski, J., 2000. Exact computation of the triply periodic G (Gyroid’) minimal surface. *Chemical Physics Letters*, *321*(5-6), pp.363-371.

[3] Meeks III, W. and Pérez, J., 2011. The classical theory of minimal surfaces. *Bulletin of the American Mathematical Society*, *48*(3), pp.325-407.

[4] Osserman, R., 2013. *A survey of minimal surfaces*. Courier Corporation.

[5] Hua, H. and Jia, T., 2018. Wire cut of double-sided minimal surfaces. *The Visual Computer*, *34*(6-8), pp.985-995

Connecting a camera to a KUKA robot enables the robot to observe the environment and react responsively. The low-level information captured by the camera, namely the pixels, is transformed into a certain meaningful signal that constantly informs the robot’s motion. This post briefly introduces the connection and the communication between the vision system and KUKA.

**1. System architecture**

One can either develop robot’s software interpreting low-level signals (pixels) and reacting so that the robot has the a brain or let the camera’s software transform the original signals into structured data before feeding it to the robot so the camera is both the eye and the brain. Our example follows the second approach, as the commercial vision system (COGNEX) already integrates intelligent functionalities, such as pattern matching, into the standalone camera. We connected a COGNEX In-Sight 1100 with a KUKA KR6 through the EtherNet/IP protocol. The Ethernet cable connects the camera with the X66 of the C4 compact controller.

We used WorkVisual to configure the digital inputs (e.g., $IN[200] to $IN[231] receive a 32-bit integer value, which represents the x-coordinate) from the EtherNet/IP communication. On the camera side, In-Sight explorer was used to configure the format of the output data to match the WorkVisual settings. The figure below illustrates the system architecture.

**2. Communication**

The COGNEX camera recognizes the current workpiece (whose pattern is predefined in COGNEX’s In-sight Explorer) and computes the workpiece’s position X, Y, and orientation A. We convert the three real variables into 32-bit integers by multiplying them by 1000 respectively. Eventually, the camera will constantly send the three integers to the KUKA controller through EtherNet/IP.

For KUKA, one needs to firstly define three integers (SIGNAL) variables that receive the data from the camera (in KRC:/ R1 / System /config.dat):

SIGNAL INPUT X $IN[200] TO $IN[231]

SIGNAL INPUT Y $IN[232] TO $IN[263]

SIGNAL INPUT A $IN[264] TO $IN[295]

and a FRAME variable whose values will be replaced by real-time data:

FRAME pos={X 91, Y 188, Z 128, A 0, B 0, C 0}

Second, the main program (.src) uses the real-time values of X, Y, and A to plan the robot motion, for example, to reach the recognized workpiece’s position:

FOR NI=1 TO 10

wait sec 2

pos.x= 615+ INPUT X *0.001

pos.y= -180+ INPUT Y *0.001

pos.c= INPUT A *0.001

PTP pos C_DIS

END FOR

In real applications, the codes could be much more complicated because of issues of the stability of communication, smoothness of motion, collision, and safety.

**3. Gripper**

We used a digital signal from KUKA to control a gripper, for example, ON: grasping; OFF: leasing. To control the gripper, one needs to

1) Wire the gripper to KUKA’s digital I/O. Some robots have an X41 connection on the arm so we can easily wire the X41 to the gripper. Otherwise, we need to connect the EtherCAT (in C4 controller) to the gripper. One can switch a specific digital output (Display / Inputs/ outputs / Digital I/O) and see the corresponding LED switch on the EtherCAT module.

2) Manipulate the digital output (corresponding to a specific slot of X41) in the main program (.src) to control the gripper. For instance:

pos.z= 100

$OUT[2]=false

pos.z= 0

PTP pos C DIS

$OUT[2]=true

wait sec 0.5

pos.z= 100

PTP pos C DIS

which opens the gripper ($OUT[2]=false) before grasping and closes the gripper ($OUT[2]=true) when grasping at the right position.

]]>

**1. External axes**

What’s the point in installing a rotary table when the robot already has six axes? While the robot arm is indeed agile, adding an external axis could make planning the tool path simpler.

Once the external axes are correctly installed, KRL can directly drive the external axes. For example:

{X 27.3, Y 84.2, Z 20, A 201.5, B 0, C -90, E1 0, E2 -162}

where E1 denotes the linear unit’s displacement; E2 denotes the degree of the rotary table; XYZ specify the tool’s position relative to the BASE; and ABC inform the tool’s orientation (Euler angles) relative to the BASE.

There are many options for using a rotary table:

1. Turn the table using its controller when it is not connected to KUKA.

2. KUKA and the rotary table are fully coupled so the table’s rotation becomes part of the robot’s internal kinematics. A position instruction XYZABC may invoke the table rotation, even if there are no explicit instructions on the external axis.

3. KUKA controls the rotary table but decouples the rotation from the robot’s kinematics (let $EX_KIN={ET1 #NONE, ET1 #NONE,…} in KRC\R1\MADA\$machine.dat). Because the robot is unaware of the effects of the rotation, the offline programming takes care of the cooperation between the robot and rotary table.

The following example takes the third approach. It keeps a hot cutter on one side of the workpiece (a cylinder foam) during the cutting process. The procedure is as follows:

1. Calibrate the tool.

2. Calibrate the rotary table and work piece simultaneously by our 5-point method.

3. The Java program uses the 5-point data to unify the movements of the robot and the rotary table. Finally, the program transforms the tool path into a .src file.

4. Copy the .src file to KUKA and run the machine.

**2. Frame**

A frame, or a coordinate system, is defined by its position (x, y, z) and its orientation (x, y, and z-axis):

The orientation (three axes) can be written as a 3☓3 matrix (see the methods matrixBy2Axis and matrixBy3Axis in LA class). Combing the position and the orientation leads to a 4☓4 matrix (allowing matrix-matrix multiplication and matrix-vector multiplication):

where the top left block is the orientation matrix. This matrix and KRL’s XYZABC are interchangeable, see the methods in LA class:

**double**[][] matrix(**double** aDeg, **double** bDeg, **double** cDeg) //compute a 3*3 matrix from Euler angles

**double**[][] matrix(**double** x, **double** y, **double** z, **double** aDeg, **double** bDeg, **double** cDeg) //compute a full matrix from XYZABC

**double**[] ABC(**double**[][] m) //compute Euler angles from a 3*3 matrix

**double**[] XYZABC(**double**[][] m) //compute XYZABC from a full matrix

**3. 5-point method**

This method computes the BASE from five points measured on the workpiece. is the matrix representation of the BASE (frame -1) relative to the WORLD (frame 0), equivalent to the XYZABC model (extended discussions are in entry Kinematics). With a rotary table, the following relationship holds:

where denotes the frame of rotary table (r) relative to the WORLD while stands for the BASE (workpiece) relative to the rotary table.

The following image shows the table’s flange and the workpiece can be defined simultaneously by five points:

: workpiece’s origin;

: a point on the positive x-axis of the workpiece;

: a point on the XY plane (with positive y) of the workpiece;

: the workpiece’s origin when the table is turned 90 degrees;

: workpiece’s origin when the table is turned -90 degrees.

The method does NOT assume the workpiece’s origin is at the center of rotary table nor that the workpiece’s XY plane is parallel to the table’s flange.

To measure the five points:

1. Use a pen to mark the origin P of the workpiece (it is the top center of the cylinder in our case), and draw a line on the top as the x-axis.

2. Set the current TOOL/BASE in the pendant (BASE = NULLFRAME, i.e. the WORLD).

3. Manually align the defined tool to a point (e.g., the origin P) on the workpiece, navigate to Display / Actual position to read the position. O+ and O- need to be measured after rotating the table by 90 and -90 degrees, respectively.

4. Put the position data (XYZ) into the Java program. For example:

**final** **double**[] P = { 436.39, -1414.71, 763.37 };

**final** **double**[] Px = { 341.55, -1315.84, 762.09 };

**final** **double**[] Pxy = { 341.52, -1516.66, 764.59 };

**final** **double**[] Op = { 425.80, -1412.27, 763.27 }; // +90

**final** **double**[] On = { 434.58, -1425.12, 763.49 }; // -90

The Java program Rotary produces a runnable .src file for KUKA, employing the LA (linear algebra) class and the KRLwriter class.

Now, we explain how to transform the 5-point data into the rotating BASE (workpiece). First, the origin, the x-axis, and the y-axis of the table can be defined as , , , respectively. Thus, the table’s orientation (T1 in Java) can be computed in Java by:

O = *between*(Op, On, 0.5);

T1 = LA.*matrixBy2Axis*(LA.*sub*(P, O), LA.*sub*(Op, O));

where the columns of matrix represent the x, y, z axis of the orientation of the table:

Second, the origin, the x-axis, and xy-axis of the BASE (workpiece) are , , and , respectively, relative to the rotary table. Thus, (T2 in Java) can be obtained by:

**double**[] rela_ax = LA.*mul*(LA.*transpose*(T1), LA.*sub*(Px, P));

**double**[] rela_ay = LA.*mul*(LA.*transpose*(T1), LA.*sub*(Pxy, P));

**double** d = LA.*dist*(O, P);

T2 = LA.*matrixBy2Axis*(d, 0, 0, rela_ax, rela_ay); // relative to T1;

has a form of

where the top left 3☓3 elements represent the frame’s orientation while the last column specifies the frame’s origin.

Third, we compute the BASE rotated by an arbitrary angle . A 3☓3 matrix represents the rotation around the z-axis and, subsequently, the orientation of the rotated table can be obtained:

Combining the origin O leads to a 4☓4 matrix (the top left 3☓3 elements are taken from matrix (1))

Therefore, the rotated BASE (relative to WORLD) is

The corresponding Java codes read:

**double**[][] rotateTable(**double** angle) {

** double** c = Math.*cos*(angle);

** double** s = Math.*sin*(angle);

** double**[] rx = { c, s, 0 };

** double**[] ry = { -s, c, 0 };

** double**[] nx = LA.*mul*(T1, rx);

** double**[] ny = LA.*mul*(T1, ry);

** double**[][] T1 = LA.*matrixBy2Axis*(O[0], O[1], O[2], nx, ny);

** return** LA.*mul*(T1, T2);

}

**4. Tool path planning **

The plan is to cut ten S shapes around a cylinder foam. The first S shape is a parametric curve (parameter s) that lies on the XZ plane of the BASE:

Other S shapes are the rotated (around the z-axis of the BASE) copies of the original:

If there is no rotary table, the robot has to turn the tool around the cylinder. In this situation, it is difficult to avoid a collision between the robot and the workpiece. With the help of a rotary table, the robot arm can stay on one side of the workpiece with the following process:

1. Cut the first S shape.

2. Rotate the table by , update BASE by (3) and

cut the S shape, which is rotated from the first one.

3. Rotate the table by , update BASE by (3) and

cut the S shape, which is rotated from the first one.

…

The signs of in (1) and (4) are opposite, meaning the BASE’s rotations “compensate” the rotations of the S shapes.

The corresponding KRL codes look like:

$BASE={X 437.3,Y -1416.8,Z 763.4,A 115.8,B 0.6,C 0.2}

PTP {X 27.3,Y -84.2,Z 20,A 57.5,B 0,C -90,E1 0,E2 0}

SPLINE

SPL {X 27.3,Y -84.2,Z 20,A 57.5,B 0,C -90,E1 0,E2 0}

…

$BASE={X 434.9,Y -1413,Z 763.3,A 151.8,B 0.4,C 0.7}

PTP {X -27.3,Y -84.2,Z 20,A 21.5,B 0,C -90,E1 0,E2 36}

SPLINE

SPL {X -27.3,Y -84.2,Z 20,A 21.5,B 0,C -90,E1 0,E2 36}

…

$BASE={X 430.6,Y -1411.3,Z 763.3,A -172.2,B 0,C 1}

PTP {X -71.6,Y -52,Z 20,A -14.5,B 0,C -90,E1 0,E2 72}

SPLINE

SPL {X -71.6,Y -52,Z 20,A -14.5,B 0,C -90,E1 0,E2 72}

…

Kuka is blind on workpiece’ rotation; however, the updates of $BASE guarantee the relative position between the robot and the workpiece is correct.

Each S shape corresponds to a SPLINE of three segments (SPLs, SLIN, SPLs):

SPLINE

SPL {X 27.3,Y 84.2,Z 20,A 201.5,B 0,C -90,E1 0,E2 -162} //downward cut

SPL {X -0.8,Y 93.3,Z 0}

…

SPL {X 100.7,Y 60.4,Z -380}

SLIN {X 100.7,Y 60.4,Z -380,A 266.5,B 0,C -90} //change orientation

SPL {X 100.7,Y 60.4,Z -380}//upward cut

SPL {X 117.8,Y 54.8,Z -360}

…

SPL {X 27.3,Y 84.2,Z 20}

ENDSPLINE

The following image shows that the two cuts follow the same path but with different orientations.

This example indicates the added freedom given by a rotary table can facilitate path planning, especially when collision and the robot’s workspace are critical. The 5-point method is for general purpose; it computes the BASE rotated with the rotary table.

**5. 5-point method revisited**

When the workpieces’s origin is close to the turntable’s center, the aforementioned 5-point method may result in inaccurate calibration. To solve this problem, one can measure the 5 points as in the following image

The measured coordinates are saved in the Java codes, for example:

final double[] P = -558.92, 1400.13, 841.81 ;

final double[] Px = -77.44, 1270.00, 843.67 ;

final double[] Pxy = -440.21, 1840.17, 840.69;

final double[] Pxy90p = -999.72, 1516.83, 842.63; // point xy +90

final double[] Pxy90n = -116.46, 1281.05, 844.92 ; // point xy -90

The origin, the x-axis, and the y-axis of the table can be defined as , , respectively. Thus, the table’s orientation (T1 in Java) can be computed in Java by

O = M.between(0.5, Pxy90p, Pxy90n);

T1 = LA.matrixby2Axis(LA.sub(Pxy90n, O), LA.sub(Pxy, O));

where the columns of matrix represent the x, y, z axis of the orientation of the table:

Second, the origin, the x-axis, and xy-axis of the BASE (workpiece) are , , and , respectively, relative to the rotary table. Thus, (T2 in Java) can be obtained by:

double[] rela ax = LA.mul(T1T, LA.sub(Px, P));

double[] rela ay = LA.mul(T1T, LA.sub(Pxy, P));

double[] d = LA.mul(T1T, LA.sub(P, O));

T2 = LA.matrixby2Axis(d[0], d[1], d[2], rela ax, rela ay);

**References:**

1) Kuka manual, on the calibration of the base and the external kinematic system.

2) J. J. Graig, Introduction to Robotics, chapter 2.

3) P. Schneider and D. Eberly, Geometric Tools for Computer Graphics, chapters 2,3,4.

**1. Transformation algebra**

Translating a point leads to vector addition:

Rotating the point about the z-axis of the coordinate system (or frame) corresponds with multiplying a rotation matrix (here we replace cos with c and sin with s):

It’s convenient to put translation and rotation (about the z-axis) into one matrix:

Translation and rotation about the y-axis amounts to

Suppose the default frame is {0}, performing transformation (1) relative to {0} leads to a new frame {1}. Performing transformation (2) relative to {1} leads to a third frame {2}. A point (x,y,z) (coordinates in {2}) has its coordinates (x’, y’, z’) in the original {0}:

We denote the matrix description of {2} relative to {0} with :

The principle is that the matrix of a successive transformation is at the right side of the multiplication:

**2. Forward kinematics**

Following the rule of compound transformation (3), it is straightforward to computer , namely, the description of the FLANGE {6} relative to the WORLD {0}:

Where the six matrices are given by ( stands for and stands for )

Where and (i=0,1,.., 5) are the DH (Denavit–Hartenberg) parameters that describe the dimensions of the each linkage of the robot.

For instance, the DH parameters of KR6 R900 are:

a = { 25, 455, 35, 0, 0, 0 };

d = { 400, 0, 0, 420, 0, 80 };

Likewise, the DH parameters of KR16 are:

a = { 260, 680, -35, 0, 0, 0 };

d = { 675, 0, 0, 670, 0, 158 };

ABB IRB 4600-45/2.05:

a = { 175, 900, 175, 0, 0, 0 };

d = { 495, 0, 0, 960, 0, 135 };

These data agree with the robot’s dimensions, which can be found in the data sheet.

Now, we use forward kinematics to visualize robot’s body in Java. The pedestal is directly rendered in frame {0} (WORLD), which is the default coordinate system of Java’s virtual 3D scene. As the first link resides in frame {1}, we need to transform the geometry of the link before drawing it in the frame {0}:

where x, y, z are the coordinates of the vertices of the link’s geometry, relative to itself (the link’s bottom center is located at (0,0,0)); while x’, y’, z’ are the coordinates of the link in the frame {0}, so we can render all the vertices (x’, y’, z’) in {0} correctly.

The vertices of the second link are given by

Likewise for other succeeding links. Finally, the position of the flange (the sixth link) would be

As such, one can visualize the links one by one using the transformation matrices for i=1, 2,…6:

DisplayKuka (dependencies: Processing and Peasycam) demonstrates the forward kinematics using a 3D model of KR6 R900. Please download the 3D model (and unzip) and place it in the bin folder (Eclipse).

Our Robot class provides the function **double**[][] forward(**double**[] ts) whose input is the joint angles in radius, and output is the matrix .

Another function **double**[][][] forwardSequence(**double**[] ts) returns the six matrices: , , , , , and .

**3. BASE & TOOL**

XYZABC and transformation matrix are two exchangeable representations of transformations (methods for conversion can be found in the LA class). When navigating to Start-up / Calibrate / BASE (or TOOL) / Numeric input, we can see the BASE or the TOOL represented by XYZABC, which is equivalent to the matrix representation.

denotes the BASE frame relative to WORLD. Regarding the tool as the 7th link, we denote the TOOL frame (relative to FLANGE) as , as a result:

where is the very data that one mostly cares for, because tells how the tool is located in the BASE (usually corresponds to the workpiece). Notice that a typical KRL command PTP {X 280, Y 0, Z -10, A 30, B 90, C 0} specifies the tool’s position in the BASE.

The Robot class provides a method **double**[] forward(**double**[] degs, **double**[][] base, **double**[][] tool) which converts joint angles A1-A6 (with TOOL and BASE) to (in the form of XYZABC).

Here is a simple example testing forward kinematics :

**double**[] a = { 260, 680, -35, 0, 0, 0 };

**double**[] d = { 675, 0, 0, 670, 0, 158 };

**Robot** kr=**new** **Robot**(a,d); //KR 16

**double**[] degs = {35.55, -54.91, 88.58, 62.39, 39.19, -32.95 }; //A1-A6

**double**[][] tool = LA.*matrix*(-54.707, -59.723, 77.7, -11, 22, -33);

**double**[][] base = LA.*matrix*(898.094, -1265.699,245.752,161.956,-11,22);

**double**[] results = kr.forward(Robot.*DegToRad*(degs, “KUKA”), base, tool);

**4. Inverse Kinematics**

Opposite to forward kinematics, inverse kinematics calculates joint angels (A1-A6) from tool positions (XYZABC). Given a flange position XYZABC (corresponds to ), there could be multiple solutions of joint angles. KUKA uses **S** and **T** parameters to reduce ambiguity. The following image shows four configurations of joint angles with the same position .

The robot arm has a characteristic feature: the center of the fifth joint (), as well as , , , and , always lies on the XZ plane of the first joint. Therefore angle A1 is obtained by

Within the XZ plane, one can employ geometric method to find A2 and A3 (multiple values possible). The following image shows the robot skeleton in the XZ plane (orthogonal to the XY plane of WORLD) of the first joint.

First we compute :

where denote the projection of a vector onto the XY plane of WORLD. Notice that is available once A1 is obtained. Then we compute

so A2 and A3 are given by

Notice that the above formula only gives one possible pair of A2-A3 values that lead to a given position .

Now, we take an algebraic approach to find A4, A5, and A6. First, one can obtain the matrix’s value:

since could be computed from A1, A2, and A3. Based on the following equation:

we finally arrive at the angels A4-A6:

Equation (4) indicates that is a function of A4, A5, and A6. It is easy to find the following invariance:

which leads to multiple solutions of A4, A5, and A6 given a specific .

Additional care should be taken for singularity ( ). The following graph shows that the mapping from a Cartesian position (of flange) to joint angles is not necessarily smooth. The origin of graph is the HOME position (flange’s position in WORLD). When the flange move slightly toward the positive (or negative) y-axis of WORLD, A4 and A5 change extremely quickly to .

The following Java codes (or download TestInverse) illustrate how to perform inverse kinematics with the Robot class:

**double**[] a = { 25, 455, 35, 0, 0, 0 };

**double**[] d = { 400, 0, 0, 420, 0, 80 };

**Robot** kr = **new** **Robot**(a, d); // KR6 R900

**double**[] position = { 525, 0, 890, 0, 90, 0 }; // __xyzabc__, HOME position, flange’s position in WORLD

**double**[] theta = kr.inverse(position, **new** Double(0), **null**, **null**);

**double**[] angles = Robot.*RadToDeg*(theta, “KUKA”);

**References:**

J. J. Graig, Introduction to Robotics, chapters 2,3,4.

P. Schneider and D. Eberly, Geometric Tools for Computer Graphics, chapters 2,3,4.

]]>

Euler angles A, B, and C are essential in KUKA KRL language. This introduction explains and compares three models of orientation: fixed angles, Euler angles (ABC), and the 3-point method.

A typical KRL file starts with

$TOOL=TOOL_DATA[1]

$BASE=BASE_DATA[1]

PTP XHOME

PTP {X 280, Y 0, Z -10, A 30, B 90, C 0}

…

The first two lines specify the TOOL Frame (relative to the FLANGE frame) and the BASE frame (relative to the WORLD frame), after you define them with the teach pendant. The following scripts specify the positions (X, Y, Z) and the orientations (A, B, C) of the tool in the BASE frame.

For instance, {X 0, Y 0, Z 0, A 0, B 0, C 0} means that the tool is aligned with the BASE Frame:

Through this post, TOOL refers to the static (unless one explicitly changes it in KRL codes) frame of the tool relative to the FLANGE. Conversely, “tool” refers to the variable position of the tool in the BASE.

Tips:

To see the TOOL data, navigate in the pendant to Start-up / Calibrate / Tool / Numeric input.

To see the BASE data navigate to Start-up / Calibrate / BASE / Numeric input.

To see the tool’s current position, first set the current TOOL/BASE in the pendant, and then go to Display / Actual position.

**2. X-Y-Z fixed angles**

As Kuka uses ABC representation (Euler angles) instead of fixed angles, this section can be skipped. Nevertheless, understanding fixed angles is critical to grasping the spirit of Euler angles. They are simply two interpretations of one mathematical object!

It is a convention to represent the rotation in a 2D space with a 2 by 2 matrix:

One can obtain the coordinates of a point after rotation by

Extending this formulism into 3D, we get three matrices for rotations about the x, y, and z-axis respectively (here, we replace *cos* with *c* and *sin* with *s*):

Therefore, rotating a point (x, y, z) first by the x-axis, then by the y-axis, and finally by the z-axis leads to

where the x, y, and z axes are fixed (not affected by rotation). That is why people term such representations with X-Y-Z fixed angles.

**3. Z-Y-X Euler angles**

In KRL language, the following transformation {X 0, Y 0, Z 0, A 90, B -90, C -90} can be virtually performed by:

Frist, rotating the tool about the tool’s z-axis through an angle A (90 degree)

Second, rotating the tool about the tool’s y-axis through an angle B (-90 degree)

Third, rotating the tool about the tool’s x-axis through an angle C (-90 degree)

The process is illustrated below:

The intermediate steps are only for illustrative purposes, as the robot does NOT follow these steps to reach the final position. Therefore, the unreachable intermediate state {A 90, B -90, C 0} (third column in the figure) does not prevent the machine from arriving its final destination.

Contrary to fixed angles (1), the matrix for a successive rotation is at the right side of the multiplication in the ABC representation (Euler angles). For instance, rotating about the tool’s z-axis (A) and then about its y-axis (B) amounts to

The general formula for Euler angle rotations is given by

It is surprising that formulas (1) and (2) are identical. This suggests that X-Y-Z fixed angles is the same as Z-Y-X Euler angles!

Our LA (linear algebra) class implements the conversion between ABC and the rotation matrix by the two functions:

**double**[][] matrix(**double** aDeg, **double** bDeg, **double** cDeg) {

** double** a = -aDeg * ** PI** / 180;

m[0] =

m[1] =

m[2] =

}

}

VisualABC1 (dependencies: LA, Processing, and PeasyCam) visualizes the tool in the BASE frame.

**4. 3-point method**

Given the vectors of the tool’s three axes (normalized):

a straightforward representation of orientation is a 3 by 3 orthogonal matrix (whose columns are orthonormal vectors):

We can also incorporate the tool’s position (XYZ)

into the matrix to obtain the following general formula:

Comparing (3) with (2) and (4), we can determine the correspondences between the 3-point method and the ABC model. The LA class offers a method of coverting an orientation matrix to ABC:

**double**[] ABC(**double**[][] m) { // Euler angles from 3*3 matrix

**double** sb = m[2][0];

**double** cb = Math.*sqrt*(1 – sb * sb); // + –

**double** ca = m[0][0];

**double** sa = -m[1][0];

**double** cc = m[2][2];

**double** sc = -m[2][1];

**double** a = Math.*atan2*(sa, ca) * -180 /** PI**;

}

Formula (3) complies with Kuka’s “3-point” method:

1) define the origin o;

2) find a point p on the positive x-axis;

3) find a point q in the XY plane with a positive Y value.

The y-axis can be found by , where . The z-axis can be obtained by cross product of x and y (both normalized): . Therefore, the 3-point method is equivalent to specifying the vectors of x, y, z-axis.

The LA class also contains a method static double[][] matrixBy2Axis(double[] _dx, double[] _dxy) which returns the orientation matrix by 3-point method.

**5. XYZ & ABC**

In linear algebra a point (x, y, z) is often represented by a column vector as in formulas (1) (2) (3). Translating a point is equivalent to vector addition

An alternative is multiplying a 3 by 4 matrix with the column vector:

Now, we can integrate the rotation and the translation into one formula:

which is consistent with (2) and (3).

One can perform transformations with the LA class, for example (VisualXYZABC):

**double**[][] matrix = LA.*matrix*(20, 30, 40, -90, -90);

** double**[] point={50, 0, 0};

** double**[] point_transformed = LA.*mul*(matrix, point);

**6. TOOL & BASE revisited**

Under most circumstances, a Kuka user first defines the TOOL and the BASE with the pendant and then refers to them in KRL codes However, one can always define a TOOL directly in KRL as

$TOOL={X 280, Y 0, Z -10, A 30, B 90, C 0}

where the XYZABC data are relative to the FLANGE. Likewise we may directly write

$BASE={X 0, Y 0, Z -200, A 90, B 0, C 0}

where the XYZABC data are relative to the WORLD.

The contingence of tool and base coordinates makes the serial manipulator unique among CNC machines. We will use this feature in another entry to facilitate turntable use.

**References:**

1) Kuka manual, on tool calibration and base calibration.

2) J. J. Graig, Introduction to Robotics, chapter 2.

3) P. Schneider and D. Eberly, Geometric Tools for Computer Graphics, chapters 2,3,4.

**Step 1: **create the tool path in java:

**float**[][] spline = **new** **float**[num_pts][];

**for** (**int** i = 0; i < num_pts; i++) {

** float** theta = (**float**) (i * 7 * Math.** PI**) / (num_pts – 1);

spline[i] = point;

}

A hot knife will follow the spline to cut the foam.

**Step 2: **Java writes the spline into KRL as a .src file. Finally, copy the first_program.src from the computer to KUKA (KRC:/R1/Program/) and run it. The correspondence between Java, KUKA, and KRL is as follows:

FirstProgram.java includes header(), PTP(), SPL() and other methods. It produces the runnable .src file.

The image above shows that the trajectories of TCP (Tool Center Point) during the two cuts are identical, however, the knife has opposite orientations during the two cuts.

FirstProgram1_visual (dependencies: Processing and Peasycam) visualizes the foam and the tool path.

]]>