第一次跑通 auboi5 D435i 的手眼标定我前前后后折腾了三天。装上 easy_handeye 之后我以为照着 README 就能一次跑通结果采集了 17 组样本Compute 出来的平移量跟实际相机安装位置差了 49cm旋转矩阵也明显不对。后面对照 TF 树一点点查发现是两个问题叠在一起一是 tracking_base_frame 填错二是 aruco 标定板的 marker_size 跟实物对不上。这篇文章就把我实测中遇到的问题、排查思路、以及最后稳定跑通的流程记录下来给正准备做 auboi5 D435i 手眼标定的朋友一个参考。文中默认环境是 Ubuntu 18.04 ROS Melodic机械臂是越疆 auboi5相机是 Intel RealSense D435i标定工具是 easy_handeye以 mhe 的维护分支为准。如果你用的是 Kinetic、Noetic 或者其他版本命令可能略有差异但排查思路是一样的。1. 开标之前先算清这笔坐标账1.1 你是 eye-in-hand 还是 eye-to-hand这一步直接决定 launch 参数手眼标定第一步不是跑代码而是想清楚你的系统属于哪种安装关系。D435i 固定在 auboi5 第六轴法兰或者末端夹具上标定板放在工作台不动这种叫 eye-in-hand眼在手上easy_handeye 的 eye_on_hand 参数要设为 true。反过来相机固定在天花板或者支架上标定板绑在机械臂末端来回移动这种叫 eye-to-hand眼在手外eye_on_hand 要设为 false。我一开始没有认真看这个参数想当然按 README 默认的 eye_on_hand:true 来跑。但当时相机其实还没装到末端是放在旁边三脚架上的这样标出来的结果自然毫无意义。新手最容易在这里翻车因为两种模式的 TF 结构完全不同。对 auboi5 配 D435i 的常见项目来说如果只是做视觉引导抓取eye-in-hand 会更灵活如果相机需要盯着整个工作区做安全监控那就选 eye-to-hand。确定好之后再往下一步走。1.2 别被 AX XB 吓到但要知道采样为什么必须花式动easy_handeye 底层调用 visp 的 vpHandEyeCalibration解的是经典手眼标定方程 AX XB。用大白话说机械臂带动相机从位姿 1 运动到位姿 2机械臂自己知道末端动了多少这个运动记作 A相机通过观察固定的标定板也能算出自己动了多少这个观测值记作 B。A 和 B 之间的差值就是相机相对末端的固定安装变换 X这也是我们最终想要的结果。只有一个 A 和一个 B 是解不出 X 的需要多组大差异运动互相约束。这也是为什么 easy_handeye 要求采集至少 3 组、实际建议 15 到 20 组样本而且每组之间要有明显旋转变化。如果机械臂只是平移或者每次都是绕同一根轴小幅转动方程会退化解出来的 X 误差巨大甚至直接发散。我第一次采样的动作就很保守每次只挪几厘米、角度几乎不变结果 Compute 之后残差非常大。这是非常典型的误区。1.3 先把 TF 树拉出来看一眼能省下半天的排查时间在启动任何标定程序之前我强烈建议先用rosrun tf view_frames把当前完整的 TF 树截图存下来确认 base_link 到 tool0或 ee_link、以及 camera_color_optical_frame或 camera_link到标定板 frame 的链路完整。easy_handeye 的采样过程本身不会自动识别你的坐标系名所有 frame 名称都要在 launch 里准确指定。D435i 的 realsense-ros 驱动发布两个容易混淆的坐标系camera_link 和 camera_color_optical_frame。前者是相机外壳的物理位姿后者是光学成像坐标系Z 轴朝相机前方、Y 轴向下。easy_handeye 做视觉位姿解算时默认工作的是 optical frame。如果 tracking_base_frame 填成 camera_link检测到的标定板位姿和真实视觉结果之间就差了一个固定旋转标定出来的 X 自然就乱了。这个细节非常隐蔽因为 TF 树里两个 frame 都存在名字相近不容易察觉。2. 环境准备期的三处暗雷2.1 realsense-ros 版本和 librealsense 对不上相机话题直接翻车D435i 在 ROS 里跑起来依赖两块底层 librealsense2 和上层 realsense-ros。很多人装完 realsense-ros 后直接 roslaunch结果发现 /camera/color/camera_info 话题一直没数据或者颜色图像花屏多数是 librealsense2 和 realsense-ros 的版本要求不匹配。我踩过的问题是 Ubuntu 18.04 上默认 apt 源里的 librealsense2 太旧而 realsense-ros 是直接 checkout 的最新 master编译能过但运行时固件通信报错。建议先用dpkg -l | grep realsense和rs-enumerate-devices | grep Firmware确认当前版本再按 realsense-ros 的 README 指定对应的 librealsense2 版本安装。启动相机后也不要急着标定先rostopic echo /camera/color/camera_info看一眼内参 K 矩阵有没有值这是后续视觉位姿解算的基础。如果内参全为零后面无论怎么调 easy_handeye 都是白搭。2.2 auboi5 的机器人驱动、MoveIt 和示教器之间的控制权关系auboi5 接入 ROS 通常有两种路径一种是直接用 aubo_robot 源码里的驱动节点连接控制柜这种方式简单直接机械臂的关节状态、末端位姿会发布到 TF 树但运动规划要自己在代码里写服务调用另一种是启动 MoveIt 的 move_group 规划节点可以结合 RViz 做拖拽、规划和执行。对 easy_handeye 来说核心需求只是能读到 base_link 到 tool0 的 TF所以两种方式都能用关键是 TF 树别断。实际中很多人遇到的问题是示教器上已经手动拖到某个姿态但 ROS 端 RViz 里的模型没有同步原因是 aubo 驱动里的 robot_state_publisher 没有正确加载 URDF或控制柜没有开启使能。还有一点要注意MoveIt 控制真机前必须确认示教器端的协作模式设置正确、使能钥匙处于自动位置否则 move_group 会一直报 planning failed严重时还会触发安全停机。启动后先rostopic echo /tf看看 base_link 到 tool0 的变换是否在持续刷新再做后续操作。2.3 easy_handeye 用哪个源码分支依赖才装得齐全easy_handeye 在 GitHub 上有 IIT 原版和 mhe 的维护分支我更推荐用 mhe 分支因为原版仓库更新慢对 Melodic 和后续 ROS 版本的兼容性差一些有时候还缺依赖。安装方式不复杂进入 catkin 工作空间 src 目录clone 下来再用 rosdep 安装依赖。cd ~/catkin_ws/src git clone https://github.com/mhe/easy_handeye.git cd ~/catkin_ws rosdep install --from-paths src --ignore-src -r -y catkin_make如果 rosdep 提示找不到某些包多半是没加未发布源或者需要从源码编译 visp_hand2eye_calibration。把依赖装齐之后先跑一次空 launch 确认不会报 package not found 再开始标定。这一步省下来的时间远大于装错分支后反复排查的时间。3. 标定流程与采样策略一次顺利标定应该怎么做3.1 把相机、机械臂、easy_handeye 服务器依次拉起来先启动相机roslaunch realsense2_camera rs_camera.launch再启动机械臂这里以 MoveIt 路径为例roslaunch aubo_i5_moveit_config moveit_planning_execution.launch sim:false确认机械臂在 RViz 里能正常显示、TF 树刷新、示教器无报警后再启动 easy_handeye。我通常开三个终端分别放日志避免混合输出难排查。启动 easy_handeye 服务器时关键参数都在 launch 里显式给出不要依赖默认值roslaunch easy_handeye easy_handeye.launch eye_on_hand:true \ camera_name:camera \ robot_base_frame:base_link \ robot_effector_frame:tool0 \ tracking_base_frame:camera_color_optical_frame \ calibration_target:charuco其中 camera_name 要和 realsense 话题名前缀一致robot_effector_frame 需要根据你实际 TF 树里的末端名字来填是 tool0 就写 tool0是 ee_link 就写 ee_link。打开 GUI 客户端rosrun rqt_easy_handeye rqt_easy_handeye3.2 标定板选择charuco 优先材质比版面更关键easy_handeye 支持 aruco 和 charuco 两种标定板。我最后稳定跑通用的是 charuco因为它同时有棋盘格角点和 aruco 编码对遮挡和光照的鲁棒性比单个 aruco 好很多。无论用哪种材质都建议是亚克力板或铝基板上面贴哑光打印的标定板。A4 纸直接贴在纸箱上这种方案在标准室内灯光下偶尔能检测到但稍微晃一点就丢采样时会浪费大量时间。尺寸一定要实际测量而不要只看打印设置的理论尺寸。charuco 的 checkerboard 格子边长和 marker 边长都要按实物准确填写aruco 方案则对应 marker_size。我最初就是从网上下载了一个 aruco 图片直接打印以为边长是 10cm结果打印机缩放后实际只有 8.6cm。这个尺度误差会直接按比例写进标定结果的平移量非常坑。3.3 采样的动作设计姿态要敢动、组合要够散打开 rqt_easy_handeye 之后界面上能看到当前标定板的检测图像和位姿。点击 Take Sample 会同时记录机器人末端位姿和相机观测到的标定板位姿。这里最关键的策略是每组采样之间的姿态差异要足够大覆盖空间要足够散。我后来摸索出来的习惯是把工作空间划分成 5 到 6 个高度层每层在不同 roll、pitch、yaw 下各采 3 到 4 个点总量控制在 15 到 20 组。动的时候要避免两个极端。一是只平移不旋转方程退化二是每次姿态差异过大导致机械臂规划路径必经奇异位型容易报错。协作机械臂虽然可以手动拖拽采样但我还是建议用 move_group 设目标位姿让机械臂自己走这样可以保证每次停止时速度为零、姿态记录稳定。采样过程中我会时不时用 GUI 里的样本一致性检查按钮看一眼如果有明显偏离的 bad 样本果断删除不要留着凑数。3.4 计算与保存结果不是点一下 Compute 就完事采集完样本后点击 Computeeasy_handeye 会调用 visp 求解器给出标定结果终端日志里会打印求解残差数值越小越接近理想情况。得到结果后先不要急着关终端花两分钟看平移量是否在合理范围。比如 D435i 装在 aubo 法兰正下方约 8cm 处那么 X 的 z 分量应该接近 -0.08m 这个量级x 和 y 则取决于相机是否对中。合理的话点 Save结果会以 yaml 文件保存默认路径在 ~/.ros/easy_handeye/ 下。我的习惯是立即用cat ~/.ros/easy_handeye/*.yaml看一眼内容把 rotation 和 translation 抄到项目配置里同时也作为结果备份。4. 实测踩坑记录四类问题从现象到根因4.1 机械臂规划失败导致采样线程卡住我实际踩过的第一个坑是连续采到第 9 组样本时点击 Take Sample 后机械臂不动GUI 一直转圈终端里反复出现 move_group 的 IK failed 或 Planning failed 日志。一开始以为是程序死锁后来发现是目标位姿离机械臂的奇异位型太近move_group 算不出合法轨迹。这类问题的排查思路是先确认是不是所有采样的目标位姿都失败还是只有某一个。如果只有个别先取消当前运动规划把机械臂手动拖到安全位姿再用 rqt_easy_handeye 换个更温和的目标重试。如果所有规划都失败检查机器人是否处于报警状态、是否要重新使能。协作机械臂的好处是遇到奇异位型往往会刹车配合人工拖拽比较好恢复但千万别生拉硬拽先确认刹车状态再说。4.2 标定板检测抖动纸质板、反光和曝光三个因素叠加另一个高频问题是标定板位姿在 rqt 里跳动TF 树里 camera_color_optical_frame 到 marker frame 的变换每秒都在变有时还会突然跳没。排查下来常见原因有三个第一纸质标定板边缘轻微弯曲在较大视角变化时角点提取出现偏差第二打印墨水反光在闪光灯或顶灯下局部过曝aruco 解码失败第三D435i 的自动曝光在某些角度下反应太慢。解决方法我试下来比较有效的是换亚克力或铝基标定板调整相机曝光参数尽量让标定板在画面中占比超过三分之一同时避免阳光直射或强点光源。我在 rqt 里专门调了 realsense 的 color 曝光后检测稳定性明显提升bad 样本的比例大幅下降。另外标定板固定时要用夹子或双面胶固定牢手扶平板这种操作在采样过程中绝对不要出现。4.3 标定结果偏差几十厘米tracking_base_frame 和 marker_size 双重翻车这就是文章开头说的那次 49cm 偏差事件。当时我采集了 17 组样本样本一致性看起来也正常可 Compute 出来的结果偏离到离谱。我先把机械臂末端停在几个固定位姿用rosrun tf tf_echo base_link tool0打印末端 TF确认机器人侧数据没错再用 RViz 观察标定板检测结果发现检测出的 marker 位姿虽然平滑但它的坐标系方向跟真实场景对不上。进一步排查原来是 easy_handeye launch 里我把 tracking_base_frame 写成了 camera_link而视觉解算实际工作坐标系是 camera_color_optical_frame。这两个 frame 之间存在一个接近 180 度的旋转导致标定板观测位姿整体被扭转。另外我还发现打印的 aruco 边长和 marker_size 参数差了 14%。两个错误叠加最终结果自然荒唐。把 frame 名称改对、marker_size 改成实测值之后重新采样计算结果立刻回归合理范围。这个坑很难靠看代码发现因为它不报任何错误只表现为数值错误。建议在标定前先花一分钟在 RViz 里加一个 Axes 显示 camera_color_optical_frame手动确认标定板坐标系的方向和位置跟真实标定板对得上再开始采样。下面这个对照表是我后来整理给自己看的排查清单现象可能原因排查方法平移量数值偏离安装位置几十厘米tracking_base_frame 用了 camera_link 而非 camera_color_optical_frameRViz 里查看标定板坐标系方向平移量按比例整体偏大或偏小marker_size 与实物不一致用卡尺实测标定板边长旋转矩阵看起来不自然标定板平面与光学平面的尺度或 frame 出错检查样本一致性标记重看 frame 参数4.4 一致性检查出现大量 bad 样本的教训有一轮标定我图省事把机械臂大致移到 5 个位置每个位置只做小幅旋转就采集 3 个样本结果 15 个样本里有 11 个被标记为 bad。原因是这 5 组样本的末端姿态实际都在同一个平面上旋转轴方向几乎一致方程求解退化visp 算法无法稳定估计 X。坏消息是 bad 样本删掉之后只剩 4 组有效样本又太少了。只好重新设计采样路径把末端分别朝向多个不同方向每组之间保持至少 15 到 30 度的姿态差同时让机械臂臂型在空间上分散开重新采集后 bad 样本基本都消失了。这个经历让我养成了一个习惯每采 3 到 4 个样本就检查一次一致性而不是最后一起检查这样能及时发现问题重采成本也低。5. 验证标定结果并把它真正用起来5.1 如何判断这次标定到底靠不靠谱标定完成后首先要看数值合理性平移向量的量级和方向要与相机实际安装位置一致旋转矩阵基本接近正交。但数值合理并不代表精度足够真正的验证方式是做视觉引导对准。我的做法是先把标定结果发布到 TF 里roslaunch easy_handeye publish.launch eye_on_hand:true然后在工作台上放一个小目标物体用视觉检测它在相机坐标系下的位置通过标定出的 X 换算到机械臂基座坐标系再让机械臂末端移动到该点上方观察实际对准误差。如果对准误差在 1cm 以内说明这次标定可以进入项目联调如果差得很远大概率不是验证代码的问题而是标定数据或参数仍有错误需要重新检查。5.2 别忘了机械臂绝对精度给标定带来的天花板很多人在标定结果不理想时会把锅全甩给视觉或者 easy_handeye但其实手眼标定的精度有一个现实天花板机械臂的绝对精度。auboi5 的重复定位精度可以做得比较高但手眼标定求解过程依赖的是运动学模型计算的末端位姿机器人绝对精度、连杆参数误差、负载下垂都会影响这个值。这就是为什么即使采样动作很完美也会存在一定系统误差。降低这种误差的办法是让采样覆盖机械臂的不同构型而不是在同一个狭窄区域反复走。比如抓取任务常用到的工作空间多采一些点尽量让各个关节都参与运动让标定结果在实际使用工况下更平均。如果项目对精度要求很高建议配合外部测量设备标定机器人运动学参数再做手眼标定效果会更好。5.3 把结果固化到系统不要每次启动都重新标定标定完成并验证通过后把生成的 yaml 文件保存到项目配置目录在启动脚本里加载。只要相机没有被拆装机器人基座没有被移动标定结果就一直有效没有必要每次开机都重新跑一遍。但如果相机固定螺丝松动过一次、或者机器人被重新设定了零点那就要重新标定这个判断原则要刻在项目文档里。我在项目里是写了一个 launch 文件加载标定 yaml同时启动相机、视觉检测节点和机械臂驱动这样每次上电一键拉起不需要人工介入。整个 auboi5 D435i easy_handeye 的标定流程跑通之后后续做目标抓取、工件定位都顺畅了很多前期那些坐标系、marker_size、采样动作的坑反而成了排查问题的宝贵经验。如果让我给后来者一个最实在的建议标定前花 30 分钟把 TF 树和标定板的真实尺寸核对清楚比什么都值。坐标系和尺度这两件小事几乎决定了手眼标定是第一次就过还是折腾三天。有一次我把 tracking_base_frame 改对之后重新采集了 15 组样本从启动到验证只用了不到 40 分钟。如果你的系统流程和我类似照着上面的思路走一遍大概率能少踩一大半的坑。