雷锋网：图片来自网络
雷锋网按，去年 3 月份 Uber 自动驾驶测试车在亚利桑那 Tempe 市的那场致命事故依然令人记忆犹新。经过 20 个月的漫长调查，美国全国运输委员会（NTSB）今天又公布了一份新报告，其中一些细节真是令人感觉细思极恐。
去年 5 月份 NTSB 就曾发布过一份初步报告，当时它们就指出事故的元凶是软件故障，而非硬件问题。今天，NTSB 终于用一份新报告结束了这场马拉松式事故调查，详实还原了事故发生前的最后几秒。原来，那辆撞死 Elaine Herzberg 测试车上的雷达在事故发生前 5 秒就探测到有行人经过了，但在软件设计上的一系列失误还是让自动驾驶系统慢了半拍，直到碰撞发生前 0.2 秒才踩了急刹。
错误分类闯下大祸
与大多数自动驾驶软件类似，Uber 的软件工作时也要试图对探测到的物体进行分类，将它们定义为汽车、自行车、行人或其它物体。随后，软件会根据分类计算并预测物体的行进速度及可能的运动轨迹。不幸的是，这套系统在 Tempe 的事故中彻底“崩掉了”。
在这份最终报告中，NTSB 用时间线列出了软件最后几秒钟到底在“想些什么”。面对远离人行道且推着自行车前行的 Herzberg，测试车为什么没能及时停下来？
1. 碰撞发生前 5.2 秒，系统将 Herzberg 划归为“其它”物体。
2. 碰撞发生前 4.2 秒，系统又将 Herzberg 重新归类为“车辆”。
3. 碰撞发生前 3.8-2.7 秒的时间段中，软件的分类功能在“车辆”与“其它”的分类结果中跳动了好多次。
4. 碰撞发生前 2.6 秒，系统又变了，将 Herzberg 和她的自行车识别为“自行车”。
5. 碰撞发生前 1.5 秒，Herzberg 被识别为“未知物体”。
6. 碰撞发生前 1.2 秒，她居然又被识别成了“自行车”。
这里有两个值得注意的点。
首先，碰撞发生前的几秒里，软件居然从未将 Herzberg 分类为“行人”。NTSB 指出，这是因为“Uber 在进行系统设计时根本就没考虑过那些不遵守交规过马路的行人。”
第二，一直变来变去的分类让 Uber 的软件无法准确计算 Herzberg 的轨迹，谁知她正好走在了测试车的行车路线上。你可能会觉得，既然自动驾驶系统探测到了物体，不就应该及时刹车吗？可惜，Uber 的软件不是这样工作的。
具体来说，Uber 的系统会利用探测到的物体位置推测其速度及未来轨迹。不过，NTSB 在报告中指出，“如果感知系统一直改变对物体的分类，那么软件就不再考虑物体的追踪历史了，这样容易造成判断轨迹时的混乱。”
在现实中，如果系统无法识别 Herzberg 和她的自行车是什么，系统就会觉得她处在静止状态。
碰撞发生前 5.2-4.2 秒的时间段中，系统将 Herzberg 识别为“车辆”，因此判断她处于静止状态，也不会出现在测试车的行进路线上。电光火石之间，系统更改了分类结果，并且意识到 Herzberg 正在移动，但预测她会继续保持现有路线。
碰撞前 2.6 秒再次将她分类为“自行车”时，系统再次预测 Herzberg 会继续保持现有路线。显然，系统犯下了大错，因为它没法参考追踪历史了。碰撞前 1.5 秒时，Herzberg 又成了“未知物体”，而且状态继续是“静止”。
碰撞前 1.2 秒时，她进入了测试车的行车路线，系统这才意识到事故就要发生了。
“动作抑制”
到了这个节骨眼上，想避免事故也不现实了，但一脚重刹也许能最大限度的减小对 Herzberg 的伤害，可惜她运气不够好。
对于该问题 NTSB 解释称：
“当系统探测到紧急情况时，它会启动动作抑制。这是个需要花费 1 秒钟时间的过程，自动驾驶系统会抑制计划好的刹车，此时系统会核实探测到危险的性质并计算出一个替代方案，或者直接将车辆操控权交还给安全司机。”
Uber 表示，公司“在系统中加入动作抑制程序是因为担心试验性质的自动探测系统频繁误报，给车辆带来一些不必要的紧急机动。”
这样来看，Uber 测试车的救命刹车在碰撞前 0.2 秒才踩下去，不过已经于事无补了。
NTSB 还指出，即使已经晚了 1 秒钟，系统也没有来个全力刹车。因为在 Uber 的设定中，如果事故能避免，车辆就要全力刹车，但如果避无可避，它们则更倾向于让车辆逐步慢下来并提醒安全驾驶员紧急接管。
去年，Business Insider 的 Julie Bort 也曾给出过自己的调查报告，她详细分析了 Uber 这样设计自动驾驶软件的原因：当时 Uber 自动驾驶团队正忙着准备给新任 CEO Dara Khosrowshahi 展示自家自动驾驶汽车的风采呢，因此主管要求工程师优化乘坐体验。所以，为了让 Khosrowshahi 坐得舒服些，Uber 的自动驾驶系统上线时沃尔沃 XC90 自带的 ADAS 功能（比如自动刹车或紧急变线等）会自动关闭。
当然，这背后还有其他原因，比如 Uber 雷达与自带雷达处于同频率的问题，这样很容易有干扰。
致命事故发生后，Uber 对自家雷达进行了重新设计，这样在测试时就能有个双保险了。此外，Uber 还对软件进行了重新设计，紧急情况下再也没有“动作抑制”了。同时，在物体分类改变时，软件也不会再无视过去的位置数据了。
雷锋网(公众号：雷锋网)原创文章，未经授权禁止转载。详情见转载须知。
。
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/industrynews/132984.html