企业官网建设流程全解析

1. 先弄清楚：D435i和ROS2组合到底在解决什么问题

在我开始讲安装步骤之前，先说说我自己的真实经历。最早拿到Intel RealSense D435i的时候，我以为"插上USB、装个官方软件、能出图"就算接进机器人了。结果真正开始做项目才发现，单机演示和把它接进机器人系统完全不是一回事。D435i这颗传感器同时输出RGB彩色图像、深度图和IMU数据，如果数据不经过统一的通信标准封装，后面做视觉抓取、VIO定位、手眼标定每一步都会卡壳。

这里说的"统一封装"，指的就是ROS2环境。RealSense和ROS2的深度集成，说白了就是把相机节点变成整个机器人系统里一个标准化的传感器节点，让其他模块通过话题、服务、TF坐标树去拿数据，而不是各家写各家的SDK。多传感器数据融合更是依赖这套机制——视觉、惯性、里程计、机械臂关节角，每一种传感器都有自己的数据格式和坐标系，只有在ROS2的框架下才能把这些异构数据统一治理起来。

为什么选ROS2而不是ROS1？做了几年机器人的人应该都有体感：ROS1在2025年已经停止维护，新项目没有理由再往旧生态里跳。ROS2的通信基于DDS，分布式部署、服务质量QoS控制、多机协同都是原生能力，而且Humble是当前使用最广的LTS版本，官方支持期很长，社区资料也最全。Intel官方持续维护对应的ROS2功能包realsense-ros，遇到问题基本都能在GitHub Issues里翻到答案。

这篇文章适合谁来读？如果你正准备：

• 把D435i接入自己的ROS2机器人做视觉感知
• 同时用深度图和IMU做数据融合（VIO、EKF定位这类）
• 做机械臂抓取、移动机器人避障、室内三维重建

这篇文章就是按这条完整链路写的。下面所有内容都是我在Ubuntu 22.04 + ROS2 Humble + D435i这套组合上反复试过、验证过的东西。和官方文档最大的区别是，我会把那些官方假设"你应该会"的细节全部拆开讲，包括走不通的路和踩进去的坑。

1.1 D435i的传感器构成与数据特点

D435i能被这么多项目选作感知核心，和它的硬件设计有很大关系。从物理结构上看，它有一颗RGB彩色相机、两颗红外相机和一颗红外点阵投影仪，再叠加一个六轴IMU（三轴陀螺仪+三轴加速度计）。深度原理是主动红外立体视觉：投影仪向场景投射不可见的红外纹理，两颗红外相机通过视差计算深度。这意味着在弱纹理环境里它比被动双目靠谱得多，因为它自己会"打光"。

但主动视觉有主动视觉的脾气。最明显的限制是有效距离，理想工作范围在0.3米到3米左右，太近会过曝，太远则纹理映射精度不够。另一个限制是它对强红外干扰敏感，比如大太阳直射下深度图会出现明显空洞。我最初在落地窗旁的工位上测试，深度图到处是黑色的洞，一度以为是相机坏了，后来拉上窗帘才恢复正常。做融合项目之前先了解传感器的物理边界，能省下后面一大部分排查时间。

1.2 整套系统的数据流与坐标关系

从ROS2的角度看，D435i接入后至少会提供三个维度的数据流：颜色图像（用于视觉识别和纹理映射）、深度图像（用于空间测距和点云重建）、IMU数据（用于运动估计和位姿解算）。而多传感器数据融合的难点不在"同时拿到这些数据"，而在于让它们的时间戳和坐标系严格对齐。

时间戳问题在后面第5章会详细说，这里先用一个生活化的类比帮大家建立概念：相机、IMU、激光雷达就像三个不同语速的人，EKF融合就是让他们在同一个时间轴上开会，谁迟到了就等谁，谁数据跳了就信谁少一点。坐标系则像每个人各自说的"左"和"前"到底指哪里，IMU说的"前"和相机光轴说的"前"可能差着好几个角度，不标定清楚就融合，结果一定是灾难。

2. 环境准备：Ubuntu 22.04装ROS2 Humble的三种方式和我的推荐

2.1 图形化、无桌面还是物理机：先想清楚再动手

很多人一上来就搜"ROS2安装教程"，结果装到一半发现版本不对、源不对、环境变量没配，然后放弃。我给你的第一个建议是先把运行环境想清楚：如果你是在自己电脑上做开发和调试，装带桌面的完整版ROS2 Humble Desktop；如果你是在Jetson这类嵌入式板卡或者服务器上部署，装ros-base核心版就够了，省内存也省磁盘。

另一个更关键的问题是物理机还是虚拟机。我的明确结论是：如果你只学ROS2基本操作、跑小乌龟，虚拟机没问题；但如果你要让D435i出深度图和点云，千万不要在虚拟机里做USB透传。RealSense的深度数据流对USB带宽极其敏感，我试过VMware和VirtualBox各一版，现象都是相机能识别、单帧能出图，但连续跑几十秒就断流，日志里全是libusb传输错误。浪费了一天时间，最后老老实实换到物理机或者用Docker直通镜像，一切正常。

2.2 官方二进制安装：最可靠的方式

我自己最常给朋友推荐的是官方二进制安装。为什么不用源码编译安装ROS2？因为Humble在Ubuntu 22.04上已经发布了官方预编译包，版本稳定、依赖齐全，源码编译除非你有定制中间件或需要给arm64交叉编译的需求，否则纯属自讨苦吃。

官方安装步骤看起来很长，实际拆开就四步：

# 第1步：确保系统UTF-8编码 sudo apt update sudo apt install locales sudo locale-gen en_US en_US.UTF-8 sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 # 第2步：添加ROS2软件源 sudo apt install software-properties-common sudo add-apt-repository universe sudo apt update && sudo apt install curl -y sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null sudo apt update # 第3步：安装ROS2 Humble桌面版（含RViz2、demo、Python客户端库） sudo apt install ros-humble-desktop # 第4步：配置环境变量 echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc source ~/.bashrc

国内网络环境如果拉取官方源太慢，可以把软件源换成中科大或清华的镜像，命令几乎一样，只要把http://packages.ros.org/ros2/ubuntu换成https://mirrors.ustc.edu.cn/ros2/ubuntu，同时保留ROS官方签名密钥即可。我实测下来中科大的同步速度能到几兆每秒，比直连官方源快一个量级。

装完之后顺手装两个高频使用的工具，后面编译realsense-ros会用到：

sudo apt install python3-colcon-common-extensions python3-argcomplete

2.3 鱼香ROS一键安装：适合反复重建环境的人

如果你像我一样经常要在新板卡、新电脑上重搭ROS2环境，或者你是第一次接触Linux终端，对每一条apt命令都小心翼翼，那可以试试鱼香ROS的一键安装脚本。这个脚本在中文社区里流传很广，原理是自动检测系统版本、替你配置软件源和安装参数，交互式选择要安装的ROS2版本和桌面组件。

wget http://fishros.com/install -O fishros && bash fishros

脚本运行后按菜单选择ROS2 Humble Desktop，剩下的交给它跑。它能省掉手动配置locale和软件源的步骤，对于新手来说是最快的路径。我的经验是：一键脚本不是银弹，如果网络不稳定或者系统里已有冲突的软件源，它偶尔会在中间步骤抛错。这时候别慌，看清报错是apt源冲突还是依赖缺失，大部分问题可以通过apt --fix-broken install解决。

三种安装方式我各自的建议是：长期开发主力机用官方二进制，求稳；临时容器测试机用Docker镜像，求快；嵌入式低配板卡用ros-base核心版，求省。脚本方案则作为辅助手段，用在频繁重建的机器上。

2.4 安装验证：别急着装相机，先跑通通信

环境装好后别急着接着装RealSense，先验证ROS2本身没问题。最基础的验证命令是：

ros2 topic list

如果能看到/parameter_events、/rosout这几个默认话题，说明核心服务正常。接着跑官方自带的小乌龟测试：

ros2 run turtlesim turtlesim_node

另开一个终端：

ros2 run turtlesim turtle_teleop_key

能用键盘控制小乌龟动起来，说明话题发布-订阅链路没问题。这一步虽然简单，但能帮你提前筛掉一类常见问题——环境变量没有source，或者.bashrc里重复source导致命令行为异常。很多人在装完所有东西之后才回头排查这种基础问题，反而更浪费时间。

3. 深度相机的SDK：librealsense安装、固件升级与图像验证

3.1 用apt安装librealsense和它的内核模块

librealsense是Intel RealSense的官方SDK，ROS2功能包realsense-ros底层就依赖它。在Ubuntu 22.04上装librealsense最省心的是通过Intel官方的apt仓库。

# 添加Intel的软件源和密钥 sudo mkdir -p /etc/apt/keyrings sudo curl -sSf https://librealsense.intel.com/Debian/librealsense.pgp | sudo tee /etc/apt/keyrings/librealsense.pgp > /dev/null echo "deb [signed-by=/etc/apt/keyrings/librealsense.pgp] https://librealsense.intel.com/Debian/apt-repo $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/librealsense.list sudo apt update # 安装SDK、命令行工具和内核模块 sudo apt install librealsense2-dev librealsense2-utils libreansense2-dkms

注意，librealsense2-dkms这个内核模块非常关键。RealSense的深度相机在Linux下需要内核级USB视频类的补丁支持，dkms会动态编译对应内核模块。如果系统升级内核后没有顺手重新编译dkms模块，插上相机后经常会报Device is in recovery mode之类的问题。装完可以用一条命令确认设备能被正确枚举：

rs-enumerate-devices

能看到设备型号、固件版本、USB接口类型，就说明SDK这层通了。

如果你要在arm64平台（树莓派4、Jetson系列）上使用，Intel官方apt仓库也提供arm64版本，但有些老教程会建议你源码编译，因为早期arm64的预编译包不完整。我的经验是：Ubuntu 22.04 + arm64直接用apt装通常没问题，装完再用rs-enumerate-devices验证，如果缺库再从源码编译不迟。

3.2 realsense-viewer验证三大数据流

安装完成后，打开图形化工具验证一下相机所有数据流是否正常：

realsense-viewer

你的左边列表会出现D435I设备，上方有Stereo Module、RGB Camera、Motion Module三个模块。分别打开：

• Depth流，默认分辨率640x480，看深度图是否连续、边缘是否平滑
• Color流，确认彩色图像没有花屏
• Motion Module里的Gyro和Accelerometer，确认IMU数值会随着你晃动相机发生变化

这一步非常值得做。因为后面接ROS2之后，一旦出现"深度图全黑"或"IMU没数据"的问题，你至少要能够判断是传感器本身的问题还是ROS2配置的问题。我在实际项目中遇到过一次很奇怪的现象：ROS2里IMU话题完全有数据，但数值永远恒定为0，后来在realsense-viewer里看到Motion Module已经报错了，才发现是USB供电不足导致IMU芯片复位。如果你没先验证硬件，这种问题会让你排查很久。

3.3 固件检查与升级：一个容易忽略的稳定性来源

realsense-viewer左侧设备信息栏会显示当前固件版本。Intel官方固件更新页面和SDK会不定期发布新版本，修复IMU漂移、深度精度等问题。我个人的一个实际案例：我手里一批D435i的出厂固件是5.12.x，在ROS2下IMU数据偶发跳变，融合出来的姿态偶尔会突然偏转十几度，升级到5.13.x之后故障消失。如果你的IMU数据有类似问题，第一件事先看固件版本。

升级固件的命令方式：

# 查看当前固件 rs-fw-update -l # 把相机切到升级模式后刷入固件文件 rs-fw-update -f signed_firmware_5_13_0_50.bin

升级过程中不要拔USB线，一旦中途断电有概率变砖。虽然官方有恢复模式能救回来，但没必要冒这个险。如果相机已经在ROS2节点运行中，先关掉节点再升级。

3.4 硬件排错三连：USB接口、供电、散热

D435i这个级别的深度相机，最影响稳定性的是USB接口。它需要USB 3.0及以上带宽，如果用USB 2.0口或者经过不带独立供电的USB Hub，深度流会出现间歇性中断，具体表现是节点长时间运行后话题停止发布。检查命令：

lsusb -t

如果看到D435i挂在5000M带宽的端口下，说明是USB 3.0；如果看到480M，就是USB 2.0。另外很多笔记本的USB口看起来是Type-C实际带宽分配不足，建议插在主板直出口上，不要经过转接头。

供电方面，D435i官方通过USB供电，一般USB 3.0口能供给900mA，正常够用。但如果你同时接了多个传感器，或者用的是老款USB Hub，就容易出现IMU供电不足。如果出现跑一会儿"掉相机"的现象，排除完代码问题后优先查供电。

散热这个问题网上提得少，但D435i在长时间高负载跑点云时发热很明显。外壳摸上去烫手时，深度图质量会下降，甚至RGB图像出现噪点。我试过给它在支架上加一个小的散热风扇，长时间测试的稳定性明显提升。

4. realsense-ros功能包：编译、launch与话题结构全解析

4.1 分支选择与源码编译流程

librealsense这层通了之后，接下来把相机接进ROS2。核心功能包是Intel官方出的realsense-ros。这里有一个非常容易踩的坑：realsense-ros的master分支在不同时期对应ROS1和ROS2的代码不太一样，你必须明确切换到ros2-master分支（或者看release标签是否标注humble）再编译。

推荐的做法是在单独的工作空间编译，方便出问题时整个删掉重来：

mkdir -p ~/realsense_ws/src cd ~/realsense_ws/src git clone https://github.com/IntelRealSense/realsense-ros.git -b ros2-master cd ~/realsense_ws rosdep install -i --from-path src --rosdistro humble -y colcon build --symlink-install source install/setup.bash

--symlink-install参数强烈建议加上。它会让编译后的Python脚本和launch文件以符号链接形式指向源码目录，这样你改launch文件不用重新编译就能生效，调试效率高很多。

rosdep这一步有时会因为网络原因卡住，如果一直卡在crawling状态，可以检查网络或者手动安装依赖。realsense-ros在Humble下的核心依赖包括ros-humble-realsense2-camera、ros-humble-diagnostic-updater等，实在拉不下来就用sudo apt install ros-humble-realsense2-camera直接装发行版，但注意发行版可能没源码版新，建议在线环境允许时源码编译。

4.2 启动相机节点：两种方式与关键参数

编译成功后在终端里source环境，先试默认launch：

ros2 launch realsense2_camera rs_launch.py

默认情况下，这个launch会发布深度、彩色、和相机信息这些基础话题，但IMU和点云默认不开启。我们做融合，IMU和点云是刚需，所以启动时要显式打开：

ros2 launch realsense2_camera rs_launch.py depth_module.profile:=1280x720x30 rgb_camera.profile:=1280x720x30 pointcloud.enable:=true

或者换用ros2 run方式逐参数设置，效果一样：

ros2 run realsense2_camera realsense2_camera_node --ros-args \ -p align_depth:=true \ -p enable_gyro:=true \ -p enable_accel:=true \ -p unite_imu_method:=linear_interpolation \ -p pointcloud.enable:=true

我需要把几个关键参数讲透，因为这些参数理解错一个，后面的数据处理就会多绕一大圈。

align_depth尤其重要，因为它决定了你要在深度图里查像素值还是直接在彩色图坐标系里使用深度。开启后，realsense-ros会额外发布一个/camera/camera/aligned_depth_to_color/image_raw话题，这时深度图里每一个像素的位置和彩色图严格对应，做目标检测后直接取深度就方便多了。

4.3 话题命名空间与TF树：理解相机节点到底发布了什么

realsense-ros节点跑起来后，话题数量一开始会让人有点眼花。先查看一下完整列表：

ros2 topic list

常用话题我整理成了一张表：

注意看，话题名带了双重的/camera/camera前缀。这是因为节点名默认叫camera，命名空间也叫camera。这个设计在单相机时略显冗余，但在多相机场景下反而是优势，你可以通过给不同相机设置不同的camera_name参数来区分命名空间，避免话题冲突。

TF树方面，realsense-ros默认会发布一套完整的坐标系关系：

• camera_link：机体原点，通常是你安装相机的参考系
• camera_depth_frame/camera_depth_optical_frame：深度相机光心坐标系
• camera_color_optical_frame/camera_color_optical_frame：彩色相机光心坐标系
• camera_imu_optical_frame：IMU坐标系

这些坐标变换里，深度和彩色之间的外参是出厂时标定好的，SDK会以静态TF形式发布。这意味着你可以直接在RViz2里叠加RGB图像和深度点云，而不用自己做图像配准。IMU和相机之间的变换，官方也给了出厂标定结果，但如果做高精度VIO，建议重新标定一次外参再融。

4.4 QoS配置：为什么你的订阅节点"收不到"相机数据

这是RealSense接入ROS2后最经典的坑之一，也是让很多人怀疑人生的地方。现象是：ros2 topic list能看到相机话题，ros2 topic echo也能在命令行看到数据，但自己写一个订阅节点却收不到任何消息。

根因在于ROS2的QoS（Quality of Service）策略。RealSense相机节点发布数据时默认走的是Sensor Data QoS，可靠性策略是BEST_EFFORT，换句话说发送方说"我尽量发，丢了不管"。而你在代码里新建订阅者时如果用默认QoS，可靠性策略是RELIABLE，"你必须保证我每条消息都不丢"。

这两种策略在DDS层面无法自动匹配，结果是发布端认为没有合适的订阅者，订阅端也等不到数据。解决办法是在创建订阅者时显式指定与相机一致的QoS：

from rclpy.qos import QoSProfile, ReliabilityPolicy, HistoryPolicy sensor_qos = QoSProfile( depth=10, reliability=ReliabilityPolicy.BEST_EFFORT, history=HistoryPolicy.KEEP_LAST, ) self.sub = self.create_subscription( Image, '/camera/camera/color/image_raw', self.callback, qos_profile=sensor_qos )

理解了QoS这个机制，后面写融合节点时很多"莫名其妙"的问题都会有思路。相机的数据量大、实时性要求高，用BEST_EFFORT是合理的；而你如果要对运动指令做可靠传输，该用RELIABLE还得用。QoS机制不是bug，它是ROS2比ROS1更精细的地方。

5. 多传感器数据融合实战：时间同步、坐标变换与EKF融合

5.1 融合的第一步不是写滤波器，而是让数据先"对齐"

很多人一提到多传感器数据融合就直奔卡尔曼滤波，我的经验是先停一步，把数据对齐问题解决。所谓对齐，核心是两个层面：时间轴对齐和空间坐标对齐。

时间轴对齐上，视觉和IMU本质上是两套不同频率的传感器。D435i的IMU可以跑到200Hz以上，而彩色/深度通常30Hz。要做融合，必须先确保"同一时刻"的两路数据才能被输入滤波器。每一帧ROS2消息都带有时间戳，你要做的就是用消息过滤器把时间差在容忍范围内的消息匹配成一组。

空间坐标对齐上，每个传感器都有自己独立的坐标系。IMU测的是camera_imu_optical_frame下的加速度和角速度，彩色图是camera_color_optical_frame下的投影，深度点云是camera_depth_optical_frame下的三维点。如果直接拿不同坐标系下的数据做融合，得到的位姿必然是错的。所以正确顺序一定是：先理解并校准传感器之间的外参，再做融合。

5.2 用message_filters实现视觉与IMU的时间同步

ROS2里做时间同步的官方工具是message_filters的ApproximateTimeSynchronizer。这个名字起得很形象：它不是要求两路时间戳完全相等，而是在设定的slop窗口内，把最接近的消息凑成一对。

下面是我实际用过的同步节点代码，订阅彩色图像和IMU：

import rclpy from rclpy.node import Node from rclpy.qos import QoSProfile, ReliabilityPolicy, HistoryPolicy from sensor_msgs.msg import Image, Imu import message_filters class SyncFusionNode(Node): def __init__(self): super().__init__('sync_fusion_node') sensor_qos = QoSProfile( depth=20, reliability=ReliabilityPolicy.BEST_EFFORT, history=HistoryPolicy.KEEP_LAST, ) self.image_sub = message_filters.Subscriber( self, Image, '/camera/camera/color/image_raw', qos_profile=sensor_qos) self.imu_sub = message_filters.Subscriber( self, Imu, '/camera/camera/imu', qos_profile=sensor_qos) self.time_sync = message_filters.ApproximateTimeSynchronizer( [self.image_sub, self.imu_sub], queue_size=20, slop=0.05 ) self.time_sync.registerCallback(self.callback) self.get_logger().info('Fusion node started.') def callback(self, image_msg: Image, imu_msg: Imu): # 拿到时间对齐后的图像和IMU消息，做后续处理 dt = abs(image_msg.header.stamp.sec - imu_msg.header.stamp.sec) self.get_logger().info(f'Time diff: {dt} sec') def main(args=None): rclpy.init(args=args) node = SyncFusionNode() rclpy.spin(node) node.destroy_node() rclpy.shutdown()

slop=0.05表示允许5毫秒的时间误差。如果你的融合算法对时间精度要求极高，可以把slop调小，但代价是消息匹配成功率降低。建议先用0.05跑起来看输出日志，再根据实际时间差分布调整。

这里有个细节容易忽略：message_filters的Subscriber在创建时也必须传入与话题一致的QoS。如果你用默认QoS，它同样会面临上一节说的收不到数据的问题。

5.3 让IMU参与融合：robot_localization的EKF配置

在ROS2生态里做多传感器融合，最成熟的现成工具是robot_localization，它提供了扩展卡尔曼滤波器（EKF）实现，可以把IMU、里程计、GPS等不同来源的数据融合成一个稳定的位姿和速度估计。

安装：

sudo apt install ros-humble-robot-localization

我写了一个EKF配置示例，把D435i的IMU数据作为唯一的传感器输入，输出融合后的odom：

ekf_filter_node: ros__parameters: frequency: 30.0 sensor_timeout: 0.1 two_d_mode: false transform_time_offset: 0.0 transform_time_limit: 0.0 odom0: /odom odom0_config: [true, true, false, false, false, false, false, false, false, false, false, false, false, false, false] imu0: /camera/camera/imu imu0_config: [false, false, false, true, true, true, false, false, false, false, false, true, true, false, false]

imu0_config里那15个布尔值对应[x, y, z, roll, pitch, yaw, vx, vy, vz, vx_dot, vy_dot, vz_dot, wx, wy, wz]这15维状态，含义是这一路传感器为对应状态提供观测。IMU给EKF提供的是roll、pitch、yaw角度和wx、wy角速度，所以只有这几个位置是true。如果你把加速度计数据也喂进去，还可以把vx、vy、vz设置为true，但要注意IMU的加速度计在运动激烈时噪声很大，不一定比纯角速度融合效果好。

启动EKF节点的命令：

ros2 run robot_localization ekf_node --ros-args --params-file ekf_params.yaml

跑起来之后配合RViz2查看，你会看到EKF输出的/odometry/filtered轨迹比原始IMU积分出来的轨迹平滑很多，这正是滤波器的价值——它不依赖任何一种传感器的绝对精度，而是通过融合互相修正。

5.4 深度点云与机械臂坐标系的手眼标定

如果你的目标是机械臂抓取，那D435i的深度点云只是第一步，真正的难题是把相机坐标系下的三维点转换到机械臂基座坐标系。这里说的就是手眼标定。

手眼标定的数学模型是AX=XB，其中X是相机到机械臂末端的变换矩阵，A是机械臂末端在不同位姿的变化，B是相机观测到的标定板在不同位姿的变化。要解出X，至少需要从两组不同的机械臂位姿和对应的标定板观测中建立方程。

实操中，我的建议是使用easy_handeye2这个ROS2包，它能在RViz2里交互式完成标定数据采集和求解。基本流程是：

1. 把标定板固定在机械臂工作空间内，让相机能清晰看到它
2. 控制机械臂移动到几个不同的姿态，在每个姿态下记录机械臂末端位姿（话题来源通常是机械臂驱动节点）和相机看到的标定板位姿（aruco_ros检测）
3. 采集5到8组数据后，调用求解器计算手眼矩阵
4. 验证：控制机械臂移动到新位置，用标定结果把相机点云投影到基座坐标，检查误差是否在可接受范围

标定过程中有几个影响精度的关键点。标定板平面和相机光轴夹角不能太小，最好在30度到60度之间；机械臂姿态要多样化，不要都在一个位置附近微调；记录数据时机械臂必须静止，避免运动模糊影响位姿解算。我见过最离谱的一次标定失败，是因为标定板在桌子上没贴平，从相机角度看有轻微弯曲，导致所有观测位姿都带系统误差，重贴标定板后精度立刻恢复正常。

手眼标定完成之后，你才真正拥有了"把像素坐标变成机器人基座坐标"的能力，后面的视觉抓取、避障规划才有意义。这一步是整个多传感器数据融合链路里最"物理"的一环，也是纯代码调试无法替代的环节。

6. 实测中踩过的坑：从USB带宽到DDS不通的全记录

6.1 USB带宽不够：点云断流、深度图跳变

第一次我同时打开深度、彩色和点云，运行5分钟发现点云话题中间断了几秒，再一看日志，报错大概意思是USB传输超时。查lsusb -t发现相机挂在USB 3.0口下，但同一时间系统里还挂了一块高速固态硬盘的移动硬盘盒，抢占了同一条PCIe通道上的带宽。

解决办法不是把硬盘拔了，而是学会降低相机负载。最有效的方式是把分辨率降到640x480，帧率降到15fps，点云计算开启后这属于高负载模式，不要盲目上1280x720@30，除非你确认USB链路完全独占。另外，realsense-ros里有一个depth_module.hdr_enabled参数可以控制曝光模式，开启高动态范围之后单帧处理时间会增加，对带宽也有影响。总的来说，USB带宽的坑往往是多个设备叠加造成的，排查时要先做减法，逐个设备停用测试。

6.2 深度图全黑或大量空洞：从IR发射器查起

如果你打开realsense-viewer发现深度图大面积黑色，实际操作中按这个顺序排查：

1. 距离：目标物离镜头太近（小于0.3米）会超出立体视觉最小范围，深度值为0是正常的
2. 强环境红外光：窗外阳光、红外遥控设备、其他深度相机的红外投影都会干扰，拉上窗帘或换到室内测试
3. IR发射器被关闭：有些方案为了功耗会禁用发射器，需要显式打开

打开发射器的命令：

ros2 run realsense2_camera realsense2_camera_node --ros-args -p emitter_enabled:=true -p emitter_on_off:=true

emitter_on_off表示让发射器根据场景亮度自动开关，在黑暗环境下自动打开。如果深度图偶尔闪烁，可以尝试固定曝光参数，比如把IR曝光时间设为100，增益设为32：

ros2 run realsense2_camera realsense2_camera_node --ros-args -p depth_module.exposure:=100 -p depth_module.gain:=32

这个技巧在室内灯光较均匀的场景下效果明显，基本能消除60%以上的深度闪烁问题。

6.3 arm64平台：树莓派4和Jetson上的RealSense

很多人想把D435i直接接到树莓派4或者Jetson Nano上做小车项目，但arm64平台的坑和x86不太一样。

首先是SDK安装：Ubuntu 22.04 arm64可以通过apt装librealsense2，但某些老版本SDK在arm64上缺少预编译的dkms模块，需要源码编译。源码编译时要注意内存，树莓派4如果内存只有4GB，建议先增加swap，否则编译到一半会因为内存不足被杀掉。

其次是算力限制：arm64平台上即使连接成功，点云计算在高分辨率下也跑不动。我实测过树莓派4跑640x480@15fps深度流，CPU占用达到70%以上，如果再开点云，基本没有余力做其他任务。所以arm64平台建议只开深度+彩色，点云计算留到上位机或者用硬件加速（Jetson的GPU/NPU）。

最后是RViz2可视化：如果你在本地电脑上连远程板卡的相机节点，不要把RViz2跑在板卡上，而是本地电脑装RViz2，订阅板卡发布的话题。跨机器通信的配置方法见下一节，这个方案能让板卡把宝贵的算力集中在传感器处理上。

6.4 跨机器通信：DDS类型和ROS_DOMAIN_ID不一致导致的话题不通

在真实机器人项目里，相机经常挂在一块板卡上，上位机在另一台电脑上做融合。这时你除了要保证网络连通，还要保证两台机器的DDS配置一致。

最常见的问题是两边用的RMW实现不同。ROS2的DDS抽象层支持多种实现，比如FastDDS、CycloneDDS、RTI Connext DDS。如果你的板卡侧用的是默认FastDDS，而上位机侧配置了export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp，那么即使ROS_DOMAIN_ID相同，话题也可能互相看不到。

我踩过一次很深的坑：两台机器都用默认安装，但一台装了ros-humble-desktop-full，另一台用了一键脚本，脚本把RMW切换成了CycloneDDS，结果两边ros2 topic list都正常，就是订阅不到对方的话题。解决办法是明确统一RMW：

export RMW_IMPLEMENTATION=rmw_fastrtps_cpp

另一个跨机器问题就是ROS_DOMAIN_ID。ROS2默认domain是0，如果多个项目同时运行会互相干扰，一定要给每个项目设置不同的domain：

export ROS_DOMAIN_ID=42

两台机器设置相同domain之后，用ros2 topic list验证能否互相看到话题，能看到了再往下做融合。这一步是跨机器调试的前提。

6.5 多相机并联：串口干扰和命名空间冲突

有的项目需要在机械臂上装多台D435i做全方位感知，这时新问题就来了。第一个问题是两台的IR投影仪会互相干扰：相机A的投影点阵被相机B看到，深度图出现随机噪点。解决办法是给相机设置不同的inter_cam_sync_mode参数，或者用外部硬件同步线缆，让两台的曝光时刻错开。

第二个问题是命名空间冲突。前面说过realsense-ros默认话题带/camera/camera前缀，多相机场景必须手动指定camera_name：

ros2 run realsense2_camera realsense2_camera_node --ros-args \ -p camera_name:=camera_front \ -p serial_no:='_042322070034' \ -p pointcloud.enable:=true

通过serial_no指定每台相机的物理序列号，用camera_name区分话题命名空间，这样才能保证两台相机的话题不冲突，TF树上的不同frame也能区分开。如果你用的是USB连接，还建议写udev规则给不同相机固定设备别名，否则操作系统可能随机分配设备名，导致每次开机相机的对应关系都不一样。

多传感器数据融合做到这个阶段，你会发现"传感器能出数据"只是最浅的一层，真正让你在项目中不慌的，是对话题结构、坐标变换、时间同步和QoS这套机制的理解。我个人的感受是，第一次把这些链路完整跑通时，很多之前觉得玄学的概念突然都有了落脚点：TF树不再是想当然的坐标系，QoS不再是文档里的名词，融合也不再是导出一个rosbag交给别人处理。你可以带着这套经验去处理激光雷达、里程计、视觉标签等多传感器的组合，核心思路都是一样的。