24、传感器融合：车辆传感器（GPS、IMU、轮速），传感器 HAL 与融合算法

各位同学，今天我们来聊聊车载系统里一个非常核心的话题——传感器融合。说实话，在 Android Automotive OS 里，传感器融合是连接物理世界和数字世界的桥梁。没有它，你的导航就是瞎指路，你的自动驾驶辅助就是纸上谈兵。

我个人习惯把传感器融合比作「多感官协同工作」。你想想看，一个人闭着眼睛走路，光靠耳朵听，能走直线吗？很难。但如果眼睛、耳朵、脚底的感觉一起上，那就稳了。车也是一样。

24.1 车辆传感器的三驾马车

在 Automotive 场景下，我们主要依赖三类传感器：GPS、IMU 和轮速传感器。这三者各有各的脾气，也各有各的短板。

24.1.1 GPS：全局定位的锚点

GPS 提供绝对位置信息，精度通常在 2-5 米（开阔环境下）。但它的更新频率很低，一般只有 10Hz 左右。而且一旦进入隧道、高楼林立的街区，信号就会断断续续。

我在项目中遇到过一个典型场景：车辆驶入地下车库，GPS 信号瞬间丢失。这时候如果只靠 GPS，定位直接就漂到隔壁楼去了。所以，GPS 只能当「慢速参考」，不能当实时定位的唯一依赖。

24.1.2 IMU：高频惯性测量单元

IMU 包含加速度计和陀螺仪，更新频率可以到 100Hz 甚至更高。它能提供短时间内的相对位移和姿态变化。但问题也很明显——漂移。IMU 的积分误差会随时间累积，跑个几十秒还行，跑几分钟就完全不准了。

24.1.3 轮速传感器：里程计的核心

轮速传感器（Wheel Speed Sensor）提供的是车辆实际行驶的里程信息。它不像 IMU 那样容易漂移，但受轮胎打滑、胎压变化的影响很大。在湿滑路面或急加速时，轮速传感器会「虚报」里程。

这三类传感器各有优劣，单独拿出来都不靠谱。但把它们融合在一起，就能取长补短。这就是传感器融合的核心思想。

24.2 传感器 HAL：硬件与框架的桥梁

在 Android Automotive OS 里，传感器 HAL（Hardware Abstraction Layer）是连接底层硬件和上层框架的关键。它定义了一套标准接口，让不同厂商的传感器都能被系统统一管理。

传感器 HAL 的核心结构大致如下：

// 传感器 HAL 的核心接口（简化版）
struct sensors_module_t {
    int (*get_sensors_list)(struct sensors_module_t* module,
                            struct sensor_t const** list);
};

struct sensor_t {
    const char*     name;
    const char*     vendor;
    int             version;
    int             handle;
    int             type;       // SENSOR_TYPE_ACCELEROMETER, etc.
    float           maxRange;
    float           resolution;
    float           power;
    int32_t         minDelay;
    uint32_t        fifoReservedEventCount;
    uint32_t        fifoMaxEventCount;
    const char*     stringType;
    const char*     requiredPermission;
    int32_t         maxDelay;
    uint32_t        flags;
    void*           reserved[2];
};

嗯，这里要注意：type 字段决定了传感器类型。在 Automotive 场景下，除了常规的加速度计、陀螺仪，还有专门的 SENSOR_TYPE_GEAR、SENSOR_TYPE_WHEEL_SPEED 等车辆专用传感器类型。

24.3 融合算法：从数据到位置

有了传感器数据，接下来就是融合算法登场了。最常用的方法是卡尔曼滤波（Kalman Filter），尤其是扩展卡尔曼滤波（EKF）和无迹卡尔曼滤波（UKF）。

为什么用卡尔曼滤波？说白了，它能在有噪声的测量值中，估计出最可能的真实状态。它把传感器的「预测」和「观测」结合起来，不断修正误差。

一个简化的融合流程如下：

// 伪代码：传感器融合主循环
while (running) {
    // 1. 预测步骤（基于 IMU + 轮速）
    state = predict(state, imu_data, wheel_speed);
    covariance = predict_covariance(covariance, process_noise);

    // 2. 更新步骤（基于 GPS，如果有新数据）
    if (new_gps_data_available) {
        kalman_gain = compute_kalman_gain(covariance, measurement_noise);
        state = update(state, kalman_gain, gps_measurement);
        covariance = update_covariance(covariance, kalman_gain);
    }

    // 3. 输出融合后的位置和姿态
    output(state);
}

这个循环以 100Hz 的频率运行。GPS 数据进来时，就做一次「校正」；GPS 没数据时，就靠 IMU 和轮速做「预测」。这样即使 GPS 短暂丢失，定位也不会立刻崩掉。

24.4 传感器融合的整体架构

下面这张图展示了传感器融合在 Android Automotive OS 中的整体架构。从底层硬件到上层应用，数据流是单向的，但融合算法会做双向的反馈修正。

从图中可以看到，数据从底层硬件向上流动，经过 HAL 的校准和格式化，进入融合算法模块，最终输出给应用层。同时，融合算法会通过反馈回路，对传感器的偏差进行在线校准。这是一个闭环系统。

24.5 实际项目中的避坑指南

最后，我总结几个实际项目中容易踩的坑，希望能帮你少走弯路：

• 时间戳不同步：不同传感器的时钟源可能不同，必须统一到同一个时间基准。我建议使用 CLOCK_BOOTTIME，它不受系统休眠影响。
• 传感器噪声模型不准确：卡尔曼滤波的效果高度依赖噪声协方差矩阵的设置。如果设置得太小，滤波会「过于自信」，导致轨迹震荡；如果设置得太大，滤波会「过于保守」，导致响应迟钝。
• 忽略传感器失效检测：GPS 信号丢失、IMU 饱和、轮速传感器卡死——这些情况必须被检测到，并动态调整融合策略。否则，一个坏传感器会污染整个融合结果。
• 性能优化：融合算法通常运行在实时线程上，要避免内存分配和锁竞争。我习惯在初始化阶段就分配好所有内存，运行时只做计算，不做分配。