我喜欢简单化和节省时间，因此实现了一种从 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 说，仿真环境为每个对象提供物理与虚拟模型，但现在缺少对声音仿真的支持，而这正是项目需要的。公正地说，微软的环境是针对机器人技术，而我只使用来自现有产品的预定机器人。但是，能将一台机器人置于某个环境中，通过直观的方法看到机器人在环境中的运行方式与功能，还是很不错的。我无法确认要花多少工作量才能设置一个机器人名单，完成对它的仿真，但很多支持的机器人平台都存在着一些基本配置，可以直接用作启动工作。看这两个环境最终能否相互补充，协同工作，将会是件有意思的事。