第二章 数据采集系统：传感器配置与硬件架构
大家好，我是你们的老朋友。今天我们来聊聊数据采集系统——说白了，就是自动驾驶车的「眼睛」和「耳朵」怎么装、怎么连。
我记得刚入行那会儿，总觉得传感器越多越好。后来踩过坑才明白，配置不合理，数据再多也是垃圾。嗯，咱们今天就把这事掰扯清楚。
2.1 传感器配置：各司其职的「感官」
一辆典型的L4级自动驾驶车，传感器配置大概长这样。我习惯把它们分成三类：
- 环境感知类：摄像头、激光雷达、毫米波雷达
- 定位类：IMU（惯性测量单元）、GPS（全球定位系统）
- 车身状态类：轮速传感器、方向盘转角传感器等
你想想看，如果只有摄像头，晚上或者大雾天就抓瞎了。如果只有激光雷达，那红绿灯的颜色又识别不了。所以，传感器融合不是选择题，而是必答题。
2.1.1 摄像头
摄像头是成本最低、信息最丰富的传感器。但它的缺点也很明显——怕暗、怕逆光、怕雨雾。
我在项目中遇到过一个问题：某款车在隧道出口处，因为光线突变，摄像头直接「失明」了大概0.5秒。这0.5秒在高速上就是十几米的盲区。后来我们加了HDR（高动态范围）摄像头，才勉强解决。
配置建议：
- 前视：至少2个（广角+长焦），覆盖30°-120°视野
- 环视：4个鱼眼摄像头，用于泊车和低速场景
- 侧视：2个，覆盖盲区
- 后视：1个，用于变道辅助
分辨率：建议不低于200万像素，帧率20-30fps
2.1.2 激光雷达
激光雷达是「精度担当」。它能直接输出3D点云，不受光照影响。但价格嘛……嗯，以前一颗64线要几十万，现在国产化后便宜多了。
我个人的经验是：激光雷达的线束密度比探测距离更重要。为什么？因为城区场景下，你需要看清行人、自行车这些小目标。128线比16线能多识别出30%以上的小物体。
| 参数 | 典型值 | 我的建议 |
|---|---|---|
| 线束 | 16/32/64/128 | 至少64线，推荐128线 |
| 探测距离 | 100-300m | 前向200m+，侧向80m足够 |
| 视场角 | 水平360°/垂直30° | 水平覆盖360°，垂直覆盖-15°~+15° |
| 帧率 | 10-20Hz | 10Hz够用，20Hz更流畅 |
小技巧：激光雷达的安装位置很关键。车顶是最佳位置，但会牺牲美观。前保险杠位置也可以，但容易被泥水遮挡。我曾经见过一个方案，把激光雷达藏在进气格栅后面——结果散热和振动问题一大堆。
2.1.3 毫米波雷达
毫米波雷达是「速度专家」。它直接输出目标的速度信息，这是摄像头和激光雷达做不到的。而且它穿透雨雾的能力很强。
但毫米波雷达也有坑——对静止目标不敏感。我记得有一次测试，车前面停了一辆白色货车，毫米波雷达愣是没检测到。后来查原因，是因为静止目标的多普勒频移为零，被雷达的滤波器给滤掉了。
避坑指南：我曾经因为毫米波雷达的「静止目标漏检」问题，差点导致一次碰撞测试失败。解决方案是：
- 使用4D成像雷达，能检测高度信息
- 与激光雷达做深度融合，互相弥补
- 在算法层面，不要完全依赖雷达的「静止目标过滤」功能
2.1.4 IMU/GPS
IMU和GPS是定位系统的「黄金搭档」。GPS提供绝对位置，但更新频率低（10Hz），而且容易受高楼遮挡。IMU提供高频的相对运动信息（100-200Hz），但会随时间漂移。
我习惯的做法是：用GPS做长期校准，用IMU做短期推算。两者通过卡尔曼滤波融合，就能得到稳定且高频的定位结果。
这里有个细节要注意：IMU的零偏稳定性。便宜的MEMS IMU，零偏漂移能达到10°/h，跑10分钟就偏了1.7°。换算到100米外，就是3米的误差。所以，IMU的选型不能省。
2.2 数据采集硬件架构
传感器选好了，怎么把它们的数据「收」回来？这就涉及到硬件架构了。
我见过最「暴力」的方案：每个传感器直接连一台工控机，用USB线。结果线缆乱成一团，数据同步也做不好。后来我们学乖了，用车载以太网做主干网络。
2.2.1 典型架构
一个成熟的数据采集系统，大概长这样：
传感器层 → 数据汇聚层 → 计算存储层 → 监控显示层
传感器层：
- 摄像头：通过GMSL（千兆多媒体串行链路）或FPD-Link传输
- 激光雷达：通过以太网（UDP协议）传输
- 毫米波雷达：通过CAN（控制器局域网）或以太网传输
- IMU/GPS：通过串口或CAN传输
数据汇聚层：
- 使用车载交换机（支持TSN时间敏感网络）
- 数据同步：PTP（精确时间协议）或GPS PPS（秒脉冲）信号
计算存储层：
- 工控机或嵌入式平台（如NVIDIA Drive、华为MDC）
- 存储：NVMe SSD，容量至少2TB，支持热插拔
监控显示层：
- 实时显示传感器状态、数据流、存储进度
- 支持远程监控（4G/5G网络）2.2.2 数据同步：最容易被忽视的坑
数据同步是数据采集的「灵魂」。如果摄像头和激光雷达的时间戳对不上，回放分析时就会看到「车在动，但点云不动」的诡异现象。
我踩过最大的坑就是：不同传感器的时钟源不一致。摄像头用电脑时间，激光雷达用GPS时间，IMU用自己的晶振。结果三个数据的时间戳差了50ms。50ms在60km/h的速度下，就是0.83米的位移误差。
解决方案：
- 所有传感器统一使用GPS的PPS信号作为硬件同步信号
- 使用PTP协议（IEEE 802.1AS）做网络时间同步
- 在数据包中打上硬件时间戳，而不是软件时间戳
- 采集完成后，做一次时间戳对齐校验
2.2.3 数据存储与带宽
数据采集的带宽需求，比你想象的大得多。我算一笔账给你看：
| 传感器 | 单路带宽 | 数量 | 总带宽 |
|---|---|---|---|
| 摄像头（200万像素，30fps） | ~200 MB/s | 9路 | ~1.8 GB/s |
| 激光雷达（128线） | ~40 MB/s | 1个 | ~40 MB/s |
| 毫米波雷达 | ~1 MB/s | 5个 | ~5 MB/s |
| IMU/GPS | ~0.1 MB/s | 1套 | ~0.1 MB/s |
| 总计 | ~1.85 GB/s |
看到没？一小时的数据就是6.66TB。所以，数据压缩和选择性存储是必须的。我一般会：
- 摄像头视频用H.265压缩，压缩比约10:1
- 激光雷达点云用点云压缩算法（如Draco）
- 只保存「感兴趣区域」的数据，比如触发事件前后30秒
- 使用RAID 0阵列，提升写入速度
我的习惯：在采集车上装一个「数据健康监控」界面。实时显示每个传感器的数据流状态、存储剩余空间、温度、电压。一旦发现异常，立即报警。这个习惯帮我避免过好几次「采集了一整天，结果数据全是坏的」的悲剧。
2.3 小结
好了，今天的内容就到这里。总结一下：
- 传感器配置：摄像头负责「看」，激光雷达负责「测距」，毫米波雷达负责「测速」，IMU/GPS负责「定位」。缺一不可。
- 硬件架构：用车载以太网做主干，用PTP或PPS做时间同步，用NVMe SSD做存储。
- 避坑：数据同步是灵魂，带宽是瓶颈，压缩是必须。
下一章，我们会聊数据回放系统的设计。到时候我会分享一个我亲手搭建的回放工具，保证让你眼前一亮。
有什么问题，欢迎在评论区留言。咱们下期见！
公众号:蓝海资料掘金营，微信deep3321