17、GPS与传感器驱动开发：QNX GPS驱动框架、Android Location HAL、加速度计/陀螺仪驱动、传感器融合与数据校准
各位同学，今天我们来聊聊车载座舱里一个“看不见但离不开”的模块——GPS与传感器驱动。说实话，很多刚入行的朋友觉得GPS就是收个卫星信号，传感器就是读个寄存器。但真正上车之后，你会发现事情远没那么简单。
我当年第一次做车载导航项目时，GPS在隧道里丢星，出来之后花了整整两分钟才重新定位。产品经理急得跳脚，我蹲在车里调了一整天。后来才发现，问题出在传感器融合的时序上——加速度计的数据没及时喂给GPS模块。嗯，从那以后，我对这套驱动框架就再也不敢马虎了。
17.1 QNX GPS驱动框架：从物理层到应用层
在QNX系统里，GPS驱动不是简单的字符设备。它要处理NMEA协议解析、PPS秒脉冲同步、以及和IMU（惯性测量单元）的数据对齐。我个人习惯把GPS驱动拆成三层：
- 物理层：UART或SPI接口，负责收发原始NMEA语句
- 协议层：解析$GPGGA、$GPRMC等语句，提取经纬度、速度、时间
- 融合层：与加速度计、陀螺仪数据做时间戳对齐，输出融合后的位置
下面是一个简化的QNX GPS资源管理器驱动框架图，我用SVG画出来，方便你理解整体结构：
在QNX下，我通常用resmgr_attach()注册一个路径，比如/dev/gps0。然后开一个线程循环读取UART数据。这里有个坑——GPS模块的波特率经常是9600或115200，但有些模块上电后默认是自动波特率检测。我曾经遇到过模块和驱动“握手”失败，导致一直收不到数据。解决办法是在驱动初始化时先发一条$PUBX,41,1,0007,0003,115200,0*1A之类的配置语句，强制锁定波特率。
核心要点：QNX GPS驱动的关键不在于读数据，而在于时间戳的精度。PPS（秒脉冲）引脚必须接到GPIO中断上，用ClockTime()打上硬件时间戳，否则后续融合全是错的。
17.2 Android Location HAL：桥接GPS与Framework
到了Android Automotive这边，GPS驱动变成了HAL（硬件抽象层）。Google定义了一套hardware/libhardware/include/hardware/gps.h接口，我们只需要实现里面的回调函数。
说白了，Android Location HAL就是一个“翻译官”。它把QNX底层传上来的NMEA数据，转成Android Framework能理解的GpsLocation结构体。我建议你重点关注这几个回调：
location_callback()：上报经纬度、海拔、速度status_callback()：报告GPS状态（比如搜到几颗星）nmea_callback()：透传原始NMEA语句，给调试用
下面是一个简化的HAL实现片段，注意看我是怎么把QNX的驱动数据“喂”给Android的：
// gps_hal.c - Android Location HAL 实现片段
static void gps_hal_init(GpsCallbacks* callbacks) {
// 保存回调函数指针
s_gps_callbacks = *callbacks;
// 启动QNX端GPS驱动读取线程
pthread_t tid;
pthread_create(&tid, NULL, gps_read_thread, NULL);
}
static void* gps_read_thread(void* arg) {
int fd = open("/dev/gps0", O_RDWR);
char buf[256];
while (1) {
// 从QNX驱动读取NMEA数据
int len = read(fd, buf, sizeof(buf));
if (len > 0) {
// 解析NMEA，提取位置信息
GpsLocation loc;
parse_nmea(buf, &loc);
// 通过HAL回调上报给Framework
s_gps_callbacks.location_cb(&loc);
}
}
return NULL;
}个人经验：在Android HAL层，我习惯加一个“数据质量检查”逻辑。比如经纬度如果都是0.0，或者速度超过500km/h，直接丢弃不上报。否则导航APP会画出一些匪夷所思的轨迹——我见过测试车“飞”到海里的案例。
17.3 加速度计与陀螺仪驱动：IMU的底层实现
IMU（惯性测量单元）是传感器融合的另一条腿。车载上常用的有BMI160、ICM-20602这些芯片。驱动开发的核心就两件事：配置寄存器、读取FIFO数据。
加速度计和陀螺仪的数据读取方式不太一样。加速度计变化慢，但容易受振动干扰；陀螺仪响应快，但会有零偏漂移。我一般在QNX下用SPI或I2C来读，开一个高优先级的中断线程。
下面是一个典型的加速度计初始化流程：
// imu_driver.c - 加速度计初始化
int imu_init(void) {
// 1. 复位传感器
i2c_write(IMU_ADDR, REG_PWR_MGMT_1, 0x80);
delay_ms(100);
// 2. 设置量程：±4g
i2c_write(IMU_ADDR, REG_ACCEL_CONFIG, 0x08);
// 3. 设置输出数据速率：100Hz
i2c_write(IMU_ADDR, REG_ACCEL_SMPLRT_DIV, 0x09);
// 4. 使能数据就绪中断
i2c_write(IMU_ADDR, REG_INT_ENABLE, 0x01);
return 0;
}注意：IMU的FIFO缓冲区很容易溢出。如果你用100Hz采样率，但应用层读取不及时，FIFO满了之后老数据会被新数据覆盖。我曾经在高速测试时发现定位突然跳变，查了两天才找到原因——FIFO溢出导致时间戳错乱。解决办法是加大FIFO阈值，或者用DMA方式读取。
17.4 传感器融合与数据校准：让1+1>2
单独用GPS，隧道里就抓瞎。单独用IMU，几分钟就漂到天边。所以必须做融合。最经典的算法是卡尔曼滤波（Kalman Filter），但车载上我更推荐扩展卡尔曼滤波（EKF），因为车辆运动是非线性的。
融合的核心逻辑其实不复杂：
- GPS提供绝对位置（低频，但有漂移）
- 加速度计提供线性加速度（高频，但有噪声）
- 陀螺仪提供角速度（用于推算航向）
- EKF把这三者“揉”在一起，输出最优估计
但这里有个前提——数据必须校准。加速度计有零偏和尺度因子误差，陀螺仪有零偏。我分享一个我在项目中用过的六面校准法：
| 校准步骤 | 传感器朝向 | 理论值 | 实际采集值 |
|---|---|---|---|
| 1 | X轴向上 | (+1g, 0, 0) | (+0.98g, +0.02g, -0.01g) |
| 2 | X轴向下 | (-1g, 0, 0) | (-1.01g, -0.01g, +0.01g) |
| 3 | Y轴向上 | (0, +1g, 0) | (+0.01g, +0.99g, -0.02g) |
| 4 | Y轴向下 | (0, -1g, 0) | (-0.01g, -1.02g, +0.01g) |
| 5 | Z轴向上 | (0, 0, +1g) | (+0.02g, -0.01g, +0.97g) |
| 6 | Z轴向下 | (0, 0, -1g) | (-0.01g, +0.01g, -1.03g) |
拿到这六组数据后，用最小二乘法拟合出零偏和尺度因子。校准完之后，加速度计的精度能从±100mg提升到±10mg以内。嗯，这个步骤千万别省，否则融合出来的位置误差会让你怀疑人生。
避坑指南：我曾经在量产前发现一批车的GPS定位总是偏东2米。查到最后，是陀螺仪的安装角度偏差了0.5度。0.5度看起来很小，但车辆开出去1公里，横向误差就接近9米。所以，传感器融合前一定要做“安装角度校准”——把车开直线，对比GPS航向和陀螺仪积分航向，算出安装偏角。
17.5 实战中的融合策略选择
最后聊聊融合策略。不是所有场景都适合用EKF。我总结了几种常见方案：
- 城市道路（有GPS信号）：用松耦合，GPS修正IMU漂移，IMU填补GPS更新间隙
- 隧道/地下车库（无GPS）：用紧耦合，IMU+轮速计做航位推算（Dead Reckoning），撑个几分钟没问题
- 高速路（高动态）：用EKF，状态向量要包含速度和加速度，否则跟不上车辆急加速
我个人习惯在QNX侧做一个“融合引擎”守护进程，它同时监听GPS驱动和IMU驱动的消息队列，然后以100Hz的频率输出融合后的位置。Android侧只需要通过Socket或共享内存来读这个结果就行。这样解耦之后，即使GPS模块换型号，Android上层代码一行都不用改。
好了，这一章的内容就到这里。GPS和传感器驱动看似基础，但真正做好融合、校准、时间同步，需要花不少功夫。希望今天分享的这些实战经验，能帮你少走一些弯路。