在线问答5

这个屌丝很懒，什么也没留下！

热门标签

自动驾驶合集23

作者：在线问答5 | 2024-07-18 17:19:56

踩

自动驾驶合集23

# 端到端与下一代自动驾驶系统，以及端到端自动驾驶的一些误区

最近一个月由于众所周知的一些原因，非常密集地和行业内的各种老师同学进行了交流。交流中必不可免的一个话题自然是端到端与火爆的特斯拉FSD V12。想借此机会，整理一下在当下这个时刻的一些想法和观点，供大家参考和讨论。

如何定义端到端的自动驾驶系统，应该期望端到端解决什么问题？

按照最传统的定义，端到端的系统指的是一套系统，输入传感器的原始信息，直接输出任务关心的变量。比如在图像识别中，CNN相对于传统的特征子+分类器的方法就可以叫做端到端。在自动驾驶任务中，自然想到的一个定义便是，输入各种传感器的数据（相机/LiDAR/Radar/IMU…），直接输出车辆的控制信号（油门/方向盘转角）。为了考虑不同车型之间的适配问题，也可以将输出放宽为车辆的行驶轨迹。这便是一个传统意义上，或者我叫做狭义端到端的定义。在这样的一个基础上，也衍生出了例如UniAD这样模块化端到端的概念，即在最终输出控制信号或者路点之外，也引入了一些相关的中间任务的监督来提升性能。

然而，除了这样狭义的定义之外，我们还应该从本质上思考一下，端到端的本质是什么？我认为端到端的本质应当是感知信息的无损传递。我们先回想一下在非端到端系统中，感知和PnC模块的接口是什么样子的。一般我们会有针对白名单物体（车，人，etc）的检测/属性分析/预测，会有对静态环境的理解（道路结构/限速/红绿灯，etc），如果做的更细致一些的话，还会做通用障碍物的一些检测工作。从宏观的角度来讲，感知输出的这些信息，都是对复杂驾驶场景的一种抽象，而且是人工定义的显式抽象。然而，对于一些非常见场景中，现在的显式抽象难以充分表达场景中会影响驾驶行为的因素，亦或是我们需要定义的任务过多过琐碎，也难以枚举尽所有需要的任务。所以端到端系统，提供了一种（也许是隐式）全面表示，希望能够自动地无损地将这样的信息作用于PnC。我认为，所有能满足这样的系统，都可以叫做广义端到端。

至于其他的问题，比如对动态交互场景的一些优化，我个人的观点认为至少并非只有端到端才能解决这些问题，端到端可能也不是解决这些问题最好的一个方案。传统方法是可以解决好这些问题的。当然，在数据量足够大的时候，端到端可能会提供一个还不错的solution。关于这个事情是否有必要，会在后几个问题中展开讨论。

关于端到端自动驾驶的一些误区？

一定要输出控制信号和路点才是端到端

如果能认同上面所讲的广义端到端的概念，那么这个问题就很容易理解了。端到端更应该强调的是信息的无损传递，而不一定要直接输出任务量。这样狭义的端到端做法，其实带来和非常多不必要的麻烦，需要大量的兜底方案来保证安全，然而这样也会有很多的问题，在后面会展开。

端到端系统一定要基于大模型或者纯视觉

端到端自动驾驶的概念和大模型自动驾驶以及纯视觉自动驾驶没有任何必然的联系。这三个概念是完全独立存在的，一个端到端的系统不必一定是传统意义上的大模型驱动的，也不一定就是纯视觉。三者之间有一些关联，但不等同。

长远来看，上述狭义的端到端系统有没有可能实现L3级别以上自动驾驶？

其实我先想来吐槽一句，号称要用大模型来颠覆L4的人，都没有实际做过L4；号称端到端包治百病的人，也都从来没做过PnC。于是和很多对端到端狂热的人聊下来，就变成了一个纯粹的无法证实也无法证伪的宗教信仰之争。我们做前沿研发的同学，还是应该更实事求是，讲究证据一些。。。最起码对想要颠覆的东西有一些基础认知和了解一下其中棘手的问题，这是应该有的基本科学素质。。。

言归正传，目前来看，我是悲观的。暂且不论目前号称是纯端到端的FSD，性能还远远不能达到L3级别以上所需要的可靠性和稳定性，未来就算是统计意义上这个车辆和人是一样安全的，还要面临如何和人类驾驶员的错误做align的问题。更直白一点来说，就是说，一个自动驾驶系统想要让大众和舆论接受，关键可能不在于一个绝对的事故率和致死率，而是在于大众是否能接受有一些场景中，对于人类是相对轻松解决，而机器会犯错的。这个需求对于纯端到端系统来说更难以实现。

举在北美的Waymo和Cruise为例，其实分别都出过不少事故，但是为什么Cruise最后一次出现的事故让监管和大众尤为不能接受呢？这个事故发生了两次伤害，第一次的碰撞，对于人类驾驶员也是相当难以避免的，其实也是可以被接受的。但是在这一次的碰撞发生之后，发生了严重的二次伤害：系统错误地判断了碰撞位置和伤员位置，为了不阻塞交通，降级到了靠边停车的模式，将伤员拖拽很久。这样的一个行为，是任何一个正常的人类驾驶员都不会做出的事情，而且影响非常恶劣。这个事情直接导致了Cruise后续的一些动荡。这个事情其实也给我们敲响了警钟，如何避免这样的事情发生，应该是自动驾驶系统研发和运营中认真考虑的问题。

那么站在现在的这个时刻，下一代量产辅助驾驶系统中切实可行的方案是什么？

简单来说，我认为一个合适的系统应当是首先充分挖掘传统系统的能力上限，然后再去结合端到端的灵活和普适性，也就是一个渐进式端到端的方案。当然这两者如何有机地结合就是个付费内容了，哈哈。。。但是我们可以分析一下，现在所谓的端到端或者learning based planner实际落地在做的事情是什么。

以我有限的了解，目前所谓端到端模型在行车中使用的时候，在输出的轨迹之后都会去接一个基于传统方法兜底的方案，或者是这样的learning based planner和传统的轨迹规划算法会同时输出多条轨迹，再通过一个selector来选择一条执行。如果这样设计系统架构，这么一个级连系统的性能上限其实是被这样的兜底方案和selector限制住的。如果这样的方案仍然是基于纯feedforward learning的，仍会有不可预测的失效，本质上并不能达到兜底的目的。如果考虑在这样输出的轨迹上使用一个传统的规划方法再去优化或者选择，那相当于learning based方法出的轨迹，只是给这样的一个优化和搜索问题做了一个初始解，我们为何不直接去优化和搜索这样的轨迹呢？

当然有同学会跳出来讲，这样的一个优化或者搜索问题是非凸的，状态空间很大不可能在车载系统上跑到实时。我请大家在这里仔细想这样一个问题：在过去10年中，感知系统至少吃到了100x的算力红利发展，但是我们的PnC模块呢？如果我们同样允许PnC模块使用大算力，结合上近几年先进优化算法的一些发展，这样的结论仍然成立吗？针对这样的问题，我们不应该固步自封，路径依赖，而是应该从第一性原理思考什么才是对的。

数据驱动和传统方法之间关系如何调和？

其实和自动驾驶非常类似的一个例子就是下棋，刚好在今年2月份的时候Deepmind发表了一篇文章（Grandmaster-Level Chess Without Search：https://arxiv.org/abs/2402.04494）就在探索只用数据驱动，抛弃AlphaGo和AlphaZero中的MCTS search是否可行。类比到自动驾驶中就是，只用一个网络直接输出action，抛弃掉后续所有的步骤。文章的结论是，在相当的规模的数据和模型参数下，不用搜索仍然可以得到一个还算合理的结果，然而和加上搜索的方法比，还有非常显著的差距。（文章中这里的对比其实也不尽公平，实际差距应该更大）尤其是在解一些困难的残局上，纯数据驱动性能非常糟糕。这类比到自动驾驶中，也就是意味着，需要多步博弈的困难场景或corner case，仍然很难完全抛弃掉传统的优化或者搜索算法。像AlphaZero一样合理地运用各种技术的优势，才是最为高效提升性能的方式。

传统方法 = rule based if else？

这个观念也是我在和很多人的交流中需要反复纠正的。按照很多人的定义，只要不是纯数据驱动，就叫做rule based。还是举下棋这个例子，去死记硬背定式和棋谱是rule based，但是像AlphaGo和AlphaZero一样通过搜索和优化赋予模型reasoning的能力，我认为并不能叫做rule based。这恰恰也是目前大模型本身所欠缺的，也是研究者通过CoT等方式试图赋予一个learning based model的。然而人开车每一个动作都是有明确的动机的，这和需要纯数据驱动的图像识别等无法清晰描述原因的任务不同。在一个合适的算法架构设计下，决策轨迹都应该成为变量，在一个科学的目标指引下统一优化。而不是通过强行打patch和调参去修各种case。这样的一个系统自然也不会存在各种hardcode的奇怪的rule。

总结

最终总结一下，端到端也许是一个很有希望的技术路线，但是这样一个概念如何付诸实践还有很多有待探索的事情。是不是狂堆数据和模型参数就是唯一正确的解决方案，目前在我看来并不是的。我觉得，任何时刻作为一个前沿研究的技术人员，我们都应该真正奉行马斯克所讲的第一性原理和工程师思维，从实践中思考问题的本质，而不是将马斯克本身变成第一性原理。想要真正遥遥领先，就不应该放弃思考，人云亦云，否则就只能在不断想要弯道超车。

# 为什么工程上选择VINS而不是ORB-SLAM

很多公司在工程上是用VINS（VINS-Mono或VINS-Fusion）做里程计，而不是ORB-SLAM，但是好像ORB-SLAM比VINS效果更好，这是为什么呢？且看大家是怎么说的

简单回顾

ORB-SLAM是一种基于特征的单目视觉SLAM系统，广泛用于实时三维地图构建和机器人定位。该系统使用ORB特征进行高效的视觉识别和地图重建，支持关键帧技术和回环检测来优化地图的准确性。ORB-SLAM能够在多种环境下稳定工作，适用于动态场景和长时间操作，因其出色的性能和灵活性，被广泛应用于自动驾驶、增强现实等领域。

VINS（Visual-Inertial Navigation System）是一种结合视觉信息和惯性测量单元（IMU）数据的SLAM框架，能够提供高精度的实时定位和地图构建功能。VINS通过融合相机和IMU的数据，即使在视觉信息不足的情况下也能保持较高的定位精度，使其适用于快速运动或低光照条件下的场景。VINS框架因其鲁棒性和准确性，在无人机导航、移动机器人等领域得到了广泛应用。

袁博融说

因为大部分工程师对SLAM都没有深入了解。要么是都试试，哪个能跑通效果好就用哪个，要么是跟着主流意见走。而主流意见未必就是对的，很大程度上也是受公众号自媒体影响。其实VINS和ORB-SLAM都不是适合工程使用的好方案。

工程应用首先应保证前端的鲁棒性，其次才是精度。毕竟你要先能收敛，看精度才有意义。运行时但凡飘一下，之前精度再高也是打水漂。VINS和ORB-SLAM对于corner cases是没啥特殊处理的，连ZUPT都没做，这就注定鲁棒性不足。VINS长时间运行会发散是必然的。

大家觉得VINS和ORB-SLAM精度高，那是它们在几个公开数据集上表现好。但这并不意味着它们在工程应用中也一定表现好。实际上，应用中对精度影响更大的反而是数据质量，而不是算法本身。比如传感器的标定误差、同步精度、曝光、对比度、噪点等都可能会产生显著影响。在这种情况下，算法本身的差异甚至可以忽略不计。即便你出厂标定的再好，产品在整个生命周期里的参数漂移也是要考虑的吧。这些都是工程问题。

我一直不建议SLAM研究者只拿数据集做测试。数据集的固定序列难以让我们认识算法表现的随机性。我见过在某些序列上基础的VO比VINS和ORB-SLAM精度更高。但这显然是随机性引起的，因为综合多个序列的结果还是VINS和ORB-SLAM更好。我经常手持设备去跑测试，即便走同样的线路，多次的表现也会有差异。如果一个算法多次表现起伏很大，我们至少可以说它在这个场景中没有处于合适的工作窗口。

作为开发者不能总是照顾算法的特性，而应该多创造可能产生退化的极端场景做研究。这就是为什么我之前甚至录了过山车数据来做SLAM测试。

我自己实现的VIO方案可以跑完这条序列，但我不觉得VINS或ORB-SLAM能做到。我开源这套数据后也一直没有其他人说能跑通。即便我的方案能跑通这种极端场景，也不意味着它在其它看起来更简单的场景中就不会出问题。事实上我们在其它项目中也遇到过各种挑战，也是花了几个月的时间去分析和优化，现在也还在继续迭代。

VINS和ORB-SLAM的后端其实都不算先进，应该说还不如RTAB-Map。这几个后端其实都在用BoW，但RTAB-Map还有内存管理等高级特性。我一直奇怪咋还不更新成VLAD，是因为大家跑的场景不够大吗？反正RTAB-Map很快会支持VLAD的，因为我也是它的第二大贡献者。但我并不是说RTAB-Map比VINS或ORB-SLAM更好，而是它们根本不好比。RTAB-Map最初就是个VSLAM后端框架，后来才加的前端。我前面说的基础的VO就是RTAB-Map后来加的实现。而你甚至可以在RTAB-Map中用VINS或ORB-SLAM做前端。这也是为什么我要另外做VIO方案，因为RTAB-Map本来就没提供这些，它只是预留了模板。RTAB-Map不是个算法而是个框，什么都可以往里装。

ORB-SLAM的最大硬伤就是它用的是ORB特征。ORB特征除了性能好一些，在各类任务上都没什么优势。不知道有多少研究者仔细测试和比较过，其实传统特征描述子最好的还是SIFT（而且专利也到期了），后来的没一个能打的。但SIFT检测开销大也是众所周知的。而SIFT检测+SIFT描述子也不是最好的。我目前知道的最好的组合是GFTT（Shi-Tomasi）+SIFT描述子，回环检测能力吊打其它各种组合。CV领域就是这么神奇，最老的反而是最好的。GFTT本身开销就低，还方便做硬件加速。ORB做硬件加速都要更麻烦一些。我自己方案就是用GFTT+RootSIFT或SuperPoint（HF-Net）。不考虑后端的话，GFTT+KLT其实都非常好了。 whaosoft aiot http://143ai.com

所以如果你要问工程上哪个方案最好，我会告诉你RTAB-Map不错，但它只能做后端，你还需要一个好的前端。我们的前端方案今年会推产品，RTAB-Map这一两年也还会有重量级更新。除了VLAD部分还会有iSAM2，Gaussian Splatting等。目标就是纯视觉做超大场景（至少城市级吧）VSLAM+三维重建。

乐知者说

论文与实际有差别。

这就看你把orbslam和vinsmono用来干什么了。

先作为Vio来说，结论vinsmono优于orb3（没有了回环检测、多地图功能和重定位的orb3,不如vins一根毛）。理由如下：

1、运行资源。orb3远比vins消耗的多，不解释。

2、前段跟踪稳定性。lk光流跟踪比orb3 track跟踪稳定很多。orb3在实际场景中，tracklocalmap容易失败。orb3在室外场景中容易reset，然后新建地图。

3、后端优化这块。怎么说呢，orb3确实强，但是不符合导航要求的定位。因为你会经常看到它明开始跟飞很远，然后又给你突然拉回来。这种跟飞又来回来很蛋疼。没有vins-mono那边平滑。

4、精度这块（假设你成功运行完一个数据集），精度orb3会比vins强（vio初始化好的话，orb3可以到达1%)。然并软，因为orb3并不稳定，跑同一个书籍，你可能得到的结果都差异很大。

5、外参和实延。orb受外参数影响特别大，不如vins一根毛。

6、调试。vins参数量小于orb3，且稳定性比orb3强多了，不然你都不知道这次结果比上次好到底是什么原因导致的。

结论：

vio1 vins-mono+orb3初始化策略

vio2 msckf前段+orb后端

这两个YYDS。

作为slam (三维重建，语义地图),orb3远优越于vins。自己理解。忠告：远离vslam或者Vio，拥抱感知或者激光。

余世杰说

说下自己的理解，ORB强在是一个完整的系统，代码结构逻辑非常清晰，比较模块化，要做修改替换啥的比较方便，同时地图的部分对于需要的项目来说很省事儿，可以直接拿来用。缺点是，代码中还是存在一些致命的bug，会跑崩（程序挂了），以及作为一个VIO系统来说，稳定性不够强，若视觉失效，几乎立马就整体丢了，所以精度高的意义没那么大了又。若要求视觉必须稳定，那为啥我还要加IMU呢，这也是一个ORB3精度可能不如ORB2的一个原因。

VINS强在一个对外参依耐性没那么强，毕竟自己可以估计，导致就算初始化有点点问题，也可以很快稳定下来。而稳定性更是不用说，在视觉失效个5秒左右，系统都能比较正常的跑下来。还可以融合GPS输出个对齐结果，对于需要的项目也是一个加分项。缺点的话，大概就是缺少了地图一部分吧，自身是比较强的。

格雷茨卡说

因为VINS-Mono在真实场景中的稳定性远远好于ORB-SLAM3，虽然ORB-SLAM3在论文中的精度指标大幅度好于VINS-Mono，但是，你总不能一直在那几个数据集刷指标吧，在工程中的应用就要求一个系统必须能够鲁棒稳定，本人实测ORB-SLAM3对外参，特别是rotation，非常敏感，标定差一些直接就跑飞了，而VINS就不会有这个问题，可能虽然整体误差有一些大，但是实时性和鲁棒性足够了，ORB-SLAM3的VI初始化很耗时间，同时在自己实际设备上的有效性一般，VINS的初始化简单明了，实测也不会跑飞，而且又有一个250HZ的IMU预积分线程，能够很好的保证实时性，因此工程应用无脑VINS，会省很多事情

# 相机/激光雷达-相机/毫米波雷达/环视相机的标定板有什么不同

为什么需要标定板？

标定板是一种用来精确定位和标定相机(包括鱼眼环视)、LiDAR、Radar等感知设备的工具。它通常是一张或多张印有特定图案的平面物体，由高精度的制造设备制成，其图案可以用来辅助精确定位。标定板能够提高感知数据的准确性和可靠性，被广泛应用于自动驾驶、三维测量、机器人等领域。是自动驾驶中实验、量产、售后等必不可少的工具。

常用的相机标定板可以分为：april标定板、棋盘格标定板、aruco_marker标定板、V型/品字形标定板、竖型标定板等，其它传感器的联合标定或校准工具有：激光雷达-相机联合标定圆孔板、环视整车组合标定工具、毫米波雷达校准工具等。

标定板有哪些具体类型？

一、激光雷达和相机的联合标定

（1）适用范围和材质说明

适用范围：激光雷达和相机的联合标定

制作材质说明：PVC发泡板

（2）标定板形态说明

圆孔标定板