Alt-BEAM Archive
Message #02295
To: beam beam@corp.sgi.com
From: Richard Piotter richfile@rconnect.com
Date: Tue, 13 Apr 1999 20:17:37 -0500
Subject: [alt-beam] Re: CPU again? (was Beam genome)
Speaking of which, I could easily pop a PIC onto my Spyder with a DAC I
could bias the thing to turn. Controll the MUXs with the processor, and
I'd have full control over it. Well, whatever. I don't know how to
program a PIC anyway! Hehe! but at least I know I CAN!!! (:
Bob Shannon wrote:
>
> 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.
--
Richard Piotter
richfile@rconnect.com
The Richfiles Robotics & TI web page:
http://richfiles.calc.org
For the BEAM Robotics list:
BEAM Robotics Tek FAQ
http://people.ne.mediaone.net/bushbo/beam/FAQ.html
------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/alt-beam
Free Web-based e-mail groups by eGroups.com
Home