Slashdot Mirror
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."
So, you want an iRobot so you can have access to the AppStore
The line to kill me for the bad pun starts at the door, people.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
That's all we need....a standardized API to allow malware writers access to robots...
seems obvious
This is not the greatest
This is actually quite interesting for me, since we've gone through (or are going through) a similar thing in the MFP (Multi Functional Peripheral (Printer/Scanner/Copier/Fax machine)) manufacturer industry. While it may be much less glamorous than the world of robotics, we do essentially need to deal with a lot of the same concepts.
Essentially, an MFP has two main "parts" to the firmware. One is Engine control, which tells all the physical bits how and when to move, temperature control for the fuser, paper take-up, feeding mechanisms, electrostatic charging, laser control and so on. The other is the "user" part, where we deal with how to access networks, interpreting print jobs, user authentication systems, file format conversion, user interface and so on.
The "user" part generally is pretty standardised for each individual manufacturer across the manufacturer's range. As a base, it's not uncommon to run things on an RTOS such as some flavours of Linux or VxWorks.
For the "Engine Control" part however, it's a lot more chaotic. Almost every machine from every manufacturer is going to be vastly different with code being rewritten many times for what is essentially doing the same thing, just with a bit of different hardware. My day job is as a developer for these things, but pretty much exclusively in the "user" part of things and I haven't even touched the Engine control. I do however talk from time to time with the engine guys, and they're in DESPERATE need of some standardisation. Personally, I'd love to see standardisation across the industry, but I doubt it'll happen. If we ever do get there (which they appear to be heading towards, slowly), we'll probably end up with a different solution for everything in each different manufacturer, which is the current state of play for the "user" part also.
My book about LSD and Self-Discovery
Also on facebook as: DroppingAcidDaleBewan
10 PRINT "Destroy all humans!"
20 GOTO 10
"Give someone a program, frustrate them for a day... Teach someone to program, frustrate them for a lifetime."
As far as I know we don't have a standard OS for cell phones, do we? The problem with robots is the huge variations in platform ability. And I personally sure don't want a least common denominator solution. With the PC, you had one kind of hardware, the IBM PC, that everyone cloned, and that made a common OS a lot more practical. Cell phones & Robots have taken a completely different path so far. Yes, I dabble in robots - a hitec RoboNova. It's fairly limited as to processing power, but comes with an adequate RoboBasic language. If I really wanted to do more serious things with it, I would bolt on a PC (yes they have them for it now). In that respect, there is already a common OS available - the same common OS that any PC can run. And yes, it will run DOS, Windows and/or CE, and linux - pick your poison.
slashdot troll = you make a compelling argument I do not like the implications of.
Robotics is at the stage where personal computing was about 30 years ago,' says Chad Jenkins of Brown University.
So, completely free of AOLers, women, and social skills? Ah, the halcyon days.
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 ;).
Though I will worry when the most purchased robot app is "machinegun control".
I will worry more when this project leads to a situation in which there is little or no diversity in the robot OS. Then the outsiders will be like us Linux users today, but worse off.
"Oh, you use Debian instead of Windows For Robots? We don't serve your kind here"
Thank for reading to the sig. You may stop reading now. It is safe. There is no more content. Why are you still reading?
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.
PHEM - party like it's 1997-2003!
It's a hard problem, I've also worked on for the last several years. You're combining research problems in AI, computer vision, localization/mapping, motion planning, human interaction, etc.; each of which demands high end hardware to run its computations, but then you want to do it on mobile platforms with tight constraints on power and sensors.
Then in order to modularize things you have to come up with a generic interface for each piece in order to abstract it. I think this aspect in particular kills reusability, because these pieces are all so interdependent. Each module needs internal state from the other modules to interpret its own data, and depending on the implementation used for each module and the actual robot hardware it's running on, some types of data may or may not be available, and some outputs may or may not be possible. It's a combinatorial explosion of different capabilities, which leads many people to write to their current hardware and their own specific implementations.
I entirely agree to make progress we need to address this issue. Asking every researcher to reinvent the wheel in all of the related fields before they can work on their own piece is ludicrous. And it doesn't help that many implementations are very sensitive to robot specific parameters, so even if a research publishes his code for a problem (which IMHO should be part-and-parcel of publishing results), you might still have a hard time running it on different hardware where sensor or motor models differ or may not even apply.
Microsoft Robot A.I.:
./createOmelet ./createOmelet -s -c -p -t ...Compiling an omelet with Sausage, Cheese, Peppers, and Tomatoes!!! ... ... ... ... ... ... ... ... ... ... ...
INPUT: Make me an omelet.
--Are you sure you would like an omelet? {YES / NO}
---MSROBOT is trying to access your refrigerator. {DENY / ALLOW}
----MSROBOT is trying to access your eggs. {DENY / ALLOW}
----MSROBOT has broken an egg and must be shut down. {Send Error Report / Exit}
Macintosh Robot A.I.:
INPUT: Make me an omelet.
-chord-
-outputs an eggwhite omelet made with organic cheese, soymeat, and fresh tomatoes.
INPUT: Add some sausage.
iROBOT: DID YOU KNOW? Sausage contains cholesterol and transfats, so iRobot does not support Sausage!
Linux Robot A.I.:
$ Make me an omelet.
make: *** No rule to make target 'me'. Stop.
$
Usage: createOmelet [omelet-options]
where omelet-options are -s (sausage), -c (cheese), etc.
$
roboTux:
roboTux: Cutting Sausage..
roboTux:
roboTux:
roboTux:
roboTux:
roboTux:
roboTux:
roboTux:
roboTux: Cutting Sausage... DONE!
roboTux: Shredding Cheese...
roboTux:
roboTux:
roboTux:
roboTux:
roboTux: ERROR: Unable to find CHEDDAR.CHEESE. Please consult your refrigerator administrator.