Changing position orientations

[SkyeFire]

Well, I confused.  In the past, I've done a LOT of programming that depended on generating or adjusting frames and points on the fly, but always just in XYZ.  Changing a position's ABC orientation *should* be straightforward, shouldn't it?  I know I can't simply add/subtract from the existing ABC values, but that's what the geometric operator is for.
I've been trying to run code like this:

LIN P1
NextPos=P1
NextPos=NextPos:{X 0,Y 0,Z 0,A 10,B 0,C 0}
LIN NextPos

Now, what I *expected* to happen would be that the robot would reach position P1, then hold position while rotating the TCP 10deg around the Z axis of the active base.  Instead, it rotated around the X axis.
Puzzled, I tried changing the shift to {X 0,Y 0,Z 0,A 0,B 0,C 10}, and the robot rotated THE SAME WAY.  Now that's just not right.
The only rotation that worked the way it should have was B, rotating the robot predictably about the Y axis.

Now, I can achieve the same effect by moving to P1 and then using a LIN_REL command, but my eventual goal is to be able to pre-calculate an existing point with an orientation change, and move directly to it. 

Any ideas?  I must be missing something fairly elementary hear, since controlling E6POS variables can't be that hard.

[SkyeFire]

And, now I'm replying to my own posts because I forgot to put everything into the first one...   

I also have another item on my plate regarding generating orientations for E6POS variables.  I have two robots facing each other and sharing a common base frame.  These robots need to move to the same location but facing in opposing directions (one is a drill, the other acts as a backstop).  Getting them to the same XYZ is easy, but my orientation is controlled by the drill robot, and I need to generate equivalent e6POS variables for the backstop, but with an opposite orientation.  The TCP data for both tools is identical, which simplifies matters.  So if the Drill is at {X  100, Y 100, Z 100, A 0, B 0, C 0}, I need to put the backstop at (I assume) {X 100, Y 100, Z 100, A 180, B 0, C 0} -- the two end effectors should be pointing directly at each other, a perfect 180deg apart.
I *know* this can be done, but it's something I've never needed to do before, and (as shown in my previous post) I'm not quite succeeding in trying to develop it from scratch.

[asimo]

This is really strange indeed. Just so that you don't think your crazy, your first code was supposed to rotate along the Z axis (not from the active base but from P1 in your case). Even more strange, changing the value from A to C does the same thing? Are you sure you haven't changed something else by the meantime?

[Stefan]

LIN P1
NextPos=P1:{X 0,Y 0,Z 0,A 10,B 0,C 0}
LIN NextPos

Try to do it this way, to make sure the compilator is not little bit lost in the notation. And try to debug it in mode step by step and when you go into the point NextPos, look on the actual base and tool. Then try the same with C 10 and look on the actual base and tool.

[SkyeFire]

Well, I got an answer from a friend, who cleared things up for me.  The Geometric Operator works the way you'd intuitively expect when adjusting base frames, but when adjusting E6POS variables things are less obvious.

Essentially, doing this:  POS1=POS1:Shift_Frame
where Shift_Frame is {A=10} values of 0, causes a *tool* rotation around the position, rather like: LIN_REL {A 10} #TOOL.

In order to rotate a position around the *base* axes, you need to reverse the order of the variables in the geometric operator.  HOWEVER!  Doing this causes your XYZ position to be offset as well.  So doing what I've been trying to do takes some extra effort.

So, in order to rotate a point in place around the axes of the base, you need to do something like this:
TempPos=Pos1
TempPos.X=0 ; remove the XYZ elements of the position, leaving only the rotational elements ABC
TempPos.Y=0
TempPos.Z=0
TempPos=ShiftFrame:TempPos ; ShiftFrame should have X,Y,and Z values of 0, and the desired rotation around each base axis in ABC
Pos1.A=TempPos.A ; recombine original XYZ values with new rotations
Pos1.B=TempPos.B
Pos1.C=TempPos.C

And that does it.  I put code like this into two opposing robots whom I needed to keep oriented to each other in a shared base frame, and it worked -- by rotating the same amounts about the same base axes, I could keep both robots in place tip-to-tip while rotating around in three dimensions, *and* keeping their Tool Z axes aligned to each other.

Apparently, the Geometric Operator takes the *orientation* of the first variable as the set of axes around which the ABC rotations of the second variable will be applied.  Which means that a simple Pos1=Pos1:ShiftFrame will act like LIN_REL #TOOL.  But just reversing the order of the operands won't help, because although it will give you the right orientation, it will also shift your XYZ by amounts equal to the original XYZ values of your position variable.  So in order to rotate a point around the base axes, you have to isolate the rotational factors first, perform the geometric operator, then restore the original XYZ values.

I know -- clear as mud, right?      

[asimo]

 I haven't understand that you wanted to turn around the base frame, I thought you wanted to turn around the current position (that's why I mentionned that you will turn around P1 instead of the base, thinking that that's what you wanted to achieve). Your problem (now solved) looks a little bit like the solution I had to move to another point but from another base (look at the end of first page):
http://www.robot-forum.com/robotforum/kuka_robots/switching_base_without_stop_the_robot-t555.0.html

Now it makes sense, thanks for sharing. But I still don't understand why
NextPos=NextPos:{X 0,Y 0,Z 0,A 10,B 0,C 0}
and
NextPos=NextPos:{X 0,Y 0,Z 0,A 0,B 0,C 10}
would give the same result. When you are saying that it turned around the X axis, was it the X axis of your base or your TCP? I'm just curious :-)

[SkyeFire]

I'll have to see if I can re-create the original conditions again.  It might have been a side effect of my starting point being exactly square to the active base frame -- I might have generated a mathematical singularity or something without realizing it. 

[asimo]

I understand. Don't bother with that. I'm pretty sure you have something better to do than trying to recreate a behavior for some forum user. Thanks for replying and good luck with your project.

[TylerRobertson]

Thanks for the well documented solution - good to know.