第4章车载传感器HAL适配

第4章车载传感器HAL适配：GPS/IMU/轮速传感器HAL实现、传感器融合框架、虚拟传感器调试

各位好，我是老张。今天咱们聊聊车载传感器HAL适配。说实话，这一章是整车系统移植里最让我头疼，也最有成就感的部分。GPS、IMU、轮速传感器，这三个家伙凑在一起，就是车辆感知的「铁三角」。我当年在某个量产项目上，就因为IMU的HAL层一个参数配错了，导致车辆在隧道里定位漂移了十几米……嗯，从那以后我对这块就格外小心。

4.1 车载传感器HAL架构概览

Android Automotive的传感器架构，说白了就是三层：应用层、框架层、HAL层。我们嵌入式工程师主要跟HAL层打交道。它位于Linux内核和Android框架之间，负责把硬件数据「翻译」成框架能理解的格式。

我个人习惯把HAL实现分成三步：

第一步：定义传感器类型和通道。比如GPS用NMEA协议，IMU用I2C/SPI，轮速传感器用CAN总线。
第二步：实现HAL接口函数。主要是open_sensors、poll、activate这几个。
第三步：注册到传感器服务。这一步容易忘，我吃过亏。

核心要点：车载传感器HAL必须支持多实例。因为一辆车可能有多个GPS天线、多个IMU模块。Android框架默认只支持单实例，你得在sensors.h里把numSensors设对。

4.2 GPS传感器HAL实现

GPS这块，Android原生用的是IGnss.hal接口。但车载场景下，我们往往需要同时支持GPS+北斗+GLONASS。我建议的做法是：

// 伪代码：GPS HAL初始化
struct gps_device_t {
    const struct hw_module_t *common;
    int (*init)(struct gps_device_t *dev);
    int (*start)(struct gps_device_t *dev);
    int (*stop)(struct gps_device_t *dev);
    void (*inject_time)(GpsUtcTime time, int64_t timeReference, int uncertainty);
};

// 实际项目中，我习惯把NMEA解析器单独抽出来
static int gps_start(struct gps_device_t *dev) {
    // 打开串口，波特率9600
    // 启动NMEA数据接收线程
    // 注意：这里要处理GPS冷启动和热启动的区别
    return 0;
}

你想想看，GPS最坑的是什么？是定位延迟。我遇到过一辆车，GPS数据从硬件到HAL层走了200ms，导致导航箭头永远滞后。后来发现是HAL层里加了个不必要的sleep(100)……

调试技巧：用adb shell dumpsys sensorservice查看传感器数据延迟。如果看到GPS的延迟超过100ms，赶紧查HAL层的poll循环。

4.3 IMU传感器HAL实现

IMU（惯性测量单元）包括加速度计和陀螺仪。车载IMU和手机IMU最大的区别是什么？是量程。手机加速度计量程一般是±2g，车载得±8g甚至±16g。为什么？因为车辆急刹车时加速度能到1g以上，过减速带时冲击更大。

我记得在某个项目里，IMU的HAL层直接用了手机端的配置，结果车辆一过减速带，数据直接饱和。嗯，后来我们改成了±16g量程，问题解决。

// IMU HAL关键代码：数据校准
static int imu_poll(sensors_event_t *data, int count) {
    // 读取原始数据
    int16_t accel_x_raw = read_register(ACCEL_X_OUT);
    int16_t accel_y_raw = read_register(ACCEL_Y_OUT);
    int16_t accel_z_raw = read_register(ACCEL_Z_OUT);
    
    // 应用校准参数（从EEPROM读取）
    // 我习惯把校准参数放在/sensor_calib/目录下
    float accel_x = (accel_x_raw - calib.accel_offset[0]) * calib.accel_scale[0];
    float accel_y = (accel_y_raw - calib.accel_offset[1]) * calib.accel_scale[1];
    float accel_z = (accel_z_raw - calib.accel_offset[2]) * calib.accel_scale[2];
    
    // 填充传感器事件
    data->type = SENSOR_TYPE_ACCELEROMETER;
    data->acceleration.x = accel_x;
    data->acceleration.y = accel_y;
    data->acceleration.z = accel_z;
    data->timestamp = get_current_ns();
    
    return 1;
}

注意：IMU的零偏校准必须在车辆静止时进行。我曾经在HAL层里加了个自动校准逻辑，结果车辆在行驶中误触发了校准，导致后续所有数据都偏了。后来我加了个条件：车速为0且发动机熄火时才允许校准。

4.4 轮速传感器HAL实现

轮速传感器，说白了就是ABS系统用的那个。它通过CAN总线发送数据，频率一般是100Hz。Android Automotive里，轮速数据主要用于里程计算和航位推算。

实现轮速传感器HAL，核心是解析CAN报文。我一般这么干：

// 轮速传感器HAL：CAN报文解析
static void can_message_handler(const struct can_frame *frame) {
    // 假设CAN ID 0x0A0是左前轮速
    if (frame->can_id == 0x0A0) {
        // 数据格式：Byte0-1为轮速值，单位0.01km/h
        uint16_t raw = (frame->data[0] << 8) | frame->data[1];
        float wheel_speed = raw * 0.01f;
        
        // 更新传感器事件
        sensors_event_t event;
        event.type = SENSOR_TYPE_WHEEL_SPEED;
        event.data[0] = wheel_speed;
        event.timestamp = get_current_ns();
        
        // 放入事件队列
        enqueue_event(&event);
    }
}

这里有个坑：轮速数据是离散的，每个轮子独立。但Android框架期望的是车辆速度。所以你得在HAL层做个融合：取四个轮子的平均值，或者用非驱动轮的速度（更准确）。

经验之谈：轮速传感器最容易出问题的是CAN总线丢帧。我建议在HAL层加个超时检测：如果连续10个周期没收到CAN报文，就报错并切换到备用传感器（比如IMU推算）。

4.5 传感器融合框架

传感器融合，说白了就是把GPS、IMU、轮速数据揉在一起，得到更准确的定位和姿态。Android Automotive里有个SensorFusion服务，但说实话，它太简单了，只适合手机。

车载场景下，我推荐用卡尔曼滤波或者粒子滤波。这里给个简单的融合思路：

传感器	优势	劣势	融合权重
GPS	绝对位置，无累积误差	更新慢（1-10Hz），易受遮挡	开阔区域高，隧道内低
IMU	更新快（100-1000Hz），短时精度高	有漂移，长时间误差累积	短时高，长时低
轮速	速度准确，不受GPS遮挡影响	只能测速度，不能测方向	始终中等

我习惯用扩展卡尔曼滤波（EKF）。状态量包括位置、速度、姿态、陀螺零偏。观测量包括GPS位置、轮速、加速度。嗯，这里要注意：EKF的协方差矩阵初始化很关键，设大了收敛慢，设小了容易发散。

// 伪代码：EKF预测步骤
void ekf_predict(float dt) {
    // 状态预测：根据IMU加速度和角速度
    state.x += state.vx * dt + 0.5 * accel_x * dt * dt;
    state.y += state.vy * dt + 0.5 * accel_y * dt * dt;
    state.vx += accel_x * dt;
    state.vy += accel_y * dt;
    
    // 协方差预测
    P = F * P * F.transpose() + Q;
}

// EKF更新步骤
void ekf_update_gps(float gps_x, float gps_y) {
    // 计算卡尔曼增益
    K = P * H.transpose() * (H * P * H.transpose() + R).inverse();
    // 更新状态
    state.x += K(0,0) * (gps_x - state.x);
    state.y += K(1,0) * (gps_y - state.y);
    // 更新协方差
    P = (I - K * H) * P;
}

调试建议：融合算法的调试，我建议用MATLAB或者Python先离线跑一遍。把实车采集的GPS、IMU、轮速数据导出来，在PC上验证算法正确性，再移植到嵌入式平台。这样能省很多时间。

4.6 虚拟传感器调试

虚拟传感器，说白了就是软件模拟的传感器。在开发阶段，没有实车怎么办？用虚拟传感器。Android Automotive支持sensorservice的虚拟传感器模式。

我一般这么搞：

在HAL层实现一个虚拟传感器模块，读取模拟数据文件
数据文件格式：时间戳、传感器类型、数据值
通过adb shell setprop切换真实/虚拟模式

// 虚拟传感器：从文件读取模拟数据
static int virtual_sensor_poll(sensors_event_t *data, int count) {
    static FILE *fp = NULL;
    if (!fp) {
        fp = fopen("/data/virtual_sensor_data.csv", "r");
        if (!fp) return 0;
    }
    
    char line[256];
    if (fgets(line, sizeof(line), fp)) {
        // 解析CSV：timestamp,type,x,y,z
        sscanf(line, "%ld,%d,%f,%f,%f", 
               &data->timestamp, &data->type,
               &data->data[0], &data->data[1], &data->data[2]);
        return 1;
    }
    return 0;
}

我曾经用虚拟传感器模拟了车辆在隧道里行驶的场景。GPS信号逐渐变弱，IMU和轮速接管定位。这个测试帮我们发现了一个融合算法的bug：当GPS信号恢复时，位置跳变太大，导致导航界面闪烁。后来加了平滑过渡逻辑才解决。

注意：虚拟传感器的时间戳必须模拟真实场景。我见过有人直接用gettimeofday，结果虚拟数据的时间间隔是固定的，跟真实传感器完全不一样。建议用真实采集的时间戳回放。

4.7 调试与验证

调试传感器HAL，我常用的工具：

sensorservice的dump功能：adb shell dumpsys sensorservice
getevent：查看原始传感器事件
自定义log：在HAL层加ALOGD打印关键数据
CAN总线监控：用candump抓取CAN报文

验证标准：

GPS定位精度：静态下<5米，动态下<10米
IMU零偏稳定性：<0.1°/s（陀螺仪），<0.01g（加速度计）
轮速精度：<1%误差
融合定位：隧道内200米内误差<20米

嗯，这一章内容不少。传感器HAL适配是车载系统移植的硬骨头，但也是最有技术含量的部分。你想想看，一辆车能不能安全地自动驾驶，很大程度上取决于传感器数据准不准。所以，咱们做HAL的，责任重大啊。

下一章我会讲车载音频系统的移植，包括音频路由、回声消除、噪声抑制这些。到时候见。

📚 课程目录