自定义轨迹和基于EHP log进行匹配的算法对比_更新

基于 ADASISV2 的 EHP log 和基于自定义轨迹的算法流程差异对比如下所示。其中①

代表基于带属性轨迹匹配过程， ②代表基于 EHP log 匹配过程。

图 1 自定义属性轨迹和 EHP log 算法流程对比

具体的，基于带属性的轨迹直接与 SD 进行匹配， 而基于 EHP log的需要基于 EHR 进行reconstruct 获得带属性的轨迹。

匹配算法过程和模块设计如下。匹配过程分初始匹配、增量匹配、终止匹配以及后处理

四种模式。匹配输入的基础数据可选带属性的轨迹或者 EHP log， 匹配输出 MPP。

图 2 匹配算法功能模块设计

补充问题回答

1. EHP 发送长度影响

在实际匹配中， 增量匹配模式就是每次基于上一次匹配结果， 对 EHP 更新长度的一部分进行匹配。具体来说，为了保证匹配正确率，如果 EHP 更新长度为2km，那么每次输出更新的道路的匹配结果长度为 1.5km。如果 EHP 更新的长度为6km，那么每次输出更新的长度可以达到 5~5.5km， 这样匹配可展示效果更佳。如下图，reserved MPP 长度默认为500m，如果整个更新长度较大时，可以适当提高 reserved MPP 长度来进一步保证鲁棒性。

另：目前量产项目 EHP 发送前方 3km， 我们按照 2.5km 给出匹配结果。供参考。在安卓环境中的资源消耗对比目前基于其他硬件给出相应的供预估结果。

项目 自定义轨迹 ADASIS v2 CPU 峰值占比 7.6%（3000DMPIS） 8.6%（3400DMPIS） CPU 均值占比 3.6%（900DMPIS） 3.8%（940DMPIS） 内存 150~170MB 170~190MB 3. ADASIS v2 消息重建的难点

难点在于预测树重置的时候，能够维持 position- >segment 的正确匹配； 4. Segment 的 formofway 和 roadclass 抽取问题

之前我们这边的 position- >segment 的映射策略有点问题，预测树重置的时候，会小 概率把 position 映射到前面的 segment 上， 导致 roadclass、formway 提取错误；修复错误后，可以正常使用 formofway 和 roadclass。

5. 关于疑难场景的区分方法

疑难场景主辅路是通过 formofway 和 roadclass 来解决。 另： 目前对于深圳外环高速， 由于时效性问题导致该高速及其 JCT 缺失， 已通过使用 formofway 来解决这个问题。