ToF相机技术全解：从测距原理到工业应用落地

1. 整体链路与设计思路拆解

1.1 从测距物理层说起：ToF 的本质是测时间

要聊 ToF 相机的整体链路，我建议先忘掉“相机”这两个字，把它当成一个“高速计时器”来看。

ToF 的全称是 Time of Flight，也就是飞行时间。原理说起来很朴素：我发出一束光，光打到物体表面再反射回来，只要测出这束光从发射到接收用了多长时间，乘以光速再除以二，就是相机到物体之间的距离。这个公式小学物理水平就能看懂：

距离 = (光速 × 飞行时间) / 2

但真正做产品的人都知道，难点全在“怎么把时间测准”上。光速大约是每秒 30 万公里，也就是说，想要实现 1 毫米的测距精度，你需要分辨大约 6.7 皮秒的时间差。常规的电子计时电路根本做不到这个量级，所以工业界换了一个思路，不直接测时间，而是测相位。

这就是 iToF（间接飞行时间）相机的主流做法：发射的是经过调制的连续光波，比如正弦波或方波，接收端把反射回来的光波和发射端的参考信号做相关运算，通过测量相位偏移来反推飞行时间。用公式表达就是：

距离 = (相位偏移 / 2π) × (光速 / (2 × 调制频率))

而 dToF（直接飞行时间）走的则是另一条路，用单光子雪崩二极管（SPAD）配合高精度时钟，直接记录每一个光子的飞行时间。苹果从 iPhone 12 Pro 开始用的 LiDAR 就是典型的 dToF 方案，它的抗环境光能力更好，在远距离场景下优势更明显。

这两种方案没有绝对的优劣，iToF 成本低、分辨率容易做高，但在远距离和环境光强的场景下精度衰减明显；dToF 测距远、响应快，但 sensor 成本贵，分辨率上不去。选型时主要看应用场景：手机人脸识别、工业近距离测量，大概率选 iToF；自动驾驶、扫地机器人这种需要远距离探测的，dToF 更合适。

我的建议是，不管项目里用的是哪类 ToF，都必须先建立一个认知：ToF 相机的精度不是出厂定死的，而是从激光驱动、传感器响应、标定参数到环境补偿一整条链路共同作用的结果。项目一旦出现问题，往往不能只在某一个环节找原因，而是整条链路都得过一遍。

1.2 为什么是 ToF：和结构光、双目比一比

很多刚接触深度相机的朋友会在 ToF、结构光、双目之间纠结。我直接说我个人的结论：没有“最好的深度相机”，只有“最适合当前场景的方案”。

结构光的思路是投射已知图案到物体表面，再用摄像头观察图案的形变来算出深度。它的优点在近距离精度很高，比如手机人脸解锁的典型工作距离是 30 到 80 厘米，能够达到毫米级的精度。但一旦距离变远，投射出去的图案会被环境光淹没，精度迅速恶化；而且它非常怕强光，室外基本没法用。

双目则是通过两个摄像头看到的视差来计算出深度，原理和人眼类似。它的优势是只要标定得好，室内外都能工作，硬件成本也比较低。但它特别依赖物体表面的纹理特征，如果面对一面纯白墙壁或者光滑金属表面，左右相机找不到可以匹配的特征点，深度图就会出现大片黑洞。另外双目的计算量不小，在没有专用计算单元的情况下，跑 VGA 分辨率也得占用不少 CPU。

ToF 在这个对比里的定位很有意思。它不依赖环境纹理，所以面对白墙、金属件、黑色吸光物体，只要反射率不太离谱，都能给出深度数据；同时它是主动光源，在光线很暗甚至完全无光的场景下也能工作。工业上很多场景，比如 AGV 避障、机器人拆垛、料箱定位，往往既没有丰富纹理也经常在人工照明条件下作业，ToF 反而成了最稳的选择。

ToF 的短板是在强阳光下容易饱和，远距离精度受多重反射影响，而且普通 iToF 的分辨率目前普遍还停留在 640×480 或者 1280×960 这个级别，远远比不上动辄 2000 万像素的 RGB 相机。所以你会发现，实际项目里 ToF 很少单独扛下所有任务，多数时候是和 RGB 相机配合：RGB 负责颜色纹理信息，ToF 负责距离轮廓，两者做数据融合。

1.3 一条完整链路有哪几个节点

一个 ToF 相机从硬件到应用，大概可以切成四个大块：

很多做上层应用的人有一个惯性思维，觉得相机就是“插上电，调用 SDK 取帧”，把深度相机当成一个普通摄像头来用。但 ToF 不一样，它的输出结果是典型的“算出来的数据”而不是“拍出来的数据”。Sensor 出来的是四步相移的 Raw 数据，需要经过解相位、去包裹、标定矫正、滤波等一系列计算，才能变成你在 SDK 里拿到的深度图。这个过程里任何一步参数设置不合理，都会直接影响最终精度。

所以这篇文章我打算按这条链路从下往上走，把每一层的核心要点、常见坑位、实操选型逻辑一次讲清楚。

2. 底层硬件拆解：发射、接收与控制

2.1 光源选型：VCSEL 和波长背后的门道

ToF 相机里最关键的光源器件，现在基本都是 VCSEL，也就是垂直腔面发射激光器。相比传统的 EEL（边发射激光器），VCSEL 的优势是光束质量好、易于二维阵列化、温漂小、成本可控。你去看市面上主流 ToF 模组的拆解，光源部分十有八九是 VCSEL 阵列加上一片 Diffuser 扩散片，VCSEL 负责出光，Diffuser 负责把光束打散成目标视场角。

波长选择上，市面上绝大多数 ToF 用的是 850nm 和 940nm 这两个近红外波段。在室内场景，850nm 的量子效率更高，sensor 响应更好，但缺点是环境光里 850nm 附近也有不少成分，阳光直射时容易饱和。940nm 在太阳光谱里的能量低不少，抗环境光能力更强，但 sensor 的量子效率会下降，需要更强的激光功率来补偿。我的实际经验是：如果是纯室内项目，优先选 850nm；如果有靠近窗户或者户外使用的可能，直接上 940nm，别犹豫。

激光功率这方面有个硬约束，就是人眼安全等级，脉冲激光的功率不是你想加就加的，尤其 ToF 是面发光的泛光照射，不像雷达那样是点扫描，最坏情况下人眼会直接注视激光源。产品要通过 Class 1 人眼安全认证，发射功率是被严格限制的，所以你在项目中经常需要做的不是“把功率调大解决所有问题”，而是在法规允许的范围内做积分时间和功率的平衡。

这里顺带提醒一句：调 ToF 相机参数的时候，不要长时间直视激光窗口。iToF 相机用的是连续调制光，虽然不是瞬时高峰值功率，但日积月累的暴露对眼睛没有好处，实验室里养成的习惯永远是把激光窗口朝下或者遮挡之后再调试。

2.2 接收端：CIS 还是 SPAD，决定了性能天花板

接收端的传感器，iToF 和 dToF 走的是完全不同的路线。

iToF 主流使用的是 CIS（CMOS Image Sensor），本质上是带有调制解调功能的像素阵列。每个像素不仅记录光强，还能通过像素内部的电子快门，在极短的时间窗口内对反射光进行多次采样，计算出相位差。像素内通常还集成了解调结构，用来输出 I/Q 两路信号，消除一部分共模噪声。

dToF 则使用的是 SPAD，也就是单光子雪崩二极管。SPAD 的工作状态是“盖革模式”，任何单个光子触发的雪崩都会被记录为一个数字脉冲，配合时间数字转换器（TDC）直接记录光子到达时间。它的时间分辨率能做到几十皮秒量级，这是 dToF 测距精度和测距范围都优于 iToF 的根本原因。

在项目中做选型时，我通常会问三个问题：

1. 工作距离是多少？如果超过 5 米甚至 10 米，直接放弃 iToF，选 dToF。
2. 环境光条件如何？户外、强光下，优先 dToF，或者选带环境光抑制算法的 iToF。
3. 对分辨率有多高要求？如果既要深度又要看得清细节，iToF 往往更容易满足，因为它的像素可以做到小尺寸和高密度。

2.3 激光驱动与电源设计：没人在意的“隐形杀手”

激光驱动是整个 ToF 硬件链路里最“硬核”也最容易被上层应用忽视的部分。

iToF 的驱动需要给 VCSEL 提供高频调制电流，调制频率通常在 10MHz 到 100MHz 之间。也就是说，激光器不是在连续发光，而是在以非常高的频率做开关切换。切换的边沿陡峭程度、电流的稳定性，都会直接影响到相位测量的准确性。

电源设计方面，ToF 模组往往对电源纹波非常敏感。如果供电纹波太大，调制信号的质量就会下降，最终反映在深度图上是周期性的条纹噪声。我自己踩过一个坑：用同一个开关电源给机械臂和 ToF 相机供电，机械臂一启动，深度图上就出现固定模式的波动，查了半天才发现是电源干扰。后面改成独立供电，问题立刻消失。

散热也是一个隐藏约束。VCSEL 的效率不是 100%，大部分电能会转化成热，工作温度升高后激光波长会发生漂移，标定参数就会失效。很多工业场景的相机防护罩本身不透风，夏季车间温度能到 40℃以上，这时候相机内部的温度补偿算法就特别重要。

2.4 调制与同步：iToF 的测距核心

iToF 的整套测距流程，我尽量用通俗的方式讲：

假设发射光是一个正弦波，物体反射回来的光也是同频率的正弦波，但因为走了额外的路径，相位会滞后。这个相位滞后和飞行时间是线性关系。为了算出这个相位差，传感器不会直接测一帧，而是采样四帧，这四帧的采样窗口分别在 0°、90°、180°、270° 的相位偏移上，称为四步相移法。

这四个采样值记为 Q1、Q2、Q3、Q4，通过下面的公式可以算出相位差：

相位差 = atan2(Q4 - Q2, Q1 - Q3)

再把相位差换算成距离。但问题来了：相位差是按 2π 周期循环的，如果相位差超过 2π，就无法判断是“走了 1 个整周期 + 相位差”还是“只走了相位差”这一段，这个现象叫相位卷绕。解决方法是使用多个不同频率的调制波，用低频波解高频波的模糊，类似用游标卡尺的粗细刻度配合读数，这样就能扩展最大无模糊测量距离。

这个多频解包裹的过程，就是 ToF 数据链路里最核心的计算模块之一。如果频率设计选得不好，比如两个频率不是互质关系，解包裹算法很容易在信噪比不足的区域跳变，表现为深度图上突然出现 1 米级别的大跳变。

3. 驱动与数据流：从 Raw 到深度图

3.1 相机驱动层的几种形态

到了驱动这一层，你会看到 ToF 相机和普通相机的明显差异。

消费级的 ToF 相机通常会模拟成一个标准的 UVC 摄像头设备，你把它插到电脑上，系统直接识别为摄像头，可以像调用普通相机一样取流，深度图和 RGB 图会以特定的帧格式输出。这种方式的好处是兼容性极好，Android、Windows、Linux 都能免驱使用，代价是你拿不到 Raw 数据，只能拿到已经处理好的深度流。

工业级的 ToF 相机则更愿意走自定义的传输协议。常见的有 GigE Vision、USB3 Vision、Camera Link 等。走 GigE 的好处是布线距离可以到 100 米，数据带宽用网线就能顶起来，而且可以通过 POE 供电，现场部署非常方便。坏处是 GigE 的驱动和 SDK 每家厂商的封装风格差异很大，跨平台的时候踩的坑比较多。

比如你在项目里用 Basler 的工业相机，它有自己的 pylon SDK；换成海康机器人相机，又要换成 MVS SDK 和 GigE Vision 采集卡驱动。ToF 相机同理，奥比中光、Intel RealSense、瑞识、光珀各家的 SDK 设计理念完全不同，有的是纯 C++ 偏底层，有的直接给 Python 封装。项目选型时，SDK 的可维护性和文档质量要作为和硬件参数同等重要的维度来评估。

3.2 从 Sensor 出来的 Raw 数据流

如果你用的是一个能拿到原始数据的 ToF 模组，你会发现从 Sensor 出来的数据不是深度图，而是未经处理的 Raw 帧。

在四步相移模式下，每一帧深度需要 4 张原始采样图，这 4 张图记录的是不同相位窗口下的光强度。有些传感器是“一拍四”的设计，也就是在同一帧时间内同时输出四张相位图；有些是“1+3”或者“1+2+1”的顺序曝光模式，需要连续拍多帧合成一张深度图。这就导致了一个问题：如果物体在采集过程中快速运动，四张原始图之间的对不齐，最终深度图上就会出现运动伪影，尤其是在物体的边缘部分。

这个问题在工业场景特别明显。比如用机械臂抓取一个快速运动的传送带上的目标，如果 ToF 相机的曝光方式是顺序曝光，深度图里运动工件的边缘就会出现“鬼影”。那怎么办？两条路：一是选择带有全局快门和“一拍四”功能的 ToF sensor；二是从应用层下手，限制目标的运动速度，或者在算法上做运动补偿。

Raw 数据的带宽也值得算一算。假设分辨率是 640×480，每个相位图 16bit，一次输出 4 幅相位图，单帧原始数据量就是：

640 × 480 × 2 字节 × 4 = 2,457,600 字节 ≈ 2.34 MB

如果帧率是 30fps，数据量就是 70MB/s。这个带宽在 USB3.0 下勉强撑得住，但在 USB2.0 下完全不可能。所以很多便携式 ToF 模组会限制帧率到 15fps，或者直接在 sensor 端完成部分深度计算再把压缩后的数据输出。你在项目里做带宽评估时一定要把这个数据量算清楚，别等现场采集卡扛不住了才想起来。

3.3 深度图、置信度图和 IR 图的生成逻辑

ToF 相机的 SDK 输出通常不止一张深度图，至少还会有两个伴随数据：IR 图和置信度图。

IR 图是红外反射强度图，本质上就是反射光强度的分布。这个图在图像识别上非常有用，因为它不依赖可见光，在暗环境下依然可以清晰地看目标物体的轮廓。很多项目用 IR 图做人脸检测或者物体定位，效果比可见光图更稳定。

置信度图每个像素值表示接收信号的质量，值越高说明这个像素的深度越可靠。如果你在做机器人抓取，建议把置信度图用起来：深度值低于某个阈值的像素直接丢弃或者置为无效，可以显著减少飞点对后续点云处理的影响。

飞点是什么？主要是两种物理现象造成的：一是多径效应，光在物体之间多次反射后再回到传感器，导致测出的距离比实际远；二是边缘效应，在物体边缘，光斑的一部分打到前景，一部分打到背景，sensor 最终测出来的是一个折中值，表现为深度图边缘一圈“毛刺”。飞点是 ToF 的原理性缺陷，不可能彻底消除，只能通过置信度阈值、中值滤波、时间一致性滤波等方法来抑制。

3.4 相机的“掉线”问题不只是网络问题

拿到工业现场，最让项目组头疼的问题大概率是“相机时不时掉线”。

很多人的第一反应是网线或者 USB 线接触不良，但我实际排查过很多次以后发现，ToF 相机掉线的高频原因其实是这三类：

第一，供电不足或者电源纹波过大导致的异常复位。GigE 的 POE 供电在长距离网线上压降明显，PoE 供电模式标称 12V 或 24V，到相机端可能只剩下临界值，电流稍有波动就直接断连。

第二，带宽冲突。同一个交换机上接了多台相机，数据突发脉冲来不及缓存，相机内部 buffer 溢出，发生丢包重传之后，SDK 判定连接超时直接断开。

第三，电磁干扰。工业现场的伺服电机、变频器在工作时会产生很强的 EMI，如果网线屏蔽层的接地做不好，数据链路被干扰后频繁重连。

我现在的处理习惯是：项目一开始就做电源隔离和独立的网络交换机，网线全部使用屏蔽六类线，相机端接口做好防水防尘，然后在 SDK 里把网卡巨型帧打开、接收缓冲区调到最大。这套配置下来，工业现场基本不会因为基础环境问题掉线。

4. 标定：从内参到多机协同

4.1 深度相机的标定和普通 RGB 相机有什么不一样

普通相机的标定，核心是计算内参（fx, fy, cx, cy）和畸变系数。这个流程相机标定界早就是标准操作了，OpenCV 的findChessboardCorners加calibrateCamera一条龙，目标检测做得好，内参标定的精度就能达到亚像素级。

但 ToF 相机的标定复杂得多。因为 ToF 输出的深度值不是直接测量值，它受系统误差影响很大，这些误差包括：

• 温度变化导致的激光波长漂移和 sensor 响应变化
• 不同距离下由于光斑强度不同引起的 wiggling 误差
• 多重反射和散射导致的系统偏差

所以在 ToF 相机里，“标定”这个词至少包含两个层面：一是标准的相机内参标定，把像素坐标系和相机坐标系的关系定下来；二是深度误差补偿标定，要建立一个距离和误差的映射关系，用一张查找表或者多项式模型来修正测量距离。

很多刚做 ToF 项目的朋友只做了第一层标定就上产线测尺寸，结果发现测量值总是偏离真值 1-2 毫米，怎么调都不对。这就是忽略了深度误差补偿标定。

4.2 内参标定的实操流程

先说内参标定的流程，和我推荐的参数设置。

1. 准备一个高精度棋盘格或者 ChArUco 标定板，建议使用玻璃基板或者铝基板，保证平面的平整度。
2. 用 ToF 相机采集不同角度、不同距离、不同姿态的标定板图像，半分钟左右，不少于 20 张。如果是工业场景，建议同时在目标工作距离附近多采一些图像。
3. 在标定时，不仅要使用 IR 图，还要使用深度图。因为 ToF 相机的深度图分辨率通常低于 RGB 图，如果你只用 IR 图做角点检测，得到的内参可能和实际深度图材质不完全匹配。
4. 把检测到的角点输入到 OpenCV 或者相机厂商标定工具中，计算 fx、fy、cx、cy 和畸变系数。

这里有个很多新手会忽略的问题：标定板本身的精度。你可能从网上下载一张棋盘格图片然后打印出来贴到纸板上，这在消费级验证没问题，但用于毫米级测量项目，打印误差和纸张热胀冷缩就可能引入 1% 以上的误差。工业场景建议直接购买玻璃基板或者陶瓷标定板，精度控制在 0.01mm 以内。

4.3 外参、手眼标定和多机协同

如果你的 ToF 相机需要装到机械臂上，只做内参就远远不够了。你还需要知道相机坐标系和机械臂末端坐标系之间的相对位置关系，这就是手眼标定的活。

手眼标定分两种：一种是相机固定在一个位置，机械臂移动到相机视野里的多个位置，求解相机与基座的变换关系，即 Eye-to-Hand；一种是相机固定在机械臂末端，随机械臂运动，求解相机与机械臂末端的变换关系，即 Eye-in-Hand。ToF 相机在这种标定中的优势是它有深度信息，可以直接利用深度图对目标物体的中心点进行粗定位，再转化为像素坐标，鲁棒性比单纯的 2D 手眼标定好很多。

多机协同的情况，比如一个工位装了三台 ToF 相机，各自负责一块区域，最后要把三块点云拼到一起。这种场景除了各个相机的内外参之外，最麻烦的其实是视场重叠区域的数据一致性。三台相机对同一个物体测出的深度值，如果差别在 5mm 以上，拼接后点云会看起来像“撕开”了一样。解决办法一般是在重叠区域放置标定球或标定板，对深度偏差做二次校正。

4.4 标定最容易踩的坑

我不敢说自己是标定大师，但确实在这上面摔过不少跤，把最典型的几个坑列出来：

第一，标定板照明不均匀。强光环境下标定板部分区域过曝，角点检测跑飞，标定结果必然不可靠。标定场景尽量使用均匀的环境光。

第二，标定距离和实际工作距离差距过大。如果你的相机实际工作距离是 2 米，但标定距离基本都集中在 0.5 米，这个内参在 2 米处不一定准确。建议标定时把你的目标工作距离作为中心距离。

第三，忽略温度。很多 ToF 相机在刚开机时 sensor 温度还没稳定，深度值会缓慢变化。标定前一定要让相机开机预热至少 20 分钟再开始。

第四，使用“不合格”的角点。双目相机的标定我们有剔除不合格角点的操作，ToF 标定也应该加这一步。检测角点后要检查重投影误差，误差异常大的帧直接丢弃，不要强行纳入优化。

5. 上层应用：点云处理与场景落地

5.1 从深度图到点云：一个数学公式的事

当深度图已经拿到手，下一步通常是把深度图转换成点云。这个过程需要用到内参。公式非常简单，对于像素坐标 (u, v)，深度值 z，对应的相机坐标系三维坐标是：

X = (u - cx) × z / fx Y = (v - cy) × z / fy Z = z

如果你在用 OpenCV 或者 PCL 处理，这个过程可以直接用相机内参矩阵完成。写成 Python 伪代码就是：

import numpy as np def depth_to_pointcloud(depth_img, fx, fy, cx, cy, scale=1000.0): h, w = depth_img.shape v, u = np.mgrid[0:h, 0:w] z = depth_img / scale # 如果深度图单位是 mm，转换成 m x = (u - cx) * z / fx y = (v - cy) * z / fy points = np.stack([x, y, z], axis=-1).reshape(-1, 3) # 去掉 z <= 0 或者置信度低的点 valid = z.reshape(-1) > 0 return points[valid]

很多 SDK 已经提供了现成的点云转换接口，但我还是建议理解一下这个公式，因为实际项目里当你需要做“像素坐标和三维坐标互转”时，比如机械臂抓取时把目标在图像中的像素位置换算成机器人坐标系下的位置，这个公式就是基础。

5.2 点云处理的几个标准动作

拿到点云之后，你面临的第一个问题永远是“数据太脏”。

实践中我习惯把点云处理流程固定成这么几步：

1. 直通滤波。先根据实际工作距离，把无效范围的深度直接切掉。比如相机装在机械臂上方 2 米，那 2.5 米以外的点根本不需要，直接忽略，节省计算资源。
2. 统计滤波。ToF 点云里有零星飞点，用 PCL 的StatisticalOutlierRemoval做邻域距离统计，把偏离局部平均值太远的点给滤掉。
3. 体素降采样。640×480 分辨率的深度图转出来有超过 30 万个点，后续算法跑起来压力不小。用体素滤波器对空间内的点做合并，在不损失精确度的前提下大幅减少点云数量。
4. 平面分割 / 欧式聚类。用 RANSAC 拟合平面或者用欧式距离做聚类，把目标和背景分开。

以上步骤用 PCL 或 Open3D 都能比较方便地实现，关键是把参数调好。比如StatisticalOutlierRemoval的meanK和stddevMulThresh参数直接影响边缘保留效果，为了追求滤得干净而把参数调得太狠，会把物体表面的真实细节也磨平，这在精密测量场景里是致命的。

5.3 应用场景一：尺寸测量

ToF 相机做尺寸测量是一个看起来简单、实际上抠细节的需求。热搜词里“C# 如何使用相机拍照判断物品尺寸”差不多就是这个场景。

我做过一个快递包裹体积测量的原型，采用的方案是深度图加上 RGB 图结合。ToF 负责获取包裹顶面点云，RGB 负责识别包裹边缘，两者做像素级对齐后，在深度图上提取包裹边缘对应的深度值，再映射到三维空间里计算出长宽高。

这里最核心的难题是：包裹边缘在深度图上和背景粘连在一起，很难用阈值分割干净。后面换成了高对比度背景板，把包裹放在白色平台上的黑色垫板上，再用形态学提取，问题迎刃而解。做测量项目，环境改造往往比算法优化更立竿见影。

测量精度这块要知道 ToF 的理论极限。一个 640×480 分辨率的 ToF 相机，水平视场角 70 度，工作距离 1 米时，每个像素对应的空间尺寸大约是：

水平方向像素尺寸 ≈ 2 × 1m × tan(70°/2) / 640 ≈ 1.7 mm

这决定了你用 ToF 做高精度测量时的“下限”。如果客户要求测量精度是 ±1mm，那这台相机在 1 米工作距离下先天就不够。选型时一定要先按视场角和像素数反推一下每个像素的现实尺寸，别等方案做完了才发现物理分辨率根本达不到。

5.4 应用场景二：AGV 避障与机器人抓取

AGV 避障是 ToF 的另一个经典落地场景，尤其是室内仓储物流。

传统 AGV 用 2D 激光雷达只能扫描一个平面，遇到悬空物体、低矮障碍或者形状不规则的货物容易漏检。ToF 相机可以覆盖一个视场角的立体空间，把上方悬垂的托盘叉齿、货架横梁这些 2D 雷达“看不见”的障碍都识别出来。

在机器人抓取场景，ToF 的价值在于可以直接输出目标的三维位姿估计。比如料箱抓取，ToF 相机从斜上方安装，点云分割之后用平面拟合找到料箱内物料的最高点，引导机械臂做抓取规划。dToF 和 iToF 在这个场景里的差别主要体现在距离和响应速度上，近距离（1.5 米以内）iToF 完全够用，远距离堆垛建议用 dToF。

5.5 系统的性能优化：线程模型和 GPU 加速

ToF 上层应用不是只跑一个算法就完事，它通常是一个多线程系统。我的经验是至少分三个线程：

1. 采集线程：负责从相机 SDK 取原始帧，不参与计算，只做数据搬运。
2. 处理线程：负责深度重建、点云生成和基础滤波。
3. 应用线程：负责业务逻辑，比如尺寸计算、目标识别、机械臂通信。

三个线程之间用循环缓冲区连接，避免互相阻塞。为什么要这样设计？因为相机采集是有固定帧率的，如果采集线程和处理线程耦合在一起，一旦处理耗时超过一个帧周期，采集线程就会阻塞，轻则掉帧，重则触发 SDK 内部超时断开。

深度重建和点云转换这类计算是天然的并行任务，用 GPU 加速通常能达到十几倍的性能提升。现在很多相机 SDK 也提供了 CUDA 版本的深度重建模块，项目初期就应该确认 SDK 是否支持 GPU 加速，这决定了你后面对硬件平台的选择。如果你用的是 NVIDIA Jetson 系列的嵌入式平台，通常可以发挥出比普通主机更好的性能。

6. 实操中遇到的问题和排查方法

6.1 常见故障速查：先看表象，再猜病因

做 ToF 项目这几年，最常被问到的问题就是“深度图出现了一堆奇怪的噪声”。这种问题单靠口头描述很难定位，建议团队内部建一个故障现象和排查方向的对照表。我自己常用的是这一版：

这张表不是什么高深理论，但能帮团队在出现问题的时候快速划定范围，减少大量无效排查时间。

6.2 温度和时间的漂移：ToF 的慢性病

ToF 相机的深度精度会随着时间缓慢变化，这个现象在刚开机和长时间工作后尤其明显。

我做过一个实验：让一台 iToF 相机持续工作两个小时，每隔十分钟记录一次对固定平面的测距结果。结果发现，刚开机的前 20 分钟，测量值会以可见的速度漂移，累计误差最大可以达到 15mm；工作一小时之后趋于稳定，但和环境温度仍然有线性关系。

所以有两条很实际的经验：

第一，产线或者机器人的 ToF 相机不要频繁断电重启，保持持续上电工作，让相机处于热稳定状态。常电常开是保证精度的最简单手段。

第二，如果项目对精度要求苛刻，建议在相机旁放一个温度传感器，建立“温度 - 深度偏移”的补偿模型，用软件把温度误差实时补偿掉。很多工业 ToF 相机已经在 firmware 层做了温补，但消费级相机通常没有，需要应用层自己处理。

6.3 多机互扰：多台 ToF 相机一起工作时的“串扰”

同一空间里有多台 ToF 相机同时工作，它们发射的红外光会互相干扰。如果你 A 相机的发射光被 B 相机接收到了，B 相机的深度图会出现周期性的噪声带或者点云漂移。

解决思路主要有这么几种：

1. 时分复用：让多台相机分时曝光，你拍的时候我休息，我拍的时候你休息。商务上叫做“帧同步”。
2. 频分复用：不同相机使用不同的调制频率，彼此错开。这个方案对 iToF 有效，但需要相机支持多组调制频率配置。
3. 码分复用：给每个相机分配不同的调制码型，在这个场景下比较少见。

我实际做过的项目里，最常见且稳的方案是时分复用。用外部触发信号把所有相机的曝光时间对齐，然后顺序错开。比如三台相机各占 90° 的相位窗口，轮流拍摄，这样数据不会互相污染。缺点是总帧率会被分割成原来的 1/3，但对于很多静态或者慢速场景，10fps 完全够用。

6.4 案例复盘：一次机械臂抓取的深度测量问题

说一个我印象很深的项目复盘。

当时是给一条生产线做机械臂无序抓取，用的是 iToF 方案，相机安装在机械臂正上方 1.6 米处。机械臂根据 ToF 点云生成的抓取点去抓料，前期实验室验证一切正常，一上线就频繁抓空。

现象非常诡异：只有机械臂运动到某个特定区域时，点云里的抓取点会发生 2-3cm 的跳变。

排查过程回忆一下：

1. 第一步，关掉机械臂，手动把料箱移动到各个位置，结果是点云数据正常。说明问题出在机械臂运动带来的干扰上。
2. 第二步，开启机械臂但保持静止，点云还是正常。证明不是机械臂底座的震动。
3. 第三步，让机械臂执行大幅度运动，同时观察深度图，发现点云发生周期性波动。用示波器测相机供电，发现电压波形在机械臂运动时出现明显的毛刺。

最终定位：机械臂的驱动器和相机共用了一个 24V 开关电源，机械臂启动时瞬时电流把电压拉低，相机内部供电稳压器来不及响应，导致调制信号质量下降，深度计算出现跳变。

解决办法很简单：相机改用独立电源，数据线保持和动力线分离布线，从此再没出现过问题。

这个案子让我养成了一个习惯：任何 ToF 相关系统，第一件事先把供电拓扑画清楚，把相机和电机、加热器、变频器等大功率器件隔离开。这个小习惯能省下的排查时间，远比想象得多。

一些收尾心得

这篇文章从 ToF 的物理原理一路聊到了上层应用和现场排查。写到最后，还是想留几句个人实际工作中的体感。

第一个体感是，ToF 相机的技术栈非常“交叉”。做硬件的人要懂光学和模拟电路，做驱动的人要懂调制解调和信号处理，做上层应用的人又要懂标定和点云算法。一个项目组如果只由单一背景的人组成，大概率会在跨层问题上卡壳。

第二个体感是，ToF 项目最怕的不是技术难，而是链路太长、问题定位太慢。很多团队喜欢一股脑往上堆最新算法，但其实把基础工作做扎实——供电隔离、温度控制、标定流程、数据质量评估——就已经能解决 80% 的问题。

最后再分享一个小技巧：项目初期不要只看相机 SDK 输出的深度图效果，一定要求把 IR 图和置信度图同时输出出来。深度图看起来光鲜亮丽，不代表数据可靠；IR 图和置信度图才能告诉你真正的物理信噪比是什么水平。光学会看深度图，不算真正会用 ToF 相机。