ROS2 Python实战：基于launch.py与pyrealsense2实现多台Intel RealSense D405相机同步采集与话题发布

最新推荐文章于 2026-04-03 10:06:16 发布

原创

最新推荐文章于 2026-04-03 10:06:16 发布 · 444 阅读

1. 项目背景与核心价值

大家好，我是老张，在机器人视觉领域摸爬滚打了十来年，经手过不少多传感器融合的项目。今天想和大家深入聊聊一个非常实用的工程场景：如何用ROS2 Python，配合launch.py和pyrealsense2库，来驱动多台Intel RealSense D405相机，实现同步采集和独立的话题发布。

你可能要问，为什么非得是多台D405？一台不够用吗？在实际的机器人应用里，比如一个智能分拣工作站、一个三维重建平台，或者一个需要多视角监控的安防场景，单台相机的视野和感知能力是远远不够的。我们需要从不同角度获取信息，才能构建出更完整、更可靠的环境感知。Intel的RealSense D405是一款轻量级的深度相机，体积小、精度不错，特别适合集成到多相机阵列中。

但是，把多个相机接入ROS2，可不是简单地把一个节点的代码复制粘贴几遍就完事了。这里面有几个实实在在的“坑”：硬件同步、资源管理、数据流组织和可视化调试。如果处理不好，你会发现要么相机之间数据对不上，要么系统资源被吃满，要么在rviz2里看图像看得眼花缭乱。我当初也踩过这些坑，所以今天就把我趟出来的路，结合一个完整的、可运行的代码实例，掰开揉碎了讲给你听。我们的目标很明确：让你能快速搭建一个稳定、高效的多D405相机ROS2节点，并且能通过一个launch.py文件优雅地一键启动所有设备。

这个方案的核心优势在于它的工程化和可维护性。我们不是写几个孤立的脚本，而是构建一个标准的ROS2功能包。通过launch.py文件，我们可以用声明式的方法配置多个相机节点，为每个节点分配独立的命名空间和参数，从而避免话题冲突。同时，我们利用pyrealsense2这个官方Python绑定库直接驱动硬件，绕过了ROS2官方realsense2_camera驱动包可能存在的复杂依赖和配置，让整个流程更轻量、更可控。接下来，我们就从零开始，一步步实现它。

2. 环境搭建与准备工作

工欲善其事，必先利其器。在开始写代码之前，我们必须把开发环境搭建妥当。这里我假设你已经有了一个基本的ROS2 Humble环境。如果没有，可以去ROS官网按照教程安装，过程不算复杂。

2.1 核心依赖安装

首先，我们需要安装几个关键的库。打开终端，依次执行以下命令：

sudo apt update
sudo apt install ros-humble-rviz2 ros-humble-cv-bridge python3-pip

第一行是更新软件源列表。第二行安装了两个ROS2包：rviz2是我们的可视化神器，后面用来同时观看多个相机的画面；cv-bridge是连接OpenCV图像和ROS2图像消息的桥梁，必不可少。

接下来是Python库。我们主要依赖pyrealsense2来驱动D405相机。这里我强烈建议使用pip安装，因为通过系统apt安装的版本可能较旧，对新硬件的支持可能有问题。

pip3 install pyrealsense2 opencv-python numpy

安装pyrealsense2时，如果网络环境不佳可能会比较慢，耐心等待即可。opencv-python和numpy是图像处理和数据运算的基础，同样需要安装。

2.2 创建工作空间与功能包

环境准备好后，我们创建一个专属的工作空间。我喜欢把项目整理得清清楚楚，这样以后维护起来也方便。

mkdir -p ~/realsense_ws/src
cd ~/realsense_ws/src

现在，我们在src目录下创建我们的功能包。ROS2 Humble推荐使用ament_python作为Python包的构建类型。

ros2 pkg create multi_d405_camera --build-type ament_python --dependencies rclpy sensor_msgs cv_bridge

这个命令创建了一个名为multi_d405_camera的功能包，并自动声明了它依赖的三个核心ROS2库：rclpy（Python客户端库）、sensor_msgs（包含Image等消息类型）和cv_bridge。命令执行后，你会看到生成了一整套标准的包目录结构。

进入这个包，我们创建后续需要的子目录。这是保持代码结构清晰的好习惯。

cd multi_d405_camera
mkdir launch config

launch目录用来存放我们的启动文件，config目录则可以用来存放配置文件，比如相机的序列号映射文件。至此，我们的开发环境就准备就绪了。你可以用ros2 pkg list看看能不能找到新创建的包，确认一切正常。

3. 相机驱动层封装：`camera.py`与`realsense_camera.py`

驱动层是我们的地基，它的目标是抽象出相机硬件，让上层的ROS2节点不用关心具体是哪个型号的RealSense，甚至是不是真实相机。这种设计模式大大提高了代码的可测试性和可扩展性。我借鉴并优化了一个在实际项目中验证过的驱动结构。

3.1 抽象基类：`camera.py`

首先，在multi_d405_camera/multi_d405_camera/目录下（注意，这是Python包的源码目录，和上层的功能包目录同名），创建camera.py文件。这里我们定义了一个协议类（Protocol），你可以把它理解为一个“接口”或“合同”，规定所有相机驱动都必须实现read方法。

from pathlib import Path
from typing import Optional, Protocol, Tuple
import numpy as np

class CameraDriver(Protocol):
    """相机驱动协议。
    所有相机驱动类的抽象基类，用于将相机硬件与上层代码解耦。
    """
    def read(
        self,
        img_size: Optional[Tuple[int, int]] = None,
    ) -> Tuple[np.ndarray, np.ndarray]:
        """从相机读取一帧数据。
        参数:
            img_size: 可选参数，期望返回图像的尺寸（宽，高）。如果为None，则返回原始分辨率。
        返回:
            color_image: 彩色图像，NumPy数组，形状为(H, W, 3)，数据类型为uint8。
            depth_image: 深度图像，NumPy数组，形状为(H, W, 1)，数据类型为uint16。
        """
        ...

这个CameraDriver协议只定义了一个read方法，返回彩色和深度图像。为什么这么设计？因为无论你用的是RealSense D405、D435，还是为了调试用的虚拟相机、播放录制的视频流，它们对外提供数据的方式都是一样的：read一帧。上层节点只调用这个方法，根本不需要知道下面具体是什么硬件。

为了演示这种抽象的好处，我们可以马上实现两个“虚拟”相机驱动。第一个是DummyCamera，它每次read都返回随机噪声图像。这在没有真实硬件的时候，用来测试节点逻辑和消息流是否通畅，简直太方便了。

class DummyCamera(CameraDriver):
    """用于测试的虚拟相机，生成随机图像。"""
    def read(
        self,
        img_size: Optional[Tuple[int, int]] = None,
    ) -> Tuple[np.ndarray, np.ndarray]:
        if img_size is None:
            h, w = 480, 640
        else:
            h, w = img_size[1], img_size[0]
        # 生成随机彩色图 (H, W, 3)
        color_img = np.random.randint(0, 255, (h, w, 3), dtype=np.uint8)
        # 生成随机深度图 (H, W, 1)，深度值范围通常在0-65535
        depth_img = np.random.randint(0, 1000, (h, w, 1), dtype=np.uint16)
        return color_img, depth_img

第二个是SavedCamera，它从磁盘上固定的图片文件读取数据。这个在算法开发初期特别有用，你可以用一组固定的图像数据，反复调试你的处理流水线，确保每次运行的结果都是确定、可复现的，排除了硬件波动带来的干扰。

标签