Alt-BEAM Archive
Message #04676
To: beam@sgiblab.sgi.com
From: Steven Bolt sbolt@xs4all.nl
Date: Sun, 20 Jun 1999 20:27:02 +0200 (CEST)
Subject: [alt-beam] Re: Non-beam: a Mac AVR programmer
On Sun, 20 Jun 1999, Terry Newton wrote:
> 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.
Using a beacon isn't cheating, in my book. Local navigation/manoeuvring
can be made more precise by mounting for instance interruptors and
optocouplers from a mouse on the wheels of a `bot; they make nice,
cheap shaft-encoders. Counting the pulses and performing useful
dead reckoning is well within the capabilities of a 1200, but can't
usually replace a long-range navigation sensor.
> I doubt bugs make maps but only remember direction and distance
> vectors,
If that. Pheromone trails are more important - they allow bugs to
use the actual environment as their `memory'.
> 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...)
True map-making works only in a static environment. It doesn't help
much if obstacles appear, move and disappear, as is common in the
real world. A simple `bot can't distinguish static walls from
dynamic chairs, cats and people.
> >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.
The ATMega offers 128K of flash :)
But the 1200 will do quite a bit, with 1K flash, 64 bytes eeprom,
32 registers, 15 programmable i/o (sinking up to 20mA), an analog
comparator and a timer/counter, both with their own interrupts.
And it costs just a few dollars.
> 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.
Depends on your application, of course.
---8<---
> 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.
What goes on will basically be linear, though. Mark T. seems to
emphasize non-linear aspects. Understandable/predictable circuits
are against the grain of BEAM :)
Best,
Steve
----------------------------------------------------------------------
# sbolt@xs4all.nl # Steven Bolt # popular science monthly KIJK #
----------------------------------------------------------------------
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/alt-beam
http://www.egroups.com
- Simplifying group communications
Home