从USB相机到边缘立体视觉：Physical AI数据采集架构演进实录

搞机器人和具身智能这一年多团队在Physical AI数据采集上花的功夫比模型调参还多。以前总觉得数据采集就是把相机架上、录出来、存下来直到我们在不同场景跑了两三个项目之后才反应过来物理世界的数据采集不是拍视频是生产能用来训练的“示范动作数据”。也正是在这个阶段我们把方案从一堆USB相机慢慢换成了带边缘算力的立体视觉模块。手边正好在折腾ZED X Nano把自己的思考过程整理出来给同样在做Physical AI数据采集、脑部/腕部视觉方案选型的同行一个参考。1. 从实验室到产线Physical AI数据采集为什么不再依赖USB相机1.1 早期采集系统的“能跑”与“扛不住”先说背景。我们第一版采集系统是典型的“主机多路USB相机”结构工控机里插一张USB3.0的扩展卡机器人的腕部装一个工业USB摄像头桌面旁边再架两个全局快门USB相机分别负责可以看到整个场景的第三人称视角和对应目标物体的特写视角。当时逻辑很简单因为团队最不缺的就是普通USB摄像头USB接口兼容性又好插上就能用SDK成熟甚至不需要专门写采集程序。这套系统在小批量、短周期、动作单一的任务上确实能跑起来。比如一个“抓取-放置”任务我们只需要在固定工位上录2000条数据当时大概折腾了一周半问题不算大。可是后续当任务变成“倒水、分类整理、开瓶盖”这种需要手眼协调、又需要在不同工位间移动的场景时问题开始集中爆发。我先记一下当时最头疼的几个现象四个摄像头同时采集1080p60fps大概带宽快吃满一张USB3.0卡偶尔某个相机会自动断开;到了布置多工位的产线上USB线超过5米要接延长线然后开始丢帧。这些问题不是个例是几乎每轮采集中都会碰到。1.2 USB相机真正的瓶颈带宽、同步、线缆与后处理很多文章一谈USB就被“带宽”两个字带过去但实际踩坑后会发现带宽只是其中最表层的问题。拿1080p RGB图像来说一帧不压缩的RGB888数据大概是1920x1080x3字节约6.2MB60fps下单相机就需要372MB/s左右的吞吐半双工的USB3.0实际有效带宽一般到不了400MB/s单个相机占满之后其他设备就得排队。也就是说一根USB 3.0线在60帧1080p彩色未压缩模式下一个相机的压力都很大更不用说腕部相机加多个全局相机同时跑。真正让USB方案在Physical AI数据采集中难以为继的其实是时间同步。机器人数据采集需要把关节角、力矩、末端速度和图像帧对齐到同一个时间基准否则训练出来的策略在仿真迁移到真机时会有严重的时序错位。USB相机通常靠外部触发线或者软件时间戳来做同步但软件同步的抖动在Windows/Linux非实时系统下经常是几毫秒到十几毫秒而机器人控制周期本身可以到1kHz甚至更高也就是说一个控制循环里图像可能已经滞后了十几帧。对单手抓取这种低速动作可能还能容忍可一旦动作里包含快速插拔、液体倾倒、柔性物体捏取这个抖动就无法接受了。还有一个很少有人提前重视的问题是线缆和接口可靠性。产线上机械臂高速运动腕部相机跟着来回摆动USB线在拖链里反复弯曲半年内断了好几次。更麻烦的是USB线缆超过3米之后信号完整性明显下降我们试过5米延长加带供电的USB hub偶尔会在采集到一半时掉设备重启之后又不一定能枚举上。排查起来极其费时你甚至无法确定是线、口、扩展卡驱动还是供电的问题。后处理开销也是不能忽略的一块。裸流RGB传输到主机后视频编码、压缩、归档全都要吃掉CPU或GPU资源。即便是用RTX 4090解码要同时处理四路1080p视频再叠加机器人的状态数据对数据流水线来说也够忙。如果数据规模到几十万个episode这一步的资源浪费就会被放大得非常明显。所以从本质上说USB相机是一套“把原始图像搬运到主机再处理”的方案它适合开发调试却不适合作为Physical AI数据采集的主力架构。1.3 数据采集不只是“拍照”而是高质量示范数据生产Physical AI的数据采集和传统机器视觉的数据采集有一个本质区别传统视觉采集要的是“图像本身”目标是分类、检测、分割而Physical AI的数据采集尤其是训练操作技能策略时要的是“示范动作的可复现信息”。一个episode通常包含视觉观测、本体感觉观测、动作指令甚至语言指令。策略模型要从这样一组多维度的时序数据中学会状态到动作的映射。也就是说每一帧图像必须和关节反馈真正对齐还必须保证图像覆盖末端操作区域同时尽量减少主机后处理带来的延迟和损失。这时“能拍照”已经远不够采集设备得是一台“能感知、能计算、能同步的传感单元”。也正是从这条思路出发我们开始尝试把感知计算下放到靠近执行器的地方于是腕部视觉模块逐渐代替了那些USB摄像头。2. 腕部视觉的需求倒逼传感架构演进从“主机看”到“手眼看”2.1 腕部视觉对硬件的苛刻要求把相机固定在机械臂末端在机器人学术圈一直叫eye-in-hand构型中文语境里有人叫腕部视觉有人叫末端视觉。这两年因为“数据采集热”我们更常叫它“手眼”或“腕部第一人称视角”。这个安装位置天然对硬件提出了几个USB相机特别难满足的要求。第一是重量和体积。末端每多100g机械臂的动态特性和安全限速都会受影响尤其在协作臂上非常敏感。USB工业相机加上镜头、沉重外壳重量很难做得轻而且它是“相机本体镜头”的分体结构安装尺寸也不规则蹩手蹩脚。第二是功耗和散热。USB相机设计时基本默认数据流是主机侧解码相机本体做很少的计算一旦要在末端做深度或AI推理发热量就会上来。第三是抗振和连接稳定性。机械臂启停和加减速的冲击很大USB插头在振动中容易接触不良而这个问题的排查又很让人崩溃。还有一个长期被忽视的细节外参稳定性。机械臂UNIX手眼标定做完之后相机相对末端Link的姿态必须保持不变。USB相机如果只是靠一个支架夹住稍微受一点碰撞或者线缆拉扯外参就变了标定全部作废。腕部视觉模块就是为了这个工况设计的一体化外壳、多个定位面、靠谱的安装结构外参稳定性比普通USB相机好一个量级。2.2 ZED X Nano的设计取舍边缘算力与模块化ZED X Nano是Stereolabs在750万像素模块化立体相机这条线上针对边缘AI和机器人场景出的产品。它最大的特点就是把NVIDIA Jetson Orin Nano这颗能在边缘端做深度估计和AI推理的芯片直接放在相机模组内。第一次用的时候我有种很直观的感受它不像是“相机”更像是一个“视觉感知模块”因为它在输出端默认给出的就不是一帧孤零零的RGB图而是带深度、支持AI处理的“感知数据”。这颗Orin Nano能跑实时立体深度估计算法还能跑目标检测、语义分割这类轻量级模型。这意味着很多原本必须在主机上做的计算比如深度图生成、图像校正、神经网络推理现在在相机端就完成了。回传到主机的只是在时间上严格对齐的深度图、RGB图以及AI推理结论。相比USB相机裸流回传主机侧不存在解码瓶颈问题。功耗方面ZED X Nano的整机功耗可以做到很低的水平比“工业USB相机主机GPU做后处理”的模式低得多。低功耗对机械臂末端还有一个隐性的好处末端不容易积热长时间连续采集中也不会因为传感器过热降频。这一点在数据采集车连续跑8小时时格外重要。2.3 生态之外为什么固定基线立体方案适合操作场景腕部视觉如果只用单目彩色图那么在训练策略时通常还要额外估计深度或者仅靠二维像素处理。固定基线的立体相机则直接提供从相机坐标系出发的深度虽然基线短意味着远处深度精度有限但在机械臂末端操作范围内恰好够用。因为这种视觉主要覆盖的是“手面前0.3米到1.5米左右”的操作区域这个距离内立体视觉的深度精度表现出色。另一个好处是时间同步的工程实现路径更完整。ZED X Nano内部自带IMU并且在硬件层面对双目图像、IMU和深度数据做了同步系统对外还提供与UTC时间对应的硬件时间戳。这个设计在构建统一时间基准的采集系统时省了很多功夫不用再手工给图像叠加时间戳。可以说它直接把“多传感器对齐”从一个软件问题降低成一个配置问题。3. 实操记录把ZED X Nano接入我们的采集管线3.1 硬件连接与系统准备我们这套采集系统大致由三台设备组成一台高性能数据采集工作站一个安装到机械臂末端的腕部视觉模块还有一台运行遥操作主手的控制主机。实际操作的时候ZED X Nano通过官方支持的网口方式连接到采集工作站供电和数据走一根线这种连接方式比USB线缆在拖链中的稳定性强很多。虽然它也能提供调试用的USB接口但我们在产线数据采集场景里更信任网口方案毕竟网线在工业场景的部署和维护经验更丰富。系统层面我建议直接用Ubuntu 20.04或22.04NVIDIA驱动版本尽量和官方SDK保持一致。ZED X Nano在Jetson上预置了JetPack环境主机侧安装一下对应的ZED SDK即可。装好后第一件事是用官方工具查看设备健康状态确认双目帧率、IMU频率、温度都正常。这一步别跳过我们第一次因为固件太旧导致时间戳不输出排查了大半天最后才发现升级SDK后还要升级相机固件。3.2 时间同步与多模态数据流对齐Physical AI数据采集系统的核心难题就是怎样把不同传感器的数据流放到同一条时间线上。我们的视觉数据来源包括ZED X Nano的深度、彩色和IMU机器人控制数据来源包括电机关节角、力矩、末端速度遥操作主手还要提供三至六自由度的位姿指令。这几个来源在系统中各自有自己的频率视觉30fpsIMU在我配置下200Hz关节控制1kHz如果每一层时间基准不一致后面对齐就是一场灾难。我们的做法是以ZED X Nano的硬件时间戳为视觉基准然后让机器人控制侧的数据在采集时就打上同一套UTC时间。这样后期可以用线性插值把慢速的视觉数据对齐到高频控制数据上。具体实现中我在机器人状态回调里读取系统单调时钟再把单调时钟换算成UTC视觉SDK拿到的帧得到的是自主时钟对应的UTC两者就可以放到同一个时间轴上。这个链路如果你用的是纯USB方案会麻烦很多因为普通USB相机本身没有高精度硬件时钟你能拿到的只是“接近接收时刻”的软件时间戳抖动完全不可控。在数据流处理上不要图省事直接把图像丢给Python的list再转NumPy大几G的缓存会把内存挤爆。要成熟的做法是边收边写把每一帧图像编码后写入磁盘同时把对应的状态数据写成CSV或JSONL。这样即使半途崩溃已经写入的数据也不会丢失应该说这算我们当时做得比较对的决定之一。3.3 标定从出厂参数到手眼标定ZED X Nano的关键参数在出厂时已经做了标定包括双目内参、畸变系数、外参、IMU到左目的变换。这一步省了不少事用官方工具可以一键获取这几个参数根本不需要自己对着一张棋盘格反复拍。需要特别注意的是ZED SDK升级时相机固件可能会一起升级这时个别标定文件可能被重建或覆盖务必在升级前备份相机标定结果。比较麻烦的是手眼标定。我们的机械臂末端安装了一个法兰转接板视觉模块固定在这个转接板上。理论上要解一个AXXB的方程实际操作中我建议采集多组机械臂末端位姿与相机观测的标定板位姿然后选择支持多姿态求解的开源标定库。如果标定出来重投影误差大于2个像素多半是标定板姿态变化不够大或者机械臂读数本身误差大。我踩过一次坑标定过程中机械臂低速运动视觉模块和支架之间轻微位移结果标定结果多了一个微小的旋转误差。后来我们在所有安装螺丝和接触面贴了防松胶垫外参稳了很多。3.4 数据落盘与数据集格式设计数据落盘格式我们几经改版现在固定为视频流用压缩格式存储深度图用16bit PNGRGB图用JPEG每一条轨迹对应一个文件夹。目录结构类似这样episode_00001/ color_left/ depth_left/ imu.csv robot_state.csv obs_time.csv meta.jsonmeta.json记录任务类型、语言指令、操作员ID、控制器配置等信息。这样做的目的是让数据后续进入训练管线时可以按需读取不必一次性载入内存。ZED X Nano侧输出的彩色图和深度图是自带时间戳的我们按帧序号写入文件后期通过obs_time.csv把机器人状态与图像帧关联起来。这里有一个建议如果你训练的是视觉-语言-动作模型建议你再额外录一段固定频率的全局视角视频用来做回放和筛选。只靠腕部视角会丢掉很多上下文信息比如初始物体摆放、自己手臂的动作对后续判断数据质量很有帮助。ZED X Nano当然不能代替全局相机但它们在系统里负责的职责完全不同。4. 常见问题与排查技巧实录光看宣传材料永远不知道一个硬件在真实采集里会有什么脾性。这里记录几个我们实际遇到并解决的问题也给准备上腕部视觉方案的同行一个速查参考。问题现象可能的根因排查与解决采集一段时间后深度图出现空洞操作距离太近/太远表面反光或透明材质调整安装位置保持操作区域在深度有效范围内透明物体考虑红外结构光方案数据流偶尔掉帧网口带宽不足或交换机丢包改用直连网口确认没有其他设备抢占关闭Wi-Fi省电策略时间戳偶尔跳变系统时间同步漂移部署PTP或定期NTP校准采集前先核对UTC偏差机械臂运动时图像有撕裂卷帘快门效应操作速度放慢或选择全局快门模式ZED X Nano此类模块本身快门特性偏全局化但动态场景仍要留意手眼标定结果重复性差安装松动或标定板姿态变化不充分加固安装采集至少15到20组姿态覆盖不同空间位置和朝向推理模型掉帧/显存不足Orin Nano侧算力被深度估计占满关闭不必要的AI模块只保留立体深度和IMU减少模型输入分辨率另外还有两个经验想单独拿出来说。第一不要为了“省流量”在相机端开太强的H.265压缩。深度图本身对压缩噪声非常敏感如果压缩质量参数太低边缘会出现预测误差。最好是把RGB做适度压缩深度图保持无损16bit PNG或者直接用官方容器格式保存。第二数据采集环境里强烈建议把工控机的CPU调频策略设为性能模式。看似只是一个小参数但采集时线程调度非常看重低延迟政府模式或者平衡模式会导致某些周期任务间歇性卡顿表现出的现象就是视频帧晚到几十毫秒。我们当初就因为Linux默认的调度器配置在长时间采集里遇到间歇性卡顿排查了很久。5. 关于腕部视觉架构演进的一点思考回到最初的问题Physical AI数据采集开始抛弃USB相机本质上不是因为USB接口不好而是因为任务对数据质量、同步稳定性、边缘算力和安装可靠性的要求已经从“能录就行”进化到“能训练可用策略”了。USB相机低成本、低门槛的优势依然存在但它作为一个兼顾高带宽、高同步精度、可嵌入执行器端的感知架构已经触及天花板。ZED X Nano这类带边缘算力的立体视觉模块之所以能在腕部视觉场景里站稳是因为它把深度感知、AI推理、IMU时间同步这些功能集中到一个靠近数据源头的模块里从结构上降低了系统复杂度和主机侧压力。当然它的价格肯定不会比几十块钱的USB摄像头便宜所以选型时还是要看场景如果你做的是低速、离线、固定工位的数据采录USB相机仍然是经济之选但如果你在跑一整条产线或一排机械臂的连续数据采集需要可靠性和时间对齐那这类边缘视觉模块的优势非常明显。我个人在实际操作中的体会是Physical AI的数据采集问题最终都会变成“系统设计问题”。选择哪款相机只是其中一个因素更重要的是想清楚数据的用途、不同传感器的时序关系以及整个流水线的稳定边界。腕部视觉的演进会继续因为末端本身就在变得越来越智能ZED X Nano是个不错的样本但一定不会是终点。