国际无人驾驶车辆系统协会 (AUVSI) 赞助一年一度的机器人车辆竞赛。来自世界各地的学校聚集在一起，看看谁的车辆能够最快、最远地导航户外赛道。车辆对赛道的布局没有任何先验知识。

赛道由绘制在草地上的白色或黄色线条定义，机器人必须保持在这些线条内。各种尺寸的障碍物、沙坑、陡坡和急弯沿途出现，让比赛充满刺激。随着机器人沿着赛道前进，难度也会增加。除了导航路径外，机器人还必须携带 20 磅的负载，并且速度不得超过每小时 5 英里。每台机器人有三次尝试导航赛道的机会，获胜者根据所用时间和行驶距离来选择。越过线路和撞击障碍物会被处以罚款。到目前为止，还没有团队成功导航完整个赛道。

今年的比赛于 5 月 31 日、6 月 1 日和 6 月 2 日在密歇根州罗切斯特市的奥克兰大学举行。1997 年比赛的规则可以在网站 http://www.secs.oakland.edu/SECS_prof_orgs/PROF_AUVSI/rules97.html 上找到。

图 1. 赛道示意图

Robocar 是科罗拉多大学（CU）博尔德分校参加本次比赛的作品。我们的团队从儿童电动汽车开始，添加了基本的传感和控制设备，以及两台运行 Linux 的计算机和专门为 AUVSI 竞赛设计的软件。在科罗拉多大学参加这项比赛的四年里，Robocar 发生了显著的变化。本文档记录了今年 Robocar 各种系统的化身、其软件架构和导航算法。

Robocar 的基本框架是儿童车辆，经过改装——那种可以坐一两个孩子驾驶的玩具。我们拆除了原装玩具上配备的动力不足的电机，并用更大、更强劲的电机以及链条和齿轮代替它们，以提高驱动力。我们用计算机控制装置代替了方向盘和踏板，并增强了其车身结构。除了框架和外塑料外壳外，原始车辆几乎没有剩下什么。

一个倒置的金属“U”形结构焊接到前挡风玻璃原来位置上方的车身上，并在其上安装了两个摄像头。原始的挡风玻璃没有使用，因为它离地面太低，并且没有提供足够大的视野。一个用于容纳各种电路的金属盒也连接到金属“U”形结构上。

电池紧密地安装在车辆以前的座椅区域。覆盖电池的是一块木板，用于放置比赛负载。同样，在汽车后部增加了一个木制平台，用于承载我们的主计算机，这是一台带有大型显示器的传统台式机。包括我们较小的第二台计算机在内的其他设备都藏在发动机罩下，取代了原来的电池。

总的来说，这辆车的尺寸为 30 英寸宽、54 英寸长和 62 英寸高，重量超过 200 磅。实际上，经过三年的功能添加，汽车的车身已经变成了一个巨大而笨重的改装品。我们可能会在明年使用更轻的材料从头开始重建它。

Robocar 必须承受相当大的压力，因为它要穿越颠簸的赛道（草地、沙地、模拟路面、木制坡道）。需要减缓振动以获得清晰、有用的视频——尝试在崎岖不平的道路上行驶，同时通过抖动的摄像机观看，您就会大致了解 Robocar 眼中的世界。此外，我们不希望硬盘在各处弹跳；因此，所有四个车轮都配备了减震器，以帮助减少振动，并且我们机械上脆弱的设备安装在泡沫塑料上。

最后，我们用充气橡胶轮胎替换了汽车原装的打滑、僵硬的塑料车轮，以提高在草地和坡道上的牵引力。Robocar 在这些轮胎上轻松地穿过沙坑。在轮胎稍微放气的情况下行驶有助于吸收冲击。

图 2. Robocar 练习的照片。 此时，我们正在使用墙壁电源来节省电池电量，并使用操纵杆手动选择电机功率。但它确实是在自己循线行驶。与草地上喷漆的更细微的效果相比，我们的练习线是不可能错过的。

今年，Robocar 配备了大型船用电池，可以轻松为其供电七个小时或更长时间。电池成对使用，为所有执行器、传感器和计算机供电。这些是深循环电池；也就是说，它们被设计为能够承受多次完全放电和充电循环。每个 12 伏电池可以提供 550 安培的电流。即使每个电池持续很长时间，我们仍然在场边保留了两套备用电池。不幸的是，电池非常重——每个电池增加了 40 磅的重量。重量的权衡非常值得电力增益，这应该使我们能够爬上坡道，而坡道在往年给我们带来了很多麻烦。

图 3. 减震器的特写

车内有两个电路：一个 12 伏电路和一个 24 伏电路。噪声大的驱动电机和 CAN-AMP 伺服的电源与数字设备位于单独的电路上。继电器将驱动电机从前进切换到后退，并在紧急情况下切断电机的电源。电气系统图提供了更多信息。

如果 Robocar 失控，只需快速拍一下两个紧急停止按钮之一（其中一个是遥控器），即可通过断开电机与电池的连接来快速使其停止。即使汽车以每小时 5 英里或更低的速度行驶，它仍然会对物体和人造成很大的损害。我有伤疤可以证明这一点。

每个机器人都依赖执行器来作用于其世界。Robocar 有三个这样的执行器

图 4. 糟糕的鸟巢，它也充当 Robocar 的布线

为了感知其环境，Robocar 需要传感器。我们为其配备了摄像头，用于检测草地上绘制的赛道边界线；扫描声纳，用于避障；以及编码器轮，用于速度检测。Robocar 还有一些用于辅助项目的额外传感器，这些传感器在比赛期间未使用。

视觉由两个标准视频摄像头提供，并通过两个 Matrox Meteor 帧捕获器馈送。我们有两种不同的 Matrox 卡：Meteor 和 Meteor/RGB。两者都可以从多个摄像头读取并捕获高分辨率 24 位彩色图像。唯一的区别是 Meteor/RGB 可以从分离的 RGB 源捕获帧，而普通的 Meteor 则不能。即使我们可以将两个摄像头插入单个 Meteor 板，我们仍然使用两个板来实现每个摄像头每秒 30 帧的速度。Matrox 的 Meteor 板价格低廉、可靠且支持良好。

安装在 Futaba RC 伺服顶部的单个 Panasonic 声纳传感器充当障碍物检测设备。它扫描汽车前方的区域，来回旋转以覆盖更广阔的区域。使用单个声纳的优势在于消除了任何串扰的可能性，并且能够朝任何方向看。使用多个静态安装的声纳传感器无法为我们提供如此大的灵活性。Futaba 伺服系统与车辆的驱动电机一样，使用 PWM 进行控制。

编码器轮将数据返回到速度传感器，指示其转动了多远。由于我们知道车轮的直径，因此我们知道自上次检查以来它转动了多远。因此，该传感器可以计算我们在该时间段内的平均速度。传感器到编码器轮的接口是通过我们主计算机上的 CAN-PC 板。Robocar 使用此传感器来确保其速度保持在 5 MPH 的速度限制以下。

除了作为比赛车辆外，Robocar 还充当 Kevin Gifford 博士论文的试验台，该论文旨在为（可能在异世界的）自主漫游车开发一种高效的导航算法。为此选项添加了一组额外的传感器：GPS 传感器和“地图”传感器。使用这些传感器，Robocar 始终确切地知道它在哪里以及它想去哪里；它还可以规划到达那里的最经济的方式。

Trimble Series 4000 使用差分 GPS，可以进行极其精确的测量——与普通民用 GPS 相比，精度为 + 或 - 10 厘米。它配备基站、接收器和无线电调制解调器。GPS 信息通过串行线路提供。

在 Kevin 的研究期间，除了比赛和 GPS 传感器外，Robocar 还通过使用地图传感器来了解其环境。地图传感器基本上是研究领域的拓扑地图。有了这些知识，Robocar 可以计算到达一组目标坐标的最有效路径。

除了上述传感器外，我们还有一个操纵杆，用于手动驾驶 Robocar 往返赛道（或在测试场地周围兜风）。如果没有这个，我们将不得不推或搬运这个沉重的野兽——这是我们尽量避免的事情。操纵杆插入我们主机的通用声卡。

两台联网的计算机为 Robocar 提供大脑，并控制传感器和执行器。Debian Linux 1.2 版本安装在这两台机器上。

第一台是 Highlab，这是一台 Pentium 166MHz，配备 16MB RAM 和 1GB 磁盘。Highlab 中用于传感器和执行器控制的三块板是

Highlab 做出高层决策并控制所有执行器。它还执行视觉和速度感应。

Flea 是 Robocar 上的第二台计算机，是一个 PC/104 堆栈。PC/104 是通用 PC/AT 架构的可嵌入实现。它由堆叠在一起的小型（90 x 96 毫米）卡组成。PC/104 使用 ISA 兼容硬件，尽管连接器和引脚输出不同。在普通台式机上运行的任何软件也将在 PC/104 上运行。除了紧凑的尺寸外，它相对于台式机的最大优势在于其大大降低的功耗。有关 PC/104 标准的更多信息，请参见 http://www.controlled.com/pc104/

Flea 由几个模块组成：主板（来自 Ampro 的 CoreModule/486-II）、IDE 软盘控制器（来自 Ampro 的 MiniModule/FI）、数字 I/O 卡（来自 Diamond Systems 的 Onyx-MM）和以太网卡（来自 Ampro 的 MiniModule/Ethernet-II）。它具有 16MB 内存，并使用单个 20MB 固态 IDE 驱动器（来自 Sandisk 的 SDIBT-20）运行。

由于 Flea 没有显卡，因此它使用串行终端作为其控制台。我们需要修补内核才能获得此功能，因为它不是正常内核发行版的一部分。串行控制台补丁可以在 ftp://ftp.cistron.nl/pub/os/linux/kernel/patches /v2.0/linux-2.0.20-serial-cons-kmon.diff 找到

Onyx-MM 具有 48 条数字 I/O 线、3 个 16 位计数器/定时器、3 条 PC/104 总线中断线和一个板载 4MHz 时钟振荡器。Flea 使用此卡控制扫描声纳的伺服系统。Sebastian Kuzminsky 的 Linux 驱动程序可以在 ftp://ftp.cs.colorado.edu/users/kuzminsk/ 找到

Flea 的任务很简单；它转动伺服系统，ping 声纳并监听响应。当它完成机器人前方弧线的完整扫描后，它会处理并将信息发送到 Highlab。

今年的软件在 Linux 操作系统下运行，与去年在 MS-DOS 下运行的软件相比，有了显著的改进。尽管 MS-DOS 系统运行良好（我们在过去三年中获得了第三名、第一名和第五名），但它极其难以扩展、丑陋且是单片的。一旦 Sebastian 完成了我们所有不受支持的设备的 Linux 驱动程序的开发，我们就从我们的系统中完全删除了 MS-DOS 的任何和所有痕迹，并从头开始重写了代码。

功能已模块化为两种类型的程序：一个做出决策并控制汽车的仲裁器，以及向仲裁器提供有关世界信息的传感器。传感器是从骨架传感器派生的，并且易于创建。您编写代码来创建建议，连接硬件并链接到传感器库。仲裁器和传感器使用通用的配置库，这使得从命令行和配置文件解析配置信息变得容易。

由于传感器和仲裁器可以在 Robocar 网络上的任何机器上运行，因此可以根据需要简单地向系统添加和删除计算机。仲裁器在启动时使用 rsh 生成传感器。简单的命令协议允许传感器和仲裁器之间通过网络进行通信。仲裁器可以获取和设置传感器的配置，从传感器获取单个建议，设置传感器的建议速率并杀死传感器。由于我们使用不可靠的 UDP（用户数据报协议）作为我们的网络协议，因此来自传感器的确认是必要的。

传感器为仲裁器生成几种类型的建议：占用网格、当前速度和（仅用于 Kevin 的研究）航向。占用网格只是一种以网格格式表示世界信息的方式。我们的占用网格宽 6 米，高 3 米，每米有 10 个网格点。汽车位于网格底部的中间位置。网格的每个点都可以标记为三个值之一：良好（汽车可以移动到该位置）、不良（汽车应避免该位置）和未知。并非所有传感器都提供占用网格；提供占用网格的传感器仅寻找特定类型的“不良”——赛道边界（视觉传感器）和障碍物（声纳传感器）。将来，我们可能会允许传感器使用不良权重而不是单个值，以便仲裁器可以更好地在两条“不太好”的路径之间进行选择。传感器以尽可能快的速度、以指定的速率或根据需要通过 UDP 将建议发送给仲裁器。这些建议不会被仲裁器确认，并且如果网络拥塞，可能会被丢弃。这可以保护仲裁器免受发送建议速度过快的传感器的影响。建议上的时间戳让仲裁器知道建议有多旧。

用户可以使用 curses 库例程显示的漂亮菜单来配置和调试传感器和仲裁器。仲裁器本身可能希望配置传感器；例如，它可能希望更改特定传感器的建议速率或更改传感器完成的过滤类型。

在生成传感器后，仲裁器等待每个传感器连接到它，然后从所有传感器收集配置信息以供以后使用和显示。最后，它进入一个循环。在循环中，仲裁器从所有传感器文件描述符和标准输入中选择，以收集来自传感器的建议和来自用户的命令。使用这些建议，仲裁器做出导航决策并执行。

我们有几种导航算法可供选择，并且可以随时在它们之间切换。但是，我们发现最简单和最容易的一种效果最好。Robocar 只需要做出本地决策，不需要保留其环境的地图。它只需要快速利用其传感器提供的数据。

仲裁器没有单独查看所有传感器信息，而是将建议合并为一个总建议。然后，它查看总建议的占用网格部分，以查找与其自身相关的坏点。坏点可以是彩绘线或障碍物——对于机器人来说，这实际上并不重要——并且必须避免。机器人向左看，然后向右看，以找到最左边和最右边的坏点。然后，它尝试在两者之间转向。如果只有一侧有坏点，它会尝试为坏点提供宽阔的间隙——至少是赛道的一半。

这是我们可以切换到的众多算法之一，但它似乎运行良好且相当简单。当然，Kevin 使用不同的算法，这些算法考虑了当前和期望的位置以及周围的地形。我们的简单算法非常适合比赛。

参与 Robocar 项目是一次非常有益和令人兴奋的经历。没有什么比看到您构建和编程的东西自行移动更令人愉悦的了。切换到 Linux 使我们能够改进我们的机器人软件并使用我们最喜欢的开发工具。我们希望在今年的比赛中取得好成绩。但即使我们没有做到，我们也将拥有明年的良好平台，并将对构建机器人和机器人导航有更多了解。

贡献者/联系人

Robocar 团队

Robocar 比赛结果