# Relative and Absolute modes of KUKA operationOperating KUKA in the relative mode

• Hi there

I want to know how exactly the motion commands are interpreted by the KUKA in the relative and absolute modes. As far as my knowledge, this is what I think it is:

Absolute Mode: The coordinates provided to the KUKA as input will move the KUKA by the given input with respect to the KUKA home position(user-defined). It does not consider the current/previous position For eg: if (10,20,-15) is provided as the input, the KUKA moves 10 mm, 20 mm and 15 mm in the X, Y Z directions respectively from the home position.

Relative: The coordinates provided to the KUKA as input will move the KUKA by the given input with respect to the current postion of the KUKA. Taking the same input as above, let's say the KUKA is currently positioned at (20,50,-30). The new position of the KUKA will then be (30,70,-45)

Please correct me if I'm wrong (which I'm quite sure I'm)

Also, in my application I'm moving the KUKA to the home position using the PTP command in the KRL program. There onward I want the KUKA to move in the relative mode, interpreting the input as incremental values, instead of absolute. This I guess is done using PATHCORR. The object parameters of the RSI object ST_ON1 specifies the coordinate system and the mode for PATHCORR as:

ST_ON1(A,B)
eg: ST_ON1 (Base, 1/0)
1/0 define the integration mode

1: Relative
0: Absolute
The integration mode defines how the coordinates sent to the robot are interpreted by the controller.
In case of relative mode, the coordinates sent to the robot are calculated from the actual position of the robot
However, in my code the parameter defining mode, is already set to 1. So I assume I'm operating the KUKA in relative mode only.

Also, In case we need to initially move the KUKA in the absolutre mode to some pre-defined position (say HOME) and then switch its operation to the relative mode, in order to interpret the input as incremental values, How will I be able to do this?

Kindly help.

• First: KRL programmed motions, and RSI controller motions, are completely separate things, although they do share the same concepts.

KRL motion locations are normally programmed as E6POS variables, which are Cartesian coordinates, although some positions, like HOME, are usually programmed in E6AXIS, to explicitly control the axis angles.

Any Cartesian location in KRL is treated as a multi-stage 6-DOF transform, using the current values of \$BASE and \$TOOL. This can become rather complex, but briefly, \$TOOL defines the location of the Tool Center Point (TCP) whose position the robot is controlling, relative to the mounting flange on Axis 6. \$BASE defines that current active reference frame of the robot, as a transform relative to \$WORLD. \$WORLD is usually colocated with \$ROBROOT, which is located in the bottom center of the robot's baseplate.

Due to the interaction of \$TOOL, \$BASE, and E6POS positions, a single Position can move the robot to multiple locations in physical space, depending on changes made to \$BASE and/or \$TOOL. A palletizing program, for example, might shift \$BASE as the counters increment through the palletizing pattern, while an end effector mounting both a vision system and drilling tool might switch between \$TOOL settings at the same programmed Position, in order to bring both tools to bear on the same point in space without maintaining separate copies.

Relative motions can be commanded in either Cartesian or Joint space. Cartesian relative motions can also be commanded relative to \$BASE, or \$TOOL.

• Thanks for the reply SkyeFire
Although I don't understand much (being from a Electronics background). Could you please let me know how do I operate the KUKA in the relative mode (this is within the RSI code). I want the KUKA to interpret the input as an incremental velocity command rather than absolute positions.
Thanks

• That's... some pretty deep water, there. You really want to be well-grounded in how KUKAbots function when you try this -- RSI is powerful, but also dangerous. It can cause the robot to move at near-automatic speeds even in T1, and a badly-tuned PID object can make the robot move so violently as to damage itself just from inertia. RSI operates "beneath" several of the "safety nets" in the system.

POSCORR objects generally operate in relative mode already, starting from the robot's position when the RSI_ON command was issued. The POSCORR objects can be selected to operate in Tool or Base. However, these are explicitly positional commands -- to command velocity, you're essentially going to have to integrate your desired velocity into an equivalent positional increment. Since RSI (usually) updates every 12ms (4ms for some limited modes), you can work backwards to your integral factor from there. You can build a set of PID objects between your input and the POSCORR to do the conversion.