帖子: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 PMhoolymama.）
嗨,杰里米,
我是朱利安·曼。我正在和Asher (xop)一起研究这个问题，今天我们进一步探讨了一下。
我们有一个KR8机器人。我根据规格表构建了模型，并在本文中包含了.robot文件。
我们一直在输出由KUKA KRC4后处理器生成的程序，它们在机器人上运行得很好。
问题是当我们使用线性移动的Run-On-Robot时。实际机器人上TCP的方向是错误的。换句话说，直接发送给机器人的旋转值与后处理器生成的旋转值不同。一些细节:
刀架WRT法兰全为零。
参考系WRT机器人基座均为零。
预设的欧拉角设置为ZYX (Kuka/Nachi/ABB)
在机器人面板(截图)中可以看到，当将tool- wrt -reference设置为显示ZYX (Kuka/Nachi/ABB)，旋转值设置为(-25,88，-30)时，则工具的方向正确(X指向下，Z指向远离机器人，Y指向世界Y)。
我在那个位置/方向做了一个目标，在目标选项中，默认情况下，它显示Staubli/学术方向[-70.91,84.69,69.99]。(我假设具有不同旋转顺序选项的组合框仅用于显示?
如果我们编写一个程序，让它线性移动到那个目标，然后保存程序，机器人就能顺利到达那里。
然而，如果我们在机器人上运行，使用apikuka驱动程序，它面向机器人，并且我们在教师挂件上读取的方向值与设置为Staubli时在目标选项中显示的方向值相同。例如，真实机器人的X方向应该是-25，但实际上是-70，以此类推。如果roboDK机器人被真正的机器人驱动，它也面朝后接收[-70.91,84.69,69.99]。
只是为了确保，我们然后用手(-25,88，-30)进入教学挂件和工具转向正确的位置。
因此，在我们看来，apikuka是直接通信发生的通道，它的行为与KRC4后置处理器不同。
应用程序中是否还有其他地方需要设置旋转顺序?
我在设置机器人的时候错过了什么吗?
阿皮库卡有问题吗?
或者我可以尝试一个简单的解决方法——也许转换旋转来补偿?
多谢! !
职位:28
线程:12
加入时间:2018年4月
声誉:
4
嗨，杰里米，艾伯特，
只是想知道这个解释和截图是否有助于解释这个问题?
帖子:1832
线程:2
加入:2018年10月
声誉:
70
嗨Hoolymama,
我上周和艾伯特讨论过你的问题。
本周，他应该在某个地方进行更深入的调查。
看起来TCP和/或Base没有被驱动程序更新。
这可能是控制器端的“保护”，防止外部修改这些参数……
杰里米
职位:28
线程:12
加入时间:2018年4月
声誉:
4
谢谢杰里米!
这可能是控制器端防止外部修改这些参数的“保护”吗?
我不这么想。控制器(KUKA KRC4)从RoboDK接收线性移动值，并且这些值的平移分量是正确的。TCP到达正确的位置。问题是它接收到的欧拉旋转值是在Staubli/学术性旋转顺序中，因此这些值与KRC4期望的库卡旋转顺序完全不同。
帖子:1832
线程:2
加入:2018年10月
声誉:
70
01-29-2021, 02:56 am
(这篇文章最后修改:01-29 2021,02:58 AM由杰里米.）
嗨,朱利安,
很抱歉耽搁了。
你可以试试附在这里的驱动程序，让我知道它是否有效吗?
只需将其解压缩到“C:/RoboDK/api/Robot”
杰里米
