A robot mounted on a linear axis - how is it controlled?

Hi,

There are many different methods for the handling of redundancy caused by the external axis. Inside the kuka controller the external axis is always handled separetly of the robot that is the external axis always uses a ptp-move from its taught in starting to its taught in final position. Hence at each position along the path the external axis values are known and can be used to evaluate the flange of the external axis system. The result of this operation then is used to solve the inverse kinematics for the robot. So basically {X, Y, Z, A, B, C} still is the position in the base-system that you want to drive to. Part of this movement is already handled by the taught external axis values E1. Only the remaining delta to the desired cartesian position is handled by the robot axes.

Quote

I mean, if the robot is told to move to a point that is outside of its reach, will it automatically move along the linear axis in order to be able to reach?

No. you have to teach a external axis value that allows reaching the desired cartesian position.

Quote

How does the solver choose one of the solutions? Is there some sort of weight function involved?

As mentioned above the robot always uses a ptp-external axis movement. No weight functionat all.

Quote

Do the tcp-coordinates on the teach-pendant change when the robot is moved along the axis, or does the robot not know that it is moving, but only that it has an external axis?

That depends on the chosen reference frame. If e.g. in manual jogging mode you chose "axis reference frame" the tcp moves with the external axis if the external axis is jogged. If you choose "cartesian jogging (e.g. relative $WORLD,$BASE) the tcp does not move when jogging E1. Similar behaviour you get comparing PTP_REL {A1 0, E1 100} vs.
PTP_REL {X 0, E1 100}. In the first case the tcp changes in the second case the tcp stand still.

Quote

And finally: If the tcp-coordinates on the teach-pendant change when the robot moves along the axis, then it means that the direction of the axis is known to the robot. How is the robot and the axis co-calibrated? Or is there only one way of mounting the robot on the axis, and therefore no need for calibration?

How the robot is mounted on the linear axis is configured inside the machine data file R1/$machine.dat. ($ERSYSROOT, $EX_KIN, ...) . The setup can be made using WorkVisual (KRC4) or axis configurator (KRC2). For high accuracy after setting up the system you can "measure in" the linear axis on the HMI (similar to "measure in" bases and tool).

Fubini

An external axis can be kinematically integrated, or not. If the former, the motion of the external axis is part of the robot's Cartesian position. If the latter, then it is handled separately.

For example, take a standard KUKA KL1500 linear axis for carrying the robot. By default, this axis is kinematically integrated. The World coordinate frame is effectively "detached" from the base of the robot and "mounted" to the linear rail. So, the the robot is mounted such that the axis of the rail is parallel to the Y axis of the robot, the robot's Cartesian envelope would expand in the Y direction. Jogging the robot along the rail would cause the TCP position to change, even if the arm axes did not move at all. Kinematic integration makes it possible to move the arm and the linear axis in a path-integrated fashion. For example, I once programmed a KR to loop through two positions with identical XYZABC values, but different E1 values, as LIN motions. The effect was that the TCP stayed at the same location in space (minus noise) whilst the linear axis "wiggled" back and forth underneath.

However, if the external axis is not kinematically integrated, the robot is "blind" to any effects that axis has on TCP positions. Most users don't use this option for axes that the robot is mounted on, but some do, for whatever reason. This removes the ability to coordinate interpolated motions of the robot with the motion of the external axis, although their motion will still be time coordinated. Generally, people choosing this option just use the rail to index the robot to a working position, then "freeze" the external axis while the arm goes about its business.

I would say it is quite similar to ABB, based on my experience with both systems. Jogging, for example -- IIRC (it's been a few years), the ABB's linear axis would carry the robot in a fixed pose if you jogged the linear axis in Joint mode, but jogging the linear axis in one of the Linear modes would cause the TCP to maintain position in space while the base of the robot moved. The KUKA setup behaves in a similar fashion.

The one thing I found ABB had that I wished KUKA did was the EOffSet command. That came in very handy.

Quote

The one thing I found ABB had that I wished KUKA did was the EOffSet command.

SkyeFire:
Can you describe what this command on ABBs does. I am asking because we are currently working in different strategies for the redundancy solution of the external axes. The already mentioned teaching of external axes position in many cases is not very optimal, hence we are trying to get rid of it and would like to replace it with automatic calculation off optimal external axis position in the controller.

Thanks in advance,
Fubini

The command would add an offset to any given external axis, and that offset would remain until the offset was cleared using the correct command (I don't recall the exact syntax). I used it in a situation where the robot was removing parts from a multi-row, multi-column rack, using WorkObject shifts, but getting parts out of the left side of the rack required the linear axis to be on the right side of the rack, and vice versa. Using the EAxisOffs command allowed me to mathematically shift the linear axis separately from the WorkObject shifts without giving up kinematic integration (since I also had to perform flying searches using all 7 axes to reach around a corner without stopping).
The closest equivalent on a KUKA would, I think, be changing $MAMES on the fly, but I don't think that variable can be written to.

Hi Skyfire,

thanks for your explanation of EOffset. It is is still somewhat inofficial and I dont know of any official documantation but you get on a KRC4 pretty much the same feature by setting $JOINT_OFFSET[1-12] = shiftValue.

Fubini

Ooooooo!