做点云处理的人迟早会遇到一个尴尬局面模型库里的三维点云有鼻子有眼可面对桌面上一堆散乱摆放的真实物体程序死活认不出哪个是目标。PCL的Recognition模块就是在这类场景里做点云识别的“工具箱”。它的目标很直白给你一个模型点云和一个场景点云输出场景里有没有目标、目标在哪个位置、以什么姿态出现也就是6自由度位姿。这篇教程适合两种读者一种是刚开始接触点云物体识别、想用PCL把识别链路跑通的新手另一种是已经用配准做了不少事但发现配准在散乱堆叠、多实例场景里无能为力想切换到识别思路的老手。我会按自己实际调通这套流程的顺序来讲包括原理、代码、参数以及翻过车之后才知道的那些细节。1. Recognition模块到底在解决什么问题1.1 先分清“配准”和“识别”的边界很多朋友一开始会把点云识别和点云配准混着看其实这俩解决的问题完全不同。配准Registration处理的是“两片点云已经比较接近了求一个精细变换把它们对齐”。它的前提是大概知道初始位置哪怕这个位置很粗甚至靠猜测只要在收敛半径内ICP这类算法就能给你一个漂亮的结果。但配准对初始值极其敏感一旦两片点云的相对位置猜得离谱迭代很容易掉进局部最优。识别Recognition面对的是更恶劣的场景场景里有目标物体也有杂物你完全不知道目标在哪儿、什么朝向。拿配准的思路去穷举初始位姿你会立刻被组合数淹没。PCL的Recognition模块换了一个路子先在模型和场景上分别提取局部特征描述子找到可靠的局部对应关系再用几何约束把对应关系聚成“目标实例”的假设最后通过假设验证筛掉错的。整个过程不需要初始姿态所以它能处理“没有任何先验位姿的散乱场景”这是它和配准最本质的区别。1.2 识别任务的两条技术路线PCL里的Recognition从大的方向上其实包含两条路线。第一条是基于局部特征加对应分组的路线。模型和场景各自提取关键点或直接对所有点计算局部特征FPFH、SHOT、3DSC等然后做特征匹配得到一组对应点对再利用几何一致性分组或者霍夫投票把这些对应点对聚成一个个目标实例。这是PCL官方教程主推的路线对遮挡和散乱堆叠的容忍度相当好也是本文后面要展开的内容。第二条是基于全局特征或者模板匹配的路线。它对完整、无遮挡的物体识别效果好速度很快但物体一旦被遮挡全局特征会被污染得面目全非。PCL里也有相关实现比如Linemod那套以及一些全局描述子相关代码但工程里要处理散乱工业场景时局部特征路线的鲁棒性明显更强。另外还有一个常见问题是那深度学习做点云识别不是更流行吗确实基于学习的方法在复杂场景里上限更高但它需要标注数据、训练显卡和推理框架不是所有人上手就能搭起来。PCL这套经典几何识别方案的优势在于没有训练成本模型点云可以直接从CAD或者三维扫描来一个纯C程序就能跑非常适合工业原型验证、教学演示也适合作为学习点云特征体系的入门材料。1.3 什么场景适合用PCL Recognition我自己的判断标准很简单目标物体的表面几何是相对稳定的并且你能拿到它的三维模型点云。典型适合的场景包括工业分拣从传送带上或者料筐里抓出指定型号的零部件货架商品识别识别包装盒、瓶罐这类有明显几何轮廓的物体增强现实识别真实物体后在它上面叠加虚拟信息还有几何质检判断一个工件是否安装到位、朝向是否正确。不适合的场景也要心里有数纯纹理主导的物体PCL这套流程不用颜色只用几何、严重变形或非刚体的物体、完全没有先验模型的未知物体。遇到这些情况你需要的其实是另一套方案硬拿Recognition模块去套会很痛苦。2. 识别管线的主干数据准备、特征与对应关系2.1 完整管线全景PCL的Recognition整个流程如果画成一条线大概是下面这样模型点云和场景点云预处理降采样、去离群点、估算法线。对模型和场景分别计算局部特征描述子。在特征空间里做最近邻搜索建立模型到场景的对应关系。过滤掉不够可靠的对应保留候选。用对应分组算法GeometricConsistencyGrouping或Hough3DGrouping把对应聚成一组组“实例假设”。用假设验证HypothesisVerification判断每个假设是否真的能匹配场景。输出通过验证的模型实例及其6自由度变换矩阵。实际写代码的时候第2步到第6步往往只有几十行但每一步都藏着细节。我在实操里发现新手最容易翻车的地方恰恰是第2步和第3步特征没算对后面全白搭。2.2 预处理体素降采样与法线估计预处理这一步看起来基础但绝对是整套识别效果的“地基”。先说降采样。工业传感器扫出来的点云密度分布常常不均匀离传感器近的地方密、远的地方疏。如果不做处理直接算特征局部邻域点数忽多忽少特征直方图的统计稳定性会受影响。我一般先用体素滤波器把点云降到一个均匀的分辨率。以毫米为单位的话普通场景用3mm的体素尺寸起步大目标可以用到5mm精密小零件用1mm。体素尺寸的选择直接决定了特征搜索半径后面第6章会细说。然后是法线估计。FPFH这类特征必须依赖法线法线质量差特征描述子就是一堆没有意义的数字。我习惯用NormalEstimationOMP多线程版本搜索半径取体素尺寸的1.5到2倍左右。比如体素3mm法线搜索半径用5mm左右。这里有个特别容易踩的坑法线方向存在二义性。局部PCA算出来的法线朝向是不确定的一个区域的法线可能朝左也可能朝右而FPFH直方图对法线朝向是敏感的。解决方案主要有两种一种是在估计法线时设置setViewPoint让法线统一朝向视点另一种是后续计算特征前做一次法线方向翻转让法线大致指向传感器方向。模型和场景如果来源不同这个操作务必做一致不然对应关系数量会断崖式下降。2.3 FPFH特征为什么它是默认选择特征描述子有很多PFH、FPFH、SHOT、3DSC、Spin Image等等。其中FPFH是PCL识别例子里最常见的也是我长期用下来最省心的。FPFH全称是快速点特征直方图。它的思想是在点的一个局部邻域里把点对之间的几何关系编码成三个角度值alpha、phi、theta统计成直方图。PFH需要计算邻域内所有点对的相互关系复杂度很高FPFH做了一个近似只计算中心点与邻域点的关系再对邻域点的SPFH做加权合并这样复杂度从O(nk²)降到O(nk)在工程上完全可接受。输出是33维的直方图。为什么33维这个维度刚刚好太低区分度不够描述不了复杂几何太高KDTree最近邻检索在高维空间里的效率会下降出现“维度灾难”的征兆。33维在PCL生态里既稳定又不慢所以是默认选择。还有一个容易被忽略的点FPFH对邻域半径非常敏感。搜索半径太小能看到的局部几何太少直方图区分度不足半径太大会把不该算进来的表面也包进来模糊了局部特征。我的经验是特征搜索半径取法线搜索半径的2倍左右保证邻域内有足够点参与统计。具体数值搭配见第6章的表格。2.4 建立对应关系的正确姿势特征算好之后接下来的任务是为模型里的每个特征点在场景特征里找到最相似的一个。最直接的做法是KDTree最近邻搜索。我自己写的时候会再加一道“双向一致性校验”先从模型特征搜场景特征找到最近邻再反过来从场景特征搜模型特征只有两边都能对上同一对索引才认为这个对应是可信的。这个操作虽然多写几行代码但能干掉大量“单方面看着像”的误匹配。下面是一段建立对应关系的示例代码我用的是模型特征到场景特征的最近邻搜索加上距离阈值过滤pcl::KdTreeFLANNpcl::FPFHSignature33 matcher; matcher.setInputCloud(scene_features); pcl::Correspondences correspondences; std::vectorint nearest_index(1); std::vectorfloat nearest_sqr_distance(1); for (std::size_t i 0; i model_features-size(); i) { matcher.nearestKSearch(model_features-at(i), 1, nearest_index, nearest_sqr_distance); if (nearest_sqr_distance[0] distance_threshold) { pcl::Correspondence corr; corr.index_query static_castint(i); corr.index_match nearest_index[0]; corr.distance nearest_sqr_distance[0]; correspondences.push_back(corr); } }distance_threshold这个值怎么定33维空间里的欧氏距离没有一个万能数字。我通常的做法是先设一个比较大的值比如1.0把程序跑起来看对应关系的数量再逐步收紧到0.3到0.5之间。如果对应数量太少很可能是特征算得有问题这时候不要盲目放宽阈值先回头检查法线和半径。3. 对应分组从散乱对应到聚类假设3.1 GeometricConsistencyGrouping的分组思想对应关系建好后里面其实混着大量噪声。那怎么从中找出“真正属于同一个目标实例”的那组对应答案是几何一致性。想象你手里有一组对应点对模型上的点A对应场景里的点A模型上的点B对应场景里的点B。如果这组对应是对的那么模型上A和B之间的距离应当和场景里A和B之间的距离近似相等。这个距离一致性不受刚体变换影响因为距离是旋转平移不变的。GeometricConsistencyGrouping干的事就是基于这个原理遍历对应关系凡是两两之间距离差小于阈值的就认为它们几何一致聚到同一个簇再以簇为基础不断扩张最终每个簇对应一个“目标实例假设”。这个过程有点像区域生长但生长的判据不是颜色或者法线而是对应点对之间的距离一致性。3.2 两个关键参数怎么理解、怎么调GeometricConsistencyGrouping有几个参数其中两个最重要gc_threshold_和eps_。gc_threshold_是几何一致性阈值单位跟点云坐标一致用来判断两个对应是否“距离一致”。我试过太小的值比如设成1结果一个完好的圆柱体目标被切成了七八个碎片每个碎片只覆盖目标的一小片表面设太大的值比如20又会出现把不同实例甚至杂物的对应混在一个簇里的情况。一般从体素分辨率的2到5倍起步比如3mm体素就设5到10再观察聚类输出调整。eps_是区域生长的搜索半径它决定了“多大的局部范围算同一个簇”。这个值跟特征搜索半径有一定关系通常取特征搜索半径差不多或者稍大一点。我习惯从和特征搜索半径相同的数量级开始比如10mm。还有一个setModelSceneCorrespondences的输入要注意这个函数接收的是我们第2章算出来的pcl::Correspondences不是点云。我头一回用的时候想当然给了一堆点云进去编译不报错但运行结果完全不对卡了半天才反应过来。实际调用代码大概是这样的pcl::GeometricConsistencyGroupingpcl::PointXYZ, pcl::PointXYZ gc_clusterer; gc_clusterer.setGCThreshold(8.0); gc_clusterer.setEpsilon(10.0); gc_clusterer.setInputCloud(model_down); gc_clusterer.setSceneCloud(scene_down); gc_clusterer.setModelSceneCorrespondences(correspondences); std::vectorpcl::Correspondences clustered_correspondences; gc_clusterer.cluster(clustered_correspondences);跑完之后clustered_correspondences里每个元素就是一个候选实例。在调试阶段我会把这个数量打印出来如果一个场景里明明只有3个目标却聚出了20个簇那多半是gc_threshold_太松或者特征质量不行、误匹配太多。3.3 Hough3DGrouping什么时候更划算GeometricConsistencyGrouping简单直接但它有局限它本质上是贪心的局部聚类遇到目标数量多、相互遮挡严重、场景非常杂乱的情况容易碎或者混。这时候可以考虑Hough3DGrouping。它的思路是把每个对应关系作为一次投票投到霍夫空间里位置和姿态一致的投票会在同一个格子里形成峰值峰值对应一个实例假设。这个算法对局部噪声和部分遮挡更不敏感因为它靠的是投票的累积效应。作为交换它需要法线作为额外输入参数也多一个setHoughBinSize霍夫空间的格宽需要根据目标尺寸和点云分辨率来试。当你的场景里塞了十几个互相交叠的零件时Hough3DGrouping往往比GC稳定不少。不过我的经验是绝大多数普通场景GeometricConsistencyGrouping够用且好调。如果你发现GC聚类结果非常碎再考虑把Hough搬出来而不是一开始就上复杂方案。4. 假设验证把误检挡在最后一道门槛4.1 为什么分组结果不能直接当最终结果对应分组只是把“几何上自洽”的对应点聚在了一起它并不能保证这些对应拼出来的是一个完整、真实的目标。举个例子一个圆柱体目标它在场景里有好几个相似的圆弧结构这些圆弧的对应很容易几何一致但拼出来的姿态天差地别又比如目标物体表面有一大块平面平面上的对应距离约束很弱聚类时可能拉进来一堆杂物的匹配点。我自己调试时经常遇到一幕GeometricConsistencyGrouping聚出了6个簇画出来一看每个簇的包围盒都挺像模像样但叠到场景里只有2个能真正贴合点云。剩下4个全是“假想实例”。这就是为什么最后必须过HypothesisVerification这道闸。4.2 HypothesisVerification的核心机制与参数经验HypothesisVerification做的工作可以用一句话概括把每个假设里的模型点云变换到场景里看看它是不是真的“贴上去”了同时看它有没有被其他点“埋住”。具体来说它根据每个簇的对应关系估计一个初始变换矩阵把模型点云变换到场景坐标系然后逐点做检查。两个核心指标一个是模型的点有多少能落在场景表面的邻域内内点比例另一个是模型被场景遮挡的比例有多大。前者太低说明模型跟场景对不上后者太高说明这个位置可能被别的物体占了或者模型放进去不成立。算法内部用栅格化和掩码加速统计并且会迭代优化姿态让模型与场景表面的一致性更高。参数方面我常用的初始值如下参数建议初始值说明setResolution体素分辨率的1到2倍栅格化精度setInliersThreshold0.6到0.8内点比例下限setOcclusionThreshold0.3到0.5允许遮挡的比例上限setMaxIterations1000左右内部优化迭代次数代码大概是这样std::vectorpcl::PointCloudpcl::PointXYZ::Ptr models; models.push_back(model_down); pcl::recognition::HypothesisVerificationpcl::PointXYZ, pcl::PointXYZ hv; hv.setModelCloud(model_down); hv.setSceneCloud(scene_down); hv.setResolution(3.0); hv.setInliersThreshold(0.7); hv.setOcclusionThreshold(0.4); hv.setMaxIterations(1000); hv.setModels(models); hv.verify(); std::vectorbool mask; hv.getMask(mask);mask的长度等于聚类簇的数量对应位置是true就代表这个假设通过验证。这个数组是调试时最重要的输出之一我建议把它打印出来跟聚类结果一一对照。4.3 遮挡场景下的验证策略工业场景里目标物体很少是“光光鲜鲜”躺在场景中央的更多时候被压在一堆零件底下只有半个身子露在外面。这时候inliers_threshold如果设得过高算法会把被遮挡的目标全拒掉设得太低又容易放过误检。我的处理办法是分两轮第一轮用一个偏严谨的阈值比如0.75把所有候选过一遍把置信度高的实例先定下来第二轮把被拒绝的候选单独拿出来用更低的阈值比如0.5复查一遍。复查时还要留意一个细节一个被拒的假设它的姿态估计往往因为遮挡已经飘了单纯放宽阈值也不一定能救回来所以真正要做的是重新用经过验证的周围物体把场景“排除”掉再对剩余候选做验证。PCL里可以通过把某个已通过验证的模型的点云从场景中移除比如把对应区域的点删掉来实现这个效果这样被遮挡目标的验证就不会被别的物体干扰。这套“先整体验证、再排除式复查”的办法我实际用过很多次比单靠调参管用得多。5. 一个能跑起来的识别Demo5.1 预处理到特征的完整代码我把前面讲的内容串成一个能跑的完整程序。为了不让代码块吓到人分段放。第一步包含头文件读入模型和场景点云做预处理#include pcl/point_types.h #include pcl/point_cloud.h #include pcl/io/pcd_io.h #include pcl/filters/voxel_grid.h #include pcl/filters/statistical_outlier_removal.h #include pcl/features/normal_estimation_omp.h #include pcl/features/fpfh_omp.h #include pcl/search/kdtree.h #include pcl/registration/correspondence_estimation.h #include pcl/recognition/cg/geometric_consistency.h #include pcl/recognition/hv/hv_go.h #include pcl/registration/transformation_estimation_svd.h #include pcl/visualization/pcl_visualizer.h pcl::PointCloudpcl::PointXYZ::Ptr preprocess_pointcloud(pcl::PointCloudpcl::PointXYZ::Ptr input, float leaf_size) { pcl::PointCloudpcl::PointXYZ::Ptr filtered(new pcl::PointCloudpcl::PointXYZ()); pcl::VoxelGridpcl::PointXYZ voxel_grid; voxel_grid.setLeafSize(leaf_size, leaf_size, leaf_size); voxel_grid.setInputCloud(input); voxel_grid.filter(*filtered); return filtered; } pcl::PointCloudpcl::Normal::Ptr compute_normals(pcl::PointCloudpcl::PointXYZ::Ptr cloud, float radius) { pcl::NormalEstimationOMPpcl::PointXYZ, pcl::Normal ne; ne.setInputCloud(cloud); ne.setRadiusSearch(radius); pcl::PointCloudpcl::Normal::Ptr normals(new pcl::PointCloudpcl::Normal()); ne.compute(*normals); return normals; } pcl::PointCloudpcl::FPFHSignature33::Ptr compute_fpfh(pcl::PointCloudpcl::PointXYZ::Ptr cloud, pcl::PointCloudpcl::Normal::Ptr normals, float radius) { pcl::FPFHEstimationOMPpcl::PointXYZ, pcl::Normal, pcl::FPFHSignature33 fpfh; fpfh.setInputCloud(cloud); fpfh.setInputNormals(normals); fpfh.setRadiusSearch(radius); pcl::PointCloudpcl::FPFHSignature33::Ptr features(new pcl::PointCloudpcl::FPFHSignature33()); fpfh.compute(*features); return features; }这里的一个关键点是模型和场景必须走同一套预处理参数否则后面的特征匹配等于在两个不同的特征空间里做比较结果会非常离谱。第二步建立对应关系pcl::Correspondences find_correspondences(pcl::PointCloudpcl::FPFHSignature33::Ptr model_features, pcl::PointCloudpcl::FPFHSignature33::Ptr scene_features, float distance_threshold) { pcl::KdTreeFLANNpcl::FPFHSignature33 matcher; matcher.setInputCloud(scene_features); pcl::Correspondences correspondences; std::vectorint nearest_index(1); std::vectorfloat nearest_sqr_distance(1); for (std::size_t i 0; i model_features-size(); i) { matcher.nearestKSearch(model_features-at(i), 1, nearest_index, nearest_sqr_distance); if (nearest_sqr_distance[0] distance_threshold) { pcl::Correspondence corr; corr.index_query static_castint(i); corr.index_match nearest_index[0]; corr.distance nearest_sqr_distance[0]; correspondences.push_back(corr); } } return correspondences; }如果你想让对应更干净可以再写一个反向搜索校验双向匹配是否一致这个我之前说过效果很显著。5.2 分组、验证与可视化代码对应关系到位后跑分组和验证就顺理成章了std::vectorpcl::Correspondences clustered_correspondences; pcl::GeometricConsistencyGroupingpcl::PointXYZ, pcl::PointXYZ gc_clusterer; gc_clusterer.setGCThreshold(8.0); gc_clusterer.setEpsilon(10.0); gc_clusterer.setInputCloud(model_down); gc_clusterer.setSceneCloud(scene_down); gc_clusterer.setModelSceneCorrespondences(correspondences); gc_clusterer.cluster(clustered_correspondences); std::vectorpcl::PointCloudpcl::PointXYZ::Ptr models; models.push_back(model_down); pcl::recognition::HypothesisVerificationpcl::PointXYZ, pcl::PointXYZ hv; hv.setModelCloud(model_down); hv.setSceneCloud(scene_down); hv.setResolution(3.0); hv.setInliersThreshold(0.7); hv.setOcclusionThreshold(0.4); hv.setMaxIterations(1000); hv.setModels(models); hv.verify(); std::vectorbool mask; hv.getMask(mask);验证通过后我习惯把每个簇的变换矩阵算出来方便保存和可视化。用TransformationEstimationSVD从簇对应关系估计刚体变换pcl::registration::TransformationEstimationSVDpcl::PointXYZ, pcl::PointXYZ t_est; for (std::size_t i 0; i clustered_correspondences.size(); i) { if (!mask[i]) continue; Eigen::Matrix4f transform Eigen::Matrix4f::Identity(); t_est.estimateRigidTransformation(*model_down, clustered_correspondences[i], *scene_down, transform); pcl::PointCloudpcl::PointXYZ::Ptr model_instance(new pcl::PointCloudpcl::PointXYZ()); pcl::transformPointCloud(*model_down, *model_instance, transform); // 这里可以把 model_instance 保存或用于可视化 }可视化我用PCLVisualizer场景点云显示成灰色把每个通过验证的模型实例用高亮颜色叠上去。这一步看着简单但在调参阶段非常有用因为你一眼就能看出识别出来的姿态是不是“贴”在真实点云上。我说一个经验不要跳过可视化直接看数字矩阵。姿态变换矩阵里的数字再精确也顶不上你在视图里转一圈看到模型与场景完美贴合来得直观。我每次调试都靠可视化快速排除明显有问题的假设。6. 实测中的问题与调参手记6.1 体素尺寸、法线半径、特征半径的“三角关系”算特征的时候三个半径必须放在一起考虑它们之间是强耦合的。我整理了一个常见搭配表方便你起步时参考以点云单位为毫米计算体素尺寸法线搜索半径FPFH搜索半径适配场景1mm2到3mm4到6mm高精度小零件、细节丰富3mm5mm10mm左右常规工业场景最常用5mm8mm15到20mm大目标、大尺寸堆叠场景为什么要这样配原因在特征统计的稳定性。法线半径太小邻域点数不够法线估计受噪声影响非常严重法线半径太大法线被周围不同表面“平均”掉细节丢失。特征半径同理它决定FPFH能“看”多远太小特征没有区分度太大特征会把邻接物体包进来。调参时千万不能只动其中一个三个数要一起调。6.2 法线朝向与特征质量的隐性关联NormalEstimation默认用局部PCA算出来法线的正负方向是不确定的。这个问题我以前吃过大亏同一个模型从CAD导出的点云和从三维扫描仪得到的点云法线朝向上经常一个朝外、一个朝内或者在平面两侧随机翻转。FPFH对法线方向很敏感法线方向不一致同样的几何结构算出来的直方图可能完全不同对应关系数量少得可怜。解决办法是统一法线朝向。常用的一招是估计法线时指定视点方向让所有法线偏向视点一侧。对于场景点云视点通常就是传感器位置对于模型点云CAD坐标系的视点需要自己指定一个合理方向。如果模型和场景来源不同务必用同样的方式处理。我后来写代码时干脆封装了一个“法线重定向”的函数遍历所有法线如果法线与视点方向的点积小于0就将法线翻转。这样保证后续特征计算的一致性。6.3 场景质量太差时的兜底方案如果场景点云本身就很烂比如噪声大、密度忽高忽低、目标被遮挡严重我通常会做三件事作为兜底。第一预处理阶段先加一个统计离群点去除StatisticalOutlierRemoval把那种孤零零的飞点干掉。这类点对法线估计的影响很大一个飞点就能把一个局部邻域的法线拉偏。第二如果场景里有明显的支撑平面桌面、传送带、地面用平面分割把支撑面先剔除掉。不剔除的话平面上会积累大量误匹配对应分组聚类时很容易把平面点也卷进簇里导致假设姿态漂移。第三如果识别出来的姿态精度不够把PCL识别流程当作“粗定位”之后再用ICP做一步精配准。粗识别负责把目标从杂乱场景里找出来ICP负责把姿态精修到亚体素级别。这样分工既利用了识别对杂乱场景的鲁棒性又用上了配准的高精度是我在工程里最常用的组合。另外还有一点目标物体如果是旋转对称的比如圆柱、球体识别出的姿态在对称方向上天然存在歧义可能这次姿态是0度下次就成了90度。这种问题不是参数能解决的需要在后续逻辑里加约束或者忽略对称方向上的差异。最后分享一个我自己用下来的体会Recognition跑通只是开始真正可靠的结果是靠参数和数据的反复磨合。把管线里每一步的输出都可视化出来尤其是对应关系和分组结果很多问题一眼就能看出病根。PCL这套Recognition代码不算新但它把局部特征、几何聚类、假设验证这条经典识别流程封装得很完整理解透之后对以后换上更复杂的识别方案也有帮助毕竟几何先验在任何方案里都是能帮上忙的东西。
