3. 传感器数据基础：数据流模型、Topic与Service的选择、消息类型定义、QoS配置

各位同学，欢迎来到第三章。前两章我们把环境搭好了，也跑通了第一个传感器节点。但说实话，那只是「能跑」而已。真正要让传感器数据在系统里稳定、高效地流转，你得理解ROS2这套数据模型的底层逻辑。

这一章，我带你把这些基础概念掰开揉碎。搞懂了这些，后面调试传感器的时候，你才能做到心里有数。

3.1 传感器数据流模型：从物理世界到数字信号

传感器接入ROS2，本质上是一个数据流动的过程。我个人习惯把这个过程拆成三个环节：

  1. 物理采样：传感器硬件把物理量（温度、距离、图像）变成电信号。
  2. 协议解析：通过I2C、SPI、UART等接口，把原始数据读出来。
  3. ROS2封装：把解析后的数据打包成ROS2消息，发布到话题上。

这里有个常见的误区——很多人以为ROS2节点直接「连接」传感器硬件。其实不是。ROS2节点只负责处理数据，它不关心数据是从I2C总线来的，还是从串口来的，甚至是从仿真环境里模拟出来的。这种解耦设计，正是ROS2的优雅之处。

核心要点：传感器数据流是单向的、周期性的。传感器节点是生产者，订阅节点是消费者。生产者只管发，消费者决定要不要收。

我在项目中遇到过一个问题：有个同事把激光雷达的数据处理逻辑直接写在了回调函数里，导致回调阻塞，数据丢包严重。嗯，这里要注意——回调函数里千万别做耗时操作，否则整个数据流都会卡住。

物理传感器 （硬件层） ROS2节点 （驱动层） 订阅节点 （应用层） I2C/SPI/UART Topic

3.2 话题（Topic）与服务（Service）的选择

ROS2提供了两种通信方式：Topic和Service。很多新手会纠结该用哪个。我直接给你一个判断标准：

  • Topic：数据是持续流，发布者不知道谁会收，订阅者也不知道谁在发。典型场景：激光雷达点云、摄像头图像、IMU数据。
  • Service：数据是一问一答，客户端发起请求，服务端返回响应。典型场景：修改传感器参数、触发一次校准、读取设备序列号。

我的经验：传感器数据99%用Topic。Service适合那些「偶尔调用一次」的操作。你想想看，如果每帧图像都走Service，那系统早就被请求淹没了。

我曾经见过一个项目，把摄像头图像用Service来传，结果帧率只有2fps。改成Topic后直接飙到30fps。说白了，Topic是ROS2为高频数据流设计的，它的底层用了DDS的发布-订阅模型，天生就是干这个的。

3.3 消息类型（Message）定义

ROS2的消息类型，本质上是一个数据结构定义。传感器数据最常用的消息类型，我列个表给你：

传感器类型 推荐消息类型 关键字段
激光雷达 sensor_msgs/LaserScan ranges[], intensities[], angle_min, angle_max
摄像头 sensor_msgs/Image data[], encoding, width, height
IMU sensor_msgs/Imu orientation, angular_velocity, linear_acceleration
温度/湿度 sensor_msgs/Temperature temperature, variance
自定义传感器 自定义.msg文件 按需定义

如果你用的是非标传感器，那就得自己定义消息类型。举个例子，我做过一个PM2.5传感器，它的数据包含三个值：PM1.0、PM2.5、PM10。我这样定义：

# PM25Data.msg
std_msgs/Header header
float32 pm1_0
float32 pm2_5
float32 pm10
uint8 quality_flag  # 0=正常, 1=数据不稳定, 2=传感器故障

注意：自定义消息时，一定要加Header字段。Header里的timestamp是ROS2做时间同步的基础。我见过有人图省事不加，结果后面做数据融合时，时间戳对不上，整个项目重做。

3.4 QoS配置对传感器数据的影响

QoS（Quality of Service）是ROS2里最容易忽略、也最容易出问题的地方。说白了，QoS就是告诉DDS：你对数据的可靠性、实时性有什么要求。

对于传感器数据，我建议你重点关注这三个QoS参数：

  • Reliability（可靠性）：
    • RELIABLE：保证数据一定送达，但可能重传导致延迟。适合低频传感器（如温度）。
    • BEST_EFFORT：尽力送达，丢了就丢了。适合高频传感器（如激光雷达、摄像头）。
  • Durability（持久性）：
    • VOLATILE：不保留历史数据。新订阅者只能收到之后的数据。
    • TRANSIENT_LOCAL：保留最后一条数据。新订阅者一上来就能拿到最新值。
  • Depth（队列深度）：
    • 设置消息队列能缓存多少条数据。深度太小容易丢数据，深度太大占用内存。

为什么会这样？我解释一下。激光雷达一秒钟发20帧数据，如果用RELIABLE模式，丢了一帧就要重传，后面的数据全堵住了。用BEST_EFFORT模式，丢一帧就丢一帧，下一帧照常发。你想想看，对于实时控制来说，是等一帧旧数据重要，还是拿到最新数据重要？

我的推荐配置：

  • 激光雷达/摄像头：BEST_EFFORT + VOLATILE + Depth=10
  • IMU/温度：RELIABLE + TRANSIENT_LOCAL + Depth=5
  • 自定义低速传感器：RELIABLE + VOLATILE + Depth=1

我曾经踩过一个坑：用默认的QoS配置去订阅一个激光雷达话题，结果发现帧率只有5fps。查了半天，发现是发布者用了BEST_EFFORT，订阅者用了RELIABLE，两者不匹配，DDS一直在协商，导致性能下降。记住：发布者和订阅者的QoS必须兼容，否则通信会降级甚至失败。

好了，这一章的内容就这些。数据流模型让你看清数据怎么走，Topic和Service帮你选对通信方式，消息类型定义让你封装数据，QoS配置则决定了数据能不能稳定到达。这四个点，是传感器接入ROS2的基石。