INF 市调竞析
搭载百度Apollo自动驾驶开放平台的无人驾驶出租车“萝卜快跑”占据2024年无人驾驶新闻榜首，但为何后来“销声匿迹”，这期间为何有人淡定吃瓜，又为何有人堪忧呢？INF 市调竞析带你一探究竟，从底层技术了解真相，关注本公众号了解更多无人驾驶行业技术新闻和最前沿的无人驾驶技术。
迪沃泰克机器人
工业移动机器人集群控制系统全球领导者
WWW.AGVsTD.COM
INF.ML无人驾驶交通管制AI大模型算法平台
本文INF 市调竞析（市场技术调查和竞品分析）将带您了解如下内容：
既然Apollo开源，网约车平台为什么不自己做无人Taxi？
本文对Apollo的分析基于其最新开源版本Apollo V10.0，这不一定是萝卜快跑搭载的最新（内部）版本。
本文提到的INF系统基于INF最新非标准发行版，即可以从迪沃泰克机器人订购到的最新版本，但可能涉及小部分定制化。
本文的分析基于经过对Apollo的源代码/社区文档一个工作日时间分析得来的，可能存在不足之处。
来自百度&Apollo官网的介绍是：Apollo (阿波罗)是一个开放的、完整的、安全的平台，将帮助汽车行业及自动驾驶领域的合作伙伴结合车辆和硬件系统，快速搭建一套 属于自己的自动驾驶系统。简单讲就是，使用这套技术可以将普通的汽车改造成无人驾驶汽车，Apollo是一套车载无人驾驶系统，需要安装在每一台需要改造的汽车上的“单机控制”系统。
来自迪沃泰克机器人官网（www.agvstd.com）的介绍是：为快速设计、交付中大型和超大型规模的重载工业移动机器人集群（AGV/AMR/Android/Robot）项目部署打造的一站式产品系列，基于机器学习、大数据、数字孪生、元宇宙和混合现实等世界前沿先进技术。简单讲就是，使用这套技术可以控制多个无人驾驶移动机器人，并实现多车之间的交通管制，协同作业。
Apollo是一套车载无人驾驶单机控制系统，INF是一套无人驾驶集群控制系统。这意味着Apollo的主要职责是控制单体，而INF的主要职责是控制所有在INF系统内的无人驾驶设备：集群。
在工业低速无人驾驶移动设备中使用类似Apollo技术的设备是AMR（自主移动机器人），通常用于工作环境友好的仓储行业，也是移动机器人行业占比最大的分支之一，当然AMR的车载系统与Apollo相比还是略微简易的。
百度Apollo与迪沃泰克INF并不是出于相同目的的竞争关系，因为其主要职责不同，Apollo主要目的是实现物理车辆的自动化运动控制，而INF主要目的是实现集群间的交通管制。当然两者之间也存在一些技术交叉项。下图列出了两者的主要责任区别和交叉内容：
Apollo使用传感器技术帮助用户实现从有人驾驶汽车到无人驾驶汽车的转换。INF（不含INF.DT）主要侧重控制无人车集群之间的交通管制和用户体验。其中地图、规划和优化三个部分为两者共同涉及的技术，但均有不同意义。INF.DT是迪沃泰克机器人的数字孪生技术，从某种程度来讲，包括传感器和运动控制技术。
地图：Apollo应用HD Map(百度的高精度地图技术)来实现精准感知导航定位，并借助Routing实现两点之间的最短路径；INF无需高精度地图，只需要普通地图来实时更新两点之间最优路径（借助INF运输优化系统），除此之外INF.ML基于深度学习多神经网络算法需要借助地图数据对交通管制AI大模型进行训练，目的是避免集群间交通管制问题，比如集群死锁。
规划：Apollo主要是根据传感器数据感知周围环境执行预测，然后根据Routing模块的长途路径（路由）给出一个短途路径规划（Planning）；INF原理相似，但无需传感器技术而是依赖INF.ML训练的AI大模型数据输入作为辅助参考（关于更多INF.ML的信息点击查看）。
优化：Apollo的优化主要指的是车体运动控制/轨迹的优化，让行车更平稳，附带一些Routing优化，主要从单体控制考虑；而INF的优化主要指的是INF RTS TOS(运输优化系统)，负责车辆集群与订单池之间的最优映射，同时交通控制系统（Routing和Planning）对映射做出响应变更，比如当你下班后INF可能会安排一辆较远的车去接你，如果你附近有更优的选择（比如有新的车完成充电可以执行任务）TOS可以取消之前的远程分配而分配一个更近的（这与有人驾驶的网约车不同，因为无人驾驶车共属于一个“利益共同体”无需担心司机多跑导致的双方利益问题，所以切换订单是很常见的在INF系统中，毫秒级别的），由于TOS做出优化，Routing和Planning需要响应优化执行变更（毫秒级别的），INF的优化是从全局考虑的。
Apollo主要使用基于传感器技术和HP Map（百度的高精度地图技术）来实现对车辆周围环境的感知（Perception）导航（NAV）和定位（Loca）的，然后基于这些数据执行预测（prediction）和（决策）规划（Planning）生成短途路线循环（路由(Routing)），Planning间接通过运动控制（Control）来控制电机，最后实现车辆的无人驾驶驱动，Apollo的各模块关系如下：
简单来讲，就是通过对周围环境的感知来进行车体控制的。Perception（感知）类似人的眼睛，Control（控制）类似人的手，而Planning（规划）充当了人的大脑，大脑将眼睛看到的信息进行分析和处理，然后通过手来控制方向盘。这也是为什么AGV行业中经常说“调度系统”是AGV集群的大脑。
在了解了基础的Apollo技术之后，我们可以来讲讲更深层次的问题了，注意，本文不对Apollo做详细解读，更多关于Apollo的深入技术可以前往其社区了解。
直接说答案：因为其当前技术水平无法处理高密度部署带来的频繁交通管制问题，最常见的或者说最关键的就是车辆间博弈（死锁/冲突/僵局，这都是一个意思，下面使用“死锁”二字表述），这里的车指的是无人驾驶车而非有人驾驶。
最开始让大众接触“无人驾驶”概念是在无人派送场景，比如互联网平台经常看到如下无人车的问题：
某快递无人配送机器人之间产生死锁，谁也不让谁或者互相谦让：
那么到底是什么原因造成这样的问题的？下面我们来深入分析。
Apollo可以借助传感器技术来避免障碍物和其他车辆，但是无法避免自己的无人驾驶车辆，这是由于路径规划（Planning/Routing）模块中可能没有对集群层面车辆死锁预防的有效处理算法。
“在开始接触Apollo时我便直奔主题：看看Apollo是如何处理死锁预防的，虽然之前已经了解到Apollo是基于预测式实现交通控制的，但还是期望能发现一些不同的或者让人惊讶的部分，尤其在交通管制死锁预防部分”，一位来自迪沃泰克机器人臭鼬小组的技术人员说到。
“但是，找遍了和规划相关的两大模块（Planning和Routing）和源代码搜索只找到了下面的一些描述：”
简单意思是当死锁Issue处理之后将取消下面的注释，这也基本说明了上面的车辆之间为什么会出现死锁的原因了，似乎这个死锁问题到今天还没有解决（注释未取消），当然这里的死锁和我们说的死锁是一个意思吗？带着好奇心该名技术人员前往社区了解相关内容，目的是看看迪沃泰克的INF系统是否可以针对相关死锁问题给出解决方案，以在未来对Apollo社区做出贡献。然而并没有找到Apollo与Apollo之间的死锁预防，最相似的“deadlock”概念是如下Issue:
该Issue明确表示Apollo （当时的版本）不（NOT）支持在路口进行侧面（对向车道）通过（过来）的“Obstades(障碍物)”监测，注意是障碍物而没有指明这个障碍物是Apollo，当然后面我们可以知道这个“障碍物”应该是包括了Apollo在内的，但是问题也就出现在这里。
“即便我们非常清楚的知道Apollo是部署在单体设备上的系统，几乎不会考虑多个Apollo之间的交通控制，他们似乎把彼此（其他Apollo）当作与其他障碍物相同的事物处理，所以我们没有找到感兴趣的东西”。
结合大量萝卜快跑出现的实际死锁问题和社区文档得出浅显的结论：Apollo没有特别用于处理Apollo集群间死锁的算法，而是把它们当作与其他障碍物相同的事物对待。而这也将导致最常见的问题：多智能体之间的博弈现象，这也是AMR集群之间难以处理的问题，也是AGV集群交通管制的世界难题，最终的结果就是萝卜快跑无法高密度部署。
结合实际情况来看，武汉几百平方公里部署了300多台萝卜，等这个数字上升到3000，1万台呢（当然一般小城市是不需要这么多出租车的，但是像上海这种一线城市的出租车和网约车容量超过10万辆，300距离10万还差的很远），随着车数辆的提升，每平方公里部署容纳的车密度就会提高，死锁问题也会随着车密度加大越来越严重，上面得知Apollo的规划算法很“简单粗暴”，根据感知和预测+红绿灯来判断“障碍物”的移动趋势避让，一旦量上来了预测失败率（下面会讲这个）就会上来。
无人驾驶的核心算法在于规划，不是控制，甚至不是感知和预测。浅显的通过对Apollo的代码量也可以得出这个结论。
Apollo总计代码量180多万行（非有效代码行，包括大括号和空行），与INF系统的■多万行相比只多了■万行，但是INF是专注于集群交通管制的，也就是Apollo的Planning和Routing的部分以及Apollo可能没有的运输优化系统（简单理解为为用户订单派哪台车的优化系统）和仓储管理系统，INF.MeTA元宇宙技术与Apollo的Dreamview+可视化调试技术有异曲同工之妙，单单从代码量上看Apollo与INF几乎是同体量的系统，但是两者的侧重点不同。
Apollo的路径规划是非常“简单”的（相对于INF系统而言），根据感知+预测来获取外部障碍的移动趋势并根据地图规划短途路径，没有“专门”考虑智能体之间的死锁问题，用这些来做死锁预防，这有两个弊端：
1，全局问题-综合故障率。预测，既然是预测就会有失败率，而一台车的失败率和300台车、3000台车、1万台车在一个时间段内的综合失败次数不是一个量级的。一旦预测失败，场景就会进入错误脱困状态机，之后就是“固定式”的等待逃生条件了。为什么说是“固定式”？因为如果多台无人车同时进入这个等待就会一直等待下去。除非安全员（后台司机）介入并驾驶其中一台或多台车离开才可以让剩下的车脱困，随着无人车部署的数量增多，这个问题会很棘手，代码中也没有发现关于这种场景的说明，甚至没有在社区的issue中找到类似的问题。
网传的萝卜后台安全员
当然，这都是可以被理解的，因为Apollo的开发人员更多的把精力放在了车辆单体的控制上，几乎很少有人会考虑全局问题，而死锁就是典型的全局问题，当然，这也跟其技术路线有关，毕竟就像上面说的，Apollo可能是把它们（Apollo）当作与其他障碍物相同的事物对待。
2，预测频率被限制。这个在后面的问题中单独分析。
只有这些就敢说无法大面积部署是不是太草率了？别急，我们继续往下看。
这不是一个可以轻易下结论的问题，因为除了百度的Apollo在海外还有一套无人驾驶系统：特斯拉的FSD，由于FSD不是开源的系统，所以我们无法获取足够有支撑的数据来进行分析。虽然迪沃泰克的INF和特斯拉的FSD都是基于深度学习多神经网络的相同技术路线，但是侧重点不同。所以该文章的大部分结论都是基于Apollo的。
Apollo似乎还“差点意思”，Apollo是靠感知+预测+HD Map来做短途轨迹规划（Lattice算法），然后控制车体，以此往复到达订单终点。为什么说差点意思，因为以上方案其实是典型的多智能体解决方案（HD Map除外）。这类技术路线目前有一个世界级瓶颈：大批量上岗带来的多智能体博弈问题，也就是上面看到的两台无人（快递，外卖，汽车）车谁也不让谁或者互相礼让谁也不走的现象，而两台车的博弈还是最简单的相比于3台车、4台车、甚至更多台车之间的博弈，我们先不讨论集群之间的博弈问题，先回过来看看Apollo的架构。首先是感知，感知不能说是无人驾驶的核心算法，应该算是基础，这个技术应该没什么大问题，毕竟这是一切的依赖输入。接下来是预测，这是一个关键算法，并且有相关指标来衡量算法的优劣：预测的成功率或者说失败率。在网上可以搜到Apollo的预测成功率：99.99％，这个数字乍一看上去很唬人，但是在工业无人驾驶场景这是一个很平常的数字（工业RFID的读写成功率就要求99.99%），说不好听的，这个成功率在无人驾驶这种场景下要求太低了，低的可怕。为什么呢，99.99％意味着平均每10000次预测出现1次失败。那么问题就来了，如果这10000次预测是在1天内进行的，那么一台车1天才会预测失败一次。但是Apollo或者说无人驾驶系统的预测会是1天10000次吗？肯定不是，无人驾驶系统把预测频率作为一项指标，用来对感知数据进行再处理，什么意思？只要外部环境发生变化（比如变化率超过1％）就必须再次进行预测，网上可以查到的Apollo预测频率是10HZ（0.1s一次），那么进行10000次预测需要多少时间呢？1000s，这意味着平均驱动16分钟预测失败一次。现在知道为什么99.99%的成功率低了吧，因为预测频率的原因。先不管它，继续分析，如果这里的99.99％这个数据是真的，那么应该是基于现实理想环境下得到的最好数据，不然宣传的应该比这个还高。当然，这不能说明16分钟就出现一次故障，相反事故率会远低于这个值，为什么？一方面车没有Routing的时候可能不用预测，另一方面大部分预测失误是不影响或者说影响较小的对车辆执行来讲，比如车道线跟随这种非常简单的规划，即便预测失误前后都没有车的情况下也没有影响，但是如果是在市区经常遇到红绿灯和需要拐弯、会车的地方，比如天津市这种全是七拐八扭的道路或者重庆市这种“奇葩”路径，这个故障率就会蹭蹭的上涨。当然，即便上涨也不会16分钟出现一次，为什么呢？就像前面说的，即便预测失败了，也不一定会出问题，比如过十字路口的时候车比较少，并且人工开的车会礼让。所以这也是为什么现实中看到无人驾驶汽车运行的还算“流畅”的原因之一。
之所以对预测式技术路线比较了解的原因是INF系统的前身就是基于时间窗预测式的（注意，现在迪沃泰克将其（时间窗预测）标记为过时的技术，不再提供搭载该技术的产品。注意，这里并没有表示其他预测式技术也是过时的意思）。AGVsTD曾经的这部分成员现在为众多世界先进的无人驾驶技术公司做出贡献，所以我们深知在随着智能体数量上涨时预测式算法带来的弊端，这还是在不考虑整体运输优化系统的优化频率的前提下，如果考虑运输优化频率，问题就更大了。
现在，我们再回到上面那个0.1s预测一次的问题上，也开始回答第2个预测式技术路线弊端，10Hz这只是从网上查到的数据，假如这个数据是真实的，那么这个预测频率稍微有点低了，0.1秒什么概念？100毫秒，40km/h市区限速，每秒11m，0.1s就是1.1米的距离，也就是说车前进1m才会预测一次。这个数据如何因人而异，需要自己感悟。INF之所以舍弃时间窗预测式技术路线是出于一些可持续发展的目标原因，简单来讲就是：INF.RTS.TOS（运输优化系统）逐渐取代INF.RTS.TCS（交通控制系统）在INF系统中的重要地位，TOS需要TCS团队提高其预测频率到几个毫秒级，以响应TOS毫秒级（基于事件）的订单池和设备池之间的优化映射变化。TCS也不是做不到，而是提高预测频率会导致预测失败率大幅上升。这在之前的文章中做了说明：
在INF工业移动机器人（AGV）的集群优化系统中也会实时预测当前系统内车辆的状态，而这个预测频率是基于事件的（几个毫秒级别）的，当然工业车辆的最高厂内限速是5km/h，而且这个预测是不会或很难传递到规划器里面做参考的，因为INF认为预测频率越高，如果规划算法不为提高预测频率而做优化的话，会直接拉升预测失败率。比如预测频率100毫秒一次，成功率为99.99%，如果10ms预测一次，那又会是多长时间导致预测失败一次呢？1.6分钟。现在知道为什么Apollo的预测频率是100ms了吧，可能它也想做高吧，但是似乎条件不允许。此外，上面我们说的都是1台车的预测成功率，那如果是100台车呢？1000台车呢？虽然每台无人车都是一个独立的个体，几乎在低密度场景下互不产生负面影响，但是系统整体的故障间隔是不是16/车数呢？当然这是把100台车看做一个整体，发现问题了吗？这意味着投放的车辆越多，综合故障频率越高，这就是典型的多智能体问题，而且随着部署密度的提高，车与车之间的故障率也会相互产生干预，必须考虑进来，尤其在集中停车点（充电区域和作业高频区域/时段）。
绕了一大圈，终于回到多智能体问题了，多智能体目前最棘手的就是集群之间的博弈问题，博弈的典型表现是车辆之间出现死锁，就是谁也不让谁或者互相礼让，当然还有车辆和障碍物博弈的。而Apollo仅仅依靠感知和决策以及HDMap（HDMap下面会讲）来决定规划继而控制车体，并没有重点考虑到集群概念，最起码现在没有。因为集群问题不是智能体单体研究的范畴。这问题就来了，如果无人驾驶算法仅仅依靠单体实现，那么现阶段是无法彻底避免集群博弈问题的。如果是无人车和有人车之间博弈，态度好的司机礼让一下就可以提供给无人车逃生脱困条件然后继续运行。但是态度再好也不能总给你礼让吧。而且如果是无人车之间的博弈呢？就有安全员和交警忙的了。
所以，解决集群博弈是无人车大批量部署的前提，而这几乎是一个世界性难题，所以Apollo可能还有很长一段路要走在大批量部署之前。
INF可以在这里做些什么？
迪沃泰克机器人致力于移动机器人集群控制技术整体解决方案，自主研发的INF.ML基于深度学习多神经网络技术可以生成用于多智能体的交通管制AI大模型（点击查看）。根据估算，INF.ML只需要不到■小时便可生成上海市6400平方公里道路的集群博弈预防模型(具体耗时取决于服务器集群算力)，将无人车部署数量提高到10万+，当然这只是估算，毕竟这种体量的多智能体控制和INF.ML所需要的算力资源（服务器集群）还无法低成本轻易获取到。
为什么INF可以如此自信呢？
其一，因为开放式无人驾驶道路的交通管制要比复杂的工业制造业的AGV交通管制更“简单”。首先前者有红绿灯作为判断，很难出现那种一个路口各种方向都可以进入的场景，而INF系统为了将集群控制系统效率拉满，取消了控制灯概念，这意味着只要空间允许，随便红绿灯什么状态、随便哪个方向的车都可以随意通行，毕竟空间够用，为什么非要等灯呢，对吧。大家在开车时有没有遇到过大马路上就你一辆车但是还要等灯的场景，心里是不是想着：这红绿灯系统怎么就不会借助传感器判断这片区域的人车状况而智能化的调整交通灯状态呢。
其二，开放式道路几乎都是单行道=>车只能往一个方向走，而INF允许双向单通道，也就是逆行，为了更快到达目的地完成订单。大家是否遇到过要去的目的地位置就在左手边拐个弯就到的对面车道旁，只要左转逆行再左转就可以到达目的地（注意遵守交通规则，这里只是举例子），而不是左拐绕一大圈再回来。所以开放式道路对INF（INF.ML）而言简直是降低了几个数量级的难度。
其三，INF.ML结合了道路网规划技术（一种在还没有进行城市道路详细规划前根据交通需求自动规划详细车道功能的技术），这一技术非常适应高速无人驾驶车辆的集群规划，尤其在高密度部署时，尤其在交通流量控制上，尤其在交叉路口的交通控制处理上。迪沃泰克机器人臭鼬小组中的技术人员甚至将INF相关技术部署到游戏《都市天际线2》的交通模组插件中进行交通和流量控制。
INF系统的运输优化系统（TOS）是INF系统的技术护城河之一，INF.RTS.TOS基于毫秒级进行车辆与订单之间的映射绑定关系，这意味着INF.RTS.TCS必须在TOS做出改变之后及时调整未来规划（Routing和Planning，无论短途还是基于订单的到终点的长途路由改变）。
INF对系统内所有智能体进行监控并根据除此之外的数十个数学模型进行交通控制和运输优化分配，INF系统所研究的技术方向早已经不是简单的死锁预防了，而是为了将运输效率提的更高，将能源降到最低。换句话说，就是萝卜快跑基础技术问题解决之后考虑的问题：如何投放更少的车、用更少的电接更多的订单，比如组合订单和拼车等，这都在INF系统中有体现。
INF专注的就是复杂场景下的集群控制，言归正传，我们继续回归高速无人驾驶话题
短时间内无人Taxi对网约车和出租车的冲击影响？
就像上面提到的，由于关键的技术问题还需要时间来解决，这不是说有多少算法工程师可以搞定的，而是一个时间问题。网约车平台会不会受到影响？必然会，但会来得慢一些。为什么？有人说Apollo不是开源的吗？网约车平台拿过来包装一下，不也就出来自己“自主研发”的Bpollo、Cpollo无人驾驶系统了吗？
既然Apollo开源，网约车平台为什么不自己做无人车？
有些在做，而有些受制于没有技术。Apollo不是开源的吗，为什么还说没有技术？这就要先聊另一个问题了：
为什么Apollo会开源？
如果这里的答复和大多数开源软件一样：为了世界技术的发展、系统安全需要被公众评估和监督，或者为了赚钱等等就显得很俗，所以我们主要从技术层面出发来回答这个问题。上面还有一个东西没有讲：百度的HD Map，这可是个好东西。很多开源软件可以盈利的原因是开源软件所依赖的一些核心技术是不开源的，所以Apollo开源的原因之一是：这不是百度的技术护城河，就像上面提到的，即便没有Apollo，也会有Bpollo，Cpollo。
Apollo之所以开源的一方面原因是为了让更多人来参与这项技术的测试以做出贡献以及接受公众的安全监督，另一方面是为了吸引更多的车企来使用这项技术，而这项技术是需要依赖百度的HP Map来实现感知导航定位的，而HD Map是不开源的。
Apollo随便用，必须搭配HD Map，当然，也可以找一些小众的高精地图来做数据支撑，但是出了问题很难说清。
我们回到网约车平台的问题上去，高精度地图制作是需要具备甲级测绘资质的，在这方面就连高德地图都没有，当然阿里巴巴有，也算是高德有了。
资质这个东西，可不是什么网约车平台都能搞到的，而Apollo无人驾驶系统的预测成功率暂时是离不开这个东西的。当然，如果特斯拉的FSD（深度学习多神经网络训练而来的无人驾驶系统）开源了，那就另说了。
但是，无人驾驶技术的落地还涉及到社会对其的接受程度响应，如果社会不接纳，无人驾驶汽车大面积部署也不会很顺利。但无论如何，无人驾驶技术在各个领域已经成为未来发展趋势，而迪沃泰克机器人也将为此做好准备，INF集群控制系统将为未来无人驾驶系统提供了优秀的集群控制的技术支撑。
INF的开源计划？
AGVsTD从一开始便存在一项关于INF系统的开源计划，迪沃泰克机器人在AGV技术领域拥有多项护城河技术，比如最坚固的INF.ML可以说是全球首个用于AGV行业的AI大模型算法平台（点击查看），即便欧洲主流的AGV技术提供商都没有这项技术。INF RTS在未来可能会开源，尤其在INF RTS Cloud大规模部署之后，为了接受安全监督以及需要承担社会和行业发展的责任时，开源是义不容辞的。
再次说明，本文仅仅是在对Apollo系统/社区做了1日浅显分析的前提下给出的，应存在一些不足之处，未来《INF市调竞析》板块会分享更多关于各领域无人驾驶技术的信息，点关注不迷路。
上海迪沃泰克机器人科技有限公司专注于极其复杂工业生产环境中的重载移动机器人集群控制技术，在全球具有绝对的产品领先地位和技术护城河。更多技术和商业信息将在后续发布或前往www.agvstd.com，也可以发送邮件到marketing@agvstd.com获取较高的合作优先级。
