4. 常见传感器数据格式
在多传感器系统中，传感器输出的数据格式决定了采集、传输、存储与融合的效率。不同格式在可读性、体积、解析速度、模式约束和生态支持上差异显著。理解这些差异，才能在激光雷达、摄像头、IMU、GPS等异构传感器共存时做出合理选择。
核心原理：文本格式与二进制格式的分野
常见传感器数据格式可分为两大类。文本格式包括 JSON、XML、CSV、YAML，它们以人类可读字符表示数据，便于调试和跨平台交换；二进制格式包括 Protobuf、MessagePack 以及 ROS 消息的序列化形式，它们以紧凑字节流表示数据，体积小、解析快，适合高频率、大数据量的传感器流。
文本格式的代价是冗余字符多、解析需要词法分析，带宽和 CPU 开销较高；二进制格式的代价是需要预先定义模式或依赖特定库，跨语言调试不如文本直观。选择格式的本质，是在可读性、传输效率、模式演进能力和工具链成熟度之间做权衡。
方法流程：从传感器原始输出到目标格式
实际工程中，格式转换通常遵循一条清晰链路。以 IMU 为例，其原始输出可能是串口字节流，先解析为结构体，再序列化为目标格式。
- 解析原始帧：按协议（如 UART 帧头、长度、校验）拆出有效载荷。
- 映射为内存结构：将字节按字段类型（int16、float32）还原为结构体或字典。
- 附加元数据：补充时间戳、坐标系、传感器 ID、标定参数版本。
- 序列化为目标格式：按下游需求选择 JSON、Protobuf 或 ROS 消息。
- 校验与回读：反序列化验证字段完整性和数值范围。
# 以 Python 为例：IMU 结构体转 JSON 与 Protobuf
import json
imu = {"ts": 1710000000.123, "ax": 0.02, "ay": -0.01, "az": 9.81,
"gx": 0.001, "gy": 0.002, "gz": -0.003, "frame": "imu_link"}
# JSON：可读，体积较大
json_str = json.dumps(imu, ensure_ascii=False)
# Protobuf：需先定义 imu.proto，再调用 SerializeToString()
# payload = ImuMessage(**imu).SerializeToString()
案例场景：多传感器融合中的格式搭配
在一台自动驾驶小车上，摄像头图像以 H.264 压缩流传输，激光雷达点云以 Protobuf 或 ROS PointCloud2 传输，IMU 与轮速计以 ROS 消息在节点间高频发布，而整车标定参数和传感器配置则用 YAML 保存。云端数据回传时，常将 ROS 消息转为 Protobuf 以降低带宽，同时保留 JSON 摘要用于可视化平台。
这种“混合格式”策略很常见：内部高频通信用二进制，外部配置与调试用文本。若强行统一为单一格式，往往会在某一环节付出不必要的代价。
对比清单：七种格式关键特性
| 格式 | 可读性 | 体积 | 模式约束 | 典型场景 |
|---|---|---|---|---|
| JSON | 高 | 中 | 弱（可选 Schema） | Web 上报、配置、日志 |
| XML | 高 | 大 | 强（XSD） | 工业设备、医疗仪器 |
| CSV | 高 | 小 | 无 | 标定表、离线分析 |
| YAML | 高 | 中 | 弱 | ROS 参数、流水线配置 |
| Protobuf | 低 | 很小 | 强（.proto） | 车云传输、大规模流 |
| MessagePack | 低 | 小 | 无 | 嵌入式、实时推送 |
| ROS 消息 | 中 | 小 | 强（.msg） | 机器人节点通信、rosbag |
误区与复盘
复盘建议：在项目早期就明确“内部通信格式”和“持久化格式”两条线，并编写双向转换测试。对 Protobuf 和 ROS 消息，务必把 .proto / .msg 纳入版本管理，字段编号一旦发布不要随意复用。对 YAML 和 JSON，注意浮点精度与单位统一，避免同一物理量在不同文件中使用不同量纲。
掌握这些格式的特点与边界，才能在多传感器数据转换工程中做出稳定、可维护的选择。