Force torque configuration blocks RSI

FTC is simply an advanced usage of RSI, using several "black box" objects that KUKA provides.

Quote from John Black

1. Input: With the input blocks i get the data from the force-torque sensor.

2. Offsetscale: The Offsetscale block is not really clear for me. For what is that?

3. ZeroGravTrafo: The data will be transferred from sensor coordinate frame into the toolcenter point coordinate frame.

4. FTCtrl is the controller. What type of controller is it? By reading some books I think it is a PT1-controller?

5. PosCorr: From the 6 separate controllers (with certain gain factor Kr) the processor calculates the correction of the path that the robot makes.

1. Correct. In this instance, it appears that the robot is receiving 6 32-bit values starting at $IN[1]

2. OffsetScale isn't an object I'm familiar with, but it would appear that it does what the name suggests: it offsets the 0-reference of each channel, and alters the scaling of each channel's 32-bit value into values used by RSI. These values should be set automatically as part of the FTC configuration menu

3. ZeroGravTrafo is supposed to attempt to correct the sensor inputs for gravity effects. For example, if your Force-Torque sensor was mounted between the robot's A6 flange and the end effector. I've never used it, as all of my FTC applications were designed to avoid the need.

4. FTCtrl is a "black box". It contains a great deal of complex custom RSI coding written by KUKA, and is part of why you pay for FTC instead of just buying RSI. Technically, it is "just" a 6-DOF PID controller, but it contains a great deal of complexity for handling inertia, gravity, and a multiplicity of other factors, all tested heavily by KUKA.

5. PosCorr is a basic RSI object. It applies Cartesian corrections along/around each axis of the active Base/Tool combination, in realtime.

Quote from John Black

When I have a look at the FTCtrl object on my smartPad I can insert only the Kr factor. This should be the P-controller.

IIRC, the Kr factor was a strange combination of the P and D gains. The RSI Help file had a detailed description, with an algebraic formula describing the exact relationship.

Quote from John Black

But the I controller I can set only on the RSI-object and not on the smartPad of the robot. Why I can set the value for tht I-controller only on the FTCtrl object and not on the smartPad?

In the past, the FTC object was never exposed like this, and you never entered individual gains. Instead, "gain" configuration was done only through the FTC Config menu, and it wasn't called gains -- instead, it was menu items like "speed" and "stiffness", which roughly equated to P and D.

Either FTC has changed quite a bit over the past few years (entirely possible), or you are using a non-standard version.

Quote from John Black

And is the FTCTRL object for sure a PID controller? Because if I see this right I can insert only P and I value but not a value for D. So it should be a PI-controller?

Oh, it's a full PID controller. But not every gain is exposed for your manipulation.

Quote from John Black

Is this officially mentioned somewhere from KUKA side? I have studied the manual of the KST_ForceTorqueControl_41 and KST_RSI_41. But I did not found this special information. There is only described the mathematical equation of PID. The thing is I am writing a project report from my University and I want refer that there is working inside a PID controller for force control, but without an official document from KUKA where this is described I did not want to mention this.

Ah. Well, at this level of detail (and keeping in mind that my knowledge is rather dated), the FTC block itself is not necessarily a full PID -- for one thing, eliminating the I factor could help avoid runaway conditions, and restart-windup.

That said, FTC/RSI are still just layers atop the deep architecture of the robot's kinematic planner, which is multiple PID controls all interlocking in complex and proprietary ways. FTC/RSI gets you a lot closer to "bare metal" than programming in KRL, but you're still not directly controlling raw servo inputs, for example. $FILTER, for another example I can recall encountering, is basically a low-pass filter applied even to FTC/RSI control, to try to protect the robot from badly-programmed PDs creating "jackhammer" effects and wrecking the arm.

Quote from John Black

How this Kr factor is in a real application set up? With try and error? For my application I start with a small Kr factor und I try to increase the factor until the sensorguided movement gets instable. Is this way of setting up Kr factor right? Or is there in real life a mathematical equation to set a perfect Kr factor?

Most PIDs in the real world are tuned empirically. There's simply too many factors that can't be modelled with sufficient accuracy.

Looking at the raw RSI elements, instead of the FTC docs, shows this for the P, PD, and PID objects. I think it's probably safe to assume that the PD inside the FTC block operates similarly, as FTC is just an implementation of RSI. KR, TV, and TN are, IIRC, the "gain" inputs to the objects.

The attached Zip contains a Help file for an older RSI version, that goes into somewhat more depth describing the various Objects and gains.