2. 定位数据采集：传感器类型、数据格式与采集工具
做数据回放驱动定位优化，第一步就是搞定数据采集。这活儿看着简单，不就是把传感器数据记下来嘛？但我在项目里踩过的坑，十有八九都出在这一步。数据采得不对，后面所有优化都是白搭。
今天咱们就聊聊，到底该采哪些数据、用什么格式存、以及怎么采才靠谱。
2.1 传感器类型：你得知道谁在干活
组合导航系统里，传感器就是我们的眼睛和耳朵。常用的就三种：GNSS、IMU、里程计。我一个个说。
2.1.1 GNSS（全球导航卫星系统）
GNSS 是定位的骨架。它提供绝对位置，说白了就是告诉你「你现在在地球上的哪个点」。常见的信号源有 GPS、北斗、GLONASS、Galileo。
但 GNSS 有个毛病——信号容易丢。过个桥洞、进个隧道，它就歇菜了。所以它必须跟其他传感器配合着用。
关键参数：
- 定位精度：单点 2-5 米，RTK 厘米级
- 更新率：通常 1-20 Hz
- 观测量：伪距、载波相位、多普勒频移
2.1.2 IMU（惯性测量单元）
IMU 是定位的肌肉记忆。它测量加速度和角速度，通过积分推算位置和姿态。我习惯把它比作「盲人走路」——每一步都靠感觉，但走久了误差会越积越大。
IMU 分两种：
- 消费级（MEMS）：便宜、体积小，但零偏稳定性差。我做过一个项目，用手机 IMU 做室内定位，10 秒就飘了 5 米。
- 工业级（光纤/激光）：贵、精度高，适合自动驾驶、无人机。我记得有个客户用光纤陀螺，半小时才飘 1 米。
我的经验：选 IMU 时别只看精度，还要看温漂。有一次我在北方冬天做测试，IMU 零偏直接翻了一倍。后来我学乖了，每次采集前先让 IMU 预热 5 分钟。
2.1.3 里程计（Odometry）
里程计是定位的「轮子」。它通过车轮转速或视觉特征推算位移。常见的有：
- 轮式里程计：简单可靠，但打滑就完蛋
- 视觉里程计：不依赖轮子，但光照变化时容易丢
- 激光里程计：精度高，但计算量大
我个人习惯把里程计当作「短距离救星」。GNSS 丢星时，靠它和 IMU 撑着，能撑个几十秒。
2.2 数据格式：存成什么样才方便回放？
数据格式这事儿，说白了就是「怎么把传感器说的话记下来」。我见过有人用 CSV 存 IMU 数据，结果时间戳对不上，回放时一塌糊涂。嗯，这里要注意，格式选对了，后面省一半功夫。
2.2.1 NMEA 格式
NMEA 是 GNSS 最通用的格式。它是一串 ASCII 文本，以 $ 开头，用逗号分隔字段。比如：
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
$GPRMC,123519,A,4807.038,N,01131.000,E,0.0,0.0,220394,,*0D常用的 NMEA 语句有：
- GGA：时间、经纬度、海拔、卫星数
- RMC：推荐最小数据，含速度、航向
- GSA：卫星精度因子（DOP）
- GSV：卫星可见信息
注意：NMEA 是文本格式，解析简单但体积大。如果你要采集高频数据（比如 20 Hz），建议别用 NMEA，否则文件会膨胀得很快。我曾经采了 1 小时数据，NMEA 文件有 2GB，回放时读盘都卡。
2.2.2 UBX 格式
UBX 是 u-blox 接收机的二进制格式。它比 NMEA 紧凑得多，而且包含更多原始观测值（比如载波相位）。
// UBX 消息结构
同步字符: 0xB5 0x62
消息类: 1 字节 (如 0x01 = NAV)
消息ID: 1 字节 (如 0x02 = POSLLH)
长度: 2 字节 (小端)
载荷: 长度可变
校验和: 2 字节 (CK_A, CK_B)我个人强烈推荐用 UBX 格式。为什么？
- 体积小：同样数据，UBX 只有 NMEA 的 1/3
- 精度高：可以拿到原始载波相位，做 RTK 后处理
- 配置灵活：可以只采集你需要的消息
我的习惯：采集时同时开 NMEA 和 UBX。NMEA 用来快速查看，UBX 用来做后处理。有一次 RTK 解算失败，我靠 UBX 里的原始观测值重新算了一遍，救回来了。
2.2.3 ROS Bag 格式
如果你用 ROS（机器人操作系统），那 Bag 格式就是标配。它把传感器数据按话题（Topic）和时间戳存成二进制文件。
# 录制所有话题
rosbag record -a
# 录制指定话题
rosbag record /gps/fix /imu/data /odom
# 回放
rosbag play --clock data.bagROS Bag 的好处是：
- 时间戳统一：所有传感器数据按同一时钟对齐
- 回放方便：可以调速、暂停、跳转
- 工具链成熟：有 rviz 可视化，有 bag_to_csv 转换
但要注意，ROS Bag 依赖 ROS 环境。如果你在嵌入式设备上采集，可能跑不了 ROS。我有个项目用 STM32，就只能自己写二进制格式。
2.3 采集工具：用什么家伙干活？
工具选对了，事半功倍。我按场景推荐几个：
| 场景 | 推荐工具 | 说明 |
|---|---|---|
| GNSS 采集 | u-center (u-blox) | 免费、支持 NMEA/UBX、可实时查看卫星图 |
| IMU 采集 | ROS bag + imu_tools | 自动标定、时间戳对齐 |
| 多传感器同步 | RTKLib + 自定义脚本 | 支持后处理、精度高 |
| 嵌入式设备 | SD 卡 + 二进制日志 | 轻量、无依赖 |
我的建议：别迷信工具。我见过有人用 u-center 采了 3 小时数据，结果发现采样率设错了。工具只是辅助，关键是你得知道自己在采什么。
2.4 注意事项：避坑指南
这部分是我最想说的。数据采集的坑，我基本都踩过。下面几条，你记好了。
我曾经犯过的错：
- 时间戳不同步：GNSS 用 UTC 时间，IMU 用系统时间，回放时对不上。后来我强制所有传感器用 GNSS 的 PPS 脉冲同步。
- 采样率不匹配：IMU 采 200 Hz，里程计只采 10 Hz，融合时高频数据浪费了。我建议 IMU 至少 100 Hz，GNSS 至少 5 Hz。
- 忘记标定：IMU 的零偏、里程计的刻度系数，不标定直接采，数据就是垃圾。我吃过这个亏，后来每次采集前先跑标定程序。
- 存储空间不足：有一次采了 2 小时，SD 卡满了，后半段数据全丢了。现在我都会提前算好：1 小时数据大约 1-2 GB，准备 32 GB 以上的卡。
为什么会这样？说白了，数据采集不是「插上电就录」那么简单。你得考虑传感器之间的配合、时间同步、存储策略。我刚开始做的时候也以为很简单，直到被坑了几次才老实。
2.5 知识体系总览
下面这张图，是我自己总结的数据采集知识体系。你照着这个框架去准备，基本不会漏东西。
嗯，数据采集这部分就聊到这儿。记住一句话：垃圾数据进，垃圾结果出。你花在采集上的功夫，后面都会加倍回报给你。