Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Technology

Immobile Robots 92

Posted by michael from the what-you-get-when-the-servos-break-down dept.
Roland Piquepaille writes "Wade Roush wrote a long and well-documented article for the Technology Review about this new concept, the immobot, short for "immobile robot." He gives different industrial examples, from NASA to the water utility in Porto Alegre, and from Toyota cars to some new Xerox photocopiers. And he looks at the programming model behind the immobots. No "heuristic" programs here, but model-based programs instead. Check this column for details." The original article has more information.
This discussion has been archived. No new comments can be posted.

Immobile Robots More

Immobile Robots

Comments Filter:

  • Warping the definition of robot (Score:3, Insightful)

    by altaic ( 559466 ) on Saturday November 30, 2002 @02:03PM (#4784510)
    Wouldn't an immobile robot just be a computer, then? It seems as though they are just discussing AI, eh.
    • It is a robot in the sense that it recieves data through its sensors and then interacts with the world via effectors. It just happens that for an immobile robot, none of the effectors are wheels or other locomotion devices.
      • Well in that case "agent" would be a much better word. An agent is a situated entity that observes an environment, makes decisions, and takes actions in that environment. Note that this nicely includes active software systems, "immobots", and mobile robots, while ruling out things that just observe and require a human to take action, like a fault detector. Unfortunately the meaning of agent has been so dilluted by now that they decided to come up with something new. Immobot sounds pretty strange to me though...

        Okay so I'm not completely unbiased, being a mobile robot researcher and all, but hey...
    • You're missing the concept here: model-based programming is an entierly different paradigm. You don't tell the program what to do when something happens; you just tell it how it interacts with it's environment and it figures out what to do to accomplish a certain task.

  • I have an immobile robot (Score:2, Funny)

    by Anonymous Coward
    It's called my computer. While it isn't very useful for getting me things, I'm not afraid I'll wake up one night to find it holding a knife at my throat.
  • But Deep Space One had something Mars Polar Lander lacked: an onboard robot ... [which] devised a successful plan

    Nonsense, of course, it was just programmed better.

    Immobile robot == computer. Whoopdedoo.

  • A machine? (Score:5, Insightful)

    by gelfling ( 6534 ) on Saturday November 30, 2002 @02:07PM (#4784525) Homepage Journal
    What was Gutenberg's press? A presentient nonmobile robot?

    C'mon people...

  • huh (Score:4, Funny)

    by Anonymous Coward on Saturday November 30, 2002 @02:07PM (#4784526)
    about 8 or so years ago i had a photocopier which was able to diagnose its own problems.

    isn't this the same thing?

  • Slasdhotters are immobots? (Score:4, Funny)

    by YahoKa ( 577942 ) on Saturday November 30, 2002 @02:09PM (#4784534)
    Imobile robots ... sounds alot like some of the computer obsessed people i know. Doesn't thinkgeek have a fridge for your desk now? I mean, we don't even have to get up to get beer anymore...

  • Doesn't it seem.... (Score:3, Insightful)

    by Cali Thalen ( 627449 ) on Saturday November 30, 2002 @02:15PM (#4784550) Homepage
    ...like this is just another stab at A.I.? It's hardly a robot of any type according to most standards, but rather a program that has some limited self-awareness?

    Even so, the examples don't really seem to indicate self-awareness, as much as a somewhat more robust error diagnosis. BFD. Nice if you can get it, but it's nothing new.

    Personally, when I read the headline, I thought of 'robots that don't walk around', which to me describes most real robotics systems...so maybe I was jaded before I read the article.

    • Re:Doesn't it seem.... (Score:3, Informative)

      by yy1 ( 238590 )
      I don't think the guy who wrote this article really understood exactly what they are talking about. I'd like to preface by saying this is a fantastic concept that could revolutionize the way we think about troubleshooting and diagnostics of hardware.

      from the original article:
      Say you're making 70 copies of a booklet. Even before you press the Start button, a machine running PARC's model can predict that stapling will be the slowest part of the job and communicate this fact to other components of the machine, allowing them to run concurrently and without creating a big backup. Another advantage, Bobrow says, is that the DocuColor controller models are built from smaller models hard-wired into each component. When a new station such as a scanner or sorter is added, it transmits its internal model to the central controller, providing a painless software upgrade.
      From what I understood, this thing is able to emulate/simulate itself in software (this is the jargon'ed up "models") the fact that they build each "addon" with its own simulation in rom or such is such a great idea, so the copier itself is able to add that into its interal simulation, this is a pretty impressive feat, (think about MAME).

      THEN they build in some sort of diagnostic software that is able to use that internal simulation + sensors (the weak link in all this) to determine problems and come up with alternative ways of accomplishing a given task.

      This is where things delve into the AI aspects, thats pretty high-level. I think an analogy would be instead of having a health manual for people in the 15th century. that lists stuff like "cut finger, clean and keep covered", you teach them about bacteria and why things get infected. Maybe the give a man a fish he eats for a day, teach a man to fish he eats for a lifetime (and can teach others.. etc) analogy applies here as well.

      It does seem more productive to write software that is better able to use a simulation to solve problems than to have solutions each and every individual problem a device might ever encounter.

      I think the main application for this kind of software is in really expensive stuff people expect to (hope)work forever. (space probes, copiers, cars) so that's why all this bs about immobot, blah blah, probably some fancy name they had to give the research when it was time to shop for funding and the commercial applications had to be extremly obvious.

      I wonder if they are using neural net type stuff, genetic algorithms to help with the diagnostics, that would seem the most obvious choice. Wonder if they paired this up with the FPGA stuff (there was a slashdot post about it but i can't find the link now) that can program its own hardware....

    • ...like this is just another stab at A.I.? It's hardly a robot of any type according to most standards, but rather a program that has some limited self-awareness?

      Well, let's not use the term AI -- it has too much baggage and nobody knows what it means anyway.

      There are three aspects to making workable self-fixable photocopiers and water plants: (1) figure out how such a system should figure out what's happening and how it should figure out what to do about it, (2) implement a system that carries out such figuring, and (3) encode knowledge about a specific domain so that the system can crunch on it.

      Problem (1) is solved, AFAICT. The right thing to do is to use probability to represent beliefs about the world, and to use utility theory to express how happy you are with the state of the world. The combination of those two concepts is conventionally called decision theory.

      Problem (2) is very difficult. Having decided you want to build a general decision theoretic system, you immediately get into serious computational difficulties. Here's the tip of the iceberg: if there is more than one chain of events that lead from causes to effects, it's a hard problem. Time-dependent problems (i.e., most real problems) have this characteristic left and right.

      Problem (3) is difficult in a practical sense as opposed to a theoretical sense. This is basic engineering -- translating a real problem into a mathematical representation suitable for solution.

      The payoff of this approach is that you can put together the model of the system from the bottom up -- each little component can be modeled separately, and then the rules of decision theory tell you how to combine all the pieces. Essentially, you construct a system that is an "automatic heuristic generator". Lights out? Check the battery? Battery is good? Check the wires... etc. Such a system can generate an appropriate response in many more scenarios than human heuristic-generators.

      auai.org [auai.org] is a great resource for information on automated reasoning systems. I attempted some research in this direction -- see riso.sourceforge.net [sourceforge.net]; all the results are in my dissertation.

  • Immobots vs. Computers (Score:5, Insightful)

    by creative_name ( 459764 ) <paulsNO@SPAMou.edu> on Saturday November 30, 2002 @02:17PM (#4784557)
    I think most of the posters so far are missing the big point. Even having a computer control a function at a water plant still requires a fairly large degree of human supervision. Someone has to make sure the computer is working properly, make sure the control programs don't screw up, and if the programs do screw up, they must fix them. The idea behind immobots seems to take it a bit further than that by actually reducing the amount of control neccessary. I suppose you could say it's just a computer, but then couldn't all things effectivly be reduced to computers (our brains, for exmaple) which certain things in common and certain things different.

    The point of this article was that the immobots require almost no human control, whereas a computer still requires a human. Or something like that. Just my 1/2000000000000th of Bill's (estimated) fortune worth.

    • The idea behind immobots seems to take it a bit further than that by actually reducing the amount of control neccessary.

      Whereas mobile robots (Mobots [cmu.edu]) require more human interaction. Exactly how does a computer not provide a service which any businessman with half a brain or more wouldn't have an administrator/engineer oversee?
    • Tossing the probe in with the rest of these "immobots" is a bad example, since it is mobile after all. The control system turned the robot, or in this case, the probe.

      The problem is that the word "robot" is being misused (well, redefined perhaps) here. Ever since it was first applied in the play R.U.R., "robot" has always indicated a mobile machine, usually with some fashion of humanoid appendages (arms, head, sometimes legs). Primary parts of the goal of robotics are path planning (how to move an arm to pick up an object, or how to mow the lawn without hitting the puppy running back and forth), and environmental awareness (being aware that the puppy or the object is there to be avoided or picked up in the first place.)

      However, the examples in the articles don't have direct contact to physical appendages, rather, they have a model of the appendages internally to work on. While not making for an impressive sight, these have the advantage of allowing the designer to break free of the anthropomorphism all too common in robotics. Why does a robot need arms and a head? The original article talks about controlling a water treatment system where these appendages are rivers and treatment tanks. Unlike traditional robotics, the goal isn't physical path planning, rather, its planning a course of action that solves a problem. The larger such systems become, the more complex their model will become, which will require greater environmental awareness than visual object identification.

      The development in this field will surely help the "real" robots, as advancements in developing these models will continue until the robot is capable of extending these models itself, which will allow your lawnmower to decide that its also important to avoid hitting the neighbor's cat that your puppy has been chasing around your lawn, even though you forgot to tell it about the cat.
      • I agree with you regarding the term robot, but it really boils down to most people's lack of knowledge about the real definition of a robot.

        This Post [slashdot.org] has a literal definition of the word.

        Glad we're on, generally, the same page.

      • but that doesn't make it robotics.

        if someone comes along and says: i want to build a sewage treatment plant where A, B and C are self-regulating and the entire system requires a minimum of human supervision, then that's an engineering problem. there are people you'd probably hire to stake out the requirements, to engineer and then to implement the system. maybe even a fair bit of research to push the envelop.

        but d00d, its very unlikely you'd hire a robotocist to do that. not even one who watched an episode of "spock's brain" and got the idea that ideas from robotics research could maybe be redeployed almost anywhere else ...

        anyone but the most self deluded - or maybe one pushing really hard for some grant money - would have at least paused to ask himself: "hey, maybe the fact that i'm claiming that all of this stuff we use in robotics isn't actually 'just robotics' means that its stuff that folks in those other areas actually know and use already (without the hype of course), rather than assuming that robotics has somehow solved all the problems of embedded systems that nobody else had ever thought of before ..."

        arrogant academic, i'd say. "immobot". i like the name "smart pickle" better.
    • Ok, it seems they have a new idea that allows to design systems that react better in unexpected situations.

      By the way, this would be great for PCs, at BIOS and OS levels...

      But, is there any public information about how these so-called "immobots" are actually programmed ?

  • Other new names... (Score:1, Flamebait)

    by dagg ( 153577 )
    Immobot? Here are some other new names:
    • Silradio - A radio with no sound.
    • Cleartv - A TV with no picture.
    • CPUlessPC - A computer without a CPU.
    • Darklight - duh.
    Since this article is pointless... here's something else to do:
    Get your sex here [tilegarden.com]

    • I see the obvious joke you are trying to make, but unfortunately you are incorrect. The word robot, as defined by the American Heritage Dictionary of the English Language, Fourth Edition, is defined as:

      1) A mechanical device that sometimes resembles a human and is capable of performing a variety of often complex human tasks on command or by being programmed in advance.
      2)A machine or device that operates automatically or by remote control.
      3)A person who works mechanically without original thought, especially one who responds automatically to the commands of others.

      Now, none of these three definitions imply a universal ability to move, and as such, the term Immobot does not really fit in with the rest of your "inventions" (by the way, you should try and get some VC for those!)

      Sorry for being overly-literal. It's a curse.

  • Wait a second... (Score:5, Funny)

    by ActiveSX ( 301342 ) on Saturday November 30, 2002 @02:19PM (#4784567) Homepage
    Using its engineering knowledge, the robot tried to repair the switch by toggling it on and off.

    Isn't this like saying "Using my engineering knowledge, I tried to repair the toilet by jiggling the handle." I'd hardly call brute-force "engineering knowledge."

  • A little outdated? (Score:4, Insightful)

    by Devil's BSD ( 562630 ) on Saturday November 30, 2002 @02:22PM (#4784575) Homepage
    Well, I think ever since the integration of microchips into home appliances, they have become 'immobots'. Take for example:
    • Your coffee pot brewing some hot stuff every morning at 6 AM
    • The dishwasher going through its cycles automatically
    • The office copier making 300 copies without you having to push copy 300 times
    • The thermostat regulating the temperature of your house, and supposedly regulating it at your workplace
    • The robotic arms on an automobile assembly line (well, that might be streching it)

    As you can probably see, a lot of these things don't even need IC's to do their job. This article, IMHO, is like saying the wheel was a great invention.

  • Or any cybernetic geek exercising for that matter.

    IMMOBILE.

  • Hah! (Score:2, Informative)

    by Anonymous Coward
    "water utility in Porto Alegre"

    When I visited Porto Alegre (in southernmost Brasil, near Uruguay) eleven years ago, they were already then monitoring deformities in various fish species as to detect any increase/decrease. The prejudiced me didn't expect that then.

  • immobile robots = computers = not. (Score:4, Informative)

    by mestoph ( 620399 ) on Saturday November 30, 2002 @02:29PM (#4784588)
    Definition of Robot: noun: 1. A mechanical device that sometimes resembles a human being and is capable of performing a variety of often complex human tasks on command or by being programmed in advance. 2. A machine or device that operates automatically or by remote control. 3. A person who works mechanically without original thought, especially one who responds automatically to the commands of others. ETYMOLOGY: Czech., from robota, drudgery. Compulsory labors. * The foundation of the term robot as it is used today can be found in a science fiction book and a play written by Karel Capek. The book is titled Valka s Mloky (War with the Newts) and the play is titled R.U.R (Rozuma Univerzalni Roboti) [rozum means wisdom] (Rozum's Universal Robots).

    Technically anything that is compulsory labour is a robot, as long as it is artifical. So is a clone a robot? Anyhow, photocopies come under definition 2. Just though i'd drop the definition in :)
    • Technically anything that is compulsory labour is a robot, as long as it is artifical

      Actually a definition from the dictionary is anything but technical. A dictionary describes day-to-day English usage, not technical usage.

      For example, according to the dictionary Venus is a star, more specifically, the morning star, which in day-to-day English usage is correct, but technically is wrong. Technically, Venus is a planet.

  • ( or fridge heat or car engine heat)is nothing more than an immobile robot. Some of them even have electrical logic circuits these days, but even the "old fashioned" kind were a simple analog robot with its "logic" built into the properties of the materials.

    Pretty much nothing to see here I'm afraid. Your house has been full of variants of the simple "immobile robot" for several decades.

    KFG
    • Yeah, but what if your thermostat knew that the reason the temperature was a tad low was because your front door was open while you were lugging in a case or two of beer, and that the temperature would equalize soon enough after you closed it, and no need to waste fuel firing up the furnace just now. Another oversimplification, sure, but the real thrust behind the article is that most of the functionality we're familiar with is based on a simple "if a then do b" logic, but hasn't involved more complicated heuristics to take into account more complicated, situational issues that fall outside of the initial assumptions on how the system should react to input.
      • It doesn't know that. In fact it can't know that. It can only *assume* that. That's the failure of all mechanical heuristic approaches. The human mind is more complex and dasterdly than that.

        In fact Brasil deals directly with this very example.

        The smartest robot is stupider than my cat, and I wouldn't trust heuristic decisions to my cat, at least with regards to my own safety and comfort.

        Clippy was a bad idea. Putting clippy in control of my house when I'm perfectly capable of spending the 2 seconds to make a decision and actually *do* something myself is a revolting concept.

        Maybe I've left the door open because the damned thermostat is acting funny and I need to the cool the house down through alternate means.

        In the real world as it is right now this problem is dealt with by the age old method simpler, and more effectively, by the proper placement of the thermostat in the most temperature stable portion of the house *away* from the front door. Never use a computer to do what ordinary common sense arangement of physical parameters renders unecessary.

        Nor can any artificial hueristic sense what *I want* at any given time. Like leaving the door open for the breeze. Humans are wonderfully changable in mood and 50 degrees may be comfortable for me one minute and intollerable the next, completely unpredictably. So even a "perfect" robot is only going to be able to operate effectively a certain small percentage of the time.

        More often than not the most effective way to deal with an issue is to get off your ass for 10 whole seconds and deal directly with the issue, personally.

        "Immobile robots" deal with certain things very effectively, like timing the spark to your car's engine, but very poorly when trying to figure out WHY the door is open and just what it should do about it.

        There isn't even savings in human time and aggravation if you simply replace having to do it yourself with having to hit the override button and do it yourself anyway half the time.

        Just like that damned paperclip.

        KFG
  • Unlock the pod bay doors, HAL. HAL? Unlock the pod bay doors.
  • If we lock a technician in a small box, we've created an immobot clone?

  • Politically Correct?? (Score:1, Flamebait)

    by Myriad ( 89793 )
    Hrmmm, I would have applied this definition:

    Immobile Robot: (politically correct term) used to describe a robot which has suffered a Blue Screen of Death [tuxedo.org].

    Similar, but more polite form of: "Who borked the bot?" [tuxedo.org], "The bot's FUBARed" [tuxedo.org], or This bot is hosed!" [tuxedo.org]

    One possible cause for an immobile robot is a users irresponsible experimentation with magic [tuxedo.org].



  • I'd imagine Al Gore has been around for at least 50 years now.

    Cheers,
  • I got acused a couple weeks ago of being an immoble robot....but i think thats just becuase I never leave my computer didn't read the article but I doubt they're talking about others like me
  • It's an interesting idea. Of course, I read the original article, not the redigested summary the poster referenced. Much better.

    Reasoning from an engineering model seems to have the potential to do lots of interesting stuff. The limit the article didn't mention is the reasoning power of the robot; it seems like it could easily get overwhelmed by models that are just too big.

    An interesting potential application: universal controls for complicated home entertainment systems built out of heterogenous parts.

    John Roth
  • I guess that it is very hard to think of all the errors and influences in a complex system.
    While heavily interdependent systems like desktop computers might have the processing power to monitor themselves, few programmers care to write decent error-reporting features. As for me, few of the error messages I've seen actually told me about the real problem.
    If it's programmed thoroughly, it's a very good idea for cars.

  • If it doesn't move... (Score:2, Insightful)

    by Alomex ( 148003 )
    If it doesn't move or cause movement it is not a robot. That is the technical definition of a robot.

    According to the International Federation of Robotics (IFR) a robot is a machine which can be programmed to perform tasks which involve manipulative and in some cases locomotive actions under automatic control.

    The Swedish Industrial Robotics Association defines a robot as an automatically controlled, reprogrammable, multi-purpose manipulative machine with or without locomotion for use in industrial automation applications.

    A robot has three essential characteristics according to the Australian Robotics and Automation Association :
    It possesses some form of mobility
    It can be programmed to accomplish a large variety of tasks
    After being programmed or commanded, it operates automatically

    Immobot seems to be a short hand for a control loop computer. It is a good one at least in the sense that it generated PR. After all, when was the last time you saw a slashdot article on control loop software systems?

  • Model-based control (Score:5, Informative)

    by Animats ( 122034 ) on Saturday November 30, 2002 @05:19PM (#4785158) Homepage
    OK, first we have a buzzword problem. Someone has taken a reasonable and known idea and called it something new for PR reasons. This stuff is called "model-based control", and there's a fair amount of theory about it. "Immobot" is PR, like "autonomic computing".

    Still, we're talking about a basically good idea that needs to be pried out of the hands of the control theorists and used more. As a discipline, control theory has a theorist problem - too many of the people in the field develop pretty theory unusable in the real world. (A friend of mine on the Harvard faculty says that control theorists are failed mathematicians.) As a rule of thumb, if you pick up a book on control theory and it starts out by proving theorems, it's useless. If it starts out with "and here's how we did it in the F-15", things are looking good. Linear control theory leads to beautiful mathematics in the frequency and phase domains, based on Laplace and Z-transforms. Unfortunately, that approach doesn't get you very far for nonlinear systems or systems with multiple states. It's useful mostly for systems that maintain some steady state, for which simple PID controllers tend to be good enough.

    Conceptually, model-based control is simple and elegant. You have some mathematical model of the system, which includes some number of inputs, some of which you can set (the control variables), and some of which you can only observe (the disturbance variables). You also have some number of outputs which you wish to control. The idea is to use the model in reverse to figure out useful values for the control variables, given the desired outputs and the disturbance inputs.

    For models made up of certain standard components (linear elements like integrators, summers, multipliers, and certain filters) there's an analytical method for solving the model for its inputs. All the heavy work is done offline; the control system itself only has the canned solution to the problem, and a small microcontroller can do the job.

    For more complex models, the analytical solution breaks down. Now, the entire solution has to be computed in real time, and the complexity of the controller software becomes much greater. It requires at least a nonlinear equation solver, and if the system has discrite states, some means of exploring the state space as well. These are non-trivial pieces of software.

    This isn't a happy thing if you're running something important. The stability behavior of controllers created by offline analysis is predictable. Getting well-behaved controllers for systems that can't be analyzed analytically is tougher.

    One thing you have going for you is that you can run the model whenever you want, and use it to check the proposed control solution. Model-based control lets you can ask "what if" of before you do it. You can have a dumb system that does sanity checks on the complex system. As long as you have an backup control strategy (often an emergency shutdown) for when the complex solver isn't generating good answers, there's hope of building safe systems this way.

    Model based control can be made "adaptive". You build a model with some tuning parameters, and let it watch the "plant" (the system being controlled) for a while, with some other (either simpler, manual, or an older model) controller running things. The tuner then tries to tweak the model to make it match the plant. Only when the model is tracking the plant reliably is it given control. AI people call this "training"; control engineers, less inclined towards anthromorphism, call it "self-tuning".

    Any time the model in control isn't tracking the plant's outputs, that's an indication that something has gone wrong. So you have a clear indication of when things are broken. Model based control is thus able to detect fairly early when it isn't working, unlike most simpler control systems.

    So that's model-based control. It works for some problems. Black boxes in avionics bays of high-performance aircraft use it in flight every day. It's about to filter down to the masses, probably accompanied by the sort of hype that came with "fuzzy logic control".

    • Thank you for writing your comment. If I had any moderator points left, I'd definitely mod you "+1 Informative". I see that between the time I downloaded the comments page and the time I downloaded the reply page, you've been modded up so now you're at four. Hopefully, you'll get to five soon. :-)

      I've never heard of "control theory" before but since I have a CS degree, I probably should have. It sounds very interesting. It's nice to know there are systematic methods for attempting to keep control of complex systems other than just periodically asking the question, "is it still on?". :-)

      Also, thanks for clearing up the "immobot" crude. I went to the "Check this column for details" link but it had been simplified to the point that there was no technical info in it. (Nothing left... Like if you take the derivative of a polynomial too many times: you always get f(x)=0.) So it was impossible to determine if they were actually telling me something or just saying, "Wow! Technology's cool, you bet!!" I hate when that happens.

      • Re:Please mod up parent comment (Score:4, Interesting)

        by Animats ( 122034 ) on Sunday December 01, 2002 @01:40PM (#4788343) Homepage
        Thank you.

        Control theory is more of a traditional engineering discipline, studied by electrical, mechanical, and industrial engineers. It takes a strong math background: calculus, linear and nonlinear equations, tensors, Laplace and Z transforms. There isn't yet "Control Systems for Dummies", although some friends of mine are trying to change that by writing a controls curriculum, accompanied by a parts kit, for bright high-school students.

        The path to low-level AI (moving around, not bumping into stuff, not falling down) may lie in the region between model-based control and machine learning. That region is now open for business, due to cheap compute power. Control systems used to be powered by computers with well under 1 MIPS; most of them still are. With cheap gigaflops available, approaches that were once far out of reach can be used. Real-time stereo vision finally works, and is about to get cheap. Stability enhancement systems for cars [gm.com] are quite impressive today. Self-balancing machines, from the Segway to the Asimo, are showing up as products.

        Mobile robots, which have been sluggish machines for decades, typically have rather low-performance control systems. The DARPA LA to Las Vegas robot race [darpa.mil] may change that.

  • Seems to me.. (Score:2, Insightful)

    by WillRobinson ( 159226 )
    I work with robotics everyday, and while its nice to see theories advancing, this method is still not there yet. I don't think that there is enough computing power to take on a very large model. Program complexity, or better object control complexity will grow with each object added, until the time to calculate the correct move in a critical situation would exceed the point of no return.
  • The huge number of posts that this is stupid proves that most Slashdoters are posers rather than real programmers! While the naming of immobots is rather silly, the concept is truly profoud and is another small step on the road to AI. Imagine if PC systems had the same abilities. They would be less buggy, more reliable. Programming would become training the AI rather than debugging pages of code. I like it when the moderators post stuff like this--otherwise I would never find it. Thanks!
    • > the concept is truly profoud and is another small
      > step on the road to AI. Imagine if PC systems had
      > the same abilities. They would be less buggy, more
      > reliable. Programming would become training the AI
      > rather than debugging pages of code.

      and indeed, that's why people tried to do it 20 years ago and still haven't succeeded. the complexity of the problem doesn't disappear by waving your magic buzzword at it. more likely, you've just exchanged the specific problem for a more general class of problems that's even harder to solve adequately.
  • Yeah...uh huh...right. Immobile Robots.

    Show me some code. Surely there's some sort of software model and code to illustrate this idea?

  • "Wade Roush wrote a long and well-documented article for the Technology Review about this new concept, the immobot, short for "immobile robot." He gives different industrial examples, from NASA to the water utility in Porto Alegre, and from Toyota cars to some new Xerox photocopiers."

    As an owner of Toyota car I find this remark highly offensive! Please forgive me that I don't have a Ferrari! Well, some people are rude, indeed.

  • "... being a Linux user is sort of like living in a house inhabited
    by a large family of carpenters and architects. Every morning when
    you wake up, the house is a little different. Maybe there is a new
    turret, or some walls have moved. Or perhaps someone has temporarily
    removed the floor under your bed." - Unix for Dummies, 2nd Edition
    -- found in the .sig of Rob Riggs, rriggs@tesser.com

    - this post brought to you by the Automated Last Post Generator...

Slashdot Top Deals

How many hardware guys does it take to change a light bulb? "Well the diagnostics say it's fine buddy, so it's a software problem."

Close