Forgot your password?
typodupeerror
Robotics Programming IT Technology

A Standardized OS For Robots 184

Posted by timothy
from the kill-all-humans-until-done dept.
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."
This discussion has been archived. No new comments can be posted.

A Standardized OS For Robots

Comments Filter:
  • 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.

  • Kinda of already do (Score:5, Interesting)

    by Spiked_Three (626260) on Tuesday August 11, 2009 @09:11AM (#29022351)
    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.
  • by damburger (981828) on Tuesday August 11, 2009 @09:18AM (#29022431)

    To an extent, anyway.

    I was doing my final year AI project, and had read about the role the cerebellum plays in human movement and physical sensation. I tried to create a program that would abstract the physical nature of a small Lego robot such that a neural network trained to avoid obstacles in a computer simulation could be transferred into the robot, and function without further training.

    The implementation was, I admit, less than brilliant. But hearing others think along the same lines reassures me a little that the concept wasn't quite as nutty as I had feared.

  • by flyingfsck (986395) on Tuesday August 11, 2009 @10:02AM (#29022951)
    This guy wants to see a Robot App Store. Nothing wrong with SourceForge for your favourite GNUbot Apps...
  • They got trolled. (Score:3, Interesting)

    by vlm (69642) on Tuesday August 11, 2009 @10:11AM (#29023069)

    I think "New Scientist" was trolled. The concept makes no sense. Sure it wasn't an Onion article?

    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.

    Here's a top secret copy of "std_robot.h":
    (blank space here)

    No parts are common to all robots. Roombas and toys operating on extremely simplified flowcharts plus a touch of randomness, remote space exploration vehicles that are semi-autonomous, those battle-bot things that are just human controlled R/C cars with weapon hardpoints and are not real robots, hydraulic arm industrial welding robots, lynxmotion-ish multi-leg crawlers powered by servos, G-Code programmed numerically controlled lathes and milling machines, and last but not least RC airplanes converted into UAVs. They all have the general idea that something electronic controls something mechanical. Beyond that vague idea, what they all have in common is... Umm ... yeah, nothing at all, thats it.

    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."

    Why an app store? Why not:

    http://sourceforge.net/search/?type_of_search=soft&words=robot [sourceforge.net]

    Why would it work as easily as an iPhone app? All iPhones are "the same" more or less. In the future, why would all robots be the same?

    Mystifying how the article got it so wrong.

  • by foniksonik (573572) on Tuesday August 11, 2009 @10:57AM (#29023699) Homepage Journal

    I have the distinct feeling that there is a misunderstanding of the intent of the article.

    What is being called for is an SDK which will apply to a multitude of hardware platforms. Call it an OS, call it an API either way it isn't the BIOS equivalent aka firmware. The firmware manages the motors, turns on and off power to sensors, fans, power supplies, etc. Additionally you would have driver equivalents to provide base operating routines for specific modules of hardware ie: a "hand" driver would provide instructions telling the fingers of the hand to contract or extend. These are not things that need to be made common, nor can they. Certainly they would also benefit from a standardized methodology but that is not the topic today.

    What is being called for is that the makers of the drivers and the firmware provide a common set of hooks as an abstraction layer and that some higher level OS be developed which knows about said abstraction layer and can interoperate with it, pass instructions to it and generally manage when and what the drivers or the firmware instruct the hardware to do.

    This 3rd level of abstraction (firmware, drivers, OS) should have an Open SDK. Individual drivers may or may not be open - up to the manufacturer (think printers, video cards, etc) how much community support they feel will benefit their product.

    With an Open SDK independent developers can write software for multiple hardware platforms potentially with several versions which take advantage of available hardware which is not universal.

    So for example I could write a program that tells a robot how to perform a particular dance move. I'll call it the "electric slide" - my instructions will tell the robot to move forward 4 units, shake an appendage, move back 4 units shake, move forward 2 units hop or shake, slide left with some easing then start over. How the robot accomplishes this feat is up to it's drivers and firmware... tracks, wheels, 4 feet or 2 feet - but I could add in some checks to discover each type of mobility and enhance the movement routine to make each mobility type perform the movements with slight adjustments to add "character" to the dance.

    Additionally my dance may need to be updated so I'll add in an update function which will download the latest version and prompt the owner to install it (never auto install). Each device may have it's own internet connection capability - some will have wifi, some 3G, some will connect through their base station while recharging and others may need a USB drive plugged in with the update. I shouldn't need to write my own TCP stack, WiFi handler, etc. my app just asks for an outside connection and the platform gives me back what is available.

    Hopefully this has clarified something for someone.

  • Technical vs. Legal (Score:4, Interesting)

    by Dr. Manhattan (29720) <sorceror171&gmail,com> on Tuesday August 11, 2009 @11:50AM (#29024447) Homepage

    Having a common software platform which has been tested and debugged across multiple projects should result in more reliable robots exhibiting fewer errors.

    Sure, that makes sense from a technical perspective. The problem is the legal perspective... because "fewer errors" does not equal "no errors". Bugs will still happen. And who takes responsibility when a bug results in a robot suddenly whipping around and killing someone? (We just talked about OSS & liability last week on Slashdot [slashdot.org].)

    So, would you contribute to such a project when you might get summoned to court years later because someone misused a function you wrote, somebody died, and the developer blamed you? Even if you prove that it wasn't actually your fault, you're still out legal fees and time and stress. (And that's assuming you really didn't make a mistake...)

    I recognize that this is a common FUD tactic against Linux. But Linux isn't generally used in situations where people could die if it fails. I'm not sure, given the legal landscape, any open-source OS could work in such situations.

  • by C0L0PH0N (613595) on Tuesday August 11, 2009 @02:29PM (#29026907)
    I think the classification schemes for the animal kingdom can provide insight for robotic development. The robotic community should pay attention to billions of years of evolution, and mine all the information possible :) There is a lot in common across all animal nervous systems (nerve conductors, synapses, brains, muscles, etc). Take the animal system for the eye for example - muscles, structures, nerves, synapses, and a brain to interpret. At the most fundamental levels, there is commonality in the types of cells used by animals. But there is incredible diversity in how they are implemented. One might compare the building blocks of the nervous systems to the robotic components, the way these components "work together" as the robotic OS, and the universe of ways they are implemented in animals as the "programs". Animals are categorized into Kingdom, Phylum, Class, Order, Family, Genus, and Species. In a very mature robotic development environment (many years from now), will we have similar classes of robots, with a set of category-specific OS subsystems and components? For example, the industrial robots mentioned above which are capable of accidentally moving a half-ton object as if it were a piece of paper will need a different OS subsystem than the Roomba, which is mostly harmless. Robots moving in water or air will belong to different categories, etc. Ultimately, if the animal system is a good model, robots will have some things in common, and much that is unique to their category.

Your own mileage may vary.

Working...