MapTR: Structured Modeling and Learning for Online Vectorized HD Map Construction论文信息标题MapTR: Structured Modeling and Learning for Online Vectorized HD Map Construction作者Bencheng Liao, Shaoyu Chen, Xinggang Wang 等会议ICLR 2023论文地址arXiv:2208.14437代码地址hustvl/MapTR一句话总结MapTR的核心贡献是把在线矢量化 HD Map 构建问题重新表述成一个基于 Transformer 的结构化集合预测问题直接从环视相机图像输出实例级矢量地图不再依赖分割后处理也避免了传统点序列建模里的排列歧义。这篇论文在解决什么问题自动驾驶中的在线 HD Map 构建目标是在车辆运行时实时输出局部地图元素例如lane dividerroad boundarypedestrian crossing这类任务过去主要有两条路线1. 栅格分割路线先做 BEV 语义分割再把分割结果转成矢量地图。问题在于输出不是实例级的后处理复杂从 mask 到 vector 会引入额外误差很难高效获得结构化地图结果2. 点序列回归路线直接预测地图元素的点序列。问题在于点序列的排列并不唯一起点和方向常常有歧义自回归解码速度慢训练不稳定MapTR就是在解决这两个问题既要直接输出矢量地图又要保证速度和训练稳定性。MapTR 的核心创新1. Permutation-equivalent modeling这是整篇论文最关键的创新。作者指出地图元素虽然可以表示成点序列但“点序列顺序”通常不是唯一的。为什么会有歧义对 polyline比如一条车道分隔线两个端点谁是起点并不总是有自然定义反向连接后几何形状并没有变化。对 polygon比如人行横道边界不仅可以顺时针或逆时针排列而且起点还可以在任意一个顶点因此会有更多等价排列。作者怎么做MapTR 不把一个地图元素简单表示成固定顺序点列而是表示成一个点集V一组等价排列Γ也就是(V, Γ)。这意味着监督时不再强行要求模型去拟合某个唯一排列而是在所有等价排列中找到最合理的匹配方式。这个设计的价值消除了排列歧义让训练目标更合理稳定了学习过程对 polygon 类元素尤其有效论文里的消融结果显示这个设计相比固定顺序建模带来了5.9 mAP其中pedestrian crossing的提升达到11.9 AP。2. Hierarchical query embeddingMapTR 没有像目标检测那样一个 query 对应一个 bbox而是做了更结构化的 query 设计。作者把 query 分成两层实例级 query表示“这是第几个地图元素”点级 query表示“这是该元素中的第几个点”二者组合得到层次化 queryq_hie(i, j) q_ins(i) q_pt(j)这个设计的意义是显式编码“元素级”和“点级”结构一个元素可以自然表示为一组点所有实例、所有点都可以并行预测这比自回归地逐点生成更适合实时场景。3. Hierarchical bipartite matchingMapTR 的训练不是只做一次 Hungarian matching而是分两层实例级匹配先把预测的地图元素和 GT 地图元素做一一匹配。匹配代价包含类别代价位置代价点级匹配在某个预测实例和 GT 实例匹配好之后再在这个 GT 对应的等价排列集合Γ中找到最优点级匹配。这个设计正好和 permutation-equivalent modeling 配套保证监督既有实例级一致性也考虑点级排列合理性。4. p2p loss edge direction lossMapTR 的几何监督不是只看点的位置还看边的方向。损失由三部分组成分类损失L_cls点对点损失L_p2p边方向损失L_dir其中edge direction loss很关键因为地图元素不仅是点的集合点与点之间的连接方向也决定了形状质量。这个设计的价值在于约束局部几何结构防止点虽然靠近 GT但连接关系不对对 polyline 和 polygon 都更友好网络结构图6路环视图像输入Backbone 提取多视角图像特征2D-to-BEV 变换BEV 特征图Map Decoder实例级 Query点级 Query层次化 Query多层 Transformer 解码分类分支点坐标回归分支地图元素类别Polyline 或 Polygon 点序列网络结构怎么理解1. 输入端MapTR 默认使用6路环视相机图像作为输入先经过 backbone 提取多视角特征再通过2D-to-BEV模块变换到统一 BEV 表征。论文默认使用的是GKT但也兼容IPMLSSDeformable AttentionCVT这说明 MapTR 的重点并不在 2D-to-BEV 模块本身而在后面的结构化地图解码器。2. Map Decoder这是 MapTR 最核心的模块。它不是常规的 dense prediction head而是用层次化 query 显式表示地图实例和点结构用 Transformer decoder 并行更新所有点最后直接输出类别和点坐标从感知工程视角看它本质上是把“地图元素检测”改写成了“实例级点集结构预测”。3. 输出端MapTR 的输出头很简单只有两支分类分支预测地图元素类别点回归分支预测2 * N_v维坐标向量也就是说一个地图元素最终就是一串 BEV 平面中的点。这也是它比 segmentation-then-vectorization 更简洁的地方。为什么 MapTR 比之前方法更快论文里对比的关键基线主要有HDMapNetVectorMapNetMapTR 的速度优势主要来自三点1. One-stage它不是“先分割再聚合”而是端到端直接预测矢量地图。2. Parallel decoding它不是自回归逐点输出而是实例和点都并行预测。3. Structured queries层次化 query 直接编码结构不需要复杂中间表示和冗长后处理。和已有方法相比MapTR 到底强在哪里1. 相比 HDMapNetHDMapNet更偏 rasterized map再通过后处理转成 vector。MapTR 的优势是直接输出实例级 vector后处理更少结构更清晰更适合下游规划和预测2. 相比 VectorMapNetVectorMapNet已经开始直接预测点序列但采用 coarse-to-fine auto-regressive 解码。MapTR 的优势是解决了排列歧义并行预测更快单阶段结构更紧凑训练更稳定一句话说VectorMapNet更像“能做点序列预测”而MapTR更像“把点序列预测做成了结构化且高效的 Transformer 框架”。实验结果怎么理解论文在nuScenes上评估三类地图元素pedestrian crossinglane dividerroad boundary感知范围是X轴[-15m, 15m]Y轴[-30m, 30m]评价指标是基于 Chamfer 距离阈值的AP。1. 主结果论文给出的代表性结果如下方法输入mAPFPSHDMapNet-CCamera23.00.8VectorMapNet-CCamera40.92.9VectorMapNet-CLCamera LiDAR45.2-MapTR-nanoCamera45.925.1MapTR-tinyCamera50.311.2MapTR-tinyCamera, 110 epochs58.711.2这组结果说明什么MapTR-nano首次把 camera-only vectorized map construction 推到了实时级别MapTR-nano只用相机就超过了此前 camera-only SOTAMapTR-tiny甚至超过了以前的多模态方法这也是这篇论文影响力很大的原因之一它不只是精度高而是把这个任务真正往“可部署”方向推了一步。2. 消融结果里最值得注意的点permutation-equivalent modeling 有明显收益固定顺序建模44.4 mAPpermutation-equivalent50.3 mAP说明排列歧义确实是这个任务里的真实问题不是论文作者“人为制造”的问题。edge direction loss 有帮助不加方向损失时mAP 为48.2合适权重下可提升到50.3。说明只监督点还不够边的方向信息对地图几何表达也很重要。点数和 decoder 层数存在效率-精度平衡点太少几何表达能力不够点太多效率下降decoder 层数增加到6后效果趋于饱和这说明 MapTR 的设计并不是“越大越好”而是有明显的结构平衡点。从感知算法工程师角度看这篇论文最值得学什么1. 把任务定义清楚比堆模块更重要MapTR 最强的地方不是用了多复杂的 backbone而是把问题重新定义对了地图元素是结构化对象点序列存在等价排列学习目标应该对这些等价性不敏感这个抽象一旦成立后面的 matching、loss 和 decoder 设计就顺理成章。2. 结构化建模要和训练机制一起设计MapTR 不是只提出了一个 representation然后沿用普通训练方式它把permutation-equivalent modelinghierarchical query embeddinghierarchical matchingp2p / direction loss放在一起形成了一套闭合设计。这点对做感知模型很重要好的结构表示必须和匹配策略、loss 设计协同。3. 实时性来自任务改写不只是工程优化MapTR 之所以快不只是因为代码快而是因为它把问题从自回归逐点生成改成了并行实例预测并行点预测这类“问题改写带来的效率提升”通常比单纯调 kernel 更有价值。这篇论文的局限虽然 MapTR 很强但它也有一些边界1. 评估类别还比较少论文在 nuScenes 上主要评估pedestrian crossinglane dividerroad boundary对于更复杂、更长尾的地图元素这个框架的扩展能力还需要更多验证。2. 还是依赖 2D-to-BEV 质量虽然 MapTR 的核心亮点不在 2D-to-BEV但其上限仍然受 BEV 表征质量影响。相机标定误差、深度估计误差、跨视角融合误差都会传导到最终地图结果。3. 拓扑关系并没有显式建模MapTR 输出的是实例级矢量地图元素但它并没有显式建模更高层的lane connectivitypredecessor / successorroute graph所以它更适合作为地图感知基础模块而不是完整拓扑地图系统。4. 点数是固定的每个元素都用固定数量的点表示这虽然便于训练和并行预测但在表达特别复杂或特别简单的几何时不一定是最优的。最值得记住的 5 点MapTR的核心创新是permutation-equivalent modeling。它把地图元素预测做成了结构化的层次化集合预测问题。它用实例级 query 和点级 query 共同描述地图元素。它通过hierarchical matching p2p loss edge direction loss稳定训练。它在 camera-only 条件下把在线矢量地图构建首次推到了实时级别。简短结论MapTR之所以重要不只是因为它“比之前更准更快”而是因为它第一次把在线矢量 HD Map 构建清晰地组织成了一个结构化 Transformer 问题。它既解决了排列歧义又兼顾了端到端、实例级输出和实时性因此成为后续很多 vectorized map 工作的基础范式。