应使用成熟库解析：pcap用libpcap+自定义解包（需对照手册），bag用rosbag C++ API（需ROS环境），或直接采用ouster_ros/livox_ros_driver等封装SDK，避免手写易错解析器。
怎么读取 .pcap 或 .bag 激光雷达原始数据
大多数激光雷达（如 Velodyne、Ouster、Livox）出厂输出的是二进制封装格式，.pcap（网络抓包）和 .bag（ROS 封装）最常见。C++ 本身不原生支持解析这些格式，得靠专用库。
关键判断：别自己写解析器——协议细节多、字节序易错、版本迭代快。直接用成熟方案：
-
libpcap+ 自定义解包逻辑（仅推荐 Velodyne VLP-16/32 等老型号，需对照官方user manual中 packet layout 手动提取x/y/z/intensity） -
rosbagC++ API（适用于.bag，但必须在 ROS 环境下编译，依赖roscpp和对应 sensor_msgs） -
ouster_ros或livox_ros_driver提供的 SDK（推荐，已封装点云构建、时间同步、坐标系转换）
注意：.bag 文件若含压缩数据（如 lz4），需确保编译时链接了对应解压库，否则 rosbag::View 会静默跳过消息。
pcl::PointCloud<t></t> 怎么从原始扫描帧构建
原始数据通常是按扫描线（scan line）或扇区（sector）组织的极坐标数据（azimuth, distance, vertical_angle），不是现成的 XYZ。必须做坐标变换。
立即学习“C++免费学习笔记（深入）”；
典型流程：
- 先校准内参：获取每束激光的固定
vertical_offset和horizontal_offset（查传感器 datasheet，例如 Ouster OS1-64 的beam_altitude_angles是一个 64×1 数组） - 对每个有效距离值
range，用三角函数转为笛卡尔坐标：x = range * cos(vert) * sin(horz)等（注意单位：角度是弧度还是度） - 用
pcl::PointCloud<:pointxyzi>::Ptr cloud(new pcl::PointCloud<:pointxyzi>)</:pointxyzi></:pointxyzi>分配内存，逐点 push_back
坑点：range == 0 或 range > max_range 必须滤掉，否则生成 NaN 点，后续 pcl::StatisticalOutlierRemoval 会崩溃。
为什么 voxel_grid 下采样后点数不减反增
这不是 bug，是 PCL 默认行为：当 voxel 内无点时，setLeafSize() 不影响输出；但若启用 setMinimumPointsNumberPerVoxel(true)，且某 voxel 恰好只有 1 个点，它仍会被保留——看起来“没降采样”。
真正控制密度的参数是：
-
setLeafSize(x, y, z)：决定 voxel 边长，建议设为传感器精度的 2–3 倍（如 VLP-16 水平精度约 2 cm，可用0.05f） -
setDownsampleAllData(true)：确保intensity、ring等字段也参与重心计算 - 务必调用
filter(true)而非filter(false)，后者只返回索引不生成新点云
验证是否生效：打印前后 cloud->size()，别只看可视化——PCL Visualizer 对密集点云会自动裁剪显示。
实时处理时 CPU 占用飙高，怎么定位瓶颈
激光雷达频率常为 10 Hz（VLP-16）或 20 Hz（OS1），单帧点数可达 10 万以上。高频调用 pcl::SACMODEL_LINE 或 pcl::NormalEstimation 很容易吃满单核。
快速排查方法：
- 用
perf record -g ./your_node抓火焰图，重点看pcl::search::KdTree::nearestKSearch或矩阵运算耗时 - 禁用所有滤波器，只做坐标转换 +
cloud->size()输出，测出 baseline 耗时 - 把
NormalEstimation的KSearch改为RadiusSearch（半径搜索通常比 K 近邻快 30%+）
一个常被忽略的点：pcl::PointCloud 的 resize() 会触发内存重分配。循环中应预先 cloud->reserve(expected_size)，否则每帧都 malloc/free。
