Alt-BEAM Archive
Message #01990
To: beam@corp.sgi.com
From: Justin jaf60@student.canterbury.ac.nz
Date: Sat, 03 Apr 1999 10:34:43 +1200
Subject: [alt-beam] Re: Socer bots/ Hive behaviour
> Selective simplification helps to build many a paper argument, but
> to paraphrase James Bond, you'd be surprised to see how much wear
> and tear these arguments suffer in the field...
Here's another selective simplification - practical problems are not
unique to BEAM technology. A selectively simplified CPU solution has
been proposed, as has a BEAM one. Both designs would require a lot of
work and modification and addition to get them to work off paper, I
don't see that this necessarily means that neigther are feasible.
Also, I make a lot of different things in a lot of different ways. It's
_very_ rare for me to discover I can't make something that I thought I
could, I'm usually pretty good at estimating the potential, and allowing
for unforeseen problems. Were I to try and make the soccer bots, the
design _would_ incorperate a lot of extra stuff specifically to solve or
allow for real world problems, long before I even picked up a
breadboard.
I am of the view (based on experience*) that problems can be solved, and
as such, tend to ignore them as somewhat irrevelant to the key
conceptual issues, which tackle the real problems.
Example: What happens if the light sources on different bots are at
different intensities (batteries flattening at different rates or
whatever)? There are several easy solutions to this, so I don't consider
it an issue.
*Most of it not directly BEAM, but close enough :-)
> Perhaps a long bar magnet below the soccer field could point at the
> `north' and `south' goals, but you may see a few surprises if you
> try that with a compass.
Why not have two bars, behind the goals, arranged so that the field of
the appropriate pole is in the playing field? This allows for
off-the-shelf parts, which a long bar magnet or electromagnet wouldn't,
and generally seems simpler and better.
>(IR) light can be blocked and reflected,
> which means trouble if you don't allow memory at all.
I don't think so. Remember, you get to build the environment as well as
the bots, which means minimal reflection, and zero blockage (ie only
partial occulsion). Regardless of this, reflection and blockage may well
actually aid the game - with so many primary sources being calculated
from, the effects of these secondary ones in even a badly designed
system, is likely to be reasonaly small, probably not even enough to add
an interesting zig to that zag, but even if it were, is that so bad?
Why build photovores if they can't find light because of reflection and
blockage? Probably because they find it in interesting ways. To tell you
the truth, I'm not sure I would try to completely remove these effects
were I to try and build it. Let them play in interesting ways.
> "Minimally functional" has not been defined.
I probably say something like:
Capible of having a game that has some form of method in the madness,
regardless of whether the untrained observer will see it, such that the
ball going into a goal could conceivably not simply be that the goal
happened to be in the way of a random knock of the ball, etc.
Admittedly, it _is_ a little more than the minimal requirement, which is
just random action, but random would seem to preclude teamwork.
(Allthough I seem to indistinctly recall an excellent philosopical
arguement that would show otherwise, however I can't remember it and was
probably just a cool sophistry anyway :-)
> The sensors and mechanical bits are indeed more likely stumbling
> blocks than the brain, but...
> Enough to fill a book :)
> To be able to select the most appropriate I&Bs I'd have to know
> what this is actually about. In a previous mail, you say:
>
> > A lot of people consider ants to be one of the epitomes of teamwork
> > and they don't do it via memory. Pheremone stimulas-response is a
> > big part of it.
>
> Ants can't play soccer. And robots can't do pheromones. You're
> discussing unspecified `teamwork' when it fits the line of your
> prose and switch back to soccer when you please.
Hmmm, I don't think so. The original post to which I was repling argued
along the lines of `BEAM can't do teamwork, therefore BEAM can't do
soccer'. Thus unspecified, generalised teamwork is the central issue,
and soccer merely an example or context to use when convenient. This is
my concept of what it is about, though I'm probably the only one viewing
it like this. Does that help? :)
> You use black and
> white flower simulated temperature control to argue that it's easy
> to keep an opponent at the optimum distance. But the latter is a
> multi-dimensional problem; it's not just distance, but also the
> angle that counts, both players and opponents move at speed and
> there is a ball in there somewhere :)
I kind of fail to see the problem here - if you can create a system that
optimises a dimension, and you have a multiple, independant, dimensional
problem, then you use multiple, independant, optimising systems. The
example I gave used two bicores for simplicity, but even that is likely
enough to give a crude "control" to distance and angle.
> You have to define the kind of teamwork you want to see and really
> look at the details, or nothing but confusing talk ever happens.
Given that I was responding to a generalisation in the order of no
teamwork is possible with BEAM technology, all I have to provide is
_any_ example of teamwork at all to prove my point. It's not a very
ambitious point really :) You are however, correct in that there would
need to be some agreement that an example was, in fact, teamwork... :-)
>From talk of anticipating team members and responding to tactics, I do
get the impression he was assuming extremely high-level teamwork, in
which case I'd be happy with statements about non-programable solutions
being unsuitable, but the generalisation was a little too broad
methinks.
For the record, if I sound like a religious BEAM zealot defending my
unshakable beliefs against the nay-sayers, I'm not - I'm more enthused
by things like biological self-correcting non-intelligent systems*,
which were similarily dismissed as incapible of performing perfectly
suited tasks, like maintaining distance.
(Also, I should add, I actually said the bots would tend to stay
reasonably near the ball, which, given the extremely choatic nature of
what I envisage, would not be immediately obvious, and could certainly
not be described as "maintaining distance", but as to the claim that
this requires high reasoning, it's pretty damn easy to design a BEAM bot
that maintains distance from a bulb, which I think pretty much sinks the
claim).
*I can't remember what these are called and it's driving me crazy! :-)
------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/alt-beam
Free Web-based e-mail groups by eGroups.com
Home