企业官网建设流程全解析

做机器人和机器视觉这几年，深度相机换过不少，结构光、双目、激光雷达都摸过一圈，最后ToF（Time of Flight，飞行时间法）相机是我在室内中近距离场景里用得最顺手的方案。前几天还有朋友问我，为什么一开ToF相机，画面里穿黑衣服的人就成了一个洞？这个问题如果只停留在"黑色物体吸光，所以测不到"的层面，说明你对ToF的认知还是黑盒状态。真正搞懂ToF相机，需要把整条链路从底层硬件到上层应用全部打通。

这篇东西我打算彻底摊开来讲：从一颗VCSEL激光器怎么发光，到sensor怎么算出每个像素的距离，再到驱动层怎么把I2C寄存器配置和MIPI数据流收上来，最后是标定、点云生成、SDK封装、实际项目里的坑。适合正在选型深度相机的工程师、做机器人感知和自动化集成的同学，以及想搞懂相机底层原理但是被各路科普绕晕的入门者。我会尽量说人话，但这不意味着绕过核心原理——只有把"为什么"吃透，遇到问题才不至于只会重启相机。

1. ToF相机到底解决了什么问题

1.1 一个典型的落地场景引路

自动化产线上最常见的需求之一：机械臂要从料筐里抓取散乱堆叠的工件。双目视觉在这种场景下经常翻车——工件表面纹理太少、反光厉害，立体匹配根本找不到对应点；结构光方案在近距离精度确实高，但容易被环境光和多次反射干扰，而且有些结构光投射器在室外直接废掉。

ToF相机的好处是单帧就能输出完整深度图，不依赖纹理，响应快。它不像双目那样需要左右图做匹配，也不像结构光那样需要投影编码图案再解算，而是直接测光飞行的时间差，天然就能给出每个像素的距离。在AGV避障、安全防护区域检测、人流统计、体感交互、体积测量这些中近距离场景里，ToF几乎是性价比最高的选择。

1.2 两个流派：iToF和dToF

ToF自己还分两派，很多刚接触的人容易混淆。

iToF（间接飞行时间）：发射端不是打个脉冲就完事，而是用高频正弦波或方波对激光进行强度调制，接收端在像素内部做相关采样，通过测量反射光和发射光之间的相位差来反推距离。因为测的是相位差而不是直接测时间，所以叫"间接"。代表产品有英飞凌+pmd方案的模组、索尼DepthSense系列、瑞萨等。iToF的测距范围通常在0.1米到10米，精度能做到厘米级甚至毫米级（近距离），是消费级和工业中短距离场景的主流。

dToF（直接飞行时间）：这个更简单粗暴，发射一个极短的光脉冲，直接测量光子从发射到返回所用的时间，距离等于光速乘时间除以2。核心器件是SPAD（单光子雪崩二极管）阵列，代表产品有苹果LiDAR、索尼的dToF传感器等。dToF的优势是远距离性能好、抗环境光能力强，但SPAD阵列分辨率做不高，成本也更高。

两个流派在硬件链路、校准策略、后处理算法上有很大差异，后面讲的很多内容会区分来看。

1.3 这篇文章适合哪些人

如果你是底层驱动工程师，可以重点关注第2章和第4章的寄存器配置、数据流收包逻辑；如果你是算法工程师，第3章的标定原理和点云生成、第5章的深度后处理应该对你有直接帮助；如果你是做系统集成或者选型评估的，第1章和第6章的对比表、性能验证方法会更实用。

前置知识要求不高：懂点光学的基本概念（波长、焦距、视场角），写过几行C/C++或者Python，能理解坐标系变换就行。遇到概念我会先给一个生活化的类比，再落到数学表达式上。

2. 把光子变成数字：ToF底层硬件链路拆解

2.1 发射端：VCSEL激光器和光学扩散

ToF相机的光源几乎都是VCSEL（垂直腔面发射激光器），原因很简单：它可以在同一片晶圆上做成百上千个发光孔阵列，功率密度高、发散角小、波长稳定（通常是850nm或940nm）、调制速率能做到几百MHz甚至GHz级别，而且封装后体积非常紧凑，适合做进手机和相机模组里。

一颗ToF模组的发射端，本质结构是：驱动电路 + VCSEL阵列 + DOE光学扩散片。驱动电路负责把调制信号（比如80MHz的正弦波或方波）叠加到激光器的供电上，让激光按照这个频率亮灭变化。DOE的作用是把VCSEL发出的点状光束扩散成覆盖整个视场角的均匀光斑。

这里有一个很关键的选型点：波长选850还是940。850nm的量子效率高，相同功率下信号更强，但940nm的环境光背景更小，因为阳光中940nm波段能量衰减厉害。室内场景用850nm的多，室外或者强环境光场景优先考虑940nm。

从安全角度说，产品设计上发射功率要控制在人眼安全的激光等级，这类消费级和工业级ToF模组通常工作在内置安全等级，做过处理后对人眼基本无害，但调试时千万不要直视发射窗口，尤其不要拿放大镜去看。

2.2 接收端：sensor像素结构和采样机制

接收端是ToF相机整个链路里最核心也最复杂的部分。

iToF的像素不是普通CIS（CMOS图像传感器）像素那样只记录光强，而是在每个像素内部集成了多个抽头（tap）和电荷存储单元。以最常见的2-tap或4-tap像素为例：在激光器发光的同一个时钟周期内，像素在相位0度、90度、180度、270度四个时刻分别打开电荷门，把反射光产生的光生电荷分配到不同的存储节点上。

这就像四个人站在四个不同的时间窗口前，各自只接住自己时间段内到达的光子。因为发射光是已知的正弦调制信号，反射光的调制波形和发射光基本一致，只是有一个相位延迟。通过比较四个窗口接到的光强比例，就能算出相位差：

Δφ = arctan((Q90 - Q270) / (Q0 - Q180))

距离 d = c * Δφ / (4π * f)

其中f是调制频率，c是光速。

这个公式是iToF的命根子。调制频率越高，距离分辨率越高，但最大不模糊距离越短（因为相位差会以2π为周期混叠），所以高精度和远距离天生矛盾。解决方法是多频调制：用两个或多个不同频率分别测量，再用中国剩余定理做解缠，把模糊距离扩展出去。市面上很多ToF模组内部同时跑20MHz和80MHz两个频率，就是为了兼顾近处精度和远处量程。

dToF的SPAD像素就完全不同了。SPAD工作在高出雪崩电压的状态，一个光子打进来就能触发一次雪崩，产生一个数字脉冲，配合时间数字转换器（TDC）记录这个脉冲到达的时刻。SPAD阵列的每个像素内部集成了TDC和直方图处理逻辑，通过统计大量光子的到达时间分布来提取准确的距离。SPAD像素尺寸大，所以分辨率上不去，目前主流的dToF sensor也就30万像素以下。

2.3 片上处理和数据输出

sensor拿到四相位原始数据后，并不是直接把原始信号扔出来，大多数ToF sensor在芯片内部已经有深度计算引擎。比如索尼的DepthSense系列，内部直接输出经过相位解算的深度图和置信度图，对外只通过MIPI CSI-2接口输出metadata流。

如果你用FPGA或者MCU接sensor裸片，那驱动开发的活就重了：要配置PLL锁相环让调制时钟和像素采样时钟对齐，要配置曝光时间和帧率，要处理MIPI接收、CSI-2协议的帧同步信号，还要自己做相位解算、坏点校正、温度补偿。

这里最容易出问题的就是调制时钟的相位对准。发射端的激光驱动信号、接收端的像素采样信号必须来源于同一个时钟树，否则发射和接收之间的相位基准漂移，测出来的距离就会跟着漂。这也是为什么很多模组把驱动芯片和sensor封装在一起，出厂前已经做好了同步校验，整机厂省了很多事。

从整个链路来看，ToF相机的一次测量流程可以概括为：

• 驱动电路给VCSEL加上高频调制信号
• 激光经DOE扩散后照亮场景
• 反射光经镜头和带通滤光片到达sensor
• 像素在四个相位窗口分别积分，读出四组电荷量
• 片上DSP算出相位差、距离、幅值、置信度
• 深度图和红外图经MIPI/USB输出给主机

3. 中间层的硬仗：标定和深度质量校正

3.1 内参标定和畸变校正，ToF和RGB有什么不同

任何相机要变成可用的测量工具，第一步永远是标定。说到这里，我见过太多人拿到ToF相机，直接读深度图就跑算法，结果项目死得莫名其妙——因为深度图本身带畸变，而且ToF sensor的标定和普通RGB相机是两码事。

ToF相机标内参，方法和普通相机类似，核心是张正友标定法：对着棋盘格或圆点阵拍十几张不同角度的图像，提取角点，用PnP算法求内参矩阵K和畸变系数。区别在于，ToF相机标定时用的通常是它的红外强度图（IR图），而不是RGB图。IR图是ToF sensor自己输出的反射光强图，和深度图是同一个坐标系、同一组像素，直接用IR图提取角点即可。

一个小建议：标定板别用普通纸打印的棋盘格，尽量用漫反射材料的陶瓷圆点阵。原因是ToF相机发射红外光，普通打印纸在850nm波段可能反光不一致，棋盘格角点检测在IR图下容易抖动；圆点阵则可以通过椭圆拟合并考虑到畸变，鲁棒性高很多。每次采集标定板图像时，要保证整个靶面都在画面内，姿态不要太平（多转几个角度），这个和RGB相机标定的要求是一样的。

我踩过的一个坑是：标定板离相机太近，深度图边缘的飞行像素把圆点边缘污染了，角点提取出来是歪的。解决办法是让标定板保持在最佳测距范围内（比如0.4~1.2米），然后对IR图做一个轻度高斯滤波再送进角点检测。

3.2 深度图到点云：一个公式和一串代码

标定得到内参后，深度图转点云就是一个纯数学操作了。核心公式：

• x = (u - cx) * d / fx
• y = (v - cy) * d / fy
• z = d

其中(u, v)是像素坐标，d是深度值，fx、fy、cx、cy来自内参矩阵K。就这么简单，每个像素独立计算，天然适合并行处理。

写一个最小实现：

void depth2pointcloud( const float* depth, int w, int h, float fx, float fy, float cx, float cy, float* xyz, float* ir) { for (int v = 0; v < h; v++) { for (int u = 0; u < w; u++) { int idx = v * w + u; float d = depth[idx]; // 深度值为0通常表示无效像素 if (d <= 0.0f) { xyz[3 * idx + 2] = 0.0f; // 标记无效 continue; } float x = (u - cx) * d / fx; float y = (v - cy) * d / fy; xyz[3 * idx + 0] = x; xyz[3 * idx + 1] = y; xyz[3 * idx + 2] = d; } } }

注意，很多ToF SDK输出深度图时，数据是带缩放的。比如某些SDK深度值单位是0.001毫米，有些是0.001米，还有一些直接把float深度图给你，这个务必先确认清楚，否则点云会被整体放大或缩小一千倍。这种错误低级但发生频率极高，我在社区里无数次看到有人问"为什么点云坐标大得离谱"，八成是scale没除。

3.3 深度图和RGB对齐：外参标定是关键一步

如果项目里同时用了ToF相机和RGB相机，那就需要做深度-彩色对齐。原理也不复杂：通过联合标定求出两个相机之间的外参（旋转矩阵R和平移向量t），然后把RGB相机的内参代入重投影公式，把深度图变换到RGB图像坐标系下。

操作上，我会用通用的相机联合标定工具来做，操作流程通常是：先把两个相机固定在一个刚性支架上，保证相对位置不动，然后对着标定板多次采集图像对（ToF取IR图，RGB取彩色图），提取角点后，工具会同时优化两个相机的内参以及它们之间的外参。

这里有个关键经验：采集标定数据时，两个相机的帧率如果不一致（比如ToF是30fps，RGB是60fps），最好给两个相机做硬件帧同步，或者在离线采集时用软件时间戳对齐，否则标定结果会发生微小的抖动。稳定的三脚架、充足的室内光照、静止的环境，缺一不可。每次采集完，我都习惯先看一眼重投影误差，如果大于0.5像素，就重新采一组，不要硬往下走。

另一个常见场景是相机和IMU的联合标定。要让深度相机输出的点云和IMU的姿态在时间上对齐，需要估计两者的相对外参和时延。这类标定同样有开源工具可用，但操作门槛稍高，要采集充分的旋转激励，让IMU的加速度和角速度有足够的变化范围。我自己跑下来的经验是，标定过程至少持续2分钟以上，涵盖六个自由度的多方向旋转，不要只转一个轴。

3.4 手眼标定和九点标定，什么时候用哪个

很多做机器人抓取和定位的朋友还会遇到手眼标定。手眼标定要解决的是相机坐标系和机械臂基坐标系（或工具坐标系）的关系。

• 眼在手上（Eye-in-Hand）：相机装在机械臂末端，标定的是相机相对工具末端的位置关系
• 眼在手外（Eye-to-Hand）：相机固定在外部支架上，标定的是相机相对机械臂基座的位置关系

算法上通常用AX=XB矩阵方程求解，开源库和商业库都有现成实现。

如果你的应用是平面定位——比如只要求相机坐标系下的（x, y）能对应到机械臂底下的一个平面坐标，不关心深度，那直接用九点标定就够了。就是让机械臂末端分别对准九个小孔或者圆锥位置，记录机械臂坐标和像素坐标，然后拟合一个2D仿射变换矩阵。这个方法简单实用，尤其适合视觉引导贴装、打螺丝这类场景。但注意九点标定只适用于平面场景，别指望用它解决三维姿态估计问题。

4. 上层应用：SDK封装和算法栈该怎么搭

4.1 SDK接口设计：别把底层细节漏给上层

如果你做的是完整产品而不是只用现成模组，SDK封装这一步决定项目后续迭代的复杂度。我见过很多团队把sensor寄存器配置、MIPI恢复、深度算法全堆在应用代码里，最后变成一团乱麻。好的做法是分层清晰，对外暴露的接口尽量抽象。

我一般推荐的SDK结构：

• 设备层：枚举、打开、关闭、设置参数（曝光、增益、帧率、调制频率）
• 数据层：push/pull模式，回调携带深度图、IR图、置信度图、点云
• 算法层：内参校正、滤波、时间平均、点云变换、区域ROI统计
• 应用层：对接具体的业务逻辑

接口设计上，最关键的是数据所有权的转移。如果SDK回调里每帧都拷贝一份完整深度图，CPU占用率会很难看。建议用对象池或者零拷贝引用计数方案，回调把帧对象的指针交给用户，用户使用完释放引用，SDK复用底层的buffer。

很多从USB深度相机入门的朋友，第一次接触工业级的CSI接口模组时会不适应，因为CSI没有现成的UVC协议，需要自己处理丢包、帧同步、带宽分配。这一阶段最容易踩的坑是缓冲队列溢出，表现为画面一卡一卡、深度图出现带状噪声。我的排查习惯是先看dmesg有没有MIPI报错，再检查应用层是否及时取帧，最后才怀疑硬件信号完整性。

4.2 深度预处理：置信度、滤波和飞行像素

SDK拿到的深度图往往不能直接用，要做几道预处理。

第一步是看置信度图。ToF sensor在算距离的同时会估计每个像素的置信度（幅值或者噪声水平），这个信息是后处理的钥匙。幅值太低的像素，深度基本不可信，直接用置信度阈值把它置为无效，能滤掉很多环境光干扰和远距离噪点。

第二步是空间滤波。最常用的是双边滤波：既考虑空间距离权重，也考虑深度差权重——深度突变大的边缘处不会被过渡平滑掉，这样既能降噪，又能保留物体边缘。具体参数（空间sigma、深度sigma）要根据场景调，一般深度sigma取20~50mm，空间sigma取1~2像素。

第三步是时间滤波。静态场景直接用滑动窗口平均或者指数移动平均，能显著降低随机噪声。动态场景则要小心运动拖影，建议只在低运动区域做时间滤波，或者升级成基于运动补偿的滤波算法。

还要提一下飞行像素（flying pixel）。物体边缘处，一个像素的光斑可能同时覆盖了前景和背景，测出来的深度介于两者之间，形成边缘毛刺。处理办法是在边缘区域检测深度梯度突变的地方，把过渡带上的像素置为无效，或在点云层面做离群点删除（比如PCL的StatisticalOutlierRemoval）。如果你做的是机械臂抓取、尺寸测量这类精度敏感的应用，宁可少点，不可错点——错误深度的点会直接毁掉后续位姿估计。

4.3 一个可运行的C++取流示例

结合前面讲的点云生成，给一个最小可用的取流流程示意（伪SDK风格）：

#include <tof_sdk.h> #include <pcl/point_cloud.h> #include <pcl/point_types.h> int main() { // 1. 枚举设备并打开 auto devices = TofSDK::enumerateDevices(); TofSDK::Device device = TofSDK::openDevice(devices[0].id); device.setDepthScale(0.001f); // 统一到米 device.setExposureTime(800); // 微秒 device.setFrameRate(30); // 2. 注册帧回调或主动拉取 device.startStream([](const TofSDK::Frame& frame) { pcl::PointCloud<pcl::PointXYZ>::Ptr cloud(new pcl::PointCloud<pcl::PointXYZ>); cloud->reserve(frame.width * frame.height); for (int v = 0; v < frame.height; v++) { for (int u = 0; u < frame.width; u++) { int idx = v * frame.width + u; float d = frame.depth[idx]; float confidence = frame.confidence[idx]; if (confidence < 80.0f || d <= 0.0f) continue; float x = (u - frame.cx) * d / frame.fx; float y = (v - frame.cy) * d / frame.fy; cloud->emplace_back(x, y, d); } } // 交给下游做配准、抓取规划、安全监控等 processCloud(cloud); }); std::this_thread::sleep_for(std::chrono::seconds(100)); device.stopStream(); return 0; }

这样一个最小实现，已经把设备配置、置信度过滤、内参投影、点云输出全串起来了，稍微扩展就能接PCL的ICP配准、区域分割、包围盒估计。

5. 实测中的坑：精度漂移、多机干扰和丢帧排查

5.1 温度漂移：一个让所有工程师头疼的慢性病

ToF相机的精度对温度非常敏感。VCSEL的发光功率会随温度变化，接收sensor的暗电流也会漂移，相位解调电路更是受温度影响——结果就是开机时的深度数据和跑了半小时后的数据能差出几厘米甚至更多。

解决方法分两个层面。硬件上，尽可能选择带温度补偿算法的模组，现在主流sensor内部都有温度传感器，SDK会做实时修正。软件上，如果算法允许，可以在系统启动后预热几分钟再用，尤其在户外或者发热严重的设备里。长期稳定性测试是ToF项目选型的必做项：开机记录一组墙面深度数据，每5分钟记录一次，跑1小时，看深度均值漂移曲线。如果漂移超过项目精度预算的一半，这个模组就要慎重考虑。

5.2 黑衣服、阳光和镜子：环境的物理边界

回到文章开头的问题，黑衣服为什么在ToF画面里变成黑洞？因为ToF测距依赖反射光的强度，黑色物体对850nm光的反射率可能只有几个百分点，接收端信号太弱，置信度阈值直接让这个像素失效了。

类似的环境问题还有：

• 强阳光直射：阳光里的红外分量会淹没主动光源的信号，940nm模组会好很多，但也不要指望在正午户外获得稳定高精度
• 镜面反射：反射的光走了一个假的光路，深度值变成镜像距离，而且往往是剧烈的跳变，比较难完全修复，只能靠置信度过滤和空间滤波把它尽量消除
• 高反射率的白色物体：近处纯白物体反射太强，sensor可能饱和，导致深度值被拉近或拉远，解决办法是调节曝光，或者用带HDR策略的sensor

如果项目会遇到这些场景，选型阶段就要做材质专项测试：把项目里所有要测的物体都搬出来，放在不同距离测一遍，画出反射率-距离-深度误差的关系表。

5.3 多机干扰和帧同步

多台ToF相机同时工作时会互相干扰——A相机的激光被B相机的sensor收进来，产生深度噪声、带状条纹甚至整个画面花掉。这一点在很多场景里是硬伤，比如一台AGV装了4个避障相机，或者产线上2台相机相邻部署。

解决思路有三种：

• 时分复用：把相机分配在不同时间片，错峰曝光。缺点是帧率会除以相机数量
• 频分复用：用不同调制频率区分，比如A相机用80MHz，B相机用100MHz，加解调滤波，但可选频率有限
• 编码调制：用伪随机码或者特殊的相位编码区分不同发射源，这个成本最高但效果最好

如果你做系统集成，选型时一定要问清楚某一台相机是否支持帧同步输入/输出。硬件上把主相机的帧同步信号接到从相机的触发输入，再从驱动层面配置为主从模式，这样才能在硬件触发层面保证多机交替曝光。不少国产工业ToF相机都开始支持外触发模式，这对多机应用来说是刚需。

5.4 丢帧和未收到触发信号，怎么往下查

工业现场还常遇到"相机为什么不给数据"的怪问题。排查思路要像剥洋葱一样一层层来：

1. 先看供电：ToF激光器瞬间功耗大，电压跌落会造成莫名其妙的丢帧、花屏。用示波器看相机供电纹波是否超标
2. 再看连接：USB3.0线缆过长或者劣质线会导致带宽不稳，表现为传输速率忽高忽低；GigE相机则是网卡缓冲区溢出，调优网卡接收描述符和中断亲和性往往能解决
3. 然后看触发信号：如果配了外触发，确认触发源的真值时序和相机的触发电压阈值是否匹配。这一步用示波器量触发线最直接
4. 最后翻日志：sensor内部错误寄存器、驱动log、SDK错误码，都能定位到是传输层、sensor层还是host层的问题

有一次项目里相机频繁丢帧，查了半天发现是USB线从桌面走过，旁边的机械臂一动作，电磁干扰就上来了，换一根带屏蔽层并且两端有磁环的线缆，问题立刻消失。这类问题没有捷径，只能按链路逐段排查。

6. 从选型到落地：一套能直接抄的评估流程

6.1 先把需求拆成硬指标

到这一步，链路你已经清楚了大半。真正选型时，建议不要被"XX万像素""精度1mm"这些宣传词带着走，而是先画一张需求表格。以"机械臂抓取随意摆放的零件"为例：

每一项都要量化，不要写"尽量高""差不多"这种话，不然选型会变成拍脑袋。

6.2 实测验证：别信参数表，信自己的测试脚本

即使参数表再漂亮，拿到样机后也要做一轮规范化的实测验证。我建议至少跑下面四个测试：

• 平面拟合误差：把相机正对一面平整墙面，距离0.5米/1米/2米各采几帧，用RANSAC拟合平面，统计各点到平面的残差。残差均值是系统偏差，标准差是随机噪声
• 台阶精度：放一个已知高度的台阶（比如50mm的标准量块），看深度图上台阶高度测出来是多少。这一步能直接检验距离精度和边缘准确性
• 动态扫描：拿一个标准球或者圆柱体，开着相机让物体旋转或平移，做点云配准或者拟合球面，看球心偏移和半径误差
• 稳定性：连续跑1小时，统计深度值漂移、丢帧率、相机表面温度

这些测试写成一个脚本，所有候选模组用同一套流程跑，横向对比才有意义。

6.3 从原型到量产：链路里最容易忽略的三件事

最后分享几个我在从原型到量产过程中最常被忽略的细节。

第一是结构光路设计。模组装进外壳后，如果外壳的窗口玻璃透过率不佳，或者玻璃反射的红外光进到sensor视场里，深度图会多出莫名其妙的亮斑和暗带。窗口玻璃尽量选对850/940nm透过率高的材质，并且镀增透膜。最麻烦的是玻璃内侧和sensor之间形成二次反射，这个只能在结构上增加遮光罩来解决。

第二是散热对深度精度的影响。前面温度漂移提过，到量产阶段这个影响会变成用户投诉：设备开久了测距不准。所以整机设计时，发热器件（主控、激光驱动）要和ToF模组保持距离，或者做导热隔离，同时SDK里一定要有温度补偿开关，并且做老化验证。

第三是标定数据的可追溯性。产线上每一台相机都要有出厂标定，标定文件要和相机SN绑定存储。我在售后排查时经常遇到深度数据整体偏移的情况，查到最后就是出厂标定文件丢了，固件刷机后跑的是默认标定，精度当然不对。标定数据管理看起来是流程问题，到最后坑的还是软件工程师。

说回文章开头的那个黑衣服问题。理解整条链路之后，你会意识到"黑衣服测不到"其实不是一个bug，而是ToF物理原理下必然存在的边界情况：主动光信号落到低反射率表面，返回光子数不足，置信度判定不通过，于是深度值被丢弃。你可以通过选940nm波长、提高激光功率、降低曝光阈值或者使用更强的后处理算法来缓解，但物理边界就在那里——这正是做工程和做理论的差别：理论告诉你极限在哪，工程决定你在多接近极限的地方安全运行。

我个人这几年用ToF最大的体会是：绝大多数所谓"相机不稳定"的问题，最后都能在链路某一层找到明确原因。要么是发射端光功率随温度漂了，要么是接收端置信度阈值设得不合理，要么是点云生成时scale没除干净，要么是标定文件压根没生效。做ToF开发，别把它当黑盒，从上到下把链路梳理清楚，再去解决问题，会顺手非常多。