Alt-BEAM Archive
Message #00660
To: Terry Newton wtnewton@nc5.infi.net, beam beam@corp.sgi.com
From: Sean Rigter rigter@cafe.net
Date: Fri, 19 Feb 1999 16:15:06 -0800
Subject: [alt-beam] Re: hmmm...i wonder which subject
Hello Terry et al,
I just tuned into this thread, so oops if I repeat old news.
There may be an interesting analogy in the "real" world.
If you have ever pointed a camcorder at a connected monitor you may have
had an opportunity to explore an exquisitely complex feedback system.
Warning "tuning" is required, mileage varies, older hardware gives the
best results:
Use a tripod, position camera level with center and about 3-4 ft away
from the screen, tilt the camera about 45 degree with respect to the
screen defocus, adjust zoom, turn down the lights adjust brightness
contrast, color, and hue , do it all again until something interesting
starts to happen, tilt, push, pull, squint, turn on ozzy osbourne and
suddenly ..... watch the most amazing cellular automata come to life!
Now that's about the complexity of advanced BEAM!
I can't image adding a micro processor to this form of virtual machine
"life" but I am searching for a hardware solution (other than the CAM8)
just try it!
\|/
wilf - (c) - rigter
/|\
Terry Newton wrote:
>
> At 11:07 AM 2/19/99 +0100, Steven Bolt wrote:
> >On Thu, 18 Feb 1999, Terry Newton wrote:
> >> Nevertheless the walker is much more functional with the
> >> processor than without. Not for intelligence reasons but for
> >> the on/off timer, wakeup on approach, a monitor that resets the
> >> microcore if it saturates, sensor processing, reverse timing, etc.
> >> If I would have hardwired all those neat functions it would of been
> >> much more complicated.
> >
> >But it seems that it would be less complicated and just as
> >functional if you let the uC control the motors with nothing but
> >dumb drivers in between.
>
> In the case of walkers, you may be correct, but such a setup
> probably will -not- be any better than a good analog design.
> If I learned anything I learned one can't throw smarts at a
> CPG walker and make it smarter. Mechanical sensors on the body
> work just as well. I'm also old fashioned and believe there is
> some truth to the notion that a real microcore is a computer of
> a different kind and probably cannot be fully captured in a
> simulation. The sim might walk, but the real thing will probably
> walk better and is certainly cooler.
>
> > From your documentation I got the strong
> >impression that the Nervous Net was a problem rather than a
> >solution in your case:
> >
> > A big problem with controlling microcore walking robots is the
> > control signals don't cause the same motion every time,
> >---8<---
> > Trying to make it do specific things is frustrating, rather you
> > have to let it find a solution that it likes. If you don't like
> > what it's doing, you have to find learning rules that trick it
> > into behaving the way you want it to,
>
> These are problems with using a CPG to drive motors with no real
> positional feedback, not problems with the nervous network itself.
> A simulation would have the same problem.
>
> >What I was looking for in this discusion is an example of synergy,
> >a combination of uC and Nervous stuff which is more capable then
> >either would be on its own.
>
> I think I came close to achieving that, although most of the
> functions that the PIC ended up being good at could easily be
> hardwired. Whereas other designs increased in capability by
> magnitudes by addition of a memory brain, the walker gained
> only about 50% and then only after I simplified it.
>
> > In your pages, it is easy to find
> >arguments for having a uC in control, but the Nervous Net family of
> >things doesn't appear to hack it. You conclude that
> >
> > I'm left with the feeling that much more will be needed to make
> > these devices useful in the real world.
>
> :) I further conclude that real world operation is not necessary
> to have fun and learn. The statement implies that I thought that
> eventually real-world applications would be achieved, still do.
> The "much more" doesn't have to be cpu, I've been seeing some
> mighty fine analog solutions lately that push the state of the art.
>
> The fundamental problem, at least as far as 2-motor walkers are
> concerned, is gaining useful control over steering. Stamp walkers
> turn on a dime because they use servos with exact positioning.
> Of course by doing that you lose adaptibility to terrain. The very
> thing that inhibits external control gives the microcore (or even a
> simulated CPG on a processor) abilities a stamp walker can only wish
> for. This is not a cpu problem at all, it's how to make it do our
> wishes irregardless of what components are selected to do the
> controlling. There is very little information about how best to
> connect feelers and eyes to a microcore. Hook 'em somewhere?
> I think more motors are needed to solve the steering problem.
> More research too.
>
> >And proceed with a (very interesting :) project based on a
> >programmable device, with nothing Nervous on the parts list.
>
> I had to regain my sanity with something almost guaranteed
> to work the way I wanted it to work.
>
> >Which brings me to a next subject:
> >
> >[ Is the `brain' overrated? ]
>
> Probably. Must match body capabilities or mass confusion results.
> For walkers, no brain at all is probably a better solution.
> Otherwise, intelligence is limited by the body and the senses
> no matter how smart you try to make it. For walkers anything
> more than 7 bytes proved overkill, the pic-bot popper likes
> around 64 bytes, and the owi spider hack with IR has hundreds
> of memories and had quite an attitude until his gears stripped.
> Seems like rather than me rating the brain, the brain size that
> worked the best rated the capabilities of the different bodies.
>
> >I have great respect for Terry's work on machine learning. And that
> >bridge will no doubt have to be crossed, but imho much more than
> >the present level of capability can be reached without any learning
> >at all.
>
> Like a hard-wired reversing obstacle avoiding photovore. Being able
> to back up makes all the difference in the world. Someone's gotta
> do a (beam) photopopper that backs up, a pair of h-bridges and some
> minor logic, shouldn't be that difficult. The most useful thing
> about my PIC-bot popper was not that it could learn (always learns
> about the same thing anyway) but that it could back away from
> obstacles in its way and not get stuck. There is much work to be
> done with simple analog circuits and bodies, please keep it coming.
> Like those 1 chip reversible walkers! Now that's beam.
>
> Terry Newton
------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/alt-beam
Free Web-based e-mail groups by eGroups.com
Home