MMF 是什么

一句话概括就是：将地图匹配的结果通知给 DR 模块（地图匹配结果依托于道路数据）。

MMF信息只在巡航匹配在道路上时才有效，如果巡航脱离道路(如地下停车场等场景)则返回的MMF信息是空的。即道路数量为0，匹配点经纬度、道路属性等所有信息均无效。

以下是 MMF 在 Obsidian 工具上的视觉化展示。图中的灰色细线为路网，三个深蓝色车标就是 MMF 节点。可以直观的看出每个 MMF 节点至少包含了坐标、方向、概率信息。

MMF 的作用

DR 模块的主要数据源有两类， GNSS 和传感器（陀螺仪、车速脉冲、加速度计等）。 GNSS 提供的是绝对位置，传感器提供的是相对（推算）位置。

由于传感器受精度、零漂、温漂、刻度系数误差、安装误差等影响（传感器基础知识），在持续推算时存在误差累积的问题，所以推算一段时间后需要使用 GNSS （绝对位置）进行修正，从而持续输出可靠的融合位置。

但 GNSS 容易受周边环境（遮挡、信号干扰、多路径反射等）影响，出现信号漂移、丢失的情况（高架下、地下停车场、隧道等场景），光靠 GNSS 无法做到全场景修正。

MMF 对于 DR 模块来说，就是一个比较可靠的绝对位置数据源。借助 MMF ， DR 模块理论上可以进一步提高融合位置信息的准确度。

长隧道表现

以下改善效果仅作参考，实际表现受 MMF 信息准确度以及 DR 模块融合算法影响。

无MMF

有 MMF

高架下表现

无 MMF

有 MMF

如何对接 MMF

目前需要对接 MMF 功能的为前端融合项目，此时 DR 模块为外部模块。

在对接 MMF 功能前，需要先充分理解定位输出的 MMF 以及 DR 模块需要的 MMF。

充分理解两方面的信息后，一般而言，会需要对定位引擎输出的 MMF 信息做一定的转换后再输入到 DR 模块。

例如，定位输出的 MMF 信息最多包含6个匹配信息节点，而 DR 模块可能只需要一个，此时可以根据 DR 模块的需求只提供概率最高的一个。

定位输出的 MMF

以下为目前定位引擎输出的 MMF 信息结构体，包括时间戳、匹配点坐标、匹配点偏移量、道路角度、匹配概率、反馈类型、道路宽度等信息。

每个字段的具体说明参见下方的注释。

地图匹配相关数据结构

#define MAX_MM_FEEDBACK_BUFF (6) /**< 地图匹配反馈最大道路条数 */\n\n\n/**\n* @brief 地图匹配反馈信息\n* @see   LocMMFeedbackInfo\n*/\nstruct LocMMFeedbackInfo {\n    LocMMFeedbackInfo() : ticktime(0), count(0), toRoadStartDist(0), toRoadEndDist(0), onFlat(false), hasMapData(false), gpsOnRoad(false) {}\n    uint64_t   ticktime;                       /**< 时间戳。@note 单位：毫秒。此时间戳与计算地图匹配反馈的信号的时间戳一致 */\n    int32_t    count;                          /**< 道路数量，当count == 0时表示feedbackNodes中的信息不可使用，此时无地图匹配反馈 */\n    double     toRoadStartDist;                /**< 到概率最大的道路的起始节点距离 */\n    double     toRoadEndDist;                  /**< 到概率最大的道路的末尾节点距离 */\n    LocFeedbackNode  feedbackNodes[MAX_MM_FEEDBACK_BUFF];   /**< 反馈数据 */\n    bool       onFlat;                         /**< 当前匹配点是否在平路上（所有概率较大的LPS匹配段都没有坡度） */\n    bool       hasMapData;                     /**< 是否有离线地图数据 */\n    bool       gpsOnRoad;                      /**< GPS信号是否在道路上 */\n};\n\n/**\n* @brief 地图匹配信息节点\n*/\nstruct LocFeedbackNode {\n    LocFeedbackNode() : roadAzi(0), probability(0), type(LocFeedbackInvalid), roadWidth(0) {\n        matchPoint.lon = 0;\n        matchPoint.lat = 0;\n        matchPoint.z = 0;\n        deltaPoint.lon = 0;\n        deltaPoint.lat = 0;\n        deltaPoint.z = 0;\n    }\n\n    PosCoord matchPoint;         /**< 匹配点坐标(GCJ02)。\n                                 @note 单位：百万份之一度\n                                 @note 无效时，经度，纬度均为0。高度一直无效\n                                 @note matchPoint或者deltaPoint无效时，则整个结构体中所有的信息都无效\n                                 @warning 原则上，该坐标点不对外传，如果有需要，需要项目负责人发邮件申请，否则有法务问题，慎！！！ */\n    PosCoord deltaPoint;         /**< GCJ02下的偏移量\n                                 @note 单位：百万份之一度\n                                 @note 偏移量 = 原始位置点坐标(GCJ02) - 匹配点坐标(GCJ02)\n                                 @note 无效时，经度差，纬度差均为0，高度一直无效\n                                 @note matchPoint或者deltaPoint无效时，则整个结构体中所有的信息都无效 */\n    float   roadAzi;            /**< 道路角度，即航向。@note 单位：度，北零顺时针(0：正北；90：正东；180：正南；270：正西) */\n    float   probability;        /**< 匹配在这条道路上的概率。@note 范围：[0-1]。所有道路的概率值累加起来为1 */\n    LocFeedbackType type;       /**< 地图匹配反馈类型 */\n    int32_t   roadWidth;        /**< 道路宽度。@note 单位：米 */\n};\n\n/**\n* @brief 地图匹配反馈类型\n* @see   LocFeedbackNode\n*/\nenum LocFeedbackType {\n    LocFeedbackInvalid = 0x0000,                /**< 无效 */\n    LocFeedbackMatch = 0x0001,                  /**< 车标匹配在路上 */\n    LocFeedbackTunnel = 0x0002,                 /**< 隧道 */\n    LocFeedbackRoundabout = 0x0004,             /**< 环岛 */\n    LocFeedbackElevated = 0x0008,               /**< 高架 */\n    LocFeedbackBridge = 0x0010,                 /**< 桥 */\n    LocFeedbackCrossLink = 0x0020               /**< 复杂节点内部道路   */\n};

此处做一下简单的说明：

MMF 以外部传入位置信息驱动，正常情况下，一个位置信息对应一次 MMF 。 MMF 时间戳（ticktime）与对应的位置信号时间戳相同。

只有匹配在道路上时， MMF 信息才是有效的；未匹配在道路上时，反馈数量为（count）0，反馈数据（feedBackNode）无效，

定位一次 MMF 会输出最多 6 个反馈节点，每个节点都包含GCJ02偏移量、道路角度、道路宽度、反馈类型及概率。所有节点概率和为 1 。
理论上只能将 tagGDFEEDBACKNODE 结构体中的 deltaPoint （GCJ02下偏移量）传给外部。如果确认需要将反馈节点的 GCJ02 坐标传给外部，需正式申请，否则有法务问题。如下图示，红色箭头就代表 deltaPoint 。

DR 模块需要的 MMF

首先， DR 模块很可能不支持 MMF 。不过出于提高定位信号精度，进而提升导航整体表现的目的，强烈建议在项目初期推动所有前端融合项目的 DR 模块支持 MMF 。此外，尽量引导 DR 模块使用定位引擎已具备的 MMF 信息。

如果 DR 模块支持 MMF ，必须了解清楚它需要哪些反馈信息（每个项的意义、单位、取值范围等），通常会有相应的文档来说明。

这些信息可能与定位引擎能够提供的不完全一致。不过一般而言，定位引擎提供的 MMF 应该能够覆盖 DR 模块的需求，也就是定位引擎提供的 MMF 信息会是 DR 模块需求的超集，适配时按需要提取部分信息即可。

如果出现无法满足，需要与定位引擎进一步讨论解决方案。

示例:

DCY11,UBLOX

1.系统方通过LocFeedbackNode.type判断，当为隧道属性是才使用MMF；

2.隧道分岔路口，前后50米（toRoadStartDist或者toRoadEndDist小于50）不使用MMF；

3.LocFeedbackNode[0]为当前车标所匹配道路信息，同时概率也最大，可以只使用该点信息；

4.由于不能直接对外输出匹配点经纬度，但可以通过LocFeedbackNode.deltaPoint及原始信号经纬度Dr.Point，推算出匹配点match.Point。如下，假设原始经纬单位为（度）

match.Point.lon = Dr.Point.lon + LocFeedbackNode.deltaPoint.lon / 1000000.0

match.Point.lat = Dr.Point.lat + LocFeedbackNode.deltaPoint.lat / 1000000.0

5.可以通过ticktime进行，MMF信息与原始信号的同步。ticktime为外部传进来的原始信号包含的时间戳，地图匹配完成后再透传出去。

MMF 时延

从导航接收到位置信号到导航输出 MMF 信息之间的间隔，定义为 MMF 的时延。

以下基于某项目得到的统计数据：
【验证环境】
硬件版本：XXX
CPU：ARM cortex-A9 Freescale i.MX 6Dual 800MHZ
内存：1GB
系统（SOC）版本：01.02.hybird.T05
导航版本：2.1.8.1030
定位版本：8.0.8.12108

【测试方法】
进行巡航、导航路测，路测过程中记录客户端收到融合信号与客户端发送对应地图匹配反馈信息的时间间隔，记这个时间间隔即为地图匹配反馈时延。
对整个路测过程的时延数据进行统计分析。测试时间大约1.5小时，总计样本数为 4259 个。

【结论】

地图匹配反馈时延平均值 16.5 ms
地图匹配反馈时延最大值 494 ms
地图匹配反馈时延最小值 5 ms
时延小于100ms的占比为 99.11%
偶发的匹配反馈时延偏大的情况，基本确认为硬件 IO 性能瓶颈引起。