Alt-BEAM Archive
Message #02289
To: Terry Newton wtnewton@nc5.infi.net
From: Bob Shannon bshannon@tiac.net
Date: Tue, 13 Apr 1999 19:28:08 -0700
Subject: [alt-beam] Re: CPU again? (was Beam genome)
Terry Newton wrote:
>
> At 07:46 PM 4/12/99 -0700, Bob Shannon wrote:
>
> >[snip]
> >I beleive that BEAM construction and design methods will advance
> >robotics, but
> >I cannot accept the idea that Tilden's BEAM approach will ever comppete
> >with CPU
> >based robotics. The difficulty is designing and evolving a hardwired
> >controller
> >can only be justifiable if the end result is sufficiently superior to a
> >CPU based
> >design.
>
> Practically speaking, true... but how pray tell would one program
> a Symet that works better than a real one?
The only thing that comes to mind for a Symet application would be to
use a Type III solar engine, unless of course the CPU was also 'cargo'
that performed some additional function.
> I look at like this: if
> the robot only needs a handful of fixed responses (or even one) then
> no cpu is needed or desired. This covers most beam robots. A middle
> ground is when the fixed responses needed would require lots of
> circuitry, then it is convenient to replace many chips with one
> cpu chip. Then there are things like reenforcement learning, mapping
> etc that can only be (practically) achieved by using a cpu. Unless
> you want to lug around dozens of chips. Some advanced stuff can be
> hardwired but be prepared to lower your standards! I still want
> to try a static ram hardwired RL brain though... my experiments
> indicate that a 16 memory brain (4 address lines, two feelers,
> left > right and right > left light) with very simple learning
> rules works darn near as good as 64 memories with every trick
> I know to throw at it. Would take about 6 chips. If I built it,
> the only reason I could use to justify why I didn't use a cpu
> would be "it's a learning machine that doesn't use a cpu".
Clearly in this case it would not perform as well as the CPU based
design, due to the power to weight ratio!
> Hmmm... I detect some macho-ism there. BUT someone else could
> easily justify hardwiring because for them getting the necessary
> programming equipment and knowledge would be much more expensive
> than a half dozen stock chips. Unfortunately, since I did happen
> to take the time to be able to do that stuff I do not have that
> reason. It's hard to motivate myself to make a simple hardwired
> net when I know I can program a single chip to do magnitudes more.
Exactly! BEAM is only 'superior' if you are unable to properly use
a CPU, not because there is any advantage to hard-wired controllers.
> Whew! there I said it. I think... In short, if you solder, keep
> soldering there's nothing wrong with it. If you want more than simple
> responses, learn how to use micropower cpu's, it ain't that bad.
I agree there is nothing 'wrong' with soldering together small, hobbiest
BEAM devices. I simply love building BEAM creatures, for fun.
But when I want a robot to do something useful, I end up with a CPU
based
design.
> >This simply is not the case at all, a CPU can do everything a microcore
> >can do,
> >and then some. The first 'living machine', will have a CPU. Probalby
> >more of
> >them than the original Walkman has transistors.
>
> :) that ought to draw some arrows... I am not convinced of this.
> Actually computers are too sequential and deterministic to achieve
> the necessary decoupling from reality to become "alive" in any normal
> sense of the word. Some sort of quantum arctitecture will be needed.
Not at all Terry.
PIC's have schmidt trigger inputs, so all the same design tricks used in
the current BEAM technology can still be used with a non-BEAM design.
More importantly perhaps, I can write a program for a CPU that
implements
a simple cellular automata. The behavior of that automata can be used
to
drive a robot. Now we have totally disconnected the CPU's sequential
program execution from the activity that drives the robots behaviors.
A CPU does not preclude anything directly. This is where Tilden got
things
badly wrong. This is also where hype takes over from real science.
> However simulating life is good enough for me, cpu's can do that.
>
> Defending the microcore and (hardwired) neural nets in general...
> there are things going on in there that cannot be adequately simulated,
> and if quantum-(un)determinate noise influenced the neuron threshholds,
> you'd have the basic mechanism by which quantum consciousness could
> arise, at least to the complexity the architecture can support.
> Do you know what your coupled bicores are thinking about?
There is nothing that prevents this from being done with a schmit
trigger
input on a PIC is there?
Once again, the CPU does not preclude this level of operation in any
way.
> >But there is more behind the lack of science here. Without measurments,
> >we cannot
> >test the basic concept behind BEAM at all. Just how does it compare to
> >implementing
> >a stim/response based network with a CPU?
>
> Depends on the test! In a static non-changing environment then a
> hardwired network (be it real electronics or hard-coded cpu responses)
> just about always does better. In a variable environment then some
> kind of adaptability will increase the score. Imagine this... what
> if a robot gets hung up in a way that would require an opposite motion
> to free itself. A hard-wired robot would never know to try another move,
> but a learning robot would notice that the move isn't working and would
> try other moves until something worked. However in a race the hardwired
> (or hard-coded) 'bot wins every time.
I disagree. I've seen adaptive systems evolve solutions to problems the
programmer would never have tought of in advance. Thats the whole point
to a 'living' machine, it finds its own solutions to problems.
> >(No, a stimuli/response system running on a CPU is not "BEAM", just ask
> >a lawyer.)
>
> Cool. We can sell it :)
You bet!
> >[snip]
> >
> >If we want to evolve a living machine, we need to adopt a standard
> >platform.
> >
> >I think something along the lines of Terry Newton's PIC BOT II is a good
> >starting
> >point. Rather than have many people investing many hours into learning
> >how to
> >free form the same six transistors, we should invest time into
> >developing new sets of behaviors for a standard platform.
>
> Uh oh... I feel a layout coming on...
And you thought that PIC was free eh?
No good deed goes unpunished.
> >Of course we would also have to have competitions, to test which sets of
> >behaviors were superior to other sets. Identical platforms with
> >different behavior sets could be placed into an arena (not a park) and
> >observed. Simple timed trials common in animal behavior experiments
> >could be used similar to the firefighting contests.
>
> I've gotten a couple requests for kits, if I could sell at least a
> dozen or so it would pay for the circuit boards and development.
I'd buy a few!
> The programming port would double as an external sensor port for
> user-defined tasks (already is just haven't done anything with it:)
>
> >Has any BEAM design ever entered one of those? How did it do? How
> >would we know?
>
> Well... I don't think my poparound picbot would do so well either
> unless it had a battery and big motors.
>
> There's room for both, it all depends on what you want your
> robot to do, and whether you prefer solder or code. Using a
> pic or other cpu is a design decision that is getting harder
> to ignore all the time. They're out there. While not required
> or for everyone, it should come as no surprise to see them
> being used in robot designs once considered "beam". Cpus just
> got good enough to use in tiny low powered robots.
True, but if each hard-wired controller is in a unique body, we
cannot easily know how much of a given robots behavior is due to
the controller, and how much is due to the body.
I feel that the ability to 'transplant' sets of behaviors and directly
compare them in a common body.
The common body eliminates a lot of variables while permiting a direct
evaluation of different sets of behaviors. This would greatly
accelerate
behavioral development and robot evolution.
> Once a critical threshhold of users is reached the heckling
> will die down. There should Always be access to traditional
> beam designs for newcomers and those who wish not to program,
> but once people start using cpus and stuff they'll need a place
> to talk about it. Although some argue that this is off-topic for
> this list, there is no other place one can go on the internet for
> robotics that emphisise efficient, solar powered small practical
> autonomous robots. The newsgroups are a joke. People trying to
> run Linux on their robots... sheez. I much prefer it here
> where a bug can be just a bug.
I totally agree!
If BEAM is about robot evolution, then we cannot dismiss 50 years of
progress. There is a reason designers use CPU's rather than dedicated
logic.
BEAM so far has done its best to ignore this.
If we enbrace the basic ideas behind BEAM, but foget this unfortunate
and misguided bias against CPU's we can get much faster evolution than
BEAM technology has produced to date.
------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/alt-beam
Free Web-based e-mail groups by eGroups.com
Home