[adam_frey]

Greetings,

Problem:
The simulated movements work, but after transferring the files to the robot, the movements do not work. The robot moves to the desired start position, then makes a completely incorrect movement, often ending in a physical crash (not damage, going slow and monitoring).

Setup:
A KRC4 controller, a KL 100 linear positioner (E1), a KR 10 R1100 sixx. The ultimate goal is to have it 3d print.

Attachments:
-The RDK station (ignore the floating robot, that is by design; the linear positioner has '0.000' set in the center of the rail.
-One of the generated 3d print programs (the odd movements also occur with regular movements between targets.


Thank you,
Adam

[Jeremy]

Hi Adam,

There's a lot of things to consider before flagging this as a RoboDK bug. I will move this to the general thread.

Did you look for other threads on the subject? I'm pretty sure we discussed that in the past.

Basically, you need to make sure setup you have in the controller matches with the setup you have in RoboDK.

我的意思是说,确保铁路轴在the right orientation, make sure your base frame matches with the robot base frame, making sure if you set the same base and same tool active on the controller and active in RoboDK the jog direction for each axis and the TCP with respect to the base position matches in both environments.

Jeremy

[adam_frey]

Hi Jeremy,

Sorry about putting the thread in the Bugs area, now I know these things should go in General.

I've spent a week trying to implement the changes you have recommended, but I am still having issues.

I have fiddled around with the orientations and I am pretty sure that the kuka base coordinates and the robodk reference frame are aligned. The TCP in robodk is oriented properly (+Z extending out of the tool tip, per the 3d printingdocumentationimages), but it is different than how kuka normally orients TCP's (+X axis extending out of the tool tip). However, I suspect that this is irrelevant because the KRC4 post-processor should translate this.

I finally figured out how to connect directly to the kuka arm for online programming. Using this, I have confirmed that the robot jogs in the correct direction for each joint.

Simulated movement still looks accurate, but when I try to run a program on the actual robot (online and offline) the movements are incorrect. This seems to be a problem with LIN movements; the first program event is a PTP movement that works fine. The problems start with the LIN events.

I have attached an updated version of the RDK file.
I will work on getting a screen capture of the simulated vs. actual movements.

Adam

[Jeremy]

Hi

Did you try creating a simple 3-4 points project and see where it lands in space?

Did you try just bringing the robot to specific joint positions and verify if it matches with the data from RoboDK?
Making sure the right frame is activated:





Also, good practice would be to have the frame you are printing on as a child of the linear rail base frame.

Jeremy

[adam_frey]

Hi,

I tried doing the 3-4 target test. I found that MoveJ events worked fine but MoveL events made the robot move incorrectly.

I also found a few forum posts that seemed to describe the same issue I have been having.

Simulation of linear movement not accurate to actual trajectory (www.sinclairbody.com)
Physical robot position and robodk disagree! Caused crash.

The following thread looks like the thing I need, but I don't know where to start with changing python programs:
Modify MoveL to MoveJ (www.sinclairbody.com)

Adam

[Jeremy]

If MoveJ works fine, that's a good sign.

It means it's really just a matter of making sure the frames are properly setup between RDK and the controller.

Don't waste your time trying to change MoveL to MoveJ, it will "solve" the issue for where the points are, but the created motions won't be straight lines, so that's useless.

Did you try just bringing the robot to certain spots and comparing the data in RDK with the data showed on the controller?

Jeremy

[adam_frey]

Jeremy,

I had not tried comparing the position data on the KUKA to that in RDK, so I began to do that but then discovered some relevant information concerning the TCP.

I switched to developer mode and tried to run a simple program. I noticed a line in the live-connection log that looked like this:
SETTOOL### ### ### ### ######

I assume this is in XYZABC format, so I checked the tool data on the KUKA controller. The XYZ were fairly close, but the ABC were completely off.

I calibrated the KUKA and RDK simultaneously so they would have the same points and got the following:

RDK: SETTOOL 347.351686 115.639365 44.855727 -149.695500 84.686120 -156.230849

KUKA: X 332.772 Z 116.152 Y 45.530 A 0.000 B 0.000 C 0.000


I think this discrepancy may be the source of the problem, but I am unsure how I should proceed.

Adam

[Jeremy]

How did you do the calibration?
The cartesian values are quite off.
Be aware though that you can't compare just the ABC value without a good understanding of the Euler angles format.
Take a look at this:https://www.youtube.com/watch?app=deskto...e=youtu.be

Jeremy

[adam_frey]

Jeremy,

Thank you for the video. I now understand that KUKA uses a [Z, Y', X''] rotation format.
For calibration, I used the RDK Utilities>>Define Tool Frame and used 4 points. Simultaneously, I calibrated the same tool using the KUKA 4-point calibration procedure.