商用车端到端自动驾驶详解(上):从传感器到世界模型

如果把自动驾驶说成“感知、决策、规划、控制”四个词，外行人很容易以为系统就是四个黑盒排成一排：前面看路，中间想一想，后面踩油门和打方向。可真正做商用车端到端自动驾驶时，事情要复杂得多。重卡车长、质量大、制动有气压和挂车耦合，动力系统可能是柴油、燃气、纯电或氢燃料，变速箱还可能存在 AMT、AT、DCT、直驱电桥等多种形态。一个看似简单的“并线后保持 80km/h”，背后其实要同时判断传感器是否可信、前方坡度会不会导致动力不足、是否需要提前换挡、制动压力是否能按期建立、转向执行器是否到位、挂车是否稳定，以及任何一个部件失败时怎么把车带到最小风险状态。

本文按上下篇来拆。上篇先回答“这套系统由哪些部分组成，端到端到底端到哪一端”。下篇再沿着控制链路往下走，细讲油门、制动、转向、转向灯和换挡如何发命令、如何闭环、如何判断成功。为了避免把端到端讲成抽象口号，文中会同时放真实商用车资料图和自制机制图：真实图负责说明车和硬件长什么样，机制图负责把模型、公式、状态机和控制逻辑讲清楚。

图 1：商用车端到端自动驾驶的六层结构。真正落地时，神经网络、规则、安全监控和线控执行必须合在一起看。

一、先把“端到端”说准：不是黑盒直接踩踏板

端到端自动驾驶的核心，不是把所有工程模块删掉，然后让一个巨大的神经网络从摄像头图像直接输出油门、刹车和方向盘角。学术上确实存在这种单体策略模型，但商用车量产系统通常更接近“规划导向的端到端”或“组件化端到端”：传感器数据被编码成鸟瞰图特征、占用网格、目标轨迹、交通语义和地图语义；感知、预测、规划可以共享骨干网络或共同训练；最终输出一般是未来几秒的轨迹、速度曲线、行为意图或代价场，而不是没有解释接口的踏板百分比。

这么做有一个很现实的原因：商用车的控制执行链太长，安全责任太重。感知模型可以学习，但制动阀建立压力需要时间；规划可以学习，但 40 吨车的轮胎附着、坡道阻力、变速箱换挡间隙不能靠“感觉”糊过去；模型可以给出并线意图，但法规、转向灯、盲区、挂车摆动和最小风险停车必须由可审计的安全外壳持续监督。工程上的端到端，是用统一目标训练感知到规划的链条，同时保留必要的中间表征、可验证接口和执行闭环。

可以用一个函数来理解：传统模块化像是先算检测框，再算预测，再算规则，再算轨迹；端到端则希望用同一个训练目标让前面的特征对最终驾驶质量负责。换成公式，就是让模型学习从历史传感器序列到未来轨迹的映射：

这里 x 是多传感器历史输入，m 是地图或导航任务，g 是目标约束，τ 是未来 H 秒的轨迹。注意，τ 还不是最终油门和制动，它更像“我想让车在什么时间到达什么位置、以什么速度通过”。控制器再把 τ 变成底盘命令。

图 2：端到端自动驾驶不是一种单一形态，而是一条从模块化到单体策略模型的谱系。商用车更常见的是保留安全接口的组件化端到端。

二、为什么商用车比乘用车更难：重量、制动、挡位和运营约束

乘用车自动驾驶常被人拿来做类比，但商用车的工程约束很不一样。第一是质量。牵引车带挂车常见总质量可以到几十吨，同样 0.1m/s² 的加速度，对轮端力的需求就很可观。第二是制动。许多重卡和挂车仍然以气压制动为主，EBS 可以电子控制，但空气管路、阀体、制动气室和挂车连接都带来响应延迟。第三是挡位。柴油重卡或混动重卡在高速爬坡、匝道汇入、跟车恢复时，是否提前降挡会直接影响速度跟踪和油耗。第四是运营。商用车不是单车炫技，系统要服务真实货运：路线固定、时间窗明确、车队调度、远程监控、维护周期、法规审查都要进入系统设计。

所以，商用车端到端的“端”至少有两头：上端是传感器、地图、任务、车队调度和历史数据；下端不是一个简单控制量，而是发动机/电机、EBS、EPS、TCU、BCM、驻车制动、挂车制动、远程监控和最小风险停车等执行链。模型的输出如果不理解这些物理约束，就会在真实车辆上表现得像一个会看路却不会开卡车的人。

图 3：Kodiak 第五代自动驾驶卡车把前向激光雷达和广角相机集成到两侧 SensorPods，用来提高长距感知冗余和维护便利性。

三、传感器层：先回答“我能看见什么，多久以前看见的”

端到端模型再强，也只能处理传感器给它的世界。商用车感知层通常包括相机、毫米波雷达、激光雷达、GNSS/INS、轮速、方向盘角、制动压力、发动机转速、变速箱状态等。相机提供纹理、车道线、信号灯和目标类别；雷达对速度和雨雾有优势；激光雷达给 3D 结构和远距离障碍物；GNSS/INS 和轮速负责自车定位；底盘 CAN/J1939 则告诉系统车辆本体正在发生什么。

这一层最容易被低估的是时间同步和坐标统一。假设相机图像晚了 80ms，激光雷达点云晚了 50ms，车速来自 20ms 前，方向盘角来自 10ms 前。如果系统直接把它们拼起来，80km/h 的重卡在 80ms 内已经走了约 1.78m。对乘用车这已经不小，对重卡换道、匝道、近距离跟车更危险。因此上车前必须做三件事：传感器时间戳对齐、外参标定、运动补偿。所谓感知输入，不是一堆原始图片，而是一套被同步、标定、补偿后的多源观测。

图 4：Aurora Freight 页面中的自动驾驶重卡，展示了商用车自动驾驶系统与干线物流车辆平台结合后的典型外观

真实系统还会做传感器健康诊断：镜头是否被泥水遮挡，雷达是否有干扰，激光雷达是否有盲区，GNSS 是否漂移，IMU 是否饱和，轮速是否与惯导不一致。端到端模型看到的是世界，但安全监控要先判断“看到的世界是否可信”。如果传感器可信度下降，规划层就要扩大跟车距离、降低速度，甚至触发最小风险停车。

四、表征层：从图片和点云变成 BEV、占用和对象

端到端系统里最重要的一步，是把不同传感器转换成模型能共同理解的局部世界。现在主流做法之一是 BEV，也就是鸟瞰图表征。简单说，车把周围几十到几百米的空间切成网格，每个网格里编码道路、车道、车辆、行人、障碍物、可行驶空间、速度、置信度和历史变化。这样模型不再只看“前视相机的一张图”，而是看一个以自车为中心的局部世界。

占用网络则回答“这个空间被什么占着，未来可能被什么占着”。对商用车来说，占用比检测框更重要。一个遗落轮胎、施工锥桶、路肩台阶、拖车尾部、被遮挡的车辆，都不一定能被稳定归成标准类别，但只要它占据了可行驶空间，规划就要避让。好的端到端表征不追求把世界命名得非常漂亮，而是把“会影响未来轨迹的东西”表达清楚。

图 5：PlusAI SuperDrive 的复杂交通场景展示图，用来说明端到端系统最后面对的是车道、目标、交通流和自车轨迹的统一判断

五、世界模型：预测的不只是别人，也包括自己

感知告诉系统“现在有什么”，世界模型要回答“接下来会怎样”。对自动驾驶来说，预测不是画几条他车轨迹那么简单。它包括交通参与者未来运动、自由空间变化、施工区边界、红绿灯相位、道路曲率、坡度、湿滑程度、前车可能急刹、旁车是否会切入，以及自车执行动作之后世界会如何回应。

端到端世界模型的价值，是它可以把感知和规划放在同一个目标下优化。比如传统检测模型可能把一个远处目标框得很准，但这个目标在自车轨迹之外，对规划没影响；另一个不完整的施工锥桶虽然类别置信度不高，却正好压在自车前方路径上。规划导向的端到端会倾向于把计算资源和学习能力放到后者身上，因为它决定车能不能安全通过。

商用车还要把“自车未来”纳入世界模型。车辆不是理想质点，轨迹能不能执行，取决于轮端力、制动能力、转向角速率、挡位、发动机转速、轮胎附着和挂车姿态。世界模型如果只预测外部交通，不预测自车在当前挡位、当前质量、当前坡度下能不能加速，就会给控制层一个不可实现的轨迹。

图 6：PlusAI 对全冗余传感器套件的官方展示：商用车 L4 系统通常需要雷达、相机、激光雷达的主备覆盖。 图片来源：https://www.plus.ai/solutions/superdriv

六、决策和规划：输出的是可执行轨迹，不是“向左一点”

规划层通常分为任务规划、行为决策和运动规划。任务规划回答“去哪里”，例如从物流园到高速入口，再到服务区或收货仓；行为决策回答“当前要保持车道、跟车、并线、避让、靠边还是等待”；运动规划回答“未来几秒每 0.1s 的位置、速度、加速度、曲率应该是多少”。端到端模型可以参与其中的一层，也可以把多层共同训练，但最终必须产出控制器能跟踪的时空轨迹。

轨迹必须满足五类约束。第一是几何约束：不能出车道、不能压不可通行区域、不能让挂车扫到障碍物。第二是碰撞约束：与前车、旁车、行人、静态障碍保持安全时距和空间距离。第三是动力学约束：曲率、横向加速度、纵向加速度、加加速度、转向角速率都要在车辆能力范围内。第四是法规和交互约束：限速、禁行、让行、转向灯、应急车道、施工区引导都要被遵守。第五是可执行约束：如果当前挡位无法提供足够轮端力，规划要提前降挡或降低速度目标。

这就是端到端和控制层之间最重要的接口：轨迹不是一句“开过去”，而是一组带时间的状态序列。控制层拿到轨迹后，才能计算当前位置误差、航向误差、速度误差和加速度需求。

图 7：NVIDIA DRIVE AGX Orin 开发平台。车端计算平台承担多路传感器接入、深度网络推理、规划控制和安全监控等实时任务。 图片来源：https://developer.nvidia.com/drive/agx

七、计算平台和实时性：模型越大，越要知道每毫秒花在哪里

车端计算平台不是普通服务器。它要同时处理多路相机、雷达、激光雷达、惯导、CAN/J1939、以太网、日志、诊断和安全监控。深度网络推理可能跑在 GPU、DLA 或专用加速器上，控制和安全任务则常常跑在实时 CPU 或安全 MCU 上。一个典型周期里，感知可能是 10-20Hz，规划可能是 10Hz，控制可以是 50-100Hz，底盘报文则有 10ms、20ms、50ms、100ms 不同频率。

端到端模型越复杂，越不能只看平均延迟。工程上要看最坏情况延迟、抖动、丢帧、温度降频、传感器异常、网络拥塞、日志写入对实时性的影响。比如规划轨迹晚到 120ms，控制层即使算法正确，也是在跟踪旧世界；如果转向角反馈晚到 50ms，横向控制会出现相位滞后；如果 J1939 总线在换挡和制动事件中负载突然升高，控制报文可能发生排队。

因此，车端架构通常会把“性能计算”和“安全控制”分开：大模型负责理解复杂世界，安全控制器负责最后的使能、限幅、故障监测和紧急降级。端到端不是取消安全层，而是要求安全层更清楚模型正在请求什么。

八、数据闭环：端到端不是一次训练，而是长期运营系统

端到端自动驾驶的生命线是数据闭环。车辆每天跑真实路线，系统记录传感器、轨迹、控制命令、底盘反馈、接管、异常、远程辅助和维修事件。后台从这些日志里挖出困难场景：高速汇入、施工区临时标线、雨夜反光、前车急刹、坡道跟车、挡位选择错误、制动压力建立慢、传感器遮挡。然后重新标注、重训、仿真回放、影子模式验证、灰度发布。

这里有一个关键区别：传统规则系统主要靠工程师写新规则，端到端系统主要靠数据让模型学到新模式。但数据闭环不是“把所有失败样本扔进去再训练”。它要回答四个问题：失败发生在哪个 ODD，模型为什么错，新的训练样本是否覆盖同类场景，修复后是否在闭环仿真和实车影子模式中都成立。没有这些闭环，端到端会变成不可控的模型堆叠。

图 8：端到端系统的改进依赖数据闭环：场景挖掘、自动标注、训练、仿真、灰度上车和线上监控必须连成闭环。

九、商用车端到端系统的典型组件清单

把上面的内容落成工程清单，一套商用车端到端自动驾驶系统至少包含下面这些组件。实际项目里，不同公司命名不同，但功能边界大体相近。

端到端自动驾驶不是把“感知、决策、规划、控制”四个词换成一个大模型，而是让感知到规划更统一地为最终驾驶目标服务；同时，车辆控制、线控执行、安全监控和运营闭环仍然必须严格存在。

十、上篇小结：模型负责理解世界，控制负责兑现承诺

上篇讲的是上半条链路：真实重卡通过传感器看世界，通过计算平台把多源输入变成 BEV、占用、对象和预测，通过端到端或组件化端到端模型给出未来轨迹。到这里，车还没有真正动起来。轨迹只是一个承诺：系统认为未来几秒应该这样开。下篇要讲的是兑现承诺的过程：控制器如何把轨迹变成油门、制动、转向灯、转向和换挡；如何处理商用车的气压制动、发动机/电机扭矩、AMT 换挡、CAN/J1939 反馈；以及系统如何判断“命令已经执行成功”。

参考资料

[1] End-to-end Autonomous Driving: Challenges and Frontiershttps://arxiv.org/html/2306.16927v3

[2] Autoware Autonomous Driving Stack Architecturehttps://autowarefoundation.github.io/autoware-documentation/main/design/autoware-architecture-v2/roadmap/autonomous-driving-stack-architecture/

[3] Apollo 3.0 Software Architecturehttps://daobook.github.io/apollo/docs/specs/Apollo_3.0_Software_Architecture.html

[4] Kodiak AI 第五代自动驾驶卡车发布资料https://kodiak.ai/news/kodiak-introduces-5th-generation-autonomous-truck

[5] Kodiak Driver 技术页面https://kodiak.ai/technology

[6] Aurora Freight 官方页面https://aurora.tech/freight/

[7] PlusAI SuperDrive 官方页面https://www.plus.ai/solutions/superdrive

[8] NVIDIA DRIVE AGX Orin Developer Kithttps://developer.nvidia.com/drive/agx

[9] PlusAI SuperDrive 6.0 发布资料https://www.businesswire.com/news/home/20260304797832/en/PlusAI-Launches-SuperDrive-6.0-to-Accelerate-Scaled-Commercialization-of-Driverless-Autonomous-Trucking-Operations