array/grid-wise measurement with kuka robot

  • dear ladies and gentlemen,


    i am a junior research associate a we are regularly researching on wireless power transfer systems linked with autonomous driving (WPT-systems) .
    in one of the tasks we wanna create a look-up table of an inductive localization system, where inductive voltages, which depends on a planar disposition, will be noticed / measured.

    so far, i never had contact with kuka robots and stuff around (please consider that, if you give an advice like "ahhh just tune parameter xyz, and abc, and uvw"). also consider, that this working task here is meant to be a prototyping-like issue, means we do not have the human and financial resources to modify the second-hand kuka device, we're having limited access to, time and we won't using it multiple times.


    in last two weeks, i was partially trying to get familiar with the kuka system . i downloaded and used the evaluation version of kuka sim, because i wanted to test certain movements / codes, before i will turn on the real robot.

    the kuka device, we're having access to, is the following (legacy?) setup:


    controller: KR C2 ed05

    robot: KR 240-2 F 2000 (in panel info area listed as KR 2240-2 F)

    linear extenal axis: KL 1500-3

    software and options: kcp_info.png in my nextcloud ('coz limited attachment number here)


    the place, where robot is located, is pretty "crowded". actually there is only one spot, where we can get satisfying displacements. see attached robot_enviroment.png .

    the / a WPT-system generally consists of a primary and a secondary side. you can imaging both as a rectangular planes with a certain thickness.

    the primary coil-side needs to lay on the ground (for realistic behavior (right above / on ferro-concrete)). the secondary coil-side will be covered by an 1.5 x 1.5 m aluminum shield (so called vehicle mimic plate) and is directly attached to robot's flange.


    i also uploaded a schematic demonstration video with a reduced / simplified "calibration grid".

    see simplified_simulated_array_run.mp4 under https://nextcloud.ifak.eu/s/of5LNnR9HP47Mb3


    as you can see, i want the "tool" keeping same orientation over all grid points. later... in real, we wanna granulate the grid to about 100 x 100 sections by an area of about 2 x 1.5 m (x, y)


    when i was trying to implement such simplified code into my kr c2, i crash landed..

    - obviously the krl syntax has changed, so sometimes i need to use "DECL", sometimes not. for-loops don't run with "STEP 1" suffix, and so on

    - second, while moving robot's flange to grid points near to the linear axis, the program is halting with errors like "some axis velocities got over 208%"

    - third also in the near of some of that strange-behavior-points, my robot's wrist (?!) is moving, so the orientation of moving secondary side will not be kept ( in world coordinate system-expressions: A, B and C are changing even if one is steering an x-y-movement, like before)


    after some researches and a quite good video on youtube, i am with the fact, that i have a singularity problems (

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.
    ).

    a kuka's customer support member gave me the hint, that i probably could keep "tool"-orientation with " $ORI_TYPE = #CONST ", but when i m adding this, i only get error #2326 "expected name".


    so does anyone has a cool idea, how i can get my kuka to hopefully reach all grid points with constant orientation of secondary coil (tool)?


    theoretically, if I am correct, it follows from the youtube video that I could add an auxiliary construction to the flange to ensure that, for example, A4, A5 and A6 are never in line when traversing the array.

    That would mean that I could / have to, e.g., attach the wpt's secondary side to the flange at such an angle that the resulting angle between the tool and the flange is greater than theta, which in the sketch occurs at maximum or minimum deflection, right (see sketch.png under https://nextcloud.ifak.eu/s/of5LNnR9HP47Mb3?path=%2F) ?


    if someone could help, especially related to ooold. kuka systems, i would appreciate (-:


    regards

  • Place your Ad here!
  • yes,
    here is the simulation's code snippet :smiling_face:

    Edited once, last by El_Mo ().

  • massula

    Approved the thread.
  • Is this code running on your robot?


    You have mentioned you have a KRC2 ed05 (KSS 5.x) robot, but the robot in simulation looks like a KRC4, and You code snipped looks to have KSS 8.5 or above syntax (KRC4 or KRC5).

  • overspeed issues close to singularities can many times be solved by setting $CP_VEL_TYPE to #VAR_ALL if you are not smack in the middle of the singularity and can tolerate that CP motions may be slowed down where axis velocities are exceeded.

  • .. theoretically, if I am correct, it follows from the youtube video that I could add an auxiliary construction to the flange to ensure that, for example, A4, A5 and A6 are never in line when traversing the array...

    You are right, this would be the best solution.

    Can't imagine that your code will run on krc2, like massula already stated.


    You shouldn't use external links.

  • hi there,


    thanks for responding.

    first of all, you are right. in kuka sim i just can select younger robots at all. thats the reason, why i wrote, that i had to adapt that code to make it run on kr c2 ed 05 ( as i mentioned e. g. "DECL" or "STEP" in for loops, and so on)

    so again, i simulated a whatever robot in modern kuka sim and transfer the code to kr c2. this is not a too big deal, because my code just use for loops and is short. everyone can get this running on kr c2.


    second, yah about the external youtube link. while i was posting and visit my thread again, i also thought "probably this will not be a good tactic in a forum". on the other hand i wanted to share this youtube video, so we all "talking the same language". for future: how am i supposed to quote such external links ? :smiling_face:


    third, Hes

    overspeed issues close to singularities can many times be solved by setting $CP_VEL_TYPE to #VAR_ALL if you are not smack in the middle of the singularity and can tolerate that CP motions may be slowed down where axis velocities are exceeded.

    do you know, how to implement this line in kr c2 exactly? i guess it's the same like "$ORI_TYPE = #CONST". the kr c2 / kr c3 manual is providing this statement, but when i write it in my code, i get an error (2326 - expected name).


    so how and where exactly would i write "$CP_VEL_TYPE = #VAR_ALL" in my code and do i have to use another files like config.dat or anything like that ?

  • so how and where exactly would i write "$CP_VEL_TYPE = #VAR_ALL" in my code and do i have to use another files like config.dat or anything like that ?

    If memory serves it is in operate.dat my assumption is that this variable also exists for krc 2 which i am unfamiliar with.

  • You can not change cp_vel_type in program. Its treated as machine data. If i remember correctly its in $ custom.dat.


    With ori_type it should be #constant not #const probably.


    Fubini

    Yah, thanks for that hint.

    it was a typho. i remember, that i tried both on Friday evening and both didn't work :frowning_face:

    i will give hes' advice an attempt and will place "$CP_VEL_TYPE = #VAR_ALL" in my init section in my kr c2 code on tomorrow morning

  • if that wont work as well, i will sit down and think about a geometrical flange adapter to carry my secondary coil side device.

    i will test, how much angle between "tool" and wrist i get, when i move the flange to most, center and least displacement. technically then i just need to realize, that the adapter's angle is bigger, so i will never get A4, A5, and A6 in a line. i hope this will work and it will still has enough clearance / travel, to reach all of my grid points i the same run

  • i will give hes' advice an attempt and will place "$CP_VEL_TYPE = #VAR_ALL" in my init section in my kr c2 code on tomorrow morning

    Do not try to place this in any init section, alter its value in either custom.dat (as fubini suggested), operate.dat or somewhere else if we all have become senile.

  • good morning @all,


    i found a CP_VEL_TYPE = #CONSTANT line only in custom.dat only.

    i recently edited my kr c2 program and tried to run those PTP-series.

    when i hit the CP_VEL...-line, i'm always get an error, that this parameter is write protected =-(


  • You need to change it in custom.dat. Not in the robot program.

    this is a quit good hint, especially because i cannot find such advice in a manual :grinning_face_with_smiling_eyes:


    i just got a call-back by the helpful kuka support employee:

    he also said,..

    - some variables/parameter you can change on the fly in expert or inline code

    - some of them, it's better to set in init-area

    - some of them better get changed in storage's file

    Another really good hint of him is:

    because those parameter work with ENUM variables, i should advoid writing like..


    " $ORI_TYPE = #CONSTANT ; nice comment here "


    , because the space can/could brake the ENUM detection and this could be the reason, why i got "expected another name" failure


    so i will further give all hints a try now and notify you here :smiling_face:


    thanks in advance

  • space has nothing to do with it. inserting spaces before or after equal sign makes no difference unless you exceed maximum line length (2047 char).

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • space has nothing to do with it. inserting spaces before or after equal sign makes no difference unless you exceed maximum line length (2047 char).

    ok panic,

    i cannot discuss this at the same level as yours,... i'm lagging that skills, but after i changed this "space-thing", i was able to keep $ORI_TYPE = #CONSTANT in my program.

    the negative part of this is, that this advice by kuka didn't changed the orientation problem at all.


    i set up another simplified array-like movement as shown in my video file published on top. this time i successfully could T1-run it without sticking in a singularity and without getting the 208 % velocity error, but i guess only because i didn't stopped at such critically point/location
    ( so: postponed is not canceled, i quess ).


    i tried to visualize the orientation issue in the attached figure


Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners