Hi, I have a problem running a Kuka KR-8 / KRC4 Compact robot remotely through RoboDK.
I followed the setup instructions here and here. So the robot is connected, the ping is successful, and the robot moves as expected in the first P2P move of the test program.
At the first point the robot then rotates roughly 180 degrees so the tcp is facing towards the robot, instead of away from it, before attempting to follow along a series of linear movements. It eventually runs into a joint limit error.
The program runs with the TCP facing away as planned if running the visualisation in RoboDK while not connected to the robot, and if I publish the KRL.src and load the program to the robot via usb it also works.
Could this be a driver issue? I am using the 'apikuka' driver selected from the list in the connection panel. Is this the correct one? The only other Kuka driver I see in the list is for the IIWA
As your first movement is fine (a PTP using joints value) and the other ones aren't, it means you have a discrepancy between your controller setup and your RoboDK setup.
It could be a simple TCP orientation issue, or something a bit more tricky like the position of the robot base with respect to the rail orientation.
I would recommend you to start moving the robot with the teachpendant and note the motion direction. You can then compare with the behavior in RoboDK.
Make sure the X,Y,Z move in the same direction in both environments.
Jeremy
Find useful information about RoboDK and its features by visiting our Online Documentation and by watching tutorials on our Youtube Channel.
01-05-2021, 10:56 PM (This post was last modified: 01-05-2021, 11:21 PM by hoolymama.)
Hi Jeremy,
It's Julian Mann here. I'm working with Asher (xop) on this and we explored a little further today.
We have a KR8 robot. I built the model from the spec sheet and have included the .robot file in this post.
We have been outputting programs generated by the KUKA KRC4 Post-processor and they run perfectly on the robot.
The problem is when we use Run-On-Robot with linear moves. The orientation of the TCP on the real robot faces the wrong way. In other words, the rotation values being sent directly to the robot are not the same as those generated by the post-processor. Some details:
The tool frame WRT flange is all zeros.
The reference frame WRT robot base is all zeros.
Default Euler angles in prefs are set to ZYX (Kuka/Nachi/ABB)
In the robot panel (screenshot) you can see that when tool-WRT-reference is set to display ZYX (Kuka/Nachi/ABB), and the rotation values are set at (-25,88,-30), then the tool is oriented correctly (X pointing down, Z pointing away from robot, Y aligned with world-Y)
I made a target at that position/orientation and in the target options, by default, it displays Staubli/Mecademic orientation [ -70.91, 84.69, 69.99 ]. (I assume the combo box with different rotation order options is for display-only?
If we make a program with a linear move to that target, and save the program, the robot goes there just fine.
However, if we run-on-robot, using the apikuka driver, it faces back into the robot and the orientation values that we read on the teach-pendant are the same as those displayed in the target options when set to Staubli. i.e. X orientation on the real robot should be -25 but it is -70 and so on. If the roboDK robot is being driven by the real robot, it too faces backward and receives [ -70.91, 84.69, 69.99 ].
Just to make sure, we then entered by hand (-25,88,-30) on the teach pendant and the tool turned to the correct position.
So it seems to us that apikuka is the channel through which direct communication happens, and it is behaving differently to the KRC4 post processor.
Is there another place in the app where we need to set the rotation order?
Did I miss something while setting up the robot?
Could there be an issue with apikuka?
Or is there a hacky workaround I could try - Maybe convert rotations to compensate?
I discuss your issue with Albert last week.
He should take a deeper look somewhere this week.
It looks like if the TCP and/or Base were not updated by the driver as they should.
Could it be a "protection" on the controller side preventing external modifications of these parameters...
Jeremy
Find useful information about RoboDK and its features by visiting our Online Documentation and by watching tutorials on our Youtube Channel.
>> Could it be a "protection" on the controller side preventing external modifications of these parameters?
I don't think so. The controller (KUKA KRC4) is receiving linear move values from RoboDK, and the translation component of those values is correct. The TCP goes to the right place. The problem is that the Euler rotation values it receives are in the Staubli/Mecademic rotate order, and therefore the values are completely different from the Kuka rotation order that the KRC4 is expecting.
