A Standardized OS For Robots

Hugh Pickens writes "The New Scientist reports that at present, all robot software is designed uniquely, even for parts common to all robots but that could be about to change as roboticists have begun to think about what robots have in common and what aspects of their construction can be standardized, resulting in a basic operating system everyone can use. 'It's easier to build everything from the ground up right now because each team's requirements are so different,' says Anne-Marie Bourcier of Aldebaran Robotics but Bourcier sees this changing if robotics advances in a manner similar to personal computing where a common operating system allowed programmers without detailed knowledge of the underlying hardware and file systems to build new applications and build on the work of others. 'Robotics is at the stage where personal computing was about 30 years ago,' says Chad Jenkins of Brown University. 'But at some point we have to come together to use the same resources.' This desire has its roots in frustration, says Brian Gerkey of the robotics research firm Willow Garage. If someone is studying object recognition, they want to design better object-recognition algorithms, not write code to control the robot's wheels. "You know that those things have been done before, probably better," says Gerkey, who hopes to one day see a robot "app store" where a person could download a program for their robot and have it work as easily as an iPhone app."

Not entirely new

[DoofusOfDeath]

For a few years, MOOS [ox.ac.uk] has been developed at Oxford University, to separate low-level control issues from high-level issues. It runs on OS X, Linux, and Windows.

There's also IvP [moosivp.org], an autonomous vehicle control system that gets uses MOOS to abstract away the low-level details of controlling the particular vehicle on which it's running.

F.I.R.S.T

[Noam.of.Doom]

The robots built within the F.I.R.S.T competition are all built with the same basic software

Player/Stage already exists....

[rndmtim]

I built a robot for my school (City College of New York) for the Intelligent Ground Vehicle competition, and we used an open source programming environment called player/stage from Carnegie Mellon, which already has a huge number of libraries, and has a standardized driver format for sensors and other devices. It gives stuff like abstraction of motion - in other words, you draw a map, and have your navigation algorithm try to go around the map and it gives you back simulated data from your sonar, scanning laser, GPS, etc... It did save us a huge amount of time... instead of figuring out how to construct the data flow for sonar sensors we could just drop their packets in a queue... which let us move on to openCV - again, another existing open source project that already is well developed and gets you 75% of the way there. We used it for the drive system, and the position control had all sorts of generic modes for tank mode vs car mode, etc. It even starts you with some algorithms like "laser obstacle avoid", i.e., use the scanning laser and try to get around a maze. Drivers are typically in C, other stuff was in C++. And yes, it runs on Linux ;).

Right - maybe for research, not industry

[Dr. Manhattan]

I actually worked for an industrial robot company - the big robots that carry around spot-welding guns weighing a couple hundred pounds. The worst kind of bug wasn't when the system went down and the robot froze up. The worst kind of bug was an "unexpected motion" bug where the robot moved in a way it wasn't supposed to.

Safety was taken really seriously. When testing, you'd set up a tripwire fence that'd shut the robot down if it were jiggled. Every single person inside that fence had to be holding a deadman switch - let go and the robot shuts down. When I saw one of those suckers casually drag around a 500lb steel table that hadn't been bolted to the floor I got respect fast. Thankfully nobody got hurt, but at a customer site once, a badly-maintained spot welder managed to attach itself to a truck body on an assembly line. The robot kept right on going and literally threw the truck body into the aisle.

Liability's kinda critical for something like that. For unarmed, relatively weak research robots, a common platform makes sense. For higher-powered industrial robotics, this ain't gonna fly.

Microsoft Robotics Studio

[wjsteele]

It seems that someone has already thought about this. Robotics Studio [microsoft.com] has these types of features already.

In fact, I've written and demonstrated several programs that will run on a wide variety of robotics platforms without any changes in the base code itself. It's a services based architecture that is extremely flexible.

Bill

Re:Robot Virii

[Anonymous Coward]

'Virii'? Fuck you, you're a retard!

Re:Similarities in other industries

[tlhIngan]

If I may ask, is the Engine Control more chaotic because the "secret sauce" is in the physical parts? Like how Boeing and Airbus's trade secrets are all located in the wings and not the main body of the aircraft?

That I think is the reason. Think across a line of printers. Home printers have it somewhat simple (start heating up fuser, monitor temperatures, activate mechanism to feed paper, output data to laser and feed toner, etc). But a corporate printer adds in duplexers, multiple pages in-flight (often when one page is being flipped in the duplexer, the drum is free for another page to be printed, then the reverse side of the page in the duplexer, then the other page if flipped, and another page loaded...), etc. Add in multiple uses of the engine pieces simultaneously (oh, you're printing AND using the ADF to scan in?) and it gets chaotic fast. (Home MFPs often just do one at a time).

Oh yeah, and engine control is an analog process that's highly event driven - you can't activate a motor for X seconds and leave it that that - you have to use sensors to detect where everything is in the process. A piece of paper may take longer to load, or be thicker and the motors feed it in slower... or it's special paper and requires special handling. And maybe the first sheet is special, the rest in flight are normal, or another paper tray is to be used, etc.