[luuk_endlich]

Hi,

Via Python API I am trying to jog the robot with both linear and rotational movements in/around x, y, z. In the RDK simulation, when the robot 'Kuka 150 KR 2700-2' is not connected, jogging via Python works exactly as expected for both linear and rotational movements. I calculate the new poses via the following code, followed by executingMoveJandMoveL.


linear: newPose = transl(x, y, z) * robot.Pose()
rotational: newPose = robot.Pose() * rotx(..) * roty(..) * rotz(..)

However, when I connect to the Kuka, the requestedlinearjogging movements result in unexpected movements (x,y,z translations, a,b,c rotations, rather than only the requested translation). The rotational jogging movements do work as expected for both simulation and the Kuka.

I checked the cartesian coordinates and the joint values for the Kuka and RDK, and they match. I tried to modify theKuka KR 150 R2700-2via RDK and found here that theBase reference, Base, joint 1,..., joint 6不选择正确的部分the robot (see image attached). Could this be a mistake in the RDK file that was sent to me? Or do you have any other idea what could be the reason for this mismatch? Thank you in advance!

[Albert]

The first calculation of your pose with translation information is ignored. You should calculate rotation after the translation.

This example should work and it shows a translation relative to the tool:

Code:

newPose = robot.Pose() * transl(X, Y, Z) * rotz(C) * roty(B) * rotx(A)
robot.setPose(newPose)

Which is the same as:

Code:

newPose = robot.Pose() * KUKA_2_Pose([X,Y,Z,A,B,C])
robot.setPose(newPose)

Instead, if you want to calculate a movement relative to the reference you should pre-multiply instead of post-multiply.

Example:

Code:

newPose = KUKA_2_Pose([X,Y,Z,A,B,C]) * robot.Pose()
robot.setPose(newPose)

[luuk_endlich]

Hi Albert,

Thank you for your quick response! I see your point about the order of translation and rotation and I modified my code such that it is respected now.

Unfortunately, again this works fine in simulation only, even when the correct 'currentPose' and 'newPose' are printed when I am connected to the Kuka. Still, the Kuka shows unexpected rotational movements not ending in the pose I send to MoveL, so it seems that the Kuka does not process the result of MoveL(newPose) correctly. Could it be the wrong settings in Modify robot (the picture I attached to the previous post)? Or do you have any other idea why this difference between RoboDK and Kuka is shown? Thank you!

---

In addition: the real Kuka seems to move to the correctly calculated pose, but from a different angle (exactly the opposite). So could it be the case that there is a mismatch in the Kuka.rdk robot file (joint angle definitions) compared to the real robot?

[Albert]

The rotation functions of the API rotx, roty and rotz require angle values in radians. However, the KUKA_2_Pose function works in degrees.

All distance/position units should be in millimeters (unless otherwise stated).

[luuk_endlich]

For linear movement I use, with x,y,z in mm:

newPose = KUKA_2_Pose([x,y,z, 0, 0, 0]) * robot.Pose()
robot.moveL(newPose)

So let me show you an example, I want to do a linear translation in z-direction wrt the robot base (x = 0, y = 0, z = -10):
The initial pose of the tool frame wrt the reference frame from RoboDK equals [ 1965.000000, 0.000000, 1570.000000, 0.000000, 90.000000, -0.000000 ]
After the jogging request, the pose from RoboDK equals [ 1965.000000, 0.000000, 1560.000000, 0.000000, 90.000000, -0.000000 ]

So the result of the target pose calculation matches my expectation, therefore, I don't think it has something to do with the calculation. I also validated the frame I am working in, this is also correct. Could it be that the .rdk robot file (which was a second version only) does not exactly match the real robot? Maybe one or multiple joint inputs are inversed compared to the real Kuka?

[Albert]

I don't understand if there is an issue. The result you got is expected as it is a translation with respect to the reference frame.

Keep in mind that the pose you are operating with is the active tool with respect to the active reference.

[luuk_endlich]

I will try to explain it better one more time. The calculations for the jogging methods (both linear and rotational) are correct. I validated this by testing the Python API on the RoboDK simulation without the real Kuka connected. This works perfectly.

However, as soon as I run the simulation with the real Kuka connected, unexpected movements occur, even if the same movements as for simulation only (without the robot connected) that used to work well are requested. So the problem lies in the connection between RoboDK and the real Kuka. The moveL(target) that is sent to RoboDK works without the real Kuka connected only. But those movements do not match the unexpected movements of the real Kuka.

To conclude: jogging API works for simulation only, as soon as the real robot is connected, the real robot has unexpected non linear movements.

[Albert]

Can you share your full working example?

Did you update the tool on the robot controller?

[luuk_endlich]

Can you share your full working example?

Did you update the tool on the robot controller?

Hi Albert,

我只是做了一些实验MoveL和密苏里州veJ, and the problem seems to be a mismatch between RDK and the Kuka. Everytime, before the robot executes a MoveL, it starts moving to a random (at least, it seems random) configuration. From here, it executes the requested program (also the linear jogging movements). RDK visualises the difference between the RDK position and the real Kuka position. Each time I call the jogging method, the configuration shortly changes and then it goes back again. Please find an example video attached to this post.

It only happens when I execute MoveL, for MoveJ it works perfectly without any issues!

[maexbecks]

Hi Luuk,

did you create the robot by yourself? I checked the library and could not find a KR 150 R2700-2, only the KR 150-2.
Anyway, I had a similar problem with a robot created by myself. I forgot to set the robot parameters to KUKA:


At least I think that it was the issue. Could also have been the joint sense.