Newsgroups: comp.robotics.misc,sci.space.policy
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!eecs-usenet-02.mit.edu!nntprelay.mathworks.com!howland.erols.net!ix.netcom.com!erkyrath
From: erkyrath@netcom.com (Andrew Plotkin)
Subject: Re: Nonsense from JPL
Message-ID: <erkyrathEEu1n4.5FM@netcom.com>
Followup-To: comp.robotics.misc,sci.space.policy
Organization: Netcom On-Line Services
X-Newsreader: TIN [version 1.2 PL2]
References: <871264321snz@stellar.demon.co.uk> <33EF5A14.74A3@schools.tec.mn.us> <871416808snz@stellar.demon.co.uk>
Date: Wed, 13 Aug 1997 03:28:15 GMT
Lines: 116
Sender: erkyrath@netcom13.netcom.com
Xref: glinda.oz.cs.cmu.edu comp.robotics.misc:16469 sci.space.policy:76941

Joseph Michael (Joe@stellar.demon.co.uk) wrote:
> Pathfinder and Sojurner are full
> of redundant systems - there are no redundant systems in a fractal
> machine... its kind of difficult to explain - but the entire system
> can reshape into other systems without having redundancy for each
> system. Fatal arithmetic if you just built Sojurner, because machines like
> that are infinitely more expensive when compared to a similarly
> functional fractal machine.

> Read up http://www.robodyne/mars2001

Well, I've read your pages, and this particular flame has been warming up
in me for a while; and since the subject line of this thread very
conveniently says "Nonsense" already (killfilers feel free!) I think I'll
throw in my two joules' worth. 

You do not seem to understand the programming involved. At all. I say this
because I haven't the foggiest idea how *I* would program a fractal robot,
even if someone handed me all the hardware already built. And I don't
particularly think you're a better software designer than I am. 

Your pages talk about "fractal programming" and "fractal operating 
system"; but there's barely any information on how this will *work*. 
Plenty on what it will be able to do if it does work, but that's not 
science, that's science fiction. (Science fiction is the art of glossing 
over the nonexistent details so that your reader can enjoy the 
story. You've got a good story, or rather a good idea for a story, or 
rather you would if Forward hadn't thought of it first. But you don't 
have engineering.) 

Organizing a large system made up of small independent parts, so that the 
overall thing acts intelligently, is a hard problem. I think it's *the* 
hard problem.

We could go back and forth about what existing systems are "like" the 
massively parallel behavior you want for your robots. (Neural nets are 
sort of. The Internet, or Usenet, are also sort of, although not very.) 
That argument would probably get dull.

Instead, why don't you start writing some code? This is one area of your
proposal that you can start working on *now*, no funding required, no cube
building. Write a sim of some shape-changing Mars rovers, and release the
source code so we can test it ourselves. 

Here's what I'd like to see: given a big terrain map (just a two-D array 
of altitudes), program a bunch of cubes that can walk around on it. 

- The user must be able to point at any spot on the map and say "walk 
here", and the rover will figure out how to get there and then do it.

- All the same size cubes, or a full fractal setup, whichever you like. 
Feel free to assume that joints are completely rigid, and, heck, the cube 
motors are arbitrarily strong. (Well, strong enough that one motor can 
lift the whole set of cubes by itself.)

- The model world will require some physics programming, but it shouldn't
be *too* hard. You don't have to demonstrate jumping or fast movement. The
rover can move slowly, so it's in a stable position at all times. The
physics only has to figure out how each cube motion affects the shape and
position of the rover; and then check friction and foot positioning, and
overall center of mass, to make sure that it *does* stay stable. (If it's
not, just abort and print "The rover fell down" -- you don't have to
simulate the falling object.)

- Don't worry about sensory input (if you don't want to.) The rover
program can have access to the terrain map. 

- The terrain is rigid, and the rover must not break it. That is, the 
rover must not try to push a cube forwards into a rock if it's wedged 
against a rock to the rear -- that would constitute burning out a motor. 
The physics should detect this (solid objects intersecting), abort, and 
throw a "motor failure" error. 

- Alternatively, if you're willing to handle more complex cube behavior, 
give each cube "motor failure" sensors, so that the robot can deal with 
this condition intelligently. You can also add contact sensors, if you 
want. (That would add some work to the physics, though.)

- The programming must be "fractal" -- a set of programs, one for each
cube, each of which can only affect that single cube's actions. (I guess
an "action" is either moving relative to an adjacent cube, or transmitting
information to an adjacent cube.) No fair having a single program
controlling all the cubes. You can have designate a "brain" cube running a
control program, but then you also have to write "nerve"  programs for the
other cubes to relay the brain's commands around. Similarly, if a cube
has any sensors on it, the sensor info only goes to that cube's program; 
the programs must handle their own data exchange, each cube to adjacent 
cubes.

- (Of course you'll probably be running the simulation on a single-CPU 
machine, and faking the parallelism of the cube programs by some 
scheduling system. That's ok. That's why we call it a simulation.)

- To be completely realistic, and to emphasize the point :-), one cube 
should be designated the radio cube. This is the one which contains a 
receiver, which receives the user's "walk here" commands. Radio commands, 
like control commands and sensor info, must be communicated from cube to 
adjacent cube via the protocols you will be designing.

- The second phase, which I will also require in order to be really
impressed with your stuff, is to make the cubes able to split into two
rovers, journey to different destinations, come back, and join together
again. (When so commanded by the user, via the radio.)

This is a large project. People write degree theses about this sort of
project. (The physics alone is kind of a pain in the ass -- sorry about
that, but you see why it's necessary.) If you manage it, you will have
created something of real value, and you'll get a lot less razzing on
these newsgroups. 

--Z

-- 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
