使自动驾驶汽车的Teleop安全

一辆卡车滑落到州际公路。司机抬头超速而感到震惊-这辆自动驾驶卡车没有司机！在前面，一只鹿跳进卡车的车道，并在数百英里外要求遥控操作员控制车辆。但是他们无法及时赶到–鹿跳得太快，或者遥控操作员还无法了解情况，甚至更糟：蜂窝连接不够好！

担任StarskyRobotics首席执行官时不时出现这样的情况，他的远程自动驾驶卡车理应正好面对这样的情况。然而，这是完全错误的情况。

正如我之前所写，安全并不意味着一切都可以正常运行，实际上恰恰相反。确保系统安全是要深入了解系统将在何时何地发生故障，并确保这些故障是可以接受的。

正如您可以不断测试雷达是否正常工作一样，您也可以通过蜂窝连接进行相同的操作。您可以将具有足够连通性的路由列入白名单，这样，如果您处于死区中，就知道某些地方肯定出了问题，并且转弯是适当的。最终，您可以围绕人类态势感知的局限性设计整个Teleop产品-在Starsky，我们发现，要态势感知卡车需要10秒钟，并且该窗口内的任何紧急情况都需要由卡车本身解决。

电信安全性的大多数谴责源于可用性启发法-这种观念认为，如果可以回忆起某些事情，它必须比不容易回忆的事情重要或至少重要。几乎每个人都亲身经历了糟糕的蜂窝连接性，而且这总是特别令人沮丧。另一方面，很少有人对雷达，LIDAR，GPU或高级相机的故障感到恼火。

当然，遥控汽车的连接会出现问题，就像激光雷达会失败并且机器学习模型会吐出不好的结果一样。安全关键型系统从来都不是完美的，为此目的，无线通信是无与伦比的-您还需要围绕它构建安全案例。

那个安全案例远没有大多数人想象的那么困难。电信系统的两个经常失败的组件是连接性和远程驱动程序。对于前者，您可以轻松编写有关所需连接级别的规范，进行测试以验证它们，然后根据逻辑确定，如果系统开始失败的测试，它将终止。如果您能够控制系统的运行位置，则可以使所有这些操作变得容易得多，从而为您提供良好的连接可能性。

在围绕远程操作员进行规划时，主要问题来自产品设计。正如我的Starsky联合创始人在此指出的那样，对于以更高速度进行直接远程操作而言，延迟成为一个更大的问题（因为恒定的延迟会导致在命令和执行的命令之间传递更多的距离）。在Starsky，我们通过设计所谓的“有监督的自治”解决了这一问题，其中远程驾驶员可以从有限的离散行为列表中进行选择（例如左车道变更，减速5英里/小时等）。这种方法不仅减少了延迟，而且每次远程驱动程序下达命令时，我们都会创建低维决策数据，最终将这些数据用于训练更高级别的AI（如果有ROI）。

我曾经与一个同龄人进行坦率的讨论，那个同龄人告诉我，自治公司有两种类型：那些不重视无人驾驶的公司和那些使用遥控的公司。

随着AI幻灭的低谷不断加深，我认为将会有越来越多的人意识到，不仅对将人带离车辆有用，而且安全是安全的。