Uber测试车为什么会撞死行人？
外国相关媒体挖掘了许多来自Uber内部的声音，其中最引人注意的是：只在意路测，忽略了模拟器上的测试。
相比之下，今年Waymo在欢庆自动驾驶里程达到5百万英里的同时，也提到了模拟器的里程数，那是翻越几个数量级的50亿英里。
不只是Waymo，许多开发自动驾驶技术的公司，都把模拟测试放在最高优先级。
Waymo自动驾驶的虚拟世界
而像Uber这样，在坦佩事故发生之后，才开始大规模开展模拟器测试，确实有些令人惊讶。毕竟，模拟器存在的意义，就是让自动驾驶汽车在上路之前，暴露出大大小小的问题，以便改进系统，提升自动驾驶的安全系数。那么，为何Uber自动驾驶的模拟测试一直是龙套？内部人员给出了一些苦涩的原因。
跑在自动驾驶出行服务 (Robo-taxis)的赛道上，Uber急于推出自家的无人出租车。整个自动驾驶团队，都处在“今年一定要落地”这样紧迫的节奏之下。
可是，模拟器测试非常消耗时间。攻城狮们需要下大功夫，给自动驾驶汽车建造一个五花八门的世界，让它在里面经受各种路况的考验。而Uber团队里，并没有太多这方面的行家，构建一个好用的模拟系统，无论从时间还是人力来看，可能都有些奢侈了。于是，在高层的决策上，Uber从一开始就没有重视起模拟器来。
谈到人力，据知情人类透露，Uber模拟测试组的攻城狮，比部门里其他的攻城狮，工资都要低。按年薪算，甚至可以相差几万美元。如此差别对待，是很难吸引厉害的攻城狮，投入模拟器开发的。就连本组小伙伴，也纷纷想要转去其他组。
这个问题，直到今年年初才有了改善。死磕模拟器的人们，终于争取到了和其他组同等的待遇。而致命事故的发生，停掉了所有路测，让模拟器变成了更加重要的练兵场，可能也让这个小组看到了一些希望。不过，即便有了外部条件的刺激，模拟系统的进展，还是绕不开内部的难题。
2015年，Uber从卡耐基梅隆大学(CMU)挖来半个机器人部门，启动了自动驾驶项目。这支团队写过一个模拟软件，那是以土木工程师用来规划城市交通的程序为基础，写成的。不过，后来加入团队的攻城狮，都觉得那个软件没什么用。
2016年，Uber自动驾驶团队来了一个新的负责人，叫做AnthonyLevandowski，姑且称他莱万。
表情包的明日之星
莱万的自动驾驶卡车公司Otto，被Uber收购了。在那之前，他还曾经在Waymo服务过。前文也提到，那里的模拟器工作很有成效。莱万试图推动公司，在模拟测试上投入更多一点。但他和Uber老人之间存在分歧，或许也是模拟系统开发在Uber遇到的一个阻碍。如今Uber用的模拟器，还是在他离职之后才出生的，和3年前很不一样。
Unreal上的塞尔达
这个模拟测试系统，依托于游戏引擎Unreal，目标是测试一些特定的操作。比如超车，比如在没有左转信号灯的路口左转等等。里面的场景可以有千千万万，比汽车在现实中能遇到的情形丰富得多。系统要摄取的，除了非常详细的道路数据，还有其他机动车、自行车和行人的动态信息。听上去很幸福，但问题在于，自动驾驶核心团队，写的代码，有时候和模拟程序并不兼容。
真插不进去
这样的话，模拟测试推进起来就有难度。模拟测试组的人类也曾经恳请核心团队，写写能兼容的程序，但对方似乎也很忙，抽不出太多时间来管这个。直到现在，模拟器也没有跟核心系统，达成顺滑的配合。于是，即便模拟系统想要给Uber的自动驾驶提供更大的帮助，可能也是有心无力。
既然，不能去公开路段测试，且模拟测器地位依然尴尬，现在Uber就把更多的注意力，放在了私人路段的测试上。
毕竟，Waymo已经在亚利桑那州，跑起自己的无人的士了。Uber早在2016年启动Roadrunner计划，也要加快步伐才行。
不过，真的不是只有路测才重要，几十亿英里的模拟器测试也重要。
来源：量子位
/2 
