Function for calculating a new Base frame in a program

    Hello!

    I need to create a new base coordinate system within a running program. The robot will move to three calculated points where one will depict the origin, the second point the positive x axis direction and the third a point in the xy plane. in other words I need to copy the 3 point base calculation process within a program. Is there a function that can do this? Three points as input arguments and a calculated base[x] frame as an output? ??? ???
    Then I would assign this frame as the active base frame and move the robot to predefined positions.
    Thank you in advance!

    cosva

    Edited once, last by cosva (November 10, 2011 at 8:54 PM).

    Quote from SkyeFire


    That's not a simple task. Are you doing this just for initial setup, or does it have to be done on the fly in the program?

    Well the problem is that I am not doing it for an initial set up. While running a program the robot calculates 3 points which should describe a new base frame. So it should be done on the fly without stopping the running program... :wallbash: :wallbash: ???


    Quote from SkyeFire


    The former is a simple menu-driven setup task under CONFIGURE>MEASURE>BASE. The latter involves some non-trivial mathematical coding.

    Well a certain workaround before coding the mathematics for creating a new base frame for me could be the manual menu-driven setup but with one certain addition. Is it possible to move a robot to a certain position and then use CONFIGURE>MEASURE>BASE and only record one point depicting the origin. Then start the robot program again where the robot moves to the positive x direction point, I would then record this point in the same CONFIGURE>MEASURE>BASE. And make the same procedure for the point in xy plane. My problem is that whenever I exit the CONFIGURE>MEASURE>BASE procedure I cannot get back inside the one which I started and I was not able to split the screen to have a program and also the CONFIGURE>MEASURE>BASE window. ??? ???
    On a FANUC robot I could do this, the R30iA controller allowed simultaneous creation of a frame and in another window I could run a robot program and drive the robot to the calculated positions. Is this possible with KUKA? I hope that the answer will be positive :toothy9:

    I was quite tempted to have a go at this today, but it turns out I've got some proper work that needs doing.

    Anyway, I'll explain the process that I would use.

    I guess that the first question to ask is how good is your maths - specifically 3D transforms and matrices? If you're familiar with these it should be a reasonably easy task. If not (which I guess is more likely, since not many people know this stuff well), then it's going to take a bit longer.

    1. Collect the 3 points into variables.
    2. Subtract the origin coordinates from the x-axis point coordinates to get the x direction vector.
    3. Subtract the origin coordinates from the xy plane point coordinates to get another vevtor in the xy plane.
    3a. (Almost forgot) Normalise the two vectors by dividing the elements by the length of the vectors.
    4. Take the cross product of the two vectors that you have to create the z direction vector.
    5. Take the cross product of the z and x vectors to create the y direction vector.
    6. You now construct the rotation matrix for the frame. The first column contains the elements of the x direction vector, the second column takes the y direction, the third column takes the z vector.
    7. Now calculate the ABC values from the rotation matrix:

    Code
    A = Atan2(rot[2, 1], rot[2, 2]);
B = Atan2(-rot[2, 0], Sqrt(rot[2, 1] * rot[2, 1] + rot[2, 2] * rot[2, 2]));
C = Atan2(rot[1, 0], rot[0, 0]);

    I took this code from a c# program (and simplified it a little), but I can't remember exactly what maths functions are available in KRC, so you'll have to figure out how to do the above calculations in the controller.

    Edited once, last by bert (November 11, 2011 at 10:49 AM).

    Quick assumption (that is probably wrong :smiling_face: )

    Isn't your base flat to the robot so that elimenates the need to calculate the Z value? (and as result we can assume B,C angle 0)

    Also third point is just to show the robot in which direction Y will be going (and Z in consequence)
    So maybe it will be easier to just calculate positive X first and then based on third point add Y and Z to it (90 degrees offsetes).

    Again this may sound like I am idiot :smiling_face:
    Please correct an idiot :smiling_face:

    Thanks for the reply! :yesyesyes:

    I feel really "stupid" now that I "made" you write the whole procedure but hopefully it will help also someone else! :yesyesyes:
    I will program the function in C++ or Matlab because I suppose that it will be too much of a bother to do it in KRL...
    To me it is very strange that Kuka does not have this function embedded inside it's software... ???

    Thanks again! :beerchug:

    I don't think it should be too much bother in KRL.
    I had a look through an old program I wrote to do frame interpolation, and all of the maths functions seem to be there in the robot controller.
    We've got a new lad here at work who was looking a bit bored this morning, so I thought this would be a good challenge for him to implement. I'll give him a few hours and see how he gets on with it. If he does a decent job I'll post up the results later.

    Quote from bert


    I'll give him a few hours and see how he gets on with it. If he does a decent job I'll post up the results later.

    So has he done a decent job? :icon_mrgreen:
    You can even post your frame interpolation KRL code because I think that I might find it useful to see how to you handle maths in KRL...

    Unfortunately, it turns out that my confidence in him was misplaced :smiling_face: I guess it was a little dificult for a newbie.

    Anyway, I got bored of watching him struggle with it so I had a go myself. It's been a while since I've worked with Kukas, so I struggled a little to get my GLOBALs working correctly. I'll tidy it up a little and post it later today.

    As for the interpolation code, just look through my previous posts and you'll find it.

    Edit: Here it is https://www.robot-forum.com/robotforum/kuk…g19849#msg19849

    Second edit: Attaching some files...

    Third edit: I've combined the interpolation code with the frame creation code so that everything is available in a single module

    Fourth edit: A and C were reversed in the calculation - this is fixed no along with some other small issues

    bert
    thx for all coding , I tested it and it works but either I am doing something wrong or there is a small error somewhere

    base origin is in front of the robot with X positive pointing back at robot at 15 degrees angle
    your function calculates it correctly but it seems to mix A,B and C somewhere
    my base is flat with the robot base so B and C angles should be zero and 15 degrees off at A (A 165,B 0,C 0)

    attached is a screenshoot of my results,
    please correct me if I am doing something wrong
    P1 is origin , P2 positive X and P3 positive Y

    There's a good chance I've mixed up the A and C angles in the calculations.
    I didn't really test the software, other than to make sure it compiled on the robot.
    Let me have a look at it and get back to you.

    Edit: A and C were reversed in the calculations. In my original code, there were 2 reversals and I only saw one of them. I also made some fixes to deal with the case when B is +/-90

    Edited once, last by bert (November 17, 2011 at 3:52 PM).

    Ah...the KRL ATAN2 function takes its arguments the wrong way round :smiling_face:
    I really should test code that I write.

    I'm still not convinced about the value of C that you're suggesting. There shouldn't be any need to have any value in C, since at the singularity it is the sum (when B is -90) or difference (when B is 90) of A and C that matters.

    Again, I haven't actually tested this on a robot - only on paper and it seems to work ok. I'll try to get on a real robot later to see what I can find out.

    Anyway, thanks for the info. I'll change the code so that the B calculation is correct and repost.

    Edited once, last by bert (December 2, 2011 at 4:48 PM).

    I had set up two frames. The first had XDIR of (0,0,-1), YDIR of (-1,0,0) and ZDIR of (0,1,0). And the second had XDIR of (0,0,1), YDIR of (-1,0,0) and ZDIR of (0,-1,0).

    For the first frame your program calculated angles (A 180, B 0, C 0) and for the second frame (A 0, B 180, C 0). We know B was wrong and you have fixed that.

    But, the first frame should have been either (A 180, B 90, C 90) or (A 90, B 90, C 0). Similarly, the second frame should have been either (A 0, B -90, C 90) or (A 90, B -90, C 0).

    So either C needs to be set to 90, or your A calculation is also off for this special case (B is +/- 90).

    Quote from bert


    Ah...the KRL ATAN2 function takes its arguments the wrong way round :smiling_face:


    Also I have not noticed/found any issue with the other calculations, but if you mixed up how to use the ATAN2 for this case you may want to double-check the other ATAN2 you used as well.

    Ok...I've spent a bit of time thinking about this. There's definitely something very wrong with the A calculation.

    I think we need it be actually be ASIN(-YDIR.X), but since KRL doesn't have ASIN we'll have to use 90-ACOS(YDIR.X).

    I'll update the src file again to reflect this.

    Thanks again for the testing :smiling_face:

    I installed the frame calculation code today. (25 Sep 2013)
    It correctly calculated the frame for a piece of equipment.
    This particular piece of equipment moves in the production cycle, and needs to be calibrated from time to time.
    Using the frame calculation code cuts our calibration procedure from over an hour to about fifteen minutes. Also makes the procedure much simpler--better for us in development and better for the customer in the field.

Advertising from our partners