51c自动驾驶~合集26-EW帮帮网

我自己的原文哦~ https://blog.51cto.com/whaosoft/11968755

#大模型/Sora/世界模型之间是什么关系

1 什么是大模型

人工智能大模型（Artificial Intelligence Large Model，简称AI大模型）是指具有庞大的参数规模和复杂程度的机器学习模型。通常指的是参数量非常大、数据量非常大的深度学习模型。

大模型通常由数百万到数十亿的参数组成，需要大量的数据和计算资源进行训练和推理。

由于其巨大的规模，大模型具有非常强大的表示能力和泛化能力，可以在各种任务中表现出色，如语音识别、自然语言处理、计算机视觉等。

1.1 大模型的优点

1）强大的表示能力

大模型可以学习非常复杂的模式和特征，从而能够处理各种复杂的任务。

2）泛化能力强

由于大模型在大量数据上进行训练，它们可以捕捉到普遍存在的模式，因此在处理新数据时具有较好的泛化能力。

3）多任务学习

一些大模型可以同时处理多个任务，例如图像分类和目标检测，或者自然语言处理中的文本分类和情感分析。

4）预训练和迁移学习

大模型可以在大规模数据上进行预训练，然后在其他数据集上进行微调，以适应特定的任务。这种迁移学习的方法可以大大减少在新任务上的训练时间和数据需求。

通过在大量的标注和未标注的数据上进行预训练，大模型可以从中捕获通用的知识和特征，并将其存储在参数中。

然后通过对特定任务进行微调，大模型可以将预训练的知识迁移到下游任务中，极大地提高了模型的性能和泛化能力。

1.2 大模型的应用

大模型的典型代表有GPT-4、盘古、Switch Transformer等，它们的参数量都达到了千亿甚至万亿的规模。

除此之外，还有代码大模型、视觉大模型、多模态大模型等。

1）语言模型

语言模型是一种自然语言处理领域的深度学习模型，通过语言模型的应用，可以实现机器翻译、文本摘要、问答系统、情感分析等功能。

例如，谷歌的BERT模型可以用于提高搜索引擎的搜索质量和广告质量；OpenAI的GPT系列模型可以用于自动生成文章、对话和摘要等。

2）图像识别模型

图像识别模型是一种计算机视觉领域的深度学习模型，可以用于图像分类、目标检测、人脸识别等任务。

例如，在医疗领域，图像识别模型可以用于诊断疾病和辅助手术；在安防领域，图像识别模型可以用于监控和人脸识别等。

3）语音识别模型

语音识别模型是一种语音信号处理领域的深度学习模型，可以将语音转换成文本，并支持语音到文本的转换、语音搜索、语音控制等功能。

例如，谷歌助手、苹果的Siri、亚马逊的Alexa等智能助手都使用了语音识别技术。

4）推荐模型

推荐模型是一种个性化推荐领域的深度学习模型，可以根据用户的历史行为和偏好，推荐相关的内容和服务。

例如，在电商领域，推荐模型可以根据用户的购物历史和浏览行为，推荐相关的商品和优惠券；在新闻领域，推荐模型可以根据用户的阅读历史和兴趣，推荐相关的新闻和文章。

5）强化学习模型

强化学习模型是一种通过试错来学习行为的深度学习模型，可以用于游戏、自动驾驶等领域。

例如，DeepMind的AlphaGo可以用于玩围棋游戏；OpenAI的Dota2 AI可以用于玩Dota2游戏。

2 什么是world model

与大模型相比，世界模型是一个更高级别的概念，它涉及到具身智能和现实世界的感知、理解和交互。世界模型试图通过对周围环境进行建模，使人工智能系统能够像人类一样理解和预测环境，从而做出相应的行动。

World Model其本质是对视频中的丰富语义以及背后的物理规律进行学习，从而对物理世界的演化产生深刻理解。

举个例子，在人类的理解中，能够评估出一杯水的重量。当我们拿起一杯水时，大脑其实已经“预测”了应该用多大的力。于是，杯子被顺利拿起。但如果杯子是不透明有盖的而碰巧没有水呢？如果延续杯子有水的理解，我们就会用过大的力去拿杯子，此时发现很轻，我们立刻感觉到不对。对世界的理解里就会加上这么一条：杯子有可能是空的。于是，下次再“预测”，就会对不同内容的杯子使用不同的力。

“不断理解，不断预测”，这种理解世界的方式，是人类理解世界的方式。这种思维模式就叫做：世界模型。

人经历的事情越多，大脑里就会形成越复杂的世界模型，用于更准确地预测这个世界。这就是人类与世界交互的方式：世界模型。

3 什么是Sora

OpenAI官方信息从未表示Sora是world model，而是强调它是world simulator。

Sora，美国人工智能研究公司OpenAI发布的人工智能文生视频大模型（但OpenAI并未单纯将其视为视频模型，而是作为“世界模拟器”），于2024年2月15日（美国当地时间）正式对外发布。

Sora可以根据用户的文本提示创建最长60秒的逼真视频，该模型了解这些物体在物理世界中的存在方式，可以深度模拟真实物理世界，能生成具有多个角色、包含特定运动的复杂场景。

Sora有别于其他AI视频模型的优势在于，既能准确呈现细节，又能理解物体在物理世界中的存在，并生成具有丰富情感的角色，甚至该模型还可以根据提示、静止图像甚至填补现有视频中的缺失帧来生成视频。

在原理上，Sora主要通过三个步骤实现视频训练。首先是视频压缩网络，将视频或图片降维成紧凑而高效的形式。其次是时空补丁提取，将视图信息分解成更小的单元，每个单元都包含了视图中一部分的空间和时间信息，以便Sora在后续步骤中进行有针对性的处理。最后是视频生成，通过输入文本或图片进行解码加码，由Transformer模型（即ChatGPT基础转换器）决定如何将这些单元转换或组合，从而形成完整的视频内容。

3.1 Sora的应用

视频创作：用户可以根据文本生成高质量视频；

扩展视频：可以在给定的视频或图片基础上，继续向前或向后延申视频；

Video-to-video editing：例如将SDEdit 应用于Sora，可以很容易改变原视频的风格；

视频连结/过渡/转场：可以将两个视频巧妙地融合到一起，使用Sora在两个输入视频之间逐渐进行插值，从而在具有完全不同主题和场景构成的视频之间创建无缝过渡；

文生图：图像可以视为单帧的视频，故Sora也能实现文生图。

3.2 目前Sora存在的缺点

尽管Sora的功能十分的强大，但其在模拟复杂场景的物理现象、理解特定因果关系、处理空间细节、以及准确描述随时间变化的事件方面OpenAI Sora都存在一定的问题。

（1）物理交互的不准确模拟：

Sora模型在模拟基本物理交互，如玻璃破碎等方面，不够精确。这可能是因为模型在训练数据中缺乏足够的这类物理事件的示例，或者模型无法充分学习和理解这些复杂物理过程的底层原理。

（2）对象状态变化的不正确：

在模拟如吃食物这类涉及对象状态显著变化的交互时，Sora可能无法始终正确反映出变化。这表明模型可能在理解和预测对象状态变化的动态过程方面存在局限。

（3）长时视频样本的不连贯性：

在生成长时间的视频样本时，Sora可能会产生不连贯的情节或细节，这可能是由于模型难以在长时间跨度内保持上下文的一致性。

（4）对象的突然出现：

视频中可能会出现对象的无缘无故出现，这表明模型在空间和时间连续性的理解上还有待提高。

world model是用Sora能准确生成视频一个很重要的核心，比如人在苹果上咬了一口，并不总是能“咬就会有痕”，sora“有时”也会出错。但通过训练，sora会越来越准确。

Sora的技术文档里有一句话：

Our results suggest that scaling video generation models is a promising path towards building general purpose simulators of the physical world.

翻译过来就是：

我们的结果表明，大规模视频生成模型是一条很有希望构建物理世界通用模拟器的道路。

OpenAI最终想做的，其实不是一个“文生视频”的工具，而是一个通用的“物理世界模拟器”。

4 大模型 Sora和世界模型对自动驾驶的意义

基于World Model所提供的丰富语义信息以及对世界强大的理解力，自动驾驶模型的感知与预测能力有望得到显著提升，规划、控制等下游任务也有望迎刃而解。

类比GPT为所有NLP问题提供了一个通用解，特斯拉、Wayve等公司不约而同地在2023年推出World Model，很大程度上是受到了GPT的启发。对于自动驾驶来说，World Model 是一个无需标注、自监督的预训练模型。可生成自动驾驶相关的连续帧视频场景。

目前，World Model或仍处于GPT-1的阶段，但考虑到目前行业整体对“大模型”潜力的强烈共识、算力的升级以及以特斯拉为代表的玩家此前积累的海量数据，World Model从0到1的爆发或较ChatGPT更快（OpenAI从GPT-1至GPT-3.5共历经4年）。

但考虑到更标准化的解决方案和更巨大的资金投入（资金需求或是这一代BEV+Transformer方案的数倍），行业内有望出现少数几家强大的World Model基础模型层平台方，以SaaS或API的方式为主机厂/运营方提供自动驾驶能力，行业格局和合作模式或将发生较大变化。

中短期来看，World Model或将主要应用于数据合成和仿真模拟环节，厂商的车队规模对算法训练的重要性或有所下降，数据闭环的框架也将有所改变。

长期来看，World Model有潜力成为自动驾驶乃至具身智能领域的基础模型。

#HRMapNet

历史地图发大力！日日新的在线地图新方案（港中文）

无图NOA以来，研究人员focus在端到端的在线矢量地图构建上，该技术在鸟瞰图（BEV）空间中实现，希望能够替代传统成本较高的离线高精（HD）地图。但是当前方法在恶劣环境下的准确性和鲁棒性很容易受限。为此本文提出了HRMapNet，其利用低成本的历史光栅化地图来增强在线矢量化地图的感知能力。历史光栅化地图来源于先前预测的结果，因此可以提供当前帧一定的先验信息。为了充分利用历史地图，作者设计了两个模块来增强BEV特征和地图元素的查询。对于BEV特征，本文设计了特征聚合模块，以编码图像和历史地图的特征。对于地图元素的查询，则设计了一个查询初始化模块，以赋予查询从历史地图中得到的先验信息。这两个模块对于在在线感知中利用地图信息至关重要。HRMapNet能够与大多数现有的在线矢量化地图感知方法集成。问鼎nuScenes和Argoverse 2 SOTA。

开源链接：https://github.com/HXMap/HRMapNet

#GaussianPU

消费级GPU即可完成彩色点云超采样点云超采样的瓶颈

点云超采样的早期方法主要依赖优化技术，但这些方法高度依赖点云的先验知识。基于深度学习的点云超采样网络出现并取得了显著成果。代表性方法有：

分层学习和多级特征聚合

逐步超采样稀疏3D点集的多步骤端到端网络

通过GAN框架学习点的多样化分布，确保超采样片段的均匀性

引入图卷积网络进行超采样，并进行多尺度特征提取

尽管这些深度学习方法取得了很大进展，但由于计算开销大，难以直接处理大规模点云，现有方法大多仅限于处理小于1,024个点的点云片段。此外，这些方法主要针对几何信息进行超采样，未充分利用彩色点云的颜色特性。

基于点的神经渲染技术早期利用神经网络增强点云渲染，随着NeRF的提出，神经渲染取得了巨大进展。目前，3DGS已成功应用于动态3D场景建模、生成式AI内容和自动驾驶等多个领域，展示了其在低级别点云处理任务中的潜力。

彩色点云通过添加颜色属性增强了传统点云（仅包含几何位置信息）的表现。然而，当前机器人传感器的性能限制通常导致彩色点云稀疏且不均匀，进而不可避免地降低了机器人的感知精度和决策能力。应用超采样技术的目标是生成更稠密、更高质量的彩色点云，从而显著提升机器人对复杂场景的解释能力、识别精细物体的能力以及与周围环境的精确互动能力。

当前先进的点云超采样技术通常采用基于多层感知器（MLPs）的深度学习架构的瓶颈在于：巨大的计算需求以及训练中采用的批处理方法通常要求对点云进行预处理，分割为片段。这些片段随后被用作模型的基本输入单元，正如图1所示。将点云分割为片段的超采样模型可能会在这些片段之间产生不连续性。这些不一致性会损害点云的整体质量和感知体验。这个问题对于包含大量点、旨在用于人类视觉感知的彩色点云尤为重要。

本文介绍的GaussianPU[1]一种用于机器人感知的点云超采样新框架，结合了3D高斯斑点（3DGS）和轻量级2D图像恢复网络。该方法解决了机器人应用中处理大规模点云的挑战。引入了一种双尺度渲染恢复模型来处理稀疏点云渲染中的遮挡不确定性。利用3DGS作为2D图像与3D点云之间的桥梁，再结合插值点云的几何和颜色先验，将恢复的图像转换为高质量的3D点云。框架能够让机器人在消费者级GPU上高效生成大规模彩色点云，增强其对环境的理解能力。

主要贡献如下：

提出了一种结合3DGS和2D渲染图像恢复模型的新型彩色点云超采样框架。该框架解决了传统超采样方法直接处理大规模点云时遇到的挑战。
针对点云渲染图像的前后遮挡问题，提出了一种双尺度渲染恢复方法。对原始3DGS进行的系列改进有效提升了超采样点云的质量，并实现了对超采样点数量的精确控制。
在机器人感知场景中的大量实验表明，所提方法显著增强了稀疏彩色点云的视觉和空间精度，提高了机器人对复杂环境的理解和导航能力。

具体方法

如图2所示。整个超采样框架可分为两个模块：数据准备和3DGS超采样。数据准备阶段包括渲染稀疏点云、重建渲染图像以及插值稀疏点云。接着，重建的渲染图像和插值后的点云，连同相机姿态一起输入到超采样模块中，以获得超采样后的稠密点云。

预备知识

考虑一个由N个点组成的点云P，表示为，其中每个点由一个六维向量表示。这个向量包含两个基本属性：几何属性和颜色属性。几何属性由XYZ坐标表示，定义了每个点在3D空间中的位置，而颜色属性由RGB值表示，提供了点云的视觉外观信息。给定一个稀疏点云和一个超采样因子，目标是生成一个包含个点的稠密点云，并且希望

点云渲染与渲染图像恢复

点云渲染：在这项工作中，使用Open3D工具来实现点云的渲染。渲染过程的数学表达如下：

其中，PS表示点的大小，IR表示渲染图像的分辨率，T表示相机的外部参数矩阵，具体形式如下：

其中，和分别代表相机在图像传感器的水平和垂直方向上的焦距，和

在设置点大小

双尺度渲染图像恢复网络：在获得稀疏点云的渲染图像后，使用图像恢复网络恢复稀疏点云的渲染图像，目标是生成与稠密点云渲染效果相当的结果。考虑到轻量化的需求，选择了BRNet作为图像恢复的主干网络。BRNet通过引入均值移位模块来规范化输入图像，从而提升性能。为了结合不同点大小渲染图像的优点并减少其缺点，将FFDNet的输入通道扩展为六个通道，构建了一个双尺度恢复网络。将两种不同点大小的渲染图像拼接后一起输入点云恢复网络，以获得较小尺寸的稠密点云渲染图像。更多关于网络架构的详细信息，请参阅BRNet。在网络训练过程中，考虑到点云渲染图像中存在一定的空白背景区域，对前景和背景区域分配了不同的损失权重，损失函数如下：

其中，和分别表示恢复的渲染图像及其真实值，W表示白色像素集（即背景区域，像素值为(1, 1, 1)），O表示其他像素集（即前景区域）。通过设置不同的权重系数和，可以调整前景和背景区域在总损失中的重要性，从而使网络更专注于前景，同时减少背景对整体损失的影响。

高斯插值

为了更好地控制超采样过程中生成的点数量，在将稀疏点云

在这个公式中，代表点的几何或颜色属性，表示高斯分布的方差，表示标准正态分布。对于点云的几何属性，将设置为点云步长的0.25倍，而对于点云的颜色属性，将设置为0。通过对稀疏点云中的每个点执行R次重参数化，获得了高斯插值后的点云，其点数量是稀疏点云的R倍。

3DGS点云超采样模块

在获得恢复的多视图渲染图像后，利用这些图像进行3DGS超采样。通过优化3DGS，可以根据3D高斯分布中心和球谐系数

通过给定的点云渲染图像及相应的相机姿态，3DGS可以学习以一组3D高斯分布形式表示的3D场景，这使得从任何视角渲染新图像成为可能。为了更好地适应彩色点云的超采样任务并提高感知质量，对原始3DGS框架进行了以下改进：

为了精确实现超采样后期望的点数，在优化过程中禁用了原始3DGS中的克隆、分裂和剪枝操作。这样可以固定3D高斯分布的数量，确保点云中的点数与输入到3DGS超采样模块的插值点云
由于每个点在点云中以相同的大小进行渲染，引入了一个缩放约束，以确保点云整体的一致性。在每次优化迭代中，计算点云中所有点的平均缩放值，并将其分配给所有点，确保它们在渲染过程中具有一致的大小。
除了原始3DGS中的L1距离和DS-SSIM作为优化目标外，还引入了对超采样点云的正则化约束。具体来说，使用高斯插值点云的颜色信息的L1距离作为颜色约束项。此外，还使用原始稀疏点云

其中，是权重系数，和分别表示点云的颜色和几何属性。通过优化，能够生成更加精确的超采样点云。

实验效果

总结一下

GaussianPU是一种新颖的2D-3D混合彩色点云超采样框架，结合了3D高斯斑点技术（3DGS）和2D渲染图像恢复网络。该框架可以在消费级GPU上直接进行大规模彩色点云的超采样，而不需要进行点云分割，从而避免了基于分块处理可能导致的质量下降。此外，提出了双尺度点云渲染图像恢复网络，并对3DGS进行了一系列针对点云超采样任务的改进。这些改进不仅实现了对超采样点数量的精确控制，还显著提高了超采样点云的质量。实验结果表明，在提高稀疏彩色点云的感知和几何质量方面表现出色，并且其处理数百万点的能力表明其在大规模机器人应用（如自主导航和环境建图）中的巨大潜力。

#Hint-AD

面向可解释端到端！语言与感知-预测-规划全面对齐，助力多项任务SOTA

自动驾驶中的端到端架构在可解释性方面面临重大挑战，这阻碍了人机之间的信任。为了执行诸如驾驶解释和3D字幕生成等任务，已探索过了人性化的自然语言。然而，以往的工作主要关注于声明式可解释性的范式，其中自然语言解释并未以自动驾驶系统的中间输出为基础，导致这些解释仅具有声明性质。相比之下，对齐式可解释性在语言与自动驾驶系统的中间输出之间建立了联系。在此，我们介绍了Hint-AD，这是一个集成的自动驾驶-语言系统，能够生成与自动驾驶模型的整体感知-预测-规划输出相对齐的语言。通过整合中间输出和一个用于有效特征适应的整体标记混合子网，Hint-AD实现了理想的准确性，在包括驾驶解释、3D密集字幕生成和指令预测在内的驾驶语言任务中取得了最先进的成果。

为了促进对nuScenes上驾驶解释任务的进一步研究，我们还引入了一个人工标注的数据集Nu-X。代码、数据集和模型均可在网上公开获取，网址为：https://air-discover.github.io/Hint-AD/

背景介绍

端到端的感知规划架构在自动驾驶（AD）和一般具身智能中至关重要，因为它具有利用大量数据进行自监督训练的潜力。然而，这些系统面临着严峻的可解释性挑战，在具身智能问题中，如自动驾驶，可解释性问题尤为突出。当自动驾驶系统直接输出控制信号时，人类乘客很难信任其决策。为了解决这个问题，自然语言作为一种高度用户友好的沟通媒介，已被探索用于通过诸如驾驶解释、3D密集字幕和视觉问答（VQA）等任务来增强可解释性。虽然人类驾驶员认识到BEV轨迹作为解释正在发生什么（WHAT）的价值，但语言提供了为什么发生这种情况（WHY）的补充视角。这些方法可以根据单一标准分为声明式可解释性和对齐式可解释性：即生成的语言是否与自动驾驶系统的中间输出对齐（图1）。

声明式可解释性如近期在驾驶解释、3D密集字幕和视觉问答等方面的研究所示，它直接生成自然语言，而不依赖于自动驾驶系统的中间输入。这种方法经常会产生幻觉，因为语言没有基于全面的中间输出，只是驾驶行为的合理化解释。

对齐式可解释性要求语言与自动驾驶模型的内部状态保持一致。据我们所知，这种方法首先由[14]提出，他们将自动驾驶模型的注意力状态与语言解码器对齐，后来的工作将语言解码器与内部决策状态对齐。

然而，现有研究忽视了语言解码器与自动驾驶流程中的完整感知-预测-规划输出之间的对应关系，导致语言任务与自动驾驶任务之间存在差异。通过自动驾驶流程的中间输出来提高驾驶场景中语言任务准确性的潜力尚未被探索。为此，这里提出了Hint-AD，一个集成的自动驾驶-语言框架，旨在与自动驾驶模型的感知-预测-规划过程进行全面对齐，并生成高精度的语言，以促进自动驾驶的可解释性。

我们开发了两种方法来实现语言与自动驾驶模型之间的全面对齐以及语言输出的准确性：

(a) 开发了一个整体token混合模块，该模块将自动驾驶模型的中间输出token适应于语言解码器，重点在于稳健的特征提取和融合；

(b) 引入了一个对齐任务作为在线数据集，以将语言输出与自动驾驶模型的中间输出对齐，要求语言解码器在整个训练过程中解释自动驾驶模型推理过程中生成的中间token。

在UniAD和VAD这两个最先进的自动驾驶模型上实现了Hint-AD，这两个模型分别采用了光栅化和矢量化表示，以证明Hint-AD的通用性。实验结果表明，Hint-AD在各种语言任务上均达到了最先进的性能，包括驾驶解释（CIDEr得分比基线高出20.4%）、3D密集字幕（CIDEr得分比基线高出185%）、视觉问答（准确率提高1.2%）和驾驶指令预测（准确率提高1.2%）。对齐任务显著提高了语言输出与自动驾驶模型中间表示之间的一致性。此外，我们还贡献了一个基于nuScenes的人类标注的驾驶解释数据集Nu-X，以解决这个广泛使用的自动驾驶数据集上缺乏驾驶解释数据的问题。

#LM-Gaussian

大规模视觉模型助场景重建一臂之力大模型能带来什么帮助？

尽管已有一些尝试试图解决稀疏视角的场景重建问题，但现有的工作仍局限于简单的前向场景，比如LLFF数据集，该数据集只涉及小角度旋转和简单的场景方向。对于大规模的360度场景，不适定性和欠约束性的问题阻碍了这些方法的应用。

3DGS技术在稀疏视角条件下进行高质量的3D重建时面临三大主要障碍：

初始化失败：3DGS严重依赖于预先计算的相机位姿和点云来初始化高斯球。然而，传统的基于运动恢复结构（SfM）技术在稀疏视角下无法成功处理，由于输入图像之间的重叠不足，导致相机位姿不准确和点云不可靠，从而无法进行3DGS的初始化。

输入图像的过拟合：由于缺乏足够的图像提供约束，3DGS往往在稀疏输入图像上过拟合，从而生成严重失真的新合成视图。

细节缺失：由于多视角约束和几何线索有限，3DGS总是无法恢复捕获的3D场景的细节和未观测到的区域，这显著降低了最终的重建质量。

为了应对这些挑战，本文介绍的LM-Gaussian[1]是一种结合了大模型先验知识的创新方法，能够在稀疏输入图像的条件下生成高质量的重建。核心思想是利用各种大模型先验的力量来提升3D高斯分布的重建能力，主要包括三个目标：1）稳健的初始化；2）防止过拟合；3）细节保留。

在稳健的初始化方面，提出了一个新的初始化模块，使用来自DUSt3R的立体视觉先验代替传统的SfM方法。DUSt3R是一个综合性的立体视觉模型，它以图像对为输入，直接生成相应的3D点云。通过全局优化过程，它从输入图像中推导出相机位姿并建立一个全局注册的点云。然而，由于DUSt3R对前景区域的偏好，生成的全局点云经常在背景区域中出现伪影和漂浮物。为了解决这个问题，引入了一个背景感知的深度引导初始化模块。该模块初步使用深度先验来优化由DUSt3R生成的点云，特别是在场景背景区域。此外，通过几何一致性检查和基于置信度的评估进行迭代滤波操作，消除不可靠的3D点。这种方法确保生成一个干净且可靠的3D点云，以用于初始化3D高斯分布。

一旦获得稳健的初始化，通常使用光度损失来优化3D高斯球。然而，在稀疏视角设置下，仅仅使用光度损失会导致3DGS在输入图像上过拟合。为了解决这一问题，引入了多个几何约束，有效地规范了3DGS的优化过程：

引入了一个多尺度深度正则化项，以鼓励3DGS捕捉深度先验的局部和全局几何结构。
引入了一个余弦约束的法线正则化项，以确保3DGS的几何变化与法线先验保持一致
应用了一个加权的虚拟视角正则化项，以增强3DGS在未观测视角下的鲁棒性。

为了保留复杂的场景细节，引入了一个迭代高斯细化模块，该模块利用扩散先验恢复高频细节。利用基于扩散的高斯修复模型来修复从3DGS渲染的图像，旨在增强图像细节并产生良好的视觉效果。这些增强的图像被用作额外的伪真实数据，以优化3DGS。在3DGS优化过程中，反复执行这种细化操作，逐渐将图像扩散先验注入3DGS以增强细节。

具体方法概述

LM-Gaussian旨在通过有限数量的输入图像生成高质量的360度场景新视角。集成了多种大模型先验，并由四个关键模块组成：

基于深度感知的初始化：该模块扩展了DUSt3R，用于相机姿态估计和详细的3D点云创建。通过集成深度先验和点云清理，实现了用于高斯初始化的高质量点云。
多模态正则化高斯重建：除了3DGS中使用的光度损失外，还引入了深度、法线和虚拟视角约束，以正则化优化过程。
迭代高斯细化：使用图像扩散先验增强由3DGS渲染的图像。这些改进的图像进一步细化3DGS的优化，通过迭代引入扩散模型先验来提高新视角合成的细节和质量。
场景增强：除了图像扩散先验，还应用了视频扩散先验，进一步增强3DGS渲染图像的逼真视觉效果。

基于背景感知的深度引导初始化

传统上，3D高斯分布（3DGS）依赖通过运动恢复结构（SfM）方法计算的点云和相机位姿进行初始化。然而，在稀疏视角设置下，SfM方法经常面临挑战。为了解决这个问题，提出了利用立体视觉先验作为替代方案。DUSt3R 是一个端到端的稠密立体模型，它可以接收稀疏视角图像作为输入，并生成稠密的点云和相机位姿。然而，DUSt3R生成的点云在场景的背景区域容易出现浮动物体、伪影和失真，特别是在3D场景的背景部分。

为了解决这些问题，提出了基于背景感知的深度引导初始化模块，该模块能够生成稠密且精确的点云。此模块集成了四个关键技术：

相机位姿恢复：最初，利用DUSt3R为每张图像生成点云。然后，将相机位姿和点云对齐到一个全局一致的坐标系中。此过程通过最小生成树算法来完成，以确保所有相机位姿和点云的对齐是一致的。接下来，使用一个优化方案来提升对齐点云的质量。起初，按照DUSt3R的方法，最小化点云投影损失。对于图像对，其中和
深度引导优化：仅依赖点云投影损失进行优化可能不足以重建大规模场景，这会导致背景区域浮动和场景失真的问题，这些问题会影响后续的重建过程。为了解决这些问题，引入了一个单目深度估计模型（Marigold），该模型以其在深度估计领域的高性能表现而闻名，可以为场景深度信息提供有力的支持。优化网络中的深度引导优化通过结合DUSt3R的输出与深度指导，显著提高了深度感知，从而有效减少了场景失真。
点云清理：为了消除浮动和伪影问题，实施了两种清理策略：基于几何的清理和基于置信度的清理。基于几何的清理在深度优化过程中迭代执行，通过比较3D点在不同视角下的投影差异来去除不可靠的3D点。每经过指定的迭代次数后，执行几何清理步骤以移除漂浮的点云。优化过程结束后，应用基于置信度的清理策略，以在前景和背景之间进行区分，并使用不同的置信度阈值处理前景和背景区域，从而确保生成的点云更加稳定和准确。
深度优化的点云清理：在基于几何和置信度的清理之外，还在优化过程中引入了背景感知的深度引导，以确保不仅前景区域细致，背景区域也得到了合理的优化。具体方法包括使用图像对的投影一致性来减少背景噪声和伪影，进一步提升点云的全局一致性。

多模态正则化高斯重建

通过基于背景感知的深度引导初始化，获得了稠密的点云和相机姿态。这些变量用作高斯核的初始化。传统的3DGS方法使用光度损失函数（如L1和LSSIM）来优化3DGS核，使其捕捉基础的场景几何结构。然而，在输入图像极其稀疏的情况下，挑战随之而来。由于高斯表示的固有偏差，高斯核容易在训练视图上过拟合，从而导致在未见过的视角中性能下降。为了解决这个问题，通过整合光度损失、多尺度深度损失、余弦约束的法线损失和基于范数加权的虚拟视图损失，增强了高斯优化过程。

光度损失：与传统3DGS一致，首先计算输入RGB图像与高斯渲染图像之间的光度损失。光度损失函数结合了L1和SSIM项。

其中，是一个超参数，

多尺度深度正则化：为了解决上述挑战，可以将深度信息引入高斯场景，以在训练期间提供正则化。与初始化模块类似，首先使用单目估计模型Marigold从稀疏的输入图像中预测深度图。由于单目深度估计模型通常提供相对深度预测，而不具有真实场景的尺度信息，使用皮尔逊相关系数（PCC）作为度量来评估深度图之间的相似性。皮尔逊相关系数是一种基本的统计学相关系数，用于量化两个数据集之间的线性相关性。简而言之，它评估了两个不同分布之间的相似性。

余弦约束的法线正则化：为确保几何变化与法线先验保持一致，引入了余弦约束的法线正则化项。这个正则化项通过强制高斯核的法线与法线先验对齐，进一步提升了3DGS在几何结构上的一致性。

基于范数加权的虚拟视图正则化：为了提高3DGS在未见视角下的鲁棒性，引入了基于范数加权的虚拟视图正则化项。使用一个加权的融合算法来创建点渲染图像，并与高斯渲染图像保持一致性。这些虚拟视图提供了附加的几何约束，减少了网络在稀疏输入图像下的过拟合倾向。

最终的多模态联合优化损失函数表示为：

其中，、、

迭代高斯细化

在此阶段，实施了一种迭代优化方法，以逐步增强场景的细节。首先，使用高斯修复模型对来自虚拟视角的高斯渲染图像进行均匀增强。该模型能够将模糊的高斯渲染图像优化为清晰且逼真的表示。优化后的图像作为附加指导，结合深度和法线正则化项，帮助进一步优化高斯核。经过

1) 迭代高斯优化

最初，使用高斯核从虚拟视角生成张图像。随后，使用高斯修复模型对这些图像进行均匀增强，生成一组修复后的图像，记作。为了保持场景的连贯性并减少潜在冲突，将降噪强度设置为较低，并在每次修复过程中逐步重新引入有限的细节到高斯渲染图像中。这些修复后的虚拟视角图像，连同来自训练视图的单目深度图和法线图（详见IV-C部分），将用于调节高斯优化过程。高斯细化阶段的整体优化损失

其中，和分别对应于多模态正则化高斯重建过程中的深度正则化和法线正则化。修复损失的权重由控制，修复损失

在此公式中，通过光度损失函数计算修复图像与高斯渲染图像之间的差异，并将修复图像作为指导参考。参数、和

通过这种迭代优化策略，生成的新图像将逐步变得更加清晰，而不会受到视角差异所导致的模糊影响。优化过程将持续进行，直到确认扩散过程不再产生令人满意的结果，如与初始场景的偏差或视角之间的不一致性所示。

2) 高斯修复模型

模型架构

高斯修复模型的架构如图6所示。该模型以高斯渲染图像和真实世界的输入图像为输入。在图6(b)中，高斯渲染图像 \ 经过图像编码，提取潜在的图像特征。真实世界的输入图像通过一个GPT API处理以生成描述提示 σ\，然后进行编码以获得文本的潜在特征。这些图像和文本的潜在特征作为条件输入给ControlNet来预测噪声 εθ\，并逐步去除高斯渲染图像中的噪声。该模型通过在ControlNet层中注入LoRA（Low-Rank Adaptation）进行微调，最终可以生成修复后的高斯渲染图像。图6(c)展示了Lora-ControlNet的工作原理，其中LoRA权重被集成到ControlNet的UNet中的每个Transformer层内。保持Transformer块的原始参数不变，仅训练低秩矩阵 \ 和 \，其中 \、\，并且 \。在文本编码器方面，如图6(d)所示，LoRA权重被集成到编码器的每个自注意力层中。Lora-Text编码器的输入是场景提示，输出为文本嵌入。

训练过程

首先，进行数据准备，收集图像对，场景中的输入图像作为参考图像。对于每个训练视角，随机选择 ω\ 张高斯渲染图像，并将其与输入图像配对，形成训练对。随后，这些图像对用于训练高斯修复模型。

如图6(a)所示，输入图像 \ 经过前向扩散过程。具体而言，图像被输入到图像编码器中，以提取潜在表示 \。该潜在表示随后经过一个扩散过程，其中噪声 ε\ 在 \ 步中逐步加入。在获得潜在表示 \ 后，开始反向扩散过程，如图6(b)所示，Lora-UNet和Lora-ControlNet在每一步预测噪声 εθ\。此预测的噪声与扩散过程中引入的噪声结合，进一步优化生成修复后的图像。

场景增强

鉴于输入图像稀疏且训练视角有限，预计从相邻新视角渲染的图像可能会显示出差异。为了确保沿着指定的相机路径进行高质量且一致的渲染，提出了一个视角增强模块，该模块利用视频扩散先验来改善渲染图像的一致性。

该模块的重点是增强渲染图像的视觉一致性，而不涉及高斯核的细化。首先，在预定的相机轨迹上渲染多张图像并进行分组处理。随后，使用一个视频扩散UNet来对这些图像进行去噪，以生成增强后的图像。在视频扩散模型中，使用DDIM逆向将高斯渲染图像映射回潜在空间，其公式可表达为：

其中是时间步长，表示一个引导扩散过程的递减序列。σ

将高斯渲染图像映射到潜在空间的原因是为了利用潜在空间的连续性，保留不同视角之间的关系。通过在潜在空间中集体对图像进行去噪，旨在提高视觉质量，同时不牺牲空间一致性。

实验效果

总结一下

LM-Gaussian是一种利用大规模视觉模型先验的稀疏视角3D重建方法。该方法包含一个稳健的初始化模块：

利用立体视觉先验来帮助恢复相机姿态和可靠的高斯球体。多模态正则化方法则利用单目估计先验来防止网络过拟合。
采用了迭代扩散细化方法，将额外的图像扩散先验引入高斯优化中，以增强场景细节。
利用视频扩散先验进一步改进了渲染图像的真实视觉效果。

与传统的3DGS方法相比，显著减少了数据采集要求，并且即便在360度场景中也能获得高质量的结果。当前，LM-Gaussian基于标准的3DGS构建，该技术目前仅适用于静态场景，未来希望引入动态3DGS技术，以实现动态建模

#将 MOE 塞到 LoRA

在传统的 LoRA 中加入一个 Mixer 矩阵，进行混个不同子空间的信息。

Nothing will work unless you do. --Maya Angelou

文章的基本信息是：

标题：Mixture-of-Subspaces in Low-Rank Adaptation

链接：https://arxiv.org/pdf/2406.11909

代码：https://github.com/wutaiqiang/MoSLoRA

简介：在传统的 LoRA 中加入一个 Mixer 矩阵，进行混个不同子空间的信息。设计非常简单：

最初的想法

说来也是巧合，之前有很多的文章尝试将 LoRA 和 MoE 结合起来，他们基本上都是把 LoRA 当做 MoE 的 Expert，然后塞到 MoE 结构之中，之前也介绍过一些，如文章 https://zhuanlan.zhihu.com/p/676782109、 https://zhuanlan.zhihu.com/p/676557458、 https://zhuanlan.zhihu.com/p/676268097、https://zhuanlan.zhihu.com/p/675186369。这些文章无疑都是将 LoRA 看作 MoE 的 expert，一来缺乏动机，二来影响了 LoRA 的可合并性，三来训练还慢。

闲来与同事聊天，同事说没见过有文章把 MoE 塞到 LoRA 里面，我当时愣了一下。啊？MoE 塞到 LoRA 里面，意思是说把 MoE 的那种 gate+多专家去做 LoRA 的 lora_A 和 lora_B ?

最直观的设计就是：

有点抽象，但稍微知道点 MoE 和 LoRA 的应该都能懂

其实想出这种设计还是很直接的，毕竟 lora 和 MoE 都是很成熟，很简单的设计。

先不谈有没有动机，反正水文章嘛，都能找到点。就说这个设计，其实有点不合适，为什么呢？

核心就在于 Gate 这玩意，MoE 是希望尽可能训多点参数但计算量不要大太多，因此整了多个Expert 选用一部分并设计了 Gate Router 的机制。但是，LoRA 本身参数量就不大，且rank 大又不一定效果好，堆这个参数属实没必要。此外，LoRA 的好处就在于可以 Merge 回原来的权重，infer 的时候 0 延迟。这个Router Gate 因为和输入 x 耦合，因此没法 merge 回去了。这就带来了推理延迟。

去掉Gate，直接上

有了上面的分析，下一步自然就是要去掉 Gate 了。为了确保能合并，因此所有的 expert 都得用，此时就变成了：

仿佛在拼积木

有了这个设计以后，同时又出现了一些 concern：虽然说 infer 的时候，大家都可以合并到原始权重，都是 0 延迟。但是训练的时候，比如我这个图画的，训的参数是之前的 3 倍多。(在当今这个大环境下，怕是要被审稿人喷)

所以说，要说公平，那就不能设置为 r，每个模块还是得设置成r/k，上图的 case 对应的就是 r/3，这样训练的参数没变，同时 infer 都是 0 延迟。

这也就是论文里面的two-subspace-mixing 的方法的由来。

'多头注意力'的视角

既然把每个专家设置成了 r/k 的大小，这玩意就很像是多头注意力了，有维度切分+并行操作+最后合并的操作。这不禁让我思考，这和多头注意力有什么关系？原始的 LoRA 能不能等价拆开？

说到拆开，有两个量可以拆，一个是 rank，一个是输入的维度 d。若是直接说多头，可能大家想到的都是直接把 d 拆开，而不是把 rank拆开。那么这两种拆开我们都可以分析：

i) 把 d 拆开的视角：

一如既往的抽象，熟悉矩阵运算的应该能一眼看明白

图中展示的是 d拆分2 个 d/2 的 case，为了好理解，我刻意画了矩阵视角。从矩阵运算角度来看，在 d 维度切分以后，相当于过了两个 A，求和，然后再过两个 B，最后拼接在一起。这三个视角都是等价的。

说实话，要说改进这个，真就没啥好改的。

ii) 把 r 拆开的视角：

这个视角去看，就挺好的，也比较简介

类似地，也可以将 rank 去拆开。上图展示了将 rank 拆开成两个子块的过程。可以看出，等价于两条支路，每个支路 rank=r/2，最后求和。明显比上面的拆分 d 的方法更优雅。

在这个视角下，一个很简单的改进，就呼之欲出了：

思路很简单的，其实就是将中间的平行支路扭在一起，从公式的角度来看，从A1B1+A2B2 变成了 (A1+A2)(B1+B2)=A1B1+A2B2+A1B2+A2B1.

这么来，相当于多了两项。暂且称这个为扭麻花方案吧。

阶段性结果，但还不够

有了上面的分析，那么就开始做实验了：

微调 LLaMA3做 commonsense reasoning，发现还是有提高的。

不过，这么做还有个问题，那就是代码效率其实不高。划几条并行的线然后扭个麻花很简单，但是实现起来得看怎么去实现。我初始化了两个 expert 依次去 forward，因此计算效率不高。当然，也可以学习 MHA 的代码，先整个 infer，然后再拆分向量（相当于 A1和A2两个线性层拼在一起 forward，得到结果后再将向量拆开）。

这就启发了另外一个思考，也就是说，这一通操作有很多的线性层的拆分与合并操作，我们之前的分析都是从 linear 层的拆分合并去考虑的，没有考虑向量的拆分合并操作。向量角度等价于：

核心在于中间的 r 向量进行一系列操作(切分，求和，复制)

之前提到的扭麻花操作，等价于中间的 r维度的向量，拆分，逐位相加成一半长度，然后复制，再拼接，获得最终的r'。从这个视角去看，这种多 expert 的扭麻花本质就是在 r 维的向量上加一套组合拳。

混合矩阵的引入

既然是加一套组合拳，这个组合拳（r维度的向量，拆分，逐位相加成一半长度，然后复制，再拼接）用矩阵来看，是什么呢？

一番分析下来，不难得到相当于中间加了一个固定的蝴蝶矩阵因子（关于蝴蝶矩阵因子，可以参考：https://weld.stanford.edu/2019/06/13/butterfly/ ）。

既然如此，那么有没有可能模仿 Tri Dao 的做法，引入一堆蝴蝶矩阵因子？想想还是没啥必要，因为lora 本身计算量不大，无需这样的拆分，其次就是延迟可能变大很多 (此外，调研发现，蝴蝶矩阵序列在 OFT 系列里面是有应用的，也就是 BOFT)。

不往蝴蝶矩阵序列走，另外一个直观的想法就是把这个矩阵升级为可学习的矩阵了。我在论文中把这个矩阵称为 Mixer 矩阵，那么：

原始的 LoRA 相当于使用固定的单位矩阵做 Mixer，中间的扭麻花方案相当于插入固定的蝴蝶因子矩阵做 Mixer，论文里升级为可学习的 Mixer，且矩阵全部元素可学习，也就是所提出的MoSLoRA方法。

注1：这种形式和 AdaLoRA 还是蛮像的，不过 AdaLoRA 中间是一个 SVD 分解的特征值，且前后矩阵都加上了正交化约束。注2：我在写论文的时候，发现了 Arxiv 有个优秀的同期工作 FLoRA: Low-Rank Core Space for N-dimension，他们的论文是从 Tucker 分解的角度去切入的，思路很巧妙，也很优雅，感兴趣的也可以看看他们文章和解读。

回到MoE的视角

回到 MoE 的视角去看，也就是回到论文最开始的图：

我们可以简单地将 Mixer 理解为 MoE 的 Gate 生成的 weight，此外这个 Gate有几个特性：

这个 weight 和输入无关，进而确保可合并性

这个 weight 是稠密的，意思是所有的 expert 都用上，而不是 MoE 的那种选取 top-k

原始的 vanilla LoRA 可以看作是这个 Mixer 矩阵固定为单位矩阵。

看到这，还可以看明白另外一件事，也就是:

【多个并行的LoRA分支选 top-k个输出最后求和】这种常规 LoRA+MoE 设计，本质上相当于 Mixer 具备：i)每行都是同一个元素 ii)部分行全行为 0 iii) 非 0 行的元素由输入来确定 iv) 不可合并这些性质或者特点。

后记

写到这里，其实也把整个思维的推进过程都说清楚了。当然，论文不可能这么写，太冗长且难以理解。知乎上尚且没几个人有耐心看完，更别说审稿人了。不过整个的思考过程还是收获很多的，可能一个东西刚开始想的时候复杂，换个角度以后，竟然会如此简单。

2024/07/06 补充证明

这点也正如@dt3t的评论，直觉上来说，中间插一个 W，如果把 AW 合并看作 A'，那岂不是和直接学 A‘B 效果是一样的？

其实，并不是一回事，就算是初始化等价，不代表后续优化的路径是一致的。正如重参数化，虽然看起来是等价的，但是学的结果就是不一样。这个角度去看，Mixer 也可以看作是重参数化分支的形式：

其中 I 是固定的不学习的矩阵。这样就相当于原始 LoRA的旁边加了一个并行分支，和 RegVGG等重参数化一致了。

当然，这里也给出一个【后续优化的路径是不一致的】的简单证明：

https://github.com/wutaiqiang/MoSLoRA/blob/main/MoSLoRA_proof.pdf

也可以直接看图：

只有当 W 是固定的正交矩阵，才是等价的，不然就算初始化一致，优化过程也会有差异。

在 MoSLoRA 中，W 是可学习的，且我们分析了初始化对结果的影响。

#宝马利润暴跌83%

董事长火速访华...

用百米冲刺的速度跑马拉松？

这不是异想天开，而是宝马董事长齐普策在采访中被问到，如何参与中国市场竞争时，给出的一句精炼回应。

今年过去的三个季度，宝马的销量陷入低迷，尤其是在中国市场，三个季度的在华销量下滑13.2%，曾经的利润奶牛逐渐被冷落。

更糟糕的是，宝马的财务业绩也出现了明显的下滑，税后利润仅4.76亿欧元，更是暴跌了83.8%，毛利率下滑近5个百分点。

但一时折戟，没有让宝马在中国萌生退意，反而还把“全村的希望”都放在中国，其中的原因，齐普策解释得很清楚：

中国的动向，将引领世界的方向。

齐普策回应一切

齐普策现身中国，已经不是什么新鲜事。

在过去的两年里，这位宝马董事长已经来中国不下6次。不久前，齐普策进行了今年的第三次访华，同时也接受了一波小范围的媒体对话。

在对话中，齐普策坦言，宝马正在中国市场中经历残酷的竞争。即便他是一个乐观的长期主义者，但宝马面临的困境，依然让他倍感压力。

不过，压力归压力，齐普策的底气依然充足，如何应对接下来的中国市场竞争，齐普策用了一个形象的比喻：

我们是在用百米冲刺的速度跑中国马拉松。

论对市场的关注度，齐普策最看重的就是中国。

这一点，不仅仅是从齐普策频繁的中国行上看出，宝马在中国的投入力度也是证明。

宝马在海外市场最大的研发中心，就是在中国建立的，地位等同于德国本部。

还有大力押注的沈阳华晨宝马生产基地，宝马已经累计投入了超过1000亿人民币，并且把中国看作实现未来希望的“土壤”：宝马的划时代产品新世代车型，生产基地就在中国。

为什么花这么多精力在中国？换句话说，为什么齐普策的选择是中国？

齐普策曾多次解释其中缘由，在这次采访中，他继续重申了这个观点：

中国的动向将引领世界的方向。

但想在中国谋出路，也不是件简单的事，价格内卷给宝马带来的打击，到现在还在持续。

对话中，齐普策也表达了他对于“内卷”的看法：

对于“内卷”现象的出现，齐普策认为，当竞争进入高度紧张的状态时，人们会陷入焦虑当中，缺乏理性思考，这时候会只作被动反应，而非主动思考。

为了应对这种状况，要做的应该是暂停并反思，在竞争中找到自己的优势，才能立于不败之地。如果一味无意识地模仿别人，最终也只会陷入生存危机。

齐普策表示，对宝马来说，驾驶乐趣一直是宝马的核心，即便在电动车时代也是如此。

真正的驾驶乐趣，源于车辆与驾驶者之间的信息传递和情感连接，这也正是前瞻性设计的价值所在。

他拿出全新BMW 4系举例，前脸设计起初曾受到许多争议，但半年过去，这种设计就被市场接纳了，“这就是设计前瞻性的力量。”

对于“内卷”的市场现状，齐普策坦言，希望当前激烈的竞争中，不会有太多企业倒下，尽快回归到比较活跃、健康的竞争。

良性竞争既可以为企业保障利润，也能为消费者保障最佳的产品，对整个系统都是有益的。

齐普策有此感慨，实际上也是因为宝马在“内卷”当中被重创，无论是销量还是财务状况，宝马都在困境中挣扎。

宝马的在华困境

上周宝马公布的今年第三季度业绩，继续诉说着当前的困境：

宝马第三季度全球销量为54.1万辆，同比下降13%，环比下降12.6%；今年1-9月，宝马全球销量为175.4万辆，同比下跌了4.5%。

销量出现大幅下跌，一方面是受到安全隐患召回事件的影响，宝马曾在9月份召回了150万辆车，这些车辆可能在存在刹车隐患。

另一方面，中国市场成为销量“重灾区”。

第三季度中国市场的宝马交付量为14.77万辆，同比下滑29.8％，环比下跌21.6%，是下滑幅度最大的单一市场。

实际上，这种下滑趋势从第一季度就已经开始，过去的三个季度中，宝马在中国的总销量为52.42万辆，同比下滑了13.2%。

而在中国多家车企“内卷”攻势之下，宝马的在华销量出现大规模下降，为了有所挽回，宝马也不得不“以价换量”，以腰斩式的大降价加入“斗争”。

但效果不仅没有如愿，还“赔了夫人又折兵”，销量没能保住，品牌的高端形象也大打折扣。

所以宝马的第一次价格战，在加入后一个月就宣布退出了。

是的，第一次，因为退出价格战并没有挽回损失，涨价令消费者感到更加不满，反而让销量降得更快，所以宝马在9月重返了价格战。

可惜，从第三季度的业绩来看，这一次价格战依然没有起到更好的效果，不但销量下滑得更快，财务指标也出现了明显的降低。

第三季度宝马的营收为324.06亿欧元（约2475亿元），同比下降15.7%，环比下降12.3%；其中，汽车业务营收为278.54亿欧元（约2127.5亿元），同比下滑13.2%，环比下降13.1%。

第三季度税后净利润为4.76亿欧元（约36亿元），同比暴跌了83.8%，环比暴跌82.4%。

算下来，宝马这一季度的单车利润只有880欧元（约6721元），相比去年同期的4716欧元（约36021元）下跌了81%。

受到利润影响，宝马第三季度的毛利率，从上一季度的18%，骤降到了13.1%，是四年以来的最低水平。

不过，如果从根本上来说，宝马的困境其实还是源于转型进度缓慢。

按照宝马的计划，在2030年之前，纯电动车型的交付量占全球年交付量的50%以上。

而且，虽然宝马在中国市场推进电动化时，表现得非常积极，但始终没有建立起自己的纯电平台，有一些车型是油改电改造的产品，没有办法充分发挥电动车优势。

公司真正的纯电平台Neue Klasse，还要等到2025年才会面世。

在电动车的新车型上，宝马推出的频率也比较低。如今的中国市场，半年就涌现了上百款电动车型，宝马这样的速度，看起来很难“吃上热乎饭”。

如今，宝马正在全力押注划时代产品——新世代车型，也被看作是宝马“全村的希望”。

上个月，宝马带着新世代概念车和新世代X概念车，首次在巴黎车展上亮相。

据官方介绍，新世代车型将采用全新的电子电气架构，能效提升25%以上，并且基于800伏平台，高压动力电池电量从10%至80%的充电时间，相比前代产品可最多减少30%，续航里程提升30%。

新世代的首款车，明年将在全球投产，而中国会在2026年的沈阳生产基地投产，明年开启道路测试。

百年豪华品牌大象转身，想要在中国市场的马拉松里拿到好名次，是该提提速了。

#智驾无图真的可以实现吗？

自动驾驶技术的快速发展正加速推动整个汽车行业向智能化、自动化和网联化方向演进，车辆的定位、感知及决策需求也不断提升，为了实现城市复杂路况下的自动驾驶，精准的定位信息成为汽车实现自动驾驶的基本要求。传统GPS提供的普通导航定位精度一般在10 m～30 m，无法满足自动驾驶系统对厘米级甚至毫米级精度的需求，尤其是在高速行驶或面对复杂交通环境时，定位误差可能会直接导致车辆的驾驶决策失误，带来安全隐患。

自动驾驶技术架构图

高精度定位技术的出现，为智能驾驶系统解决了“我在哪”的核心问题。通过提供厘米级别的精准定位，高精度定位技术为智能驾驶车辆在复杂的城市交通场景下提供了稳定的导航与控制支持，满足了其对安全性、精确性和实时性的高标准要求。高精度定位技术不仅可以提供基于全球坐标系的绝对位置，还能够通过实时动态定位、精密单点定位等技术手段，将定位精度提升至厘米级，极大地减少了因定位误差带来的决策偏差。

与车载摄像头、激光雷达等相对定位传感器不同，高精度定位在提供绝对位置信息方面具备全天候、不间断的特点，因此可以作为车载传感器的冗余手段，在传感器信号失效或环境感知不稳定的情况下，持续为车辆提供精确的位置信息。

高精度定位技术的发展与普及在很大程度上得益于北斗卫星导航系统、5G通信网络、低轨卫星等新兴技术的推动。近年来，国内外逐渐兴起了以城市NOA（导航辅助驾驶）为代表的L3级别智能驾驶应用场景。相比于高速公路，城市道路的行驶环境更为复杂，存在着较多的交叉路口、动态障碍物等问题，对高精度定位技术的需求更大。

随着华为、小鹏等企业在L3级别智能驾驶技术上的突破，高精度定位逐步成为智能驾驶应用中的重要支撑技术，并在政策支持和市场需求的双重推动下快速增长。即便在进入2024年后，越来越多车企提出了轻地图，甚至无图方案，但高精度地图在智能驾驶中的实际应用依然很多，高精度地图依然是众多车企实现自动驾驶必不可少的一项技术。

城市导航辅助驾驶与高精度定位的发展

1.1 城市NOA发展现状

城市导航辅助驾驶（NOA）作为L3级别智能驾驶技术的重要应用方向，是近年来自动驾驶领域的关键突破之一。与高速公路上的自动驾驶不同，城市NOA需要车辆在具有复杂交通环境的城市道路中实现自动驾驶功能。2023年，国内多家知名车企，如华为、小鹏等，纷纷推出了具备城市NOA功能的智能驾驶车型，推动了高精度定位技术的进一步发展。根据市场调研数据显示，2022年搭载NOA功能的车型数量约为26万辆，到2023年迅速增长至95万辆，并预计2024年将达到150万辆以上，这意味着在短短两年间NOA车型年均增长率将达到300%以上。

标配NOA/城市NOA功能汽车数量（万辆）

各大品牌高精度定位技术的车型

这种显著的增长趋势表明，市场对高精度定位技术的需求极为旺盛，同时也反映出智能驾驶在中国城市交通中的重要性逐渐提升。城市道路的复杂性，例如频繁的路口、动态障碍物以及多样化的道路特征等，使得高精度定位系统在城市NOA的应用场景中愈发不可或缺。不同于高速公路上简单的路线和较少的交通变量，城市道路要求车辆具备精确的路径跟踪、动态避障和实时决策能力，这些都对高精度定位提出了极高的要求。

智能驾驶在复杂的城市交通中应用，需要车辆实现对路径规划和环境感知的精确控制，因此定位精度和定位稳定性成为了影响城市NOA落地的重要因素。高精度定位在城市场景中的广泛应用不仅能满足车辆对厘米级别的精确定位需求，还能在车载传感器不稳定、信号遮挡等情况下提供稳定的定位服务，进一步保障智能驾驶系统的行驶安全和稳定性。未来，随着更多车企加入城市NOA的推广行列，高精度定位技术的需求预计将持续增长，从而推动智能驾驶和高精度定位技术的发展实现双赢。

1.2 高精度定位的技术路径

高精度定位技术路径的多样化，是应对城市道路复杂性和精确性需求的必然趋势。传统的GPS定位系统，由于受到大气误差、设备误差以及卫星轨迹误差等因素的影响，其定位误差较大，无法满足智能驾驶系统的高精度需求。为了达到厘米级的定位精度，RTK（实时动态定位）、PPP（精密单点定位）和PPP-RTK等多种高精度定位方案被广泛应用到智能驾驶场景中。

RTK定位技术是一种利用基准站和流动站之间的差分信息进行定位的方案，具有较高的实时性和精度。在RTK系统中，通过接收和解析基准站发送的误差修正信息，流动站可以将定位精度提高至厘米级。然而，RTK技术的应用受到基准站布设密度和信号覆盖范围的限制，适合于相对固定、基站密度较高的场景。

PPP（精密单点定位）技术则通过提供精确的卫星轨道数据，使接收器能够实现无需基站支持的高精度定位。与RTK技术相比，PPP定位精度高且适用范围广，适合跨区域应用，但需要较长的收敛时间，且实时性较差。近年来，PPP-RTK技术结合了RTK和PPP的优势，通过全球基站网络和区域性基站的协同合作，在实现厘米级定位精度的同时，提供了更广泛的信号覆盖范围和更强的实时性。

在城市NOA应用中，PPP-RTK已成为主流的定位技术路径。PPP-RTK不仅弥补了RTK在城市场景中的信号覆盖不足，还通过区域性基站有效消除了卫星轨道和信号传输过程中的误差，为城市智能驾驶系统提供了稳定可靠的厘米级定位支持。此外，低轨卫星技术的发展也为PPP-RTK技术的广域覆盖和信号增强提供了有力支持。未来，随着北斗系统和5G通信网络的完善，PPP-RTK技术将在智能驾驶领域发挥更大的作用，为高精度定位的规模化应用创造条件。

PPP-RTK 术示意图

有图与无图模式下的高精度定位应用

2.1 有图模式与无图模式的技术对比

在智能驾驶的高精度定位应用中，有图模式和无图模式是两种主要的技术实现路径。两者的技术差异显著，各自适用于不同的道路场景和应用需求。有图模式是指智能驾驶系统依赖高精度地图来实现车辆定位、路径规划和驾驶决策。这种模式通常使用高精度地图作为主导数据源，将道路环境的细节信息（如车道线、交通标志等）预先存储到地图数据库中，车辆在行驶过程中利用高精度地图进行路线规划和环境识别。

在有图模式下，高精度地图中的详细数据可以帮助车辆准确识别车道位置、路标信息和道路边界，从而在驾驶决策时提供精确的路径指引和控制策略。相较于无图模式，有图模式在环境相对稳定的高速公路和快速路等结构化道路上表现尤为优越。然而，这种模式对地图实时更新要求较高，一旦地图数据出现偏差或滞后，可能会导致车辆决策失误。此外，高精度地图的存储和实时更新需要占用大量的计算资源和存储空间，这在一定程度上限制了有图模式的推广。

高度地图车道示意图

与之相比，无图模式是一种依赖车载传感器（如激光雷达、摄像头等）进行环境实时感知和驾驶决策的模式。无图模式不依赖高精度地图，而是通过激光雷达、摄像头等传感器实时获取车辆周围的环境数据，利用计算算法和感知技术进行障碍物检测、道路识别和导航决策。无图模式的优势在于能够快速应对道路上的突发变化，并适用于交通频繁变动的城市道路环境。

无图模式的缺点是，车辆在感知算法和计算力方面的依赖性较高，系统对数据处理的要求非常严格，尤其在复杂道路环境中更需要强大的算力支撑。此外，由于无图模式在导航过程中完全依赖车载传感器，如果遇到遮挡或信号受限的情况，系统可能无法获取到足够的信息，从而影响驾驶决策。总体而言，有图模式和无图模式各具优势，但随着智能驾驶的发展，越来越多的厂商选择在不同场景中灵活应用两种模式，以达到最优的安全性和可靠性。

有图模式与无图模式对比

2.2 “轻地图重感知”方案在智能驾驶中的应用

传统高精度地图模式虽然在高速公路等结构化道路上表现优越，但由于城市道路的动态特征较多，频繁更新地图信息成为技术上的难题，且成本较高。为解决这一问题，业内逐渐采用了“轻地图、重感知”的技术方案，以降低智能驾驶系统对高精地图的依赖，同时实现高精度定位在城市复杂道路中的广泛应用。轻地图方案的核心在于减少地图信息的存储量和更新频率，仅保留重要的道路特征信息。

高精地图与轻地图对比

在轻地图方案中，高精度定位技术为车辆提供了重要的绝对位置信息，使车辆在没有完整的高精度地图支持的情况下，仍能通过车载传感器感知周围环境，进行实时定位和路径决策。轻地图方案有效降低了地图更新频率和成本，尤其在城市复杂场景中可以减少系统对云端地图的依赖，提高了系统的独立性和反应速度。通过结合高精度定位和实时感知算法，轻地图模式可以应对复杂的城市环境变化，为智能驾驶提供高效、可靠的定位和导航支持。

在轻地图重感知的应用场景中，高精度定位为智能驾驶系统的路径规划和决策提供了底层支撑，尤其是在遇到复杂的交通环境时，通过高精度定位技术与传感器的多帧融合，可以提高车辆在障碍物识别、路面判断和环境感知中的准确性。未来，轻地图模式的推广将有助于降低智能驾驶技术的落地成本，增强智能驾驶系统在多样化环境中的适应能力，为实现更广泛的市场应用提供了可能。

高精度定位核心技术方案

3.1 主要技术：RTK、PPP和PPP-RTK的详细分析

高精度定位技术中的RTK（实时动态定位）、PPP（精密单点定位）和PPP-RTK（混合定位）是当下智能驾驶领域最为常用的几种高精度定位技术。这些技术的差异主要体现在使用场景、精度需求以及信号覆盖范围等方面。

RTK技术是基于载波相位差分的定位技术，通过设置固定的基准站和车载的流动站，实时接收卫星信号和基站发出的差分校正数据，将定位精度提升至厘米级别。RTK的实时性较强，适用于短距离范围内的高精度定位。然而，RTK技术的应用在一定程度上受制于基准站的密度分布和信号覆盖情况。例如，在城市道路中，RTK的性能可能会因为高楼遮挡或基站信号不稳定而受到限制。因此，RTK技术更适合应用在基站网络完善的高速公路等固定路线场景中，而在信号复杂、基站布局不足的城市道路中，RTK的稳定性会有所下降。

PPP技术则采用精确轨道和钟差数据进行单点定位，无需基站支持，可以实现广域范围内的定位，并且具备厘米级精度。PPP的优势在于不需要建立昂贵的基站网络，适用于需要长时间连续定位的场景，例如无人机巡航、海洋船只导航等。但PPP技术的不足之处在于其收敛时间较长，通常需要15分钟甚至更长时间才能达到稳定精度，且PPP在实时性方面的表现不如RTK，因此在智能驾驶中的应用相对有限。

PPP-RTK是一种将PPP和RTK两种技术结合的混合定位方案。其优势在于通过全球基站网络提供的卫星轨道数据实现广域覆盖，再结合区域基站的差分信号校正误差，使得车辆可以在城市道路或信号复杂的场景中实现高精度、实时的定位。PPP-RTK不仅解决了RTK受限于信号覆盖的不足，还通过区域性基站校正了卫星轨道误差和环境误差，从而提供了更加精准且稳定的定位服务。未来，随着低轨卫星的普及和北斗系统的完善，PPP-RTK将在智能驾驶和智慧交通等领域中展现更大的应用潜力，成为城市NOA等智能驾驶应用的主要定位方案。

3.2 GNSS+IMU深耦合卫惯组合技术的应用

GNSS（全球导航卫星系统）与IMU（惯性测量单元）深耦合的卫惯组合技术是目前车载高精度定位系统中最常用的一种方案，广泛应用于智能驾驶的定位和导航系统中。GNSS模块负责提供车辆的绝对位置信息，但在高楼林立的城市区域，卫星信号可能会受到遮挡，从而影响车辆的定位精度。IMU模块则通过加速度传感器和陀螺仪等元件测量车辆的加速度和角速度，实现高频率的位置和姿态更新，即便在GNSS信号不稳定或暂时丢失的情况下，IMU也可以提供短期内的位置信息补偿，从而实现无缝的导航体验。

卫惯组合导航形成安全冗余

GNSS和IMU的深度耦合是通过多层次数据融合实现的。简单的组合导航方案可以分为松耦合和紧耦合，而深耦合技术则是将GNSS信号处理和IMU数据采集高度集成，使其在复杂城市环境中也能够保持高精度的定位效果。在智能驾驶中，深耦合卫惯组合系统可以有效提高系统在信号波动、遮挡等不利环境中的适应性。例如，当车辆在隧道、高架桥下方或多层停车场等信号遮挡较多的场景中行驶时，深耦合系统通过IMU提供的惯性导航信息，可以确保车辆的定位数据保持连续性，从而避免因定位失准导致的驾驶失误。

卫惯组合系统的另一优势在于，它能够对传感器数据进行融合，通过多源信息的冗余设计，为智能驾驶系统提供更高的定位精度和数据可靠性。未来，随着深耦合算法的进一步优化和硬件性能的提升，卫惯组合技术将在高阶智能驾驶应用中进一步扩大其市场应用，为智能驾驶提供更安全可靠的导航支撑。

高精度定位的产业格局及主要企业

4.1 高精度定位产业链的结构及核心环节

高精度定位产业链包含了从上游的元器件供应、中游的系统方案集成、到下游的应用行业三个主要环节。产业链上游主要由芯片、天线、传感器等核心元器件供应商构成，提供高精度定位所需的基础硬件；中游则由系统方案集成商和定位服务提供商组成，这一环节是将硬件、软件和服务进行整合，形成具备广泛应用能力的高精度定位系统和服务平台；而下游则涵盖了智能驾驶、智慧交通、无人系统等多个行业应用，推动高精度定位技术在实际市场中的规模化落地。

在高精度定位产业链中，元器件供应商如天线和传感器生产商是技术发展的重要支撑，尤其是GNSS接收器和IMU传感器等核心器件的生产水平直接影响了整个定位系统的精度和稳定性。中游的系统方案集成商主要负责将硬件与定位算法、数据服务相结合，开发高精度定位解决方案。目前国内外的高精度定位服务提供商多通过云端服务平台和增强基站网络，向用户提供基于订阅模式的定位服务。随着高精度定位需求的增加，中游企业逐渐向上游和下游延伸产业链条，以实现软硬件一体化解决方案的开发和应用。

4.2 代表性企业及其市场布局

北斗星通：北斗星通是中国高精度定位行业的龙头企业之一，作为国内最早进入高精度导航芯片和GNSS模块领域的企业之一，北斗星通在智能驾驶和物联网市场中占有重要地位。该公司的高精度导航芯片和定位模组已在汽车前装市场占据超过50%的份额，并广泛应用于智能驾驶领域。北斗星通的核心优势在于其芯片设计能力和定位技术创新，通过与NVIDIA等国际科技公司的合作，北斗星通正在加速高精度定位产品的海外市场布局，推动其定位芯片、数据服务在智能驾驶中的广泛应用。

中海达：中海达是一家高精度定位全产业链企业，主要业务涵盖了从核心元器件、定位算法到终端应用的全套解决方案。中海达的市场定位不仅局限于高精度定位设备，还覆盖了自动驾驶、智慧城市等领域，为智能驾驶车辆提供高精度的定位与导航服务。该公司与国内知名车企上汽集团合作开发了基于北斗的车载高精度定位系统，并为多个城市的智慧交通项目提供了高精度定位支持。中海达的多元化市场布局和技术集成能力，极大地提升了其在高精度定位领域的市场竞争力。

此外，还有其他国内厂商如海格通信、华测导航等，也在不断扩展其在高精度定位行业的业务领域。海格通信作为特种无线通信设备的领先厂商，正在积极进军北斗导航产业链，推出了从芯片到整机的多种定位产品。华测导航则通过构建高精度定位芯片平台和全球星地一体的增强网络服务，成为了国内高精度定位领域的重要参与者。总体而言，国内高精度定位产业正处于快速发展的阶段，市场需求的增长和政策的推动将进一步强化行业龙头企业的竞争力。

国内导航设备终端主要企业部分业务及产品对比

结论

高精度定位作为智能驾驶系统的核心支撑技术之一，已在近年内实现了从高速公路到城市道路的应用拓展。高精度定位不仅为智能驾驶车辆提供了精确的路径规划和实时决策支撑，也为智慧交通和公共安全等领域提供了重要的数据支持。未来，随着高精度定位技术的不断发展，PPP-RTK、GNSS+IMU等定位技术的优化升级，以及5G、低轨卫星等新兴通信技术的加持，高精度定位将在智慧交通、公共安全、个人智能穿戴等多个领域展现出更广阔的应用前景。总之，高精度定位技术在政策扶持、市场需求和技术创新的多重推动下，必将成为智慧城市和智能驾驶不可或缺的重要支柱。

#端到端自动驾驶通用感知架构的前世今生

研究背景及现状

CVPR2023 best paper(商汤上海AI lab)：UniAD

来源：星球内部资料，文末扫码领取！

首先从端到端自动驾驶说起。端到端自动驾驶是目前自动驾驶领域最受关注的方向之一。UniAD提出一个端到端的感知决策一体框架，融合了多任务联合学习的新范式，使得进行更有效的信息交换，协调感知预测决策，以进一步提升路径规划能力。首次将感知、预测、规划等三大类主任务、六小类子任务（目标检测、目标跟踪、场景建图、轨迹预测、栅格预测和路径规划）整合到统一的端到端网络框架下，实现了全栈关键任务驾驶通用模型。在 nuScenes 真实场景数据集下，所有任务均达到领域最佳性能（State-of-the-art），尤其是预测和规划效果远超之前最好方案。

传统的自动驾驶系统通常会采用级联式的架构，在模块与模块之间通常传递的是结构化信息，同时在系统内存在着海量人工设计的复杂规则。这使得整体的自动驾驶系统复杂性高、难以联合优化以及迭代周期比较长。而端到端的设计思路则带来了全新的可能性。在端到端架构中，首先各个主要的模块都是基于神经网络的形式设计；其次模块间也不再只是传递结构化信息，而是同时传递稀疏实例特征表示，这使得从感知到规控的整体系统可以进行联合优化；最终的planning模块也能从更加靠前的阶段获得更丰富的信息。但这里会带来一个问题，就是在端到端自动驾驶系统中，我们是否需要显式的去做感知的模块？目前也存在着一些方法是不产生中间结果，可以直接通过图像输入，直接输出控制信号的彻底端到端技术路线。这种技术路线会存在彻底黑盒、解释性差的问题。而从自动驾驶产品安全性的角度来看，把每个模块都网络化并串联在一起的技术路线，会更加可靠可行，也就是UniAD技术路线。因此，还是非常有必要去做显式的感知结果的输出。在这样的架构设计下，主要讨论的问题是：对于一个面向落地的端到端纯视觉驾驶系统，我们需要怎么样的通用的感知后端呢？我个人认为主要包括这四个方面：1、需要具备强大的感知性能，能够输出高质量的实例化特征；2、需要高效的融合多视角+时序的视觉信息，速度快，且对于板端芯片比较友好；3、感知的范围方面能够具备All in One的能力，不需要多个模型去补充不同范围的视野；4、需要有可靠多任务能力，能够适配并良好的支持动态、静态，像HDMap的高精地图重建等各种任务。在更早期的阶段，自动驾驶系统中通常会采用后融合感知系统，如这张图所示。对于不同视角图像，我们会分别检测里面的物体。这样显而易见会带来两个问题：一个是摄像头之间有重叠的区域，一个目标可能会被检测到两次；第二就是有一些很大的目标，比如大卡车，它会跨多摄像头，使得每个视角中都没有办法完整的检测到整体的检测框。为了解决这两个问题，这类方法就需要有一个目标级的多传感器融合、目标级的时序融合和滤波模块，这样就构成了我们常说的后融合感知系统。

来源：星球内部资料，文末扫码领取！

后融合感知系统会有几个明显的不足：1、融合模块，仅仅收到了结构化的感知结果，信息不够充足；2、需要有一些前提假设，比如说感知误差分布、目标运动模型，需要很多超参数进行调优，一定程度上限制了整个感知系统的上限；3、需要维护一套独立于模型以外的融合模块，这使得系统的复杂度偏高。因此，这两年业界更多地在推行的是中融合方案，即先对不同视角的图像提取特征，然后在一个统一的特征空间下融合这些特征，最后再产出感知结果。这个坐标系，一般指自车的EGO 3D坐标系。这张图演示的是相关方法的演进。

这其中大部分都是基于BEV的方法，上图就是BEV-based相关方法的相关演进, 用某种方式将图像视角特征转到BEV特征空间，也就是一个高度方向拍扁的自车3D坐标系空间下，再用一个检测的Head实现目标检测。BEV这张图的尺寸通常比较大，比如一般常见的论文里面会用128×128 size，但在实际中，我们甚至会用两倍大小的BEV特征图。从图像特征空间向BEV层空间转换过程，是一个非常密集的计算过程。有很多的方法也是在优化这部分的速度，比如说Fast-BEV 、BEVPoolv2 等。而另外一类方法没有提取显式的BEV特征，比如 PETR 系列工作和我们的Sparse4D 系列工作。它的关键思想就是构造3D空间下Query，用3D空间的Query去获取不同视角的特征，去聚合不同视角的特征，再传出检测的结果。下面先介绍一下比较有代表性的BEV和稀疏的方法。

BEV-based方法

IPM 方法

IPM是应用广泛落地最多的自动驾驶视觉感知方案，多用于parking场景。这类方法中，我们先会设定3D空间中的一系列点。比如，将BEV空间中地面的某个点，根据相机内外参投影到多视角图像上，再去采样对应的特征作为3D空间点的特征表示。个人认为是一个最简单快速的BEV算法。它的做法是将每个BEV Grid看作所有物体在地面上，假设所有物体的高度为1，即Z轴的值都是1，等价于地平面假设，把BEV Grid的地面道路上的点投影到图像上去，获得BEV Grid的特征。可以看出，IPM依赖的一个前提是所有物体都在地面高度上，但实际场景中的高于地面的物体其实是不符合假设的，会存在很多的特征畸变。如果大家开车的时候会看360影像，会对这一点非常熟悉。因为360影像其实就是比较小范围的基于IPM的BEV。那么如何去优化IPM的效果，有很多改进方法。像去年非常有影响力的工作BEVFormer，我认为在某种程度上可以看作是一种IPM的改进。本质上IPM四张图拼接的过程应该类似与BEV-Det多v拼接的过程，只是一种是离线拼接，一种是隐式的基于learning的方式拼接特征进行feature extract learning。

LSS 方法

上图所示为LSS变化过程，也是BEV方法中一种重要的2d转3d特征的方式，BEV-Det是利用LSS进行BEV视觉感知的通用框架，也是应用最为广泛的自动驾驶视觉感知落地方案。LSS将2D 图像上的特征向3D 空间投影。最早的工作是Lift，Splat，Shoot。它的核心思想，是将图像上的每个点看作是一条射线。这条射线在3D空间中具体位置可以根据相机内外参获得，在这条射线上会去采样很多点，对于每个点去估计一个深度的置信度（即这个深度位置有物体的概率）。射线整体上的深度置信度，通过softmax可以规划为1。我们将图像上这个点的特征乘上射线上每个点的置信度，就可以获得射线上每个点的特征。基于这个思想，BEVDet 进一步实现了BEVPool算子，能够比较高效地实现升维后的视锥多视角图像特征向BEV 特征的快速转换，获得了很好的效果。在BEVDet基础上进一步发展的BEVDet4D算法，引入了时序能力。具体做法比较简单，就是把上一帧的图像特征和单点帧图像特征拼接在一起，再过一个卷积进行融合，这就是我们称之为一种两帧短时序的时序融合方式。它能够比较简单地去获得视频时序流动的运动信息。通过刚才的介绍可以知道，BEVDet 特征投影方式效果是十分依赖于视锥深度估计的效果，那么如何去提升这个特征点投影效果呢？我们就需要获得更精准的深度估计。

来源：星球内部资料，文末扫码领取！

上图是对LSS深度估计不准问题提出的解决方案，LSS方案得到的BEV-feature只能生成离散且稀疏的BEV表示。一个比较直观的做法就是给深度估计加显式的监督，也就是BEVDepth的做法。BEVDepth的监督是来自于稀疏Lidar 点云。那么再进一步如何再去提升深度估计效果呢？BEVStereo这个方法，就是将时序上的前后帧看作是一组双目图像，引入了双目深度估计中的思想去进一步提升深度估计的效果。后续的像SOLOFusion工作，就更进一步将多视角的几何的深度估计和长时序的策略融合结合在一起。它核心就包括两个模块，一个是高分辨率短时序模块，主要是基于前后帧的多视角几何的思想，去获得更加精确的深度估计，并初步获得BEV特征；再用BEV空间下的低分辨率长时序模块去融合，最多达到16帧的较长时序的BEV特征，这样它就获得了一个很好的效果。

上图是SOLOFusin的基本网络时序融合框架，随着帧数越来越多，时序方法也出现了低效率问题。以SOLOFusion为例子，在每帧的前向过程中都需要融合过去16帧的特征。这样做的问题是：一方面整体网络中存在着很多的冗余计算，另一方面系统中需要缓存非常多的历史BEV特征。又因为BEV特征图通常比较大，这样的做法在系统带宽比较低的车端，自动驾驶系统是很难使用的。今年，VideoBEV提出了一种更加简单的Recurrent时序工作方式。

来源：星球内部资料，文末扫码领取！

简单来说就是将当前帧提取的BEV特征和上一帧融合后的BEV特征进行融合，再将融合后的BEV特征传递到下一帧。这种有点类似于RNN的形式，可以让帧间传递的融合BEV特征，理论上能够保留较长时序的特征信息。当然这种循环神经结构也会存在着很强的遗忘特性，因此实际上传递的长时序信息是比较有限的。VideoBEV这种形式对于实际车端使用是比较友好的，因为它的计算量始终是恒定的，指标提升也非常明显。这张实验对比图是来自于VideoBEV。

这张图片展示了基于Lift-Splat 2D到3D的BEV生成方式的技术发展路线。从多视角的特征融合，到时序的短时序融合，再到点云深度监督，再到多视角几何的估计，再到SOLOFusion长时序，再到VideoBEV Recurrent时序的形式，一步步的把这个方法框架的效果提升，使它更加适合真实场景的使用。另外一条与2D到3D路线相对的，叫做3D到2D的特征投影技术路线（reverse-project road）。

反向投影方法

其实IPM方法也是一种3D到2D反向投影的方式，只是这种方式区别于接下来要讲的基于隐式深度学习的投影。

BEVFormer方案主要包括两个主要的模块：一个Spatial Attention，另一个是Temporal Attention。我们先看Spatial Attention。它的做法是对于BEV Grid上的每个点视为Query，每个Query会在对应的grid的高度方向上划分多个voxel，每个voxel里面去用Deformable Attention采样多点，然后全部融合在一起去作为Query也就是 BEV Grid的特征。如果说刚刚的IPM是一个BEV Grid采样一个点，BEVFormer就是一个Grid采样了非常多的点。远远更加充分的点采样和特征融合，使得BEVFormer获得了比IPM好很多的效果。时序方面，BEVFormer用的也是一个两帧的短时序融合方式，采用的也是Deformable Attention的形式进行融合。BEV类的方法可以算是当前多视角3D感知的一个主流路线，但是在实践中BEV方法也存在很多的问题。我觉得各类问题的根源在于，需要感知的目标在三维空间中通常是十分稀疏的，存在着非常多的无效区域。而从图像空间到BEV空间转换，是一个稠密特征到稠密特征的重新排列组合。它计算量非常大，而且计算量与图像尺寸以及BEV的图像尺寸是成正相关的，这使得BEV模型的感知范围、感知精度以及计算效率其实是非常难平衡的。在我们常用的nuScenes数据集中，一般感知范围会设置为长宽 [-50m, +50m] 的方形区域，但在实际场景中，我们通常会需要达到单向100米，甚至200米的感知距离。如果说我们想要保持BEV Grid的分辨率不变，那么就需要去增加BEV特征图的尺寸，这会使得端上的计算负担和带宽负担都非常重。如果要保持BEV特征图的尺寸不变，就需要更加粗粒度的BEV Grid，那么它的感知精度就会下降。因此在车端有限的算力以及带宽条件下，BEV方案的一个常见难点是比较难以实现远距离感知与高分辨率感知的平衡。这个问题怎么解决？业界一个比较常见的做法是补充一个或者若干个前视或者前视窄角模型，比如2D模型，专门去做特别远距离的感知。但是这又带来一个问题，如果有好几个3D检测的感知来源，就还得再去做后融合，这使得模型又变得复杂起来了，没有真正消除掉后融合，也很难真正去做到端到端。另外一个问题是BEV空间是一个压缩高度信息的三维空间，这使得它对于一些高度方向上敏感的任务比较难完成。一类任务是标志牌、红绿灯检测。好在标志灯、标志牌、红绿灯检测可以通过2D任务来解决。另外一类，比如异形车，它不同高度，形状不一样，用拍扁的方式，很多时候不一定能够很好地解决。那么，与这种生成密集特征相对应的就是我们称之为稀疏感知方法，比较早的有代表性的就是DETR3D。

它的稀疏体现在，并没有像BEV一样对BEV 3D空间中所有点都去转换特征，而是只对我们感兴趣的目标进行了3D特征的转换和融合，主要流程包括以下几步：

和大部分方法一样，也是提取多视角的特征；
初始化Query，用特征编码方式初始化若干的Object Queries；
将Query特征通过MLP映射到3D空间的参考点坐标，将这个点通过相机内外参投影到图像平面上，并去采样多尺度特征，融合后采样特征来作为Query的特征更新；
通过更新后的特征，迭代式地去更新Query的信息，并去预测目标框信息；最后用二分匹配方式去跟真值进行关联，再进行训练。

另外一个比较有代表性的方法是PETR系列。

来源：星球内部资料，文末扫码领取！

PETR系列方法与DETR3D的一个最大区别在于：PETR里面Query特征是通过Cross Attention直接和所有的图像特征进行交互，而非类似Deformable Attention这种基于采样的方式与图像中的特征进行稀疏性的交互。在PETR这种形式下，关键的问题在于：如何将图像特征跟3D的信息关联上？PETR的方法是将相机的视锥射线基于内外参投影到3D的自车坐标系下，基于这些点的坐标进行编码，得到3D的位置编码，然后加到图像特征上去做。在此基础上，PETR-V2进一步引入了两帧形式的时序融合，和一个更加优秀的3D的位置编码策略。

PETR-V2更进一步，近期StreamPETR方法，类似于VideoBEV引入了Recurrent的时序融合策略。

但不同的点是采用Recurrent时序融合策略是实例级别的融合。具体做法是把t-1帧获得的检测结果作为Query，通过一定的隐式的运动变换后，把它推到第t帧作为一部分的输入Query。来自上一帧的Query和这一帧新初始化的Query，一起进入Decoder 模型，得到新一帧的感知结果。我们的Sparse4D-V2版本方法，也采用了一个类似的实例级别的Recurrent时序融合策略，后面我会介绍两者之间的设计上的差异。在上面的几个方法中， DETR3D是稀疏Query加上稀疏的特征交互；PETR则是稀疏的Query加上密集的特征交互；PETR-V2 和StreamPETR 则分别引入了两帧的时序和Recurrent的时序形式。

PETR系列方法效果非常好，但可能存在一个问题是稠密的特征交互，特别是在板端算力有限的情况下，对于比较高分辨率的图像特征输入不够友好，耗时会随着输入图像分辨率的增加而非常快地增长。我们这一系列研究出发点是，希望实现一个高性能、高效率的长时序纯稀疏融合感知算法。这条技术路线比较代表性的方法是刚刚提到DETR3D算法。但是，从开源数据及指标来看，DETR3D的性能距离其他稠密类型的算法有比较大的差距。为了让纯稀疏感知或者DETR3D感知再次把性能达到这种算法水平，这两年相继提出了Sparse4D以及它的改进版本Sparse4D-V2，从Query的构建方式、特征采样方式、特征融合方式以及时序融合方式等多方面提升了模型效果。当前 Sparse4D-V2 在nuScenes Detection 3D的榜单上也达到了比较SOTA的效果，超越了像SOLOFusion、BEVFormer-V2和StreamPETR在内的一些方法，而且在推理效率上也有明显的优势。接下来我主要会介绍Sparse4D和Sparse4D-V2方案的一些细节的实践。

前向-反向投影结合的方法

视觉转换模块（VTM），主要作用在视图转换过程，将多视图特征转换为BEV特征表示，是基于视觉的 BEV 感知系统的关键部件。目前，VTM 存在两种主流的方法模式：前向投影和反向投影。前向投影以 NVIDIA 提出的 BEV 感知算法 LSS（Lift, Splat, Shoot）为代表，在不借助后处理操作，直接产生稀疏的 BEV 特征。反向投影以 BEVFormer 为例，投影匹配时易于产生假阳性 BEV 特征，主要由于缺少统一的深度信息。

如上图所示，前向投影是将相机特征投射到BEV平面上最为直观的方法，其中涉及图像平面上每个像素深度值的估计，并且使用相机标定参数来确定每个像素在3D空间中的对应关系。称这一过程为前向投影（IPM、BEVFormer）。

其中2D像素主动投影，而3D空间被动接收来自图像空间的特征。这一过程中，预测每个像素深度的准确性，是获得高质量BEV特征的关键。为了解决预测像素深度这一难题，NVIDIA提出的BEV感知算法LSS（Lift, Splat, Shoot）首先使用深度分布来建模每个像素的不确定性，但LSS有一点不足：它只能生成离散且稀疏的BEV表示。

BEV特征的密度随着距离变大而减小。当在nuScenes数据集上使用LSS的默认配置，即为同通过将图像“抬升（Lift）”为3D点云，并将所有截头锥体“拍扁（splats）”到参考平面上时，那么在投射过程中，仅有50%的3D网格可以接收到有效的图像特征。

在动机方面，反向投影和前向投影完全相悖。在反向投影机制之下，3D空间的点占据主动。例如，BEVFormer会预先设定要填充的3D空间坐标，然后将这些3D点投射回2D图像上，具体如图1中间所示。因此，每个预设定的3D空间位置都可以获得与之对应的图像特征。反向投影获得的BEV表示特征，会比LSS稠密得多，因为每个BEV网格都填充了与之对应的图像特征。

然而，反向投影的缺陷也尤为明显，如图3所示：虽然获得了稠密的BEV特征表示，然而因为遮挡和深度误匹配，会产生很多错误的3D到2D空间的对应关系，这一错误匹配造成的主要原因是投影过程中的深度信息的丢失。近来，前向投影领域得到进一步发展，借助更多的深度监督信息辅助提高深度分布的准确性，这有助于3D感知。

为解决前向投影中的稀疏BEV特征表示问题，我们使用反向投影提炼前向投影中的稀疏区域。针对反向投影由于缺失深度信息的指导，而产生假阳性特征的问题，FB-BEV提出一个深度感知的反向投影，借助深度一致性，衡量每个投影关系的质量，来抑制假阳性特征。

来源：星球内部资料，文末扫码领取！

何为深度一致性？是通过一个3D点和与之对应的2D投影点的深度分布距离来确定的，即为深度一致性。基于这一深度感知的方法，不匹配的反向投影会被给定一个较低的权重，从而减少由于假阳性BEV特征导致的推理。

FB-BEV主要包含三个关键模块：

i. 带有前向投影的视图转换模块F-VTM

ii. 前景区域推荐网络FRPN

iii. 带有深度感知的反向投影视图转换模块B-VTM

长时序稀疏方法

首先，我们再去回顾一下DETR3D上面存在的问题。

作为一个比较早期的算法，DETR3D的设计比较简单，存在几个问题。第一点是它的每个Query只对应一个3D参考点，不能够非常有效的去采样目标特征，特别是对于比较大的目标以及一些跨视角目标，可能就投到一个点，但不能把这个目标都覆盖到；第二点是Query解码到3D参考点的形式，并不能非常有效地定位ROI区域，会存在退化解，多模式的问题。这个问题其实在2D的DETR改进方法里面有很多讨论，类似于DAB-DETR也讨论了Query到参考点解码形式的存在问题；第三点是DETR3D里面没有引入时序信息融合。在Sparse4D的第一版本中，我们主要通过Instance的构建方式，特征采用、特征融合和时序融合等方面去对DETR3D进行了改进。我们在改进过程中学习了非常多2D检测领域DETR改进的经验。

首先，最大区别是sparse4D重新引入了Anchor的使用。对于待感知的目标我们定义为Instance，每个Instance会由两个部分构成：第一部分是Instance的 Feature。它在Decoder中会不断由来自于图像特征的采样特征所更新；第二个部分3D Anchor 是目标结构化的状态信息，我们会显式地把Anchor的参数作为Anchor的信息，它会包括很多具体的值，包括目标框的位置、长宽高、yaw角、速度信息，我们都会作为Anchor的一部分。在Sparse4D-V1里面，Anchor本身我们通过K-Means算法来进行初始化的，同时在网络中基于一个 MLP网络来对Anchor的结构化信息进行高维空间映射，得到Anchor Embed的概念，并与前面说到可学习的Instance feature相加得到更加综合的特征表示。基于以上定义，我们可以初始化一系列的Instance，经过每一层Decoder都会对Instance进行调整，包括Instance特征的更新和Anchor box的refine，对于每层预测的bounding box中，Sparse4D同样会通过二分匹配的方式与真值进行匹配，并计算损失函数。在Sparse4D中，最重要的一个模块是Deformable 4D Aggregation可并行的4D特征聚合模块。这个模块主要负责Instance和时序图像特征之间交互。

如图所示，主要包括三个步骤：第一点是4D关键点生成。基于每个实例的3D Anchor信息，首先可以生成一系列的3D关键点，分为固定的关键点和可学习的关键点。将固定的关键点设置为Anchor box的每个面的中心点，以及其立体的中心点；可学习的关键点，通过实例的特征接入一层全链接的MLP网络来得到。在 Sparse4D-V1的版本中，sparse4D采用了7个固定关键点 + 6个可学习关键点的配置，一共13个关键点。然后，sparse4D会结合每个实例自身的速度信息，以及自车的速度信息，对这些3D关键点的位置进行时序的运动补偿，获得它们在每一个历史帧中的位置，相当于把当前帧的一系列关键点投影到了每一个历史帧上。那么，结合当前帧和历史帧的3D关键点，就获得了每个实例的4D的关键点。下一步是4D特征采样。在获得每个Instance的当前帧和历史帧这个关键点之后，我们会根据内外参将这些点投影到对应的多视角图像上去，进行双线性的插值采样，从而得到多关键点、多时间戳、多尺度和多视角的特征表示。这其实是一个比较大的特征表示。得到多层级特征表示之后，做层次化的特征融合，sparse4D分为了三层：首先，对每个关键点去融合在不同特征尺度和视角上投影特征，采用了加权求和的形式。权重系数是通过将实例特征输入到全连接网络中去预测到的，是一种动态加权的方式；第二点是做时序特征的融合，sparse4D采用的是一个简单的，类似于RNN的网络来做融合；最后一点会用求和的方式将一个实例不同关键点特征加在一起，作为一个融合。这页展示的是 Sparse4D中的Ablation Study。

左上角是我们在刚刚的4D关键点中做运动补偿的必要性，对自车运动以及目标实例的运动做运动补偿，对于网络的效果都是有明显提升，特别是对于速度估计的提升是非常的巨大的。其次，我们的融合策略比起直接简单的去加权多尺度的多级别特征，效果要好一些。在Sparse4D中的时序方面，我们发现跟SOLOFusion类似的结论，时序增加的越多，效果就越好，但后面的提升可能会逐步收敛。效率方面，Sparse4D单帧的版本的速度是略慢于DETR3D，这是一个预期内的情况，因为采样点变得更多了，而且有很多融合的模块。

来源：星球内部资料，文末扫码领取！

但在多帧的情况下，Sparse4D的速度下降了很多，主要是因为多帧推理的时候，在Sparse4D框架里面类似于SOLOFusion，对每一个历史帧的特征都要进行一次采样融合。在Deformable 4D Aggregation这个模块中，由于要采用多视角、多尺度、多关键点，再按多帧特征去融合，中间有很多的读写操作，效率也不是很理想。此外，Sparse4D帧间传递的是比较重的多视角的图像特征，缺乏实例间的帧间传递。这些点就使得Sparse4D特别是在多帧的情况下， FPS下降比较明显。比起一些对比的方法，它在速度和显式量上其实并没有很大的优势，并没有很好体现出稀疏框架的优点。同时Sparse4D时序采样的一个问题是：它的速度采用的是实例在当前时间节点估计的速度，而且我们用了常速度的运动假设，对于变速度的目标历史帧投影很可能是不准的。那么，针对Sparse4D-V1里面存在的这些问题，我们做了很多改进。

总体来说，可以归为两方面：第一点是我们引入了Recurrent的实例级别的时序方案；第二点是我们对网络中的非常多的模块进行了速度和效率地优化，使得整体的FPS和显式占用都得到了极大优化。具体而言，如上面这张图所示，我们会把上一帧的Instance传到下一帧作为Query的输入。接下来介绍一下具体的框架。

来源：星球内部资料，文末扫码领取！

这张图展示了Sparse4D-V2的整体框架图，Encoder部分与V1版本一致，这边就不展开。Decoder 部分为了非时序层和时序层。其中非时序层有1层，时序层有5层。非时序层全部是新初始化的Instance作为输入，输出一部分高置信度的Instance到时序层。时序层的Instance除了来自于单帧层的输出以外，大部分来自于历史帧，也就是上一帧。我们的做法是将历史帧的Instance投影到当前帧，在这个过程中保持实例的特征是不变的，但Anchor box会通过自车运动和目标速度投影到当前帧，Anchor embed通过对投影后的Anchor box进行编码得到。可以看出非时序帧的作用主要是先简单检测一下场景中的目标，去做一个比较好的新出现的目标的初始化。其实，大家如果熟悉MOTR以及MUTR3D ，会觉得这个框架跟MOTR有点相似，都有历史帧的实例进入当前这一帧，也有当前帧新的实例一起进行检测。主要区别在于，Sparse4D-V2中，目前在真值关联部分没有区分历史帧和新Instance的匹配。因为在MOTR里面，是有一套比较独特的匹配策略，它的历史帧已经贯穿目标，会继续跟历史帧关联。我们这边没有做针对tracking的关联策略的调整，还是全部放在一起进行一个关联形式。Sparse4D-V2和StreamPETR都采用了实例级别的Query的时序框架，两者之间有什么差别？主要有几点：第一点，是Instance表示方式。在PETR里面Query Instance 采用的是将均匀分布在3D 空间中的可学习 Anchor point，用MLP编码成Query特征。Sparse4D中则是更加显式的做法，会把Instance分离成Feature和3D Anchor，PETR的Instance的形式就更加隐式一些了。我们的观点是特征跟Anchor box的分离的表示方式，在稀疏3D检测任务中可能是更加有效、简洁的方式，也更加易于训练更新检测结果。第二点，我们将历史帧投影到当前帧这个时序转换的方式，其实是跟前面刚刚说到的Instance的表示方式相对应的。在StreamPETR中，采用了隐式的Query时序特征表示，既把目标的速度、自车的速度、时间戳都编码成特征，然后再和每个Query的特征做adaptive的normalization来进行隐式的更新。Sparse4D-V2 如刚刚说的是一种非常显式的时序转换方式，直接把Instance基于运动信息的Anchor box投影到当前帧，特征是保持不变的，因为希望这个特征更多的保留它的一些语义信息。第三点，StreamPETR和Sparse4D-V2中历史帧的数量不同，从PETR里面会保留多帧的信息，再去那一帧做Attention。Sparse4D-V2只cache了一帧，StreamPETR也可以只cache一帧，但是效果会略有下降。在实际的业务实践中，比较少的cache历史帧有助于减少端上的带宽占用，进一步提升系统整体的性能。此外，在Sparse4D-V2中一个比较大的改进是，我们还对Deformable Aggregation模块进行了底层的分析和优化，让其并行计算效率显著提升，显存占用大幅降低。

来源：星球内部资料，文末扫码领取！

左上图展示的是Deformable Attention基本的计算流程，在原始的流程中我们会先采样得到多关键点、多视角、多尺度的中间特征，把这个特征和group weight进行融合，得到融合后的特征。在这个过程中，需要对显存进行很多次的访问和读写操作，降低了推理速度，而且中间的特征尺度比较大，有好几个维度，使得显存占用量会显著增加，且使得反向传播过程中的显存消耗比较明显的提升。那么，为了提升op的计算效率，降低显式占用，我们将上述实现中的双线性特征插值采样和加权求和融合，合并在一起做了一个算子。就像右边这张图所示，我们称之为Efficient Deformable Aggregation(EDA)模块。这个模块关键在于将采样所有特征再融合的形式，变成了并行地边采样边融合的形式，它能够在关键点k的维度和特征的c维度上实现比较完全地并行化。每个线程或者每个cuda线程的计算复杂度仅与这个相机数量n和特征尺度s有关。此外，在大多数情况下，特别是在自动驾驶的多视角图像的情况下，3D空间中的一个点，一般最多就被投影到两个视图上，这使得我们可以进一步将计算的复杂度降低为2×s。EDA作为一种比较基础性的算子操作，可以适用于需要多图像和多尺度融合的各种应用。目前这个算子的实现，也已经在我们的官方代码库上开源了。我们在3090上对EDA模块进行了性能测试，可以看出来EDA对显存占用和推理速度都有一个比较明显的优化。在加入EDA模块之前，在这个配置下，它的推理FPS只能达到13.7FPS，但加入EDA之后就可以有50%的提升，到20FPS。而且整体的训练速度也降低了非常多。此外，我们还提了一个Ablation Study，在Sparse4D-V2上再次去检验了动态特征加权的有效性，可以看出它能够带来三个点的MVP的提升，还是比较有效的一种做法。这页展示了更多的关键设计的Ablation Study。

我们对比实验1和实验5可以看出，采用Recurrent Instance的形式来实现长时序融合，相比单帧的提升非常大，有将近10个点提升。对比实验4、实验5可以看出，在Sparse4D-V2中深度监督模块比较重要，能够比较明显降低Sparse4D-V2的收敛难度。如果去掉这个模块， V2版本的模型可能会出现一定的梯度崩溃的情况，使其指标有一定的降低。可能很多时候，在业务场景不具备深度监督条件，这时候也可以用一些其他的 head去辅助，比如FCOS Head、YoloX等去做辅助监督，都能够有效改善训练情况。实验2和实验3去做对比，可以看出我们刚刚提到的单帧层 + 时序层的组合，先用单帧层去初始化一些检测的Instance，它会比全部用未初始化的 Instance+时序Instance方式的效果好很多。实验3、实验5对比是展示了我们的另外一个小的改动，在特征聚合的模块里面加了相机参数编码，它也有比较可观的提升。此外就是实验1单帧模型，它在3090上推理速度是21FPS，实验5的推理速度是20.3FPS，基本上是保持一致的，它时序的速度稳定性还是非常好的。另外，我们也在nuScenes validation上面去更新一些参考方法，和一些比较SOTA的新的3D感知方法做了对比。

来源：星球内部资料，文末扫码领取！

可以看出，无论在低分辨率+ResNet50或者是高分率+ResNet101的配置下，Sparse4D-V2都获得一个比较好的效果，超过了像SOLOFusion、VideoBEV、StreamPETR等算法，当然也比较明显的超过了Sparse4D-V1版本，不过这个表格里面没有写 V1的效果。Sparse4D-V2在256×704的低分率下，速度要比StreamPETR慢，但是会快于LSS-Based，类似于BEVPoolv2。但当图像分辨率提升到512之后，Sparse4D-V2反而会快一些。这主要是因为在低分辨率下直接做Global Attention的代价会比较低，但随着特征图尺寸的上升，它的效率会比较明显下降。Sparse4D head部分的理论计算量和特征图尺寸是无关的，都是通过grid sample去实现特征采样，这也展示了稀疏算法的优势。实际设定中当图像分辨率从256×704提升到512×1408的时候，Sparse4D-V2 Decoder部分的耗时只会增加15%左右，但这是因为从一个比较高分辨率图像的特征上去采样特征，虽然说计算量是一样，但它会比低分辨率图像上的测量会慢一点，这跟特征的访问效率有关。另外，我们也在测试集上面去做了对比，由图可见，也获得了比较好的效果。

总的来说，对于Sparse4D-V2，我们的结论包括三方面：第一点是显式的稀疏实例的表示方式。把Instance表示为3D Anchor和特征结合，并不断地进行迭代更新，是一种比较简洁有效的方式。同时这种方式在时序框架里面，也很容易去做时序运动补偿。第二点是对于稀疏架构，它的特征采样和聚合的算子效率是非常重要的，如果是一个直接基于PyTorch实现算子，它的效率可能并没有那么高，并没有理论计算量那么高效。因此，我们就提出了针对多视角、多视图像的层级化的采样策略，也提出了一个非常高效率的算子。第三点是Recurrent的时序稀疏融合框架。它使得时序模型基本具备了与单帧模型相同的推理速度，且帧间占用的带宽非常少。这样轻量且有效的时序方案，是非常适合在一个真实的车端场景去处理多摄视频流的数据。这里还有没有写的一个结论是：Sparse4D-V2的时序框架，是非常容易去做端到端的跟踪。我们后面做了一个实验，发现将检测结果直接根据帧间的Instance对应关系，加上track id，不额外去添加一个tracker，比如一些移植的tracker，就能够得到非常好的跟踪效果。由此可以看出， Sparse4D-V2去做端到端跟踪的潜力是非常大的。这页还进一步展示了我们最新的一个实验的结果Sparse4D-V3，目前代码和报告还没有release。

在Sparse4D-V3中，进一步加入了一些新的特性，比如更大的backbone以及更优秀的训练策略，也实现了刚刚说的端到端的跟踪能力，获得了比较好的效果。这是前几天的一个比较新的实验结果。Offline版本的Sparse4D-V3到了0.719的NDS。Offline的版本是指在这个实验中用到的未来帧信息。正好聊一下这个问题，对于这种比较大Backbone的多视角感知模型，它的业务价值到底在什么地方？因为实际上在端上可以跑的模型，一般跑不了很大的Demo，比如说像刷榜大家会问到VIT-Large这种级别的Demo，它在业务场景下很难使用。因为端上的算力可能有限，可能只能用到ResNet34或者ResNet50这种小模型。那么，我们认为这种大模型的最大价值就是尽可能地追求它的指标上限，拿来作为云端真值系统的预刷模型，产生4D的真值。这些真值再拿去作为车端模型的训练。这种离线的真值系统里面一个比较重要的策略是我们要用到未来帧的图像，或者在后处理跟踪过程中，用未来帧信息去优化跟踪结果，目标是尽可能提升它的感应效果，以找到比较好的真值，作为真值系统的输入。

来源：星球内部资料，文末扫码领取！

如何在端到端自动驾驶系统中构建一个可靠可用的稀疏的通用感知后端？这是我们认为未来非常有价值的技术方向。因为只是把检测这个事情做稀疏化，其实并不够。一个真实的系统中，不止检测，还有Online Mapping、障碍物感知，还有freespace等各种各样的任务。我们想要彻底去做稀疏化，就需要把各个任务都做优化改进。这张图是最近我画的，分为5个部分，是一个我对于稀疏通用感知架构设想的框架。

第一个部分是图像特征的提取。左上角写了Foundation Model ，后续可以和Foundation Model的预训练的方式相结合，在图像特征提取上面得到更加强大的特征表示。第二部分是PV-based 感知。在图像上去做检测任务，或者一些深度估计任务的时候有很多作用。第一点是PV检测的结果，可以作为后续3D感知Query的初始化，这一点在BEVFormer-V2等几个最近的工作中都有采用。Sparse4D目前还没有用上这个策略，应该也会是一个比较有效的策略。第二点是PV的一些任务，包括深度的任务或检测任务，它也有助于图像特征的收敛，使得网络整体上训练得更好一些。第三点是认为基于图像PV特征的一些检测深度，乃至于分割结果，有助于挖掘一些场景中存在的通用障碍物。第三部分是3D感知部分，包括动态感知（也就是检测）、道路元素感知（也就是HD map的在线预测）以及通用障碍物感知。我还画了一个BEV的模块，这是因为可能有些任务需要在一个相对可能比较小的发展范围内去输出密集的结果。比如freespace就是要道路面上的密集的结果，它是没办法去做Instance表示的形式。所以，在这种框架里面还是不可避免的要加上一个BEV模块。但这里的BEV模块可以使用一个较小的size，更加轻量的设计。最右的两个模块指的是时序融合模块和实例语义关系模块。总的来说，在架构设计中出发点包括四个部分：

尽可能会去除后处理和规则融合模块，使得网络整体是端到端完全可微；
尽可能将大部分的任务稀疏实例化，实现更加高效的时序融合和存储；
整体架构是一个层次化的架构。从2D的检测结果级别，到3D的级别，到时序的级别，到语义关系的级别，整体有一个比较好的自洽性；
这个框架进一步加入预测模块和规控模块，就能够实现完整的端到端自动驾驶能力。

在这个框架里面，很多也是比较初步的设想，有很多地方都不太成熟，值得我们未来去探索。比如第一点，在稀疏范式下的视觉跟Lidar的中融合的结合。虽然我这张图片没有画Lidar，但是后面在类似Sparse4D的框架下做和Lidar的融合，也是一个很好的话题。因为Lidar的稀疏化是一个更加自然的事情。第二点和第三点是如何去做完全稀疏化的道路元素感知和通用障碍物感知，这两点我接下来会展开讲一下。第四点是实例化的语义逻辑建模，就是对Topology的建模。这个方向研究工作也比较多，像Tesla也在Workshop上面也展示过一些相关效果。最后一点也是最重要的一点，就是要做好稀疏感知架构在芯片端的效率优化。因为所有的模块都要建立在一个良好的芯片端的效率上，才能够成立。

对于具体的三个方向，首先想讨论一下稀疏高精地图建模。

早期的方法，比如HDMapNet，可以认为是模型和后处理相结合的多阶段方法。一般会先获得BEV特征，在BEV特征上做语义感知类任务，在后处理阶段对BEV特征做聚类等的一些后处理，得到结构化车道线。后续的MapTR V1&V2等方法就实现了端到端的HD map网络。它的特点是基于BEV特征直接预测结构化车道线，省去了后处理步骤，通常是会构造稀疏车道线实例的Query，以及一些车道线中关键控制点的Query，去和BEV层做Attention交互，去迭代修正车道线的结果。那么，进一步的形势可能是怎么样的呢？刚刚我们提到了MapTR是用稀疏的Query和BEV特征去交互，BEV特征又是来自于图像特征。理论上可以移除掉BEV这个特征的中间商，直接从图像特征出发，预测结构化车道线，我们认为这是一条完全可行的技术路线。另外一个方向是关于通用障碍物感知，这个问题可能就更加开放性一些。

来源：星球内部资料，文末扫码领取！

通用障碍物的感知是自动驾驶感知系统里面比较重要的一个问题。传统方法一般就是不断地扩充白名单，也就是需要增加感知的目标种类。当遇到一类新的corner case，就可能需要去标很多数据，扩充相关的系统。但这样的做法比较缺乏泛化能力，成本也比较高。去年Tesla AI DAY之后，Occupancy又成为了解决这类方法的一种可能性。通过识别空间中的通用的障碍物情况，来定位到一些此前没见过的障碍物在3D空间中的占用。但Occupancy在实际系统中存在一些问题，比如计算效率比较低，因为3D Occupancy的输出空间很大，有效的点也很稀疏，这使得下游的模块想去解析并使用Occupancy的时候，是非常困难的一件事情，要真正用起来并不是一件很容易的事情。那么，是否有一种可行的路线呢？我也不是很确定，是否能去做稀疏的Occupancy是一种我们的预期想法。即只对感兴趣的目标或区域去做Occupancy，而不把所有地方都给估计出来。因为在一个整体的驾驶场景中，很多区域的Occupancy并不太重要，比如左图所示，一些距离道路可能20米之外的树木的Occupancy，估计出来对于系统来说并没什么意义。如果只挖掘对自车驾驶重要的区域，就可以避免算力的浪费。最近有一篇非常相关的工作叫Occupancy DETR，我觉得就有点这个意思，就是把前景物体跟背景的Occupancy分开估计，前景是用一种类似于DETR的方式去做估计，对于前景物体Occupancy估计效果会提升非常多。我觉得这个方法是一个挺有趣的工作。对于通用障碍物感知的事情而言，另外一个可能比较困难或者说比较重要的事情是：如何从图像视角去挖掘出有可能是一个障碍物的 Queries，再用DETR去做估计。总的来说，前面介绍了很多端到端自动驾驶的想法，以及稀疏感知的一些内容。第一点，以端到端自动驾驶为目标，稀疏感知范式在稀疏实例化表示、计算效率、模型带宽和感知范围等方面，都存在优势，有比较大的潜力。第二点，对于稀疏感知，虽然我前面对比很多稀疏感知和BEV的形式，但其实它跟BEV并不是互斥的形式，在整体的模型框架中还需要根据具体的子任务目标和感知范围去合理地选择，至少可以共享图像特征提取器。第三点，是在稀疏感知的范式下，有很多任务和难题还有待解决。

reference：

FB-BEV: BEV Representation from Forward-Backward View Transformations
DETR->DETR3D->Sparse4D: 长时序稀疏3D目标检测进化之路：https://zhuanlan.zhihu.com/p/1442634734

#李斌内部讲话详解组织变革

要把蔚来的尊严挣回来

近期蔚来创始人、CEO李斌面向产研集群全体员工进行了一场内部讲话，详解“基本经营单元”的核心逻辑，动员团队尽快废除惯性，提升全员经营意识，交付经营目标。“我们要在有效的资源边界内，把钱花在刀刃上，把时间花在刀刃上，才有可能走出来。”李斌说。

“基本经营单元”（CBU，Cell Business Unit）是蔚来为提升组织效率、实现经营目标而设立的经营机制，将公司所有经营工作拆分为多个互不重叠的“基本经营单元”，每个单元都必须建立明确的ROI（投入产出比）指标和业绩奖惩规则。对应到实操层面，就是每个部门都要单独结算成本，计算不同项目上已花费、即将要花费的成本。

蔚来的时间表是在一季度大规模推行该制度，二季度全面落地施行，这意味着蔚来正在步入组织变革深水区。

“公司资源边界有限，我们就该非常清楚如何排序。过去更多凭感性判断，现在全部通过‘基本经营单元’这套机制来干。”在2024年三季度财报会上，李斌给外界的盈利时间是2026年。但在此次内部讲话上，李斌告诉全体产研部门员工需要摆脱过去的工作惯性，凭借新的工作机制全力以赴争取今年四季度实现单季度盈利。

李斌此前曾公开表示，2025年将是蔚来的4个大年：技术大年、产品大年、换电站建设大年和国际化大年。

产品端，4月起，蔚来将进入密集的产品发布周期，一直持续到年底，蔚来、乐道、firefly萤火虫三个品牌都有影响市场格局的车型陆续上市；
技术方面，满血版SkyOS·天枢整车全域操作系统、自研智能驾驶芯片、世界模型支撑的端到端城区智驾将陆续交付；
换电站建设将继续加速，冲刺县县通。截至3月16日，蔚来已建成换电站3166座、超充站2692座，还与长安、吉利、奇瑞等多家车企签署了战略合作协议；
未来还将进入25个国家和地区，海外市场将成为新的增长点。

“过去十年，我们在方向、愿景的部分干得不错，但是脚踏实地的行动部分，效率、成本控制、精益管理，很多人做得比我们好很多，我们要向优秀的同行学习。”李斌坦言。

业务目标的达成，需要建立在经营能力提升的基础上。2024年全年，李斌推动各核心业务梳理出15个公司级体系能力，并在此基础上推进落地基本经营单元机制，决心将局部散点的正面成功案例梳理成为整体经营机制，体系化落地到全公司各个层面，把事做对，做快，做挣钱。

在产研端，基本经营单元就是研发项目。李斌反思过去在研发项目上，项目投资计算不够严肃，“感性”导向，缺乏闭环机制，导致很多浪费。后续必须通过有效的机制，计算投资回报，精细化管理，并且责任落实到具体的人。“一定要把账搞清楚，把项目里每个人的时间、支出、产出都算清楚。”

李斌说，狠抓经营的本质，就是“低效的投资少做，高效的投资坚决做；低效的项目少干不干，高效的项目坚决干。”

李斌还以自己的错误决策为例进行反思，说曾经拍板过一些看上去正确的事情，但结果发现投资回报很低，整个决策链路没有机制避免这个浪费。“我本人确实需要提高经营意识，需要检讨。以后即使是我说要干，算不过来账，也不要干。”

日前，产研部门已经开始推行工时填报，来计算每个员工对于项目的贡献。对于机制落地过程当中的不适应，李斌强调这是团队精细化管理的基本线，不是高要求，“不愿意填工时，不愿意关联项目，只能说明一个情况，就是这个岗位不应该存在。”

同时，他也希望员工要尽快转变思想，“不要觉得以前没搞，现在突然搞了，蔚来不是以前那个蔚来了。其实，蔚来早就该是这样的蔚来。小鹏能改好，我们怎么就不能改好？”

2024年第一季度，小鹏的平均月销只有7274辆，经过近一年对产品定义、供应链渠道、营销等方面的优化，小鹏在今年1月销量达30350辆，重回造车新势力销冠。

以下是李斌当天讲话和回答员工提问的主要内容，略经编辑：

李斌内部讲话：“该听劝就必须听劝”

过去十年，我们在方向、愿景的部分干得不错，但是脚踏实地的行动部分，效率、成本控制、精益管理，很多人做得比我们好很多，我们要向优秀的同行学习。

2024年1月1日，我就写过全员信，讲要提高经营意识，“日拱一卒、久久为功”“结硬寨、打呆仗”。去年一年，我花了很多时间梳理出公司15个体系能力着手管理。管理不是简单地砍人砍钱，关键还是提高效率，提高价值创造，提高回报率。

结合这些思考，今年一季度陆续有管理动作落地。大逻辑上来讲，整个公司围绕业务的核心、成本的核心、费用投资的核心，去看把钱花在哪里，去抓投入产出和效率提升。

公司12个基本经营单元，花钱最多的，比如研发一年100多亿，市场一年几十亿，对应人员成本也很大。我们需要回答，这些投入到底产生什么效果，然后做到该省省、该花花。和2021年相比，今天公司资源边界肯定收窄，因为2022年到2024年这个周期我们没有实现经营目标。我们要在有效的资源边界内，把钱花在刀刃上，把时间花在刀刃上，才可能走出来。

不能再按原来的惯性。本质上抓经营就是低效的投资少做，高效的投资坚决做；低效的项目少干不干，高效的项目坚决干。这个大逻辑适用于所有事。

“基本经营单元”就是看钱花在哪。比如研发端的基本经营单元就是研发项目。各个项目投资汇总起来，就是所有研发费用；项目产出汇总，就是研发产出。在公司层面，把这类最基本的经营对象抽象出来，就是公司级的12个基本经营单元，这些各个维度的基本经营单元合并起来，就是公司的经营报表。公司盈利还是亏损，就是通过这些不同维度的基本经营单元汇总起来。

我们现在就是深入搞清每个基本经营单元这些花钱或挣钱的对象，围绕“基本经营单元”去提高效率，强化管理。

举例来说，目前我们有500个大大小小的研发项目，100多亿投资到各个研发项目上去，过去立项只算对外付费成本，内部人员投资计算很不严肃，都是框算，很难算清一个研发项目到底花多少钱。

另一个问题是项目闭环体系，最后有没有交付结果，谁对结果负责，查核检验在什么节点，闭环体系不严格。要把这些账都搞清楚，把项目里每个人的时间、工作、支出都算清楚账。

再拿用户来说，过去部分免费换电权益用户，把车卖掉之后，我们的权益没有回收。（注：2019年8月，蔚来推出了免费换电政策，该政策针对首发车主提供了不限次数的免费换电服务。2020 年底，新购车取消了终身免费换电政策。2023年年中，蔚来进一步调整该政策，将终身免费换电等权益从车价中剥离，推出灵活加电补能套餐，用户将付费进行换电。）

按照协议，蔚来没有义务再提供免费换电，但是因为中间管理不严，造成很多浪费。如果更加精细化地管理，一个一个用户去看，就能清楚哪些已经履约完毕，应该把权益收回。

其实有很多事情不做它也不会影响什么，有一些可能是惯性，以前好像有项目有预算就一直做。但可能市场都已经发生变化了，当时立项时的一些前提条件可能都变了，那大家还在惯性地在往前，我们是不是抽出来去做更高效的事情呢？这方面我自己也需要检讨，拍板过一些投资回报很低的事情。公司立项机制没有否决掉这种看起来很对实际上回报很低的项目，浪费了很多钱。我本人确实需要提高经营意识，需要检讨。以后即使是我说要干，算不过来账，也不要干。

如果不去算清投资回报，没人对结果负责，没有闭环体系，就会造成很多浪费。公司资源边界有限的情况下，一些低效的项目在浪费钱，一些需要加大投入的项目反而没投入足够的钱。

从去年到现在，这套管理范式越来越清晰。任何一个项目，都得有人对它的投资结果负责，都有一个唯一的人，要搞清楚这个项目最终能带来什么回报、什么价值创造，最终得有人交卷。每个CBU会对应一个投资主体，就是项目投资人，他去要找公司要投资，项目立下来，分到不同执行团队，就是经营主体，经营主体也有对应的经营负责人。每个环节都会闭环，公司很多细化流程都会受到影响。

如果没有严肃立项，就意味着确实不是高优先级，就不要做。如果立项要做，就得把你的贡献都说清楚。

成本方面，近期我们在研发端开始推进工时，这和打卡不同。工时要和项目关联，因为研发投入中最重头的就是人的费用，人的费用和事的费用大概是6: 4，软件部门的占比会更高。如果不搞清楚项目上多少人、花多长时间，就无法计算项目成本，无法评估花多花少。

过去一年，DD团队（数字化发展部门）和工业化部门已经基于“基本经营单元”做了很多尝试，比如说跟工业化相关的数字系统研发项目，回报高的就提高优先级，回报低的就降低优先级，减少投入或者取消。

公司资源边界有限，我们就该非常清楚如何排序。过去更多凭感性判断，现在全部通过“基本经营单元”这套机制来干。公司目标今年实现四季度盈利，从现在到四季度其实只剩两个季度，在管理、成本控制、资源分配，优先级制定上，一定不能再像以前那样感性。要实现可持续发展，一定要走这一步，得有一套合理的方法计算每个项目的投资回报。

这确实会对每个人的工作范式产生影响，每个人要尽量参与高投入产出的项目。这将驱动人力资源调配优化，有助于我们摆脱惯性。低产出的项目，该停就停；高产出的项目，该加资源就加资源。

关于填工时，我知道SpeakOut（注：蔚来内网论坛）上有不少吐槽，我们价值小组也给我写了很长的信，收集了很多同事的看法。填工时，在华为等很多公司都是基本操作，我们怎么就不能搞？这跟我们讲的真诚关爱不冲突。把每天干什么事、做什么项目说清楚，很正常。不愿意填工时，不愿意关联项目，只能说明一个情况，就是你所在的岗位不应该存在，你应该去找别的工作。要让真正给公司创造价值的同事，把价值体现出来，作用发挥出来；要让浑水摸鱼的人，暴露出来。

不要觉得以前没搞，现在突然搞了，蔚来不是那个蔚来了——蔚来早就该是这样的蔚来。我们在执行效率、经营效率、成本控制等方面，还没达到基准水平，给整个公司的品牌势能、经营状况带来很大的挑战。我们早就应该这么干。关键的还是要创造条件让真正能做事的人把价值体现出来，把资源聚焦到高优先级的工作项目上。

这是基本线，不是高要求。如果公司不走这一步，连如此基本的管理程度都做不到，那才是真正的麻烦。大家对我的期望，是我能把管理做好。现在很多人教我做CEO，我该听劝就必须听劝，连劝都听不到，那就真的很麻烦。

员工问答：把蔚来的尊严挣回来

Q：有什么机制能保证 CBU 朝着预期目标持续进行下去，不会沦为应付管理层的短期运动式行为？

A： CBU 绝不是应付管理层的短期运动，而是积极自救的长期持续行动。抓经营主体、经营负责人的工作表现，形成闭环机制，定期去看和当时计划的经营目标是不是一致，如果做不到，那蔚来不会存在，现在竞争太激烈了，是全面竞争，做好管理是基本生存条件。

Q：怎么看待很多人说蔚来管理不行？

A：外界质疑蔚来管理效率，很多讲的是对的，我们要认，我们既不自欺欺人，也不妄自菲薄，管理本来就没有止境，我们就从管理上把自己的尊严挣回来。

管理就是找到问题的本质，目标一致去解决它。别人质疑我们的管理，我们要做的事情就是靠管理把公司做好，只有这样才能赢得尊严。我们现在就是有错就改，小鹏能改好，我们怎么就不能改好？

Q：CBU 短期内希望看到什么变化？

A：希望全员提升经营意识。有很多部门已经行动起来了，不光是研发。大家一旦有了成本意识，就恍然大悟，有些钱真的不该花。比如说我们的门店，很多区域公司现在都在主动减掉一些低效的岗位。管理上要有自上而下的流程机制，但是要落地更多的要看到自下而上的行动，这是一个好的开始，但也不指望一两个月把问题都解决了，这是个要长期坚持的事。

Q：CBU 执行节奏？

A：整个节奏是希望一季度把这件事情启动起来，二季度持续打磨，全面执行，三季度基本上要做到融会贯通。四季度靠这个机制，靠我们的管理的同时，靠新产品带来的销量和毛利率的提升，实现盈利。

Q：如何判断一个项目 ROI 高还是低？是所有低 ROI 项目都不做吗？比如说部门的体系流程建设、制定标准、前瞻的研究、基础的赋能工作等。如果所有事情都要部门自己来承担经营责任，对于基础建设、基础能力或创新类的工作会不会有抑制作用。

A：不要去把它对立起来。公司会分配一部分的资源去在预研项目上，当然这是很长期的投入。预研项目也要排优先级，不是所有的预研项目都是值得干的。每个人都要能思考清楚自己的工作到底有什么价值创造，无外乎两方面，一方面是开源，一方面是节流。预研项目总得搞清楚一个时间表，10 年后的事很长远，但不是眼下紧要的事。我们就考虑三年内的事，三年以后的事情公司层面确实没有资源支持，任何一件事情三年内起不了作用，那就不搞。

Q：工时填写是否真的能提升体系化效率？最后的结果有没有可能是大家看起来都努力干活，填了很多工时，但干得结果怎么样不知道？

A：不填肯定是一点机会都没有。部分情况下工时可能没有那么精准，但再不精准也是一个正态分布，总有准的，总是在一个有限的范围内偏差。这不是我们不把账算清楚的理由。

#ChatBEV

VLM如何理解BEV？

今日星球自动驾驶前沿算法更新：

哈工大等团队思维链最新综述；
新加坡国立最细年底思维链综述；
上交提出ChatBEV；
复旦中稿CVPR'25的端到端算法BridgeAD；

Advances in 4D Generation

论文标题：Advances in 4D Generation: A Survey
论文链接：https://arxiv.org/abs/2503.14501

核心创新点：

1. 系统性分类框架

提出基于控制条件的四层分类法（文本、图像、视频、3D、多条件），为4D生成任务提供结构化框架（如MAV3D、AYG、TC4D等方法），帮助研究者快速定位技术路径并识别研究空白。

2. 4D表示方法的突破

4D高斯泼溅（4D Gaussian Splatting）：通过时空编码与变形场建模动态场景，结合显式高斯点表示与隐式运动预测（如Wu et al.的4D GS框架），提升动态渲染效率与质量。
动态NeRF扩展：引入时空分解策略（如HexPlane、K-Planes）与紧凑特征平面（如Tensor4D），优化动态场景的渲染速度与存储开销。

3. 融合扩散模型与物理先验

分数蒸馏采样（SDS）的优化：通过多阶段扩散模型（文本-图像、文本-视频）联合优化，提升4D资产的时空一致性（如PLA4D的像素对齐策略）。
物理驱动生成：结合物质点法（MPM）模拟粒子动力学（如Sync4D、Phy124），增强运动合理性与物理真实性。

4. 关键挑战的解决方案

一致性：引入跨视角注意力层（L4GM）与多模型融合（CT4D结合高斯与网格表示），解决几何与时间一致性难题。
效率：采用显式高斯表示（DreamGaussian4D）与中间数据生成（Efficient4D），将单模型生成时间缩短至数分钟。
可控性：多条件输入（文本+轨迹、图像+骨架）与混合表征（高斯+网格），实现精细运动与外观控制。

5. 多领域应用创新

数字人合成：通过骨架感知优化（STAR4D）与身份编码（Human4DiT），生成高保真动态人体模型。
自动驾驶仿真：结合稀疏点云与视频扩散模型（MagicDrive3D、DreamDrive），构建动态4D场景世界模型。

6. 未来方向与社会影响

数据集与评估标准：呼吁构建大规模文本-4D数据集（如Diffusion4D的5.4万动态资产），并提出适配4D生成的多维度评测基准（如T2ICompBench扩展）。
社会伦理：强调技术滥用风险（如深度伪造），倡导透明化生成流程与责任机制。

EdgeRegNet

论文标题：EdgeRegNet: Edge Feature-based Multimodal Registration Network between Images and LiDAR Point Clouds
论文链接：https://arxiv.org/abs/2503.15284

核心创新点：

1. 基于边缘特征的跨模态全局配准框架

提出首种利用2D图像边缘像素与3D点云边缘点进行全局配准的方法。通过融合深度不连续点与反射率不连续点（点云）以及LSD算法提取的线结构（图像），保留原始空间信息，避免下采样导致的信息损失，显著提升配准精度。

2. 注意力驱动的跨维度特征交互模块

设计基于自注意力与交叉注意力机制的特征交换模块，通过多层堆叠实现跨模态特征空间对齐。该模块利用位置编码与线性变换生成Q/K/V矩阵，在2D图像特征（CNN提取）与3D点云特征（PointNet++提取）间进行双向信息融合，有效缓解模态差异。

3. 基于最优传输的轻量化匹配优化层

引入LightGlue的轻量级最优匹配策略，通过可学习线性层计算相似性矩阵，结合Sigmoid激活的匹配概率预测，构建部分分配矩阵。采用Sinkhorn算法高效求解最优对应关系，提升匹配鲁棒性，同时降低计算复杂度。

4. 多任务驱动的混合损失函数

设计三阶段联合损失函数：

FOV损失（：通过二元交叉熵约束点云特征是否在相机视野内；
匹配概率损失（：监督2D像素与3D点的可匹配性概率；
分配矩阵损失（：最大化真实匹配对的分配概率。
通过加权融合( + + )实现端到端优化。

5. 高效全局配准性能

在KITTI与nuScenes数据集上，相比DeepI2P、CorrI2P等方法，EdgeRegNet在相对平移误差（RTE）、相对旋转误差（RRE）与推理速度（RTX 3090平台达25ms/帧）上均达到SOTA，成功解决传统方法对初始校准依赖及大偏移场景的失效问题。

HAD-Gen

论文标题：HAD-Gen: Human-like and Diverse Driving Behavior Modeling for Controllable Scenario Generation
论文链接：https://arxiv.org/abs/2503.15049
论文代码：https://github.com/RoboSafe-Lab/Sim4AD

核心创新点：

1. 驾驶风格聚类方法

提出基于风险特征（THW时间头距、iTTC逆时碰撞时间）的驾驶行为聚类框架，将驾驶风格划分为攻击型/正常型/谨慎型，通过轨迹片段比例（ratiorli）量化风险偏好，解决传统方法行为多样性不足的问题。

2. 分风格奖励函数重建

采用最大熵逆强化学习（MaxEnt IRL）为每类驾驶风格独立构建奖励函数，通过多项式轨迹采样近似配分函数，显式编码不同风格的底层驾驶动机（如攻击型赋予横向加速度高权重），突破传统IRL平均化策略的局限性。

3. 混合强化学习训练范式

创新性整合离线RL（TD3+BC）预训练与多智能体在线RL（SAC-CTDE），前者利用历史数据避免分布偏移，后者通过集中训练分散执行（CTDE）提升交互鲁棒性，解决单一RL方法泛化性差的挑战。

4. 可控场景生成机制

通过策略渗透率调控实现场景多样性（如提升攻击型策略比例生成高风险场景），在Automatum数据集验证中达成90.96%目标到达率，较传统BC/TD3+BC/SAC基线提升超20%，同时保持微观指标（JSD<0.1）的人类行为相似性。

DRoPE

论文标题：DRoPE: Directional Rotary Position Embedding for Efficient Agent Interaction Modeling
论文链接：https://arxiv.org/abs/2503.15029

核心创新点：

1. 方向感知的旋转位置编码（DRoPE）

针对自动驾驶轨迹生成中周期性角度建模难题，提出改进的旋转位置编码（RoPE）方法。通过引入统一标量参数重构2D旋转矩阵，将代理航向角与旋转角度对齐，首次实现显式相对角度编码，克服传统RoPE因周期性导致的相对角度信息丢失问题。

2. 时空复杂度优化

在保持Transformer架构O(N)空间复杂度的前提下，通过绝对位置编码隐式表达相对位置关系，避免传统RPE方法O(N²)的显式存储开销。理论证明其满足相对位置编码的等变性约束，同时支持全局长程交互建模。

3. 双模态集成架构

提出两种DRoPE-RoPE集成方案：头间分离式（Head-by-Head）和头内分解式（Intra-Head），分别通过多头注意力机制分离位置/方向编码或向量分解，实验证明前者在轨迹预测指标（minADE↓0.052）和交互真实性（REALISM↑0.7625）上更优。

Generating Multimodal Driving Scenes via Next-Scene Prediction

论文标题：Generating Multimodal Driving Scenes via Next-Scene Prediction
论文链接：https://arxiv.org/abs/2503.14945
项目主页：https://yanhaowu.github.io/UMGen/

核心创新点：

1. 多模态动态场景建模：

首次在自动驾驶场景生成中同时整合自车动作（ego-action）、交通参与者（road users）、动态地图（traffic map）与图像（image）四模态，新增地图模态的动态生成能力，突破传统方法静态地图或单一模态生成的限制，实现场景表征的完整性与可控性。

2. 分层自回归框架（TAR + OAR）：

时序自回归模块（TAR）：通过因果注意力机制（causal attention）捕捉跨帧时序依赖，降低长序列建模复杂度（计算成本从O降至O())。
有序自回归模块（OAR）：在单帧内按固定模态顺序（ego → map → agent → image）进行令牌（token）级自回归解码，确保跨模态对齐与一致性，减少代理碰撞率（CR降低8.9%）。

3. 动作感知地图对齐（AMA）：

基于自车动作（位移dx,dy与转角θ）对地图特征进行仿射变换（affine transformation），动态调整地图空间表示，解决自车运动与地图演化的时空一致性难题（实验显示地图偏移误差降低42%）。

4. 用户导向的交互控制：

支持通过指定自车动作（如急转、变道）或交通参与者行为（如切入）生成复杂交互场景（如紧急避障），结合多模态联合仿真，为AD系统测试提供高保真闭环环境。

5. 高效长序列生成：

框架可生成长达60秒的连续驾驶场景（21帧/秒），在nuPlan与Waymo数据集上MMD指标优于基线模型30%以上，GPU内存占用仅为传统自回归模型的1/4。

Learning-based 3D Reconstruction in Autonomous Driving

论文标题：Learning-based 3D Reconstruction in Autonomous Driving: A Comprehensive Survey
论文链接：https://arxiv.org/abs/2503.14537

核心创新点：

1. 数据范式革新

提出从多传感器标定数据（如对齐点云与图像）转向未标定图像序列的重建框架，显著降低数据采集门槛
发展基于单目/多目无约束图像的动态场景解耦技术（如SUDS、EmerNeRF），减少对3D标注的依赖

2. 3D表示突破

3D高斯泼溅（3D Gaussian Splatting）技术革新，实现高保真场景表征与低计算开销的平衡
混合高斯表示（HGS-Mapping）结合几何先验约束，提升城市场景重建精度
动态高斯神经点渲染（DGNR）实现大范围驾驶场景的密度引导重建

3. 大规模优化策略

空间划分范式（Spatial Partitioning）突破硬件限制，支持城市级场景分治重建
分布式高斯优化（DOGS）通过高斯共识机制实现超大规模场景并行处理

4. 动态场景建模

时序属性解耦框架（如VDG）分离静态/动态成分，引入周期振动高斯模型处理交通振动干扰
神经场景图（Neural Scene Graphs）实现动态物体轨迹与场景结构的联合建模

5. 生成式重建体系

组合生成模型CityDreamer与GaussianCity构建无界城市生成框架
隐式神经辐射场（UrbanNeRF）融合语义先验，实现城市场景可控生成

6. 系统级集成

PreSight框架集成NeRF先验记忆，提升感知系统语义-几何联合推理能力
UniPAD通过重建补全解决驾驶场景的部分可观测性问题

7. 基准创新

构建多模态自动驾驶专用数据集（MatrixCity、Argoverse2）
提出动态场景评估指标，涵盖几何保真度、时序一致性、语义完整性等维度

#面向感知的决策规划介绍

我觉的来看这篇文章的人应该是相关从业人员，所以决策规划是什么以及为什么要做决策规划就先不做赘述。

虽然搞了目录，但内容还是有些多，可以搜索关键字跳着看。

1. 组织架构

一般会有一层环境模型（车道模型、导航推荐、红绿灯决策）并行与预测（AI组），接着是决策层（变道、绕行等），然后是运动规划motion planning（横向规划，纵向规划），最后是控制。

2. 从入门到放弃

视频学习顺序：

https://space.bilibili.com/631671239/channel/collectiondetail?sid=992923
https://space.bilibili.com/287989852?spm_id_from=333.337.search-card.all.click
https://space.bilibili.com/325034144?spm_id_from=333.337.0.0

2.1 坐标系

FreeNet与笛卡尔

FreeNet优劣势

优势：

在弗莱纳坐标系下做运动规划的好处在于借助于指引线做运动分解，将高维度的规划问题，转换成了多个低维度的规划问题，极大的降低了规划的难度。
另外一个好处在于方便理解场景，无论道路在地图坐标系下的形状与否，我们都能够很好的理解道路上物体的运动关系。相较直接使用地图坐标系下的坐标做分析，使用弗莱纳坐标，能够直观的体现道路上不同物体的运动关系。

劣势：

XY坐标系下的规划器能力：为什么是xy，freenet的投影问题：

投影有误差
变量没有实际物理意义，算出来的cost有问题，
nudge场景：sl投影nudge膨胀，导致求解失败，xy最原始，贴合实际场景可以求解，
大曲率弯道，SL曲率有误差会影响车辆居中甚至会碰撞RB

对于轨迹生成，我认为在XY坐标系下，基于车辆运动学或再加动力学得到轨迹的方法更优。通过减少求解信息，达到减少耗时，提高限定时间内成功求解的概率；减少坐标系转换带来的损失。

Frenet高精度坐标转化需要使用优化算法，否则就可能存在厘米级误差，这会被城市场景中的决策判断放大。在Frenet下的障碍物筛选也没有XY下精度高，为了安全，只能提高冗余量，牺牲决策判断。

kd tree查点

笛卡尔：车道宽度，横向都可以解决

横向规划和纵向规划

速度规划的 s沿着轨迹的方向，路径规划的 s沿着参考线的方向。

左手坐标系和右手坐标系

左右顺时针为正，右手逆时针为正，注意0轴的定义

https://blog.csdn.net/zhouqiping/article/details/124522367

3. 预测

3.1 方案

DenseTNT需要四五十ms，改进后8ms。vectornet前半部分+denseTNT的轨迹输出部分

当前位置到目标位置：通过BFS搜索路径

3.2 现有问题

点的概率会有问题
argoverse数据集偏高速，导致实际场景的点的位置比较远
原有数据集没有的场景轨迹预测结果会较差，比如T型路口等

4. 环境模型

4.1 routing

比较稳定，A*
车道级导航算法开发（非高精地图）：采用AStar算法搜索2km路径，用于少变多选道、导航变道和路口选道。目前保定100km，北京泛化超过2000Km，选道成功率和导航变道触发率均在95%以上。

不同供应商的数据格式定义可能不同：

4.2 pnc map (lane graph)4.2.1 Perception lane

无高精地图路口建模功能：最大的问题还是强依赖与车道线平行假设。

基于SDPro地图进行路口建模，目前直行路口和少变多场景采用三次曲线、左右转采用五段式曲线（直线段、螺旋线、圆弧、螺旋线、直线段）

a. SD PRO vs HDMap：1m内，道路中心点dot_point，车道属性，有几个车道，宽度，得到拓扑map

b. routing：道路级导航，车道级导航（高德）1.映射到SDPro；2.车道级，起点是当前车道，终点无须指定，最早变道点，最晚变道点（点+buffer），右边有车卡会减速变道 road->segment->；

c. 左右转采用五段式曲线，如何保证分检点连续：转弯半径不变

d. 成功率：根据kappa是否满足最小转弯半径,R500m是个坎

-输入：感知车道线，sd pro

-输出：1.变道，2.laneid， 2变3，routing选用cost：车道中心线heading

红绿灯控车和红绿灯绑路：

红绿灯也是bbox,通过距离去匹配，匈牙利匹配。难点在于2匹1或者1匹2等存在感知或者地图丢失的情况。

主要根据灯箱的航向区分看哪组灯箱，以及根据车道箭头信息进行子灯颜色分类。根据灯的颜色进行决策，在上游稳定的情况下，控车成功率达到95%以上。

普通道路跟踪策略：

利用车道线平行假设，利用消失点计算pitch。为什么不用高精度定位的pitch？
对观测到的散点进行关键点BA优化，
对c0\1\2\3,width宽度进行滤波跟踪

多变少\少变多：

一般是车道线偏右，此时关键是要识别出远处（10-40m）的新增车道线，以进行点到点的连接。看不见新增的线（感知对线段起点有近距离要求？），会先往右打再往左打。

虚拟车道生成（无SDPro地图）应对场景：直行路口、道路分流合流场景（少变多、多变少）以及拥堵场景。主要分为跟车和跟线。

输入：感知车道线和障碍物
输出：local车道线

a. 跟车模式和跟线切换：看和线的距离

视觉感知车道线与EHR的融合：增减车道；高精地图的类型滞后；heading补偿（通常是0.3）；

4.2.2 HDMap

1 问题比较多，建议与视觉感知做融合

弯道点不够密
匝道处和曲率大弯道定位不准
匝道的时候，定位不准，单点rtk，依赖视觉线
heading偏差一般是两个原因：1.标定，定位装置/天线和车辆的标定 2.坐标系转换，wgs84转UTM坐标系存在畸变误差
定位的heading问题排查方法：画出车辆历史轨迹，然后和heading的线对比
怎么消除wgs84转utm时的误差 heading问题通过set_origin解决
匝道合入主路时地图要给全，防止左后方的车辆
定位偏还是控制偏：看时间戳，谁先震荡的，定位可以通过planning确认
怎么识别汇入口、分叉口：pre succ 所有车道的拓扑关系，难点在于哪些可换道,哪些不可以换道：通过图商给的host/subhost、 merge_left/right 、split_left/right
merge点不准；导航变道不准；参考线偏；
DR要退出系统，但是不要轻易进入DR

2.1.1 限速问题

2.1.2 虚实线问题

2.1.3 施工问题

2.1.4 匝道问题

2.1.5 隧道桥下树下等遮挡场景

xx只能DR5s(递推)

2.1.6 heading偏

标定误差：走直线标定
坐标转换误差：set_oring

2.1.7 方向乱晃yaw不准

检查惯导、RTK等硬件

2.2 地图质检模块的

专门需要修复层fix layer：十个图层，拓扑关系，lane、road；中心线起点终点的连续性；交通灯的判断生成停止墙

前后继点对不上的问题是由于可以允许1mm的误差：点连续性是因为utm 转换后有畸变造成，把阈值从0改为1mm就可以了；

offset个别会出现超过10（之前设置的是10）；还有一个是脚本错误码14写错了

新的检测脚本做了如下改动：1. offset 10->20, 2. 允许前后继节存在1mm误差，做出以上调整按理说错误信息多应该消失了

策略点：指引线平滑程度以及指引线的偏移策略点，比如最右的车道往左偏，避免频繁减速

黑名单：奇怪的位置，尽量不去偏远的地方，不去某些lane_id;

哪里的指引线，以及怎么偏移:最右侧，容易减速

2.3特殊点处理

贝塞尔曲线的链接，

消亡车道的处理

merge/split处理

2.4用到的数据结构：

center line，左右boundary，拓扑类型，后继车道，form/to_path_id，

3.SDmap

十字路口的重建：利用dot点，五次多项式螺旋曲线拟合

3.1 打断的规则

分界有几个原因：1.车道数目发生变化 2.车道拓扑关系发生变化 3.车道边界属性发生变化 4.限速 5.类型和颜色

就是保证了每个打断内的每根线属性不会变化

4.3 参考线生成

一些参考：

https://blog.csdn.net/sinat_52032317/article/details/128386386

https://blog.csdn.net/weixin_65089713/article/details/128855681

https://blog.csdn.net/ChenGuiGan/article/details/124633387

https://github.com/YannZyl/Apollo-Note/blob/master/docs/planning/reference_line_provider.md

4.3.1 多参考线生成

该项目对于车道行驶过程中除了当前车道参考线外，给出了(可能的)左右两条车道参考线。并且，每条参考线给出了换道类型、换道距离等信息，并将地图元素(汇入口、分叉口、公交车道等)绑定到参考线中。其目的在于帮助下游决策模块实现扩大行驶范围，扩大借道范围，避免急刹和碰撞风险等功能。在实际运营过程中，参考线数量增多至原先的1.8倍。

绑定hdmap元素，overlap属性位置等, sl坐标，l怎么确认：地图给

4.3.2 参考线平滑：

参考线平滑是有必要的，如果使用优化算法来光滑，个人感觉大材小用（不排除后续path求解强耦合很平滑的参考线，此处没有量化分析过）。个人感觉参考线平滑使用拟合就够了。

https://zhuanlan.zhihu.com/p/371585754

https://zhuanlan.zhihu.com/p/565854845

1.knots分段与二次规划进行参考线平滑:osqp不等式约束条件，cost，在已知box内优化，特殊点的平滑

1.1 预处理

通过第一阶段路径点采样与轨迹点矫正，可以得到这条路径的anchor_point集合,将anchor_point分成n组(n+1个knot节点)，每组用一个多项式函数去拟合，可以得到n个多项式函数

默认5m一个anchor，每段qp_spline(knot)是25m,

1.2 设置约束条件

需要拟合的多项式函数数量为2* num_spline个，每两个knots之间会拟合x和y两个多项式
多项式最高阶数为5(qp_spline.spline_order: 5)，所以每个多项式共6个参数，参数总和：(spline_order+1)2num_spline
使用每个段内的anchor point去拟合多项式函数，自变量范围[0,1]，应变量相对于第一个anchor point的相对坐标。所以最后拟合出来的函数f和g的结果是相对于第一个anchor point的相对坐标。

那么在拟合过程中还需要满足一些约束，包括等式约束和不等式约束，例如：

预测的x'和y'需要保证在真实x和y的L轴lateral_bound、F轴longitudinal_bound领域内
第一个anchor point的heading和函数的一阶导方向需要一致，大小可以不一致，但是方向必需一致！
x和y的n段函数之间，两两接壤部分应该是平滑的，两个函数值(位置)、一阶导(速度)、二阶导(加速度)必须一致。

1.3 cost函数计算

平滑度，长度，相对原始点偏离度

平滑度：FemPosSmooth相对不精准，但是只需用二次规划能快速求解

CosThetaSmooth相对精准，但是需要非线性规划，计算量大

Qk·Rk是点乘

1.4优化求解系数

求解完这个QP问题就可以得到系数矩阵，也变相得到了x和y的这n段平滑曲线，最后的工作就是包装秤一条ReferenceLine，，一共500个点

1.5平滑参考线校验

对平滑参考线SmoothReferenceLine上的点(可以采样，比如累积距离每10m采样)，投影到原始参考线RawReferenceLine的距离为l，l不能太大（阈值是6m），否则两条参考线有较大的偏移。

2,平滑参考线的拼接

复用、拼接、收缩

https://github.com/YannZyl/Apollo-Note/blob/master/docs/planning/reference_line_provider.md

5. 决策5.1 EUDM：

用dcp-tree语义动作减少减少动作搜索空间，并通过串联动作长时间决策能力弥补MPDP不足

cfb确定周围车辆的语义意图，选出具有风险的周车意图。

belief update体现在哪？

所以POMDP方法相当于没有用现有的求解器？但感觉思路差不多呀，相当于进行了行动空间和状态空间的改进。

初始信念和更新信念在EUDM和EPSILON中如何体现的？信念更新说的一个是基于规则一个基于学习，那初始信念怎么确定？下图啥意思？

参考IGP2我们考虑短期机动意图和长期预测意图
我们用现有存在的POMDP求解器去求解POMDP问题（EUDM中相当于用自己的方法去求解，和POMCP的区别是信念更新和MCTS？）
优化动作机动和长期意图序列，可以参考之前做博弈时的一些资料？EUDM中考虑的意图只是那三个？

5.2 POMDP

Michael Zhou：behavior planning 行为规划（一POMDP）

Michael Zhou：马尔可夫决策过程

5.3 Bayesian+MDP+Probabilistic Risk(Constrained)

（这段引用自卓荦锋芒：对自动驾驶中决策算法的思考）自动驾驶的决策算法的最优解是Bayesian+MDP+Probabilistic Risk(Constrained)。简要说明下理由，

Bayesian：基于数据得到先验（Prior）概率，然后使用后验（Posterior）概率，保证整个算法的拟人性和可解释性。实际上PGM的模型包括三层：因果层、意图层和观测层。

MDP：非常适合做交互决策，又能保证局部最优性。

Probabilistic Risk(Constrained)：就功能安全而言，风险的定义包括了风险的发生概率和风险的危害程度。在城市场景下，若自动驾驶做到全路段的话，需要在有约束的概率风险下的做决策。

导航变道，施工变道，超车变道（最适合cost）：变道类型不同，

大框架是使用MDP做交互，核心是MDP要素的处理，

状态S：采用语义化行为。致使该算法是基于行为的，而不是场景的，泛化能力更强。

自车的状态转移T：采用数据学习(非DNN)+车辆运动学模型的方法，模拟学习自车的规划性能。保证最终的结果符合规划的性能，又避免采用决策+规划的耦合方式的低泛化能力。

它车的状态转移T：采用Bayesian的方法学习和推断它车行为。根据它车的历史信息，使用先验和后验计算状态的转移及对应的概率。根据先验计算状态的转移及概率，避免深度学习、强化学习的不可解释性、低泛化性。

可违背风险的行为(R,A)：基于风险概率选择最优的动作序列。保证拥堵场景的通勤效率。

整体设计的思想遵循：交互性、准确性、合理性。

缺点：耗时，他车意图不确定，

根据最近的研究，再结合自身的积累储备，发现一条可行的算法方向：
MDP+LinearProgram+HomotopyClass+Interpolation(2D）。从理论上来说，该算法能够保证最优性和连续性，设计来源于十字路口的无保护转向场景；从可行性来讲，因为有过基于网格插值的MDP开发和凸优化的基础，所以不存在算法开发的堵塞点。

6. 横向规划

1 LaneChangeDecider产生是否换道的决策，更新换道状态：产生换道的状态，之后将结果保存在injector中

首先判断是否产生多条参考线，若只有一条参考线，则保持直行。若有多条参考线，则根据一些条件（主车的前方和后方一定距离内是否有障碍物，旁边车道在一定距离内是否有障碍物）进行判断是否换道，当所有条件都满足时，则进行换道决策。

// 纵向安全距离  2*adc_l + 1.2 * adc_v
const double common_safety_distance = config_.safety_distance_l_weight() * adc_l + config_.safety_distance_v_weight() * adc_v;
// input
Process(Frame* frame)
std::list<ReferenceLineInfo>* reference_line_info =
    frame->mutable_reference_line_info();
std::map<planning::ReferenceLineType, ReferenceLineInfo*>* reference_line_info_map =
    frame->mutable_reference_line_info_map();
// output
auto* prev_status = injector_->planning_context()
                        ->mutable_planning_status()
                        ->mutable_change_lane();
prev_status->set_is_clear_to_change_lane(is_clear_to_change_lane);
prev_status->set_left_lane_boundary_dist(left_lane_boundary_dist);
prev_status->set_right_lane_boundary_dist(right_lane_boundary_dist);

换道决策决定ADC是否进行换道。目前Apollo的体系是当有多条参考线时即进行换道。

如果不换道，在PathBoundsDecider中会将l ll的边界限制在本车道内(如果不借道)；
如果换道，在PathBoundsDecider中会将l ll的边界向目标车道一侧进行拓展；

1.process()
LaneChangeDecider 的主要决策逻辑在Process() 方法中
根据reference line的数量判断是否处于变道场景中，size() > 1则处于变道过程中，需要判断变道的状态

只有一条reference line，没有进行变道
有多条reference line，说明处在变道中
如果上一时刻处在变道中，根据上一时刻自车所处道路ID与当前时刻所处道路ID对比，来确认变道状态
// 1. 换道参考线选择决策，输出选择的ReferenceLineType
// 2. 安全空间判断以及对应换道参考线上是否有危险的障碍物
    // 此处判断传进来的referenceLineinfo是否是变道参考线，如果是则通过
    // IsClearToChangeLane()检查该参考线是否满足变道条件，
    // IsClearToChangeLane只考虑传入的参考线上的动态障碍物，不考虑虚的和静态的障碍物。疑点：为什么只/考虑动态障碍物？
// 3. 删除其它参考线
// 4. 换道状态机
    // 头次进入task，车道换道状态应该为空，默认设置为换道结束状态

2.PrioritizeChangeLane()
在调整参考线的顺序时，使用了PrioritizeChangeLane() 函数，它的调整参考线顺序的功能，需要配置enable_prioritize_change_lane为True，这个函数的完整代码及注释如下：

void LaneChangeDecider::PrioritizeChangeLane(
const bool is_prioritize_change_lane,
std::list<ReferenceLineInfo>* reference_line_info) const {
if (reference_line_info->empty()) {
AERROR << "Reference line info empty";return;
}
const auto& lane_change_decider_config = config_.lane_change_decider_config();
// TODO(SHU): disable the reference line order change for now
  // 如果没有配置变道优先，则退出该函数
if (!lane_change_decider_config.enable_prioritize_change_lane()) {return;}auto iter = reference_line_info->begin();while (iter != reference_line_info->end()) {ADEBUG << "iter->IsChangeLanePath(): " << iter->IsChangeLanePath();/* is_prioritize_change_lane == true: prioritize change_lane_reference_line
       is_prioritize_change_lane == false: prioritize
       non_change_lane_reference_line */// 0、is_prioritize_change_lane 根据参考线数量置位True 或 False
    // 1、如果is_prioritize_change_lane为True
    // 首先获取第一条参考线的迭代器，然后遍历所有的参考线，
    // 如果当前的参考线为允许变道参考线，则将第一条参考线更换为当前迭代器所指向的参考线,
    // 注意，可变车道为按迭代器的顺序求取，一旦发现可变车道，即推出循环。
    //
    // 2、如果is_prioritize_change_lane 为False，
    // 找到第一条不可变道的参考线，将第一条参考线更新为当前不可变道的参考线
    if ((is_prioritize_change_lane && iter->IsChangeLanePath())
    ||(!is_prioritize_change_lane && !iter->IsChangeLanePath())) {
    ADEBUG << "is_prioritize_change_lane: " << is_prioritize_change_lane;
    ADEBUG << "iter->IsChangeLanePath(): " << iter->IsChangeLanePath();
    break;
    }
    ++iter;
    }
    reference_line_info->splice(reference_line_info->begin(),*reference_line_info, iter);ADEBUG << "reference_line_info->IsChangeLanePath(): "<< reference_line_info->begin()->IsChangeLanePath();
}

3.IsClearToChangeLane() 判断当前的参考线是否变道安全
sClearToChangeLane() 遍历了当前参考线上所有目标，并根据目标的行驶方向设置安全距离，通过安全距离判断是否变道安全，代码及注释如下：

bool LaneChangeDecider::IsClearToChangeLane(ReferenceLineInfo* reference_line_info) {// 或得当前参考线的s坐标的最大最小值，以及自车速度
  double ego_start_s = reference_line_info->AdcSlBoundary().start_s();double ego_end_s = reference_line_info->AdcSlBoundary().end_s();double ego_v =std::abs(reference_line_info->vehicle_state().linear_velocity());// 遍历每个目标
for (const auto* obstacle :reference_line_info->path_decision()->obstacles().Items()) {// 跳过静止与虚拟目标
    if (obstacle->IsVirtual() || obstacle->IsStatic()) {ADEBUG << "skip one virtual or static obstacle";continue;}// 初始化
    double start_s = std::numeric_limits<double>::max();double end_s = -std::numeric_limits<double>::max();double start_l = std::numeric_limits<double>::max();double end_l = -std::numeric_limits<double>::max();// 遍历当前目标的预测轨迹点集，或得预测轨迹的边界点
    for (const auto& p : obstacle->PerceptionPolygon().points()) {SLPoint sl_point;reference_line_info->reference_line().XYToSL(p, &sl_point);start_s = std::fmin(start_s, sl_point.s());end_s = std::fmax(end_s, sl_point.s());start_l = std::fmin(start_l, sl_point.l());end_l = std::fmax(end_l, sl_point.l());}// 如果目标距离当前参考线距离太远， 则跳过该目标
    if (reference_line_info->IsChangeLanePath()) {static constexpr double kLateralShift = 2.5;if (end_l < -kLateralShift || start_l > kLateralShift) {continue;}}// Raw estimation on whether same direction with ADC or not based on
    // prediction trajectory
    // 判断车与障碍物是否同一方向行驶，同时设置安全距离。之后判断距离障碍物距离是否安全
    // 根据航向角判断是否为相同方向
    bool same_direction = true;if (obstacle->HasTrajectory()) {double obstacle_moving_direction =obstacle->Trajectory().trajectory_point(0).path_point().theta();const auto& vehicle_state = reference_line_info->vehicle_state();double vehicle_moving_direction = vehicle_state.heading();if (vehicle_state.gear() == canbus::Chassis::GEAR_REVERSE) {vehicle_moving_direction =common::math::NormalizeAngle(vehicle_moving_direction + M_PI);}double heading_difference = std::abs(common::math::NormalizeAngle(obstacle_moving_direction - vehicle_moving_direction));same_direction = heading_difference < (M_PI / 2.0);}// TODO(All) move to confs
    static constexpr double kSafeTimeOnSameDirection = 3.0;static constexpr double kSafeTimeOnOppositeDirection = 5.0;static constexpr double kForwardMinSafeDistanceOnSameDirection = 10.0;static constexpr double kBackwardMinSafeDistanceOnSameDirection = 10.0;static constexpr double kForwardMinSafeDistanceOnOppositeDirection = 50.0;static constexpr double kBackwardMinSafeDistanceOnOppositeDirection = 1.0;static constexpr double kDistanceBuffer = 0.5;double kForwardSafeDistance = 0.0;double kBackwardSafeDistance = 0.0;// 根据方向设置安全距离
    if (same_direction) {kForwardSafeDistance =std::fmax(kForwardMinSafeDistanceOnSameDirection,(ego_v - obstacle->speed()) * kSafeTimeOnSameDirection);kBackwardSafeDistance =std::fmax(kBackwardMinSafeDistanceOnSameDirection,(obstacle->speed() - ego_v) * kSafeTimeOnSameDirection);} else {kForwardSafeDistance =std::fmax(kForwardMinSafeDistanceOnOppositeDirection,(ego_v + obstacle->speed()) * kSafeTimeOnOppositeDirection);kBackwardSafeDistance = kBackwardMinSafeDistanceOnOppositeDirection;}// 判断障碍物是否满足安全距离
    if (HysteresisFilter(ego_start_s - end_s, kBackwardSafeDistance,kDistanceBuffer, obstacle->IsLaneChangeBlocking()) &&HysteresisFilter(start_s - ego_end_s, kForwardSafeDistance,kDistanceBuffer, obstacle->IsLaneChangeBlocking())) {reference_line_info->path_decision()->Find(obstacle->Id())->SetLaneChangeBlocking(true);ADEBUG << "Lane Change is blocked by obstacle" << obstacle->Id();returnfalse;} else {reference_line_info->path_decision()->Find(obstacle->Id())->SetLaneChangeBlocking(false);}}returntrue;
}

2 PathReuseDecider路径是否可重用,提高帧间平顺性

主要判断是否可以重用上一帧规划的路径。若上一帧的路径未与障碍物发生碰撞，则可以重用，提高稳定性，节省计算量。若上一帧的规划出的路径发生碰撞，则重新规划路径。

1.PathReuseDecider 是第二个task,作用是
根据横纵向跟踪偏差，来决策是否需要重新规划轨迹
如果横纵向跟踪偏差，则根据上一时刻的轨迹生成当前周期的轨迹，以尽量保持轨迹的一致性

scenario_type: LANE_FOLLOW
stage_type: LANE_FOLLOW_DEFAULT_STAGE
stage_config: {
  stage_type: LANE_FOLLOW_DEFAULT_STAGE
  enabled: true
  task_type: LANE_CHANGE_DECIDER
  task_type: PATH_REUSE_DECIDER
  task_type: PATH_LANE_BORROW_DECIDER
  task_type: PATH_BOUNDS_DECIDER
  task_type: PIECEWISE_JERK_PATH_OPTIMIZER
  task_type: PATH_ASSESSMENT_DECIDER
  task_type: PATH_DECIDER
  task_type: RULE_BASED_STOP_DECIDER
  task_type: ST_BOUNDS_DECIDER
  task_type: SPEED_BOUNDS_PRIORI_DECIDER
  task_type: SPEED_HEURISTIC_OPTIMIZER
  task_type: SPEED_DECIDER
  task_type: SPEED_BOUNDS_FINAL_DECIDER
task_type: PIECEWISE_JERK_SPEED_OPTIMIZER
  task_type: PIECEWISE_JERK_NONLINEAR_SPEED_OPTIMIZER
  task_type: RSS_DECIDER
}

PublicRoadPlanner 的 LaneFollowStage 配置了以下几个task 来实现具体的规划逻辑，
判断上一帧轨迹是否与障碍物碰撞

2.使用path_reuse的好处：
黑色轨迹为采用path_reuse，可以看到整个换道过程，轨迹完全一致; 红色、黄色轨迹为重新规划轨迹并采用trajectory_stitcher 拼接。速度和位置都会有问题。https://zhuanlan.zhihu.com/p/524300384
可以看到在轨迹拼接处以及整体轨迹可能出现不连贯不平滑的情况，可能会影响控制的平顺性：

时为了保证轨迹的连续性，当前拍的规划起点应该选在last_traj离pos_cur最近的投影点上（一般情况下需要增加dt的向前预测量）。得到该投影点的信息后，即可规划出蓝色cur_traj曲线。即使当前位置不在轨迹上，但我们规划出来的轨迹与上一拍规划轨迹完全重合。从而保证了轨迹的连续性，使得控制连贯，不会产生跳变的情况。
值得注意的是，这里需要设定pos_cur和投影点的偏差阈值，若两者距离太大，说明控制无法跟上规划的轨迹。此时，应该考虑实际位置做进一步的规划（比如设定阈值30cm，自车位置离轨迹线35cm，此时可以设定起点为离投影点20cm的地方作为规划的起点，而不是继续拿投影点作为起点继续规划。主要是因为此时偏差较大，继续使用投影点规划会导致控制的超调，从而引起更大的画龙。）。

3.PathReuseDecider 只对外暴露了Process() 一个接口，它的主要逻辑如下：
（1）当前处于非LaneFollow_Scenario场景，置位false
（2）当前未处于IN_CHANGE_LANE状态，置位false;
（3）如果存在可变车道，且已经完成换道轨迹生成，则置位false;
（4）前一时刻采用path_reuse, 若轨迹重规划、轨迹与静态障碍物发生碰撞、轨迹长度过短以及纵向求解失败，则置位false;
（5）只有前方静止障碍物走开(或大于阈值)、纵向求解成功、未与静态障碍物发生碰撞且轨迹长度大于阈值，才可置位true;

4.当path_reusable置位后，后续的task会跳过处理的过程

// skip path_lane_borrow_decider if reused path
  if (FLAGS_enable_skip_path_tasks && reference_line_info->path_reusable()) {// for debug
    AINFO << "skip due to reusing path";return Status::OK();}

5.一旦path_reusable置位，则使用上一周期轨迹生成当前周期的规划轨迹
6.在判断是否 path_reusable时，会调用IsCollisionFree 判断静态目标是否安全
3 PathLaneBorrowDecider
产生是否借道的决策：当产生阶导决策时，会将相应标志位置true。同时，在进行借道决策时，会对左右借道进行判断。借道的状态保存在injetor里。

该决策有以下的判断条件：• 是否只有一条车道• 是否存在阻塞道路的障碍物• 阻塞障碍物是否远离路口• 阻塞障碍物长期存在• 旁边车道是实线还是虚线当所有判断条件都满足时，会产生借道决策。 ADC在借道工况中：判断本车道可通过性，如果在连续n nn(参数配置)帧规划中本车道可以通行，则取消借道。

Process(
    Frame* const frame, ReferenceLineInfo* const reference_line_info)
// input
*frame
// output
reference_line_info->set_is_path_lane_borrow(

ADC不在借道工况中：ADC需要同时满足以下条件才可以进入借道工况：

必须只有一条参考线；（是否只有一个障碍物）
规划起点的速度不能过高(参数配置)；
不能在SIGNAL、STOP_SIGN 和Junction附近；
不能在终点附近；
Block Obstacle在ADC一定范围内，并且堵塞原因不是Traffic Flow；
地图车道线线型（虚线）允许借道；（实线还是虚线）
如果借道，在PathBoundsDecider中会将l ll的边界借道方向一侧进行拓展。
是否长期存在

作用主要是换道时：

已处于借道场景下判断是否退出避让；
未处于借道场景下判断是否具备借道能力。

1.PathLaneBorrowDecider只是判断是否满足借道条件
具体的轨迹是否借道，是由后面的task决定
2.Process()
借道决策器的主要功能为判断当前车辆是否具备借道能力，其实现在类PathLaneBorrowDecider的成员函数process()中。process()函数的功能一共分为三部分：检查输入、如果路径复用则跳过借道决策、判断当前街道状态。
2.1判断是否借道IsNecessaryToBorrowLane（）
借道判断主要通过核心函数IsNecessaryToBorrowLane()判断是否借道，主要涉及一些rules，包括距离信号交叉口的距离，与静态障碍物的距离，是否是单行道，是否所在车道左右车道线是虚线等规则。主要有两个功能：
（1）已处于借道场景下判断是否退出避让；
（2）未处于借道场景下判断是否具备借道能力。
需要满足下面条件才能判断是否可以借道：

只有一条参考线，才能借道
起点速度小于最大借道允许速度
阻塞障碍物必须远离路口
阻塞障碍物会一直存在
阻塞障碍物与终点位置满足要求
为可侧面通过的障碍物

2.2CheckLaneBorrow()
主要根据前方道路的线型判断是否可以借道；在此函数中2m间隔一个点遍历车前100m参考线或全部参考线，如果车道线类型为黄实线、白实线则不借道。
2.3IsNonmovableObstacle()
IsNonmovableObstacle() 中主要对前方障碍物进行判断，利用预测以及参考线的信息来进行判断：

目标太远不借道
目标停止借道
目标

3.结果
PathLaneBorrowDecider 的输出结果存在mutable_path_decider_status当中，

4 PathBoundsDecider

产生路径边界：根据现有决策在参考线上进行采样，获得每个点在l ll的边界。有四种边界决策：GenerateRegularPathBound（自车道行驶）、GenerateFallbackPathBound（失败回退）、GenerateLaneChangePathBound、GeneratePullOverPathBound。最后将边界保存在SetCandidatePathBoundaries中，供下一步使用。

利用前几个决策器，根据相应条件，产生相应的SL边界。这里说明以下Nudge障碍物的概念——主车旁边的障碍物未完全阻挡主车，主车可以通过绕行避过障碍物（注意图中的边界）。它的作用主要是：

根据借道信息、道路宽度生成FallbackPathBound
根据借道信息、道路宽度生成、障碍物边界生成PullOverPathBound、LaneChangePathBound、RegularPathBound中的一种

PathBoundsDecider会根据换道决策和借道决策生成相应的l ll的边界。
FallbackBound+PullOverBound；
FallbackBound+LaneChangeBound；
FallbackBound+NoBorrow/LeftBorrow/RightBorrow；
不管在何种决策下，PathBoundsDecider都会生成一条FallbackBound，其与NoBorrow的区别是，不会删除Block Obstacle后道路边界。

// intput
    // Initialization.
    InitPathBoundsDecider(*frame, *reference_line_info);
// output
PathBound fallback_path_bound;
PathBound lanechange_path_bound;
PathBound regular_path_bound;
PathBound -> PathBoundary -> candidate_path_boundaries.emplace_back(regular_path_boundary);
reference_line_info->SetCandidatePathBoundaries(
    std::move(candidate_path_boundaries));

1.计算path 的boundary
PathBoundsDecider根据lane borrow决策器的输出、本车道以及相邻车道的宽度、障碍物的左右边界，来计算path 的boundary，从而将path 搜索的边界缩小，将复杂问题转化为凸空间的搜索问题，方便后续使用QP算法求解
2.输出是对纵向s等间距采样，横向s对应的左右边界
PathBoundsDecider计算path上可行使区域边界，其输出是对纵向s等间距采样，横向s对应的左右边界，以此来作为下一步路径搜索的边界约束；与其他task一样，PathBoundsDecider的主要逻辑在Process() 方法中。
在Process() 方法中分四种情况对pathBound进行计算，按照处理顺序分别是fallback、pullover、lanechange、regular，不同的boundary对应不同的应用场景，其中fallback对应的path bound一定会生成，其余3个只有一个被激活，即按照顺序一旦有有效的boundary生成，就结束该task。
3.关于ADC_bound 与lane_bound的计算

（1）根据车道生成左右的lane_bound，从地图中获得；根据自车状态生成adc_bound， adc_bound = adc_l_to_lane_center_ + ADC_speed_buffer + adc_half_width + ADC_buffer
上式中的各项：
adc_l_to_lane_center_ - 自车
adc_half_width - 车宽
adc_buffer - 0.5
ADCSpeedBuffer表示横向的瞬时位移，公式如下：

其中kMaxLatAcc = 1.5
（2）根据ADC_bound 与lane_bound 生成基本的bound
左侧当前s对应的bound取MAX(left_lane_bound,left_adc_bound), 即取最左边的右侧当前s对应的bound取MIN(right_lane_bound,right_adc_bound)，即取最右边的4.InitPathBoundsDecider()
在Process()过程中，首先会初始化bounds，用规划起始点自车道的lane width去初始化 path boundary，如果无法获取规划起始点的道路宽度，则用默认值目前是5m，来初始化。 path_bounds由一系列采样点组成，数据结构如下，这组数据里共有0～199个200个采样点，每两个点的间隔是0.5m；每个点由3个变量组成，分别是根据参考线建立的s-l坐标系的s坐标，右边界的l取值，左边界的s取值：
5.GenerateFallbackPathBound()
无论当前处于何种场景，都会调用GenerateFallbackPathBound() 来生成备用的path bound，在计算FallbackPathBound时不考虑障碍物边界，仅使用道路边界，并考虑借道信息来进行计算。
// Generate the fallback path boundary.
// 生成fallback_path_bound，无论何种场景都会生成fallback_path_bound
// 生成fallback_path_bound时，会考虑借道场景，向哪个方向借道，对应方向的path_bound会叠加这个方向相邻车道宽度
PathBound fallback_path_bound;Status ret =// 生成fallback_path_bound，
// 首先计算当前位置到本车道两侧车道线的距离；
// 然后判断是否借道，并根据借道方向叠加相邻车道的车道宽度
// 带有adc的变量表示与自车相关的信息
GenerateFallbackPathBound(*reference_line_info, &fallback_path_bound);if (!ret.ok()) {ADEBUG << "Cannot generate a fallback path bound.";return Status(ErrorCode::PLANNING_ERROR, ret.error_message());}if (fallback_path_bound.empty()) {const std::string msg = "Failed to get a valid fallback path boundary";AERROR << msg;return Status(ErrorCode::PLANNING_ERROR, msg);}if (!fallback_path_bound.empty()) {CHECK_LE(adc_frenet_l_, std::get<2>(fallback_path_bound[0]));CHECK_GE(adc_frenet_l_, std::get<1>(fallback_path_bound[0]));}// Update the fallback path boundary into the reference_line_info. // 将fallback_path_bound存入到candidate_path_boundaries std::vector<std::pair<double, double>> fallback_path_bound_pair;for (size_t i = 0; i < fallback_path_bound.size(); ++i) {fallback_path_bound_pair.emplace_back(std::get<1>(fallback_path_bound[i]),std::get<2>(fallback_path_bound[i]));}candidate_path_boundaries.emplace_back(std::get<0>(fallback_path_bound[0]),kPathBoundsDeciderResolution,fallback_path_bound_pair);candidate_path_boundaries.back().set_label("fallback");

6.障碍物边界生成
（1）首先筛选障碍物，障碍物筛选规则如下，需要符合以下所有的条件，才加到obs_list中：

不是虚拟障碍物
不是可忽略的障碍物（其他decider中添加的ignore decision）
静态障碍物或速度小于FLAGS_static_obstacle_speed_threshold（0.5m/s）
在自车的前方

（2）将每个障碍物分解成两个ObstacleEdge，起点一个终点一个，记录下s，start_l,end_l,最后按s排序

7.根据场景生成另外一条path_bound
依次判断是否处于pull_over、lane_change、regular；当处于其中一个场景，计算对应的path_bound并返回结果；即以上3种场景，只会选一种生成对应的根据场景生成另外一条path_bound。
这3种path bound均考虑了障碍物的边界，用障碍物的边界来修正path bound：

首先根据借道与否，用道路宽度来生成基本的path bound
然后遍历path上的每个点，并且判断这个点上的障碍物，利用障碍物的边界来修正path bound
如果目标在左边将left_bound 设置为目标右边界
如果目标在右边，将right_bound设置为目标的左边界

Status PathBoundsDecider::GenerateLaneChangePathBound(const ReferenceLineInfo& reference_line_info,std::vector<std::tuple<double, double, double>>* const path_bound) {// 1. Initialize the path boundaries to be an indefinitely large area.
  // 1、用numeric 的最大最小值初始化path bound
  if (!InitPathBoundary(reference_line_info, path_bound)) {const std::string msg = "Failed to initialize path boundaries.";AERROR << msg;return Status(ErrorCode::PLANNING_ERROR, msg);}// PathBoundsDebugString(*path_bound);


  // 2、用当前车道宽度计算path bound，同时考虑lane borrow，如果借道将目标车道的宽度叠加
  // 2. Decide a rough boundary based on lane info and ADC's position
  std::string dummy_borrow_lane_type;if (!GetBoundaryFromLanesAndADC(reference_line_info,LaneBorrowInfo::NO_BORROW, 0.1, path_bound,&dummy_borrow_lane_type, true)) {const std::string msg ="Failed to decide a rough boundary based on ""road information.";AERROR << msg;return Status(ErrorCode::PLANNING_ERROR, msg);}// PathBoundsDebugString(*path_bound);


  // 3、在换道结束前，用ADC坐标到目标道路边界的距离，修正path bound
  // 3. Remove the S-length of target lane out of the path-bound.
  GetBoundaryFromLaneChangeForbiddenZone(reference_line_info, path_bound);PathBound temp_path_bound = *path_bound;std::string blocking_obstacle_id;// 根据path上的障碍物修正path_bound，遍历path上每个点，并在每个点上遍历障碍物；
  // 如果目标在左边将left_bound 设置为目标右边界
  // 如果目标在右边，将right_bound设置为目标的左边界
  if (!GetBoundaryFromStaticObstacles(reference_line_info.path_decision(),path_bound, &blocking_obstacle_id)) {const std::string msg ="Failed to decide fine tune the boundaries after ""taking into consideration all static obstacles.";AERROR << msg;return Status(ErrorCode::PLANNING_ERROR, msg);}// Append some extra path bound points to avoid zero-length path data.
  int counter = 0;while (!blocking_obstacle_id.empty() &&path_bound->size() < temp_path_bound.size() &&counter < kNumExtraTailBoundPoint) {path_bound->push_back(temp_path_bound[path_bound->size()]);counter++;}ADEBUG << "Completed generating path boundaries.";return Status::OK();
}

5 PiecewiseJerkPathOptimizer

PiecewiseJerkPathOptimizer 是lanefollow 场景下，所调用的第 5 个 task，属于task中的optimizer类别
基于二次规划算法，对每个边界规划出最优路径.调用piecewise_jerk_problem类进行求解，会设置一些权重以及一些约束，利用Optimize函数进行求解。
reference_line_info_->GetCandidatePathBoundaries();保存候选路径。

// input auto &reference_line

= reference_line_info->reference_line();
auto &init_point = frame->PlanningStartPoint();
const auto& path_boundaries = reference_line_info->GetCandidatePathBoundaries(); 
PathData path_data = *reference_line_info->mutable_path_data();
const double lat_acc_bound =
    std::tan(veh_param.max_steer_angle() / veh_param.steer_ratio()) /
    veh_param.wheel_base();
 
// output

问题点：

约束设计时，曲率模型做了近似，假设太理想，
特点
(1) 平滑程度高，cost_fuc中加入了目标轨迹与QP输出轨迹的贴切程度
(2) 复杂度问题，为了保证安全性，QP中的约束条件Piecewise也几乎都需要使用，一般通过第三方osqp开源库进行解算，解算耗时有较大波动
(3) 舒适度，差分考虑加加速度，对舒适性指标进行平滑
(4) 拓展性，cost_fuc可自定义
1.它的作用主要是：

1、根据之前decider决策的reference line和 path bound，以及横向约束，将最优路径求解问题转化为二次型规划问题；
2、调用osqp库求解最优路径；

2.数学模型
https://www.chuxin911.com/osqp-introduction_20210715/2.1二次规划标准型
https://blog.csdn.net/sinat_52032317/article/details/128406586

2.2定义优化变量

路径规划一般是在Frenet坐标系中进行的。s为沿着参考线的方向，l为垂直于坐标系的方向。

根据导引线和障碍物生成路径边界
将导引线在s方向等间隔采样
对每个s方向的离散点迭代的优化 , ', '' 。

一些设置
delta s : --path_bounds_decider_resolutinotallow=0.5
最大迭代次数：（15会掉帧）6
dl error 最大是0.02满足
2.3 设计目标函数

l的三阶导数，dddl可通过二阶导差分的方式获取。

piecewise-jerk method

横向位置的l三阶导数如下图所示，

图：dddl的表达式
另外，为考虑path的连续性下方的l,l',l''等式约束需要考虑到约束条件中，如下图，

图：l,dl,ddl的等式约束
整个过程的路径规划的目标函数为：

路径优化的目标函数

可变的道路边界对车辆运行学约束，道路曲率的等式约束如下，kr，kr_dot为当前点的曲率参数，△θ为车辆的航向角与当前点曲率的差值。

道路曲率与车辆的关系

QP问题的表达形式:

将bound转为qp格式
bound主要由三部分组成：

在path bound decider中获取的上下边界
l' l'' l'''的约束
起点约束
数学约束，上述的l,l',l'',l'''的数学关系

所以需要将目标函数J 以及边界bound的约束条件改为QP 问题的形式，这里Python代码在考虑约束时忽略了车辆运动学的约束，在Apollo 的算法中还考虑了车辆运动学的约束。
将路径优化问题转化为QP问题的方法如下：
（1）用path上每个采样点的横向坐标，横向一阶导、二阶导构建X 矩阵：
（2）通过展开多项式推导后，按下列公式构建P、q矩阵：

（3）根据上下边界的约束，构建A 矩阵：
（4）根据path bound的约束，构建l、u矩阵：
整个formulate problem的过程，通过以上步骤完成了P,q,A,LB,UB五个矩阵，接下来使用osqp求解器进行求解需要满足半正定(https://www.cnblogs.com/icathianrain/p/14407626.html)

2.4构建约束
曲率约束：根据坐标系转换，kappa(xy) = kappa(frent) + kappa(refenrence) 。代码里优化的是kappa(frenet)。但是在曲率比较大的地方，前面的等式不成立，导致这个约束并不准确。所以业界才考虑在xy坐标下做规划。

2.4.1约束总结

3.流程
(1) 初始化
获取障碍物信息(SL图)、Frenet坐标信息、车辆信息(位姿、车辆自身几何约束)、QP后的轨迹
(2) 纵向离散化
对于每一个离散点，计算其纵向通行区域(lmin,lmax)

(3) 选择优化变量
对于第2步中的横向偏移量，求解一阶导和二阶导，表征车辆靠近与偏离指引线的趋势同时，对相邻离散点，通过差分计算三阶导数
量化表示: 离散点i，横向偏移li，一二三阶导数分别为li'，li''，li'''

(4) 优化目标设定
(1) 车辆贴近参考线
(2) 一二三阶导数尽可能小，控制横向加速度，保证舒适性

备注: 可以根据需求，选择性的加入与边界距离的优化目标，使车辆与障碍物保持适当距离
4.求解
求解器：考虑曲率才用的是非线性的osqp，如果不加曲率约束的话就用QP，不用迭代。

6 PathAssessmentDecider

路径评价，选出最优路径。调用ComparePathData函数，对路径进行两两比较。 依据以下规则，进行评价。路径是否和障碍物碰撞路径长度路径是否会停在对向车道路径离自车远近哪个路径更早回自车道…

路径两两进行对比，选出最优的路径。
PathAssessmentDecider 是lanefollow 场景下，所调用的第 6 个 task，属于task中的decider 类别它的作用主要是：

选出之前规划的备选路径中排序最靠前的路径；
添加一些必要信息到路径中

PathAssessmentDecider会依据设计好的规则筛选处最终的path，并在规划路径上的采样点添加标签（IN_LANE、OUT_ON_FORWARD_LANE、OUT_ON_REVERSE_LANE等），作为路径筛选的依据，并为速度规划提供限制。
路径筛选的规则是：

不能偏离参考线和Road太远；
不能和Static Obstacle相撞；
不能停止在对向车道上；
选择优先级最高的Path，排序规则：

Regular path优先于fallback path；
如果两条路径至少有一条是self_lane，并且两条路径长度的差大于15m，选择路径长的；
如果两条路径至少有一条是self_lane，并且两条路径长度的差小于5m，是self_lane的；
如果两条路径都不是self_lane，并且两条路径长度的差大于25m，选择路径长的；
选择占据反向车道更少的路径；
是否停到对向车道
如果有block obstacle，选择占据空间少的方向的路径；
如果没有block obstacle，选择ADC靠近方向的路径，使车辆少打方向盘；
选择返回本车道更早的路径；
在上述情况无法区分的情况下选择左侧的路径；

7. PathDecider

根据选出的路径给出对障碍物的决策

若是绕行的路径，则产生绕行的决策；若前方有障碍物阻塞，则产生停止的决策。
PathDecider 是lanefollow 场景下，所调用的第 7 个 task，属于task中的decider 类别它的作用主要是：
在上一个任务中获得了最优的路径，PathDecider的功能是根据静态障碍物做出自车的决策，对于前方的静态障碍物是忽略、stop还是nudge

遍历每个障碍物, 根据规则判断前面优化并筛选出来的path生成对应的decisions(GNORE, STOP, LEFT NUDGE, RIGHT NUDGE等)。

对以有IGNORE/STOP/KEEP_CLEAR决策的obstacle不做处理；
如果是block obstacle，并且不是借道工况，设为STOP决策；
不在path纵向范围内的障碍物设为IGNORE决策；
对于碰撞的obstacle，设为STOP决策；
根据位置关系设置LEFT NUDGE或者RIGHT NUDGE的决策；

8 RuleBasedStopDecider

RuleBasedStopDecider 是lanefollow 场景下，所调用的第 8 个 task，属于task中的decider 类别它的作用主要是：

根据一些规则来设置停止标志。

横向输出

message PathPoint {
  // coordinates
  optional double x = 1;
  optional double y = 2;
  optional double z = 3;


  // direction on the x-y plane
  optional double theta = 4;
  // curvature on the x-y planning
  optional double kappa = 5;
  // accumulated distance from beginning of the path
  optional double s = 6;


  // derivative of kappa w.r.t s.
  optional double dkappa = 7;
  // derivative of derivative of kappa w.r.t s.
  optional double ddkappa = 8;
  // The lane ID where the path point is on
  optional string lane_id = 9;


  // derivative of x and y w.r.t parametric parameter t in CosThetareferenceline
  optional double x_derivative = 10;
  optional double y_derivative = 11;
  // Ali-XLab-Begin motai.yy 2019-10-11
  optional double slope_angle = 12 [default = 0.0];  // [rad]
  // Ali-XLab-End
}

纵向输出

message SpeedPoint {
  optional double s = 1;
  optional double t = 2;
  // speed (m/s)
  optional double v = 3;
  // acceleration (m/s^2)
  optional double a = 4;
  // jerk (m/s^3)
  optional double da = 5;
}

纵向：
https://blog.csdn.net/weixin_56492465/article/details/128870540https://blog.csdn.net/mpt0816/article/details/122009754
优化模型离散方式
在处理最优化问题时，一般会转化成离散形式，将轨迹s ( t ) s(t)s(t)按照某参数离散，并计算离散点处的约束和c o s t costcost。不同的离散方式会构建不同的优化模型。对于速度规划问题，一般可以按照等间距离散(Spatial Parameter Discretization)和等时间离散(Temporal Parameter Discretization)。
1.1.1 Spatial Parameter Discretization
使用纵向距离s ss作为离散采样参数，假设第一个采样点s = 0 s=0s=0，连续采样离散点之间等间隔Δ s \Delta sΔs离散，那么优化问题的决策变量为每个离散点的s ˙ , s ¨ 和相邻采样点之间的时间间隔Δ t \Delta tΔt。

优点：
参考线或者规划路径的曲率κ \kappaκ是纵向距离s ss的函数，因此向心加速度约束是容易处理的；
地图限速等速度约束是和纵向距离s ss相关的，那么优化问题的s ˙ 约束容易计算；
缺点：
优化问题的目标函数难以建模。Apollo规划算法用来优化纵向冲击度最小，冲击度使用相邻两个离散点的差分计算，如果采用Δ s \Delta sΔs离散会使决策变量之间有除法运算，形成非凸优化问题；
难以施加安全约束。障碍物一般投影在ST Graph中，会得到每个时刻下的安全行驶范围( s m i n , s m a x ) )，即可行驶区域s f r e e ( t ) (t)是时间t tt的函数。
1.1.2 Temporal Parameter Discretization
使用时间t tt作为离散采样参数，假设第一个采样点t = 0 t=0t=0，连续采样离散点之间等间隔Δ t \Delta tΔt离散，那么优化问题的决策变量为每个离散点的s , s ˙ , s ¨ cost funtion

使用等时间间隔离散的方式，和使用等距离离散方式的优缺点恰好相反。
优点：
优化模型可以保持凸包性质，冲击度的计算仍然是线性形式；
障碍物的安全约束容易施加在优化模型中；
缺点：
由于曲率是s ss的函数，因此向心加速度约束难以处理；
速度约束难以处理；
最小任务完成时间的优化目标难以处理；
处理方法：
使用规划路径的最大曲率计算向心加速度限制；
将离散点处的位置s ss与DP得到纵向位置s ss的差作为目标函数的一部分，使用DP结果在采样时刻t处的s处对应的速度限值；
将离散采样点处的速度s ˙ 与目标速度(reference speed)的差作为目标函数的一部分。以保证完成任务花费的时间最少；
此外，Apollo还设计了非线性速度规划来处理以上问题。
const funtion

约束
等式约束

不等式约束

7.纵向规划

7.1 STBoundsDecider

百度已经关掉此task，区间过于宽泛。

作用

生成DrivableSTBoundary 供dp搜索的时候用
对不影响纵向规划的障碍物设置IGNORE属性;

// 输入：
const PathData &path_data = reference_line_info->path_data();
PathDecision *path_decision = reference_line_info->path_decision();
// 输出：
regular_st_bound, regular_vt_bound
RecordSTGraphDebug(st_boundaries, regular_st_bound, st_guide_line,
                   &st_graph_debug);
// 1.Initialize the related helper classes
InitSTBoundsDecider(*frame, reference_line_info);
// 1.1st_driving_limits_初始化
st_obstacles_processor_.MapObstaclesToSTBoundaries(path_decision);
st_driving_limits_.Init(max_acc, max_dec, max_v,
                        frame.PlanningStartPoint().v());
// 2.GenerateRegularSTBound,Sweep the t-axis, and determine the s-boundaries step by step
// 2.1依据运动学driving_limits更新s_lower, s_upper
auto driving_limits_bound = st_driving_limits_.GetVehicleDynamicsLimits(t); 
// 2.2.依据自车运动学约束，剔除不可达的障碍物decision

STBoundsDecider是来计算ST Graph中st_drivable_boundary_。由三个模块的计算组成：

依据障碍物st_boundary约束，更新可通行s_bounds以及对应的决策(

GetBoundsFromDecisions),对于同一障碍物的st_boundary可能存在多个决策，比如overtake或yield,见GetSBoundsFromDecisions函数;
本模块障碍物的ST图计算耗时也较高，但st_boundary精度较低;同理最终生成的st_drivable_boundary_边界精度也较低。
如果在下游gridded_path_time_graph模块中FLAGS_use_st_drivable_boundary不置位时,则无需使用该模块输出的st_drivable_boundary；因此可结合实际项目需求，来精简该模块的冗余计算。

7.2 SPEED_BOUNDS_PRIORI_DECIDER

作用：
得到ST Graph中的st_boundaries
产生速度可行驶边界

所形成的区域是非凸的，不能用之前
凸优化的方法去做，需要用动态规划的方法去做。
（1）将规划路径上障碍物的st bounds 加载到路径对应的st 图上
（2）计算并生成路径上的限速信息

// 输入：
// retrieve data from frame and reference_line_info
const PathData &path_data = reference_line_info->path_data();
const TrajectoryPoint &init_point = frame->PlanningStartPoint();
const ReferenceLine &reference_line = reference_line_info->reference_line();
PathDecision *const path_decision = reference_line_info->path_decision();
// 输出:
boundaries, min_s_on_st_boundaries, speed_limit
st_graph_data->LoadData(boundaries, min_s_on_st_boundaries, init_point,
                        speed_limit, reference_line_info->GetCruiseSpeed(),
                        path_data_length, total_time_by_conf);

SpeedBoundsPrioriDecider对应的Decider或者说class是SpeedBoundsDecider，是计算每个障碍物的STBoundary得到ST Graph中的st_boundaries_和speed_limit_(SpeedLimit)。其中每个障碍物的STBoundary的计算其实是根据遍历规划时间内障碍物和规划路径的碰撞关系来计算的，并且会根据是否对障碍物做过纵向决策以及决策类型设置其STBoundary的
characteristic_length。
speed_limit_(SpeedLimit)则是根据三个方面计算的：

地图限速；

double speed_limit_from_reference_line =
    reference_line_.GetSpeedLimitFromS(reference_line_s);

向心加速度限制；sqrt(a/kappa) a= 2

const double speed_limit_from_centripetal_acc =
    std::sqrt(speed_bounds_config_.max_centric_acceleration_limit() /
              std::fmax(std::fabs(discretized_path.at(i).kappa()),
                        speed_bounds_config_.minimal_kappa()));

对于近距离nudge障碍物的减速避让；

//1.先判断是否左/右靠太近
//2.然后根据动静态障碍物设置限速比例
speed_limit_from_nearby_obstacles =
    nudge_speed_ratio * speed_limit_from_reference_line;

7.3 PathTimeHeuristicOptimizer

非凸变凸 -> DP
动态规划
动态规划——通过把原问题分解为相对简单的子问题，再根据子问题的解来求解出原问题解的方法

状态转移方程

1.目标：产生粗糙速度规划曲线

PathTimeHeuristicOptimizer是速度规划的DP过程。速度规划需要在凸空间内求解，然而由于障碍物等原因会使求解空间变成非凸的，因此需要DP算法得到对不同障碍物的决策，从而得到一个凸空间。另一方面，最优化问题一般都仅有局部寻优能力，可能会收敛到某个局部最优解。为了保障优化问题的求解质量，使用全局“视野”的DP算法快速生成粗糙的初始解，并从该初始解的领域开展局部优化可以使最优化问题收敛到全局近似解。

SPEED_HEURISTIC_OPTIMIZER 是lanefollow 场景下，所调用的第 11个 task，属于task中的optimizer 类别，它的作用主要是：

apollo中使用动态规划的思路来进行速度规划，其实更类似于使用动态规划的思路进行速度决策；
首先将st图进行网格化，然后使用动态规划求解一条最优路径，作为后续进一步速度规划的输入，将问题的求解空间转化为凸空间

// 输入:
init_point,  path_data
// 输出
(使用speed_bounds_decider的reference_line_info_->st_graph_data())
speed_data（s, t, v）

2.流程

基于动态规划的速度规划的流程如下：
1.对路程和时间进行采样2.搜索出粗略的可行路线3.选出代价最小的一条

速度规划在ST图进行采样，在t 的方向上以固定的间隔进行采样，在s方向上以先密后疏的方式进行采样（离主车越近（10m），所需规划的精度就需更高；离主车越远，牺牲采样精度，提升采样效率）

// 时间采样的一般参数设置
unit_t: 1.0  //采样时间
dense_dimension_s: 101  // 采样密集区域的点数
dense_unit_s: 0.1   //采样密集区域的间隔
sparse_unit_s: 1.0  //采样系数区域的间隔

代码总流程如下：

1、遍历每个障碍物的boundry，判度是否有碰撞风险，如果有碰撞风险使用fallback速度规划；
2、初始化cost table
3、按照纵向采样点的s，查询各个位置处的限速
4、搜索可到达位置
5、计算可到达位置的cost
6、搜索最优路径

2.1采样：
如上
2.2状态转移方程
一个点的total_cost由四部分构成：

obstacle_cost：障碍物cost
spatial_potential_cost：空间位置cost，于终点s的差值
前一个点的total_cost
EdgeCost：边界约束由三部分构成Speedcost、AccelCost、JerkCost

在更新父节点时同样有一个剪枝操作，使用限速信息FLAGS_planning_upper_speed_limit得到pre_lowest_s，进而将寻找范围限制在[r_low, r]，其中r为当前行号，因为EM Planner主要是前进场景，不会考虑倒车情况，那么S值是递增或不变，不会下降，所以r最大也就当前行号

2.2.2.1 障碍物cost计算

S_safe_overtake超车的安全距离S_safe_follow跟车的安全距离在设计状态转移方程时，要求不能与障碍物发生碰撞以及和障碍物不发生碰撞。于是可以得到以下方程：

如果在障碍物距离之内，则cost设为无穷；如果在安全距离之外，则cost设为0；如果在安全距离与障碍物之间，则按按之间的距离计算。
2.2.2.2 距离cost计算
目的是更快的到达目的地

距离cost计算方式如下：

2.2.2.3 状态转移cost计算
状态转移cost计算分为三个部分：

越靠近0，代价值越小；越靠近目标值，代价值越大，满足舒适性与平滑性。

加加速度的计算方式如下：

7.4 SpeedDecider

产生速度决策

根据粗规划出的速度曲线，依据曲线在障碍物的上方还是下方，采取不同的决策。

// 输入：
init_point_， adc_sl_boundary_， reference_line_，
MakeObjectDecision(reference_line_info->speed_data(),
                        reference_line_info->path_decision())
// 输出：
mutable_obstacle->AddLongitudinalDecision()

SpeedDecider 是lanefollow 场景下，Apollo Planning算法所调用的第12个 task，属于task中的decider 类别它的作用主要是：

1、对每个目标进行遍历，分别对每个目标进行决策
2、或得mutable_obstacle->path_st_boundary()
3、根据障碍物st_boundary的时间与位置的分布，判断是否要忽略
4、对于虚拟目标 Virtual obstacle，如果不在referenceline的车道上，则跳过
5、如果是行人则决策结果置为stop
6、SpeedDecider::GetSTLocation() 获取障碍物在st图上与自车路径的位置关系
7、根据不同的STLocation，来对障碍物进行决策
8、如果没有纵向决策结果，则置位ignore_decision；

SpeedDecider根据DP算法生成的速度曲线s ( t ) s(t)s(t)和障碍物的STBoundary的位置关系生成Ignore、Stop、Follow、Yield、Overtake的纵向决策。

Ignore：

障碍物的STBoundary在ST Graph的范围内；
已经有纵向决策的障碍物；
类型是禁停区的obstacle的STBoundary位于速度曲线的下方；

Stop：

前方是行人的停车决策；
类型是禁停区的obstacle的STBoundary位于速度曲线的上方；
在ADC前方低速行驶的堵塞道路的障碍物；
STBoundary和速度曲线相交的障碍物；

Follow：

STBoundary位于速度曲线上方，且不需要Stop的障碍物；

Yield：

STBoundary位于速度曲线上方，且不需要Stop和Follow的障碍物；

Overtake：

STBoundary位于速度曲线下方的障碍物；
13 SPEED_BOUNDS_FINAL_DECIDER
产生速度规划边界

在障碍物的上方或下方确定可行使区域。 SpeedBoundsFinalDecider对应的Decider同样是SpeedBoundsDecider，和SpeedBoundsPrioriDecider不同的是配置参数，从Apollo中的默认配置参数来看，

7.5 SpeedBoundsFinalDecider

会根据DP过程生成的决策结果和更小的boundary_buffer生成更加精确的STBoundary。

// 输入：
const PathData &path_data = reference_line_info->path_data();
const TrajectoryPoint &init_point = frame->PlanningStartPoint();
const ReferenceLine &reference_line = reference_line_info->reference_line();
PathDecision *const path_decision = reference_line_info->path_decision();
// 输出：
std::vector<const StBoundary *> boundaries,const double min_s_on_st_boundaries,
SpeedLimit speed_limit,
st_graph_data->LoadData(boundaries, min_s_on_st_boundaries, init_point,
                        speed_limit, reference_line_info->GetCruiseSpeed(),
                        path_data_length, total_time_by_conf);

配置
// 1. Map obstacles into st graph
// 2. Create speed limit along path
// 3. Get path_length as s axis search bound in st graph
// 4. Get time duration as t axis search bound in st graph

SPEED_BOUNDS_FINAL_DECIDER 是lanefollow 场景下，所调用的第 13 个 task，属于task中的decider 类别它的作用主要是：

（1）将规划路径上障碍物的st bounds 加载到路径对应的st 图上(并且根据障碍物决策生成boundary类型)
（2）计算并生成路径上的限速信息

7.5 PiecewiseJerkSpeedOptimizer

产生平滑速度规划曲线

根据ST图的可行驶区域，优化出一条平滑的速度曲线。满足一阶导、二阶导平滑（速度加速度平滑）；满足道路限速；满足车辆动力学约束。
PIECEWISE_JERK_SPEED_OPTIMIZER 基于二次规划的速度规划
PIECEWISE_JERK_NONLINEAR_SPEED_OPTIMIZER 基于非线性规划的速度规划
两者二选一即可
速度规划的优化求解即是按照上述的算法原理实现的。
可以看到，在此会依据纵向决策结果生成纵向位移的约束边界，将每个时刻和cruise speed的误差作为优化目标的一部分，并且根据DP结果在每个时刻处位移的速度约束作为优化问题的速度约束边界，因此将每个时刻的位移和DP的位置之差作为了优化目标的一部分，但是这样只能实现速度的软约束。
PiecewiseJerkSpeedOptimizer 是lanefollow 场景下，所调用的第 14个 task，属于task中的decider 类别它的作用主要是：

1、根据之前decider决策的speed decider和 speed bound，以及纵向约束，将最优速度求解问题转化为二次型规划问题；
2、调用osqp库求解最优路径；

//输入：
PathData& path_data(get 曲率)，
common::TrajectoryPoint& init_point，
SpeedData* const speed_data
//优化变量x dx ddx 
//目标函数set_x_ref，set_dx_ref，set_weight_ddx，set_weight_dddx
//构建约束set_x_bounds，set_penalty_dx，set_dx_bounds，set_ddx_bounds，set_dddx_bound
//优化器求解piecewise_jerk_problem.Optimize()
penalty_dx.push_back(std::fabs(path_point.kappa()) *
                        config.kappa_penalty_weight());
piecewise_jerk_problem.set_penalty_dx(penalty_dx);                        


//输出：s ds dds
// Update STBoundary by boundary_type影响s上下边界
speed_data->AppendSpeedPoint(s[i], delta_t * i, ds[i], dds[i],
                            (dds[i] - dds[i - 1]) / delta_t);
配置
default_task_config: {
  task_type: PIECEWISE_JERK_SPEED_OPTIMIZER
  task_process_type: ON_REFERENCE_LINE
  piecewise_jerk_speed_optimizer_config {
    acc_weight: 1.0                # ddx
    jerk_weight: 3.0               # dddx
    kappa_penalty_weight: 2000.0   # kappa penalty_dx
    ref_s_weight: 10.0             # x
    ref_v_weight: 10.0             # dx
  }
}
default_task_config: {
  task_type: PIECEWISE_JERK_NONLINEAR_SPEED_OPTIMIZER
  task_process_type: ON_REFERENCE_LINE
  piecewise_jerk_nonlinear_speed_optimizer_config {
    acc_weight: 2.0                # ddx
    jerk_weight: 3.0               # dddx
    lat_acc_weight: 1000.0         # kappa
    s_potential_weight: 0.05       # add
    ref_v_weight: 5.0              # dx
    ref_s_weight: 100.0            # x
    soft_s_bound_weight: 1e6       # add
    use_warm_start: true           # add
  }
}

动态规划得到的轨迹还比较粗糙，需要用优化的方法对轨迹进行进一步的平滑。基于二次规划的速度规划的方法与路径规划基本一致。

确定优化变量
设计目标函数
设计约束

二次规划

这些成员函数之间的相互依赖关系见下图，其中Optimize( )是入口
调用FormulateProblem( )完成二次规划问题的建模，针对二次规划问题CalculateKerne( )完成目标函数中的H矩阵计算，CalculateOffset( )完成目标函数中的g矩阵计算，CalculateAffineConstraint( )完成约束条件中的A矩阵计算
最后借用osqp求解器完成求解

1.1.确定优化变量

1.2设计目标函数
对于目标函数的设计，我们需要明确以下目标：

1.3.要满足的约束条件

1.4.转化为二次规划问题求解

代入OSQP求解器进行求解，输出一条平稳、舒适、能安全避开障碍物并且尽快到达目的地的速度分配曲线。
二次规划速度规划算法的问题

基于二次规划的速度规划中，p i 是曲率关于时间t tt的函数，但实际上路径的曲率是与s 相关的。二次规划在原先动态规划出来的粗糙ST曲线上将关于s 的曲率惩罚转化为关于t 的曲率惩罚，如此，当二次规划曲线与动态规划曲线差别不大，规划出来基本一致；若规划差别大，则会差别很大。就如图所示，规划出来的区间差别较大。限速/曲率的函数是关于s 的函数，而s 是我们要求的优化量，只能通过动态规划进行转化，如此就会使得二次规划的速度约束不精确。
二次规划与非线性的选择：
二次规划在dp的ST曲线基础上将关于s的曲率惩罚转化为关于t的曲率惩罚，导致对于道路限速的反应不准确，如下图，sv图，绿线是地图实际限速，蓝线为二次规划求解所得。但是求解效率高。
非线性优化主要考虑曲率的约束，惩罚是关于s的函数，对于限速和曲率是更加准确和严格的；二次规划是关于t的函数，从dp的st图转化过来的，是对t的约束

非线性优化

// 输入：
scont PathData& path_data，const common::TrajectoryPoint& init_point SpeedData* const speed_data


const auto problem_setups_status = SetUpStatesAndBounds(path_data, *speed_data);
const auto qp_smooth_status = OptimizeByQP(speed_data, &distance, &velocity, &acceleration, st_graph_data->mutable_st_graph_debug());
const auto speed_limit_smooth_status = SmoothSpeedLimit();
const auto nlp_smooth_status =OptimizeByNLP(&distance, &velocity, &acceleration);
 
// 输出：
x,dx,ddx
speed_data->AppendSpeedPoint(
    distance[i], delta_t_ * i, velocity[i], acceleration[i],
    (acceleration[i] - acceleration[i - 1]) / delta_t_);

2.1优化变量
基于非线性规划的速度规划步骤与之前规划步骤基本一致。

采样方式：等间隔的时间采样。s l o w e r s_{lower}与 s_{upper}为松弛变量，防止求解失败。
2.2目标函数

2.3制定约束

将所有的限速函数相加，得到下图的限速函数，很明显，该函数既不连续也不可导，所以需要对其进行平滑处理。

对于限速曲线的平滑，Apollo采样分段多项式进行平滑，之后采样二次规划的方式进行求解。限速曲线的目标函数如下：

如此，我们就有了连续且可导的限速曲线。再回到约束中,为了避免求解的失败，二次规划中对位置的硬约束，在非线性规划中转为了对位置的软约束。提升求解的精度。

同时还需满足基本的物理学原理

2.4求解器求解
最后代入Ipopt中进行非线性规划的求解。 Ipopt（Interior Point Optimizer）是一个用于大规模非线性优化的开源软件包。它可用于解决如下形式的非线性规划问题：

Apollo星火计划学习笔记——Apollo速度规划算法原理与实践
https://blog.csdn.net/sinat_52032317/article/details/128456949

8. CombinePathAndSpeedProfile

将SL曲线、ST曲线合成为完整轨迹，之后作为Planning的输出。

8.1 trajectory plan

更好的位形组成在上面的3个变量基础上加入车辆的即时转向曲率κ：如果车辆的导向轮保持一定的角度，车辆会做圆周运动。这个圆周运动的半径就是即时转向曲率 κ。加入κ，有助于控制模块获得更准确的控制反馈，设计更为精细平稳的控制器。
轨迹规划的正式定义，计算一个以时间t为参数的函数S，对于定义域内（[0, t_max]）的每一个t，都有满足条件的状态 s：满足目标车辆的运动学约束，碰撞约束，以及车辆的物理极限。

https://www.cnblogs.com/liuzubing/p/11051390.html

8.2 FallBack

GenerateFallbackPathBound
fallback是其他3种场景计算PathBound失败时的备选，只考虑自车信息和静态道路信息，不考虑静态障碍物。因此，speed decider负责让自车在障碍物前停车。

Status PathBoundsDecider::GenerateFallbackPathBound(
    const ReferenceLineInfo& reference_line_info, PathBound* const path_bound) {
  // 1. Initialize the path boundaries to be an indefinitely large area.
  if (!InitPathBoundary(reference_line_info, path_bound)) { ... }
  // 2. Decide a rough boundary based on lane info and ADC's position
  std::string dummy_borrow_lane_type;
  if (!GetBoundaryFromLanesAndADC(reference_line_info,
                                  LaneBorrowInfo::NO_BORROW, 0.5, path_bound,
                                  &dummy_borrow_lane_type)) { ... }
  return Status::OK();
}

GenerateFallbackSpeed

SpeedData SpeedProfileGenerator::GenerateFallbackSpeed(
    const EgoInfo* ego_info, const double stop_distance)
// s的最大范围应该符合车辆动力学，即车辆按照最大a和da进行刹车时，车辆在此范围内可以停下来，否则会造成优化问题无解
// 对于乘用车来说100m的刹车距离是足够了

#Hydra-MDP++

英伟达：基于专家引导的Hydra-Distillation推进端到端驾驶

论文链接：https://arxiv.org/pdf/2503.12820
项目链接：https://github.com/NVlabs/Hydra-MDP

摘要

本文介绍了Hydra-MDP++：基于专家引导的Hydra-Distillation推进端到端驾驶。Hydra-MDP++引入了一种新的教师-学生知识蒸馏框架，该框架具有多头解码器，它可以从人类演示和基于规则的专家处学习。该框架使用没有复杂组件的轻量级ResNet-34网络，并且加入了扩展的评估指标（包括交通信号灯合规性（TL）、车道保持能力（LK）和扩展舒适性（EC）），以应对传统的NAVSIM-derived教师无法捕获的不安全行为。与其它端到端自动驾驶方法一样，Hydra-MDP++直接处理原始图像，而不依赖于感知信号。Hydra-MDP++通过集成那些在NAVSIM上具有91.0%驾驶得分的组件，实现了最先进的性能，结果证明了其在维持计算效率的同时能够有效地处理各种驾驶场景。

主要贡献

本文的贡献总结如下：

1）本文引入了Hydra-MDP++，这是一种新型的端到端自动驾驶框架，它结合了人类演示和基于规则的专家；

2）本文所提出的方法仅使用轻量级ResNet-34网络在NAVSIM上实现了最佳的性能。Hydra-MDP++通过将图像编码器扩展为V2-99，实现了91.0%的驾驶得分；

3）本文通过加入交通信号灯合规性（TL）、车道保持能力（LK）和扩展舒适性（EC）教师来解决NAVSIM-derived教师中的问题，以反映更好的驾驶决策。

论文图片和表格

总结

本文提出了Hydra-MDP++，这是一种最先进的端到端运动规划器，旨在结合基于规则的方法和神经规划方法的优势。Hydra-MDP++通过学习大量的人类驾驶演示和基于规则的专家提供的理解，能够更有效地在复杂环境中导航。为了解决现有评估指标的不足，本文扩展了教师模型以包括关键方面，例如交通信号灯合规性、车道保持能力和扩展舒适性。这种综合方法确保了驾驶场景中的决策过程鲁棒、适应性强并且符合安全标准。

#对下一代自动驾驶架构的思考

随着Tesla全面转向端到端技术路线并终止AI Day开放分享，全球自动驾驶行业陷入技术演进路径的真空期。在此背景下，理想汽车自2023年起通过「理想科技日」逐步确立国内技术标杆地位——其首创的行业级技术布道平台，成功构建起中国智能驾驶发展的新型知识枢纽。

2024年，理想汽车基于卡尼曼「快思考-慢思考」认知模型，率先提出端到端大模型与视觉语言模型（VLM）的双系统协同架构，为行业提供了首个可落地的类人驾驶技术框架。今年更迭代推出革命性Vision-Language-Action（VLA）模型MindVLA，开创智能体认知新范式。该架构依托三大核心能力重塑自动驾驶边界：

空间智能：通过多模态融合实现厘米级3D场景解构
因果推理：构建驾驶决策的符号逻辑演绎链条
行为涌现：基于环境反馈的自适应策略生成机制

「理想汽车发布下一代自动驾驶架构MindVLA」，2025年3月18日，理想汽车自动驾驶技术研发负责人贾鹏在NVIDIA GTC 2025发表主题演讲《VLA：迈向自动驾驶物理智能体的关键一步》，分享了理想汽车对于下一代自动驾驶技术MindVLA的最新思考和进展。

理想汽车高调推出的MindVLA模型，究竟是革命性突破还是技术迁移实验？答案或许介于两者之间。需明确的是，视觉-语言-动作模型（Vision-Language-Action, VLA）并非自动驾驶原生技术，其本质是机器人领域技术范式的跨界延伸。让我们穿透营销迷雾，回归技术演进本质：

技术基础铺垫

VLM（视觉语言模型）的兴起：2015-2022年间，视觉问答系统（VQA）、CLIP、ViT等技术的发展，奠定了多模态融合的基础，使机器能同时理解图像与语言。
机器人控制技术的积累：强化学习（如DQN、PPO）和轨迹编码技术的成熟，为动作生成提供了方法论支持。

早期尝试
RT-1的突破：2023年3月，谷歌DeepMind推出RT-1（Robotic Transformer 1），首次将预训练的视觉语言模型应用于机器人动作生成，但泛化能力有限。
RT-2的里程碑意义
2023年7月：谷歌DeepMind发布RT-2（Robotic Transformer 2），首次明确VLA范式。该模型通过互联网规模的视觉-语言数据训练，支持自然语言指令直接生成动作序列，显著提升泛化能力（如处理未见过的物体和场景）。
核心技术突破：引入“思维链”机制，结合语言模型的推理能力与机器人轨迹数据，实现长期规划与低级技能融合。
开源与扩展
OpenVLA开源项目：2024年6月，斯坦福、伯克利等机构联合推出OpenVLA，基于7B参数的Llama 2和SigLIP视觉编码器，推动VLA技术标准化与普及。
3D-VLA的演进：2024年，麻省理工与伯克利团队提出3D-VLA，引入三维空间表征技术，增强复杂场景的几何感知能力，解决二维模型的局限性。
工业与家庭场景落地
Figure公司的Helix模型：2025年2月，Figure发布支持多机器人协作的VLA模型Helix，采用“系统1（高频控制）+系统2（语义决策）”双架构，实现低功耗、高泛化的家庭服务机器人。
特斯拉人形机器人Optimus：结合VLA技术优化动作生成，提升对动态环境的适应性，推动具身智能商业化7。
技术细分与分层架构
分层端到端VLA：2024年后，研究重点转向结合大模型泛化能力与小模型执行效率的混合架构，如TinyVLA通过模型压缩降低算力需求。
多模态数据集推动：谷歌开放X-Embodiment数据集（含160万条多机器人任务数据），加速VLA模型的训练与迭代。

随着VLA神秘面纱的揭开，那么我们迎来了自动驾驶的终极之问：VLA真的是打开大门的万能钥匙吗？

在自动驾驶的竞技场上，全球头部玩家正以截然不同的技术哲学展开角力：

Tesla：BEV→Occ→E2E的颠覆之路

BEV革命：通过鸟瞰图视角统一多传感器数据，打破传统前视图感知的局限
Occ跨越：占据网络（Occupancy Network）实现对未知障碍物的三维空间建模，解决长尾场景覆盖难题
端到端终局：从感知到控制的直接映射，2024年FSD V12已实现纯神经网络驱动

小鹏：中国版Tesla的技术复刻
跟随战略：XNGP系统高度对标Tesla技术架构，BEV+Transformer成为标配
本土化改良：针对中国复杂路况优化博弈算法，但核心框架仍受制于技术路径依赖
华为：稳中求胜的渐进主义
车云协同架构：ADS 2.0采用云端大模型与车端小模型协同，确保安全冗余
高精地图依赖：在无图化浪潮中保持谨慎，通过多模态融合弥补感知短板
理想：VLA范式的激进突围
认知科学赋能：基于卡尼曼双系统理论构建MindVLA模型，分离直觉式反应（快思考）与深度推理（慢思考）
三维空间智能：通过VLA架构实现环境理解、逻辑推演与动作生成的端到端闭环

当前自动驾驶行业正陷入两大核心矛盾：

Tesla的技术霸权与跟随者困境

算力鸿沟：Dojo超算集群提供1.1EFLOPS算力，远超国内车企（理想自建算力仅120PFLOPS）
数据飞轮碾压：Tesla 800万辆量产车日均采集数据量超国内玩家年度总和
伪端到端乱象：部分企业将传统模块化系统包装为“分段式端到端”，实为营销概念游戏

VLA的技术泡沫质疑
推理延迟瓶颈：当前VLA模型（如MindVLA）在Jetson AGX Orin平台需300ms响应时间，难以满足紧急制动需求
虚实鸿沟难题：仿真环境训练出的逻辑推理能力，在真实交通场景中出现高达37%的决策偏差
成本悖论：搭载VLA系统的域控制器成本增加4000元，与车企降本诉求直接冲突

要判断VLA的技术价值，需回归三个根本问题：

认知架构突破vs工程优化

VLA带来的“类人思考”是否真能解决Corner Case，还是仅将问题从代码层转移至模型黑箱？

技术路径的不可逆性
当Tesla用纯视觉端到端实现城市NOA 99.9%场景覆盖时，多模态架构是否仍有存在必要？
商业落地的时间窗口
在2025年L3法规落地前，VLA能否完成从实验室到量产的致命一跃？

破局之路：实现真·自动驾驶的四大支柱

认知架构的重构

双系统协同：借鉴人脑决策机制，构建快响应（System 1）与慢思考（System 2）的混合架构
案例：理想MindVLA通过视觉语言大模型处理常规场景，符号逻辑引擎应对交通规则冲突

数据-算力-算法的三角进化
数据民主化：建立跨企业数据联盟，破解Tesla的数据垄断（如中国汽车数据共享联盟）
算力平民化：基于国产芯片（如地平线征程6）开发量化版VLA模型，推理效率提升5倍
仿真-实车的闭环验证
4D仿真革命：通过时空一致性建模，将VLA训练效率提升80%（理想DrivingSphere实测数据）
影子模式升级：在量产车部署决策对比系统，持续优化VLA在真实场景中的泛化能力
成本-性能的平衡艺术
模块化部署：将VLA拆分为云端预判与车端执行，降低硬件依赖
功能分级激活：基础版提供车道保持，高阶版通过OTA解锁城市NOA，实现技术价值分层变

终局判断：没有银弹，唯有进化

VLA不是自动驾驶的终极答案，而是认知革命的关键台阶：

短期（2024-2026）：VLA将主要解决特定场景的推理瓶颈（如施工区绕行决策）
中期（2027-2030）：与神经符号AI融合，形成可解释、可审计的混合架构
长期（2030+）：融入具身智能体系，成为智慧城市交通网络的细胞单元

当技术狂热退潮，唯有那些在架构创新、工程实现、商业落地间找到平衡点的玩家，才能最终摘下自动驾驶圣杯上的明珠。

#Chain of Draft

思维链再进化！极简推理范式：推理token爆砍80%~

目前来看，虽然思维链提示提升了复杂任务的准确性，却因冗长的推理步骤导致高昂的计算成本与延迟，严重制约了 LLM 在实时场景中的落地应用。本文创新性的提出了极简推理范式Chain-of-Draft（CoD），通过模拟人类提炼关键信息的草稿思维，将中间推理步骤压缩至极致，仅用 20% 的 token 量，在 GSM8K 等基准测试中实现与 CoT 相当甚至更高的准确率，同时将延迟降低达 76.2%！

写在前面&笔者的个人理解

最近推理模型如OpenAI o1以及DeepSeek R1等方面的最新进展推动了大语言模型在使用诸如思维链CoT等相关技术在复杂任务上取得了前所未有的表现。这种范式鼓励模型将问题分解为逐步的探索，模仿人类的结构化推理过程。

尽管这类过程取得了不错的结果，但是在推理的过程中需要更多的计算资源，导致输出冗长和更高的延迟。这种冗长的回答方式与人类通常解决问题的方式形成了鲜明的对比，即我们依靠简洁的草稿或速记笔记来捕捉重要见解，而无需不必要的阐述。

受此差异的启发，我们提出了 Chain of Draft (CoD)，这是一种新颖的提示策略，通过优先考虑效率和极简主义，更贴近人类推理。Chain of Draft 鼓励 LLM 在每个步骤生成简洁、信息密集的输出，而不是冗长的中间步骤。这种方法在不牺牲准确性的情况下减少了延迟和计算成本，使 LLM 更适用于效率至关重要的实际应用。

Chain of Draft背后的直觉根植于人类如何将思想外化。在解决复杂任务时，无论是解决数学问题、起草论文还是写代码，我们通常只记下有助于我们执行操作的关键信息。通过模仿这种行为，LLM可以专注于寻求解决方案，而无需进行冗长的推理。

为了评估 Chain of Draft 的有效性，我们在各种需要多步推理的基准上进行了实验，包括算术推理、常识推理和符号推理。我们的结果表明，与标准 Chain of Thought 相比，这种极简方法保持甚至提高了准确性，同时显著减少了 token 的使用和延迟。

论文链接：https://arxiv.org/pdf/2502.18600v2。

Chain-of-Draft 提示

思维链 (CoT) 提示策略已在各种任务中表现出显著的有效性，特别是那些需要复杂的多步骤推理的任务。然而，LLM 通常会产生过于冗长的推理步骤，在得出最终答案之前会消耗大量的 token。相比之下，人类在解决涉及多步骤推理的复杂问题（例如数学或逻辑谜题）时倾向于采用更简洁的方法。人类通常不会详细阐述每一个细节，而是只记下必要的中间结果以促进他们的思维过程。受这种自然倾向的启发，我们提出了一种名为 Chain-of-Draft (CoD) 的新颖提示策略。这种方法旨在通过限制每个推理步骤中使用的单词数量来减少冗长，只关注过程所需的基本计算或转换。

为了说明标准提示、思维链CoT提示以及我们提出的CoD提示，请考虑以下的这个简单的算术问题。

Q：杰森有 20 根棒棒糖。他给了丹尼一些棒棒糖。现在杰森有 12 根棒棒糖。杰森给了丹尼多少根棒棒糖？

标准提示方法生成的响应直接输出答案，通常无需任何推理。虽然正确，但这缺乏答案得出方式的透明度，并且需要语言模型在没有任何中间结果帮助的情况下运行多步推理，这通常会导致幻觉，如下图所示。

另一方面，思维链提示CoT提供了详细的推理过程。虽然这种回答准确且可解释，但它包含有关 Jason、Denny 和棒棒糖的不必要的细节，这些细节与解决数学问题无关。这种冗长的内容会增加 token 数量并增加响应延迟，如下图所示。

相比之下，Chain-of-Draft 提示将推理过程浓缩为最小的抽象表示。在这里，推理被提炼为一个简洁的方程式，仅关注得出解决方案所需的基本数学运算。通过抽象出不相关的上下文细节，CoD 显著减少了 token 数量，同时保持了透明度和正确性，具体过程如下所示。

实验结果

在实验过程中，我们遵循原始 CoT 论文对 3 类任务进行评估：算术推理、常识推理和符号推理。我们选择具有代表性的任务，其中原始 CoT 在没有推理的情况下显著提高了基线的准确性。具体来说，我们选择 GSM8k用于算术推理；选择 BIG-bench中的日期理解和体育理解用于常识推理；并选择 CoT 论文中介绍的硬币翻转任务用于符号推理。

在实验过程中，我们比较了三种不同的提示策略：CoT、CoD 和标准提示作为基准。

在标准提示的实验中，我们使用标准的少样本进行提示，其中模型被赋予输入-输出对作为上下文示例。要求LLM直接返回最终答案，而无需任何推理或解释。在CoT提示的实验中，我们遵循了CoT论文中提供的精确少样本示例，但为了更稳定答案提取，我们将最终的答案放在了####之后。在CoD提示的实验中，我们也要求模型逐步思考。但是，要求模型将每个推理步骤限制为最多五个单词。请注意，我们不会以任何方式强制执行这种限制，这只是促进简短推理步骤的一般准则。对于每个少样本示例，我们还包括人工编写的CoD。

每种提示策略的完整系统提示如下所示。

我们使用两个最受欢迎的模型来评估了每个任务：OpenAI的GPT-4o和Anthropic的Claude 3.5 Sonnet。

算术推理

我们首先考虑衡量 LLM 算术推理能力的数学问题。GSM8k已成为评估语言模型中算术推理的首选基准，提供了 8,500 个不同的小学水平数学问题的综合数据集。每个问题都配有详细的分步解决方案，强调算术、几何、代数和逻辑推理技能。

评估的结果如下表所示。可以看出，在使用标准提示时，该数据集对 GPT-4o 和 Claude 3.5 Sonnet 都提出了重大挑战，准确率分别是53.3%和64.6%。然而，随着 CoT 的应用，两个模型的准确率都超过了 95%，尽管每次响应需要生成大约 200 个 token。相比之下，CoD 使两个模型的准确率都达到了 91%，而每次响应只需要大约 40 个 token，从而将平均输出 token 数量减少了 80%，并将平均延迟分别减少了76.2%和48.4%。

常识推理

我们从 BIG-bench 评估了日期理解和体育理解任务，以证明 CoD 在常识推理中的有效性。为了保持一致性，我们使用与算术推理评估中相同的系统提示。

下表汇总了评估结果，可以看出，与 CoT 相比，CoD 通过在响应中生成更少的token，显著降低了延迟和成本。此外，CoD 在各种情况下的准确性都优于 CoT。值得注意的是，思维链提示会导致 Claude 3.5 Sonnet 的响应过于冗长，尤其是在体育理解任务中，CoD 将平均输出token从189.4 减少到14.3，减少了 92.4%。

符号推理

原始 CoT 论文介绍了抛硬币的任务，要求 LLM 在一系列抛硬币动作之后预测哪一面朝上。由于确切的数据集尚未发布，我们按照相同的设计合成了一个包含 250 个示例的测试集。评估数据的示例如下图所示。

GPT-4o 和 Claude 3.5 Sonnet 的评估结果如下表所示。它们在标准提示下分别达到 73.2% 和 85.2%。然而，这两个模型在 CoT 和 CoD 上都达到了完美的 100% 准确率。同样，与 CoT 相比，CoD 显示出显著的 token 减少，从 GPT-4o 的 68% 减少到 Claude 3.5 Sonnet 的 86%。

CoD的限制

我们评估了零样本设置下 CoD 的性能，其中没有提供少样本示例。下表中显示的结果显示 CoD 的有效性显著下降。值得注意的是，对于 Claude 3.5 Sonnet，CoD 的性能仅比直接回答提高了 3.6%。此外，与少样本设置相比，CoD 实现的 token 节省并不那么显著。我们假设这种限制是由于大型语言模型的训练数据中 CoD 式推理模式的稀缺或缺失造成的，这使得在没有少样本示例指导的情况下生成简洁而有见地的“草稿”是一项艰巨的任务。

此外，我们在几个参数少于 3B 的小型语言模型上测试了 CoD，包括 Qwen2.5 1.5B/3B instruct、Llama 3.2 3B instruct和我们内部的 Zoom SLM 2.3B 模型。虽然 CoD 有效地减少了每个响应所需的token数量并提高了直接回答的准确性，但与 CoT 相比，其性能差距在这些模型中更为明显。与零样本设置类似，我们怀疑这是由于训练过程中缺乏 CoD 样式的数据。我们预计，使用额外的 CoD 格式数据对这些模型进行微调可以显着提高它们使用 CoD 的推理准确性。

讨论

在研究 LLM 的推理能力时，延迟问题经常被忽视。然而，对于许多实时应用程序来说，在保持高质量响应的同时保持低延迟是至关重要的。在这项工作中，我们提出了 Chain-of-Draft (CoD)，这是一种新颖的方法，它大大减少了推理所需的延迟，同时实现了与标准 Chain-of-Thought 提示策略相当甚至更高的准确性。与通常涉及冗长推理步骤的传统方法不同，CoD 利用简洁的推理草稿来加快响应生成速度，而不会牺牲正确性。此外，CoD 还具有显着的成本优势。通过压缩推理步骤，它减少了小样本提示所需的输入 token 数量并缩短了输出 token 长度，直接降低了计算成本。这种 token 效率使 CoD 在成本敏感的场景中特别有吸引力，例如大规模部署 LLM 或预算严格受限的应用程序。

CoD 表明 LLM 中的有效推理并不一定需要冗长的输出，它提供了一种替代方法，即以最少的冗长程度保持推理深度。未来的工作可以探索将 CoD 与其他减少延迟的方法相结合，以进一步优化不同应用领域的性能。此外，CoD 紧凑推理背后的原理可以启发新的策略，通过使用紧凑的推理数据进行训练来改进推理模型，同时保持 LLM 的可解释性和效率，帮助弥补研究驱动的推理改进与现实世界系统的实际需求之间的差距。

#sim-to-real

UC Berkeley最新！将sim-to-real的强化学习应用于视觉人形机器人灵巧操作！

深度强化学习是深度学习与强化学习相融合的产物。深度学习具备强大的感知和特征提取能力，能够处理图像、语音等复杂数据；强化学习则基于环境反馈让智能体通过试错来学习最优行为策略。二者结合，使得智能体可以在复杂环境下，从高维数据中学习到有效的决策策略。这么好的东西，为什么不用于机器人灵巧操作任务训练？

用力过猛？频繁出错？分分钟EMO

结果有人一试发现，在训练人形机器人执行如双手机器人移交任务时，近端策略优化算法中的学习率、折扣因子等超参数取值的微小改变，会使机器人在抓取、移交物体动作的准确性和流畅性上有显著差异。并且，同样以双手机器人移交任务为例，在相同的实验环境、代码和初始条件下，多次运行深度强化学习算法，每次训练得到的机器人操作策略和最终任务完成成功率都可能不同。有时机器人能较为顺利地完成移交任务，成功率较高；而有时则频繁出错，成功率很低。

此外，在模拟人形机器人抓取不同形状、材质的物体时，比如模拟抓取表面光滑的金属块和表面粗糙的木块，仿真可能无法完全还原真实的抓取难度差异，导致在仿真中训练好的抓取策略在现实中效果不佳。同时，设计奖励函数也很困难。以抓取任务为例，简单地以是否成功抓取作为奖励，机器人可能会学习到一些不规范的抓取动作，如用力过猛损坏物体或抓取姿势不稳定。

然而，它存在一些自身问题，并在机器人应用场景中面临额外挑战：深度强化学习存在对超参数敏感的问题，超参数的微小变化可能导致模型性能大幅波动，增加了调优难度；其可重复性存疑，相同实验设置下多次运行结果可能不同，不利于研究成果的验证和推广；在机器人应用场景中，还面临环境建模不精确的难题，难以准确模拟现实环境的复杂性，以及奖励函数设计困难的问题，难以制定合理有效的奖励机制引导智能体学习，同时在高维动作和感知空间中探索效率较低，学习过程缓慢。

针对以上问题，“Sim-to-Real Reinforcement Learning for Vision-Based Dexterous Manipulation on Humanoids” 一文提出了将仿真到现实（sim-to-real）的强化学习应用于基于视觉的人形机器人灵巧操作的方法，通过解决环境建模、奖励设计、策略学习和仿真到现实转换等方面的挑战，使机器人能够在现实世界中完成多种灵巧操作任务。具体如下：

环境建模难题：仿真环境与现实环境难以精准匹配，使用物理硬件训练成本高且风险大，而以往灵巧操作的仿真到现实工程工作繁琐且针对性强。文章提出自动化的Real-to-Sim调优模块，自动搜索参数空间优化模拟器物理参数和机器人模型常数，快速校准参数使模拟环境更接近真实情况，同时采用近似物体建模，将物体简化为基本几何形状，平衡训练效率和策略迁移能力。
奖励设计困境：对于接触丰富或长时程的灵巧操作任务，设计通用的奖励函数非常困难，传统依赖专家知识的手工工程方法可扩展性差。文章提出将任务分解为“接触目标”和“物体目标”的通用奖励设计方案，使用基于关键点的技术，在物体表面设置“接触贴纸”来指定接触目标，简化奖励工程复杂性，使复杂任务可通过强化学习有效学习。
策略学习困境：在高维空间中，由于样本复杂性和奖励稀疏性，策略学习困难，多指手操作的复杂接触模式加剧了该问题。文章提出两种技术改进，一是利用任务感知的手部姿势初始化任务，收集人类相关数据作为初始状态，减少探索难度；二是将复杂任务分解为子任务，训练专家策略后蒸馏为通用策略，提高样本效率和策略泛化能力。
物体感知难题：物体感知在操作任务中至关重要，但物体形状、大小、质量等属性多样，高维物体表示虽信息丰富但仿真到现实差距大，低维表示则难以学习最优策略。文章提出混合使用低维的3D物体位置和高维的深度图像来表示物体，并对高维特征进行数据增强，减少感知差距，同时应用域随机化技术，确保策略在不同环境下的鲁棒性。

哪些深度强化学习的工作值得follow？

在深度强化学习应用方面，其在多领域成果显著，但自身存在对超参数敏感、可重复性存疑的问题（Henderson 等，2018; Islam 等，2017）。在机器人应用场景中，面临探索效率低、环境建模不精确、奖励函数设计困难等挑战（Bellemare 等，2013; Tassa 等，2018）。过去的研究提出了学习人类运动数据（Rajeswaran 等，2017; Yin 等，2025; Chi 等，2023; Zhu 等，2018）、实仿技术（Akkaya 等，2019; Haarnoja 等，2024; Handa 等，2023; Lin 等，2024; Torne 等，2024）和更合理的奖励设计方法（Memmel 等，2024; Zhang 等，2024）等缓解措施，为本文研究奠定了基础。

在基于视觉的人形机器人灵巧操作方面，模仿学习和经典方法依赖遥操作或人类演示数据，成本高昂（Levine 等，2018; Fanqi 等，2024; Tony 等，2024）。强化学习方法虽有应用，但存在假设单手持操作、不使用像素输入或专注单一技能等局限（Akkaya 等，2019; Yuanpei 等，2023; Handa 等，2023; Tyler 等，2024; Haozhi 等，2023; Ritvik 等，2024; Jun 等，2024）。与本文最接近的 Chen 等人的研究（Yuanpei 等，2024），依赖人类手部运动捕捉数据学习手腕控制器，并非从头学习手 - 臂关节控制。而本文首次成功将基于视觉的灵巧操作策略从仿真转移到新型多手指人形机器人硬件上。

模型架构

文章图2展示了基于视觉的灵巧操作的仿真到现实强化学习流程，涵盖环境建模、奖励设计、策略学习和视觉仿真到现实转换等关键模块，各模块协同工作以实现人形机器人的灵巧操作。

自动现实到仿真调优模块：现实与仿真环境难以匹配，该模块旨在解决这一问题。它通过自动搜索参数空间，快速校准模拟器物理参数和机器人模型常数。具体来说，先从制造商提供的机器人模型文件出发，随机采样参数组合初始化多个模拟环境，接着在真实机器人硬件和模拟环境中并行执行关节位置目标的校准序列，通过比较跟踪误差，选择能最小化均方误差的参数集，从而优化机器人和环境的建模，减少手动调优的工作量，提高仿真与现实的契合度。

可泛化奖励设计：将操作任务分解为“接触目标”和“物体目标”，以此为基础设计奖励函数。利用基于关键点的技术，在物体表面生成“接触贴纸”来指定接触目标，根据手指与接触点的距离计算接触奖励；通过惩罚物体当前状态与目标状态的距离来设定物体目标奖励。例如在双手交接任务中，依据不同阶段的接触和物体状态变化来分配奖励，引导机器人完成任务。

样本高效策略学习

任务感知手部姿势初始化：通过连接遥操作系统收集人类的任务感知手部姿势数据，包括物体姿态和机器人关节位置，将这些数据随机采样作为仿真中的任务初始化状态，降低策略学习的探索难度，减少数据收集时间。

分治蒸馏：把复杂任务分解为简单子任务，如将多物体操作任务拆分为多个单物体操作任务，为每个子任务训练专家策略，再将这些策略蒸馏为通用策略。同时，可根据子任务策略的最优性筛选轨迹数据，提高样本质量和训练效率。

基于视觉的仿真到现实转换

混合物体表示：结合低维的3D物体位置和高维的深度图像表示物体。3D物体位置由第三方视角相机获取，确保物体在视野内且位置可追踪；深度图像提供物体几何信息，二者结合平衡了信息丰富度和仿真到现实的差距，提升策略从仿真到现实的可转移性。

域随机化：对动力学和感知进行多种域随机化处理，如随机化物体的摩擦、质量、尺度，施加随机力模拟物理效果，以及对观测和动作中的噪声进行建模，增强策略在不同环境下的鲁棒性，确保可靠的仿真到现实转换。

实验

实验设置

实验采用Fourier GR1人形机器人，其配备两个7自由度的手臂和不同类型的多手指手，如Fourier手和Inspire手，以测试跨实体的通用性。实验中的具体任务包括：

（1）抓取 - 到达任务，要求机器人用一只手抓取桌面上的物体并移动到目标位置，测试物体具有多种形状、质量等属性，每次试验会改变物体的初始位置、方向和目标位置；

（2）箱子提升任务，机器人需要提升太大而无法单手握持的箱子，箱子的颜色、大小和质量随机变化，每次试验随机设置箱子的初始位置和垂直轴方向；

（3）双手机器人移交任务，机器人要从桌子一侧用一只手抓取物体，然后交给另一只手，物体的颜色、尺寸和质量多样，每次试验的物体初始位置和方向也会变化。

实验结果

研究发现自动调优模块的均方误差（MSE）与仿真到现实的成功率相关。在抓取 - 到达任务中，对三组使用不同机器人建模参数（由自动调优模块得出不同MSE）的策略检查点进行测试，结果显示MSE越低，仿真到现实的转移成功率越高。例如，MSE最低的一组，抓取成功率为8/10，到达成功率为7/10；而MSE最高的一组，抓取和到达成功率均为0/10。

图4对比了使用不同物体集训练抓取 - 到达策略的情况。结果表明，将物体建模为简单几何原语（如圆柱体、立方体和球体）在训练效率和仿真到现实的转移性之间能达到较好平衡。从训练曲线看，使用简单几何物体训练的策略比使用复杂物体训练的策略样本效率更高。此外，用随机化简单几何物体训练的策略，能泛化到多种未见物体。

以箱子提升任务为例，展示了不同接触标记放置下出现的不同接触行为。结果显示，接触行为与指定的接触位置紧密对齐，表明使用接触标记来指定接触目标是有效的，为奖励设计中基于接触目标的设定提供了支持。

表2对比了有无任务感知手部姿势初始化时各任务成功训练策略的百分比。结果表明，有人类先验知识进行初始化能显著提高困难强化学习任务的探索效率。如抓取任务，有人类初始化时成功率为80%，无人类初始化时为60%；双手移交任务，有人类初始化时成功率为30%，无人类初始化时为0%。

表3比较了基于深度和位置的策略（Depth + Pos）与仅基于深度的策略（Depth Only）的仿真到现实转移性能。在抓取、提升和双手移交等任务中，结合低维3D物体位置和深度的策略（Depth + Pos）在仿真到现实的转移上表现更优。例如，在双手移交任务的不同阶段，“Depth + Pos”策略的拾取成功率和任务成功率均高于“Depth Only”策略。

图 6 展示了人形机器人在不同任务中，面对各种力扰动时所学习到的策略的鲁棒性实验结果。在抓取 - 到达、箱子提升和双手机器人移交等任务中，机器人在遭遇如撞击、拉扯、推挤和拖拽等外力干扰时，仍能保持较好的操作表现，体现出策略的鲁棒性。

总结与展望

文章提出了一套完整的应用于人形机器人基于视觉的灵巧操作的仿真到现实强化学习方法，解决了环境建模、奖励设计、策略学习和仿真到现实转换中的关键挑战，证明强化学习可有效学习操作技能，且策略具有良好的泛化性、鲁棒性，能完成复杂任务。但研究仍存在不足，虽然提出的技术构建了可行的仿真到现实强化学习流程，实现了一定的泛化性、鲁棒性和灵巧性，但仍与人类的通用操作能力存在差距。奖励设计可融入更多人类先验，如遥操作任务演示；在动力学仿真到现实的差距上，仅用简单域随机化，可能是双手机器人移交任务成功率低的原因；还受限于现有硬件的灵巧性，未来期望应用于更先进的机器人手。

参考文献

Sim-to-Real Reinforcement Learning for Vision-Based Dexterous Manipulation on Humanoids
https://arxiv.org/pdf/2502.20396

https://toruowo.github.io/recipe/

https://huggingface.co/papers/2502.20396

第一作者：https://toruowo.github.io/

通讯作者：https://people.eecs.berkeley.edu/~malik/

51c自动驾驶~合集26

#大模型/Sora/世界模型之间是什么关系

#HRMapNet

#GaussianPU

#Hint-AD

#LM-Gaussian

#将 MOE 塞到 LoRA

#宝马利润暴跌83%

#智驾无图真的可以实现吗？

#端到端自动驾驶通用感知架构的前世今生

#李斌内部讲话详解组织变革

#ChatBEV

#面向感知的决策规划介绍

#Hydra-MDP++

#对下一代自动驾驶架构的思考

#Chain of Draft

#sim-to-real

网站公告

今日签到

热门文章

最新发布