[人工智能]STAIR: Hardware and Software Architecture

Abstract

斯坦福大学人工智能机器人(STAIR)项目旨在生产一种可行的家庭和办公室助理机器人。作为朝着这个目标迈出的具体的一小步，我们在2007年AAAI移动机器人展上展示了一个演示视频，展示了STAIR 1机器人对一个口头命令做出反应来取物品。

完成这项任务涉及多个组件的集成，包括语音对话、导航、计算机视觉对象检测和机器人抓取。本文描述了用于促进这些组件开发的硬件和软件集成框架，并将它们组合在一起进行演示。

Introduction

在AAAI 2007移动机器人展上，我们展示了STAIR机器人进行取订书机的演示视频。在本文中，我们描述了这个演示背后的硬件和软件集成系统。我们发现，拥有一个一致的软件框架对于构建一个像STAIR那样复杂的机器人系统至关重要，它包含了从语音对话到导航到计算机视觉到机器人操作等组件。在本文中，我们描述了我们的一些设计决策，以及在构建这样一个系统中所学到的经验教训。我们也描述了具体的技术细节，应用这些想法，让机器人取物品，以回应口头要求。

Hardware Systems

由STAIR项目建造的前两个机器人被简单命名为STAIR 1和STAIR 2。每个机器人在移动基座上都有一个机械臂，但这些机器人在许多细节上有所不同。

STAIR 1

如图1所示，这个机器人主要是使用现成的组件构建的。这个机器人被建造在一辆Segway RMP-100上。该机器人手臂是Katana6M-180，在位置控制臂的末端有一个5个自由度的平行的板夹持器。

在本文描述的演示中使用的传感器包括一个立体相机、SICK激光扫描仪以及一台PTZ摄像机。另一台SICK激光扫描仪安装在机器人顶部的平移电机上，获取机器人前方物体的三维点云。

大多数传感器都安装在一个用螺栓固定在Segway 底座上的铝制框架上，我们没有使用Segway 的自我平衡功能。相反，我们建造了一个额外的铝框架，在机器人的前面和后面分别加了一个轮子，这样机器人就能保持静态稳定。这样做是为了在紧急停车时避免损坏，代价是增加机器人的占地面积几英寸。

机器人由12伏深循环电池供电，由一系列DC-DC转换器提供机器人各子系统所需的各种直流电压。装有车载自动充电装置的12伏电源轨道可以起到不间断电源(UPS)的作用。在移动实验中，如果切断交流电源，机器人的电脑和传感器也可以继续工作。电力系统允许在典型负载下运行大约两个小时。

板载计算由一台运行Linux的奔腾- m机器和一台运行Windows的奔腾-4机器提供。这些机器通过一个板载以太网交换机连接，并通过一个802.11g无线桥接到整个building的工作站。

STAIR 2

STAIR 2平台如图2所示。轮式基座(包括机器人的底部10英寸)是由斯坦福生物机器人实验室的鲁本·布鲁尔设计和建造的。这个基地有四个可操纵的炮塔，每个炮塔包含两个独立驱动的轮子。因此，平台可以在任何方向上完整地平移、原地旋转或同时平移和旋转。机器人坐标系中的理想动作由专用的XScale处理器(在Gumstix Verdex板上)转换成运动指令。

这个平台使用了一个巴雷特WAM手臂，它安装在一个铝制框架上建立在轮式底座的顶部。WAM手臂是一个力控手臂，有七个自由度，还集成了一个三指手。

我们使用专用的板载Linux PC来控制手臂。机器人还有一个Bumblebee2立体摄像头，另外的机载计算由第二台Linux机器提供。

电源和网络系统类似于STAIR 1:一个以太网交换机连接板载计算机，一个802.11g无线桥接提供与机器人板外(更大)计算资源的连接。

Software Systems

我们在STAIR上所做努力的重要部分包括 设计和实现一个支持机器人软件开发的框架，以便实现诸如获取订书机演示等应用程序。

许多其他研究人员在这个领域工作，设计了著名的机器人框架，如Player/Stage (Gerkey, Vaughan, & Howard2003), CARMEN (Montemerlo, Roy, & Thrun 2003), MCA (Scholl, Albiez, & Gassmann 2001), Tekkotsu (TiraThompson 2004), Microsoft Robotics studio等。

在研究了这些现有框架之后，我们认为我们的平台和目标与其他框架的设计者的平台和目标有很大的不同，他们认为实现一个专门构建的框架是值得的。

Requirements

并行处理

我们的应用程序运行一个单一的、大型的、高能力的机器人，并需要进行大量的计算。我们的软件有硬实时和软实时的约束，也可以执行较长的运行规划和场景分析任务。机器人的板载计算资源不能支持所有所需的计算，因此我们必须将计算负荷分散到板外机器上。

模块化

因为STAIR项目涉及到数十名研究人员，他们对庞大的代码库做出了贡献，因此加强软件组件之间的模块化是很重要的，这样组件就可以尽可能独立地调试和验证。

跨平台

我们大多数可用的计算资源是以Linux工作站和服务器机架的形式存在的。但是，机器人的传感器中也有一些是二进制Windows驱动程序。因此，我们的系统必须同时运行Linux和Windows操作系统，并且需要跨平台通信。

Robot-independent

因为我们运行的两个机器人有完全不同的硬件，所以软件必须尽可能独立于机器人。一些软件模块作为设备驱动程序，因此与硬件绑定在一起。然而，尽可能多的软件模块应该只在独立于硬件的抽象上操作，以限制代码库的大小和复杂性。

代码优美

与任何大型软件项目一样，保持代码的整洁和流线型会使机器人的研究进展明显更容易。

设计选择

为了满足上述需求，我们构建了一个名为Switchyard的库，它支持通过用户定义的、特定于任务的软件模块之间的连接图传递消息来进行并行处理。

模块化是通过操作系统进程模型来实现的：每个软件模块在某个CPU上作为一个进程执行。选择TCP协议进行消息传递，因为它在所有现代操作系统和网络硬件上都受到支持。它的操作本质上是无损的，因此只需要更简单的解析器，无需处理重新同步。

从美学的角度来看，这个库是以c++类的形式存在的，每个模块都通过扩展来提供所需的功能。

网络、路由和调度代码不会出现在软件模块中，因为它们是由超类提供的。

这使得大多数模块只有很少的样板代码。

这些设计选择当然是有争议的。事实上，我们目前正在设计另一个机器人软件平台，该平台基于从当前框架中吸取的经验教训。不过，为了完整起见，我们将提供Switchyard的设计和操作细节，正如在AAAI 2007移动机器人展上展示的演示视频中所使用的那样。

消息传递的拓扑结构

Switchyard在现有的联网机器集群上建立一个虚拟计算机集群。术语虚拟集群指的是在机器人运行期间，网络上的机器子集将作为一个内聚组cohesive group进行操作。

Master Server 主服务器

选择虚拟集群中的一台计算机作为主服务器。

重要的是，主服务器并不处理流经虚拟集群的所有流量。这将产生星型网络拓扑结构，对于机器之间具有异构连接的网络，这种拓扑结构的效率非常低。

作为一个具体的例子，考虑一个STAIR机器人，它使用一个板载以太网交换机连接机器人上的几台机器，并使用一个无线桥把这些机器连接到建筑物的网络，而建筑物的网络又由许多以太网交换机连接更多的机器。无线链路两端的机器之间的吞吐量很好，但在机器人穿过建筑物时，无线链路上的吞吐量通常很慢且速度可变。主服务器必须驻留在无线链路的一端，如果它要处理所有数据，无线链路将使整个虚拟集群的吞吐量陷入停顿，特别是在无线链路两端的子网上存在大量数据流的情况下。

主服务器只用于自动启动和关闭虚拟集群。 软件模块之间发送的数据有效负载在点对点TCP连接上流动。在启动时，主服务器加载所需连接图(“虚拟集群”的拓扑)的XML描述，并自动化其创建，如下一段所述。

进程启动

一个简单的进程启动程序在虚拟集群的每台机器上运行。作为命令行参数，该程序接收主服务器的IP地址及其虚拟机名称(不需要与IP主机名一致)。然后，进程启动程序连接到主服务器，宣布它的名称，并返回要启动的进程列表。

这一步只是为了方便，如果需要手动启动进程(例如，在调试器中)，则可以将其排除在自动启动列表之外。

进程连接

Switchyard进程是通过主服务器的IP地址、虚拟名称(不需要与可执行文件名一致)和可用的TCP端口号来调用的。

进程在它们指定的端口上启动一个服务器，连接到主服务器，宣布它们的名称，并接收其他进程的列表，以建立对等连接。然后这些流程自动连接到它们的对等节点，并可以开始生成和消费数据。

数据流

相对于任何其他模块，Switchyard中的数据流总是单向和异步的。发送方 (或上游) 节点在准备就绪时发送数据块。每个数据流可以有任意数量的接收器。数据总是以有意义的块或quanta流向下游节点，并且不能在逻辑上进行细分。quanta的一些例子是图像、激光扫描、地图、矩阵或航点列表。

虽然每个quanta可以被分割成更小的单元(即图像和矩阵可以被分割成行或块)，但下游节点可能必须在处理开始之前重建原始逻辑单元(例如，图像或矩阵)。因此，为了减少接收节点的代码大小和复杂性，Switchyard一次只发送整个quanta。

为了保存样板代码，数据流模型被写成一个抽象的c++类。这个抽象超类包含传输任意大小的字节块所需的所有网络和排序代码。派生超类是为了在系统中创建每种类型的数据流。当前正在使用的数据流类型包括：

• 2D、3D和6D点
• 2D路径
• 粒子云(用于定位)
• 图像和深度图像
• 用于导航的网格地图
• arm(配置空间)坐标和路径
• 文本字符串
• 音频片段
• 其他简单的tokens(用于排序)

每个子类只包含将其数据序列化为字节流所需的代码和在显示其字节流时反序列化自身的代码。这些方法是作为 c++ 虚函数实现的，这允许高级调度代码调用序列化和反序列化方法，而不需要知道实际传输的是什么。这种c++多态的使用显著地减少了代码的大小和复杂性。

由于计算图是异步运行的，所以每当一个进程准备将数据发送给它的下游同伴时，它就会调用一个框架提供的函数，其作用如下：

1. 数据流子类中 的serialize虚方法 用它的 字节流表示 填充 buffer。
2. 数据流子类报告其quanta的字节流表示的长度。
3. 字节流大小通过TCP发送到下游。
4. 字节流本身通过TCP发送到下游。

在数据流的下游，框架做以下工作：

1. 接收字节流大小并分配足够的空间，如果必要的话，来接收它
2. 字节流本身被接收并存入buffer。
3. 数据流子类中的反序列化虚方法 重新创建数据结构。
4. 调用虚函数通知接收进程数据结构已更新。

为了避免竞争，每个数据流都有一个互斥锁，该互斥锁在inflation和处理每个数据流quanta期间自动锁定。因此，数据处理代码不需要是可重入的，这有助于简化其结构。如果进程没有完成对前一个quanta的处理，框架将静默地丢弃传入的quanta。

Data Flow Registration

在Switchyard进程的初始化过程中，数据流必须被实例化并注册到框架中。这通常是通过进程构造函数中的一行c++代码 (针对每个数据流) 完成的。

如果进程将在此流上生成数据，框架将采取以下操作：

• 数据流名称被复制到框架数据结构中，框架数据结构将 为 【即将传入的订阅了此流的】TCP连接 路由。
• 当其他(接收)进程连接到这个(发送)进程时，套接字句柄被存储在传入连接所请求的数据流中。
• 当这个(发送)进程希望在此流上发送数据时，框架调用deflate虚拟方法（如上一节所述），并将生成的字节流发送到此流的任何和所有活跃的TCP连接上。

如果进程将接收流上的数据，框架将采取以下操作：

• 一个线程被分离出来处理数据流；
• 这个线程尝试通过TCP与产生数据流的进程连接。
• 一旦连接上，线程就宣布它希望接收的数据流。
• 线程解析数据流并调用用户代码来处理每个传入的quanta，如上一节所述。

通过这种方式组织行为，整个点对点连接方案可以由框架自动完成。这节省了大量在每个进程中重复(且易于出错)的联网和代码排序。

端口配置

许多机器人软件模块都有启动参数。例如，地图服务器可以访问许多地图文件，激光扫描仪可以配置为各种分辨率，等等。遵循在Player/Stage框架中设置的先例，图形XML文件本身可以选择包含启动参数，这些参数在运行时将覆盖每个进程中硬编码的默认值。

Operation

要运行一个实验或演示，必须执行以下步骤：

graph设计

必须在graph XML文件中描述可用来运行实验的机器，以及它们的主机名或IP地址。接下来，必须选择或编写实验或演示所需的软件进程。在列出机器和进程之后，进程之间的连接必须用XML定义。

作为一个具体的例子，下面的XML图形文件将视频从一台计算机路由到另一台计算机，并允许远程PTZ控制:

当这个图运行时，它将导致计算机1上启动两个进程，计算机2上启动一个进程。一旦进程启动，它们将自动连接到彼此，数据将开始流动。

云台(PTZ)摄像机控制图

图3显示了这个简单图的可视化。它允许计算机1(通常在机器人之外)查看视频流，并命令摄像机平移、倾斜和变焦。摄像机设备驱动程序在计算机2上运行(通常在机器人上)，视频作为单独的jpeg压缩图像在网络上传输。

获取项目演示涉及的图要大得多。如图4所示，该图涉及在3台机器上运行的21个进程，其中两台在机器人上，一台在机器人外。模块化软件结构允许在更小的，甚至微不足道的图形中（并行）开发许多这样的模块。这种方式的单元测试减少了开发时间，并有助于隔离bug。

这个框架的异步特性也显示在图4中。如果图是同步操作的，那么图中的循环会产生潜在的死锁。

为了简单起见，框架没有强制同步：任何和所有同步行为都是使用局部状态变量实现的。

框架用法:“获取订书机”

本节将讨论如何使用软件和硬件系统来执行获取一个项目的演示。在这个演示中，用户口头要求机器人取一个物品(订书机)。根据这个口头指令，机器人导航到包含物品的区域，使用计算机视觉对象检测找到它，应用学习的抓取策略来捡起物品，最后导航回用户那里交付物品。

图4显示了本演示中使用的组件的详细组织。计算机1是一台外置Linux机器，计算机2是板载Windows机器，计算机3是板载Linux机器。

(每个进程名后括号中的数字表示它运行在哪台计算机上，图中的边表示TCP数据流的方向。)

使用的过程被大致细分为5个主要分区(如图所示)，由大约4-5个基本不相关(但合作)的研究团队使用Switchyard实现。

口头对话

我们现在描述STAIR的口语对话系统，具体地说，它使用Switchyard实现。(另见Krsmanovic et al. 2006)。音频麦克风过程连续记录音频，并流到 sphinx_transcribe，使用CMU Sphinx语音识别系统连续识别语音。当系统识别到命令时，它将命令传递给中央计划器的fetch_item_director进程。在演示中，STAIR对命令的口头确认是使用Festival语音合成系统生成的，由在机器人上运行的tts_Festival过程生成。

导航

一种导航系统，使STAIR能够在室内环境中导航和打开门，（详见Petrovskaya &2007 Ng)。在这个演示中，我们替换了软件的某些部分，以提高其在不断变化的环境中的速度和健壮性。我们的实施使用了基于voronoi的全局规划和VFH+ (Ulrich &Borenstein 1998)，以避免局部障碍。如图4所示，导航和定位模块使用不同的流程来流化激光读数，执行定位，生成低级命令来控制Segway基座，等等。实时性要求较高的过程一般在机器人(计算机3)上运行;在更长的时间尺度上运行的进程，如Voronoi规划器，在更强大的外部机器(计算机1)上运行。

目标检测

(Gould et al. 2007)开发了一种 foveal-peripheral视觉目标检测系统，该系统使用可操控的云台 (PTZ)摄像机获取被识别物体的高分辨率图像。由于在高分辨率图像中目标检测明显比在低分辨率图像中更容易，这大大提高了视觉目标检测算法的准确性。(请注意，相比之下，如果我们对从互联网上下载的图像进行目标检测，通过这种方式获得高分辨率、放大的图像是不可能的。)

在我们的演示中，快速舷外机(计算机1)负责操纵我们的机器人的PTZ摄像机，以获得选定区域的高分辨率图像，并运行目标识别算法。一个板载机器(计算机2)被用来运行负责控制摄像机和拍摄/流图像的低级设备驱动程序。我们的目标识别系统是使用(Serre, Wolf， &方法2005)中描述的图像特征建立的。

抓取

为了抓取物体，机器人使用了Saxena开发的抓取算法。机器人使用立体摄像机获取要抓取的物体的图像。使用对象的视觉外观，学习的分类器然后选择一个好的“抓取点”——即，这是一个很好的三维位置，在这个位置可以尝试拿起物体。该算法在大量标注的各种家居物体的自然图像和合成图像上进行抓取点的训练。

尽管该训练集不包括订书机，但学习到的特征集足够健壮，可以推广到订书机。摄像头和机器人手臂的低级驾驶员在机器人(计算机2)上运行;寻找抓取点的较慢算法在舷外运行(计算机1)。机器人执行订书机抓取的一个例子显示在5中。

Conclusion

在本文中，我们描述了允许STAIR机器人执行取订书机演示的硬件和软件系统。Switchyard软件框架为跨进程通信提供了一套统一的约定，并允许不同的研究团队为许多不同的模块并行地编写软件。使用Switchyard，这些模块可以很容易地同时执行，并以分布式的方式在一小组机载和外部计算机上执行。