Microsoft believes the demand for consumer, research, and military robots will grow significantly–and it wants to own the market.
At the annual RoboBusiness conference this past June, the software giant released the first “community technical preview” of Microsoft Robotics Studio (MSRS). Now, in its second preview version, MSRS is both a product and the lynchpin of a new educational push: the Institute for Personal Robots in Education (IPRE).
Founded by Microsoft Research, Georgia Tech, and Bryn Mawr College, the computer science and robotics program is aimed at college and graduate students. Together, the product and program are designed to bypass small, cheap robots, such as the Roomba (see “Hacking the Roomba”), in favor of a world of robots that are more complex and PC-like.
MSRS is a visual programming environment, similar to the LabView-based software provided with LEGO’s Mindstorms NXT kit. It allows users to drag and drop box-like symbols for simple, low-level behaviors and services (such as accessing a sensor) and string them together to create complex robotic programs. MSRS also uses the AGEIA PhysX physics engine, which powers many PC games, to provide a visual simulation of the robot and its environment, complete with realistic friction, drag, gravity, and other factors.
Another feature of MSRS is that it provides a method for controlling robots over a network through a PC’s Web browser. In addition to requiring Windows on the PC side, MSRS robots must use a CPU that supports Microsoft’s .NET runtime, which could rule out the inexpensive and less power-hungry processors used in many robots today.
“We’re trying to make it easier for people to write applications for robots,” says Trandy Trower, general manager of Microsoft’s Robotics Group. He says the current robotics community is too diverse, with many different hardware and software variants, to be efficient. “[MSRS is] like what Microsoft did with MS Basic,” he says, “in smoothing out the fragmentation of PC hardware.” Trower claims that MS Basic became a “de facto standard,” which then allowed developers to write to one target and use a set of common tools.
“Robotics programming is very ad hoc,” says Tucker Balch, associate professor of Georgia Tech’s College of Computing and director of the IPRE. He notes that many students in robotics often have to spend much of their time recreating solutions that already exist to basic problems (such as how to program a wheeled robot to move in a straight line).
“Each robot is a one-off new development,” says Balch. A large part of the work, he says, is making modules–software components that take input from sensors and deliver output other components can comprehend–work together. This low-level busy work can thwart his pedagogical goal: to teach 3,000 students about computer science at a high level; “so the robotics part has to be easy and robust,” he says. Compounding the problem, various sensors and other robot components are made by different companies. “At present,” Balch says, “we have to get source code and manually integrate the pieces.”
When designing an embedded system choosing which tools to use often comes down to building a custom solution or buying off-the-shelf tools.