本文主要是介绍20T算力打造轻地图方案，这家智驾公司持续内卷，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
作者 | 张祥威
编辑 | 德新
行泊一体的话题热度不减。
近日，宏景智驾核心产品单SoC行泊一体解决方案已全场景跑通，可实现高速导航辅助驾驶。
在推进量产的同时，宏景智驾也在布局BEV感知、轻高精地图甚至去高精地图的智驾方案，同时也在打造4D BEV感知真值系统产品，赋能更多车企进行相关技术开发。
宏景智驾在HiEV进行了主题为《如何打造极致“品价比”的轻地图ADAS 产品》的线上分享，要点如下：
- 宏景智驾BEV去高精地图技术展示；
- 宏景智驾轻地图ADAS产品，打造极致“品价比” ；
- 宏景智驾 Hyper-GTMax如何附能车企高阶感知自研能力？
以下为线上分享问答环节的内容整理。
一、将BEV轻地图能力降维到20T级算力芯片上
Q：当实时感知的结果跟本地的SD Pro Map（比标精地图精度更高）有差异的话，我们的逻辑策略是什么样的？
A：首先，宏景目前的开发重心还是高性价比的行泊一体产品。所以我们在高速上面采用的是SD地图，不是SD Pro的方案。在高速上SD地图就可以实现BEV+去地图的方案。因为我们在感知端的开发是不分高速和城市的。
在城市里面很多地方的拓扑是非常困难的，所以目前拓扑的模块还没有非常成熟之前，在这种比较复杂的路段，我们还是以图商提供的为准。
Q：目前我们对BEV的最低算力有评估吗？
A：我们目前可以把6V的BEV方案，在20TOPS+ 的芯片上实现目标检测和地图检测的能力。
Q：宏景的4D真值系统相当于是给车厂搭建了一套地图采集的设备么？
A：它其实不是地图采集。它更多的是，比如我们希望用一段多个图像的30秒数据，针对下游的任务，比如目标检测、局部地图的一些元素检测，包括一些Occupancy 的检测提供它的真值系统。
因为构建这些真值是非常麻烦的，很多时候车企想快速完成感知的0到1的能力的构建的时候，往往取决于它要怎么把这个数据构建出来。所以我们应客户需求做出了这套真值系统。
Q：宏景的方案跟其他家比，技术差异化主要在哪里？
A：第一，我们其实已经做了大量的基于HD Map的量产NOA（导航辅助驾驶）的落地。要去掉高精地图，首先要了解在量产NOA地图里的一些点，去地图的时候就更有信心，这个过程中的积累能更好地帮我们知道什么时候该如何解决某些问题。
第二，目前BEV轻地图的方案主要还是用在一些比较贵的车型上。我们希望能够把BEV轻地图的能力，通过技术降本的方式提供给车厂和消费者。这也是我们跟其它公司一个比较大的不同，我们能够把这种BEV轻地图的能力降维放到20TOPS+ 的芯片上，能实现差不多的功能，体验上也非常优秀。我们主打的是最高的“品价比”。
Q：要做到BEV轻地图的方案，算法上是如何考量的，是否要采用Transformer类型网络？
A：首先回到商业维度，我感觉城市NOA的落地，并不一定是大芯片+Transformer就一定能实现的，更多的是整个功能做出来是怎么样的？体验如何？价格如何？这是一个点。
第二，从技术维度上，因为整个BEV模型有很多个模组，包括比如2D转3D模块、时序、检测模块，在一些功能模块上面，我认为是不是 Transformer 都无所谓，只要能够完成这个功能就可以。无论是Transformer或者CNN（卷积神经网络）都可以。在检测上面使用Transformer的方式，其实能带来表征的一些优化。
从芯片的角度说，用这种支持Transformer的芯片，对于算法的选择上是有很多的帮助的。对我们来说做BEV地图的检测，如果只是用传统的CNN，想去地图是非常困难的，因为它有非常多厚重的后处理。
所以我们现在整个BEV在车端算法的核心，是在输出端能够直接输出点集加上局部的拓扑，这个输出的表征其实是非常重要的。这也是为什么我们在20TOPS＋ 的芯片上能够做出来跟Transformer效果差不多的线，它并不是通过大量的复杂的后处理来得到的，而是直接从模型里面出的。
Q：您认为BEV的难度以及壁垒在哪里？
A：我认为算法壁垒、数据壁垒，或者说BEV究竟能不能应用到一个非常好的产品上面，其实都有壁垒。
举个例子，从算法开发的角度来说，BEV其实也有一些不同的功能模块，比如BEV下的3D目标检测这个功能，从整个数据的构建到标注到最后的输出，这个难度会稍微小一点。但是BEV轻地图的这个功能，要完成非像素级别对应的数据的构建，其实要花的时间和整个数据构建的难度会更大。
第二，数据的壁垒肯定是最大的。拥有越来越多高质量的数据，BEV感知的性能就越好，迭代周期就越快。所以到BEV的阶段，需要有非常强的数据构建的能力，包括自动标注都是非常重要的。
第三，如何基于BEV打造一个好的产品也是一种壁垒。
二、要实现城市NOA，必须去高精地图
Q：现在大家可能会感受到，去地图后的成本并没有降太多，而且体验相比于传统高精地图的体验还会差一些，您怎么看这个问题？
A：我认为这个问题一方面取决于感知的成熟度，另一方面取决于体验能不能持续做得更好，还有一方面取决于客户的接受度。
宏景目前还是脚踏实地的希望先从高速做起，在高速上基于我们非常成熟的行泊一体的量产的系统，能把高精地图和高精定位模组去掉。
然后在感知开发端，其实不论城市和高速我们都会积累，所以我们也不会那么快一定要在城市里面完全不依赖高精地图。目前阶段我们的重心还是在高速上去完成具备性价比产品的打造。
从价格方面，我非常赞同“一个ADAS系统应该在车价的3% - 5% 的区间”这种说法，如果我们要让10万的车能满足这样的功能，那是不是要把整个系统成本压到这个区间，主机厂才愿意买单，才能有更多人愿意买单。这个时候我们一定是希望通过更好的技术降本去完成。
通过BEV轻地图的方式，在现在这种比较成熟的行泊一体的里面做到体验不降，甚至上了BEV之后体验还能更好，同时能降低成本，把这个能力给到更多的低价的车型，更多的消费者手里，这是我们的愿景。
Q：想问一下目前在跟主机厂交流的过程当中，主机厂的态度，是不是对去地图的诉求真的很强烈？还是主机厂的诉求只是降本？并不特别关心怎样通过技术去实现这个功能。
A：我觉得这个可以分成两个点。第一点，现在比较热的城市NOA的功能，它的去地图其实并不是一个降本的方案，因为高精地图在城市里面要保持这个东西非常困难，所以它更多是从技术角度的考虑，要实现城市NOA，必须具备去地图的能力。
现在，我们在高速NOA上去地图的能力，相对来说实现的方式会比城市稍微简单一点，它只要能够把各种匝道、各种困难的场景攻克了，能够达到这样的功能，其实从降本的层面，对于这个主机厂来说他们还是非常乐意见到这样的产品推出。只要能保证产品体验足够优秀，还比别人便宜，是非常有竞争力的。
还有一点，这种新系统里面它有一个核心点，就是它会把这个BEV的感知架构给拿出来，整个数据架构可以逐渐地从高速往城市这样去走，是一个体系化的升级和更新。
Q：相比传统技术，BEV技术下的标注有哪些新的规则和新的技术?
A：以BEV地图举例，规则层面肯定还是看算法下游的一些定义，包括后面需要的哪些功能来做BEV地图的一些标注，要识别哪一些元素，之间它需要有一个关联关系，这个关联关系是怎么样的？这是一个维度。
另外从技术的角度，它会比传统的更复杂一点。因为如果想在6V上面直接标BEV地图，基本上不太可能，所以必须要能够有场景重建能力的模块，在这个场景重建的基础上去做完标注，标完的数据还得跟图像级别的像素对应起来。这个地方对于整个系统的时间同步，传感器的标定，整个基础能力都是非常考验的，才能得到4D对应好的这种真值Clip 来做BEV训练，不然构建出来的数据对齐程度不高，这个BEV训练出来结果会有很大的问题。
Q：在拥堵场景下，BEV怎么做到实时建图，比如一个拓扑结构被周围车辆遮挡住了，怎么解决这个问题？
A：这是一个非常难的点，我觉得解决了这个问题之后，就能在高速上把BEV地图去掉了。现在我们的解决方案，首先整个BEV并不是单帧的，它是带时序的。因为整个地图元素是一个静态的信息，所以只要曾经看到过，就能记住。
BEV地图跟传统的所见即可得的这种车道线检测对比，它有一定的预测和推理能力。很多时候我数据标的时候真值为一个路口，或者一个匝道口，其实有时候像素里面没有看到，它其实就有局部的预测能力。这是一个点，在感知端需要更好地解决这个问题。
如果目标车辆真的被各种大车挡住了什么都看不见，这时候我们需要更多的规控端和后端，需要用到一些车流的信息，因为车流的信息很多时候跟中心线是息息相关的，所以我们也会重点参考比如历史的车流信息，这其实对于我们BEV地图检测是有些帮助的。当然如果说极端场景下，还是需要人工接管的。
这篇关于20T算力打造轻地图方案，这家智驾公司持续内卷的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
