To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.spyboticsOpen lugnet.robotics.spybotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / Spybotics / 367
366  |  368
Subject: 
Spybotics Experiments
Newsgroups: 
lugnet.robotics.spybotics
Date: 
Mon, 20 Sep 2004 23:04:11 GMT
Highlighted: 
(details)
Viewed: 
7075 times
  
Hi, everybody,

I'm new to this forum, and I'm glad I found it. :-)

Please note that the following is only an "preliminary
report" of a "Work in progress". :-)

Recently, I bought a couple of Spybots as buddies for
my RCX and was of course thrilled by their ability to
"see" each other via their IR "radar".
So I did a bit of experimenting and wrote the following
little test program in order to monitor the values of a
target robot via the "Watch" feature of BricxCC.

The setup was very easy: I connected one Spybot to
the PC via the serial cable, then fed it this program.
Next, I placed another bot in its immediate vicinity
(its "Here Zone"), switched both robots on, started the
program and the BricxCC Watch, which continuously polled
variables 3 to 10 every 500ms. Then I just moved the
second bot around and watched the values change.

In the program I first define two events ("entry found"
and "entry changed"). When an "entry found" event is fired,
I just nail down the first valid entry in the World
Relationship Table WRT (since I know there is only one other
robot anyway in my special setup).

When an "entry changed" event is issued, I store the
values (like Range, Direction, Aspect etc.) of the
target bot in the reserved variables for BricxCC to
watch.

This works fine, indeed, but I made the following
strange observations:

(1) Relatively often, I get an "entry changed"
event, even though nothing changed at all and the
two robots are still just sitting there. My guess is that
this may be caused by IR reflections: E.g. I wore
a bright white T-shirt, and maybe when I moved around,
the changing IR reflections caused these events.
(But then again, I did not really move that much.)
Also, it was quite strange that the bot behaved very
"excited" after I started the program, receiving
one "entry changed" event after the other, every
half second or so and then seemed to "calm down" after
a minute, "entry changed" events coming maybe every five
seconds or something the like.

(2) The readings for "Range", "Direction" and "Aspect"
were not really consistent: When I got unrelated "entry
changed" events as above, the Range, for instance, often
changed from "Here" to "There" and back. Or the bot could
not make up its mind whether the second bot (in its Here
Zone) had a direction of "front" or "front right". Or,
when I moved the second robot, the Range would change
from Here to There, then to Here or Anywhere, but apparently
often unrelated to its real distance. These erroneous values
often (but not always) "normalized" one second later.

This of course leaves the question what to do with these
values in a Spybot program. I wonder if there is any way
a program can decide whether it can rely on these values ...

And if not, what use are the Range, Direction and Aspect
readings then anyway? This would just mean that a program
could not take any reasonable actions based upon these
readings because it never knew whether the values it is
dealing with are correct or not.

(3) My setup worked also with a remote controller instead
of the 2nd Spybot, of course. Here, the readings for
Range and Direction seemed more consistent. When I switched
on a second RC, I did not get another "entry found" event,
as I expected (as was the case with two additional Spybots),
but just more "entry changed" events. This, however,
was due to the fact that both RCs transmitted on channel 1
(the default). As as soon as I linked the 2nd RC to a
second Spybot on channel 2, the second RC was recognized
as a new object and generated an "entry found" event all right.
This would mean that 2 RCs sending on the same channel
cannot be told from each other, of course. :-)

And finally for something completely different: :-)

I'm still looking for a method to easily identify a new Spybot /
RC in the WRT, when an "entry found" event has been fired. -
Lets assume a Spybot program already "knows" that there are
two other Spybots in its vicinity. Now a third bot is being
announced via an "entry found" event, so my bot knows that
there is "a new kid in town".
I'm wondering what would be the easiest way to identify this
new bot? (Except, of course, traversing the whole WRT via a
loop and ruling out the bots which are already known.)

I mean, when an "entry found" event is fired, the Spybot already
created an entry in the WRT, and the index of this entry has
to be somewhere (I hope). Otherwise these events would not be
as useful as they could be.

Many greetings from Germany

Frank


Test_Spybot_Radar.nqc:

#pragma reserve 3 10
#define targetid (@3)
#define linkid (@4)
#define range (@5)
#define direction (@6)
#define aspect (@7)
#define info (@8)
#define shortid (@9)
#define current_id (@10)
#define Sparkle(n) SetAnimation(ANIMATION_SPARKLE); Wait(50);
SetAnimation(ANIMATION_SCAN); PlaySound(n);

task main() {
  SetEvent(1, VLL(), EVENT_TYPE_ENTRY_FOUND);
  SetEvent(2, VLL(), EVENT_TYPE_ENTRY_CHANGED);
  SetAnimation(ANIMATION_SCAN);
  ClearWorld();
  while (true) {
    monitor (EVENT_MASK(1) | EVENT_MASK(2)) {
      while (true) { Wait(100); } // do nothing
    }
    catch {
      if (CurrentEvents() & EVENT_MASK(1)) {
        Sparkle(1);
        current_id = -1;
        FindWorld(current_id, SPY_RANGE, REL_GT, RANGE_NOWHERE);
        SetTargetID(current_id); // start tracking
      } else {
        Sparkle(0);
        targetid = Target(SPY_TARGETID); // same as current_id
        linkid = Target(SPY_LINKID);
        range = Target(SPY_RANGE);
        direction = Target(SPY_DIRECTION);
        aspect = Target(SPY_ASPECT);
        info = Target(SPY_INFO);
        shortid = Target(SPY_SHORTID);
      } // if
    } // catch
  } // while
} // task



1 Message in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR