[colinb83]

Hi Jeremy

Please see attached images, the joint values match, but the TCP doesn't

thanks

Col

[Albert]

Hi Col,

RoboDK won't pull the tool data from your robot but you can set it using a dummy program that simply sets the robot tool (TCP) and run that program on the robot. This will update the $TOOL pose on your KUKA robot controller according to the tool you defined in RoboDK.

This can also be done using the API. Example:

Code:

robot.Connect()
robot.setPoseTool(KUKA_2_Pose([x,y,z,a,b,c])) # Updates the tool so that $TOOL = {x,y,z,a,b,c}

Albert

[colinb83]

Albert the tools are all set to zero, i even tried it with a fresh station with no tools loaded on the RDK and with the robot set to null tool and still the results don't match, but the joints are the same

[Albert]

I recommend you to create a program to update the tool. If you use the Get Position or Move Joints button it only moves the robot (these operations won't update the tool).

Maybe I don't fully understand what you tried...

[colinb83]

That's very weird.

One quick test you can run would be the following.
If you bring the robot to a certain set of joint values, do the same in RDK, does the cartesian position of the flange (TOOL[0]) match in both environments.

As the difference seems very small, I'm looking to see if the kinematic of the robot you are using in RDK and the one in the controller are the same.

Jeremy

Albert, I'm doing what Jeremy asked me to try in this post, essentially get positions of the robot with no tool loaded, and compare with the same in robodk, as you can see they do not match

[Albert]

OK, so the misunderstanding is that RoboDK will never read the TOOL of the robot. RoboDK only sets the tool when you have a set tool instruction:
//m.sinclairbody.com/doc/en/Robot-Programs.html#InsSetTCP

This will update the $TOOL variable when you are running the program on the robot using the driver.

[colinb83]

There is no tool loaded on the robot or on the rdk, but the tcp of the flange it self doesn't match between the robot and the rdk station

[Jeremy]

Hi Collin,

As the cartesian position from the controller and from RoboDK do not match when the robot et set at a specific set of joints, my guess would be that the kinematic of the robot you are using in RDK does not match the kinematic of the real robot.

A few things could explain that, but mainly 2.

1 - You didn't pick the right robot from our library. Can be a simple mistake on your end, but we also saw a similar situation where a customer bought a used robot and was told it was model "XYZ" but in fact, it was model "XZW" with a very slim difference that you couldn't just "see".

2 - We did a small mistake when creating the robot and we didn't set the kinematic properly. It doesn't happen often, but with over 600 robots in our library, we might be just 99% perfect.

-----------------------------

Ok, I took the time to look at it and the issue was on our end.
I compared the 2D drawing of the robot with our kinematic and we had a small discrepancy.



That wouldn't have affected cartesian motion accuracy-wise, but it would have definitely affected joint motion and TCP definition.

I rerun the TCP definition with the proper kinematic and it now matches within a reasonable margin of error.




I attached a robot with the right kinematic. Simply save it somewhere on your computer, right-click the robot your station, and select "replace robot". This way you won't have to rebuild your station.

The 3D model (dimensions) of our robot doesn't seem to exactly match the updated kinematic, so the flange TCP is kind of floating in front of the physical flange for now.
I'll try to grab the proper 3D model by the end of the week and fix that.



PS: I saw your comment on Robot-Forum.com, we greatly appreciate it!

[colinb83]

Thanks Jeremy!

我有一个计划,我手动移动机器人into place to line up for my tool changer, I take it that as long as I keep the joint angles it will update the TCP of the location, but keep the joint angles the same when I load in the corrected .robot? wouldn't want to have to spend a day doing that again.

As for the forum response, not a problem, there is some misinformation on there about what RDK can do, and unfortunately it did put me away from RDK initially too as I didn't think it could do what I wanted until I looked closer at it and found that it was in fact the exact thing I needed, I don't think some of the people on the robot forum have a lot of experience in the CAM and CNC milling side of things so they comment on what they think they know based on traditional robot use.

[Jeremy]

Hi Colin,

If you pulled the joint values from the real robot to RDK, you should be just fine. The location in RDK will change, but not the location on the real robot.
The same goes for the cartesian position.

The only issue would be if you took the cartesian position on the robot and converted those in joint position in RDK or vice versa. But even that could be fixe quite easily, so I don't think your will spend much time fixing that.

Jeremy