企业官网建设流程全解析

前阵子处理一个问题，现象很奇怪：用诊断工具抓CAN总线，轮速报文一直在发，帧率稳定、数值也合理，左右前轮的脉冲计数一五一十地往外吐。可打开融合定位模块的输出日志一看，位置和航向全程没体现出轮速参与的迹象。GNSS信号一进隧道，航迹立刻飘起来，本该由轮速和IMU兜底的航位推算完全没接住。

这个"轮速在发但没参与定位"的坑，做组合导航和车辆融合定位的兄弟大概率都遇到过。折腾过的人知道，这类问题往往一查就是好几天，而且最后根因经常不在传感器本身。这次我把从现象确认到定位根因的完整排查链路整理出来，重点讲清楚"在发"和"被使用"之间到底隔着哪几道关卡，每道关卡容易出什么问题，以及用什么手段逐一定位。无论你是做算法、做集成还是做测试，这条链路都可以直接拿来用。

1. 轮速在定位链路里的真实角色：先搞清"参与定位"意味着什么

1.1 轮速观测不是"加分项"而是一条硬约束

我接触过的不少方案里，轮速给融合算法带来的不只是"多一个传感器"那么简单，它是车辆运动学层面的硬约束。汽车正常行驶时，除了转向带来的侧偏角，绝大多数工况可以近似看作：前向速度由轮速传感器测出来，侧向速度约等于零，垂向速度也约等于零。这一组运动学约束在组合导航里极其关键，尤其是GNSS定位信号暂时丢失的时候，IMU负责姿态和角速度，轮速提供前向速度，陀螺再给出航向变化率，就能不断递推位置增量，这正是经典航位推算（DR）的基本原理。

所以"轮速参与定位"在代码里不是一个模糊概念，它具体体现为：融合算法会构建一个轮速观测方程，把解码换算得到的前向速度作为量测值，去修正IMU推算的车辆速度状态，同时利用侧向速度近似为零这个约束压低横摆方向的漂移。换句话说，判断轮速有没有真正工作，不能只看总线上报文有没有在发，而要确认融合引擎内部是否真的构建并执行了这种观测更新。

轮速换算成车辆前向速度，底层公式也不复杂，核心是把脉冲计数换算成车轮转过的距离再除以时间：

v = (ΔN × 2π × r) / (T × P)

其中ΔN是计时间段T内的脉冲增量，P是车轮输出轴每转一圈对应的脉冲数，r是车轮滚动半径。举个例子，假如计数周期是100毫秒，这段时间内脉冲增量是100个，每转一圈报100个脉冲，车轮滚动半径0.325米，那算出来的速度就是：

v = (100 × 2 × 3.1416 × 0.325) / (0.1 × 100) ≈ 20.42 m/s

约等于73.5公里每小时。公式本身很简单，真正坑人的是P和r这两个参数如果标错，速度就会系统性偏差，而且偏差得还很稳定，总线看数值完全正常。

1.2 确认"没参与"的标准：数据不是看有没有，而是看有没有被消费

排查的第一步，其实是把"没参与"这个现象定义清楚。我见过不少人把"GNSS失效后位置漂移"直接等同于"轮速没参与"，但这两件事不一定是一回事。轮速可能参与了，但质量太差，DR本身就不稳；也可能是DR模式的切换条件压根没被触发。所以动手改任何配置之前，先确认轮速数据究竟有没有被融合模块消费掉。

确认方法比较直观，看三类日志痕迹就够了。

第一，看融合模块有没有订阅到轮速数据。用FusionCore自带的诊断接口查看各话题的接收帧率，正常情况下应该和CAN解码器的发布频率一致。这一步如果对不上，后面的一切都不用谈了。

第二，看滤波器里有没有对应的观测更新计数。融合日志里通常会有观测状态统计，分为updated、rejected、skipped三类。轮速如果一直在参与，updated这一项会随着运行时间持续增长，而且增长的节奏应该和实车运行状态相关。我实测里见过反例：报文帧率很高，updated计数却完全不动，这基本等于宣告轮速根本没进过滤波器。

第三，看速度状态的协方差曲线。轮速观测对前向速度误差有直接约束，如果轮速真正参与了更新，前向速度方差会在每次轮速更新后出现明显的阶梯式下降，画成曲线会呈现锯齿状。如果速度方差全程是一条平滑直线，没有任何周期性下降，那基本可以断定轮速数据从头到尾都在滤波器门外徘徊。

把"是否被消费"这个事实锁定之后，再往链路深处查才有价值。我在实际项目里吃过亏，上来就怀疑轮速脉冲系数、怀疑胎压、怀疑线束接触，折腾了一天才发现消息压根没进到算法入口。

2. 链路层排查：轮速消息到了融合节点门口才算"发到"

2.1 话题通道不匹配：总线上有消息不代表订阅者有消息

第一道关卡，是消息链路层的路由问题。在基于消息总线的架构里，CAN解码器把总线上抓到的轮速报文转成内部消息，往某个话题上发布，融合节点再从自己的话题上订阅。这两条路中间只要稍微对不上，轮速就在总线上一直发，但融合节点一个包都收不到，而且没有任何告警。

我们实测就撞上过这种诡异情况。某个版本里，解码器发布的话题叫wheel_speed_filtered，融合节点默认订阅的是wheel_speed_raw，两个节点都在线，日志也没报错，消息就一直悬在半路，谁都接不到。这种问题用消息总线的诊断命令一查就能看到发布端和订阅端的连接关系，连接数如果是0，说明两端根本没配对成功，话题名对不上。

除了话题名，还有消息总线的QoS策略问题。轮速是周期性信号，发布端如果配的是BEST_EFFORT模式，而订阅端坚持RELIABLE，在大多数实现里两端协商会失败，订阅可能悄悄降级或者直接失败。这类问题不一定体现在日志告警里，需要主动查看协商结果才能发现。所以链路层排查的第一件事，永远是用诊断工具把发布端、订阅端的连接关系看清楚。

2.2 CAN解析：字节序、缩放因子与单位折算

过了路由关，下一道是信号解析关。轮速在CAN报文里通常不是直接的速度值，而是原始脉冲数或者带缩放因子的整型数值。解析的时候只要错一位，报文数值看起来正常，换算之后的速度会完全对不上。

实际项目里最常见的解析坑有三类。

第一是字节序问题。CAN信号有大端和小端之分，解析方向搞反，数值会变得离谱，有时候甚至出现负速度或者几十倍的速度。第二是缩放因子漏乘。DBC文件里明确写着scale是0.0125，代码如果直接拿原始整数值当速度用，实际轮速会差80倍。我见过一个典型症状：隧道里DR轨迹整体缩短，速度一直显示偏小，查来查去才发现是缩放因子没乘，融合算法看到的前向速度比真实车速小了一个数量级。第三是单位折算。有的总线报文给的是km/h，融合算法内部的速度状态默认是m/s，忘了做换算，速度不是偏大就是偏小。

这里我要特别提醒一句：轮速解析问题有一个迷惑性很强的特征，就是输出曲线形状是对的，只是幅值成比例偏大或偏小。如果只看趋势不看绝对值，很容易把它误判成"轮速参与了但效果不好"，而实际上它在入口处就带上了系统性偏差，后面所有融合更新都在用一个错误速度。

2.3 帧率、丢帧与存活计数器

第三类链路问题是频率层面的。轮速报文在CAN上大多是周期性发送，常见的是20Hz或者50Hz。但从CAN转发到以太网，再经消息总线到达融合节点，帧率可能会发生变化。有些实现会在解码层做丢帧检测，连续多帧缺失就把传感器健康状态标记为降级。

这里有一个很容易被总线抓包工具掩盖的细节。很多CAN协议里带有存活计数器（alive counter）或滚动计数器，每帧递增，用于检测连续丢帧。质量好一点的解码器发现计数器不连续时，不只是丢掉这一帧，还会把该传感器标记为unhealthy状态。这个标记如果没在界面上显示出来，你就会看到"报文明明在发"，但融合算法内部的传感器状态已经是降级甚至失效了。

日志里会是这样一类表现：

[WARN] wheel_speed sensor health degraded alive_counter_missed: 12 consecutive_timeout: 3 source_status: unhealthy

这种内部健康标记必须到融合模块的传感器状态模型里翻，光靠抓包工具是看不出来的。链路层排查的结论总结起来就是一句话：轮速消息必须真实到达融合节点、被正确解析成物理量、没有触发降级标记，才算站在了算法处理入口。

3. 配置与开关：轮速被静默禁用的常见姿势

3.1 观测源使能与传感器优先级

过了链路层，第二个容易栽跟头的是配置层。融合定位系统里每个观测源几乎都有独立开关，轮速也不例外。有些系统里的默认配置甚至把轮速观测关着，数据送到门口，算法出于配置原因根本不建观测方程。

另外，还要留意传感器源选择的逻辑。一些系统里有速度源选择功能，可以在"轮速传感器"和"整车CAN车速值"之间二选一，有些还支持根据GNSS信号质量自动切换。如果配置里选了整车CAN车速值，而整车CAN车速信号在某个网关上被过滤掉，就会出现一个特别迷惑的状态：轮速报文在总线上正常发送，但融合算法根本就没订阅轮速通道，它在配置层面就"静默禁用"了。这种问题用订阅关系查询都看不出来，因为配置里选的压根是另一个通道。

排查这类问题，要把配置文件和运行时的传感器源状态对齐来看。我的习惯是启动时打印一份传感器源配置快照，里面明确列出当前生效的速度源类型、健康状态、信号来源。这样至少能排除"配置开关"这一大类。

3.2 车型参数缺失或标错

轮速要转换成速度物理量，必须依赖一组车型参数：车轮滚动半径、每转脉冲数、轮距、轮速安装位置。这些参数在量产项目里通常是写在配置表里的，但如果软件迭代过程中配错了车型，或者参数表里的轮径和实际轮胎不符，问题立刻就会出现。

这里有三类参数是必查的：输出轴每转一圈的脉冲数P、车轮滚动半径r、以及轮速安装轴的传动比。P和r任何一个错了，前向速度都会出现恒定比例误差。这个误差的特征是稳定的、幅值成比例，不随时间漂移，也不会在某一段路突然变好。

我特别想提醒一个容易被忽略的物理细节：车轮滚动半径不是绝对的静态值，它会随胎压、车速、载荷变化。标定时用的是某个胎压下的半径，实车跑起来载荷一变，实际滚动半径和标定值就会有偏差。如果融合算法里有自适应调校机制，它会慢慢吸收这个偏差；如果没有，DR轨迹会整体偏短或偏长，时间越长偏差越明显。这在新车下线和跑了一段时间的车上，表现可能完全不同，排查时要记得排除轮胎磨损和胎压因素。

3.3 冗余策略里的权重调节

融合算法通常还会对多个传感器做权重管理或者健康度管理。在GNSS信号好的开阔场景，系统认为GNSS速度精度足够高，会自动把轮速观测的权重降得很低，甚至暂时关停轮速观测，这本身属于正常策略。问题出在降权和恢复的阈值上面，如果GNSS到DR的切换逻辑有缺陷，在城市峡谷里反复切换，轮速观测会被反复启用又关闭，实际参与次数远低于预期。

这种问题比较难从瞬时日志看出来，需要把传感器状态输出和GNSS状态曲线对齐来看。我通常会做一件事：把FusionCore状态日志导成轨迹曲线，再叠加GNSS失锁区间，看每次GNSS信号消失的瞬间，轮速传感器健康状态是否已经ready。

我实际踩过这样一个坑：系统里的健康模块要求轮速连续有效N秒才把状态置为ready，但车辆在运营场景里走走停停，轮速间歇性回零，ready状态一直没置起来，GNSS突然失锁时DR自然接不住。表面上你看到的是轮速一直在发，实际上健康状态永远进不了可用区。这种逻辑层面的配置问题，排查耗时最长，也最容易被误判成传感器故障。

4. 数据质量与时间同步：轮速值"有效"不代表"可用"

4.1 有效性标志位与静止判定

即使消息到达、配置开启，轮速数值本身还要过一道质量关。CAN报文里的轮速字段通常会带有效性标志位，比如车速有效位、信号品质位、传感器状态位。车辆下电、传感器自检没通过、某些整车工况下，这些标志位可能置为无效，但数值字段依然在周期变化。解码器如果只提取数值字段、不解析标志位，就会把无效数据持续送进融合算法。

这类问题的典型表现是：轮速报文数值看起来在变化，但融合后的速度输出有奇怪的锯齿，或者偶尔出现一个速度跳变到零又跳回来。排查手段很简单，把CAN原始报文里所有字节按DBC完整解码，单独看一下有效标志位的翻转情况，不要只盯着数值字段。

另一个常见问题是静止判定。融合算法需要区分"轮速为零是因为车真的停了"还是"轮速为零是因为报文失效"。许多系统用绝对值和连续性联合判定，如果阈值得不合适，低速蠕行或者走走停停的拥堵工况下，轮速反复接近零，可能被误判为静止。进入静止模式后，算法会降低位置递推频率甚至暂停DR输出，航迹自然就跟不上车辆实际运动了。

4.2 时间戳与同步窗口

时间同步是轮速定位里最常见的隐形杀手，这句话我每次排查都会强调一遍。融合算法里，IMU、GNSS、轮速三个信息源的时间基准必须统一，轮速观测必须和某个IMU状态预测时刻对齐。具体实现一般是维护一个同步缓冲区，收到轮速后去找最近的IMU更新时刻，如果时间差超过同步窗口阈值，这一帧轮速就不参与状态更新。

实际项目里，GNSS和CAN经常来自不同的时钟域。轮速时间戳由CAN接收中断打上本地时间，IMU时间戳由GNSS秒脉冲对齐的时钟打上，两者之间存在几十毫秒的固定偏差。高速工况下，这个时间偏差会直接转化为速度误差。举个例子，车速100公里每小时等于27.8米每秒，如果时间偏差有50毫秒，等效的距离误差就是1.4米。这样一来，轮速和IMU预测出来的速度就对不齐，速度曲线会出现规律性锯齿，严重时直接触发滤波器的观测门控被拒收。

检查时间同步问题有一个简单方法：把轮速消息里自带的时间戳和融合节点实际收到消息的本地时间对齐，统计差值的分布。如果差值一直围绕一个固定值小幅跳动，基本可以断定是时钟偏置问题；如果差值随系统负载增大而持续增大，那要考虑接收线程优先级和消息队列积压。

4.3 反走、跳变与异常值保护

轮速数据的异常值保护同样值得排查。车辆倒车时轮速为负，算法要能正确判读；而某些电气干扰或者传感器故障状态下，轮速会在一个周期内从正常值突变到接近零，或者跳变到几倍正常值。这种跳变数据如果直接进滤波器，状态估计会被拉偏，之后需要很长响应时间才能恢复。

多数融合系统会在观测前加一层合理性校验，把轮速换算后的速度和上一周期融合得出的速度做对比，如果差异超过动态阈值，就判定为异常帧直接丢弃。这一层保护机制的好处是保护状态估计，坏处是如果阈值配置过紧，正常加速、急刹车、激烈驾驶都会被误杀。

误杀问题从日志里很难直接看出来，但它的表现很有特征：轮速updated计数明显少于报文帧数，而且越是激烈动态工况，计数差距越大。如果你发现GNSS正常时定位没问题，一进激烈驾驶或者突然加减速，速度估计就发飘，大概率不是传感器坏了，而是异常值保护阈值太紧，把正常数据当异常扔了。

5. 融合引擎内部的最后一公里：观测门控与状态依赖

5.1 新息与卡方门控：为什么滤波器会把轮速"拒之门外"

数据到了算法入口，离真正参与状态更新还差最后一步——滤波器的观测门控。以扩展卡尔曼滤波为例，滤波器会根据当前状态预测出一个"轮速应该等于多少"，然后和实际轮速做差，得到新息（innovation）。新息大小要结合预测协方差和观测噪声协方差算一个马氏距离，再和卡方分布的阈值比较，超过阈值就判定这次观测不可信，直接拒收。

mahalanobis_distance = |innovation| / sqrt(innovation_variance) if mahalanobis_distance > gate_threshold: reject_observation() else: accept_observation()

这个门控机制的作用是防止异常观测污染状态估计。问题在于，如果轮速存在固定比例偏差，比如车型参数标错，或者观测噪声方差配得比实际值小很多，那么正常数据也会被持续判定为不一致。你在日志里看到的就是rejected计数一直在涨，但总线侧的报文数据看起来无比正常。

这也解释了为什么"换个GNSS信号好的地方就正常"的现象。GNSS信号好的时候，定位结果主要被GNSS速度牵着走，轮速的新息刚好卡在门限内；一旦GNSS信号变弱，位置预测不确定性变大，轮速只要有轻微偏差就会被判离群。所以门控问题在开阔场景很难暴露，反而在隧道、地库、高架桥下最容易触发，这也正好是DR最需要发挥作用的时候。

5.2 可观测性与动态工况判定

滤波器不是在任何时刻都适合做轮速更新的。当车辆处于静止状态，或者航向角完全没有激励，比如长时间直线行驶且没有GNSS横向速度分量参与时，观测模型里的相关状态实际上是不可观测的。这种情况下强行做轮速更新没有意义，甚至可能带来数值问题，很多系统会在工况判定逻辑里主动跳过这类更新。

这会导致一个很微妙的现象：轮速确实在发，但融合算法只在特定工况窗口里消费它。比如系统要求航向变化率或者GNSS航向差满足某个阈值才启用轮速观测，如果车辆一直低速大角度转弯，或者GNSS输出异常导致判定模块认为条件不满足，轮速照样被晾在一边。

排查这类问题，需要把融合模块里的工况状态机打印出来。我一般会在日志里加上当前dr_mode、nav_mode、wheel_speed_usable这几个字段，把轮速观测的每个决策节点都暴露出来。只看最终结果永远确定不了是哪个环节卡住了。

5.3 从日志定位被拒观测：输出层面的判据

定位"到底被谁挡下来"，最有效的办法是看融合模块的诊断输出。我也会在测试时打开观测级日志，每一帧轮速观测对应一行日志，里面包含原始轮速值、换算后的前向速度、滤波器预测值、新息、新息方差、马氏距离、门限、判定结果。

[OBS] wheel_speed speed_raw: 128 speed_mps: 18.32 predicted_speed: 18.05 innovation: 0.27 innovation_var: 0.018 mahalanobis: 2.01 gate_threshold: 3.84 result: accepted

当rejected频繁出现时，要区分两种情况：马氏距离接近门限但略超，通常是噪声方差标定问题，观测本身是好的，只是统计特性配得不合理；而马氏距离彻底爆表，比如十倍的量级，那多半是数据源、车型参数或者链路解析有硬伤。这两种情况对应的处理方法完全不同，前者去调噪声模型和门限参数，后者回过去查链路层和配置层，千万别在滤波器里硬调参数掩盖真实问题。

6. 实测排查路线与几个容易忽略的坑

6.1 从现象到根因的六步排查顺序

如果让我重新面对"轮速一直在发但没参与定位"这个现象，我会严格按下面的顺序过一遍。不建议跳步，更不建议一上来就改参数。

第一步，锁定现象。通过观测更新计数和协方差曲线，确认轮速确实没有进滤波器，而不是"参与了但质量差"。这步确定了，排查方向才不会跑偏。

第二步，查链路层。确认消息真实到达融合节点，话题匹配、QoS协商、帧率、解码后的物理量全部正常。

第三步，查配置层。使能开关、速度源选择、车型参数、传感器健康状态是否ready。

第四步，查数据质量。有效标志位、时间戳偏差、异常值保护误杀情况。

第五步，查滤波门控。看日志里马氏距离和门限的关系，判断是统计参数问题还是数据硬伤。

第六步，实车复测。重点复现GNSS失锁场景，看DR能否顺利接管，接管后位置发散是否在可控范围。

排查项、检查手段和典型误判特征，我整理成了一个简单的对照表，实际操作时可以直接照着走：

6.2 我印象最深的两个假象案例

排查这类问题多了，我发现最花时间的不是链路断、配置错这些明确故障，而是那些"看起来一切正常"的假象。

第一个假象案例是更新计数在涨，但状态没有任何变化。当时打开诊断日志发现轮速观测一直在更新，updated计数每秒钟都在增长，但速度协方差曲线全程是一条直线。最后定位到根因，是轮速观测的噪声方差被错误配置成了十的六次方量级。观测协方差巨大，新息即使通过了门控，计算出来的增益也接近于零，等于每次都在做一个昂贵的空操作。这种问题如果不打印状态协方差或者等效增益，光看更新计数根本发现不了。

第二个假象案例更隐蔽。车辆参数配置里选择的是后轴轮速作为前向速度源，但实际CAN信号里只有前轴轮速在正常发送，后轴报文虽然有值但常年接近零。平均算出来的前向速度只有每秒0.2米左右，滤波器每次都尝试更新，每次新息都爆表被拒。总线抓包看起来前轴后轴都在发，实车也确实在跑，但融合算法就是拿不到有效的速度约束。最后是把诊断端的信号曲线前后轴对齐比对，才发现后轴报文数值比前轴差了整整一个数量级。

这两个案例的共同点是：数据链路没有断，配置也不是完全缺失，问题藏在"参数不合理"和"信号语义不匹配"这种模糊地带。这也是为什么排查这类问题一定要分层走流程，每一层确认的结果都要和上一层对齐，否则很容易在一两个看似正常的假象面前反复打转。

6.3 轮速参与正常的判断标准

一次排查结束之后，我会用三个标准来确认轮速是真的参与定位了，而不是靠感觉判断。

第一，观测统计健康。updated计数随运行持续增长，rejected占比在一个合理范围内，而且在GNSS失效时updated计数没有消失，说明轮速在关键时刻依然在消费。

第二，协方差响应明显。速度协方差曲线在每次轮速更新后出现可见的下降，尤其在车辆直行、轮速激励充分的工况区间，前向速度方差应该逐步收敛。

第三，GNSS失效场景复测通过。在隧道或者地库场景断开GNSS信号，DR在几秒到十几秒内维持位置发散可控，航向不突变，速度不发散。这三个标准同时成立，才算真正闭环。

按这个流程走一遍之后，我最大的体会是：总线层面的"数据在发"和算法层面的"数据参与"属于两个完全不同的世界，中间隔着链路解析、配置开关、健康状态、时间同步、观测门控和工况依赖好几道关卡。以后再遇到类似现象，我不会再首先怀疑传感器硬件，而是会追着数据流一层层把通向滤波器入口的路走一遍。希望这篇笔记能帮你省下几天和整车日志死磕的时间。