线程评级:
  • 0 (s) - 0平均投票
  • 1
  • 2
  • 3
  • 4
  • 5
MoveJ (…,阻止= False)队列所有执行的机器人
# 1
我试图让一个机器人臂动态跟踪一个物体的位置,我以相当高的速度(125赫兹)。然而,当我叫MoveJ (…,阻止= False)在125赫兹,在队列中的位置看来几乎立刻机器人和落后。

有办法叫MoveJ (…阻塞= False),所有先前的行动被丢弃,只是专注于执行当前操作?
# 2
我试着做同样的事情,移动机器人使用Kinect传感器数据或LeapMotion。如果一个c#解决方案适合你,我会把它当我得到它。异步等待魔法……
# 3
这将是非常有用的!如果我得到它使用Python同时,我会送你我。

所以,有一件事我已经包装了MoveJ (…在两行阻塞= False)语句,将测量运行时间。当我减少我叫MoveJ (…,阻止= False)(例如,每50次,而不是每一次),我得到时间测量类似:

0.02692437171936035
0.02892446517944336
0.02849864959716797
0.030916213989257812
0.03730583190917969
0.032895565032958984
0.03286123275756836
0.033863067626953125
0.04114723205566406
0.0465848445892334
0.020911693572998047

所以,平均33毫秒。

然而,当我叫MoveJ (…,阻止= False)所需的速度(在我的例子中,125 Hz),数字似乎不少:

0.05566143989562988
0.03397536277770996
0.052632808685302734
0.03386187553405762
0.03390979766845703
0.0668799877166748
0.03586983680725098
0.04915642738342285
0.04779958724975586
0.046747446060180664
0.05224156379699707
0.04627823829650879
0.0688173770904541
0.04802346229553223
0.05086350440979004
0.031949520111083984
0.031914710998535156
0.05627083778381348

所以,平均47个毫秒。

这可能是因为我的电脑无法跟上……?代码我时间只是Fanuc_2_Pose(…)和MoveJ (…,阻止= False)。

事实上,这实际上似乎表明至少有一个的问题是……在125赫兹,这段代码需要执行在8或少女士为了跟上。但是,它需要更多的时间。

另一方面,如果所有的机器人控制器位置不排队,我认为这也就不那么重要了,因为它只会执行最新的,潜在的命令我给它。

你可能想要时间代码。

下一步我将尝试使用RTDE代替RoboDK来控制机器人,看看一个区别:

https://www.universal-robots.com/article...tde-guide/
https://pypi.org/project/ur-rtde/
# 4
这些利率看起来不错,api是一个套接字通信之间的python / c# / c++程序和robodk所以开销但是windows确实有很好的工作在减少。其他开销来自robodk与机器人交流,我们使用RTDE接口驱动程序你所以你可能会失望的任何语言的性能收益变化或直接与机器人交流。

更新率也取决于你观察到的机器人,让机器人移动少导致反应速度随着机器人似乎队列发送给它的位置。这个行为在很大程度上取决于准确的机器人和驱动程序使用,机器人的加速度和速度限制除了协议开销可能导致不够快速行动。如果您只阅读机器人的位置和不让它移动你可以得到更好的更好的性能,但30 ms是最好的你可以让你的司机当移动。
# 5
菲利普,感谢您输入!

经过进一步的考虑,我认为利率不是问题的原因我观察。

当你说,“随着机器人似乎队列发送给它的位置”,你知道一个方法,使机器人不是队列的位置吗?我的偏好是机器人仅仅遵循最新的命令我给它和摆脱其他之前的最新命令队列中。

我意识到这可能是典型的操作,但它似乎应该是可能的…
# 6
嘿,伙计们,这是我迄今为止。我创建了两个线程,一个用于从TouchDesigner获得构成数据通过OSC和把它变成一个ConcurrentStack c#后进先出(线程安全的),一个用于弹出堆栈的数据,并将其发送给RoboDK清理堆栈后流行的选择。这样我只能确保机器人得到的最新数据,忽略了休息。
在模拟模式,一切工作正常:
https://youtu.be/V2APL5nr6I8
轻微的延迟是由于滤波应用于TouchDesigner。

然而,问题是沟通与实际机器人(库卡KR250 KRC2内阁)。
发生了什么是,它需要大约30 ms的OSC线程更新堆栈(对应于30 fps),但在300毫秒,400毫秒左右机器人通信。这一切发生的时候,当我发送一个恒定的姿势。当我改变姿势和机器人实际执行一个动作我变长时间和没有连续性之间的位置。司机这方面我认为这是一个问题,我没有正确配置。这里有一个草图的:
https://photos.app.goo.gl/YRryYAAQHh3CXwoA8
# 7
我实现了一些非常相似,除了在Python中,和非常相似的结果。我使用UR5。

在我的情况下,延迟大约是400 ms。

我更新UR5最新的软件和延迟没有改变。

老实说,我不确定这是一个驱动程序问题。似乎没有人专注于解决这个问题。

我想知道如果延迟将会降低而不是使用MoveJ(…),机器人手臂的关节角计算我们在PC上运行的程序,然后使用setJoints(…)和MoveJ (…)。




用户浏览这个线程:
1客人(年代)