夜雨聆风
三路传感器，各怀绝活
Apollo MSF的入口在modules/localization/msf/msf_localization_component.h，类名MSFLocalizationComponent，继承自cyber::Component<drivers::gnss::Imu>。注意这个继承——IMU数据是整个融合的触发源，100Hz频率拉满。
三路传感器通过三个listener订阅进来：lidar_listener_订阅PointCloud，bestgnsspos_listener_订阅GnssBestPose，gnss_heading_listener_订阅Heading。发布端有四个talker：localization_talker_输出最终的LocalizationEstimate，lidar_local_talker_和gnss_local_talker_分别输出各路中间结果，localization_status_talker_汇报状态。
GNSS/RTK走的是NovAtel等接收机，拿到GnssBestPose就是厘米级定位。但城市峡谷、隧道、高架下面信号衰减得厉害，这是它致命的软肋。
IMU 100Hz高频输出加速度和角速度，短时精度极高，但积分漂移是宿命——积分一次漂一点，积分十秒就飞了。
LiDAR的点云跟预建定位地图做匹配，输出位置和姿态。不依赖卫星信号是它最大的优势，隧道里照样干活。代价是要有地图，雨雪天气点云质量下降。
三路传感器各自的弱点恰好被另外两个补上：GNSS怕遮挡但LiDAR不怕，IMU会漂但GNSS和LiDAR给绝对位置修正，LiDAR怕天气但IMU无所谓。这个互补性是整个融合能工作的根基。
三路各有独立定位能力
Apollo不是简单把三个传感器数据丢进一个滤波器就完事。每一路都有独立的定位能力，融合是在独立结果之上做的。
GNSS定位有两种模式，由gnss_mode参数控制。gnss_mode=0直接用接收机输出的best_pose，简单粗暴；gnss_mode=1用rtk_obs和rtk_eph在本地做RTK解算，好处是可以控制解算策略。
LiDAR定位更丰富，三种模式通过lidar_localization_mode配置：intensity模式用反射强度匹配，altitude模式用高度匹配，fusion模式把两者融合。地图是预建的网格地图，每个cell存储反射强度和高度统计量。地图生成靠msf_local_map_creator.sh脚本，这是离线流程。
SINS捷联惯导积分是IMU的独立定位能力——用加速度和角速度做积分，推算位置、速度、姿态。它不是配角，是融合的"主轴"。其他传感器的工作是修正它的漂移，而不是替代它。
15维ESKF：不估计状态，估计误差
这是Apollo MSF的核心设计决策：不直接估计状态，而是估计误差状态。
误差状态向量δx = [δp, δv, δθ, δba, δbg]^T，15维。δp(3)是位置误差，δv(3)是速度误差，δθ(3)是姿态误差用旋转向量表示而不是四元数，δba(3)是加速度计偏置误差，δbg(3)是陀螺仪偏置误差。
整个流程分三步。
预测步：IMU的100Hz数据驱动SINS积分，得到名义状态——就是位置、速度、姿态的大致值。同时误差状态的协方差按F矩阵传播，不确定性在增长。
更新步：GNSS和LiDAR的定位结果作为观测进来。观测向量y^T = [δp_lidar, δv_gps, δq_lidar, δp_gps]，GNSS提供位置和速度，LiDAR提供位置和姿态。计算Kalman增益K，更新误差状态δx。
注入与重置：用δx修正名义状态，然后把误差状态重置为零，协方差P做相应更新。下一轮预测重新开始。
这套方案的参考文献是Wan et al.在ICRA 2018发表的"Robust and Precise Vehicle Localization Based on Multi-Sensor Fusion in Diverse City Scenes"。误差状态比直接估计状态的好处是：误差是小量，线性化更准确，协方差矩阵的数值性质更好。
跟PX4 EKF2的核心差异
PX4 EKF2是24维误差状态，Apollo ESKF是15维。差了9维，但这9维不是Apollo"砍掉"了，而是问题域根本不同。
PX4多出的维度：地磁占了6维（earth magnetic field 3维 + body magnetic field 3维），风速2维，地形1维。无人机没有LiDAR提供绝对航向，只能靠磁力计，所以需要地磁状态。固定翼需要风速估计来做空速补偿。这些都是飞行器的刚需，Apollo作为地面车辆完全不需要。
Apollo不需要地磁，因为LiDAR能提供高精度姿态，包括航向，比磁力计可靠得多——磁力计在电机旁边受干扰是飞控的老大难问题。Apollo也不需要风速，地面车不飞。
状态向量的表示也有差异。PX4用四元数（4维）加误差旋转向量（3维），Apollo直接用3维旋转向量表示姿态误差，更紧凑。四元数在无人机上更常用是因为全姿态表示需要避免万向锁，但误差状态本身就是小角度，旋转向量足够。
延迟处理的设计思路也不同。PX4有"fusion time horizon"机制——传感器数据有延迟，EKF2在延迟时间线上做融合，再用Output Predictor前推到当前时刻。这是因为飞控的气压计、磁力计延迟特性各不相同，必须统一管理。Apollo的IMU触发是实时的，延迟靠传感器时间戳对齐来处理，简单直接。
雅可比矩阵的生成方式也不一样。PX4用SymForce自动生成，Apollo是手写推导。手写的好处是透明，出问题能直接看公式；自动生成的好处是不会犯手写符号错误。各有取舍。
参数数量：PX4约80个调参，Apollo约20个。状态更少加上传感器更少，调参负担轻得多。CPU开销方面，PX4 EKF2在嵌入式MCU上占15-25%，Apollo跑在x86上对算力不敏感。
4种运行模式，隧道里怎么活
Apollo MSF有4种运行模式，核心区别在GNSS的参与程度。
3-Systems模式下GNSS始终参与融合。gnss_mode=0用best_pose，gnss_mode=1用本地RTK解算，gnss_only_init=false表示GNSS不止用于初始化。
2-Systems模式设置gnss_only_init=true，GNSS仅用于初始化对齐。一旦对齐完成，LiDAR+SINS独立运行。这个模式才是城市场景的刚需——隧道和高架下面GNSS信号断掉后，LiDAR+SINS继续工作，不需要GNSS兜底。
初始化大约50秒，官方文档的数据。这段时间GNSS和LiDAR都在做初始对齐，IMU的偏置在收敛，协方差在稳定。
从工程角度，2-Systems模式才是Apollo MSF真正要解决的问题：城市道路GNSS频繁失效，LiDAR+SINS必须独立撑住。3-Systems模式是GNSS可用时的锦上添花，精度更高。
我的对比体会
我飞PX4的时候，EKF2调参是最大的痛苦。24维状态空间，80多个参数，磁力计标定不好航向就飘，气压计有风洞效应高度就抖。每个传感器引入的状态既是信息也是负担。
读Apollo的ESKF源码，15维反而更清晰。不是阉割版——地面车辆有LiDAR提供绝对姿态，不需要磁力计；不需要飞，不需要风速。传感器互补性更好：GNSS给绝对位置，LiDAR给绝对姿态，IMU给高频预测。三者各自的弱点被另外两个补上，这才是融合该有的样子。
PX4的融合更"孤独"。GPS断掉后只剩IMU加磁力计，没有LiDAR这种绝对姿态源兜底，漂移是不可逆的。Apollo在GNSS失效后还有LiDAR做绝对位置和姿态修正，IMU的漂移持续被拉回来。
从源码可读性看，Apollo的ESKF实现比PX4的ECL库清晰不少。PX4为了嵌入式优化做了大量矩阵运算技巧，内存预分配、定点数近似，读起来费劲。Apollo在x86上跑，不需要这些，数学表达更直接。
15维还是24维，不是谁更厉害的问题，是解决什么问题的问题。无人机和自动驾驶车面对的传感器组合、环境约束、精度需求都不一样。理解了问题域，状态向量的维度自然就定了。
