•  
• EDN Europe MAGAZINE
•  
• Free SUBSCRIPTION
• Subscription Renewal
• View Media Kit

• EDN
• EDN Australia
• EDN Asia
• EDN China
• EDN Japan

Robots on the march

ROBOTICS IS GAINING MOMENTUM AS AN ENGINEERING DISCIPLINE. A VARIETY OF AVAILABLE PLATFORMS AND TOOLS SUPPORTS IT. THIS ARTICLE IS THE FIRST OF A TWO-PART HANDS-ON PROJECT EXPLORING THE TOPIC.

The term “robot” is a tough beast to define 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 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 system? How does designing an embedded autonomous or semi-autonomous subsystem, such as the braking- and traction-control systems on high-end automobiles, differ from designing what most people think of as a robot?

I’ve seen a lot of presentations, especially in vision sensing, in which the designers mount the sensor on a rigid framework and take great care to remove the possibility of any motion during data capture. It seems that these types of system 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 attempt at testing the feasibility of motion-assisted sensing to ultimately reduce growing computational workloads and to generate better data- and patternrecognition results in sensing. For this project, I attempt to build a binauralsensing system and demonstrate it as a dual-microphone, motion-assisted, soundlocalizing 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.

PLATFORMS

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, which 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 mobilerobot 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-theshelf sensors, actuators, and other thirdparty 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 lowlevel programming tips and examples (see Reference 1 on the Web version of this article).

Segway offers the RMP (roboticmobility 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; they offer a range as wide as 15 miles and a 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 petrol generator to charge the batteries while in use.

The Segway RMP includes an onboard charging system, and you can control the system 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’s development support includes using open-source-development tools and access to multiple companysupplied algorithms for managing configurations of weight and balance on the platform. Segway and Microsoft recently announced support for the platform through Microsoft Robotics Studio, an end-to-end Windows-based environment that supports the creation of robotics applications targeting hardware platforms that can host the .NET-based REST (representational-state-transfer) servicesoriented runtime environment, such as Windows CE and Windows mobile devices. The runtime component supports the development of simulated robots; of robots you control using a direct link to a desktop computer, such as through a serial port, USB, or Bluetooth link; and of 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, which must both comply with a specific set of requirements (Reference 3).

The CCR supports asynchronous and concurrent operation through a messageoriented- 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 selfcontained 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 Webbased 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 (simpleobject- access-protocol)-based DSSP supports the manipulation of a structured state and of 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-physicsengine 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 highlevel 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. But, 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 (http://mindstorms.lego. com) 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. 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 calls for LabView 7.1.

The LabView graphical-development environment includes a built-in compiler, supports real-time data-acquisition and instrument control, and comprises 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.

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 Math- Works’ Simulink environment, to model and simulate designs.

EXTENSIBILITY

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 manageable. Additionally, at this point, the long learning curve for interfacing the hardware components and creating the software controls for the RMP seemed like a high price to pay for using the RMP just for a prototype proof-ofconcept 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 randomly placed objects. The challenge would be to find modules that I could quickly set up to collect the audio inputs and to issue commands to and receive responses from the Roomba controller. I found two evaluation platforms that could act as candidates for the audiosensing 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 that support a wireless connection between them. The wireless link appeals to me because for years I have 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 which integrates 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. 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 I would have to arrange for the system to communicate through the Roomba’s serial port.

While I was exploring with National Instruments how I could use LabView with the Lego NXT, I found out that an engineer at National Instruments had recently used an NXT in a demonstration application that is 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 motionassisted 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 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 frequencydomain signal processing (Figure 3). The HiTechnic prototype board provides a physical link between the Speedy 33 and the NXT and also provides logical mapping into the NXT’s sensor-memory model.