本文经自动驾驶之心公众号授权转载，转载请联系出处。
自动驾驶系统架构转变思考
从事辅助驾驶系统架构一段时间后，感觉到了疲惫和无力感，更加深刻的理解到道德经，道生于有，有生于无，有无相生，难易相承，.....是以圣人处无为之事，行不言之教，万物作焉而不辞，生而 不有，为而不恃，功成而弗居。系统可大可小，犹如上善若水，利万物不争，才能成其大。
推动算法系统体系的进行正向开发，最大的挑战在于，1. 自己的专业广度和深度；2. 协调推动能力，二者都是很大的挑战，尤其是1 不甚具备同时，去实现2。共性的痛点就是，专业部门不配合你，专业部门之间天然的矛盾，业务需求和自己能力之间的矛盾。对我来说，所有技术部门TD，研发人员都很熟悉，沟通上都没有太多的障碍，但是系统架构的推动，只有自己亲自去现场，沟通推动，才能进行，一旦按照体系或者指标要求等，分工各个专业并行去展开，然后再汇总review，几乎寸步难行，要么没有know how，那么感觉你越界了，并不想配合，面聊只是出于礼貌而已。但是这么大的体系，单靠一两个人肯定是独立难支。至此，我回想前同事临走前说的一句话，辅助驾驶算法部是否真的需要系统架构，或者说需要我认为的所谓的系统架构的体系。在这个行业大家说的更多的是第一性原理，刚好我也看过硅谷钢铁侠。
纵观特斯拉的历程，抹掉特斯拉这个人物，去看历程，就是一个毫无体系敏捷开发，走一步是一步，太过技术化，游走的破产边缘的很不正规的公司，只能说成王败寇，毫无体系可研。教员的实践论和矛盾论，教导我们，要抓住事物的主要矛盾和矛盾的主要方面，要在实践中检验理论。特斯拉能够成功的关键在于，特斯拉本人就是公司的体系，冒险，但是决策正确，且果断坚持。中共的艰辛历程，其实和特斯拉有异曲同工之处。所以说，一个公司或者部门要么中央集权，要么体系化，换句话说如果公司没有体系化，犹如外企，铁打的体系，流水的兵，任何人的变动不影响企业发展，要么中央集权，领导或者领导层有运筹帷幄的能力。
很多现在自动驾驶公司，其实都在经历类似特斯拉的过程，在没有特斯拉能力，也不具备体系建设条件下，如何做好系统架构，是令我很头疼的事情，系统很重要，但是推不动，等到各方面都成熟稳定了，然后反向进行体系建设，好像又没有太大的必要。
在不具备职责的情况下，又不想做亲力亲为的老黄牛，还想做成这个事情，这是一个社会哲学的问题，生而 不有，为而不恃，功成而弗居，行事上善若水，顺势而为。说人话就是，不要过分追求结果，追求体系，结合实际情况，不是自顶而下推动，而是在这个know how下，以点到面的，逐步引导并填满这个框架。潜移默化量变到质变。关键是是否愿意如此做事？
另外一个更重要的事情，就是端到端的冲击，算法的底层逻辑变了，系统之间的性能拆解也变了，系统如何做好这个转型，也是现在的焦虑点。底层逻辑变了，但是顶层功能逻辑不变，用户端是无感的，功能产品要求是一样的，点刹，画龙等问题点也是不变的，感知，规控等虽然最后一体化，但是内部的影响链路是不变的，变的技术逻辑带来的优缺点变了，比如车道线的跳变对最后轨迹的影响，传统的方式有滤波，平滑，规则等后处理的链路，模型本质上来说也是一个非线性的滤波，不同的是这两个滤波器处理优势不一样，对于跳变等滤波器只能在有限边界处理，且无法泛化，但是模型对这种跳变等有天然的过滤能力，非线性很强，那么对于感知输出的这类跳变或者对应的中间变量，下游模型就可以cover或者过滤掉。所以对于算法架构，转型只要抓住技术的本质，思维体系是相对比较容易转变的。但是对基础理论的补充，依旧是需要认真学习的。
粗鄙的思考，不成体系，然行业变革迅猛，如何抓住不变的道，去适应快速术的发展，其实就是所谓的第一性原理？后续会持续更新，进阶端到端系统架构之路
大事成于细，难事成于易
天行健，君子自强不息
胜人者有力，自胜者强
共勉！
端到端的自动驾驶系统架构思考-2
以uniad为例，聊一聊端到端模型下，系统架构工程师如何发挥自己重要角色，一方面uniad开创性的提出了以planning为导性的网络模型，这也是模型由开环到闭环的重要转变，另一方面，保留了传统各个技术模块显性输出，分析框架上，大家也比较熟悉。系统工程师都比较清楚，性能&问题拆分都是从规控执行侧逐步往上拆分，所以uniad可以说是二者的一个混合中间过渡阶段，是进行一些思考不错的参考方案
对uniad不熟悉的同学可以先从这里了解 端到端自动驾驶Uniad详细讲解 - 知乎 (zhihu.com)
首先，我们先从目前系统架构的工作职责，审视一下基于网络架构的变和不变的
不变的是
- 用户是无感的：产品体验是不care 技术的
- 功能逻辑是不变的：adas还是adas，NOA 还是NOA，该降级还得降级
- 法规行业标准是不变的：这个不赘述了
- 安全冗余依旧是要求的
变的是
- 功能要求不变，但是功能实现逻辑变了
- 如何满足功能逻辑，比如激活，退出功能，变道时间，导航信息，人机交互策略等如何重新适配
- 故障诊断如何实现：比如车道线不清楚，如果没有车道线的输出如何判断，或者模型对车道线的容忍度高了，怎么量化和标定
- 如何确定性能边界：传统规则 60km/150m 弯道即可确定性能边界ok，基于网络的是否可以
- 安全冗余等要求：planning的冗余逻辑，lidar& rader&视觉的冗余可靠性怎么设计和验证，暂时无思路
- 性能指标变了，但是又没变
- 整个网络，但是依旧有感知，规控等技术模块独立链接，可以分开调试，这是不变的
- 变的是拆解到各个网络，关注的元素变了，元素的性能要求变了，上下游的影响链路变了
- 变得是如何鲁棒性验证，比如延迟的影响分析，现在一个网络直接级联过-去........
- 重点引入感知信息的无损传递，然而有无损传递，就要求下游有效的过滤和筛选
- 迭代优化&拆解方式变了
- 如何debug问题：从Control-planning-decision&prediction-perception的链路，肯定是变了
- 如何优化问题且保证问题解决有效性：基于规则的逻辑和性能，是可确定性分析验证的，且对其他模块影响也是可分析和可控的，但是基于网络的，解释性差，如何验证问题优化不会对其他模块带来负面影响
- 主要矛盾的转变
不变的就是我们的基础能力，重点来阐述变在哪里，以及如何变，毕竟唯一不变的东西就是变化，那么好，我们就要抓住主要矛盾和矛盾的主要方面
- 主要矛盾转变，基于规则的优化算法变为数据驱动的网络模型，也就是基于数学方法论论证的设计方式，转变为数据驱动的模型拟合！本质上说是可论证方法变为实验验证的方法
- 矛盾的主要方面
- 数据代替人的建模能力，依赖数据和算力暴力拟合或者学习
- 信息的无损传递，其实就是线性化到非线性的转变，规则大部分都只适合线性系统，EKF、 QP求解等大部分都是非线性系统进行线性化处理，非线性系统的低维线性化必然会带来损失，而模型本质就是高维拟合和分类，天然优势就在非线性系统
- 闭环论证变为经验开环拟合(学习)为主，经验开环底层逻辑为注意力机制
那么好，本质上来说，是只要历遍ODD内的所有场景，二者都可以设计出符合预期的产品，现实情况是规则根据自己的边界设计ODD，模型通过数据拓展ODD，规则的ODD是上限， 模型的ODD是数据
进入正题，就从矛盾的主要方面对uniad进行系统性分析
- 无损传递&有效滤除：要实现高维信息的无损传递到决策，再有效滤除到执行端，其实挑战在决策规划，最终的执行器是两维信息，高维无损信息传递给决策规划，信息是无损了，但是更多的是无效信息，无损隐藏的要求是更多的信息给你，性能应该更好，这就对下游带来更大的挑战。本质上来说模型就是一个类似人的注意力的非线性分类和滤波器，举个例子说走路上，大部分的环境你是没印象的，甚至你会盯着某个短裙长腿妹很长时间，甚至娃名字都想好了，但是不影响你安全通过路口。
- 无损传递并不是降低感知的性能要求，只是对感知的要求有变化，更意味者决策规划要进一步挖掘感知和自身的能力，释放整个系统潜力
- 既然感知是无损传递，决策规划是后处理，依然有这个划分，那么双方依旧需要一些性能指标的拆分
- 既然留了传输接口和可视化，那么元素和性能现阶段我们依旧需要或者可以列出来，逐步迭代
- 感知无损传递
- 重新定义无损：何为无损，足够下游做正确的决策需要信息传达下去即为无损，对下游无用的信息即为噪声，所以是何为无损，够不够损，依旧跟下游模型策略有关系
- 元素：属性是否足够，比如障碍物六自由度信息，长宽高等，障碍物是否还需要其他信息
- 范围：是否整个探测区域范围元素要求都需要无损？还是不同场景重点关注场景不一样，比如拥堵路邻邻车道车根本就不care
- 性能：所有范围内的障碍物的性能要求都一样吗
- 整体关联性：车辆&车辆、车辆&车道线&路沿、自车&他车相对位置关系组成的整体观感，这是无损很重要的一个点，或者说如何学习和理解整个交通流，才是端到端的关键能力
- 聚焦点
- 逆向推演，如果有最终的决策执行，反向拆分到感知，其实能得到对整个决策有影响的只是感知的部分区域和信息
- 感知给出完备的元素，相互关系，但是不同距离的性能可以降低
- 规控需要解决的是各种注意力机制提升非线性拟合能力和判断能力，弥补感知无法给出视角范围内足够精准稳定的局限性，提升鲁棒性
- 规控要有基于自身视觉的场景理解能力，能够在无效噪声信息中，利用多方信息交叉验证，提取有效信息，实现更高的性能天花板的同时具备鲁棒性，比如在传统规则后处理试图对障碍物通过交通流的物理特性进行校验和滤波，发现几乎不现实，但是如果用模型的话，可以天然融入处理好
- 决策规划的后处理
- 闭环稳定性：开环和闭环稳定有本质的差别
- 控制出身的同学都知道，即使很轻微的正反馈的干扰，也会导致系统逐渐发散，大家都经历过，上车调试前看规划曲线很正常，但是一闭环就画龙，开环的评测和闭环反馈是有本质区别的，也是端到端必然面临的挑战
- 闭环链路
- 预测&决策&规划&控制的闭环影响依旧是存在的，预测会影响决策，规划和控制的稳定性也会影响决策，这是基本的稳定链路环路，核心点还是决策，既要保证顺序传递链路决策的合理性，即规划执行合理舒适无风险，又要随时准备规划或者预测异常时，能够足够快进行调整。这是基本的能力，在这个基础上，需要考虑博弈和交互等更加复杂的场景，这些在网络设计中依然是重点要考虑的
- 闭环理论分析&数据驱动的融合迁移
- 如何从现在感知(开环)的训练和评测迁移到感知到规划&控制的闭环，也是难点之一，以往的数据遮挡、或者异性特征，都可以从测评直接得出，但是感知到规划，如何验证闭环的稳定性，从工具和评测都会有很大差异
- 控制执行连续稳定和安全性
- 如何训练出适合控制器执行的轨迹，也就是整个端到端的输出，叠加规则和后处理也好，但是最好在网络里面有这个注意力机制起作用，能够从原理上有约束力，然后依旧需要规则的安全 校验
- 控制端最好也针对轨迹的新特性做一定的调整，依旧是一个系统工程，没有理上游底层算法特性变了，输出轨迹没有任何改变
- 核心点，还是轨迹的连续性和稳定性和安全性，需要规划和控制系统性优化
- 模型输出轨迹，是不知道控制需求的，这个需要将控制的需求体现在训练里面
- 控制关心的轨迹的长度
- 控制需要轨迹的连续性如何体现
- 控制关心的轨迹点上各个元素的精度，模型如何体现精度
- 是否需要增加一个适配层，做一些滤除和调整，实现更好的闭环？
- 控制算法，是否参考模型特性，是否可以更类人
- 人类驾驶习惯
- 大概率第一阶段还是要延续现有的方法论
- 如何设计合理和验证的整体闭环稳定性（目前对模型的技术基础尚不了解，提出问题待日后完善）
- 预测决策规划的新特性
- 需要知道控制跟踪轨迹是否正常
- 对uniad 工程量产落地进行系统工程分析
- 开环&闭环问题
- uniad 是开环验证，如图，每次轨迹都从车身原点出来，每次更新都重新刷新轨迹，没有历史的连续性，控制无法进行稳定闭环跟踪。控制是一个物理过程，是时间维度的连贯性，举个简单的例子，跟踪有误差，控制需要有误差积累的反馈然后动态调整，如图所示的轨迹，显然达不到。之所以开环看起来很稳定，每次循环都刷新轨迹，只能保证单次合理性，能够看起来合理是因为驾驶员本身做了正确的操作，只是驾驶员操作的单次映射而已。
- 参考 开环端到端自动驾驶：从入门到放弃 - 知乎 (zhihu.com)：不受到累计误差的影响。再难的路, 0.5s后 human driver总会给你正确答案
- 关于ego status：英伟达最新！CVPR 2024 | 开环端到端自动驾驶中自车状态(Ego Status)是你所需要的一切吗？- 知乎 (zhihu.com)：该文章不敢苟同，没有了图像输入，依旧有轨迹输出，应该反思的不是用不用ego status，而是训练验证方法论的问题，很明确的一个点，ego status是必须要有的，分歧点或者难点是如何使用他。腿不好不要嫌弃路不平
- 轨迹问题
- 控制需要连续的轨迹去跟踪，这块可以参考传统adas基于车身坐标系下的轨迹的拼接和stich的原理
- 如图所以uniad训练出来的轨 迹是不合理的折线
- 实际训练其实是可以参考自车走过的路径的，将未来一段时间的自车轨迹标定出来进行训练
- 上下游拆解
- 最好是复用现有的感知的能力，所谓的无损信息传递，并非是现有的接口信息不需要，而是远远不够
- 预测与感知障碍物输出合并，进一步节省资源
- 去掉或者大幅减少感知后处理，包括障碍物和车道线等，不要阻挡无损传递的通路
- 可以认为模型有自己的整体关联性视感：更多的关注车道线&障碍物的相对关系，障碍物等交通流的相对关系、道路结构拓扑图的结构关系
- 决策规划要降维滤除无效信息的能力
- 无损信息提取，拥有整体视感阅读能力和聚焦能力，也就是如何发挥注意力机制，从整体视感上，抓住重点信息
- 从感知到出规划轨迹，是有更明显的时空关联关系，最终输出是低纬度有约束的信息，从控制角度来说是多输入单输出系统，意味着存在更多冗余信息可以交叉验证，是挑战也是挖掘潜力的重要的点。
- 高维噪声的评估和过滤能力，比如高频和偶发的车道线和障碍物的抖动，现有滤波处理会带来刻板画龙或者点刹，模型我相信会有更好处理能力
- 对输入指令分类处理能力，如何设计，人类其实就有很强的分类组合能力
- 实例化描述
- 障碍物直接输出带3条预测轨迹，带概率，将预测跟感知信息一同处理能够尽可能的损失预测的信息
- 障碍物的性能指标在不同的距离和相对位置关系的要求可以进一步下降，下游通过综合无损信息和噪声信息进行滤除
- 车道线也可以允许一定的抖动
- 决策规划要求
- 对上游的高频噪声要有足够的鲁棒性
- 传统的单点滤波：障碍物前高频小幅跳动，偶发一帧跳变，速度，加速度，位置的白噪声不敏感
- 不同场景有聚焦区域：能够有意训练出真正影响功能的区域，重点关注
- 关联性滤除：无关紧要的障碍物滤除，比如邻邻车有个横向位置，这种就直接不管；能够根据周围车交通流将不符合物理规律的异常检测滤除
- 关联性优化&鲁棒&泛化：根据障碍物&车道线&路沿等，综合安全和灵活性给出合理的轨迹
- 输出要求
- 障碍物车道线的高频噪声&跳动在轨迹层面彻底滤除
- 符合车辆的物理特性，低频特性
- 轨迹是连续的，跟车身解耦的，且车身画龙等非预期时，依旧是一个解耦车身且车辆有能力跟踪
- 数据&训练：konw how 不够 hold
- 鲁棒性验证问题：hold
通过对uniad在没有网络模型的基础上，从系统工程的角度进行了一些思考，分析出一些认为关键的或者不同的方案迭代要注意的设计要点，接下来会进一步学习逐渐完善系统工程的分析、闭环和验证工作:
- transformer、注意力机制等底层的模型网络
- 数据标注&训练&评测流程
- 模型的设计和调试机理
- 决策&规划的模型如何设计
- 模型闭环的安全&鲁棒性如何验证和保证
- 对uniad进行闭环量化的分析
- 进一步评估其工程落地能力
心得补充：
人为什么开新车也很熟练：
因为人其实是三重冗余：学习的开环经验，开环经验的微调， 紧急异常执行
比如开新车过弯道
- 按照经验打一个角度基本上就能过，这就是习惯，或者程序化的
- 发现新车不一样，需要微调一下，这就是人的泛化或者鲁棒能力，其实是另外一套监控体系
- 再然后发现这车太不一样了，要撞马路牙子了，会条件反射猛打，这属于安全机制
- 对应到车上就是adas&AES，但是少adas的冗余监控，这恰恰是用网络模型我们要思考的
- 这套体系在控制系统叫做复合控制
