我认为这可能比看起来更难做到。
目前，连续点动实际上计划为向轴（或关节）限制的单个连续移动。这就是移动在行程结束时自动停止的方式。
松开点动按钮时，移动中止，关节根据其加速度限制减速至停止。
改变终点停止位置需要重新计划运动，这可能需要立即中止和停止，然后开始新的运动。

这个要求的应用是什么？停止并重新开始会起作用吗？

应用程序可能会有所不同，比方说我只能从某个点到达的工具更改，或者用于管理非 Trivkins 机器（如 scara）的轴限制，可以使用简单的 Hal 组件进行管理，但如果点动方向切换太快

对于工具更换器应用程序，我认为能够定义更复杂的碰撞几何体会更健壮。我们可以定义多个边界框，而不是只为每个轴设置一个整体最小值/最大值，这些边界框组合在一起将定义工具的允许区域。对于永久性固定装置（虎钳、旋转工作台、安装在工作台上的工具设定器）也可以这样做。

很容易检查工具位置是否在允许的区域之一内（因此在限制范围内）。然而，规划一条无碰撞路径会更难（但可行）；想象一个“U”形的允许区域，并在“U”的尖端之间规划一条路径。端点将在限制范围内，但中间点不会。

@grandixximo这会涵盖您的用例吗？如果是这样，我想长期采用这种方法，即使我们现在需要使用 INI 引脚的权宜之计解决方案。

是的，scara 会有一个甜甜圈形状的限制，你不能从中间通过，如果能够定义这样的形状或“U”形限制区域，你应该在哪里知道停止在 U 的提示上并且不发生碰撞。

那会很好用

经过一番搜索，libccd 似乎是碰撞检测的事实标准（由 OpenDE、Bullet Physics、ROS 中的 FCL 使用），它可以处理三角形网格，只要它们是凸的（非凸对象可以分解为多个凸的）。STL 文件形式的三角形网格对用户来说肯定很方便，因为它们可以在 CAD 中建模并保存到 STL。

我对 STL 作为一种基本格式的担忧是它只允许您定义一个对象。有时将多个对象组合起来会很好，例如作为 STL 的虎钳模型、用于总体限制的边界框、用于工具更换器的边界框等。为此，URDF或VRML之类的东西更适合。

与 trimesh 碰撞对象有关的其他一些问题：

• 需要预处理来处理退化或不完整的网格（尽管必须存在库才能执行此操作）
• 图元（盒子、球体、胶囊）更快，这在低功耗平台上很重要

TLDR：trimeshes 对用户来说很容易并且功能强大（复杂的几何形状），但是为了速度和可靠性也有原语会很好。

抱歉，我不清楚，您是对的，多个非连续卷没有意义。但是，需要将非凸体（例如 U 形）分解为凸体以检查点是否在内部，至少要使用像GJK这样的快速算法（libccd 就是这样做的）。的确，我们的目标与典型的碰撞检查相反（因为只有当它与工作空间体积“碰撞”时位置才是好的），但该算法应该同样有效。

没错，这是同样的问题。您知道我们可以查看的该算法的任何示例吗？我很好奇与碰撞检查算法相比它的效率如何。

@andypugh这看起来确实很容易实现，而且对于小的多边形计数，重复列表搜索的开销不太重要。当然，我想注意边界条件（并进行预处理/网格检查以避免退化实体）。在加载时快速搜索工作范围以确保没有孤岛也很有用。

这是否推广到更多维度（即如果我们想包括 ABC 以避免与倾斜头和虎钳发生碰撞）？

机器是否限制了用虎钳/夹具等避免碰撞的地方？这不是通常在 CAM 中完成的吗？我没有经验可以知道，但这就是它看起来可能的样子。

慢跑时如果能不撞到虎钳就好了，但我也希望为非 trivkins 机器（如 scara puma 或 5 轴机器）提供更高级的限制定义，以便能够更安全地在附近慢跑极限将是一项伟大的成就

@mozmck这是一个很好的观点，尝试在机器限制中对夹具的每个小细节进行建模可能会导致收益递减。对于经常更换夹具的业余爱好者来说，将虎钳建模为机器限制的一部分并没有多大意义。对于更专业的设置，除了永久性的虎钳和夹头在桌子上，也许会？

越想越喜欢@andypugh对单个 STL 文件的建议（以及 INI 文件中的坐标偏移）。光线投射算法看起来很简单（如果需要，我们可以依靠线性代数库）。对于网格导入/清理，我们可以使用trimesh2或类似的东西。

如果需要，我们总是可以稍后添加对更复杂的东西（例如 URDF 模型）的支持。