A and C Axis Move Identically in Program

  • I'm at the end of my rope here. I spent most of the day trying to troubleshoot what I thought was one problem, but have discovered that something else is going on. For troubleshooting, I have put a few lines right after the first PTP move in this program and then edited them in the program in the attempt to get what I would expect should be different results, but am finding that I get the EXACT SAME MOTION.


    This:


    Code
    PTP pstart CONT Vel=15 % PDAT6 Tool[1]:COAX 300mm Base[3]:90degRotateAbtZ
    
    
    ptarget=$pos_act
    ptarget.c = ptarget.c+10
    $vel.cp=.1
    lin ptarget
    halt


    Results in the EXACT SAME MOVE as this:


    Code
    PTP pstart CONT Vel=15 % PDAT6 Tool[1]:COAX 300mm Base[3]:90degRotateAbtZ
    
    
    ptarget=$pos_act
    ptarget.a = ptarget.a-10
    $vel.cp=.1
    lin ptarget
    halt


    And that move is that the robot rotates the tool 10 degrees about the centerline axis of the tool, which is parallel to the world z axis.


    When I jog the axes, A, B and C all do exactly what I would expect them to do (roll, pitch and yaw). And in the code above, when I put in ptarget.b instead of .a or .c, the tool rotates about some axis that I don't have any idea where it came from, but whatever this axis is, it is not parallel to x, y or z.


    Thanks for any help or thoughts.

  • Hi,


    and probably in your case b is Close to 90°? Hence what you are seeing is the so called "euler singularity" (or the "gimbal lock"). This has been discussed many times. Just use Forum or Google search with keywords "euler singularity" or "gimbal lock".


    Fubini

  • I suppose it's possible and I'll look at it again when I get in tomorrow, but when I run it in T2 mode and stop it after the PTP move, I can jog it + and - 10 degrees in a, b and c and it moves smoothly with no joints running at any high speeds that I can tell. It seems that a 10-degree jog should be the same as a 10-degree LIN motion command. Or am I missing something?

  • If I have understand correctly, You would like to rotate your tool of 10 deg on the axis x. are you speaking about the tool defined X axis direction or the base x axis direction?


    your software is rotating on the base x axis direction.

  • Fuzco,


    I have to rotate the tool (a welding head) in the a-axis during a linear move of about six inches. And yes - I had thought that one of the LIN commands would have rotated it about the X-axis. But none of the three do this.


    When you say, "your software is rotating on the base X axis direction.", can you tell me which of the two LIN commands in my original post that you're referring to? I had thought that the .a command would be about the TCP, on an axis parallel to the world's z-axis (normal to the XY plane). In any event, whatever it is supposed to be, the LIN command in both examples rotates the tool about the TCP on an axis parallel to the world's z-axis.


    I would think that regardless of what else is wrong, the three rotational axes a, b and c should be perpendicular to one another. Not only are they not perpendicular, it seems that the a and c axes are coincidental and the b-axis is somehow oriented at about a 60- degree angle to the common a and c axis.


    Lastly, I just found out that the tool TCP and orientation had been re-taught yesterday due to a configuration change. I didn't think that this would be an issue since jogging in a, b and c all work exactly as expected.

  • Which A (Z) axis do you need to rotate about? The Base Z axis, or the Tool Z axis?


    Euler math is VERY counterintuitive -- long story short, you CANNOT do what you're trying to do just by taking one of the ABC values and changing it. You need to use the Geometric Operator, which has been discussed many, many, MANY times -- just search the forum archives.

  • SkyeFire,


    Thanks much for that. I must have misunderstood what I had programmed before. On a previous application, it worked just as I had needed it to, but it seems that this could have simply been a lucky coincidence. In that application, I had to move about 18 inches along the base x-axis while rotating about the [tool] x-axis (parallel to the base z-axis). I had to do this to prevent a tool collision. It worked like a charm. But it seems like I just got lucky on that one and now I'll have to get familiar with how to do this through more complicated means.


    I suppose that I got confused having read the orientation control section in the programming manual and thought that it was relatively straightforward. (I mean, the picture looks like it's easy!) I got hung up thinking that when I jog 10degrees in A, B or C, it should do the same thing if I program it to move in A, B or C.


    Ok. I'll start reading up on this.

  • Ok. So I thought that I didn't understand what is going on here. And I didn't. So I read and made changes and thought I had things under control, but now other weird things are happening so I pigeonholed that project. So I've been reading through the manuals. Please correct my understanding here. Based on the excerpt from the expert programming manual that I have attached, page 76 shows:


    Code
    ; Linear motion to the specified position, the orientation 
    ; is continuously changed to the end orientation
    LIN {X 1030,Y 350,Z 1300,A 160,B 45,C 130}


    At this point, we may not be sure what this motion is, since we don't know where the robot was before the LIN move, but after that LIN move, the robot and tool are in the location described in the move.


    Now, let's say that I add in the following lines right after the move in the manual:


    Code
    pTarget = {X 1030,Y 350,Z 1300,A 160,B 45,C 130} ; Same coordinates as described in the manual
    pTarget.c = pTarget.c + 10
    lin pTarget


    1) I had thought that this should have rotated the tool about its TCP on an axis parallel to the c-axis of the current base, without moving the TCP in Cartesian space. Is that correct? During this tool rotation, the TCP will remain at {X 1030,Y 350,Z 1300} If that's not what this does, then can someone explain what the comments in the excerpt from the expert programming manual means?


    Next scenario: if the example in the programming manual had been as follows:


    Code
    LIN {X 1030,Y 350,Z 1300,A 160,B 45,C 120} ; assume that all goes well and the robot moves to this location as would be expected. 
    LIN {X 1030,Y 350,Z 1300,A 160,B 45,C 130} ; this moves from the point in the line above to C+10 degrees


    2) What would this move look like? Would this be the same as the example I wrote above with the pTarget variable? The manual states that the path is a linear motion to the specified position while the orientation is continuously changed to the end orientation. When the tool changes orientation 10 degrees for the "C" value, what will occur? And about what axis will the rotation occur?


    Final scenario:


    Code
    LIN {X 1030,Y 350,Z 1300,A 170,B 45,C 130} ; assume that all goes well and the robot moves to this location as would be expected. 
    LIN {X 1030,Y 350,Z 1300,A 160,B 45,C 130} ; this moves from the point in the line above to A-10 degrees


    3) What would this move look like? The difference between this example and the previous one is that it is changing A by -10, instead of changing C by +10. Should this move be different from the example where the "C" value was increased by 10?


    This is where I'm stuck. When I do (what I think is) the same thing on my robot, these two different commands result in the tool rotating about some axis that is not parallel to any defined axis of the base, world, robot or tool. If this behavior is what the typical expert programmer would expect to see, then I am very confused about the meaning of the line pointed to by the red arrow in the page I attached to this post. I have looked through the forum at the Geometric Operator as SkyeFire mentioned, but I'm still lost. Additionally, I don't see how the geometric operator would be used to simply rotate the tool about the TCP or where it comes into play in the line from the expert programming manual.


    Is there a specific post that is the end-all, be-all explainer of the geometric operator here on the forum that can explain this concept to me? Or is there a tutorial/book/anything I can be pointed to that will help me get my brain around this?

  • Hi,


    orientation control in LIN/CIRC of the robot is done with respect to the qualified x-Axis of the tool. That is the robot controller uses 2 degrees of freedom to bring any initial orientation to the desired destination orientation. These 2 dof are 'twisting' and 'turning' of the tool x-axis.


    Unfortunatly this is no longer mentioned inside the KRC 4 V8.x documentation. Checking my older KRC2 V5.4 documentation this is mentioned inside the programming orientation section.


    Fubini

    Edited once, last by Fubini ().

  • Fubini - thanks. I've been reading the KRC2 Release 5.2 Expert Programming manual and it's not quite clicking for me.


    It must be that I understand much less about this than I thought I did, which, admittedly, wasn't much to begin with.


    So now, I have drawn up the models in the attached figures and I'm just going to have to come flat out and ask how someone would program the motions shown. I understand that this may be first-day newbie question, but I can't make this do what I need.


    Figure 1:


    This is simply moving 200mm in the negative-X direction and simultaneously rotating the tool 45 degrees during the move. I would have thought that this should be the following, but it doesn't involve the geometric operator, so I know that this isn't right:


    Code
    pTarget = $POS_ACT
    pTarget.x = pTarget.x-200
    pTarget.b = pTarget.b+45 ; rotating the tool 45 degrees
    LIN pTarget


    What would be the correct code for this?


    Figure 2:


    This is simply changing the orientation of the tool. Basically, the same as Figure 1, but without the 200mm negative-X move.


    Code
    pTarget = $POS_ACT
    pTarget.b = pTarget.b+45 ; rotating the tool 45 degrees
    LIN pTarget


    What would I do simply to rotate the tool 45 degrees about the current TCP?


    And again, I know that there must be something else required, because I know that the above doesn't work. Alternatively, if there is a good post/tutorial/book on explaining this, I'll spend whatever time necessary to read it, because I'm clearly not understanding where things are breaking down.

  • Fubini,


    Thanks again. Yes - I have tried LIN_REL moves, but that gives me different problems. I'm trying to work through one issue at a time. And your recommendation is understood regarding trying out the other axes.


    Also, I have calibrated the TCP. When I mount a needle into the tip of the welding head (the location of the TCP), I can jog around with the teach pendant until the needle is a half a millimeter from the tip of a wire held stationary and then rotate in A, B and C of the tool and the gap is held pretty much exactly across any axis orientation. And the A, B and C axes work in the orientations I expect them to when I'm using the reach pendant.


    However, if this command should work (as I assumed that it should):


    LIN_REL {B 45} #TOOL


    then where does the Geometric Operator come into play as SkyeFire mentioned? Also, how would you program the move of {X -200} along with the B rotation during the linear move as the expert programming manual talks about?

  • If you look up Euler angles and orientation matrices, you'll see why the simplistic Position.B=Position.B+45 doesn't work.


    The Geometric Operator is essentially a tool in KRL to (among other things) make Euler rotations practical without having to program all the matrix algebra yourself.


    These lines of code do the same thing:

Advertising from our partners