Immobile Robots

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.

Comments

Hah!

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

[mestoph]

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 :)

Re:Other new names...

[creative_name]

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.

Re:Doesn't it seem....

[yy1]

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

Model-based control

[Animats]

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