上个月我把两台 Orbbec 深度相机装到一台移动机器人上一前一后一台做导航避障的环境感知一台做机械臂抓取前的目标测距。我原本预估这件事半天能搞定装 SDK、跑 ROS2 驱动、打开 rviz2 看点云都是熟路。结果从第一台的驱动编译到最后两台同时稳定出图前后花了整整三天。踩过的坑包括 SDK 版本不匹配、udev 权限没配、rviz2 里点云黑屏、两台相机话题互相覆盖甚至还有 USB 带宽把相机干到反复掉线的情况。这篇文章就是一次完整的部署复盘。我会从选型逻辑讲到单设备启动再重点拆解多设备配置的完整链路最后把这段时间遇到的坑和排查思路全部列出来。不管你是刚接触 ROS2 和深度相机的新手还是已经在单台上跑通、正准备接多台相机的开发者这篇都值得你收藏后照着走一遍。1. 为什么最终选了 Orbbec以及 ROS2 部署前要做的选型判断1.1 深度相机三条技术路线里Orbbec 覆盖了哪些做机器人项目选深度相机第一个要搞清楚的问题不是品牌而是技术路线。目前主流深度相机可以粗分成三类结构光、主动立体视觉、ToF。这三类的特性差异直接决定了你后期在 ROS2 里的调参方向。结构光方案在近距离和中距离精度表现不错对纹理不敏感但容易受强光干扰室外基本没法用。主动立体视觉利用红外投影加双目匹配中距离表现较好功耗和算力要求相对适中。ToF 的强项是远距离和动态场景点云质量稳定但分辨率普遍偏低而且多台 ToF 同时工作的时候互相干扰问题很头疼。Orbbec 的产品线恰好三条路线都有覆盖Gemini 系列主要是主动立体视觉Femto 系列是 ToF还有 Dobot 合作款等特殊型号。这意味着你不需要因为项目阶段变化而换 SDK底层都是同一套 OrbbecSDKROS2 驱动包也是同一套。对这个领域的开发来说省掉的迁移成本远比那一两千块的差价值钱。1.2 SDK 开源程度和官方 ROS2 驱动才是真正的决策点硬件参数之外我更看重 SDK 和驱动的成熟度。OrbbecSDK 是跨平台闭源二进制加公开 API 的形式但对用户来说和开源基本没区别因为你要关心的是能不能拿到稳定的深度流、彩色流、IMU 数据以及官方有没有维护一个能直接用的 ROS2 驱动仓库。它能短期跑通的关键原因是官方提供了orbbec_ros2这个驱动包。你在 GitHub 上找到OrbbecSDK_ROS2仓库拉到 ROS2 工作空间编译后直接ros2 launch orbbec_camera orbbec_camera.launch.py就能出图像不需要自己写相机驱动和话题转换层。省掉的那些工作量如果从零手写真的是按周计算的。1.3 什么情况下我不建议你选 Orbbec说点反方向的判断。如果你的项目明确需要超远距离 outdoor 场景或者你团队对 depth 后处理有非常深度的自研需求那别选消费级深度相机不管是不是 Orbbec都应该考虑 LiDAR 加相机融合的方案。Orbbec 这类深度相机的强项是中近距离高精度深度感知不是替代激光雷达。另外如果你的系统里已经重度依赖某个其他相机品牌的自研算法库并且项目周期很紧那也别临时换品牌。工具链迁移是有隐性成本的模型、标定、滤镜处理都要重新适配。我这次选择 Orbbec 是因为项目从零开始没有历史包袱可以直接按“多设备 ROS2 官方驱动”这条路走。2. 部署第一关OrbbecSDK 与 orbbec_ros2 的编译和权限配置2.1 环境版本匹配Ubuntu 22.04 ROS2 Humble SDK v2.xROS2 的发行版和相机 SDK 之间没有强绑定但为了让驱动包编译省心我建议你用当前主流的组合Ubuntu 22.04 配 ROS2 HumbleOrbbecSDK 直接用 2.x 版本。我第一次在这里就踩了坑。机器上之前装了 ROS2 Foxy直接拿 foxy 分支的驱动去编译结果 CMake 报了一堆依赖问题。并不是说 Foxy 完全不能跑而是 orbbec_camera 的较新版本代码里用了不少较新的 ROS2 API老版本兼容性并不好。如果你没有特别的发行版要求直接上 Humble这是目前社区测试最充分的组合。如果你还没装 ROS2我建议直接跟官方安装文档走Ubuntu 22.04 对应 Rolling/Robot 的教程即可。现在也有人用一键安装脚本那个脚本确实方便但你要注意它只负责把 ROS2 装好相机 SDK、udev 规则、驱动编译这一步还是得自己动手这篇文章后续内容可以无缝衔接。2.2 源码编译的完整步骤和三个容易卡住的点初始化工作空间和拉取驱动仓库mkdir -p ~/orbbec_ws/src cd ~/orbbec_ws/src git clone https://github.com/orbbec/OrbbecSDK_ROS2.git cd OrbbecSDK_ROS2 git submodule update --init --recursive先别急着 colcon build先把系统依赖装齐sudo apt update sudo apt install cmake libglfw3-dev libopencv-dev libeigen3-dev然后回到工作空间编译cd ~/orbbec_ws source /opt/ros/humble/setup.bash colcon build --symlink-install --cmake-args -DCMAKE_BUILD_TYPERelease source install/setup.bash这里面有三个卡点我必须说清楚。第一个是子模块拉取。OrbbecSDK_ROS2依赖OrbbecSDK作为子模块如果你只执行了 git clone 而没执行git submodule update --init --recursive编译到一半会找不到 SDK 头文件。我后来习惯把两条命令写在一起避免第二次忘记。第二个是 OpenCV 版本冲突。系统里如果同时装了 ROS2 Desktop 自带的 OpenCV 和你自己 apt 装的 OpenCVCMake 在找库的时候可能串。表现就是编译到图像转换模块时报找不到 cv_bridge 的相关符号。解决办法很简单确认当前环境只保留一个 OpenCV 来源最稳妥的方式是只靠 ROS2 Desktop 自带的那套。第三个是colcon build的参数不要乱调。--symlink-install是建议加上的不然你改 Python launch 文件要重新 build。--cmake-args -DCMAKE_BUILD_TYPERelease是优化用的Release 模式下的点云处理性能明显更好。不要加--cmake-clean-cache这种会反复全量重编的选项除非确认有缓存问题。2.3 udev 权限没配好之前一切“无法打开设备”都从这里查Linux 下访问 USB 设备需要权限深度相机这种多接口设备尤其容易踩。如果你插上相机后用lsusb能看到设备但启动节点时报failed to open device或者DeviceNotFound第一反应不是去查代码而是查 udev 规则。驱动仓库里带了安装脚本cd ~/orbbec_ws/src/OrbbecSDK_ROS2 bash scripts/install_udev_rules.sh执行完重新插拔相机。如果你的系统上没有这个脚本也可以手动创建/etc/udev/rules.d/99-orbbec.rules内容按 Orbbec 的 USB Vendor ID 匹配SUBSYSTEMusb, ATTR{idVendor}2bc5, MODE:06662bc5是 Orbbec 的设备厂商 ID。这里有个细节MODE:0666表示给普通用户读写权限避免每次都得 sudo 运行节点。这个规则对多设备同样适用因为所有 Orbbec 设备共用 Vendor ID你不需要为每台设备单独写一条规则。配置完成后用ros2 launch orbbec_camera orbbec_camera.launch.py启动理论上就已经可以出图了。但是先别急着看画面先用官方 Orbbec Viewer 做一次硬件自检。2.4 为什么先跑一遍 Orbbec Viewer 而不是直接进 rviz2OrbbecSDK 自带的 Viewer 工具OrbbecViewer是排查硬件问题的第一现场。它能直接显示深度图、彩色图、点云还能看到相机固件版本、序列号、USB 连接类型。我的建议是在 ROS2 里做任何排查之前先用 Viewer 确认相机本身是好的、参数是合理的。如果在 Viewer 里就花屏、黑屏、点云断层那大概率是硬件、USB 线或者供电问题别浪费时间去调 ROS2 参数。这一步还能帮你确认相机固件版本。有时候你在 ROS2 里遇到帧率不稳、设备掉线最后发现是固件版本太低官方在新固件里修了 USB 兼容性问题。Viewer 里把固件升到当前版本ROS2 侧的问题可能就消失了一半。3. 单相机联调从话题结构到 rviz2 里看到靠谱点云3.1 启动相机节点后应该看到哪些话题单设备启动成功后先别急着开 rviz2花两分钟看一眼话题结构ros2 topic list正常情况下你会看到一组以/camera开头的话题核心的有/camera/color/image_raw彩色图/camera/depth/image_raw深度图/camera/depth/color/points对齐到彩色坐标系后的点云/camera/depth/points原始深度坐标系下的点云/camera/color/camera_info彩色相机内参/camera/depth/camera_info深度相机内参这里我要强调一个容易误解的地方/camera/depth/points是原始深度坐标系点云单位是毫米坐标系是深度相机本身。/camera/depth/color/points是深度图对齐到彩色图之后输出的点云坐标系变成了彩色相机坐标系。大多数场景你用的是后者因为它的每个点能和彩色像素一一对应方便后面的目标检测和位姿估计。用下面的命令查看某个话题的帧率ros2 topic hz /camera/color/image_raw如果彩色图和深度图帧率都接近设定值说明链路是通的。3.2 rviz2 里点云黑屏八成是 QoS 不匹配而不是设备问题到了 rviz2 这一步新手最容易卡死。启动 rviz2rviz2然后按下面的顺序添加点云显示左侧Displays面板点Add选择By topic点开/camera/depth/color/points对应的PointCloud2点击OK把左侧Fixed Frame从默认的map改成camera_depth_frame或camera_link如果你按这个流程做完画面还是一片黑别急着怀疑相机坏了先检查 QoS。深度相机的图像话题默认使用SensorDataQoS也就是 Best Effort 可靠性加 KeepLast 深度 5。而 rviz2 的默认订阅策略是 Reliable这两者匹配不上rviz2 就收不到数据画面自然空白。解决办法是在 rviz2 左侧Displays面板展开PointCloud2这一项找到Reliability Policy把它从Reliable改成Best Effort。改完瞬间点云就出来了。这个坑几乎每个人都会遇到但很少有人第一次就知道原因。有时候你会看到点云出来了但图像的坐标系不对点云整个飘在一边。那多半是Fixed Frame没有设置成相机输出的 frame_id。用ros2 topic echo /camera/depth/color/points --once | grep frame_id看一眼实际的坐标系名字填进去就行。3.3 深度图看起来像噪声点云像筛子不一定是坏了很多人第一次看到深度相机的原始输出都会怀疑设备质量问题。我实话说这个观感在主动立体视觉方案里非常正常。深度图在 ROS2 里以uint16的毫米值存储直接可视化就是一片黑或者一片灰你需要做归一化或者伪彩色才能看到层次感。这不是设备坏了是显示方式的问题。点云看起来像筛子则是因为结构光和主动立体视觉在某些表面黑色吸光物体、反光金属、透明玻璃上无法计算出有效深度这些区域会变成空洞。做项目的时候要习惯这个物理限制。如果你的抓取场景里大量出现黑色物体和反光表面需要额外考虑加一个补光或者换 ToF 方案。这不是软件能完全解决的问题。3.4 点云对齐align_to_color 为什么常常是必选项在机械臂抓取、目标识别这类场景里你通常希望每个深度点都有对应的彩色像素方便训练好的模型直接输出 2D 框再结合深度算出 3D 位置。这时候就必须把深度图对齐到彩色坐标系。启动时加上ros2 launch orbbec_camera orbbec_camera.launch.py align_to_color:true enable_point_cloud:true对齐之后的点云在那个带color字段的话题里发布。要注意的点是对齐操作会占用一定 CPU 资源如果主控板算力一般对齐后的帧率可能比原始深度图低。我实测在工控机上同时开对齐和点云发布CPU 占用会明显上升。具体数值取决于分辨率和帧率但你别指望它零成本。3.5 单相机跑通后立刻把相机序列号记下来这一步是为多设备配置提前做的准备。在终端执行ros2 run orbbec_camera list_devices_node或者直接打开 Orbbec Viewer 在设备信息页找到序列号。我强烈建议你把每台相机的序列号用标签纸写下来贴在机身上。后面多设备配置全靠序列号区分你不想每次拔插之后都在一堆设备里靠猜来找哪台是哪台。4. 多设备配置实战从两台相机互相打架到稳定同跑4.1 直接插两台会发生什么我一开始以为多设备就是插上两根 USB 线的事结果两台相机同时上电后第二种相机启动时就报设备打开失败之后话题互相覆盖rviz2 里看到的点云一会儿是一号机的一会儿是二号机的完全是灾难现场。问题出在两个层面。第一个是设备枚举冲突驱动节点如果不指定序列号会默认打开“第一个”找到的设备两台都这样干就互相抢。第二个是话题冲突两个节点发布的是相同的话题名ROS2 没有自动去重你订阅一次窗口收到的是两台相机数据的混合点云自然乱套。4.2 用 serial_number 做设备级隔离解决这个问题的第一把钥匙是让每个节点显式指定自己该打开的相机序列号。比如一号相机序列号假设是A1B2C3二号是D4E5F6分别启动ros2 launch orbbec_camera orbbec_camera.launch.py \ serial_number:A1B2C3 \ camera_name:front \ depth_fps:10 color_fps:10 \ enable_point_cloud:true align_to_color:true ros2 launch orbbec_camera orbbec_camera.launch.py \ serial_number:D4E5F6 \ camera_name:down \ depth_fps:10 color_fps:10 \ enable_point_cloud:true align_to_color:true这里有两个关键参数一定要理解它的作用而不是照抄。serial_number决定了这个 ROS2 节点打开哪台物理相机。即使两台相机是同一型号只要序列号不同就能精准区分。camera_name决定了这个话题在 ROS2 里的名字前缀。官方驱动的逻辑是话题名带camera_name这个前缀所以一号设为front二号设为down最终你会得到/front/camera/color/image_raw和/down/camera/color/image_raw这样两组完全独立的话题互不干扰。4.3 用一份 launch 文件同时拉起多台相机实际项目中你不会想在终端里手动开两个 launch 窗口更好的做法是写一个自定义 launch 文件把多个orbbec_camera_node节点放到同一个进程组或者不同 namespace 下。以 Python launch 文件为例from launch import LaunchDescription from launch_ros.actions import Node def generate_launch_description(): return LaunchDescription([ Node( packageorbbec_camera, executableorbbec_camera_node, namefront_camera, namespacefront, parameters[{ serial_number: A1B2C3, camera_name: front, depth_fps: 10, color_fps: 10, enable_point_cloud: True, align_to_color: True, }], ), Node( packageorbbec_camera, executableorbbec_camera_node, namedown_camera, namespacedown, parameters[{ serial_number: D4E5F6, camera_name: down, depth_fps: 10, color_fps: 10, enable_point_cloud: True, align_to_color: True, }], ), ])保存成dual_camera.launch.py后执行ros2 launch dual_camera.launch.py这样两个节点同时启动话题天然隔离在front和down两个 namespace 下后面的视觉处理节点也可以分别订阅不用做任何话题重映射。有一点要提醒serial_number如果你不确定当前相机序列号可以在终端里先运行ros2 run orbbec_camera list_devices_node它会枚举所有接入的相机和序列号。实际项目中我会建议把序列号写到配置参数文件里而不是硬编码在 launch 文件因为换相机后不用改 launch。4.4 多相机时间戳同步一个值得单独处理的问题当两台相机都是结构光或主动立体视觉方案时它们各自独立曝光时间戳之间会有随机的相位差。如果你的应用只是分别处理两路点云这个差异可以忽略。但只要你想把两路点云融合到一个坐标系或者在同一时间片里做多视角匹配时间戳不同步就会导致点云错位。Orbbec 在部分型号上提供了帧同步能力硬件上可以通过同步线连接相机软件上也可以通过 SDK 的多设备同步模式实现。在 ROS2 驱动里需要在 launch 参数里开启frame_sync之类的选项具体参数名称和型号支持程度建议你查看当前固件对应的官方文档。如果你不想依赖硬件同步工程上退而求其次的做法是降低对严格同步的要求用最近邻时间戳匹配。简单说订阅两路点云各自保留最近几帧当系统需要融合时找出时间戳最接近的那一对。这个办法在帧率 10Hz、物体运动不太快的时候实测够用。4.5 多设备验证怎么看两台是不是真的同时在工作启动多设备 launch 后我习惯做三件事验证。第一件是ros2 topic list | grep camera确认存在/front/camera/...和/down/camera/...两组话题。第二件是同时订阅两路的图像话题确认两边都有数据到达ros2 topic hz /front/camera/color/image_raw ros2 topic hz /down/camera/color/image_raw第三件是开 rviz2把 Fixed Frame 设为一个公共坐标系然后分别添加两路 PointCloud2确认两片点云同时显示且相对位置符合你安装相机时的物理布局。这一步做完多设备配置才算真正跑通。5. 多设备稳定运行绕不开的带宽、帧率和系统资源问题5.1 USB 控制器拓扑为什么两台相机不能都插前面板多台深度相机同时工作的隐藏瓶颈是 USB 带宽不是 CPU。深度相机输出的是原始数据量很大的图像流1080p 彩色图加深度图 30fps 时单台相机就需要占用大量 USB 带宽。两台相机如果接在同一个 USB 控制器下的同一个 Hub 上带宽就会互相挤占表现是帧率骤降、图像花屏、设备偶尔掉线重连。用lsusb -t可以查看当前 USB 设备的树状拓扑能看到每台相机挂在哪个控制器和哪个端口下。理想情况是两台相机分别接在不同的 USB 控制器上比如主板原生 USB 口一个接前面板、一个接后面板或者干脆买一块 PCIe USB 3.0 扩展卡一卡一个控制器互不干扰。这里有一个很反直觉的点如果你用的是一个外置 USB Hub哪怕 Hub 是 USB 3.0 的两台相机同时插在上面也容易出问题因为 Hub 本身的上行带宽是共享的。多设备场景我一般建议每条相机线都直接走独立控制器不要贪图理线方便而全部塞进一个 Hub。5.2 帧率、分辨率和点云体量先从参数上做减法如果你的机器人主控是一块普通工控机那么全分辨率、全帧率、两路对齐点云同时跑CPU 和带宽都很容易被拉满。实际项目中我建议先算一笔账你的视觉任务需要多高的点云密度和频率导航避障的话深度图降为 640x480、帧率 10fps 通常够用点云没必要对齐到彩色直接用原始深度点云即可能省一大截带宽。机械臂抓取如果只关注工作台上的目标可以把彩色图降到 1280x720深度图保持 10fps。在 launch 参数里改color_fps、depth_fps、depth_mode就行。我实测下来两台相机都跑 640x48010fps、开点云但不对齐CPU 占用在 20% 以下如果两台都跑 1080p30fps 且对齐彩色CPU 能冲到 60% 以上。这个差距在实车上是致命的。5.3 QoS 策略和回调组ROS2 数据通道里两个容易被忽视的细节很多人在单相机上不会遇到 QoS 问题因为 rviz2 里手动选一下 Best Effort 就解决了。但到了多设备加下游处理节点的场景QoS 就必须认真设计。我的建议是所有相机图像话题的发发布方用默认的 SensorDataQoS订阅方统一用 Best Effort。如果你下游有一个自定义点云处理节点请在创建订阅时显式设置 QoS不要用默认的 Reliable。否则你的处理节点会一直在空转等数据表面上没有报错实际没有任何点云进来。另一个细节是 ROS2 的 callback group。如果你的相机节点里同时注册了图像回调、IMU 回调和一些服务回调默认它们可能被放在同一个单线程执行器里某个耗时的回调会把其他回调阻塞掉表现出来就是点云帧率低、IMU 数据延迟大。我习惯在写多设备快应用时为自己处理的节点配置多线程执行器并把数据密集型回调放到独立的 callback group 里。这个机制对新手有点绕但它是 ROS2 上做多路传感器融合时保证实时性的基本盘。5.4 供电和线缆掉线问题里最容易被忽视的真凶多相机联调中遇到设备随机掉线很多人会先怀疑驱动和代码但我后来发现供电和线缆因素占比非常高。深度相机启动瞬间电流很大普通 USB 口供电不稳会导致设备重启或枚举失败。解决方案并不复杂优先使用有外部供电的 USB Hub 或带供电的扩展卡保证每台相机都能拿到稳定电流。线缆也要注意长度超过一米后尽量选带屏蔽的 USB 3.0 线并且不要和电机驱动线、大电流电源线扎在一起。之前我有一台相机总是隔几分钟掉线一次最后发现是线缆经过电机驱动模块旁边电磁干扰导致 USB 链路重置。6. 从单机显示到机器人应用数据流的规划和其他扩展玩法6.1 namespace 和 TF 设计多相机系统的坐标系规划如果你只是想在 rviz2 里看看点云namespace 不规划也无所谓。但接入导航、机械臂等真实机器人系统时TF 树的规划必须提前想好。我这次是前视相机加俯视相机的组合。前视相机装在底盘前方俯视相机装在机械臂工作台正上方。我建议把所有相机的位置关系严格建模到 TF 里一个base_link作为机器人本体的根坐标系前视相机的位置变换为base_link - front_camera_link俯视相机为base_link - down_camera_link。相机驱动发布点云时把点云的 frame_id 设置成对应的相机坐标系。这样下游节点只需要查询 TF就能把两路点云变换到base_link下合并不需要硬编码任何相机安装位置。否则每次挪动相机位置你都要改一遍代码。6.2 点云进入八叉树地图和导航之前要做一次降采样把 Orbbec 点云直接丢给 octomap_server 这类八叉树建图节点是能跑但实际效果很一般。深度相机原始点云密度高、噪声多直接构建八叉树会得到一张表面上有大量杂散点的地图。更实际的做法是在点云进入建图节点之前先过一次降采样和滤波。在 ROS2 里可以用 PCL 的 VoxelGrid 把点云降采样到 2cm 或 3cm 体素再用 StatisticalOutlierRemoval 滤一遍离群点。这样 octomap 的地图质量会好看很多导航的代价地图也不会被 ICL 反射出的飞点干扰。如果你的导航框架只需要平面障碍物信息也可以不用完整三维点云而把深度相机的点云投影成 2D 障碍物栅格直接灌进 costmap。这样计算量更小。具体走哪条路取决于你是不是真的需要三维地图信息。6.3 机械臂抓取场景从彩色框到三维坐标的完整链路前面我说了俯视相机做机械臂抓取定位这里展开一下数据流。流程是彩色图送进目标检测模型模型输出目标在 2D 图像上的框然后用深度图像上对应区域的中值深度还原出目标在相机坐标系下的三维位置最后通过 TF 变换到机械臂基座坐标系。这个链路里最容易出问题的就是用哪个点云和怎么取深度。我强烈建议你使用对齐到彩色之后的点云/camera/depth/color/points这样 2D 像素和 3D 点一一对应直接用像素坐标索引点云即可不需要自己做外参标定对齐。如果你只是想把深度相机作为机械臂的眼睛别去碰原始非对齐点云太折腾。6.4 关于零拷贝和进程内通信值不值得折腾ROS2 的零拷贝和 intra-process 通信经常被提起但在深度相机场景我要泼一点冷水零拷贝主要解决的是同一个进程内部多个节点之间传递大数据时的拷贝开销而相机驱动进程和你的处理进程通常是两个独立进程跨进程通信用不上 Intra-Process Manager 那一套。如果你的视觉处理节点和相机驱动可以在同一个执行进程里跑那开 intra-process 确实能有效降低 CPU 占用点云这种大消息受益尤其明显。但换来的是模块耦合度变高进程重启隔离变差。对于项目初期我建议先老老实实走跨进程通信跑通全链路后再考虑把数据处理节点和相机节点塞进同一进程做优化。学会跑之前不要先想着飞。6.5 有现成轮子就别重复造社区仓库和文档怎么用Orbbec 的 GitHub 组织下有 SDK 仓库、ROS2 驱动仓库还有各型号的示例代码。我的建议是遇到问题不要直接翻源码先去仓库的 issues 和 discussions 里搜关键词很多型号适配问题别人已经踩过并且给出了 workaround。驱动仓库里的docs目录通常会有相机型号支持的矩阵表格哪些参数、哪些模式在哪个型号上有效一目了然。有些型号的深度模式在 Linux 下的支持和 Windows 不完全相同提前看一眼能省半天时间。7. 排坑清单这次部署遇到的所有问题、原因和解决办法我把这段时间遇到的高频问题整理成一张清单方便你将来直接对症状找方案。症状根因解决办法启动节点报设备打开失败udev 权限未设置执行bash scripts/install_udev_rules.sh后重新插拔rviz2 点云黑屏QoS 不匹配订阅端为 Reliable在 rviz2 中把 Reliability Policy 改为 Best Effort点云位置飞走或不在预期位置Fixed Frame 设置错误改为相机输出的 frame_id如camera_depth_frame两台相机话题互相覆盖camera_name 未隔离launch 中给每台相机设置独立 camera_name 和 namespace两台相机互相抢设备节点未指定 serial_numberlaunch 中显式传入 serial_number帧率提不上去USB 控制器带宽不足两台相机分别接不同 USB 控制器避免共用 Hub设备间歇掉线供电不足或线缆干扰使用带供电的扩展卡/Hub线缆远离电机驱动线点云全是飞点/筛子状高反光或黑色表面物理限制调整视角、增加补光或阈值过滤无效深度编译报找不到 OpenCV 符号系统 OpenCV 与 ROS2 冲突清理额外 OpenCV只用 ROS2 Desktop 自带版本深度图在通用查看器里全黑uint16 毫米单位未归一化用伪彩色 colormap 或归一化显示这张表我建议你直接收藏遇到问题先对号入座再动手排查别一上来就重装系统或重刷固件。排错方法论上我个人的习惯是分层排查。先硬件Viewer 里能不能出图。再中间层SDK 能不能枚举设备。最后 ROS2 层话题有没有数据、QoS 对不对、namespace 是否隔离。按照这个顺序90% 的问题都能快速定位。多台相机的项目尤其要养成这个习惯因为一次同时坏两台相机的概率很低更可能是配置逻辑问题。最后再分享一个经验调试多摄像头系统别在虚拟机里做。USB 直通、USB 控制器规划、带宽测试这些都和宿主机物理环境强相关虚拟机里跑出来的结果没有任何参考价值。另外就是买多台同型号相机的时候第一件事就是拆箱后用 Viewer 把每台序列号记下来贴上标签。你在多设备 launch 文件里写序列号的时候会感谢当初那个多写了几分钟的自己。