Need expert on ConfJ \Off

RAPID Programming
,
1

Hi,

I am a university professor teaching industrial robots with ABB robots. Of course, I know how to solve the inverse kinematics of a 6-axis robot like the IRB 1010, for example. I even know how to calculate myself the confdata. I also know how ConfJ should work, but it doesn’t. I have been using various ABB robots for more than a decade, and I just can’t understand why ConfJ \Off is programmed the way it is?!?

Why not just solve the inverse kinematics, find all the possible configurations for a given destination and then choose the jointtarget that is fastest to reach from the start jointtarget, completely ignoring the confdata that is in my calculated robtarget? Instead, ConfJ \Off, keeps conf1, but chooses the other conf parameters so that they are as close as possible to the ones in my calculated robtarget. Why? The confdata in my destination robtarget is just [0,0,0,0]. How am I supposed to go to a completely random pose given by a camera, for example. I should calculate my confdata using my own inverse kinematics? I can’t even use CalcJointT because it requires me to give the confdata.

In contrast, ConfL \Off works as it should. The robot chooses the configuration closest to the initial one, completely ignoring the confdata in the destination robtarget.

2

In my experience it does work as written in the rapid manuals. However, you have something going on which I suspect is making it not behave like it ought to or like you think it ought to behave. You have mentioned joittargets and then robtargets that are calculated. MoveJ and MoveL use robtargets, not jointtargets, as I expect that you are aware. The confdata of 0,0,0,0 is like a lack of confdata, which might leave the robot to figure it out on its own how to get to a pose. Maybe experiment with giving it the “right” confdata and then something completely “wrong” to see if it is indeed going to the nearest pose configuration by ignoring the “wrong” confdata.

3

Thanks for your prompt response. Yes, MoveJ \Off does work as explained, but the question is why. Let’s say that I am at a particular position (theta1, theta2, …, theta6). I now want to move the robot tool to a specific pose: [10,20,30],[1,0,0,0]. I don’t care about the configuration that the robot would choose. So I calculate a robtarget like this: rt := [ [10,20,30],[1,0,0,0], [0,0,0,0],[0,0,0,0,0,0]]. In most cases (depends on the initial position of the robot), I can’t just do that:

ConfJ \Off
MoveJ rt, v10, fine, tool_something;

even though there exists several possible confdata for the desired robttarget. The robot tries to go to my robtarget with some automatically calculated confdata and eventually stops because some joint is at a limit.

4

Is it just in the case of your example that the orient is also 1,0,0,0? Just for simplicities sake? Your calculated robtargets do have different orients, right?

5

Yes, it’s just that I’m not good at producing random quaternions :wink:

6

Hi,

Wouldn’t it be possible to let the robot handle the confdata recalculation automatically?
When I need to determine a specific position, I use CalcJoint().
I only resort to Conf\Off when absolutely necessary, since disabling configuration data can lead to significant trajectory variations depending on the desired movement.
The problem is for the robot to decide which configuration is best, or the fastest, and that sometimes it will prefer to ‘tip’ an axis instead of rotating another.

VAR robtarget rt;

rt:=CalcRobT(CalcJointT(Offs(PointP,10,20,30),tool_something),tool_something);

MoveJ rt, v10, fine, tool_something;

Good work.

7

Hi,

The problem is that your CalcJointT would most probably generate an error, because it needs that the confdata of the robtarget Offs(PointP,10,20,30) be correct. In your case, it might work because the offset is not that big, but if you have for example CalcJointT(RelTool(PointP,10,20,30 \Rz:= 180), it would most certainly generate an error.

Also, by the way, if you already have the jointtaget, there is no use in converting it to a robtarget. You can just use MoveAbsJ.

The way I circumvent the CalJointT restrictions is using error handling. But this is way too complicated and time consuming. I basically get all possible jointtargets corresponding to a desired end-effector pose. Then I need to find the one that is closest to my current position. Here’s the code:

MODULE MainModule

VAR iodev jtfile;
VAR robtarget r;
VAR jointtarget tryconf;
VAR bool notfound := TRUE;
VAR bool goodconf := TRUE;

VAR num cf1 := -2;
VAR num cf4 := -2;
VAR num cf6 := -2;
VAR num idx;
VAR jointtarget j{8};

PROC Main()

Open “U:”\File:=“jointtargets.txt”,jtfile\Write;
idx := 1;

! robtarget for which I need all possible confdata
r := CalcRobT([[100,40,-89,150,-40,-70], [9E9,9E9,9E9,9E9,9E9,9E9] ], tool0);
Write jtfile, “Position (x,y,z) : " + NumToStr(r.trans.x,3) + " mm, " \NoNewLine;
Write jtfile, NumToStr(r.trans.y,3) + " mm, " + NumToStr(r.trans.z,3) + " mm”;
Write jtfile, “Orientation (az, ay, ax) : " + NumToStr(EulerZYX(\Z, r.rot),3) +” deg, " \NoNewLine;
Write jtfile, NumToStr(EulerZYX(\Y, r.rot),3) + " deg, " + NumToStr(EulerZYX(\X, r.rot),3) + " deg";
Write jtfile,“”;
notfound := TRUE;
goodconf := TRUE;

FOR cfx FROM 0 TO 7 DO !looking for all solutions of the inverse kinematics
notfound := TRUE;
WHILE notfound AND cf1 <= 1 DO
WHILE notfound AND cf4 <= 1 DO
WHILE notfound AND cf6 <= 1 DO
tryconf := CalcJointT([r.trans,r.rot,[cf1,cf4,cf6,cfx],[9E9,9E9,9E9,9E9,9E9,9E9]],tool0);

IF goodconf AND tryconf.robax.rax_1 <= 180
AND tryconf.robax.rax_4 >= -180 AND tryconf.robax.rax_4 < 180
AND tryconf.robax.rax_6 >= -180 AND tryconf.robax.rax_6 < 180 THEN

j{idx} := tryconf;
Write jtfile,“j{” + NumToStr(idx,0) + “} := [[” \NoNewLine;
Write jtfile,NumToStr(tryconf.robax.rax_1,3) + “,” \NoNewLine;
Write jtfile,NumToStr(tryconf.robax.rax_2,3) + “,” \NoNewLine;
Write jtfile,NumToStr(tryconf.robax.rax_3,3) + “,” \NoNewLine;
Write jtfile,NumToStr(tryconf.robax.rax_4,3) + “,” \NoNewLine;
Write jtfile,NumToStr(tryconf.robax.rax_5,3) + “,” \NoNewLine;
Write jtfile,NumToStr(tryconf.robax.rax_6,3) + “],” \NoNewLine;
Write jtfile,“[9E9,9E9,9E9,9E9,9E9,9E9]];”;
idx := idx + 1;
notfound := FALSE; !des qu’on trouve une solution, on passe au prochain cfx
ENDIF

goodconf := TRUE;
cf6 := cf6 + 1;
ENDWHILE

cf6 := -2;
cf4 := cf4 + 1;
ENDWHILE

cf4 := -2;
cf1 := cf1 + 1;
ENDWHILE

cf1 := -2;
ENDFOR

Close jtfile;

ERROR

!When the confdata in CalcJointT is not good, RAPID generates the error number 1074 (ERR_ROBLIMIT)
IF ERRNO = ERR_ROBLIMIT THEN
goodconf := FALSE;
TryNext;
ENDIF
ENDPROC

ENDMODULE

8

Hi …

The problem is that your CalcJointT would most probably generate an error, because it needs that the confdata of the robtarget Offs(PointP,10,20,30) be correct. In your case, it might work because the offset is not that big, but if you have for example CalcJointT(RelTool(PointP,10,20,30 \Rz:= 180), it would most certainly generate an error.

I use CalcRobt() to solve the problem with confdata, it hasn’t caused me any problems so far…

CalcRobT(CalcJointT(Offs(PointP,10,20,30),tool_something),tool_something);

and for the same reason I don’t use MoveAbsJ.

And if it actually returns an error, it is because it is not possible to reach the target position without the robot tipping over on some axis, and in my case this is not good, so I will have to work around it in another way and not by calculating this position.

This is an interesting way of calculating the axis configurations.

Good work.

9

I believe, I now understood the way ConfJ \Off works.

With ConfJ \Off, the confdata of the destination robtarget is completely ignored, and the robot automatically selects the configuration that is “closest to the initial one”. Unfortunately, “closest” doesn’t mean fastest to reach. Indeed, the robot minimizes the rotation of joint 1, at the expense of all other joint rotation.

Here’s an example of how dangerous the use of ConfJ \Off could be.

Initial position (represented with a jointtarget)

jt_Debut := [[30,-20,40,-30,50,-30],[…]];

Desired pose (represented with a robtarget with a random confdata):
rt := [[386.512,-461.648,704.926],[0.0400892,0.952302,-0.121178,0.27718],[any confdata],[…]];

If I execute
ConfJ \Off;
MoveJ rt, vmax, fine, tool_something;

the robot goes to the position corresponding to the following jointtarget:
[[119.58,-6.75538,-196.451,31.2896,-46.9952,26.4324],[…]];

Thus, it moved joint 1 only 89.58°, but at the expense of moving joint 3 more than 236° !!!

Instead, it could have gone to the position corresponding to the following jointtaget:

[[-60.3958,-19.2847,38.9758,29.701,50.0471,-151.154],[…]];

which is super close to the initial position, but joint 1 would have rotated 90.39°… Thus, to save less than 1° of rotation on joint 1, the robot rotates joint 3 more than 236°…

10

Nice work. You searched an expert on ConfJ, then it turns out you yourself was the chosen one :smiley:

ConfJ\Off has always been a mystery to me.

The manual for ConfJ\Off says:
“it will search for a solution with the same main axis configuration as the current one, but it moves to the closest wrist configuration for axes 4 and 6.”

I guess thats inline with what you found out?

11

I know, but “same main axis configuration” doesn’t mean anything. Do they mean same cf1? Because it’s not; I tested it. They probably meant “a solution with the least required rotation of joint 1, and if there are several such solutions, the one that requires the least combined rotation of joints 4 and 6, although that could mean that joint 3 will rotate more than 180°”…

The main problem with confdata is that it is unnecessarily overconstrained and overcomplicated. Most six-axis robots (like IRB 1010, for example) have eight inverse kinematic solutions when you don’t take into consideration the fact that some joints can rotate more than one revolution (ABB calls this turns). Most other robots will therefore have three binary variables to identify one of these eight solutions: front/back, elbow-up/elbow-down, and flip/noflip. ABB instead uses the decimal cfx from 0 (corresponding to 000) to 7 corresponding to (111), which is OK. Converting a binary number to a decimal is not that complicated for the typical user.

Next, you only need to specify the turn (revolution) of those joints that can rotate more than 360°. In most ABB robots, these are joints 1, 4 and 6. Therefore, ABB’s cf1, cf4 and cf6 should have been only revolution numbers, not quadrants. I.e., cf1 = 0 if −180° ≤ θ₁ < 180°, cf1 = 1 if 180° ≤ θ₁ < 540°, etc.

Instead, ABB asks us to specify whether −180° ≤ θ₁ < −90° (cf1 = -2), −90° ≤ θ₁ < 0° (cf1 = -1), 0° ≤ θ₁ < 90° (cf1 = 0), 90° ≤ θ₁ < 180° (cf1 = 1), etc. How would I know??? I can’t solve the inverse kinematics in my head. What I suspect is that if you specify any of these four values for cf1 (-2, -1, 0, or 1), ABB will accept it when using ConfJ or ConfL with \On, if the correct cf1 is actually -2 for example, because you are actually specifying the desired turn (as in “I want a solution with −180° ≤ θ₁ < 180°”).

So basically I have figured out how to compute the confdata for a typical six-axis robot from ABB and I now have a theory about how ConfJ \Off works

In YuMi and GoFa, however, the confdata is impossible to compute by anyone but a few researchers from ABB, because they have made various simplifications that we don’t know about. Firstly, GoFa has 16 inverse kinematics solutions so how could cfx be only from 0 to 7. (I guess ABB simply ignores eight of the solutions.) Furthermore, in that robot, there is no analytic solution so it is impossible to designate solutions (there is no such thing as flip/noflip, front/back, etc. in GoFa). Simiarly, even for a fixed arm angle, YuMi has more than 8 solutions. Secondaly, in GoFa, there are many joints that can rotate at least 360°. So how do you distinguish in the confdata θ₅ = 180° from θ₅ = −180° or θ₂ = 180° from θ₂ = −180°?

In other words, I have no idea how ConfJ \Off works in YuMi and GoFa…