帖子:1832
线程:2
加盟时间:2018年10月
声誉:
70
嗨xop,
因为你的第一个动作是好的(一个PTP使用关节值)，而其他的不是，这意味着你的控制器设置和RoboDK设置之间有差异。
这可能是一个简单的TCP方向问题，也可能是一些更棘手的问题，比如机器人基座相对于轨道方向的位置。
我建议你开始用教学器具移动机器人，并注意运动方向。然后你可以与RoboDK中的行为进行比较。
确保X,Y,Z在两种环境中都朝着相同的方向移动。
杰里米
职位:28
线程:12
加入:2018年4月
声誉:
4
01-05-2021, 10:56 PM
(本文最后修改日期:01-05-2021,11:21 PM byhoolymama)。
嗨,杰里米,
我是朱利安·曼。我正在与Asher (xop)合作，今天我们进行了进一步的探索。
我们有一个KR8机器人。我从规格表中构建了模型，并在本文中包含了.robot文件。
我们已经输出了库卡KRC4后处理器生成的程序，它们在机器人上完美地运行。
问题是当我们使用Run-On-Robot进行线性移动时。真实机器人的TCP朝向错误。换句话说，直接发送给机器人的旋转值与后处理器生成的旋转值不相同。一些细节:
工具架WRT法兰为全零。
WRT机器人的参考系为全零。
prefs中的默认欧拉角度设置为ZYX (Kuka/Nachi/ABB)
在机器人面板(截图)你可以看到，当tool- wrt -reference设置为显示ZYX (Kuka/Nachi/ABB)，旋转值设置为(-25,88，-30)，那么工具的方向是正确的(X指向下方，Z指向远离机器人，Y与world-Y对齐)
我在那个位置/方向上做了一个目标，在目标选项中，默认情况下，它显示Staubli/Mecademic方向[-70.91,84.69,69.99]。(我假设具有不同旋转顺序选项的组合框仅用于显示?
如果我们编写一个线性移动到目标的程序，并保存程序，机器人就能顺利到达目标。
然而，如果我们run-on-robot，使用apikuka驱动程序，它面向机器人，我们在teach-pendant上读取的方向值与设置为Staubli时在目标选项中显示的方向值相同。例如，真实机器人的X方向应该是-25，但它是-70等等。如果roboDK机器人被真正的机器人驱动，它也面朝后，接收[-70.91,84.69,69.99]。
为了确保无误，我们用手在吊坠上输入(-25,88，-30)，然后工具转到正确的位置。
因此，在我们看来，apikuka是直接交流发生的通道，它与KRC4后处理器的行为不同。
在应用程序中是否还有其他地方需要设置旋转顺序?
我在设置机器人时遗漏了什么吗?
apikuka有什么问题吗?
或者有一个hack的工作，我可以尝试-也许转换旋转补偿?
多谢! !
职位:28
线程:12
加入:2018年4月
声誉:
4
嗨，杰里米，艾伯特，
只是想知道这个解释和截图是否有助于阐明这个问题?
帖子:1832
线程:2
加盟时间:2018年10月
声誉:
70
嗨Hoolymama,
上周我和艾伯特讨论了你的问题。
本周他应该在某个地方进行更深入的研究。
看起来，如果TCP和/或Base没有被驱动程序更新。
这是不是控制器端的一种“保护”，可以防止外部修改这些参数?
杰里米
职位:28
线程:12
加入:2018年4月
声誉:
4
谢谢杰里米!
>>这是控制器端的一个“保护”，防止外部修改这些参数?
我不这么想。控制器(KUKA KRC4)从RoboDK接收线性移动值，并且这些值的转换组件是正确的。TCP到达正确的位置。问题是它接收到的欧拉旋转值是Staubli/Mecademic旋转顺序，因此这些值与KRC4所期望的库卡旋转顺序完全不同。
帖子:1832
线程:2
加盟时间:2018年10月
声誉:
70
01-29-2021，凌晨02:56
(本文最后修改:01-29-2021,02:58 AM by杰里米)。
嗨,朱利安,
很抱歉耽搁了。
你能试一下这里的驱动器，让我知道它是否能用吗?
只需将其解压到“C:/RoboDK/api/Robot”
杰里米
