Robots capture the imagination. With low-cost development platforms becoming more readily available, the opportunities for people to use robots for education and end applications continue to grow. The term “robot” is a tough beast to define, though, because people usually anthropomorphize these devices, thinking of them as servants or pets. Most people know a robot when they see one, but you would be hard-pressed to find a description that works all or even most of the time. For example, iRobot refers to its Roomba as a vacuuming robot, and many people have no trouble calling it a robot. On the other hand, many people have a harder time calling an autonomous automobile, such as those running in this year’s DARPA (Defense Advanced Research Projects Agency) Urban Challenge, a robot. What is the defining difference between these functionally similar systems? More important, as a designer, is there a difference in the design approach and development resources that you need to build either of these types of systems? How does designing an embedded autonomous or semiautonomous subsystem, such as the braking- and traction-control systems on high-end automobiles, differ from designing what most people think of as a robot?

Fortunately, a growing number of design resources in the robotics community do not worry about such distinctions, and they are opening the world of robotics and autonomous subsystems to a wider range of people each day. This access is important; these types of systems are the results of cross-disciplinary teams of people with a range of general and domain-specific expertise. Robotic-development platforms provide these teams with a starting point that does not require them to be sensor-, mechanical-, and motor-control experts just to begin their project. As the software-development tools continue to mature for these systems, they will allow even higher momentum in domain experts’ efforts in the specification, design, test, and deployment of these systems.

The first part of this hands-on project briefly describes the project and then focuses on the platforms and development tools I considered to implement the project. The second part, which is scheduled for EDN’s Feb 7, 2008, issue [Editor's note: Please see "Robots on the march, part two"], will present the details of implementing the project with the chosen hardware and software platform. This hands-on project will attempt to meet multiple goals. The first goal is to expose you to the resources that are available to jump-start a development team’s efforts to build autonomous systems, whether they are embedded or explicit and whether they are completely or only partially autonomous. Another goal is to explore the state of the art of these types of platforms and the development resources that support them; it is valuable to understand whether and to what extent these development resources are in or beyond an early-adopter level of maturity.

Another goal is to present the idea of sensing the world on a mobile platform rather than on a rigid platform. I’ve seen a lot of presentations, especially in vision sensing, in which the designers mount the sensor on a rigid framework and go to great lengths to remove the possibility of any motion during data capture. It seems that these types of systems are adopting greater computational loads to compensate for the data that a rigid, stationary platform cannot capture. When I was working on autonomous vehicles, my team purposely introduced motion into the sensing scenario to help us to identify and filter out sensor anomalies and to make it easier to identify what we were trying to find. This project is a first cut at testing the feasibility of motion-assisted sensing to ultimately reduce growing computational workloads and to generate better data- and pattern-recognition results in sensing. For this project, I attempt to build a binaural-sensing system and demonstrate it as a dual-microphone, motion-assisted, sound-localizing robot. In other words, the robot will attempt to use two microphones pointing away from each other and coordinating with the robot’s ability to move, to point at, and, ultimately, to identify the location of a sound source.

This project does not attempt to exhaustively identify all of the robotics-development resources that are available, because that community is continuously growing; rather, this project will identify a few mobile-robotics platforms that I considered for this project, along with the development resources that are available to support them. Check out the blog post "Embedded robotics" to read about robotic-development resources that this write-up omits. Now, let’s explore the platforms and development resources that I considered for this project.

Since 1990, iRobot has been delivering robots that perform tasks spanning from cleaning floors to disarming explosives. The company uses its proprietary Aware robot-intelligence systems to navigate around furniture and to search abandoned buildings. Versions of the iRobot Roomba that the company manufactured after October 2005 contain the iRobot Roomba SCI (serial-command interface), comprising electronics and software, that enables developers to control or modify their Roomba’s behavior and remotely monitor its sensors. The Roomba SCI protocol provides a control link to a Roomba through its external serial port via a mini-DIN connector. The SCI includes commands to control all of the Roomba’s actuators, such as the motors, LEDs, and speakers, and to request sensor data from all in-system sensors.

In early 2007, the company released the iRobot Create, a preassembled mobile-robot platform with 32 built-in sensors, actuators, and serial interfaces that is available at prices starting at $129.99 (Figure 1). The company based Create on the core technology of the Roomba, and it is compatible with Roomba’s rechargeable batteries, remote control, and other accessories. The platform includes an open-access payload bay; a 25-pin expansion port; and threaded mounting holes that can accommodate off-the-shelf sensors, actuators, and other third-party electronics, such as cameras, arms, and wireless connections to the robot.

Users can program the platform by downloading short scripts of numeric commands using a serial connection from a desktop computer or by loading programs to the command module. The processor in the command module is a 20-MHz, 8-bit Atmel ATMega168 microcontroller. The WinAVR set of open-source-development tools supports programming the command module in C or C+ +. The development tools include an editor, a compiler, and a downloader for the command module. Developers can also use Microsoft Robotics Studio, which the company released in December 2006, to program the robot. RoboDynamics’ Roomba DevTools tools allow developers to control the Roomba platform from their computers using Bluetooth, USB, or serial interfaces.

The command-module manual includes low-level programming tips and examples (Reference 1). Programming tips include using 8-bit values whenever possible for calculations, avoiding floating-point arithmetic, and using integers and right shifts instead of division. One example of these tips is to write bit masks to registers or ports to clear, start, and read the ADC because there is currently no API (application-programming interface) for function calls. Another tip describes how to debounce a button input using a timer-delay function. Performing complicated autonomous controls will entail undergoing a substantial learning curve until iRobot adds an API framework that abstracts this layer, such as through Microsoft Robotics Studio, to the tool set.

Segway offers the RMP (robotic-mobility platform), which it based on the Segway PT (personal transporter); RMP is available in a durable package for human-scale-robotics applications (Figure 2). The Segway RMP includes configurations for moving heavy payloads in tight spaces over a variety of terrains. The Segway RMP motors can continuously produce 2 hp and can peak at 4 to 5 hp if necessary, which is sufficient to carry a human-sized payload. Segway RMP models are available in a variety of battery and tire/wheel combinations and offer a range as wide as 15 miles and payload capability of as much as 400 lbs. The Segway RMP runs on one to four NiMH (nickel-metal-hydride)- or Li-ion (lithium-ion)-battery packs. Any electrical-energy source that produces 52V can power a Segway RMP. You can outfit the Segway RMP with a compact gas generator to charge the batteries while in use.

The Segway RMP includes an onboard charging system, and the system is controllable through a USB or CAN (controller-area-network)-serial-bus interface. According to Segway, the USB electrical interface hides a CAN interface behind it because the company found that providing the USB front end greatly shortens the learning curve for developers interfacing with the platform. Developers can work directly at the CAN level if they desire. The company is considering adding other communication interfaces, such as Ethernet. The company is also considering improving the mechanical interfaces, including adding threaded holes for mounting brackets. Some models include support frames for custom sensing devices and computing hardware, casters for statically stable operation, or connection points for connecting Segway RMPs to each another. In lieu of mounting holes and brackets, some developers have successfully used industrial-grade Velcro to test and attach their prototype components to the platform.

The company’s development support includes using open-source-development tools and access to multiple company-supplied algorithms for managing configurations of weight and balance on the platform. Segway and Microsoft recently announced support for the platform through Microsoft Robotics Studio. Microsoft Robotics Studio, an end-to-end Windows-based environment, supports the creation of robotics applications targeting hardware platforms that can host the .NET-based REST (representational-state-transfer) services-oriented runtime environment, such as Windows CE and Windows mobile devices. The runtime component supports the development of simulated robots; robots you control using a direct link to a desktop computer, such as through a serial port, USB, or Bluetooth link; and robots with an onboard control processor. The development environment also includes visual authoring and simulation tools. Several dozen companies, including iRobot, Lego, and Segway, have officially declared their support for the Microsoft Robotics Studio with their products (Reference 2).

According to the Microsoft Robotics Studio User Guide, the runtime environment comprises the CCR (concurrency-and-coordination-runtime) and the DSS (decentralized-software-services) components, and these components must adhere to the following set of requirements (Reference 3). It must be possible to monitor state and interact with components while an application is running. It must be possible to discover, create, terminate, and restart components while an application is running. It must be possible to concurrently deal with inputs from multiple sensors and to orchestrate such inputs as tasks without the risk of unintended interference between the tasks. It must be possible to handle both autonomous and controlled robotics applications both locally and remotely across the network. The runtime must be lightweight enough to allow execution in a wide variety of environments. The application environment must be extensible and flexible enough to accommodate interaction with a wide variety of hardware and software environments.

The CCR supports asynchronous and concurrent operation through a message-oriented-programming model that can automatically exploit parallel hardware and coordinate messages without the use of manual threading, locks, or semaphores. This approach enables designers to build more loosely coupled software modules or components. The self-contained CCR .NET DLL is accessible from any language targeting the .NET 2.0 CLR (Common Language Runtime). Microsoft built the DSS runtime on CCR, and the DSS does not rely on any other components in Microsoft Robotics Studio. It provides a hosting environment for managing services and a set of infrastructure services that you can use for service creation, discovery, logging, debugging, monitoring, and security. The DSS supports a lightweight, service-oriented application model that combines aspects of the traditional REST Web-based architecture with pieces of the Web Services architecture. DSS defines an application model that builds on the REST model by exposing services through their state and a uniform set of operations over that state but extends the application model of HTTP (hypertext-transfer protocol) by adding structured data manipulation, event notification, and service composition.

The primary goal of DSS is to provide interoperability between services regardless of whether these services are running within the same node or across the network. DSS uses HTTP and DSSP (Decentralized Software Services Protocol) as the foundations for interacting with services. The lightweight, SOAP (simple-object-access-protocol)-based DSSP supports the manipulation of a structured state and an event model, which changes to the structured-state drive. You use DSSP for manipulating and subscribing to services as a state-driven application model.

The Microsoft VPL (Visual Programming Language) graphical authoring development environment uses a data-flow rather than a control-flow programming model. A VPL data flow consists of a connected sequence of activities, which the flow represents as blocks with inputs and outputs that you can connect to other activity blocks. Activities can represent prebuilt services, data-flow control, functions, or other code modules; activities can also include compositions of other activities. VPL targets novice programmers, but the programming language may appeal to advanced programmers for rapid prototyping or code development.

The Robotics Studio simulation runtime comprises the simulation-engine service, managed-physics-engine wrapper, native-physics-engine library, and software components that interface with the physics engine and the rendering engine to represent the hardware and physical objects in the simulated world. The simulation-engine service handles rendering entities and progressing the simulation time for the physics engine. It tracks the entire simulation’s state and provides a service/distributed front end to the simulation. The managed-physics-engine wrapper abstracts the user from the low-level physics-engine API to provide a managed interface to the physics simulation. The native-physics-engine library enables hardware acceleration through Ageia PhysX Technology, which supports hardware acceleration through the Ageia PhysX Technology processor that is available as PhysX Accelerator add-in cards for desktop computers. A number of predefined entities come with the Microsoft Robotics Studio, and they expose high-level interfaces to emulate hardware and hide the use of physics APIs.

Developers can choose to interact only with the managed-physics-engine API without any visualization. To simplify inspection, debugging, and persistence of state of simulation code, however, Microsoft recommends that developers always use the simulation-engine service and define custom entities that disable the rendering. The rendering engine uses the programmable pipeline of graphics-accelerator cards, conforming to DirectX9 pixel/vertex-shader standards.

Lego’s Mindstorms NXT is the latest generation of the company’s robotic-tool sets that began with the Robotics Invention System that has been commercially available since 1998; the NXT became available in August 2006. A growing list of built-in resources, third-party resources, and professional-grade-development tools, such as National Instruments’ LabView tool kit for Lego, support this platform. This plethora of support belies a possible first impression that the NXT is merely a toy (Figure 3). In fact, Lego’s building-block approach to NXT gives the platform the mechanical flexibility that may make it suitable for quick prototyping and exploring multiple physical configurations for sensors and motion components.

The NXT brick relies on a 32-bit ARM7 processor to provide the autonomous controller for the platform. The basic system includes three servo motors with built-in rotation sensors for precise control, an ultrasonic sensor to detect motion, a sound sensor that supports sound-pattern and tone recognition, a light sensor that detects colors and light intensity, a touch sensor, and USB 2.0 and Bluetooth wireless interfaces to support development and the integration of third-party resources. Visiting the Mindstorms Web site reveals a rich ecosystem of user resources and development, including the open-source NXT firmware-, software-, and hardware-development kits and a Bluetooth-development kit. The suggested retail price of the basic system at release was $249.99.

The use of LabView as a development tool for the NXT coincided with the release of the NXT platform last year, and, along with the increasing number of platforms that Microsoft Robotics Studio supports, these tool suites potentially portend an explosion of support and tool announcements. At one level, this explosion would open programming-robotics platforms to a larger group of developers through higher level abstractions. At another level, it would enable higher productivity and the ability to leverage the efforts of third-party developers into increasingly complex and relevant robotics designs. It would achieve these goals by providing a robust mechanism for developers to encapsulate, protect, and distribute their designs for robotic subsystems. Using the LabView tool kit to program the NXT requires LabView 7.1, 8.0, or 8.20; creating native blocks for the NXT software requires LabView 7.1.

The LabView graphical-development environment includes a built-in compiler, supports real-time data-acquisition and instrument control, and includes graphical presentation tools for creating control and test applications. It supports the features of a general-purpose programming environment, such as data structures, looping structures, event handling, and object-oriented programming, through a data-flow-programming model that allows the flow of data between nodes, not sequential lines of text, to determine the execution order of the code. This approach allows developers to create block diagrams that capture multitasking or multithreaded components and can execute multiple operations in parallel if the appropriate hardware is available.

Developers can extend the functions of LabView with add-ons that address software optimization; data management and visualization; and deployment to various hardware targets, including FPGAs. Other add-ons address signal processing and analysis; automated test, image acquisition, and machine vision; and control-design and simulation industrial control. Hundreds of third-party add-ons include those interfacing with third-party tools, such as the MathWorks’ Simulink environment, to model and simulate designs.

A common theme across all of these platforms is the support for extensibility, not just for custom and third-party software modules, but also for hardware interfaces and subsystems. Each of these platforms offers the mobility I desired for this hands-on project, but I would need to extend these platforms with hardware and software to add a binaural-sensing capability and for directing the movement of the platform in response to the audio inputs.

Unlike the iRobot Create and the Lego NXT, the Segway RMP includes the ability to sense its orientation and inertial motion, which I believe will be essential for performing sound localization in production units. However, this hands-on proof-of-concept project aims to find out whether coupling even coarse-level motion control with binaural sensing makes the problem of sound localization more tractable. Additionally, at this point, the long learning curve for interfacing the hardware components and creating the software controls for the RMP seemed like a hefty price to pay for using the RMP just for a prototype proof-of-concept project. This problem left the Create and the NXT as platform candidates.

My initial focus was on the iRobot platform because I had acquired a Roomba for use in an earlier project (Reference 4) and because the Roomba has algorithms for navigating around a room with uncertain placement of objects. The challenge would be to find modules that I could quickly set up to collect the audio inputs and issue commands to and receive responses from the Roomba controller. I found two evaluation platforms that could act as candidates for the audio-sensing and high-level-controller subsystem for the project.

One of these platforms, the Texas Instruments eZ430-RF2500 development tool, includes two USB-stick-sized development boards, which support a wireless connection between them (Figure 4). The wireless link appeals to me because I have for years wanted to do a project with one, and it appears that adding wireless to a design is finally approaching the level of adding a module to the system instead of building one from components. One of the boards gets its power from the USB connection with a host computer, and the other connects to and accepts power from a battery case. The boards host a 16-MHz, 16-bit MSP430F2274 microcontroller, which provides sufficient processing capacity and a 10-bit, 200k-sample/sec ADC, which is fast enough to acquire the audio inputs.

The other platform, the C8051F064-EK evaluation kit from Silicon Labs, features a 25-MIPS, 8-bit C8051F064 microcontroller with dual 16-bit, 1M-sample/sec ADCs to acquire simultaneous samples from both of the audio inputs (Figure 5). The evaluation board can accept power through the USB link with a host computer and includes a BNC and front-end circuitry to condition the analog signals for each of the two analog inputs. However, to use either of these boards, I would have to build hardware interfaces and software drivers for the microphones and to communicate through the Roomba’s serial port.

While I was exploring using LabView with the Lego NXT with National Instruments, I found out that an engineer at National Instruments had recently used an NXT in a demonstration application similar to an electronic “sheep dog,” which would perform an action, such as turn left or right, stop, or go forward, based on the sound it heard. This feature differs from performing motion-assisted sound localization, but knowing the details of that project could allow me to use it as a reference design and save me valuable time in configuring a setup to perform this hands-on project.

Another reason that I chose the NXT system was the immediate availability of already-identified and appropriate modules that I could interface to the NXT system. Coupling National Instruments’ Speedy 33, a Texas Instruments TMS320VC33-based DSP board, with the LabView DSP module and a sensor prototype board from HiTechnic resulted in a configuration that combined all of the appropriate hardware to do this project. The Speedy 33 integrates two microphones that are approximately 5 in. apart, with 48-kHz sampling, and, with the LabView DSP module, provides access to a library of data-acquisition and -analysis virtual instruments for time- and frequency-domain signal processing (Figure 6). The HiTechnic prototype board provides a physical link between the Speedy 33 and the NXT and also provides a logical mapping into the NXT’s sensor-memory model.

Part 2 of this hands-on article, scheduled for Feb 7, 2008, will delve into the details of working with the NXT platform and the development resources to accomplish sound localization with motion-assisted binaural sampling. If time and space allow, I will also try out and share the experience with the Microsoft Robotics Studio modeling and simulation facilities.