第十三章 车载传感器系统：车辆传感器类型、SensorManager 在车机中的使用、融合定位

各位同学，欢迎来到车载传感器系统这一章。

说实话，传感器这块内容，在手机开发中可能只是「锦上添花」—— 比如屏幕旋转、计步器这些。但在车机里，传感器是「雪中送炭」，甚至可以说是「保命」的。你想想看，没有精准的车辆姿态数据，导航怎么敢让你变道？没有轮速脉冲，里程表怎么敢算剩余续航？

我当年从手机 Framework 转到车载时，第一个被问懵的问题就是：「你知不知道车辆横摆角速度怎么从 CAN 总线上拿？」 嗯，当时我确实不知道。后来踩了不少坑，才慢慢摸清这套体系。今天我把这些经验整理出来，希望能帮你少走弯路。

13.1 车载传感器的「家族图谱」

车载传感器，说白了就是车辆的「五官」。它们负责感知车辆自身状态和周围环境。我们做系统开发的，主要关心两大类：

• 车身状态传感器：车速、轮速、方向盘转角、横摆角速度、加速度、档位、刹车踏板位置等。
• 环境感知传感器：GPS、摄像头、毫米波雷达、激光雷达、超声波雷达等。

但在 Android Automotive 的 SensorManager 框架里，我们主要处理的是第一类 —— 车身状态传感器。环境感知传感器通常走单独的感知算法栈，不会直接暴露给 App 层。

我整理了一个常用车载传感器的表格，方便你对照：

13.2 SensorManager 在车机中的「正确打开方式」

Android Automotive 的 SensorManager 接口，和手机上的 SensorManager 在 API 层面几乎一样。但背后的 HAL 层实现完全不同。

手机上的传感器 HAL 直接读取芯片寄存器。车机上的传感器 HAL，则要通过 Vehicle HAL（Vehicle Hardware Abstraction Layer）从 CAN 总线或以太网中获取数据。

我画了一张图，帮你理清这个数据流：

从这张图你能看到，App 层调用 SensorManager 注册监听器后，数据流是：物理传感器 → CAN 总线 → Vehicle HAL → SensorService → App。中间每一层都可能引入延迟和噪声。

13.2.1 注册传感器监听

代码层面，和手机开发几乎一样。但有一个关键区别：采样率。

手机上的传感器采样率可以很高（比如 200Hz 甚至 1000Hz）。但在车机上，CAN 总线的数据更新频率通常只有 20Hz ~ 100Hz。你注册一个 200Hz 的监听器，底层也拿不到那么快的数据。

我建议的做法是：

// 获取 SensorManager
SensorManager sensorManager = (SensorManager) context.getSystemService(Context.SENSOR_SERVICE);

// 获取车辆速度传感器
Sensor vehicleSpeedSensor = sensorManager.getDefaultSensor(Sensor.TYPE_VEHICLE_SPEED);
if (vehicleSpeedSensor == null) {
    // 处理传感器不可用的情况
    Log.w(TAG, "车辆速度传感器不可用，请检查 Vehicle HAL 配置");
    return;
}

// 注册监听器，采样率建议使用 SENSOR_DELAY_NORMAL 或 SENSOR_DELAY_UI
// 不要使用 SENSOR_DELAY_FASTEST，因为底层数据更新率有限
sensorManager.registerListener(this, vehicleSpeedSensor, SensorManager.SENSOR_DELAY_NORMAL);

13.2.2 处理传感器事件

onSensorChanged 回调中，你会拿到 SensorEvent。这里要注意：车机传感器的事件时间戳，通常来自 CAN 总线的时间，而不是 Android 系统时间。

@Override
public void onSensorChanged(SensorEvent event) {
    if (event.sensor.getType() == Sensor.TYPE_VEHICLE_SPEED) {
        float speedMps = event.values[0]; // 单位：米/秒
        long timestamp = event.timestamp;  // 注意：这是 CAN 总线时间戳
        
        // 转换为公里/小时
        float speedKmph = speedMps * 3.6f;
        
        // 更新 UI 或传递给算法模块
        updateSpeedDisplay(speedKmph);
    }
}

13.3 融合定位：从「能用」到「好用」

融合定位，说白了就是「用多种传感器互相弥补，得到更准确的位置信息」。GPS 在隧道里没信号，IMU 会漂移，轮速脉冲受轮胎磨损影响 —— 单独用哪一个都不靠谱。

我参与过一个项目，客户要求「隧道内定位误差不超过 5 米」。单靠 GPS 肯定不行，单靠 IMU 推算 500 米隧道后误差可能到 50 米。最后我们用了「GPS + IMU + 轮速脉冲 + 方向盘转角」的四元融合方案。

13.3.1 融合定位的常见架构

目前业界主流的融合定位架构有两种：

• 松耦合（Loosely Coupled）：各传感器独立输出位置/速度，然后用卡尔曼滤波做加权融合。实现简单，但精度一般。
• 紧耦合（Tightly Coupled）：直接融合原始观测值（比如 GPS 伪距、IMU 加速度、轮速脉冲）。精度高，但算法复杂，计算量大。

在 Android Automotive 平台上，Google 提供了 android.car.CarSensorManager 和 android.car.VehiclePropertyIds 来获取原始传感器数据。但融合算法需要自己实现，或者集成第三方的定位 SDK。

我画了一张融合定位的流程图：

13.3.2 在 Android Automotive 中实现融合定位

如果你要在车机上自己实现融合定位，我建议的步骤是：

1. 通过 CarSensorManager 获取原始数据：包括车速、轮速、方向盘转角、IMU 数据。
2. 通过 LocationManager 获取 GPS 数据：注意设置合适的 LocationRequest，比如优先使用 GPS_PROVIDER。
3. 实现时间戳对齐：将所有传感器数据的时间戳统一到同一个时间基准（比如 GPS 时间）。
4. 实现卡尔曼滤波：状态量通常包括位置 (x, y)、速度 (vx, vy)、航向角 (yaw)。观测量来自 GPS 和轮速。
5. 输出融合结果：可以封装成一个 ContentProvider 或者直接通过回调传给导航模块。

这里有一个简化版的卡尔曼滤波伪代码，帮你理解核心逻辑：

// 简化版卡尔曼滤波 - 仅用于理解原理
class KalmanFilter {
    // 状态向量: [x, y, vx, vy, yaw]
    Matrix state;
    // 协方差矩阵
    Matrix covariance;
    
    void predict(float dt) {
        // 根据 IMU 和轮速推算下一时刻状态
        // state = F * state + B * control
        // covariance = F * covariance * F^T + Q
    }
    
    void updateGPS(Location gps) {
        // 用 GPS 观测值修正状态
        // K = covariance * H^T * (H * covariance * H^T + R)^-1
        // state = state + K * (z - H * state)
        // covariance = (I - K * H) * covariance
    }
    
    void updateWheelSpeed(float wheelSpeed) {
        // 用轮速脉冲修正速度分量
        // 类似 GPS 更新，但观测模型不同
    }
}

13.4 总结

车载传感器系统，说白了就是「用数据感知车辆状态」。SensorManager 在车机上的用法和手机类似，但背后的数据源、采样率、时间戳处理都有很大差异。融合定位则是把多个传感器的数据「拧成一股绳」，得到更可靠的位置信息。

嗯，这一章的内容就到这里。记住：做车载传感器开发，一定要理解数据从「物理世界」到「App 层」的完整链路。只有理解了每一层的特性和限制，才能写出稳定可靠的代码。

公众号:蓝海资料掘金营，微信deep3321