10、位置服务与GNSS：车载定位系统架构、融合定位（GPS+IMU+轮速）、AGPS
各位好，我是老张。今天我们来聊聊车载定位。说实话，在Android Automotive里，定位模块是我个人觉得最“拧巴”的一块。为什么？因为手机定位不准，大不了你骂一句“破导航”；但车机定位不准，那可是要出事的。你想想看，高速上错过一个匝道，多跑几十公里都是轻的。
所以，车载定位系统，从来不是“有个GPS就行”这么简单。它是一套组合拳。今天我就把这套拳法的套路，掰开了讲给你听。
10.1 车载定位系统架构：不只是“搜星”
先看整体架构。车载定位系统，说白了就是三个层次：
- 传感器层：GPS/BDS/Galileo等GNSS芯片、IMU（惯性测量单元）、轮速传感器、甚至摄像头和雷达。
- 融合层：也叫定位引擎。它把上面这些乱七八糟的数据揉在一起，算出一个最优的位置。
- 应用层：地图导航、ADAS（高级驾驶辅助）、V2X（车路协同）等。
嗯，这里要注意：Android Automotive的定位服务，其实跑在融合层之上。它通过标准的LocationManager接口，向应用层提供位置数据。但底层是谁在干活？是硬件抽象层（HAL）里的gnss和vehicle服务。
核心要点：车载定位的“灵魂”在融合层，不在GNSS芯片本身。芯片只输出原始数据，融合算法才是决定精度的关键。
我画了一张架构图，帮你理清关系：
10.2 融合定位：GPS+IMU+轮速，缺一不可
为什么一定要融合？我举个真实例子。有一次我在深圳的华强北地下停车场测试，GPS信号完全丢失。如果只靠GPS，定位直接就飘到隔壁楼去了。但车机依然能准确显示我在B2层，靠的就是IMU和轮速。
融合定位的核心逻辑，其实就一句话：用IMU和轮速填补GNSS的盲区，用GNSS校正IMU的累积误差。
10.2.1 各传感器角色
| 传感器 | 优势 | 劣势 | 典型场景 |
|---|---|---|---|
| GNSS | 绝对位置，无累积误差 | 易受遮挡，更新率低（1-10Hz） | 开阔道路、高速 |
| IMU | 高更新率（100-1000Hz），不受环境干扰 | 有漂移，长时间积分误差大 | 隧道、地下车库、高楼峡谷 |
| 轮速 | 直接测量车速，低成本 | 只能测前进方向，无法测横向 | 城市道路、拥堵路段 |
你看，这三者正好互补。GNSS是“定海神针”，IMU是“短跑健将”，轮速是“老实人”。融合算法就是让它们仨好好配合。
10.2.2 融合算法：卡尔曼滤波的变种
业界最常用的，还是扩展卡尔曼滤波（EKF）。不过，我建议你关注一下因子图优化（Factor Graph）。为什么？因为EKF对非线性系统的处理比较粗暴，而因子图可以更灵活地融合多传感器数据，尤其适合视觉+IMU+GNSS的组合。
下面是一个简化版的融合定位伪代码，展示了核心逻辑：
// 伪代码：融合定位主循环
while (vehicle_running) {
// 1. 读取传感器数据
gnss_data = readGnss(); // 经纬度、速度、精度
imu_data = readImu(); // 加速度、角速度
wheel_speed = readWheel(); // 轮速脉冲
// 2. 时间对齐（重要！）
sync_data = timeSync(gnss_data, imu_data, wheel_speed);
// 3. 预测步骤（IMU+轮速推算）
predicted_state = predict(imu_data, wheel_speed, last_state);
// 4. 更新步骤（用GNSS修正）
if (gnss_data.accuracy < 5.0) { // 精度好才更新
corrected_state = update(predicted_state, gnss_data);
} else {
corrected_state = predicted_state; // 精度差，纯靠推算
}
// 5. 输出位置
outputLocation(corrected_state);
}
避坑指南：我曾经在时间同步上栽过大跟头。IMU和GNSS的时间戳如果不对齐，融合出来的位置会剧烈抖动。解决办法是：在HAL层就统一用硬件时间戳，不要依赖系统时间。
10.3 AGPS：让冷启动不再“冷”
AGPS（辅助GPS）这个概念，手机用户可能不陌生。但在车上，它的意义更大。为什么？因为车机启动时，GNSS芯片需要搜星。如果是在地库或者高楼林立的街道，冷启动可能要花1-2分钟才能定位。这在导航场景下是不可接受的。
AGPS的原理，说白了就是“作弊”。它通过网络（蜂窝网络或Wi-Fi）提前下载卫星星历和历书，告诉芯片“卫星大概在哪个方向”。这样，芯片不用盲目搜星，定位时间可以从分钟级降到秒级。
在Android Automotive里，AGPS的实现依赖GnssNetworkConnectivity和GnssAntennaInfo等API。我建议你重点关注GnssNetworkConnectivity的回调，它负责把网络辅助数据注入到GNSS HAL。
10.3.1 AGPS的两种模式
- 移动站辅助（MS-Assisted）：网络侧计算位置，车机只负责上报原始测量值。精度一般，但速度快。
- 移动站基于（MS-Based）：网络只提供辅助数据，车机自己算位置。精度更高，但需要车机有较强的计算能力。
我个人更推荐MS-Based模式。为什么？因为车机的SoC性能通常比手机强，而且车载场景对精度要求更高。你想想看，如果位置算错了，车道级导航就没法用了。
注意：AGPS依赖网络。如果车辆进入无信号区（比如偏远山区），AGPS就失效了。这时候，融合定位中的IMU和轮速就成了救命稻草。所以，永远不要只依赖AGPS。
10.4 实战经验：定位调试的“三板斧”
最后，分享几个我在项目中踩过的坑，希望能帮你少走弯路。
- 检查天线：GNSS天线如果被金属车膜遮挡，信号会衰减10dB以上。我曾经遇到过一台车，定位一直不准，最后发现是4S店贴的金属膜把天线盖住了。
- 关注IMU温漂：IMU在温度变化时，零偏会漂移。尤其是夏天暴晒后启动车辆，IMU数据可能完全不准。解决办法是：在融合算法中加入温漂补偿模型。
- 轮速脉冲的标定：不同轮胎气压、磨损程度，都会影响轮速脉冲与真实距离的换算系数。我建议在车辆出厂前，做一次“轮速标定”流程，让车机自动学习这个系数。
好了，关于车载定位系统，今天就聊到这里。定位这件事，说难不难，说简单也不简单。核心就是：别把鸡蛋放在一个篮子里。GNSS、IMU、轮速、AGPS，每个都有用，但每个都不完美。只有把它们融合好，才能让车机在任何场景下都“知道自己在哪”。
公众号:蓝海资料掘金营，微信deep3321