2. 传感器数据采集延迟
好，咱们正式开始聊延迟。第一个要啃的硬骨头，就是传感器数据采集。
你想想看，ADAS系统里，所有决策都依赖传感器数据。如果数据本身就有延迟，那后面的算法再快也没用。我常说一句话：垃圾进，垃圾出。数据采集这关过不了，后面全是白搭。
2.1 摄像头：帧率与曝光时间的博弈
摄像头的数据采集，说白了就是「曝光-读出-传输」三步走。
先说帧率。30fps的摄像头，每帧间隔33.3ms。60fps就是16.7ms。看起来很简单对吧？但这里有个坑：帧率不等于数据可用时间。
我遇到过一位算法同事，他以为30fps的摄像头，每33ms就能拿到一帧新数据。结果实际测试发现，从曝光开始到数据到达处理器，花了将近50ms。为什么？因为曝光时间本身就在消耗帧周期。
关键公式：
摄像头端到端延迟 = 曝光时间 + 读出时间 + 传输时间
曝光时间通常占帧周期的30%-50%。
举个例子。一个60fps的摄像头，帧周期16.7ms。如果曝光时间设为8ms，那留给读出和传输的时间只剩8.7ms。但如果你把曝光时间缩短到2ms呢？信噪比又不行了。这就是个典型的trade-off。
我个人习惯，在项目初期就会和ISP团队确认：你们要的曝光时间范围是多少？ 这直接决定了我们能容忍的最小帧周期。
避坑指南：
我曾经在一个项目中，摄像头供应商说支持120fps。结果一测，120fps下曝光时间只能设到1ms，夜间场景根本没法用。最后只能降到60fps，曝光时间拉到8ms才解决问题。所以，别只看标称帧率，要看实际可用帧率。
2.2 毫米波雷达：多普勒处理带来的固有延迟
毫米波雷达的采集机制和摄像头完全不同。它发射电磁波，接收回波，然后做FFT处理。
这里有个关键点：雷达需要积累多个chirp才能做一次检测。积累的chirp数量越多，信噪比越好，但延迟也越大。
我举个例子。一个典型的77GHz毫米波雷达，参数如下：
| 参数 | 典型值 | 对延迟的影响 |
|---|---|---|
| Chirp周期 | 50μs | 单次测量时间 |
| 每帧chirp数 | 128个 | 帧周期 = 128 × 50μs = 6.4ms |
| FFT处理时间 | 2-3ms | 取决于DSP性能 |
| 总延迟 | 约10ms | 从发射到数据输出 |
你看，雷达的延迟其实比摄像头小很多。但问题在于，雷达的数据是稀疏的——它只输出目标点，不是全画面。这就导致后续的跟踪算法需要做时间对齐。
嗯，这里要注意。雷达的帧率通常可以做到20-30fps，但它的数据是「异步」的。什么意思？就是雷达自己按固定周期采集数据，不管其他传感器在干嘛。这就引出了触发同步的问题。
2.3 激光雷达：旋转机械与固态的差异
激光雷达的延迟，取决于它的扫描方式。
机械旋转式激光雷达，比如Velodyne那种。它有一个旋转的激光头，360度扫描。一帧数据需要旋转一整圈才能完成。如果转速是10Hz，那一帧就是100ms。
但这里有个细节：激光雷达的数据是逐点输出的。不是等一整圈转完才输出，而是每扫到一个点就发出来。所以，如果你只关心前方90度区域，那延迟可以缩短到25ms左右。
固态激光雷达，比如Flash LiDAR或者MEMS扫描的。它们没有机械旋转，帧率可以做到更高，比如30fps。但问题在于视场角受限，通常只有90-120度。
我建议，选型时一定要搞清楚：你的应用场景需要全周扫描还是局部扫描？ 如果是前向感知，固态雷达的延迟优势很明显。如果是360度感知，那机械式的延迟问题就得认真考虑了。
注意：
激光雷达的点云数据量很大。一个32线机械雷达，每秒产生约130万个点。这些数据通过以太网传输时，会有网络延迟。我曾经测过，在千兆以太网下，一帧完整点云的传输时间大约在5-8ms。这个时间也要算进总延迟里。
2.4 触发同步机制：硬件同步信号的重要性
好，现在问题来了。摄像头、雷达、激光雷达，各自按自己的节奏采集数据。那怎么保证它们的数据是「同一时刻」的？
答案就是：硬件触发同步。
我见过太多项目，软件层面做时间戳对齐，结果发现误差有几十毫秒。为什么？因为软件时间戳是在数据到达处理器时才打的，而数据从传感器到处理器，中间经过了各种缓存和传输延迟。
正确的做法是：用硬件信号触发所有传感器同时开始采集。
比如，用一个PPS（Pulse Per Second）信号，或者一个自定义的触发脉冲。所有传感器收到这个脉冲后，立即开始曝光/扫描。这样，所有数据的采集起始时间就是一致的。
硬件触发同步的典型架构：
主控（MCU/FPGA）
│
├── 触发信号（GPIO） → 摄像头1
├── 触发信号（GPIO） → 摄像头2
├── 触发信号（GPIO） → 毫米波雷达
└── 触发信号（GPIO） → 激光雷达但这里有个坑：不同传感器的采集时间不一样。摄像头曝光需要几毫秒，雷达需要积累chirp，激光雷达需要扫描。即使同时触发，数据完成的时间也不同。
我曾经在一个项目中，用硬件触发同时启动了摄像头和激光雷达。结果发现，摄像头的数据在触发后15ms才到，激光雷达的数据在触发后50ms才到。虽然采集起点一致，但终点差了35ms。这35ms对于高速行驶的车辆来说，就是几米的距离误差。
所以，我建议：不仅要同步触发，还要记录每个传感器数据完成的时间戳。这个时间戳最好由传感器硬件自己打，而不是由处理器打。
2.5 硬件接口的延迟特性
数据采集完了，怎么传回来？接口的选择直接影响传输延迟。
| 接口类型 | 典型带宽 | 传输延迟（典型值） | 适用场景 |
|---|---|---|---|
| MIPI CSI-2 | 4-16 Gbps | < 1ms | 摄像头（短距离） |
| LVDS | 1-6 Gbps | < 2ms | 摄像头、雷达（中距离） |
| 以太网（千兆） | 1 Gbps | 2-10ms | 激光雷达、雷达（长距离） |
| 以太网（车载TSN） | 1-10 Gbps | < 1ms | 所有传感器（确定性延迟） |
你看，MIPI的延迟最小，但它只能用于短距离（通常不超过30cm）。以太网延迟大一些，但可以传几十米。
我个人习惯，摄像头尽量用MIPI，因为它的延迟最小，而且有专门的CSI-2协议，支持帧同步信号。雷达和激光雷达用以太网，但一定要选支持TSN（时间敏感网络）的交换机。
经验之谈：
我做过一个项目，摄像头用LVDS传了5米，结果发现信号质量下降，误码率升高，导致丢帧。后来换成MIPI加中继器，问题解决了。所以，接口选型不仅要看延迟，还要看信号完整性。
2.6 总结：数据采集延迟的优化思路
好，咱们把这一章的内容串一下。
- 摄像头：关注曝光时间与帧周期的关系。别只看帧率，要看实际可用帧率。
- 毫米波雷达：多普勒处理需要积累chirp，延迟通常在10ms左右。数据是异步的，需要做时间对齐。
- 激光雷达：机械式延迟大，固态延迟小。点云传输时间也要算进去。
- 触发同步：硬件触发是必须的。但采集完成时间不同，需要硬件时间戳。
- 硬件接口：MIPI延迟最小，以太网延迟大但灵活。TSN是未来的方向。
最后说一句：数据采集延迟是ADAS系统延迟的起点。如果这关没做好，后面再怎么优化算法都是徒劳。我建议，在项目初期就搭建一个延迟测量平台，用示波器或者逻辑分析仪，实际测量每个传感器的采集延迟。别信数据手册，信实测。