Alt-BEAM Archive
Message #04697
To: beam beam@corp.sgi.com
From: Terry Newton wtnewton@nc5.infi.net
Date: Mon, 21 Jun 1999 10:57:43 +0800
Subject: Re: Non-beam: a Mac AVR programmer
> At 09:26 PM 6/20/99 +0000, Ben Hitchcock wrote:
>
> >If anyone's interested in getting into AT90S1200's (A pretty cool uP with
> >internal EEPROM so your robot can 'remember' where walls are when the
power
> >cuts out)
>
> Good luck on that one, best I've been able to do is remember what
> to do when encountering a wall with particular characteristics. The
> localisation methods I've seen are too complex to fit on a small
> processor. Answering the questions "where am I", "what direction am
> I pointing" and "how far did I just go" are major problems unless
> you majorly cheat and use beacons or something like that. I doubt
> bugs make maps but only remember direction and distance vectors,
> relying on hard-wired instincts to get there, but even that takes
> some localisation skills. Not to discourage map-making, I'm sure
> I'll try. (just a program, worst that can happen is nothing...)
>
> >I'm starting to think that using a microprocessor doesn't have to be
> >non-BEAM because it's the mindset, not the method, that makes BEAM so
> >successful.
>
> Yep. In fact, a minimalist mindset is almost a necessity to make use
> of tiny processors, you can't just take existing "big-robot" methods
> and translate because there is only 1K-2K to fit your program and
> a miniscule 32-64 bytes of memory, plus whatever the eeprom has.
> Most programmers scream when confronted with such limited resources,
> but beamers are used to minimalism. If approached using a philosophy
> akin to beam, then it seems like a lot! Traditional robotists usually
> don't get this, they often need 32-64K or even hard-drives and OS's.
> Approached from the opposite (and wrong imo) direction.
>
> > For example, if you program the robot to use a couple of
> >different 'rules' that operate in parallel (Such as the light seeking
except
> >when a touch sensor is triggered) instead of the traditional uP serial
> >instructions (go forward, if you hit a wall then reverse, then turn, then
go
> >forward again).
>
> Here's a simple "no-if" robot... in pseudocode...
>
> loop until power runs out...
> get light level in leftlight, rightlight (range 0-127)
> get feeler bits in leftfeeler, rightfeeler
> motorL = rightlight + 30 (photo behavior transforms)
> motorR = leftlight + 30
> reverseL bit = right feeler bit
> reverseR bit = left feeler bit (seen this before:)
> run motors using motorL, motorR and bits reverseL, reverseR
>
> Something like this could be termed a Braitenberg Vehicle
> class 2b with reversers on the feelers. For class 3a...
> motorL = 150 - leftlight
> motorR = 150 - rightlight
>
> Other beam-like programming methods are possible... bicore-like
> things are easy to code (two counters that reset each other)
> and do all sorts of wonderfully crazy things from emulating
> existing beam designs to interconnecting themselves under
> evolutionary control. Processors can do almost anything beam
> circuits can, but allow the experimenter to take the concepts
> to the nth degree and do things that would be almost impossible
> to hard-wire.
>
> > You might even have a uP 'brain' that tells the BEAM body
> >what it would like to see happen, but the BEAM body could override the uP
> >when it needed to. Just an idea.
>
> Or use a uP to process senses and deliver them to an otherwise
> normal beam circuit. One nice thing about this kind of architecture
> is you can take wire cutters to the brain and it continues to
> function. Not that that's an important consideration, often
> it is more practical to make it all-uP and save parts.
>
> >Anyway, I just thought I'd let people know about it. I know all too well
> >about the multitudes of PC software out there for electronics, and the
vast
> >chasm where the mac equivalents should be. Perhaps if enough of us start
> >doing things like this, we might be able to start to fill that void.
>
> Hopefully this will be a trend... Mac users shouldn't be left out.
> Anyone know of Mac PIC programming software?
>
> Terry Newton
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/alt-beam
http://www.egroups.com
- Simplifying group communications
Home