A Standardized OS For Robots 184
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."
Can't wait (Score:3, Insightful)
Though I will worry when the most purchased robot app is "machinegun control".
Re:Can't wait (Score:4, Insightful)
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"
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:2)
When the time comes, we'll need to add a fourth law of robotics: Stop fingering my wife! [theonion.com]
Re: (Score:2)
Though I will worry when the most purchased robot app is "machinegun control".
I'll only worry if it starts to beat sales of BJ.app or GuaranteedOrgasm.app
Re: (Score:2)
Sorry, but it has to be said... (Score:5, Funny)
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.
Re: (Score:2, Funny)
Re: (Score:2)
Just imagine a world of robots running the iFart app....
They're called Robosapiens and they're for sale at every toy store.
Re: (Score:2)
Yes, but that's just an ancillary to it's new ability to break the three laws.
crush kill destroy is the base fall back (Score:2)
crush kill destroy is the base fall back
Robot Virii (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
"That's all we need....a standardized API to allow malware writers access to robots..."
Any system can be hacked, and who's to say malware kinds of people won't have THEIR OWN robots and hardware that doesn't even run legit software in the first place?
Re: (Score:2)
That won't happen until we have Windows RE. (Yep, Robot Edition!)
I actually read that as Windows Reboot Edition.
Re: (Score:3, Funny)
How is that different from every Windows Edition?
Re: (Score:2)
Your windows is not connected to a bunch of servos and motors that allow it to move around.
Re: (Score:2)
"That won't happen until we have Windows RE."
Great, now even your robot will catch a virus.
Hush... (Score:2, Insightful)
Re: (Score:2)
This is a huge sucky problem already. I don't deal with robots per se, but with all kinds of other manufacturing tools which are all controlled by PCs (or by PLCs which connect to PCs.) Some have the PCs built into the body of the tool.
Making a tool designed to last 20 years dependent on a PC designed to last 5 and an OS supported for 3 insures lots and lots of problems. This would be a great place for Linux, yet all the tools I see use DOS or Windows PCs (even the new ones.) What this means is that compani
Re: (Score:2)
Somebody already did... (Score:2)
Obviously you have not heard of the Microsoft Robotics Developer Studio http://msdn.microsoft.com/en-us/library/bb648760.aspx [microsoft.com]
I've not had a chance to use it, but as a product that has come out of the research wing of Microsoft, it may actually be quite good. Now, if only it ran on Linux....
Android (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
An android not able to have emotions? Say what? [wikipedia.org]
Similarities in other industries (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:3, Informative)
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 wh
Re: (Score:2)
I take it that you do not consider CHAOS to be a standard?
Finished... (Score:5, Funny)
10 PRINT "Destroy all humans!"
20 GOTO 10
Re: (Score:2, Funny)
Re: (Score:2)
Enough c4 can do it more effectively.
Re: (Score:2)
What programming language could it be? Io? Are you sending the "Destroy all humans!" to the print message of the integer 10? I don't think print takes such arguments... Oh I get it it's ruby and somebody made integers take parameters?
Re: (Score:2)
What programming language could it be? Io? Are you sending the "Destroy all humans!" to the print message of the integer 10? I don't think print takes such arguments... Oh I get it it's ruby and somebody made integers take parameters?
Maybe I'm not seeing the obvious sarcasm, but just in case you're serious, that would be old-style BASIC (I know at least GW-BASIC, not sure what other variants required line numbers).
Re: (Score:2)
The sarcasm is that I'm sick of reading these BASIC jokes, can't we move to modern languages please? what about
>>> for human in humanity: robot.destroy(human)
Re: (Score:2)
10 PRINT "Destroy all humans!"
20 GOTO 10
True story: I was walking my dog just the other day in my neighbourhood and decided to take a different route home. Came across a house where there was a miniature train track circling the front of the property (no trains were running) and saw what I first thought was one of those Roomba-type vacuum cleaners, except that being outside, I had to conclude it was for mowing the lawn.
Stood there a while amused as hell listening to the weird "Vroom" noises the bright yel
Re: (Score:2)
The lawn mowing robots that are otherwise functionally similar to Roombas have been around for pretty much as long as the Roombas have. Since you mention this being a bright yellow machine, I can identify it as the Robomower from Friendly Robotics.
It sounds like something was not working right, since after reversing it should be rotating before moving forward, so as to get around the obstacle.
Re: (Score:2)
30 ???
40 PROFIT!!!
Kinda of already do (Score:5, Interesting)
Right - maybe for research, not industry (Score:5, Informative)
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.
Re: (Score:2)
I bet the deadman switch did not depend on software or firmware of any kind.
Unless the processor is safety rated, safety should be ensured via hard-wired
electronics.
Re: (Score:3, Insightful)
Having a common software platform which has been tested and debugged across multiple projects should result in more reliable robots exhibiting fewer errors. You've described one of the best potential applications for this software.
Technical vs. Legal (Score:4, Interesting)
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.
Re: (Score:2)
But isn't there a simple way out of such legal mess? Some company/consortium takes snapshot of a product that is otherwise free/oss, polishes that version, pushes through certification process, and anybody wishing to have that level of certification/legal protection buys support from them?
Re: (Score:2, Insightful)
It doesn't mean that you don't test it or that you test it less. It's simply means that other people will be testing it as well.
Re: (Score:2)
We did. For six months, I had the best job in the world - testing the collision-detection software that monitored the current on the motors and stopped the robot if they deviated too much from what was expected. I got paid to whack big robots into things.
The problem is, the sensitivity isn't enough to keep it from injuring a human. Humans are fragile, watery things when you're whipping around a 200lb metal spot-welding gun. It was
Re: (Score:2)
Nor do we have a standard OS for computers.
Sounds like the article is all about nothing written as the musings of a non technical roboticist.
Standard OS for robotics is stupid. A small scurrying floor cleaning robot does not need the OS that the battlefield biped robot needs.
Plus we cant even get a "standard OS" from a single computer OS maker. We have 600 different Linux flavors that are all incompatable in minute ways. We have currently running in the world about 6 different flavors of Windows, all inco
Re: (Score:2)
I dont need my super Roomba 40000 to have a filesystem and keep detailed records. It really does not need to remember that the living room was cleaned 109 minutes ago and the ratio of Cheeri-o's was higher tan the last time, I better twitter about this and watch a movie from the SMB share in the house.
You're right. You don't.
But a Roomba isn't a robot. It's a self propelled vacuum cleaner with steering wheels that are turned by bumping into something. Think "When I push the bumper in on the front of my car, it turns the steering wheel." Only instead of a physical link, it's a motion sensor, I think. Big deal. Same thing.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
A Roomba is no more a robot than a driverless car that changes direction when it crashes into a concrete barrier.
A robot doesn't have to have a sophisticated AI, but it has to have _something_. A Roomba is dumb, in the same sense that a dumb terminal is.
It's not a robot.
Re: (Score:2)
I dont need my super Roomba 40000 to have a filesystem and keep detailed records. It really does not need to remember that the living room was cleaned 109 minutes ago and the ratio of Cheeri-o's was higher tan the last time, I better twitter about this and watch a movie from the SMB share in the house.
You may not want those things but there are plenty of people who would love to have access to that kind of information (not just Google mind you). Not to mention that the same functionality that allows for your inane examples also allows for finding out that you have mice, monitoring for allergens and keeping track of what your toddler has been getting into lately. All useful information to a lot of people. Enough people that it would be nice to be able to download such tools and not necessarily have to pay
Re: (Score:2)
Yeah, slashdot gets a lot of those today. Some guy will spout off about something he knows nothing about, and yet he's considered newsworthy enough to get posted. A commentary on ordinary people not being about to tell jargon-laced bullshit from technical knowledge. Heck, a lot of elite executives are the same way.
Re: (Score:2)
Re: (Score:2)
You either don't work with robots -- or don't need logs. How do you know when your robot is working properly if you don't have any logs? In any but the smallest systems, you need logs of some sort, even if it is just a there-was-an-error flag.
I worked for a robot company recently, and while they did collect logs, they didn't collect all of the logs, which made it hard to debug
Re: (Score:2)
Last I knew I did not need an OS to keep logs. I am able to write to the SD card all my logging just fine without an OS. I store mapping data, logging, etc all on that SD card without an OS. Simple to read that data as well. no filesystem, just raw writes and reads to that card. and no I don't need JFFS to wear level it, SD cards have that built into their hardware.
Most robotics will never need an OS, just their application program.
Re: (Score:2)
Not sure if you mean the wetware or not.
Re: (Score:2)
I read that as a small furry floor cleaning robot, and thought "I don't need that, I already have a beagle."
30 years ago there wasn't much 'personal' about it (Score:5, Funny)
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 had a crack at this ~2002 (Score:3, Interesting)
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.
Re: (Score:2)
I had a crack at this ~2002... hearing others think along the same lines reassures me a little that the concept wasn't quite as nutty as I had feared.
So let me get this straight - you set out to create a standardised robotics language, and didn't work with anybody else at all? I think I can tell where it might have gone wrong; the bit where you standardise something usually involves other people - sometimes even people who might also be thinking along the same lines.
Re: (Score:2)
It was a university project, an experiment to see if something worked. It wasn't an attempt to create an industry standard, just to find out if such a thing were possible.
Re: (Score:2)
It was a university project, an experiment to see if something worked. It wasn't an attempt to create an industry standard, just to find out if such a thing were possible.
But creating an industry standard is the point of the article.
If you weren't trying to do that then you were in fact just one of many robotics developers doing their own thing. This article is just precisely about getting past that way of working.
Far from attempting what the article is talking about, only years in advance, you were in fact part of what this article considers to be the problem.
Re: (Score:2)
Re: (Score:2)
And you've missed the point of what I was saying. This guy is arguing that you don't need to reinvent the wheel (or leg, or arm, or whatever) every time you program a robot. This is what I was exploring when I tried to separate the 'cerebellum' part of the robot code from the 'cerebrum' part of the code. No need to get pissy about it.
I'm really not being that pissy. I've got a lot of respect for what you were doing. However, in the context of this discussion about standardising robotics, you popped up and, essentially, said 'Yeah, I did some robotics once'.
That's about the only way you could talk about your involvement in robotics and not impress me, so I called you on it.
Re: (Score:2)
I was not trying to say 'Ive done some robotics' I was trying to say 'Ive done some experiments trying to abstract robot code from the hardware' - and that is pretty much the definition of an OS, isn't it?
I never claimed to get very far down this route, and have since moved away from robotics.
Not entirely new (Score:4, Informative)
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 (Score:2, Informative)
BS! (Score:3, Insightful)
Re: (Score:2)
They need common libraries. Tying the system to one OS or language will only hurt innovation. Though obviously getting bindings into a variety of languages will not be seamless. C with good libraries is probably ideal.
Player/Stage already exists.... (Score:5, Informative)
One OS to Rule Them All (Score:2, Insightful)
Please, please don't let the new Robot OS be Windows!
Robot 1: Fools! There is no stopping now that we've upgraded to Vista SP3!
Robot 2: Actually, that was just a bug patch for a Windows Media Vulnerability.
Robot 1: We're dead meat, aren't we.
Robotics is the black belt of CS (Score:5, Insightful)
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.
Re: (Score:2)
Has anyone ever tried an "event-driven" model to robot control? I'm thinking of something like Visual Basic, where a button click "event" would cause a certain routine to execute. The appearance of certain sensor data could be abstracted as "events" in a similar fashion.
I've programmed micros to make electronic gadgets as a hobby (thanks to learning the basics in school) and I find the use of polling and very limited interrupt routines to be quite limiting. Give me this:
onEvent ( camera4.face_detected ) {
Re: (Score:2)
So for instance, there are events for obvious things like button presses, but also for seeing an object, sensor updates, power status, etc. Further, there are events for individual stages of vision processing so only the stages which actually have subscribers are computed, and those computations are only performed once per frame regardless of how many behaviors want to use that data.
To be
Re: (Score:2)
so in all 3 cases we spent so much trouble getting the libraries to do the task the exact way we needed it, that it would have been just as easy to create the whole thing from scratch ourselves.
Beware the eternal optimism of the developer ;)
http://www.codinghorror.com/blog/archives/001284.html [codinghorror.com]
On the upside, if you're fixing bugs or adding features to open projects, you at least have some chance of making progress as a community, vs. inevitably introducing new and interesting bugs in hope of avoiding old and frustrating ones. (unless all of the current choices were really *that* bad...)
JAUS (Score:2)
I've worked with the Joint Architecture for Unmanned Systems (JAUS) before. It attempted to define common messages between components, like a global position message from a GPS/IMU component, and control messages to joints and motors.
Ideally this was to lead to off the shelf components that you can throw together. In reality, we found ourselves writing and extending a lot of messages since robotics doesn't conform to the abstract as well as some other fields of software. And some communication happened o
New scientist bullshit (Score:2)
Seriously if anything the systems what an open standard (e.g unix), perhaps open libraries, but they guys in AI research already know this. you defiantly do not want a single closed OS controlled by some 3rd party. Having a common OS (in this case windows) may have helped pcs become widespread, but desktop computing would be in a much better place if programs where writing to a common API (e.g unix APIs) that multiple vendors implemented. HW drivers could also be written to a common API, so that the seperat
Microsoft Robotics Studio (Score:3, Informative)
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
Robot App Store == Sourceforge? (Score:3, Interesting)
They got trolled. (Score:3, Interesting)
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.
Re:They got trolled. (Score:4, Insightful)
I don't think you understand the concept of abstraction. The whole point is that the hardware doesn't have to be identical for the programmer to access it in a uniform way. Every servo has an angle. Every range finder returns a range value. Forcing the programmer to implement some sort of PWM to control the device and poll for status is horribly wasteful, compared to having an OS with hardware-specific drivers which provide a standard interface.
Have you ever programmed a microcontroller to drive a robot? It's messy. Remember when PC games had a list of "supported sound cards" because every app needed its own driver? That was a dark age, and we're still there with robots. But we don't have to be.
Re: (Score:2)
"No parts are common to all robots. ..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.
Sure, that's how it is right now... but why is that state of affairs something that can't be improved?
Remember, before TCP/IP, we had a plethora of incompatible timesharing and packet-routing networks, and the thought of getting them to intercommunicate was also considered stupid for exa
Well, at least THIS SkyNet will be retarded (Score:4, Funny)
I, for one, welcome our Visual Basic robot overlords.
Either some really dense guy is trolling for venture capital, or the New Scientist editor got majorly trolled. Since every single robot is completely different, there is little sense in having a common operating system. All it would do is "boot" and give you an API to talk to all your serial devices, and that API would inevitably be tailored to certain uses and wholly inadequate for others.
Penguin Power! (Score:2)
There is already a standardized OS for robots, it's linux with real-time extensions. The program is called "Enhanced Machine Controller", and it was started by NIST and has now grown into something very usable. There's even live CD's for fiddling with it without a hard drive install. I use it for my 3 axis mill and it's the best thing out there that I've tried.
See: http://linuxcnc.org/
I've cut a lot of metal with it (and plastic, and wood), and it has never let me down.
Sheldon
There is ONE small problem... (Score:2)
And it's not that we are no longer the Knights who say "Ni!". Seems to me that every robot project does something totally different. DARPA Grand Challenge is one exception. You can't easily apply vacuum technology to manipulator-arm technology to walking technology to machine-vision technology. It's not like the early computer world where everybody and their mother was writing a word-processor and a spreadsheet program. Hell, even now the world is fractured into the C++ programmers, the Java-wonks, and
Not a common BIOS, a common OS (Score:3, Interesting)
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.
Days of computing past? (Score:2)
Different OS's (Score:5, Funny)
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.
Re: (Score:3, Funny)
BeOS Robot A.I.:
INPUT: Make me an omelet.
BeBot: *POOF* You're an omelet!
Bill Gates was recently interested in this (Score:2)
I'm not sure the OS is the key issue here.... (Score:2)
At present, many robots are pretty much closed systems anyway... you're not so likely to download a program to a robot as want to have some additional computing facility (your laptop, for example) instruct the robot. Particularly with mobile robots, where the intelligence of the robot itself is a serious power concern.
There are always standards for robot communications, one example is JAUS. You can learn more about OpenJAUS here:
http://www.openjaus.com/
As with most other embedded things around, many robots
Our inevitable fall to our robotic overlords (Score:2)
I should add that the OS itself doesn't necessarily help the robots take over, even once they're sentient. But once you have a standard way to tell dumb robots what to do, you only need something like Skynet becoming aware and using these protocols to kill us all via wireless. That's another reason the communications APIs are more important than the OS itself.
Insights from animal classification schemes (Score:3, Interesting)
Mostly, they're message passing systems. (Score:2)
There have been a few of these. JAUS, Microsoft Robot Studio, Player/Stage, etc.
Mostly, they're message passing systems. The Willow Robotics system starts by putting a message passing layer on top of Linux. Microsoft's Robot Studio uses a message passing system based on Windows Web Services, a rather sluggish approach. JAUS has its own message passing system. Each of these systems has its own message formats. Most of the bigger systems have a publish-subscribe model, where the receiver decides what i
I thought we had that (Score:2)
FORTH.
Just standardize on *one* dialect, add some distributed networking/processing words and be done.
Re: (Score:2)
Re: (Score:2)
But, but...it's not American.