机器人在前进之二：开发工具中的可复用性软件模块

　　机器人开发平台的进展主要集中在如何让开发人员着手工作，但它们也提供更急需的软件部件重用方法，如从一个机器人项目到另一个机器人项目。

　　要 点
　　设计者有很多现成可用的机器人开发平台。
　　机器人平台的工具正在逐步成熟，但仍有路要走。
　　机器人开发环境使设计者能够快速完成设计到测试思想的重复。

　　玩具、游戏和“真实世界”应用之间的界限正在模糊。原本针对严格真实世界应用的技术却不断在更大规模的电动玩具、小器具和计算机游戏市场上找到自己的用途。与此同时，娱乐设备中的新型工程创新有越来越多的机会流入真实世界的应用。对于很多低价消费电子产品（如娱乐装置），消费市场现在能接受的产品支持寿命周期远小于那些高价产品，如汽车、其它车辆、工业与医疗设备，以及大型中心办公室设备等。这些消费电子产品的较短支持寿命周期允许（甚至要求）用更高级技术进步来鉴别其工作。

　　为了制造工业机器人和半自动系统，开发人员使用的技术正日益跨越工业技术与消费、家用技术的边界，如电动玩具、小器具、游戏机和其它个人娱乐设备。不幸的是，与 上世纪80 年代初的 PC 类似，今天机器人的软件兼容性仍有很大的改进余地。去年以来开始出现的公开式机器人开发平台试图解决更快启动机器人设计项目的问题。实现这一目标的部分方法是提供一种开发软件部件的机制，设计者可将其用于一个机器人项目的开发，然后在其它机器人项目中获得重用。自从本动手项目的第一部分发表以来（参考文献 1），我又多知道了两个公开的机器人开发平台，一个来自 CoroWare，另一个则来自 Gostai（见附文“更多平台”）。

　　机器人开发平台及其不断成长和发展是实现今天和未来项目复杂程度的增减，使其达到某种可控水平以保持设计者生产率的重要基础。本动手项目主要关注 Lego NXT Mindstorms 平台与 National Instruments 的 LabView 环境。我也在微软的 Robotics Studio 上花了一些时间。

　　项目

　　本项目的硬件清单依据是 Brady Duggan 的一次展示，他是 National Instruments 的一名软件工程师。Duggan 演示了一个用于电子“牧羊犬”的非官方参考设计。他使用了别人已在类似项目中用过的硬件配置，其价值是能为快速启动和运行提供极大的帮助。硬件配置包括National Instruments基于德州仪器公司 TMS320VC33的Speedy-33 DSP模块，它连接到一块来自HiTechnic公司的原型板。该板再连接到Lego NXT控制器，后者控制Lego积木块简单平台的传动电机（图 1）。

　　Speedy-33有两个间距约5英寸的话筒，电路板支持48kHz的话筒采样。LabView支持对电路板的直接编程，如同LabView支持的其它硬件部件一样。Speedy-33用作机器人的耳朵。因为我需要在短时间内了解有关声音的更多信息，因此决定Speedy-33只作为一个传感器，然后把数据送给NXT。项目后续内容将包括实现两个单元之间的双向通信，这样声音探测算法可以在判断声音信号相对机器人的位置时，混合来自机器人平台的信息。

　　为简化项目的复杂性，我选择了一个800Hz的声源，它在整个测试期间都保持可辨别。选择这个频率的原因是：参考算法的实验表明，系统在较高频率下比低频有更高的成功率，如440Hz。只寻找一个音调使 LabView DSP模块包中的DSP函数更容易使用。实际上，算法会将话筒信号与目标频率作交叉关联，通过比较各个话筒峰值的采样点，确定相对相位差。对于以后再做的项目，系统的终极目标是采用机器人平台的运动反馈，在一个多噪声环境中探测到任意声音信号的相位差，能检测出预定的任何信号。为实现这个终极目标，机器人平台必须探测出自己的惯性位置，这样在平台旋转或移动时，就可以准确地将运动传送给检测算法。这种功能需要为机器人平台增加陀螺和加速度传感器，如HiTechnic公司的产品。

　　HiTechnic原型板基本是Speedy-33 接口与 NXT 接口之间的一个桥梁，这样，不需要在 NXT 上建立新的代码就可以实现两个部件的连接。原型板可以使设计者建立自己的传感器，并更简便地将其与 NXT 使用的物理接口与逻辑接口相连接。HiTechnic 板对 NXT 表现为遵循 NXT 传感器协议的定制传感器。对本项目，我使用了六个数字端口，用于从 Speedy-33 向 NXT 的通信。Speedy-33 有一个密封的外壳，可支持多种外设的端口。但要用到六个数字 I/O 端口，我就必须从外壳中取出板子，否则就无法连接数字 I/O。不过，本项目不必对 HiTechnic 原型板作直接编程。

　　我喜欢简单化和节省时间，因此实现了一种从 Speedy-33 ; 到NXT 控制器的单向通信。我知道建立一种双向通信方法会花时间，并增加对调试阶段的需求。Speedy-33 会在检测到目标声音时报告出声音的左、右方位。NXT 控制程序必须知道 Speedy-33 是否刷新了记录，因此我将六个数字脚中的两个用作计数器，其它四个脚表示从左至右之间的某个位置，四个脚可表示声源的 16 个位置。这种方法使 Speedy-33 只有在听到目标声音时才发送一个更新，并且当出现一个新的声音位置更新时，机器人控制器负责作出识别。

　　如 Speedy-33 一样，我用 LabView 为 NXT 编程。但是，在为它们编程之间存在着微妙但却重要的差异。LabView 并不像 LabView 系列中的那些普通硬件部件一样正式地支持 NXT。如要用 LabView 建立 NXT 代码，就必须将程序结构用作 NXT 工具集插件。即使是普通的程序结构（如循环与比较）也必须来自插件工具集，而不是普通的位置。这种限制仍允许你打开和固定住与 NXT 专用工具集菜单，这样便于使用，而不会误打开用于其它目标的工具。

　　NXT 装有一只 32 bit ARM (www.arm.com) 处理器，为该系统提供了大量的处理能力。由于 Speedy-33 的检测算法只有在听到目标声音时才会更新方向信息，因此 NXT 可以在两次方向更新之间显示状态信息或保持空闲。使用这个检测算法时，声音越接近两只话筒的等分位置，就越难以判断声音的方向。这种现象的部分原因是声源到达每只话筒的时间差小于采样速率。对本项目，这种情况是可以接受的。这种现象亦表明，由于机器人一直在调整，声音的方向也越来越接近两只话筒的中心。因此，随着被检声音的方向与两只话筒距离的接近，电机的运动也应越来越小。否则，运动粗放的机器人会在两个位置之间来回弹跳。

　　建立软件

　　使用 LabView 开发环境需要花点时间适应。我的编程经验主要以基于文字的编码为主，如使用 C 语音和汇编语言。指导软件有很大帮助作用，尤其是它们帮我熟悉了工具资源的访问位置和意义。National Instruments 已经对 LabView 的开放环境进行了 20 多年的改进，并且增加了很多针对特定领域应用的环境扩展工具。LabView 的虚拟仪器工具可用于数据采集、显示与分析，很容易使用，你可以为数据分析与纠错设定完备的显示，这是 LabView 环境的优点之一。

　　在上世纪 90 年代，我曾用过 LabView 的一个早期版本做过一个可调激光控制系统。我那时用虚拟语言工具做了一些编程工作，但多数还是用 C，因为我发现很难过渡到一个完全虚拟的编程形式。经过对当前项目的仔细思考，我可以说明为什么这种过渡对我这么难。几年来，我已经形成了在代码“空白”处说明含义与设计信息的编码风格。换句话说，代码的意图、空行的位置，以及长指令串或复杂指令串的分行，等等，这些都能给熟悉软件开发决策方式的读者提供有价值的信息。
我从来没有开发过一种在虚拟编程模式的空白中提供信息的类似方法，也不清楚业内对这种策略的方法，当然我还没找过。
在做这个项目时，我可以看到开发人员如何使用左右和上下程序流，在空白处表示出含义和其它信息。

　　使用 LabView 和微软的 Robotics Studio 这种虚拟编程模型，可以更容易给出有关并行性的信息，而在文本式编程中要更困难。你可以确定排序结构的位置，这样就能看到它们可以同时运行，并且可以更容易看到它们是否在共享某些资源。这两种环境都可以混合使用虚拟编程与基于文本的编码，即将基于文本的代码封装为块，再用于虚拟环境。Robotics Studio 教程中有一个例子提出了有关虚拟编程的一个担忧。该例表示如何不采用原来方式而实现一个前述实例，该例原使用了一个变量和一个循环。我猜由于自己缺乏虚拟编程的经验，因此看循环就与重写代码一样，但如只看代码结构，当循环不很明显时我还是一筹莫展。

　　我很喜欢用 LabView 环境仿真机器人，并且，虽然可以将 LabView 与 MathWorks 的 Simulink 环境链接起来，但我未能对本项目尝试这种方法。另一方面，我可以下载微软的 Robotics Studio，并立即开始一台机器人的仿真。不幸的是，据微软高级开发人员 Kyle Johns 说，仿真环境为每个对象提供物理与虚拟模型，但现在缺少对声音仿真的支持，而这正是项目需要的。公正地说，微软的环境是针对机器人技术，而我只使用来自现有产品的预定机器人。但是，能将一台机器人置于某个环境中，通过直观的方法看到机器人在环境中的运行方式与功能，还是很不错的。我无法确认要花多少工作量才能设置一个机器人名单，完成对它的仿真，但很多支持的机器人平台都存在着一些基本配置，可以直接用作启动工作。看这两个环境最终能否相互补充，协同工作，将会是件有意思的事。

　　用于 Robotics Studio 的虚拟编程工具不像 LabView 环境那样成熟，但工具运行良好。当执行某些代码时，我注意到了 Robotics Studio 中的一个有趣的问题。一个教程演示了有关循环以及将文字转换为语音的方法。听到系统的计数很有意思。但是，如果我在程序执行时实现一个上下文开关，则让人不安的是程序有时会混淆编号顺序。换句话说，消息传递会表现为后进先出，这样，如果系统在接收一条消息时碰巧很忙，消息就可能丢失，而在乱序情况下，后面会死锁在前面的消息上。这种怪异现象可能是语音合成块的特性，但却是一种不希望出现的行为。如果与我使用的代码相比，乱序执行不太明显，则这种类型的行为可能影响调错阶段。

　　还有一个有关 Robotics Studio 开发环境接口完备性的例子，它出现在我在一个派生对话框中间向另一个程序作上下文切换时。当对话框在副窗口中时，有时候我无法回到对话框中，而副窗口也会锁死，等候着派生窗口的结束。在 Windows XP 中对话框并不出现在任务栏上，不过我终于明白可以用 Alt 和 Tab 键手工选择它。

　　本项目只是一系列项目中的第一步，我希望能挨个完成，逐渐增加复杂性，要实现的终极目标是用一个立体检测系统在噪声环境中辨别出一个任意声音。除了项目的目标与价值以外，开发平台的使用也提供了一个机会，能够验证开发人员现在可以使用的资源，辅助复杂机器人控制系统的开发工作。一种常被表述的目标是：开发人员应能够设计出一种公共的硬件规范，然后能够在跨多种机器人平台上通过运行时绑定使用这一规范，而无需重新设计。

　　我很高兴有现在这些可用产品，也期望今后几年所有这些开发平台会有一系列后续动作，它们对于新机器人项目的启动，以及使开发人员能够重用以前项目的软硬部件都做了很好的工作。我尤其高兴的是，有些开发环境正将这些系统看作一组可以互相交互的分布式系统。对于那些建立包含多机器人协同工作系统的设计者来说，这一特性将成为一个重要能力。

参考文献
1. Cravotta, Robert, “Robots on the march,” EDN, Dec 3, 2007, pg 44, www.edn.com/article/CA6505566.

　　附文：更多平台

　　自从本文第一部分印出以来，我知道了另外两个机器人开发平台：CoreWare 的 CoroBot 和 Gostai 的 URBI（通用实时行为接口），CoroBot 是一种四轮滑移转向平台，带一只彩色摄像头、IR 距离传感器和 1.2 GHz PC 级处理器，运行 Windows XP、Xubuntu Linux，也可以两者同时运行（图 A）。设计者可以在产品的塑料顶板上钻孔，作永久性固定，还可以接受多种粘接物（如 Velcro 魔术贴）作临时固定。系统为开放式，简化了对其多个部件的访问，但将其使用限制于室内环境。它的重量为 12 lbs，可以接收最多 5 lbs 的负荷。

　　CoroBot平台有九种型号，起价为2799美元，向开发人员供应。对于预装Windows XP的型号，软件开发可以采用微软的Robotics Studio，而对预装Xubuntu Linux的型号则使用Player。平台现可选双靴型和可选四 DOF（自由度）臂并带一个抓头传感器。带臂型号有24 个可用伺服端口，无臂型号有30个可用伺服端口。现在没有能够支持平台的C 或C++库，但该公司称它正在评审PlusPack for Microsoft Robotics Studio，以支持未来的开发。

　　Gostai正在将自己的产品URBI脚本接口语言定位成一种用于软件模块的通用机器人平台。它在客户/服务器结构上工作，可远程控制一台机器人或任何复杂系统。URBI给出了一种通用方法，能够控制一台机器人、通过插入软件部件而增加功能，并且以一种轻便的方式开发出完全交互的复杂机器人应用。该平台能用于多种机器人系统、操作系统和编程语言，如C++、Java和 Matlab。

　　Gostai 将面向对象的 URBI 基于一种原型方案，允许开发人员定义纯 URBI 的对象，或者用向核心中插入 C++ 类或“UObjects”，为语言增加类，成为原生的 URBI 类。你甚至可以从核心中拔出 UObjects，将其运行为远程自主应用，从 URBI 引擎获得 IP（互联网协议）地址作为一个参数。

　　URBI 语言中有一个重要考虑因素，那就是在语义的核心中集成了并行与事件。URBI 语言支持四种类型的命令间临时约束条件。一是 Task B 必须在 Task A 后面执行。第二个是 Task B 必须在 Task A 结束时开始，而第一个约束条件允许两个任务之间有一个时间间隙。第三个约束是 Task A 和 B 必须同时开始，即，如果一个任务还未准备好，则另一个要等待前一个准备好后才开始执行。第四个约束是 Task B 的开始必须同时或晚于 Task A，但其开始不得晚于 Task A 完成前。

　　由于 URBI 是一种并行语言，它可以用互斥（互斥-排除）技术处理并行访问，保证一个时间只有一种代码能使用某种资源。URBI 支持七个混合模式，它们设定了系统应如何处理冲突性与同步任务问题。一个混合模式的例子是加法与混合模式，它将冲突任务的计算加到或平均到结果值上。队列模式实现了一种经典的互斥机制。

　　为提供更好的并行支持，时间概念成为 URBI 语义中的一部分。例如，URBI 中的一个简单任务可以使一个变量在一个给定时间里或以某个给定速度达到一个值，否则就设为一个正弦振荡。这些非瞬时的任务可以与其它设定同时执行。举例来说，考虑任务 neck.val=10 time:450ms&leg.val= -45 speed:7.5 & tail.val=14 sin:4s ampli:45;。这个任务使用 "time," "speed," "sin," 和 "ampli" 修改任务完成的方式。在本例中，"neck.val" 的值将在 450 ms内达到10。其它支持的修饰语有 "phase," "getphase," 和 "smooth."。

　　URBI 自身能够加快并行事件的处理速度，因为多个事件可以并行发生，并触发一些可以并行运行和重叠的代码。实际中，对 URBI 中一个事件作出反应的最简单方式是使用 “at” 命令，它看似 “if” 语句，即当检验为真时执行一条命令。不过，与 “if” 不同的是，”at” 命令会保持在后台作再次触发，而并不终止。另一种这类工具是 “whenever” 语句，它循环执行命令，直到检验为真。该语句类似于 “while” 语句，不同的是当检验为假时它保持在后台。语言还可以忽略有参数或没有参数的事件。