Robots, Incorporated Continued

At Microsoft, even the lowliest new programmers have their own offices, and buildings on the company's sprawling Redmond, Wash., campus consist largely of corridor after corridor of individual offices, each with a large window equipped with blinds for privacy. Except, that is, for one particular corner of the third floor in Building 113. There you'll find a large open space—the Broom Closet—with a couch, easy chairs, a coffee table, a giant LCD television, and more robots, robot accessories, and robotic toys than you thought existed.

There are iRobot's Roomba and Create robots, of course. Attached to another robot are a radio and antenna, small stereo speakers, and some kind of sensor attachment that looks for all the world like a small coffeemaker. There's also the Traxster, a robot made by Summerour Robotics Corp. of Atlanta, which has wheels that run in tracks, as on a tank, and optionally includes vision sensors connected to an articulated neck. There are joysticks, keyboards, and remotes of various kinds; a low, circular, wheeled robot that looks like a cross between the Roomba and a blue ladybug; several Lego Mindstorms robots; a black-and-white spaceman robot that looks handmade; and a green-and-purple stuffed dinosaur. When I ask whether the dinosaur is a robot, Ioana Butoi, a 26-year-old Romanian software engineer on whose desk it sits, answers shyly, “No. But it could be.”

Setting up shop in what was assumed to be a utility closet was the idea of Tandy Trower, manager of the group and its sole office dweller. “I wanted a small group that spent time together,” he says. “Good things happen in small groups of people who talk to one another a lot.”

In late 2005, Trower cherry-picked its members from every area, including two engineers from the first team to work on the Xbox, another project in which Microsoft tried to do something completely different. Today, the Xbox is the heart of the company's $4 billion entertainment division.

The idea for the robotics group came from several different sources. The first was Craig Mundie, the company's chief research and strategy officer. Back in 2000, he took a broad look at trends in computing and the Internet. What he foresaw was a “sea-change of increasing complexity. There would be processors everywhere,” he says. Computation would be distributed across different processors in a single chip, a single device, or across a network, local or otherwise. Processors would be loosely coupled; that is, they would come and go at will. And computing was moving to a services-based model, meaning that software would increasingly be written for a network cloud—a company's network or the Internet itself—instead of individual computers.

That's just the opposite of what happens on a PC, where a single processor is in charge; peripherals ask to be connected and disconnected and in between have to request some of the processor's valuable attention. We're all familiar with a print job or a Web browser timing out because the printer or a remote Web site doesn't respond quickly enough. Now imagine the timing and attention problems a robot will have—the feet want more information from the eyes before deciding where to step, while the eyes can provide that information only when the next step is taken. Or there might arise two unrelated but equally critical tasks, such as walking beside a hospital patient and simultaneously regulating the flow of her intravenous medications.

In programmer-speak, each of those tasks is a thread. A conventional program can run only a single thread to completion or put it on hold while another thread runs. In a computer with multiple processors, or a single processor with multiple cores, more than one thread can run simultaneously, each taking in a stream of data from a set of sensors and responding to the data in some way. But there's still the problem of coordinating the two threads and the responses. A thread managing the hospital patient's heart rate might tell the thread managing the IV drip to stop one of the medications from flowing.

To work on such problems, Mundie put together a team of researchers, known as the Advanced Technology Incubation Group. They came up with something called a concurrency and coordination runtime (CCR). The CCR hides the complexity of managing multiple threads simultaneously by letting programmers create a software object called a dispatcher, which can manage multiple threads (typically one for every processor in the computer) and assign scheduling priorities for each one. The CCR even lets a programmer create multiple dispatchers, which are managed through a class of objects called arbiters. Other tools in the CCR let threads share data or claim it exclusively, pass data from one thread to another, and let one thread command another to do something.