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?
Many thanks!!
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?
Many thanks!!