Rotation around X axis, why is so difficult??

Hello everyone ; )
I am a beginner in Robot Studio, because of COVID19 I found that the software now can be download for free so I really enjoy to play with it and create stuff. ; ) Previously I have experience with Fanuc CNC.
I like the interface of Robot Studio, but I do prefer to create programs by hand. So for all my programs until now I use only Rapid Editor. /Quartenons, XYZ coordinates /
The problem currently I am trying to solve is why rotation around X axes is difficult to make? Are there specific commands to control only one axis independently from others with rapid code and how? Is it depend on the tool that you’re using?
Here for example is my simple program of a square in which the head should rotate in 45 deg. angle. It always stops at the end of the line. I don’t have a notification for singularity.
What I would like to keep as constant is MoveL command, 45 deg rotation around X axes.
The robot I am using is IRB24000 12.5 kg.

MODULE Module1

LOCAL PERS tooldata rdktool[TRUE,[[126.616,0.079,183.273],[0.707106195,-0.001493302,0.707105791,0]],[2,[28.725,-34.208,130.111],[1,0,0,0],0,0,0]];
TASK PERS wobjdata Workobject_1:=[FALSE,TRUE,“”,[[1200,-50,900],[1,0,0,0]],[[0,0,0],[1,0,0,0]]];

PROC main()
ConfL \Off;
SingArea\LockAxis4;

MoveL [[-100,-100,100],[0.360597,0,0.932722,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1; ! normal problem
MoveL [[-50,-100,150],[0.360597,0,0.932722,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1;
MoveL [[-50,-100,150],[0.382683,-0.92388,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1;
MoveL [[50,-100,150],[0.382683,-0.92388,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1; ! head kink
MoveL [[50,-100,150],[0.382683,0,-0.92388,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1; ! head kink
MoveL [[100,-100,100],[0.382683,0,-0.92388,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1;
MoveL [[100,100,100],[0.382683,0,-0.92388,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1;
MoveL [[0,100,200],[0.382683,0,-0.92388,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1;
MoveL [[0,100,200],[0.382683,0,0.92388,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1; ! head kink
MoveL [[-100,100,100],[0.382683,0,0.92388,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1;
MoveL [[-100,-100,100],[0.382683,0,0.92388,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v20,Z0,rdktool\WObj:=Workobject_1;
ENDPROC
ENDMODULE

My name is Tanique, I am a girl from Slovakia : ))
If someone would like to give advice or help with my little program I would be happy.
Thank u :slight_smile:

I am not fully sure that I understand where the problem is, but for rotation I suggest that you get familiar with RelTool function.

I created a station using your code and found that the robot can’t reach two out of twelve targets. It’s not because of the translation but the orientation. The solution is to rotate two targets 180 degrees around z-axis, then the robot will be able to move along the whole path. Refer to the picture attached.

Hello,
thank you so much for the advice. I will try and post feedback. :slight_smile:

It might also help if you change your MoveL instructions to MoveJ instructions. See Rapid Instructions, Functions and Data Types Manual for clearer description of MoveL and MoveJ.

Back to the forum, thanks for the comments. I am very clear with the MOVEL function /MOVEJ as well, but in my program should not be used/ and it does exactly what I would like to do, same with data types. The issue comes from the fact that I am not familiar with how to prevent the robot to reach a target, without using all axis. My control is mostly over angles in Z-axis. I cannot find anywhere in the Rapid Programming menu, Robotstudio Menu function for this.
I’ve tried the suggestion from user Innebandy, by rotating the two of the targets by 180 deg.
What if I have over 500 targets? Do I have to make manually for each one of them?
I found for example that I can rotate the workobject itself directly in the head above the main ().
TASK PERS wobjdata Workobject_1 := [FALSE, TRUE, “”, [[1000,0,900], [1, 0, 0, 0]], [[0, 0, 0], [1, 0, 0, 0]]];
I have tried also the function MoveL RelTool, advice from user lemstep68 but basically, it makes offset from the position where the robots stop / breakpoint / and then again cannot continue.
It is weird how ABB doesn’t have such a simple function to overcome this problem?
One thing is giving me hope, that such configurations I’ve seen used in paint shops and welding manufactories… so there must be a way out of that.
Hopefully, someone in the forum with experience could help me to solve the issue.

“The issue comes from the fact that I am not familiar with how to prevent the robot to reach a target, without using all axis.”
The reason that the robot has six axes is that if you want to move linear, almost always it will need to move all 6. The major axes, 1-3 get the robot to the X,Y,Z point and the minor axes get the correct orientation. Most of the time a joint move will move many, if not all axes, depending on how you program the position. MoveAbsJ gives you more direct control over the actual joint values, as you specify the jointtarget rather than a robtarget.

Please, let me disagree with you.
I am speaking about the rotation of the tool around axis XYZ, not 1,2,34,5,6.
For instance, if I have a pen-like tool for me it is important only the orientation of the Z-axis (we are still speaking about tool coordinate system, therefore Z.). Which must be perpendicular to the surface. But rotation around Z-axis it’s not important. But if I specify that rotation around Z-axis ( and I must specify in quaternion), then the robot goes to lock position - target out of reach. Which is not true, because if it rotates around the Z-axis It is reachable.
And this is the main problem :slight_smile:

Why have you turned configL off (also SingArea\LockAxis4 is probably not helping)- having the configuration set (easy to do in RobotStudio) will keep the axis where you want them.
You can set the first configuration manually (right click on the target) then in the path right click and choose Auto Configuration - RobotStudio will automatically set the rest of the targets configurations.
If auto cxonfig fails then select a different starting config and try again.

Yes, I tried also your option, but in my case, I would have to change more than 2k targets and check each one of them. It’s not that easy and I would say not efficient. Maybe here you can see in this .gif file I’ve created what is my goal /on the right side of the .gif/. Unfortunately, I am not allowed to upload a video file. I keep improving my quaternions and code in Rapid.
I will update soon.
Thank u

image.gif

To rotate with RelTool you have to use the optional arguments Rx,Ry,Rz

Dx,Dy,Dz are for offset.

RelTool (Point Dx Dy Dz [\Rx] [\Ry] [\Rz])

Example Program

MODULE Module1
CONST robtarget Target_10:=[[1675.705137125,0.000027367,1320.000220369],[0.707106686,-0.000029488,0.707106875,-0.000029382],[-1,-1,-1,1],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
CONST robtarget Target_20:=[[1675.709982506,0,1120.00009428],[0.707106781,0,0.707106781,0],[0,0,0,1],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
CONST robtarget Target_30:=[[1675.70997035,199.999999293,1120.000097455],[0.707106807,0.000000003,0.707106756,0],[0,0,-1,1],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
CONST robtarget Target_40:=[[1675.709951068,199.999997448,1320.000084236],[0.707106774,-0.000000003,0.707106789,-0.000000004],[0,0,-1,1],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
CONST robtarget Target_10_2:=[[1675.705137125,0.000027367,1320.000220369],[0.707106686,-0.000029488,0.707106875,-0.000029382],[-1,-1,-1,1],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

PROC main()
Path_10;
ENDPROC
PROC Path_10()
MoveL RelTool(Target_10,0,0,0,\Rz:=0),v1000,fine,tool0\WObj:=wobj0;
MoveL RelTool(Target_20,0,0,0,\Rz:=90),v1000,fine,tool0\WObj:=wobj0;
MoveL RelTool(Target_30,0,0,0,\Rz:=180),v1000,fine,tool0\WObj:=wobj0;
MoveL RelTool(Target_40,0,0,0,\Rz:=270),v1000,fine,tool0\WObj:=wobj0;
MoveL RelTool(Target_10_2,0,0,0,\Rz:=360),v1000,fine,tool0\WObj:=wobj0;
ENDPROC
ENDMODULE

Hello EricH,
thank you so much for your post. I appreciate. Tonight will have a detailed look over your example and provide feedback.
Taniq

Hello again,
here is an improvement in the program. It was necessary to rework quaternions.
So far the solution could be applied only in case, where I do not shift the geometry.
The targets are rotated so as that prevents rotation on J6. If for instance the work object area with the targets is moved, the robot decides to include in movement also J4 and then the problem occurs again.
I do believe if there is a way how to ignore orientation around the Z-axis will solve the problem completely.
But for now, I don’t see someone who had experience with it, although I found some topics here, unfortunately without answer :frowning:

image.gif

MODULE Module1
LOCAL PERS tooldata ToolTest1 := [TRUE,[[0,0,30],[1,0,0,0]],[2,[28.725,-34.208,130.111],[1,0,0,0],0,0,0]];
TASK PERS wobjdata Workobject_1 := [FALSE, TRUE, “”, [[1200,0,700], [1, 0, 0, 0]], [[0, 0, 0], [1, 0, 0, 0]]];
PROC main()
confl\Off;
MoveL [[-100.000000,0.000000,100.000000],[0.364705,-0.115917,0.880476,0.279848],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v150, Z0,ToolTest1\WObj:=Workobject_1;
MoveL [[0.000000,-100.000000,100.000000],[0.364705,-0.115917,0.880476,0.279848],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v150, Z0,ToolTest1\WObj:=Workobject_1;
MoveL [[0.000000,-100.000000,100.000000],[-0.364705,0.115917,0.880476,0.279848],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v150, Z0,ToolTest1\WObj:=Workobject_1; ! head kink
MoveL [[100.000000,0.000000,100.000000],[-0.364705,0.115917,0.880476,0.279848],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v150, Z0,ToolTest1\WObj:=Workobject_1;
MoveL [[100.000000,0.000000,100.000000],[-0.364705,-0.115917,0.880476,-0.279848],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v150, Z0,ToolTest1\WObj:=Workobject_1; ! head kink
MoveL [[0.000000,100.000000,100.000000],[-0.364705,-0.115917,0.880476,-0.279848],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v150, Z0,ToolTest1\WObj:=Workobject_1;
MoveL [[0.000000,100.000000,100.000000],[0.364705,0.115917,0.880476,-0.279848],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v150, Z0,ToolTest1\WObj:=Workobject_1; ! head kink
MoveL [[-100.000000,0.000000,100.000000],[0.364705,0.115917,0.880476,-0.279848],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v150, Z0,ToolTest1\WObj:=Workobject_1;
ENDPROC
ENDMODULE

@EricH
Sir, you wrote: To rotate with RelTool you have to use the optional arguments Rx, Ry, Rz.

I understood technically and practically how to rotate target and I also know how to use RelTool. Thank you for the example program: My hope for RelTool was “magic” small movement to allow the robot arm to “unwind” rotation of one of the joints causing problems (often J6 or J4). May be better for further communication I will repeat the problem in condensed form:
Example:
My path is a circular (not really, but arc will end on the same target where it’s started) and during interpreting that path some of the joints will reach its endpoint because that joint rotates only one direction.
The question is if there is a way to tell/command/force/ the robot to ignore rotation in Z of all targets?
If it is a pen-type tool where Z orientation is not important OR if there is a function which will tell me THAT ANGLE for usage with RelTool OR to tell the robot to “reorganize” joints so that will unwind that rotation.
(for instance, if the closest rotation of J6 is left, but it is reaching out to its end rotation /360 or -180 and etc/, to rotate all the way back - (right).
Taniq

This is actually interesting.
I think what you want to do is “loosen” the TCP frame’s Z-rotation, or give it some kind of elastic force to deal with poses as wide as possible. Your example is clear, like writing something with a pencil, the rotation of the pencil itself has no influence on the writing.
Unfortunately, in common ways this is not possible for a platform like RobotStudio, I am not sure about other more powerfu (or I should say open, because RobotStudio is powerful too) platforms like ROS.
As you can see RobotStudio is bond with ABB and all functions are based on RAPID.

I have some idea, not complicated at all, but you will have to add bunch of “FOR” loop in your program.
Not pleasant to do them in RobotStudio.

I will download your code and do some research in other platform.
If I am lucky, you can got the solution 2 days later.

@Deer, thanks for your comment! I am pleased and I do believe you got the idea of my issue. I will wait for your suggestion and program example.

Ok, now I understand what you want to achieve. As far as I know, there is no command to ignore a rotation other than the two you used (ConfL and SingArea)

Did you also tried the auto configuration function in Robotstudio?

In your example, how do you have to move the workobject? I don’t have problems moving it so far.

I think that I understand a bit better now, too. You will need to take a "snapshot of the joint angles from time to time to see that you are going towards your axis limit. Use CJointT() function, or use CalcJointT() function on either the current position or upcoming robtarget. The you could say MoveL RelTool function in either a positive or negative z rotation to put you more away from the joint limit. You might also just put axis 6 into independent mode if you have no hoses or wires that you would wind up and consequently damage.

Hello Tanique.
I have been working on this for a few hours.
I am not familiar with RAPID, so it took me a long time.
Unfortunately, I think it is really hard to do it in RobotStudio. But I will try to explain the whole process.
I did the whole calculation in Rhinoceros 6.0, and I use Rhinoceros to generate the RAPID code.
Here is the code.

MODULE Module1
PROC main()
MoveL [[1100.000005,-150.000006,999.999999],[0.111886,0.88351,0.270116,0.365962],[-1,-1,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
MoveL [[1150.000009,-150.0,1050.000005],[0.253574,0.691945,0.612181,0.286613],[0,-1,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
MoveL [[1150.000011,-149.999998,1050.000008],[-0.176704,0.4266,0.819491,0.339444],[-1,-1,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
MoveL [[1250.000006,-149.999996,1050.00001],[-0.121427,0.293151,0.876137,0.362908],[-1,-1,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
MoveL [[1250.000014,-150.0,1050.000005],[-0.38197,0.056401,0.922156,-0.023362],[-1,-1,-1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
MoveL [[1300.000014,-150.0,1000.000005],[-0.38197,0.056401,0.922156,-0.023362],[-1,-1,-1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
MoveL [[1300.000012,50.0,1000.000004],[-0.382625,-0.016124,0.923739,0.006679],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
MoveL [[1200.000012,50.0,1100.000004],[-0.382552,-0.024184,0.923563,0.010017],[0,0,-1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
MoveL [[1200.000015,49.999991,1100.000004],[0.297401,-0.581416,0.717989,-0.24083],[-1,1,-2,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
MoveL [[1100.000007,50.000007,999.999999],[-0.121427,0.876137,-0.293151,0.362908],[-1,0,-2,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
MoveL [[1100.000005,-150.000006,999.999999],[0.111886,0.88351,0.270116,0.365962],[-1,-1,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,Z0,my_tool;
ENDPROC
ENDMODULE

The last one point 10 to point 1 may cause singularity because it is MoveL and my calculation did not stimulate every MoveL path to check singularity.

It is 0:38 in China and I think I will have to reply with a complete process tomorrow.
Here is the brief one:

1:Download the IRB 2400/10KG 3d model from ABB website.
2:Import 3d model into Rhinoceros.
3:Find out 6 axis rotation plane from the model and check these dimensions with ABB specification in case the 3d model is not accurate.
4:Open the inverse kinematics (analytical solution) program I wrote a couple month ago.
5:Input the 10 TCP frames into my program.
6:Rotate every TCP along the Z axis for 360 times (1,2,3,4…360 degree), that is 10X360=3600 TCP.
7:Calculate inverse kinematics to 3600 TCP frame, that is 3600 JointTarget, each one has 6 angles.
8:Some rotation can be out of reach, delete them first.
9:I would like to choose which TCP rotation is best(like the pencil, the writing will be the same, but some rotation is just much more comfortable for you hand)
10:Here I took a quick route, I give the 6 axis some kind of “weight”, Axis 1 tend to have bigger weight, and Axis 6 maybe smaller. Each axis angle has its distance to the default angle, the fomular will be [(current_angle-default_angle)*axis_weight]. Add these 6 results.
11: Choose the rotation with smallest results, it may feel like the robot is moving from default location as few as possible.
12: I choose 10 TCP from 3600 TCP, each has 6 angle. that is 60 numbers.
13:At first I think I can use JointTarget and CalcRobT easily, but…
14:I spent most time debuging the RAPID program because it is the first day I use it. Finally I give up the combination of “MoveL” , “JointTarget” and “CalcRobT” because it some how did not work at all.
15: I have to use “MoveL” and “RobotTarget” which require the actual XYZ coordinates and quaternion.(It is also the first time I saw the word “quaternion”, and I spend sometime study it).
16:Since RobotTarget require configuration data, I determine the Conf data from each angle. (0~90 is 0, 90~180 is 1, -90~0 is -1 and so on)
17:Finally it is the code.

Sorry this is not brief at all.


This is my program in Rhinoceros.
I can explaine the whole process to you in detail, and I am sure you can understand them.
Even though you may not want to re-create the logic in Robot Studio, I think this can help you better understand the problem.
See you tomorrow.

Hello,
At first, I would like to thank you for the ideas and a lot of information that you post for me. I will need some time to take a detailed look over the suggested functions.
For now, I found also how to move the work obj frame with targets together without having problems. But still keeping the direction of Z in the tool.
@EricH from Germany. Yes, for the purpose I’ve used Confl\On and SingArea\Wrist;
@lemster68 from USA. Thank you Sir I will have a look at those commands/functions. Will provide feedback if some of them help. For now, I would say that my conclusion is more about the mechanical possibility of the robot and Robot Studio itself. However, there is always a workaround as we know from experience. For instance, in my last example, I implement the ReelTool command directly in quaternions, so I don’t need to define for each of over 1000 targets I have. It works very smoothly and the robot is able to follow the path with proper orientation of the tool and moving obj without receiving a message for joint out of reach.
@Deer from Shanghai. Thanks again for your initiative and interesting thinking. Yes, I spent also more than two days around rapid code. It’s basic assembly languages, but it needs some good comprehension, especially when you would like to make complex things. Please take your time and do not be in a hurry.
Also, I am using the Rhino5 series as well, but I have a student version. Not sure if your plug-in will work for it. I will have a look at your example and provide feedback as well.
Honestly, I thought that such an issue rised up in many manufactories, especially in Paint Shops, Welding, and 3D printing (aka additive manufacturing ) that is commonly used in Europe, especially in the automobile field.
However, if we come to the moment where we have to purchase a special robot with ( excluding some of the joints as an independent) just in order to use it for one purpose, I would aim for a programmable solution and suggestion to ABB robotics. Because it is possible to happen as programming in a very elegant way.
Come back to you all later, I little bit float into thoughts… Apologize.
Have a nice evening,
Tanique