2、运动学求解器配置：KDL与TRAC-IK对比、自定义运动学插件（IKFast/BioIK）、求解器参数调优

运动学求解器，说白了就是机器人的「关节翻译官」。你告诉它末端要去哪，它告诉你每个关节该转多少度。这个环节要是没配好，后面规划、控制全是白搭。我这些年调试过的机器人，十有八九的问题都出在求解器上——要么解不出来，要么解出来但路径诡异。

今天咱们就掰开揉碎，把 MoveIt 里最常用的几个求解器聊透。

KDL 是 Orocos 项目里的老牌求解器，MoveIt 默认就带它。TRAC-IK 呢，是后来 NASA 那边搞出来的优化版。两者都是数值迭代法，但脾气完全不同。

我个人习惯是：调试阶段先用 TRAC-IK，因为它容错率高，能帮你快速验证运动学模型对不对。等上了产线，如果对实时性要求极高，再切回 KDL 并做针对性调优。

小技巧： 在 urdf 的 <plugin> 标签里，你可以同时注册多个求解器。MoveIt 会自动按优先级尝试，第一个解出来就用它。我经常把 TRAC-IK 放第一位，KDL 放第二位做兜底。

数值求解器虽然通用，但遇到特殊构型（比如 7 轴冗余臂、并联机构）就有点力不从心了。这时候就需要上「定制化方案」。

IKFast 是 OpenRAVE 项目里的一个工具，它能针对你的机器人几何参数，自动生成解析解代码。解析解意味着——只要存在解，它就能瞬间算出来，没有迭代、没有超时。

我在项目里遇到过一台 6 轴协作臂，用 KDL 求解平均要 8 毫秒，换成 IKFast 后直接降到 0.1 毫秒。不过代价是：生成过程比较折腾，需要装 OpenRAVE 和 SymPy，而且只支持特定构型（比如 6 轴球形腕）。

# 生成 IKFast 插件的典型命令
python openrave.py --database ikfast --robot=my_robot.zae --iktype=transform6d --exportcode=my_robot_ik.cpp

BioIK 走的是另一条路——它用遗传算法、粒子群这类启发式方法来找解。听起来有点「玄学」，但对付冗余自由度机器人特别管用。

你想想看，7 轴臂有无数种姿态能到达同一个末端位置，数值求解器往往只给你一个「最靠近当前关节角」的解。BioIK 可以让你指定优化目标：比如「让肘部尽量低」「让肩关节受力最小」。嗯，这里要注意，BioIK 的计算时间不太稳定，不适合硬实时场景。

避坑指南： 我曾经在 BioIK 里设了 5 个优化目标，结果求解时间飙到 200 毫秒。后来学乖了——最多设 2-3 个目标，优先级最高的放前面。

不管用哪个求解器，有几个参数是绕不开的。调好了，事半功倍；调不好，机器人就在那「抖啊抖」的。

默认值通常是 0.005 秒（5 毫秒）。对于简单 6 轴臂够用，但 7 轴臂或带移动基座的系统，建议放宽到 0.02-0.05 秒。

<group name="arm_group">
    <kinematics_solver>
        <timeout>0.02</timeout>
    </kinematics_solver>
</group>

位置精度默认 1e-4 米，姿态精度 1e-4 弧度。大多数场景够用。但如果你做精密装配（比如插孔），建议把位置精度提到 1e-5。

代价是什么？求解时间可能会翻倍。我一般先设 1e-3 快速验证，最后再收紧。

这是最容易踩坑的地方。对于 7 轴臂，你必须告诉求解器「哪个关节是冗余的」。MoveIt 里通过 redundant_joint_indices 来指定。

<kinematics_solver>
    <redundant_joint_indices>3,4,5</redundant_joint_indices>
</kinematics_solver>

我见过有人把 7 个关节全标成冗余，结果求解器直接崩溃。正确的做法是：只标 1-2 个关节作为冗余，通常是肩部或肘部的某个关节。

    核心原则： 冗余关节越多，求解空间越大，但求解难度也指数级上升。保持克制，只给必要的自由度。

下面这张图是我自己整理的求解器选型决策流程，帮你快速定位该用哪种方案：

这张图的核心逻辑很简单：构型越特殊，越值得上定制化方案。别一上来就想着搞 IKFast，先问问自己——你的机器人真的需要解析解吗？大多数场景下，TRAC-IK 调好参数就够用了。