孙煜征1. ROS1与ROS2 rosbag格式的前世今生
第一次接触ROS的朋友可能会好奇，为什么机器人开发需要专门的数据记录工具？想象一下你在调试自动驾驶小车时，摄像头、雷达、IMU传感器每秒钟产生数万条数据，如果每次测试都要实时盯着屏幕看数据，那简直是程序员的噩梦。rosbag就像一台全天候工作的录音机，能把所有传感器数据按时间顺序完整记录下来，方便后续反复分析和问题定位。
ROS1时代采用的.bag格式本质上是个二进制大文件，你可以把它理解成一卷老式磁带。磁带的特点是线性存储，从头到尾按顺序读写效率很高，但想快速跳转到某个特定时间点的数据就很麻烦。我2016年做无人机项目时就遇到过这种困扰——为了分析一次异常降落的数据，不得不把整个2小时的bag文件从头播放到尾。
ROS2团队显然意识到了这个问题，他们引入了基于SQLite的.db3格式。这就像把磁带升级成了CD唱片，数据被结构化存储在数据库表格里。去年我在处理一批3D点云数据时，只需要一条简单的SQL查询就能提取特定区域的点，效率提升了几十倍。这种设计还带来了额外好处：数据库文件可以跨平台共享，甚至直接用普通SQL工具查看内容，这在ROS1时代是不可想象的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 二进制与数据库的格式对决
2.1 ROS1的.bag格式解剖
打开一个典型的.bag文件，内部结构其实很有规律。每个消息块包含：
- 4字节的头部长度
- 消息头（含时间戳、话题名等元数据）
- 序列化后的消息体
这种设计在机械硬盘时代非常高效，我在2018年的测试中发现，连续写入速率能达到50MB/s。但问题也随之而来——有次项目需要提取特定话题的前100条消息，只能写脚本暴力扫描整个文件，耗时长达15分钟。
更棘手的是版本兼容性问题。去年帮客户迁移一个2014年的bag文件时，发现某些自定义消息类型已经变更，反序列化直接失败。这种问题在二进制格式中几乎无解，最终只能找到当年的ROS环境重新录制数据。
2.2 ROS2的.db3格式革新
.db3文件实际上是SQLite数据库，主要包含三张核心表：
- messages：存储所有消息内容
- topics：记录话题元数据
- schema：保存消息类型定义
这种结构带来的优势非常明显。上个月我需要分析机器人绕桩时的转向角