Alt-BEAM Archive
Message #10944
To: beam@sgiblab.sgi.com
From: StickG@aol.com
Date: Sun, 27 Feb 2000 07:53:21 EST
Subject: [alt-beam] Sensor Suggestions
Hi folks,
I'm making a two motor phototropic bicore walker, and I'm looking for
some great suggestions for other sensors I can attach to this baby to give
some really impressive behaviors, the simpler the better. Please e-mail with
ideas and descripitions ("see- spot run" language please), I'm itching to try
them out ASAP. By the way, if you can tell me how to attach Ian's reverser or
the essential info on it so I can incorporate it into my walker without using
his "almost complete walker circuit" that would be great.
thanks very much
stick
10945 Sun, 27 Feb 2000 10:18:44 -0500 [alt-beam] Re: BEAM: Tendency toward miniaturization beam@sgiblab.sgi.com Bob Shannon Dennison Bertram wrote:
> >
> > This is not true.
> >
> > CPU based robots are often programmed to gain experiance and have their
> > behaviors altered by their environment.
> >
> > There is no advantage to analog robot controllers at all.
> >
> > People seem to be forgetting that Nv circuits simply do not scale like
> digital
> > logic does.
> >
>
> Ok, this is not true. Analog robot controllers do have advantages over
> digital controllers. It's not hard to define what is an advantage either.
> Almost anything can be, from the fact that 14 yearold can build a walker to
> their pure analog nature. Look at the satallite that was put up while ago,
> it used satbot techonolgy as it's backup controll system. One of the reasons
> is because that sort of contorll system was just cheaper to build analog,
> why? because analog systems are hardier in terms to the effect of radiation
> on them.
But 14 year olds also build CPU based robots. As an engineer I can assure
you that to get a specific behavior from a CPU is much easier than it is to
tune and tweek a Nv based device.
More importantly its much much easier to modify what the robot does when
it uses a CPU than if it uses BEAM tech.
And BEAM is NOT cheaper to build with!
The design time to get the behavior you seek is a far larger expense than the
components.
> > > This is why I have been interested in BEAM, while not perfect, Nv/Nu
> > > circuits can be affected
> > > by the outside environment to a certain extent. What is needed is for
> > > someone to develop
> > > a VLSI chip containing large quantities of Nv/Nu circuits in which the
> RC
> > > time constants
> > > can be electronically adjusted and the interconnection between them can
> be
> > > changed and
> > > re changed to any configuration desired. Then I believe using a number
> of
> > > these chips, it
> > > may be possible to see some very lifelike qualities emerging.
> >
> > Uhh, why not do this with a processor?
> >
> Because if everyone did everything with a processor then there wouldn't be
> any innovation.
I disagree, there is a huge ammount of variation in processor based bots, and
the behaviors of even the most simple CPU bots are totally beyond the current
state of BEAM art.
I should also point out that BEAM diversity is not very high currently. Most
BEAM
devices are copies of tutorials rather than groundbreaking new designs.
> > >
> > > To understand a little why I believe a-life is possible, here is a
> thought
> > > experiment:
> > > If we were to take an electronic circuit that acted exactly like a
> > > biological neuron
> > > (scientists have done this), scale this down to the size and power
> > > requirements of
> > > the real thing and begin to replace the neurons in the human brain with
> them,
> > > when would we cease to become a living conscious entity?
> > > Would it be after the first one, 50%, 99%,!00% ?
> > > And I guess here is my main point, how would we be able to tell the
> difference?
> >
> > Science has never made a reasonably close model of a neuron. In fact,
> they have
> > no idea how neurons form useful interconnections to other neurons.
> >
>
> A key word should be added into that scentence, "Science has never made a
> reasonably close model of a neuron *yet*" The future is wide open as I'm
> sure you know. I doubt it will be that much longer considering the
> astonishing advances made by science every day.
Perhaps so. Given the large effort going into this sort of research I'm sure
that
in time such a model will be developed in time.
But its not even close today.
> One of the things I think your looking over is the time disparity between
> the research periods for each technology. Neuron type work was cut short in
> the 50's with the advent of the processor. So big deal. We've been useing
> processsors for the last fifty years. Only recently have we started to use
> neuron based analog systems again.
I disagree. Having worked at the AI lab at MIT, I'm aware of a long history of
research into stimulus-response and neuron-like controllers.
The advent of the CPU accelerated this research, it did not stifle it in any
way.
> What does it hurt to try to do it a
> different way? innovation is always a good thing. Besides who is to say that
> computer based control systems won't eventually benifit from this work. I
> recently made some acquaintances up in the Parralel and distributed
> intelegence center where I may work for the summer, and my advisor liked the
> beam stuff, but kept asking, "why not do it all in simulation on a
> computer?" And I'm like, "sure you can. But right now, I'm not." That's part
> of the point, computers have their place, but they shouldn't just be assumed
> to be 'the way'.
>
> anyway
> dennison
I never claimed it hurt anything to try new methods.
I totally agree that CPU based robots can benifit from the concepts and ideas
developed and tested with BEAM technology.
In fact, thats the only reason I build BEAM devices.
But to address the question of simulating BEAM on a computer, it really will not
work very well. Well designed BEAM devices are fractally imbedded in their
environment and no simulation will ever capture the subtle interactions between
body and environment. Also its practically impossible for computers to simulate
chaotically coupled oscillators (like master-slave systems).
You can develop programs with the same fractal behaviors in general, but this is
not the same thing as simulating the actual performance of a real-world BEAM
design.
Lastly, I dont assume CPU's are the way to go. I base my opinion on direct
experiance
and by keeping an eye on the development time and cost. I can do far far more
with a PIC than with Nv's, and there is nothing I can do with Nv's I cannot do
with a PIC.
But please dont assume I'm knocking BEAM, I'm just trying to be a little bit
objective about how BEAM compares with other approaches.
Home