做点云处理的人迟早会遇到一个尴尬局面：模型库里的三维点云有鼻子有眼，可面对桌面上一堆散乱摆放的真实物体，程序死活认不出哪个是目标。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::KdTreeFLANN<pcl::FPFHSignature33> matcher; matcher.setInputCloud(scene_features); pcl::Correspondences correspondences; std::vector<int> nearest_index(1); std::vector<float> 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_cast<int>(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::GeometricConsistencyGrouping<pcl::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::vector<pcl::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倍 | 栅格化精度 |
| setInliersThreshold | 0.6到0.8 | 内点比例下限 |
| setOcclusionThreshold | 0.3到0.5 | 允许遮挡的比例上限 |
| setMaxIterations | 1000左右 | 内部优化迭代次数 |
代码大概是这样：
std::vector<pcl::PointCloud<pcl::PointXYZ>::Ptr> models; models.push_back(model_down); pcl::recognition::HypothesisVerification<pcl::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::vector<bool> mask; hv.getMask(mask);mask的长度等于聚类簇的数量，对应位置是true就代表这个假设通过验证。这个数组是调试时最重要的输出之一，我建议把它打印出来，跟聚类结果一一对照。
4.3 遮挡场景下的验证策略
工业场景里，目标物体很少是“光光鲜鲜”躺在场景中央的，更多时候被压在一堆零件底下，只有半个身子露在外面。这时候inliers_threshold如果设得过高，算法会把被遮挡的目标全拒掉；设得太低，又容易放过误检。
我的处理办法是分两轮：第一轮，用一个偏严谨的阈值（比如0.75）把所有候选过一遍，把置信度高的实例先定下来；第二轮，把被拒绝的候选单独拿出来，用更低的阈值（比如0.5）复查一遍。复查时还要留意一个细节：一个被拒的假设，它的姿态估计往往因为遮挡已经飘了，单纯放宽阈值也不一定能救回来，所以真正要做的是重新用经过验证的周围物体把场景“排除”掉，再对剩余候选做验证。PCL里，可以通过把某个已通过验证的模型的点云从场景中移除（比如把对应区域的点删掉）来实现这个效果，这样被遮挡目标的验证就不会被别的物体干扰。
这套“先整体验证、再排除式复查”的办法，我实际用过很多次，比单靠调参管用得多。
5. 一个能跑起来的识别Demo
5.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::PointCloud<pcl::PointXYZ>::Ptr preprocess_pointcloud(pcl::PointCloud<pcl::PointXYZ>::Ptr input, float leaf_size) { pcl::PointCloud<pcl::PointXYZ>::Ptr filtered(new pcl::PointCloud<pcl::PointXYZ>()); pcl::VoxelGrid<pcl::PointXYZ> voxel_grid; voxel_grid.setLeafSize(leaf_size, leaf_size, leaf_size); voxel_grid.setInputCloud(input); voxel_grid.filter(*filtered); return filtered; } pcl::PointCloud<pcl::Normal>::Ptr compute_normals(pcl::PointCloud<pcl::PointXYZ>::Ptr cloud, float radius) { pcl::NormalEstimationOMP<pcl::PointXYZ, pcl::Normal> ne; ne.setInputCloud(cloud); ne.setRadiusSearch(radius); pcl::PointCloud<pcl::Normal>::Ptr normals(new pcl::PointCloud<pcl::Normal>()); ne.compute(*normals); return normals; } pcl::PointCloud<pcl::FPFHSignature33>::Ptr compute_fpfh(pcl::PointCloud<pcl::PointXYZ>::Ptr cloud, pcl::PointCloud<pcl::Normal>::Ptr normals, float radius) { pcl::FPFHEstimationOMP<pcl::PointXYZ, pcl::Normal, pcl::FPFHSignature33> fpfh; fpfh.setInputCloud(cloud); fpfh.setInputNormals(normals); fpfh.setRadiusSearch(radius); pcl::PointCloud<pcl::FPFHSignature33>::Ptr features(new pcl::PointCloud<pcl::FPFHSignature33>()); fpfh.compute(*features); return features; }这里的一个关键点是：模型和场景必须走同一套预处理参数，否则后面的特征匹配等于在两个不同的特征空间里做比较，结果会非常离谱。
第二步，建立对应关系：
pcl::Correspondences find_correspondences(pcl::PointCloud<pcl::FPFHSignature33>::Ptr model_features, pcl::PointCloud<pcl::FPFHSignature33>::Ptr scene_features, float distance_threshold) { pcl::KdTreeFLANN<pcl::FPFHSignature33> matcher; matcher.setInputCloud(scene_features); pcl::Correspondences correspondences; std::vector<int> nearest_index(1); std::vector<float> 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_cast<int>(i); corr.index_match = nearest_index[0]; corr.distance = nearest_sqr_distance[0]; correspondences.push_back(corr); } } return correspondences; }如果你想让对应更干净，可以再写一个反向搜索，校验双向匹配是否一致，这个我之前说过，效果很显著。
5.2 分组、验证与可视化代码
对应关系到位后，跑分组和验证就顺理成章了：
std::vector<pcl::Correspondences> clustered_correspondences; pcl::GeometricConsistencyGrouping<pcl::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::vector<pcl::PointCloud<pcl::PointXYZ>::Ptr> models; models.push_back(model_down); pcl::recognition::HypothesisVerification<pcl::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::vector<bool> mask; hv.getMask(mask);验证通过后，我习惯把每个簇的变换矩阵算出来，方便保存和可视化。用TransformationEstimationSVD从簇对应关系估计刚体变换：
pcl::registration::TransformationEstimationSVD<pcl::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::PointCloud<pcl::PointXYZ>::Ptr model_instance(new pcl::PointCloud<pcl::PointXYZ>()); pcl::transformPointCloud(*model_down, *model_instance, transform); // 这里可以把 model_instance 保存或用于可视化 }可视化我用PCLVisualizer，场景点云显示成灰色，把每个通过验证的模型实例用高亮颜色叠上去。这一步看着简单，但在调参阶段非常有用，因为你一眼就能看出识别出来的姿态是不是“贴”在真实点云上。
我说一个经验：不要跳过可视化直接看数字矩阵。姿态变换矩阵里的数字再精确，也顶不上你在视图里转一圈看到模型与场景完美贴合来得直观。我每次调试都靠可视化快速排除明显有问题的假设。
6. 实测中的问题与调参手记
6.1 体素尺寸、法线半径、特征半径的“三角关系”
算特征的时候，三个半径必须放在一起考虑，它们之间是强耦合的。我整理了一个常见搭配表，方便你起步时参考（以点云单位为毫米计算）：
| 体素尺寸 | 法线搜索半径 | FPFH搜索半径 | 适配场景 |
|---|---|---|---|
| 1mm | 2到3mm | 4到6mm | 高精度小零件、细节丰富 |
| 3mm | 5mm | 10mm左右 | 常规工业场景（最常用） |
| 5mm | 8mm | 15到20mm | 大目标、大尺寸堆叠场景 |
为什么要这样配？原因在特征统计的稳定性。法线半径太小，邻域点数不够，法线估计受噪声影响非常严重；法线半径太大，法线被周围不同表面“平均”掉，细节丢失。特征半径同理，它决定FPFH能“看”多远，太小特征没有区分度，太大特征会把邻接物体包进来。调参时千万不能只动其中一个，三个数要一起调。
6.2 法线朝向与特征质量的隐性关联
NormalEstimation默认用局部PCA，算出来法线的正负方向是不确定的。这个问题我以前吃过大亏：同一个模型，从CAD导出的点云和从三维扫描仪得到的点云，法线朝向上经常一个朝外、一个朝内，或者在平面两侧随机翻转。FPFH对法线方向很敏感，法线方向不一致，同样的几何结构算出来的直方图可能完全不同，对应关系数量少得可怜。
解决办法是统一法线朝向。常用的一招是估计法线时指定视点方向，让所有法线偏向视点一侧。对于场景点云，视点通常就是传感器位置；对于模型点云，CAD坐标系的视点需要自己指定一个合理方向。如果模型和场景来源不同，务必用同样的方式处理。我后来写代码时，干脆封装了一个“法线重定向”的函数：遍历所有法线，如果法线与视点方向的点积小于0，就将法线翻转。这样保证后续特征计算的一致性。
6.3 场景质量太差时的兜底方案
如果场景点云本身就很烂，比如噪声大、密度忽高忽低、目标被遮挡严重，我通常会做三件事作为兜底。
第一，预处理阶段先加一个统计离群点去除（StatisticalOutlierRemoval），把那种孤零零的飞点干掉。这类点对法线估计的影响很大，一个飞点就能把一个局部邻域的法线拉偏。
第二，如果场景里有明显的支撑平面（桌面、传送带、地面），用平面分割把支撑面先剔除掉。不剔除的话，平面上会积累大量误匹配，对应分组聚类时很容易把平面点也卷进簇里，导致假设姿态漂移。
第三，如果识别出来的姿态精度不够，把PCL识别流程当作“粗定位”，之后再用ICP做一步精配准。粗识别负责把目标从杂乱场景里找出来，ICP负责把姿态精修到亚体素级别。这样分工，既利用了识别对杂乱场景的鲁棒性，又用上了配准的高精度，是我在工程里最常用的组合。
另外还有一点：目标物体如果是旋转对称的（比如圆柱、球体），识别出的姿态在对称方向上天然存在歧义，可能这次姿态是0度，下次就成了90度。这种问题不是参数能解决的，需要在后续逻辑里加约束或者忽略对称方向上的差异。
最后分享一个我自己用下来的体会：Recognition跑通只是开始，真正可靠的结果是靠参数和数据的反复磨合。把管线里每一步的输出都可视化出来，尤其是对应关系和分组结果，很多问题一眼就能看出病根。PCL这套Recognition代码不算新，但它把局部特征、几何聚类、假设验证这条经典识别流程封装得很完整，理解透之后，对以后换上更复杂的识别方案也有帮助，毕竟几何先验在任何方案里都是能帮上忙的东西。
