Posts by nicok

UPDATE:

After finding out what was missing in the code I managed to run into a more fundamental problem. Apparently $GEAR_JERK is write-protected when the subprogram is called (as can be seen in image below in German). I have no idea why it should be write-protected, since I specifically didn't access $GEAR_JERK_C which I know is write-protected. Does anyone know how to circumvent this or is the only option to use a constant jerk limit for the whole SPTP motion?

In other news, if anyone ever wants to do something similar, I needed to fix a couple of mistakes in the code and now it works with acceleration & velocity constraints at least. Turns out spline motions are a bit finnicky in what parameters they expect.

• TRIGGER WHEN always needs either the DISTANCE or PATH argument. Keep in mind that DISTANCE doesn't work with SPTP. The DELAY is applied relative to the position determined by either of these (see documentation).
• If the trigger calls a subprogram you also need to insert PRIO, where a value of -1 lets the operating software schedule the priority of the subprogram call.
• Both $ACC_AXIS as well as $VEL_AXIS understandably expect values of at least 0.1 or greater but my python script that created the motion profile starts with zero acceleration. Not a big deal but I suggest to set a reasonable minimum value in your scripts from the get-go.

DEF Approach4()

...

PTP {A1 0.00000,A2 -90.00000,A3 90.00000,A4 0.00000,A5 90.00000,A6 -0.00000,E1 0.00000}
PTP SP1 C_PTP
ChangeKinematics(7, 36, 100)
PTP_SPLINE
   TRIGGER WHEN PATH=0 ONSTART DELAY = 10 DO ChangeKinematics(1, 1, 100) PRIO=-1
   TRIGGER WHEN PATH=0 ONSTART DELAY = 500 DO ChangeKinematics(100, 100, 100) PRIO=-1
   TRIGGER WHEN PATH=0 DELAY = -100 DO ChangeKinematics(7, 36, 100) PRIO=-1
    SPTP SP2
ENDSPLINE
END

DEF ChangeKinematics(jrk:IN, acc:IN, vel:IN)
DECL INT ax
DECL INT jrk
DECL INT acc
DECL INT vel
FOR ax = 1 TO 6 STEP 1
    ;$GEAR_JERK = jrk
    $ACC_AXIS[ax] = acc
    $VEL_AXIS[ax] = vel
ENDFOR
END

Quote from Hes

I do not know if it holds true but sptp's seem smoother than traditional ptp moves. Im speculating this is because they are bound by diffrent limits

This one I can clear up. The spline motions of Kuka are based on piecewise polynomials of order 5 afaik, which in turn means the position is four times continuously differentiable. If we were to differentiate three times we see the jerk is a piecewise quadratic function (and the snap being linear). This creates a motion that induces significantly less oscillations at higher frequencies (something like >5 Hz). Of course the oscillations occuring in practice are highly dependent on the system.

I only found a website plotting this for S-curves based on third order polynomials. It should look similar for fifth order ones but with a stronger shift of the energies towards f=0.

Thanks so, so much for the huge amount of info and feedback from all of you, it is truly invaluable to me right now!

Quote from Hes

You can check $ACC_AXIS_MA[] there might be a typo in the variable name but it should point you in the right direction

I haven't found a mention of $ACC_AXIS_MA[] in the systems variables handbook but I assume I will find it either in R1/$machine.dat or together with $RAISE_TIME[] in the motor configuration xml-File of the specific axis that Fubini mentioned. But maybe I will just write a program and do an acceleration test. We have acceleration sensors for the tool and if I simply test the individual accelerations of each axis I will get a rough idea of what to expect.

Quote from Fubini

If you want full control over how the robot accelerates and decelerates yourself the only option I can think of is using the RSI package.

Last but not least what you also could do is just "measure" the resulting accelertions by using the built-in oscilloscope function (aka trace) inside the KRC.

The company actually has bought the RSI package for the robot but due to a PLC defect we're using the X11 interface instead and from what I've read without a PLC it is impossible to use the RSI.

Thanks a lot for the tip with the built-in oscilloscope but as I mentioned earlier we have acceleration sensors on hand which I prefer to use, since they are already set up anyway.

Quote from Hes

If your tool is flimsier in some direction you can quite comfortably set $ACC_AXIS[6] to something decently low if it is sloppu around flange z axis.

But stiffening up your tool and lowering accelerations and setting speeds, approximation etc up perfectly would be my suggestion.

I will certainly keep in mind to use lower accelerations for axis 6 since our tool is especially flimsy around the flange Z axis. Actually we have planned for creating a stiffer version of the tool in the near future. Unfortunately 'near' is most likely next year which won't make it in time for my thesis deadline.

I've tried to integrate all the feedback for another iteration of the example programs. Especially feedback on Approach 4 would be greatly appreciated as the option to limit jerk would be wonderful for me.

Approach 1 and Approach 3 would stay mostly the same but instead with $ACC_AXIS[] and $VEL_AXIS[].

Approach 2 got canned.

If I want to limit jerk I'd need to use spline motions, as they enable me to either set $GEAR_JERK or take the more customizable route via $SPL_VEL_RESTR with $ACC_AXIS[] and $RAISE_TIME[]. I've written Approach 4 that would do this with SPTP motions and a subprogram for changing the kinematic parameters (jerk, acceleration, velocity). If I only want to use SPTP for the sake of a single PTP motion I shouldn't need to program any additional points in between my start and goal as all the spline supports are computed by the robot controller, is that correct?

DEF Approach1()

$BASE = {FRAME: X 0.000,Y 0.000,Z 0.000,A 0.000,B 0.000,C 0.000}
$TOOL = {FRAME: X 50.000,Y 0.000,Z 450.000,A 0.000,B 30.000,C 0.000}

…

FOR ax = 1 TO 6
    $ACC_AXIS[ax] = 20       
    $VEL_AXIS[ax] = 20
ENDFOR

PTP XP1 C_PTP

FOR ax = 1 TO 6
    $ACC_AXIS[ax] = 50    
    $VEL_AXIS[ax] = 50  
ENDFOR

PTP XP2 C_PTP

FOR ax = 1 TO 6
    $ACC_AXIS[ax] = 100      
    $VEL_AXIS[ax] = 100  
ENDFOR

PTP XP3 C_PTP

…

END

DEF Approach3()

$BASE = {FRAME: X 0.000,Y 0.000,Z 0.000,A 0.000,B 0.000,C 0.000}
$TOOL = {FRAME: X 50.000,Y 0.000,Z 450.000,A 0.000,B 30.000,C 0.000}

…

FOR ax = 1 TO 6
    $ACC_AXIS[ax] = 100    
    $VEL_AXIS[ax] = 100  
ENDFOR

$OV_PRO=25
PTP XP1 C_PTP

TRIGGER WHEN DELAY = 100 DO $OV_PRO=50
TRIGGER WHEN DELAY = 200 DO $OV_PRO=75
TRIGGER WHEN DELAY = 300 DO $OV_PRO=100
PTP XP3 C_PTP

…

END

DEF ChangeKinematics(factor:IN)
    DECL INT factor
    FOR ax = 1 TO 6
        $GEAR_JERK[ax] = factor    
        $ACC_AXIS[ax] = factor    
        $VEL_AXIS[ax] = factor
    ENDFOR
END


DEF Approach4()

$BASE = {FRAME: X 0.000,Y 0.000,Z 0.000,A 0.000,B 0.000,C 0.000}
$TOOL = {FRAME: X 50.000,Y 0.000,Z 450.000,A 0.000,B 30.000,C 0.000}

…

ChangeKinematics(100)
PTP XP1 C_PTP

ChangeKinematics(20)
PTP_SPLINE
    TRIGGER WHEN DELAY = 100 DO ChangeKinematics(50)
    TRIGGER WHEN DELAY = 200 DO ChangeKinematics(75)
    TRIGGER WHEN DELAY = 300 DO ChangeKinematics(100)
    SPTP XP3
ENDSPLINE

…

END

First of all, I would like to say a big thanks to both of you. The info you've provided was already a huge help (from what I can tell). I'll try to address everything one by one.

Quote from SkyeFire

So, my first question is, what's wrong with the robot's inherent accel/decel profile that you want to improve?

There isn't anything 'wrong' per se. We move a relatively large tool, which is basically a 50kg heavy, 2.5m long aluminum construction, that exhibits quite a lot of oscillations at the endpoint of a motion. Due to the robot being used for x-ray imaging, we only tolerate small oscillations during image capture so as to not impede the image quality.

Hence, part of my master thesis is to implement a way to reduce these oscillations to allow for faster cycle times. My core idea is to test a couple of different acceleration profiles for their ability to induce less oscillations in the first place. That's why I need the ability to change not only the ramping time but the accel/decel profile as a whole.

Quote from SkyeFire

All three of your examples look valid, insofar as they should execute without causing any KRL errors. Your $VEL and $ACC values may be a bit high (depends heavily on robot payload and pose).

That's a big relief. I'll probably testing Approach #3 first, as it would be more flexible for my purposes. But if I run into problems I'll likely fall back on Approach #1 and use that instead.

Quote from Hes

hang on.. isnt ptp motions only limited by axis speed $VEL_AXIS[] and axis acceleration $ACC_AXIS[]? Atleast that has been my understanding. $VEL or $ACC would do nothing for a ptp motion.

Now that I read over the documentation again I have definitely confused ORI1 and ORI2 for the axis acceleration. Thanks for the heads up, I will definitely have to use $ACC_AXIS[] and $VEL_AXIS[] instead.

Quote from SkyeFire

For example, if you command the robot to accelerate at a rate it physically can't, it will simply apply the maximum acceleration it can. And the physical limit changes, not only with robot payload, but also robot pose and inertia.

I'm well aware of that but for the most part it doesn't matter too much for me right now. The main concept behind the oscillation reduction is based on limiting acceleration/velocity at the right times. I don't mind as much if the motion is slower by a second or even two as long as I don't get more oscillations than intended. The oscillations I encounter usually take 3-10 seconds to die down which takes a lot more time overall when I move to 12 different positions.

I do have two new questions you guys might be able to help me with.

The data sheet for the KR150 2700 extra we use states the maximum speed at 150kg is:

A1: 123 °/s, A2: 115 °/s, A3: 120 °/s, A4: 179 °/s, A5: 172 °/s, A6: 219 °/s
Am I correct in assuming that I can safely set $VEL_AXIS[] to any value that is equal or smaller to these? Of course if the robot ever reaches these velocities during a motion is a completely different question.

What joint acceleration values does the robot realistically use? In the KUKA docs I haven't found any information at all so far and I don't know if the range is something like 250-500 °/s² or more like 5000-10000 °/s² or anything in between. I only need a rough estimate to know the range I am working with.

Hello everyone,

I am currently trying to approximate a custom acceleration profile for PTP motions. The robot is basically only used to perform rotations of the tool around the TCP, which is why I had some prior issues using LIN motions and decided to stick to PTP motions for now. My intention is to e.g. create a motion that is somewhat similar to an S-curve acceleration profile.

S-curve acceleration profile

(Please excuse the small size, I simply couldn't manage to upload the image directly)

From what I gathered so far, such an acceleration profile could be either accomplished by chopping a single motion into several smaller motions and change $ACC and $VEL in between (orange curve) or by adjusting the program override $OV_PRO either at certain time intervals or in between motions which would result in a smoother acceleration profile but also reduce the programmed velocity by the same factor. I hope I am correct in my understanding so far.

I tried to create example programs to implement this but unfortunately, I only have basic knowledge of KRL programming and limited robot access at the moment. Can anyone tell me if any of my approaches should work as intended or if there are major things I’ve overlooked?

DEF Approach1()

$BASE = {FRAME: X 0.000,Y 0.000,Z 0.000,A 0.000,B 0.000,C 0.000}
$TOOL = {FRAME: X 50.000,Y 0.000,Z 450.000,A 0.000,B 30.000,C 0.000}

…

$ACC.ORI1 = 400.00000
$ACC.ORI2 = 400.00000
$VEL.ORI1 = 100.00000
$VEL.ORI2 = 100.00000

PTP XP1 C_PTP

$ACC.ORI1 = 600.00000
$ACC.ORI2 = 600.00000
$VEL.ORI1 = 250.00000
$VEL.ORI2 = 250.00000

PTP XP2 C_PTP

$ACC.ORI1 = 800.00000
$ACC.ORI2 = 800.00000
$VEL.ORI1 = 500.00000
$VEL.ORI2 = 500.00000

PTP XP3 C_PTP

…

END

DEF Approach2()

$BASE = {FRAME: X 0.000,Y 0.000,Z 0.000,A 0.000,B 0.000,C 0.000}
$TOOL = {FRAME: X 50.000,Y 0.000,Z 450.000,A 0.000,B 30.000,C 0.000}

…

$ACC.ORI1 = 400.00000
$ACC.ORI2 = 400.00000
$VEL.ORI1 = 100.00000
$VEL.ORI2 = 100.00000

$OV_PRO=25
PTP XP1 C_PTP

$OV_PRO=50
PTP XP2 C_PTP

$OV_PRO=75
PTP XP3 C_PTP

…

END

DEF Approach3()

$BASE = {FRAME: X 0.000,Y 0.000,Z 0.000,A 0.000,B 0.000,C 0.000}
$TOOL = {FRAME: X 50.000,Y 0.000,Z 450.000,A 0.000,B 30.000,C 0.000}

…

$ACC.ORI1 = 400.00000
$ACC.ORI2 = 400.00000
$VEL.ORI1 = 100.00000
$VEL.ORI2 = 100.00000

$OV_PRO=25
PTP XP1 C_PTP

TRIGGER WHEN DELAY = 100 DO $OV_PRO=50
TRIGGER WHEN DELAY = 200 DO $OV_PRO=75
TRIGGER WHEN DELAY = 300 DO $OV_PRO=100
PTP XP3 C_PTP

…

END

Thanks for the extensive explanation.

Quote

I should ask: are you aiming for smooth continuous motion along a complex path, or a discrete start/stop at every scan point?

In a perfect world we'd only need discrete start/stop motions as the basic task for our CT scanner-robot is to: 1. move to pose, 2. wait n milliseconds, 3. take CT image, 4. move to next pose and repeat. Unfortunately, due to our huge tool dimensions (~2m long metal arch with X-ray source & detector at the ends) we need to account for oscillations which means we will need to control the deceleration.

I guess we might be able to approximate a "quasi-continuous" end of our path with discrete start/stop motions by dividing the last part of the path into a handful of points and use PTP motions with the desired deceleration. But I am not sure how "choppy" the motion is that could be generated with this approach.

Damn. These types of answers should be added to the official documentation. Thanks a lot guys!!!

Thanks so, so, so much!

I had no clue there was an option package just for uploading modules to the controller, I expected this to be included with any networking package.

With "Directory Loader" as a keyword I managed to find a lot of the necessary info on how Kuka handles networking with external devices and what is required. This basically answered all of my questions.

The project finances are stretched thin right now so we try to avoid paying 2k€ for the Directory Loader. For now we decided to take a look how much development work C3Bridge would mean for our application. In the meantime I also found out we might be able to make do with RoboDK's online programming capabilities. For the research project the focus is to show that certain path planning methods are working, so as long as we can generate, send & execute our code remotely we don't need to upload anything.

Controller: KRC4

OS: KSS 8.6.514

Safety-Interface: X11(but ProfiSafe theoretically available)

After an exhausting couple of months and visits from the service technician we finally have a working KRC4 and robot arm again. While everything works fine when done by hand (downloading/uploading projects & programs via WoV, executing programs in T1/T2, etc.) the goal of our research project is to automate a robot-based CT scanner. This means that the robot programs we generate need to be uploaded and executed automatically. After bashing my head against the wall for ~3 months regarding connectivity issues I am sufficiently confused and unsure what the best way to go about this is. Should I look to get this working using WoV/LabView/Python/C++ scripts? Do I have to get a PLC and Profinet and use those? Are there other/multiple options? Right now I am mainly looking at the best starting point to continue bashing my head against the next wall.

In summary:

1. Is uploading & executing programs "at the press of a button" generally possible using the Ethernet/IP connection (Ethernet KRL 3.1)?
2. Can I upload program files to the KRC4 and send the command to execute them by communicating via a C++/Python script or LabView?
3. If I want to communicate via the Ethernet connection outside of WoV then I am forced to use the EthernetKRL server, is that correct?
4. Is it possible for a separate program/script to make the running server do something s.a. upload a XML file?
5. What other documentation should I look at apart from the one for "Ethernet KRL 3.1" and "WorkVisual 6.0"?

Any feedback on the matter is much appreciated. I will gladly dive right back into the documentation but would like to start by looking in the right place if that makes sense.