企业官网建设流程全解析

从第一次把 ToF 相机接到嵌入式板子上，到在产线上用深度图去判断一个零件有没有放正，这中间踩过的坑比我预想中多得多。很多人以为 ToF 相机就是一个能出深度的摄像头，插上 USB 就能拿到点云，结果一测数据全是噪声，或者到了户外直接饱合，再或者上了机械臂之后因为反光把工件测成飞掉。这其实不是某一个环节的问题，而是底层硬件、驱动链路、标定补偿、上层算法这一整条链路没有打通。这篇文章我就从光的物理原理开始，一路讲到 SDK 的封装、OpenCV 和 ROS2 的调用方式，最后落到工业场景里那些常见的坑和排查思路，把这几年在 ToF 相机整体链路上攒下来的经验一次说清楚。

1. 从一颗光子说起：ToF相机的成像原理

1.1 什么是ToF，它和结构光、双目差在哪

ToF 的全称是 Time of Flight，翻译过来就是飞行时间。它的核心思路非常直接：发出一束光，光碰到物体表面再反射回来，测量这段往返需要多长时间，然后乘以光速再除以二，就能得到物体到相机的距离。已知光速是 299792458 米/秒，只要时间测量足够准，距离就能测得很准。听起来简单，但真正做起来的时候，一个纳秒的误差就意味着大约 15 厘米的测距偏差，所以底层题材其实是一个高精度时间测量的工程问题。

有一个误区要先纠正：很多人把深度相机都叫 ToF，其实深度相机有三大类技术路线。结构光用的是投影仪打出编码光斑或者光栅条纹，通过观察图案形变来计算深度，典型代表是早期的 Kinect v1 和奥比中光的一些产品；双目视觉则是完全被动的方案，用两个固定距离的普通摄像头同时拍摄，靠图像特征匹配和三角测量来计算深度；ToF 是唯一一种主动发光、直接测时间的方案。三者的区别就像结构光是用一把量角器去量，双目是用一双眼睛去估，而 ToF 是用一把尺子去量，这把尺子就是光的飞行时间本身。

在三者之间做选型时，结构光的优势是近距离精度高、不需要强光辅助，但受环境光干扰严重，而且在室外太阳光下基本没法用；双目方案成本最低、在纹理丰富的环境下效果不错，可一遇到白墙、反光面这类低纹理区域就直接失效，特征匹配会丢失；ToF 对环境光有一定抵抗能力，帧率高、算法简单，缺点是分辨率普遍偏低、多台设备一起用会有相互干扰。在工业检测、机器人避障、AGV 导航这类需要实时且稳定的深度信息的场景里，ToF 往往是综合下来最省心的选择。

1.2 两种主流ToF方案：dToF和iToF

ToF 内部还有两条技术分支，一个是 dToF（直接飞行时间），另一个是 iToF（间接飞行时间）。这两者的区别不是品牌差异，而是物理测量方式完全不同，直接决定了传感器的架构和成本。

dToF 的思路非常"硬核"：激光源发出一个纳秒甚至皮秒级的短脉冲，传感器里的单光子雪崩二极管（SPAD）开始计时，光子反射回来打到 SPAD 上时结束计时，得到的就是精确的飞行时间。dToF 的核心优势是测距远、抗环境光能力强，苹果的 LiDAR 激光雷达用的就是这类方案，消费级产品上它的探测距离可以做到 5 米甚至更远，工业级的 dToF 模组可以测到几十米。但 SPAD 阵列的工艺成本高，像素尺寸大，所以分辨率一直提不上去，目前常见的就是 240x180 或者更低。

iToF 走了另一条路：它不直接测单个光子的飞行时间，而是发出连续调制的正弦波或方波光信号，然后通过传感器里每个像素采集多个相位偏移下的光强，再通过三角函数解算出相位差，最后换成距离。图 1 中那种"发光-反射-采样"的示意图相信大家都见过，但实际上 iToF 在每一帧里要采集好几次不同相位的曝光，通过四步、八步甚至更多步的采样来消除误差。这种方案可以用标准的 CMOS 工艺制造，分辨率能做到 640x480 甚至更高，价格也更平民，现在市面上一千多块钱的 ToF 开发板基本都是 iToF 方案。

iToF 有一个关键限制叫"模糊距离"：因为相位差是周期性的，超过激光调制波长对应的距离之后，相位会进到下一个周期，导致测距结果周期性反转。比如调制频率 30MHz 的光，对应模糊距离大约是 5 米，超过 5 米的物体测出来会突然变成很近的值。所以用 iToF 时一定要看清楚标称的量程，不是最大显示距离越远越好，而是要看在目标距离范围内是否包含了完整的调制周期。在实际项目里，选 dToF 还是 iToF 还要看环境光强度和目标材质，玻璃、黑色橡胶这类低反射率的物体，对两种方案来说都是一个考验。

1.3 激光、镜头、滤光片：硬件层选型的关键项

很多人用 ToF 相机只看分辨率、帧率和量程这三个参数，真正把硬件拆开研究之后才发现，硬件层的选型决定了很多"软件调不回来"的问题。ToF 的硬件核心有四大块：光源、传感器、光学镜组、驱动电路。

光源方面，ToF 几乎清一色使用 VCSEL 垂直腔面发射激光器，波长集中在 850nm 和 940nm 两个波段。选 850nm 是因为普通 CMOS 传感器对 850nm 的量子效率更高，同样的光功率下能获得更强的信号；选 940nm 是因为太阳光谱里 940nm 附近的成分比 850nm 弱，户外抗阳光干扰能力更强。这里有个容易被忽略的点：发射端和接收端必须有对应波段的窄带滤光片，否则太阳光和环境照明会直接淹没反射信号。我之前接过一个项目，客户自己换了没有滤光片的镜头，测距噪声瞬间从毫米级恶化到几十厘米级，排查了半天。

VCSEL 的功率等级直接决定安全性和测距能力。消费级 ToF 通常做到 Class 1 人眼安全等级，靠的是低平均功率加高瞬时峰值，因为脉冲宽度极窄，平均能量远低于损伤阈值。工业环境如果要求更远的量程，可能会上 Class 1 上限甚至 Class 3R 的激光器，那就必须考虑防护罩和联动断电设计。这一点在做产品时必须提早在合规流程里介入，激光安全等级认证不是开发完成后补一个测试就能过的。

光学镜组上，ToF 的镜头通常用玻璃镜片 + 红外增透膜，广角镜头能看到更大的视场，但也意味着每个像素对应的角度更粗、横向分辨率更低。驱动电路则是经常被人忽略的部分：VCSEL 的驱动需要高速电流开关，SPAD 阵列需要高压偏置（通常 20V 以上），iToF 传感器需要精确的调制信号同步。这些高速信号在 PCB 上的布局、走线、屏蔽直接决定了测量噪声底。所以千万别只把 ToF 相机当成一个普通摄像头来选型，它的硬件设计是高度专精的，这也解释了为什么同样标着 640x480 的 ToF 模组，各家价格能差好几倍。

2. 从光子到数字：传感器读出与数据链路

2.1 像素阵列与片上计算

当光子经过镜头和滤光片打在传感器上之后，接下来的链路就进入了半导体世界。不同的像素结构决定了输出数据的形态。dToF 的 SPAD 像素里内置了时间数字转换器，光子击中瞬间就产生一个时间戳，大量光子事件的统计结果会构成一个直方图——横轴是时间，纵轴是光子计数——然后算法在直方图里找峰值，峰值对应的横坐标就是飞行时间。这里有一个重要细节：SPAD 存在死时间（每次触发后需要一小段恢复时间），所以高光环境下 SPAD 提前饱和，反而会丢失远处的弱反射信号，这就是 dToF 在强阳光下测距能力下降的物理原因之一。

iToF 的像素则是一个光电二极管 + 多个抽头（tap）的结构，在传感器全局快门模式下，通过控制抽头把不同相位的光生电荷分别积累到不同电容中，帧末统一读出。它不产生直方图，产生的是多个相位下的灰度强度图。很多人以为 iToF 传感器输出直接就是深度图，其实完全不是，原始的 iToF 数据是 4 张或者 8 张相位图，只有经过解相位运算才能变成深度图。这个运算可以由传感器芯片内的 DSP 完成，也可以通过 SDK 在主机端完成，两种做法的差异很大：片上处理可以减少主控负担、降低带宽占用，但灵活性差；主机端处理可以随时修改解算参数，但要多占用带宽和 CPU。

点云生成的链路里经常被忽略的是置信度图。tof 传感器在输出深度图的同时，通常还会输出一帧 amplitude（幅度图）或者 confidence（置信度）图，表示每个像素反射信号的强弱。反射信号弱的地方（黑色物体、远距离物体、逆光区域）深度值不可信，实际应用中必须用置信图做掩膜，把低置信度的像素剔除掉。很多头一次用深度相机的用户上来就直接用原始深度图做检测，结果在深色物体上出现一片一片的洞，这不是相机坏了，而是没有正确使用置信度数据处理。

2.2 数据接口怎么选：USB3.0、GigE还是MIPI

ToF 相机的输出接口直接影响到它的应用场景和部署方式。目前常见的有 MIPI CSI-2、USB3.0、GigE Vision 三种，三者的设计定位完全不同。

MIPI 是传感器和 SoC 之间的内部总线，带宽高、延迟低、功耗省，适合嵌入式设备直接把 ToF 模组贴在主板上用。NVIDIA Jetson、瑞芯微 RK3588、树莓派这些平台接 ToF 摄像头最方便的方式就是 MIPI，因为驱动可以直接打到内核层，数据不需要经过 USB 协议转换，延迟可以做到极低。缺点是物理距离短，模组必须靠近主板，不适合远距离安装，而且每个平台的驱动移植工作量都不一样。

USB3.0 接口是目前开发板和一众的通用选择，插上就能用，SDK 支持也全。USB3.0 的理论带宽是 5Gbps，实测有 3.2Gbps 以上，对 640x480 的深度图 + 彩色图 + 置信度图这类多流数据完全没有压力。缺点是易受线材质量、插拔次数和功耗分配的影响，供电不足会造成设备异常断开，这在工业环境里很头疼。

GigE Vision 是老牌工业相机标准接口，基于千兆网口传输，特点是线缆可以做到几十米长，抗干扰能力强，并且天生支持多个相机组网。很多工业 ToF 相机（比如 Basler、海康的深度相机线）都支持 GigE Vision。它的缺点是带宽相对有限，理论瓶颈 1Gbps，实际可用 900Mbps 左右，如果深度图分辨率上来了，帧率就会受限。还要注意网卡性能和巨型帧设置，很多人插上 GigE 相机只有 5 帧每秒，结果只是没开 Jumbo Frame。

接口选型有一个核心公式要算清楚，我们放在下一节细讲。

2.3 带宽与帧率如何估算

不管什么接口，数据链路的带宽瓶颈是谁都能算出来的，就怕项目做到后面才想起来算，到时候换接口就是推倒重来。先看一个准确的计算公式：一帧深度数据的大小 = 像素列数 x 像素行数 x 每像素字节数。常见的深度像素格式是 16 位无符号整数（单位是毫米），所以 640x480 的深度图一帧就是 640x480x2 字节 = 614400 字节，约 0.59MB。再加一帧同样分辨率的 RGB 图（24 位），就是 640x480x3 = 921600 字节，约 0.88MB。两路叠加大概 1.5MB/帧，按 30fps 计算，总带宽大约是 45MB/s，约 360Mbps。

这个数字对于 USB3.0 的 5Gbps 来说很宽裕，但 GigE 只有 1Gbps，扣掉协议开销后还要同时传深度和 RGB，帧率必然被卡住。很多 GigE 工业 ToF 相机出厂默认只输出深度图 15fps 左右，就是综合考虑了带宽和主机处理能力的结果。如果既想要高分辨率又想要 30fps，还想要同时输出 RGB 和点云，那 GigE 就不够用了，要么换 USB3.0，要么上 10GigE 相机。

帧率还受传感器读取时间和计算时间的限制。iToF 一帧深度图需要采集 4~8 个相位子帧，每个子帧都要完整的曝光和读出时间，所以传感器物理层面的帧率上限通常远低于标称的"输出帧率"。比如标称 30fps 的 iToF 相机，内部传感器可能实际上是工作在 120fps 甚至 240fps 的采样模式。这种细节普通用户关心不到，但如果要做多相机同步或者运动物体捕捉，就要提前确认相机的内部触发模式和曝光时序，否则运动物体的深度图会出拖影。

3. 与ToF相机通信：驱动、SDK与相机标定

3.1 驱动安装和设备枚举

接上 USB 或者网线之后，第一件事是让操作系统"认识"这个设备。ToF 相机的驱动模式和在量摄像头不一样：普通网络摄像头走 UVC（USB Video Class）标准协议，Windows/macOS/Linux 自带驱动，插上去直接被系统识别成摄像头。但 ToF 相机输出的不是标准的视频流，而是深度数据流，不能简单塞进 UVC 框架里，所以大部分 ToF 相机都采用厂商自定义的 USB 传输协议，必须安装配套的 SDK 或者底层驱动，系统才会枚举出对应的设备节点。

Linux 下最典型的问题是 USB 权限。直接用厂商 SDK 跑示例程序的时候，经常报 "Device not found" 或者 "Cannot open device"，十有八九是缺少 udev 规则。厂商 SDK 包里面通常带一份99-tof.rules之类的文件，复制到/etc/udev/rules.d/目录后重新插拔设备，权限问题就解决了。这步太基础了，但每次做新项目都有人卡在这里，值得多说一句：以后用任何 USB 传感器或者 USB 转串口，都养成先装 udev 规则的习惯，可以省掉大量的调试时间。

GigE 接口的相机的枚举流程就更讲究一些。GigE Vision 基于 UDP 协议，相机本身有一个 IP 地址，计算机网卡要有同网段的 IP 才能发现设备。工业相机 SDK 里通常有一个"强制 IP"功能，就是把相机 IP 改成和网卡一致的网段，改完之后设备才能出现在设备列表里。另外 GigE Vision 的数据包是拆分成多个小包传输的，必须要配置巨型帧（Jumbo Frame，MTU 9000）才能避免 UDP 包丢失和带宽浪费。常见的现象是：相机能枚举到，但启动采集后画面一卡一卡的，丢帧严重，优先看网络属性里的 MTU 是否设置正确。

3.2 SDK能做什么：深度图、点云、置信图

驱动安装好之后，你真正开始接触的是厂商的 SDK 接口。不同厂家的 SDK 命名和风格千差万别，但核心的采集流程基本一致，可以概括为：初始化设备 -> 设置参数 -> 注册数据回调 -> 启动采集 -> 处理每一帧 -> 停止采集 -> 反初始化。以我常用的一个 ToF SDK 为例，核心调用流程是这样的：

// 以伪代码示意，不同厂商SDK结构类似 TofDevice device; device.open(); // 打开设备 device.setDepthRange(0.3f, 4.0f); // 设置深度范围 device.setExposureTime(500); // 设置曝光时间（微秒） device.enableStream(Depth, 640, 480, 30); // 使能深度流 device.enableStream(RGB, 640, 480, 30); // 同时使能RGB流 device.setCallback([](const FrameSet& frames) { auto depth = frames.getDepthFrame(); // 深度图，毫米 auto rgb = frames.getColorFrame(); // 彩色图 auto confidence = frames.getConfidence(); // 置信度图 // 这里做业务处理 }); device.start(); // 业务代码... device.stop(); device.close();

SDK 这一层最重要的产出是三样东西：深度图（Depth Map）、点云（Point Cloud）和置信度图（Confidence Map）。深度图本质上是一个二维数组，每个像素值表示该位置物体到相机的距离，单位通常为毫米；点云是把深度图按相机内参投影到三维空间里生成的三维坐标集合；置信度图是一个灰度图，亮的地方表示反射信号强、测得准，暗的地方表示反射弱、深度值不可信。三者的关系可以这样理解：深度图是"2.5D"的底层数据，点云是深度图按内参投影的结果，置信度图是判断前两者可不可用的依据。

很多项目在深度图上做检测和定位时，我强烈建议先把置信度图利用起来。比如要做工件定位，先设定一个置信度阈值，低于阈值的深度像素直接置为无效，再对有效深度做区域生长或者平面拟合，得到的结果会稳定非常多。这一条几乎适用于所有的 ToF 应用场景，专不专业很多时候就是从这些小细节上看出来的。

3.3 相机标定不可跳过

无论是 ToF 还是普通工业相机，"标定"都躲不掉。在 ToF 场景里标定分两个层面：第一个层面是传统相机的内参标定，拿到的是焦距 fx、fy 和光心 cx、cy 以及畸变系数；第二个层面是 ToF 特有的深度误差校准。

先说传统的相机内参标定，用 OpenCV 的calibrateCamera就能搞定。准备一块棋盘格标定板，从不同角度拍十几张清晰的图像，提取角点，然后跑标定流程。这里有个 ToF 相机特有的坑：ToF 相机的红外光主要是主动照明，如果直接用 RGB 镜头拍照，可能受到低光环境的影响，所以很多 ToF 相机的 RGB 镜头默认是带红外截止滤光片的，标定 RGB 时必须保证环境光充足。另外棋盘格标定板在红外图像里的对比度经常不够，可以考虑用红外反射率高的铝板加黑点阵列，或者直接用具备红外增强的标定板。

深度误差校准则更复杂一些。理想情况下，ToF 测距误差应该是一条过零点的直线，但实际测量中，由于 VCSEL 与传感器的温度漂移、像素间的串扰、多次反射等因素，误差表现更像是"随距离变化的非线性曲线"。所以工业级的 ToF 相机出厂前会在多档距离下测量真实误差，生成一张查找表或者多项式拟合参数，烧录到设备的 flash 里，SDK 在出深度图时自动做补偿。如果你发现你自己的相机测出的平板距离呈波浪形起伏，先查一下 SDL 里的校准参数是否被重置了，再决定要不要送厂重新标定。

还有一个细节：多台 ToF 相机之间会有相互干扰。如果生产线上要多台并列架设，要么用不同调制频率错开，要么加时间同步让相机轮流曝光，否则深度图会出现周期性的条纹噪声。

4. 上层应用：OpenCV、ROS2与工业场景落地

4.1 OpenCV怎么调用ToF相机

OpenCV 是大部分人的第一站。对于普通 RGB 摄像头，VideoCapture配合 V4L2 或 DirectShow 就可以直接取流，但 ToF 相机这种自定义协议的设备无法直接通过VideoCapture读取深度图，因为 OpenCV 本身不认识 ToF 协议。常见的做法有两种。

第一种是把 ToF 相机配置成 UVC 兼容模式。部分消费级 ToF 相机（比如 Intel RealSense 的部分型号）在 UVC 协议下可以输出左右红外图和深度图，OpenCV 可以像打开普通摄像头一样打开它，再通过VideoCapture::set设置设备内部的深度处理器。这种做法很省事，但损失了很多控制参数（曝光、激光功率、滤波强度等），所以只能在轻量场景里用。

第二种也是我更推荐的做法：用厂商 SDK 取数据，再转换成 OpenCV 的cv::Mat格式。以 SDK 返回的深度数据为例，把深度缓冲直接拷贝到单通道 16 位 Mat 里，然后可以随意做 OpenCV 的后续处理，比如用cv::medianBlur去掉极深的噪声点、用cv::threshold提取出特定距离的目标、或者配合cv::findContours做物体定位。把深度图和 RGB 图对齐之后，还可以用cv::warpPerspective做透视变换，拿到工件顶视图做二维尺寸测量。

这里插一个我常跟人提的观点：OpenCV 处理的是"图像"和"二维信息"，而深度图的核心价值在于把像素和"三维世界坐标"挂上了关系。所以更高级的做法是用深度图生成点云，然后直接操纵三维点去做距离测量、平面拟合、物体分割。OpenCV 里可以配合 PCL 点云库，或者直接手写一个投影循环。很多时候你从 RGB 二维图像里半天解不出来的问题，换到三维点云里几行代码就解决了，比如测一个斜面上两个铁钉的中心距，用平面投影和圆拟合比数像素要准得多。

4.2 ROS2封装与点云使用

做机器人相关项目，ROSkills几乎绕不开。ROS2 生态里对深度相机的支持已经非常成熟，关键在于驱动封装和话题类型。ToF 相机在 ROS2 中通常被封装为以下几个话题：

• 深度图话题：sensor_msgs/msg/Image，编码类型是16UC1，单位毫米，像素坐标和 RGB 话题对齐后可被 RViz 直接显示。
• 彩色图话题：sensor_msgs/msg/Image，编码类型是 RGB8。
• 点云话题：使用sensor_msgs/msg/PointCloud2，包含 XYZ 坐标和可选的 RGB 颜色。
• 相机内参话题：sensor_msgs/msg/CameraInfo，里面装的就是标定后的 fx、fy、cx、cy 和畸变系数。

如果你用的相机已经有现成的 ROS2 驱动（比如 RealSense 的realsense2_camera、奥比中光的orbbec_camera），基本就是启动一个 launch 文件就能发布以上话题。如果用的是偏底层的工业 ToF 相机，就需要自己写一个 ROS2 节点去封装厂商 SDK 的回调，把深度和彩色数据克隆成 ROS2 消息发布出来。注意深度消息要修好encoding字段，否则下游节点会误把16UC1当成MONO16用，读取到的图像就会错乱。

ROS2 生态里最有价值的几个下游工具是depthimage_to_laserscan、rtabmap和octomap。depthimage_to_laserscan可以把深度图的一行像素转成 2D 激光扫描数据，意思就是说，一个便宜 ToF 相机加一个小节点，就能当激光雷达用，在室内导航的场景里非常实用。注意，这里实际上是把深度图的一行转换成距离值，效果约等于单线雷达，但它对全向导航已经够用了。rtabmap可以做 RGB-D SLAM，直接摄入深度图和 RGB 图，输出里程计和地图；octomap则是把点云转成八叉树占据地图，方便机械臂做避障规划。

还有一个坑是时间戳同步。如果你是分别发布深度、彩色和 CameraInfo 的，必须确保它们的采样时间是一致的，否则后期做点云配准或者融合的时候会出现颜色错位和坐标偏移。一般做法是 SDK 回调里把同一帧采集到的不同流数据打上同一个时间戳，再打包发布出去，不要各自取自己的ros::Time::now()。

4.3 工业场景实战与排查清单

最后的压轴部分聊聊产线上那些真正折磨人的问题。很多客户都会拿 ToF 相机去做定位、测量、防碰撞，联调时最容易出问题的几类问题我挨个说。

第一类是目标物反光和透光。金属工件直接裸露的情况下，VCSEL 发出的光在镜面表面会发生镜面反射，传感器收到的是高亮饱和区域，深度值会直接飞掉或变成空洞。黑色的塑料工件正好相反，反射率低，回波信号弱，深度图全是置信度极低的黑色区域。处理思路无非两条：一是从硬件上增加外部光源辅助或者加偏光片，但这个方案在 ToF 上行不太通，因为 ToF 依赖的是自身主动光的相位信息，外部光源会干扰解相；二是从算法上利用置信度掩膜和空间插值，把这些区域的深度值补出来。更直接的解决方案是涂层处理，如果工件本身允许，在不影响工艺流程的前提下喷涂一层哑光漆能立刻解决反射问题。有朋友在 OpenPNP 贴片机上遇到"底部相机有些芯片识别不了"的问题，很多也是这个原因——芯片引脚焊盘反光严重，RGB 相机在明场/暗场光下对比度不足，换一个角度把光照压暗或者加偏振镜就能解决，这个思路和 ToF 的金属工件问题如出一辙。

第二类是相机安装角度和高度。ToF 相机如果垂直向下安装在流水线上方，要确认它的最小测距距离。很多 iToF 相机的最小量程是 0.3 米或 0.5 米，如果安装高度只有 20 厘米，相机直接工作在盲区里，深度图会全部失效。另外斜装的时候要注意 ToF 的投影畸变，深度图上的每个像素点的采样间隔会随角度变大，同样的一颗螺丝，画面边缘测出来的直径会比中心偏大。所以做测量应用时，最好让目标区域落在画面中心视场范围内，或者对深度图做径向校正。

第三类是世界坐标系的映射问题。ToF 相机得到的是相机坐标系下的点云，跟机器人/流水线坐标系都有一个装夹位置的关系。这里除了相机内参标定外，还要做"手眼标定"。标准流程是用一块高精度棋盘格或者圆点标定板，在机器人可达范围内摆放多个姿态，同时记录机器人末端位姿和相机观测到的标定板位姿，然后用 AX=XB 的方程解出相机到机器人末端的变换矩阵。手眼标定的精度直接决定了视觉引导能不能把机械臂抓准，一个常见的失败原因是标定板平面和相机光轴夹角太小，导致外参解算退化，实际操作中至少要让标定板在三个不同高度、五个不同倾角下拍全。

第四类是环境光和热噪声。户外的 ToF 相机在正午太阳直射下，940nm 波段的环境光依然很强，SPAD 或 CIS 会提前饱和，量程缩短、噪声变大。这种情况的解法是加太阳光抑制的窄带滤光片，并且将曝光时间调小，宁愿回波弱一点也要先防止饱合。热噪声则表现为相机连续工作半小时后，深度图的随机噪声逐步增大——这是因为 VCSEL 的波长随温度漂移，滤光片透过率曲线也会漂移，两者一错位信号就衰减了。所以工业级 ToF 相机要设计主动散热或者恒温控制，选型时这一条不能省。

我在多次项目中总结过一个 ToF 相机问题排查的顺序，先照着查能省很多时间：

用这张表，加上前面各节的原理细节，大部分 ToF 项目的排障工作都能快速收拢到具体环节，不会像无头苍蝇一样来回换设备。

最后再分享一个从实际产线里练出来的经验：ToF 相机不是"插上就准"的传感器，它的精度高度依赖于工作温度、目标材质和环境光这三个条件。所以你在实验室里测出来的效果只能作为参考，真正上场之前一定要在目标产线的真实环境里采集一组数据，观察从开机到热机这段时间的深度变化曲线。如果温差导致的测距漂移超过了你的容差，就别想着纯软件补偿了，老老实实给相机加装散热结构或者恒温罩，比什么算法都靠谱。做深度视觉这件事，底层到上层每一环都可能变成瓶颈，但只要你把整条链路吃透，现场的问题其实都是有解的。