|
|
| |
In lugnet.robotics.spybotics, Joe Strout wrote:
| |
In lugnet.robotics.spybotics, Steve Hassenplug wrote:
| |
On Thu, November 3, 2005 12:14 pm, Joe Strout wrote:
| |
It occurred to me that one might fit some sort of light sensors on top of
some of the six LEDs on the Spybot’s top side, and use this to select an
input channel to route information from any of a number of sensors to the
VLL sensor.
Has anybody tried this yet? Any thoughts on how well this would work, or
pointers to a suitable multiplexer circuit?
|
You can control the VLL output of the spybot, so you should be able to just
connect something much like the programming cable, and get two-way
communications.
|
Two-way communications with what? Are you picturing some sort of
microcontroller that monitors all the extra sensors, and reports values to
the Spybot upon request?
That sounds beyond my capabilities, as well as probably not as fast as the
multiplexer approach. With the latter, to read (say) one of sixteen inputs,
you just set the four LEDs to address the desired input, then take a reading
from the VLL.
To communicate with a microcontroller, you’d instead have to send the
request, then wait for a reply, both using a serial protocol. I imagine that
for some applications, polling the sensors as fast as possible would be
helpful -- but I haven’t actually done the math, so maybe this isn’t actually
relevant.
| |
Here’s a good VLL page:
http://www.elecbrick.com/lego/
|
Thanks — I’d seen that before, but hadn’t realized its relevance to
Spybotics. Hmm... that suggests all sorts of fun things one might do, like
printing VLL codes onto a transparent wheel which you then spin in front of a
light (using a standard LEGO motor), making a “beacon” that not only
advertises its presence but transmits information (identity or commands) too.
Best,
- Joe
|
Some time ago, I have sugested the use of the VLL port to make an interface to
connect a couple of lego light sensors to the spybot. The ideea was to have an
analog device (powered by a 9V bov) that would just switch on a sensor, then
switch it off and turn on a LED that would shine proportional with the amount of
light sensed by the light sensor. This LED would be connected to the spybot’s
light sensor, which in turn would make the spybot light sensor sense about the
same light intensity as the Lego light sensor. Now using the spybots LED from
the VLL port, and having a fototransistor connected to it, it can trigger a gate
to select which Lego light sensor would be read. I hope it makes sense...
After playing with other microcontrollers, I just realised that this aproach is
too complicated. A simple 8 pin PIC would do the trich much easier and is not
more expensive. I did not built it yet. Other projects got in the way, but
eventualy I will build one.
Gabe
|
|
| |
In lugnet.robotics.spybotics, John Hansen wrote:
> It is possible if you are really clever to write an
> NQC program which cooperates with the built-in ROM tasks and subroutines.
I spent some time recently working on NQC headers which would enable using more
(if not all) of the Spybot ROM subroutines and tasks with a NQC program. I
haven't done extensive testing of the headers in real programs. I hope there
are still a few Spybot users out there who might be willing to test them a bit
more than I have. There are 4 header files:
SpyGlobals.nqh
SpyInteraction.nqh
SpyBeads.nqh
SpyEvents.nqh
SpyGlobals.nqh includes SpyInteraction.nqh and SpyBeads.nqh. The header files
make use of the NQC preprocessor quite a bit to make sure that global variables
are correctly reserved and defined. The SpyEvents header file also hooks up a
special spybot event initialization routine. You can get these headers at
http://bricxcc.sourceforge.net/spynqh.zip. If you test them please let me know
if you run into any problems.
I also have a port of the Mindscript code for the Task 0 program in ROM to NQC
in the file builtin.nqc. Here it is:
#include "SpyGlobals.nqh"
#include "SpyEvents.nqh"
#define right 0 // output 1
#define left 1 // output 2
#define cAdvance 1
#define cRetreat 2
//int nMode;
#pragma reserve 9
#define nMode (@9)
task main()
{
// initialize our global variable
nMode = cAdvance;
SetPriority(2);
ResetMotors();
ResetEngine();
nStatus |= EVENT_RUNBEADS;
SetAnimation(ANIMATION_SCAN);
repeat(2)
{
PlayTone(2232, 10); Wait(20);
PlayTone(1736, 10); Wait(20);
PlayTone(1202, 10); Wait(35);
PlayTone(1202, 10); Wait(20);
PlayTone(1736, 10); Wait(20);
PlayTone(2232, 10); Wait(35);
}
SetLED(LED_MODE_ON, 0);
ResetMessages();
start MyPostWatcher;
// StartTask(cBuiltInPostWatcher);
start MyBumpWatcher;
// StartTask(cBuiltInBumpWatcher);
while(true)
{
SelectTarget();
if (Target(SPY_RANGE) > RANGE_ANYWHERE)
{
if (nMode == cAdvance)
{
if (Target(SPY_RANGE) == RANGE_THERE)
PlaySound(SOUND_MAGNET);
Advance_Bead(RANGE_HERE, 100);
}
else
{
if (Target(SPY_RANGE) == RANGE_HERE)
PlaySound(SOUND_REPULSE);
Retreat_Bead(RANGE_HERE, 100);
}
}
else
{
BasicMovement_Bead(MOVE_BASIC_SPIN_LEFT, 50);
Fx_Bead(FX_TWITTER, 25);
RandomMovement_Bead(MOVE_RANDOM_FORWARD, 100);
FancyMovement_Bead(MOVE_FANCY_BUG_FORWARD, 1, 100);
Wait(25);
}
}
}
task BumpWatcher()
{
}
task PowerUpTask()
{
int nLevel = EEPROM(EEPROM_USERLEVEL);
SetLED(LED_MODE_YELLOW, 0);
Wait(50);
if (nLevel < 16)
{
nStatus = EVENT_RUNBEADS;
CountDown_Bead(nLevel, COUNT_DIR_UP, 50);
}
ResetMotors();
Wait(100);
}
task MyPostWatcher()
{
while (true)
{
monitor(EVENT_MASK(PostEvent))
{
Wait(32767);
}
catch
{
SetPriority(0);
if ((RxMessageChannel() & MSG_IR) > 0)
{
SetRxMessageLock(MSG_IR);
if (RxMessage(MSG_IR, MSG_COMMAND) == COMMAND_CONTROLLER)
{
nControllerButton = RxMessage(MSG_IR, MSG_HI_BYTE);
nControllerButton *= 256;
nControllerButton |= RxMessage(MSG_IR, MSG_LO_BYTE);
}
switch(nControllerButton)
{
case CONTROLLER_BUTTON1:
PlayTone(3401, 3);
nMode = cAdvance;
break;
case CONTROLLER_BUTTON2:
Fire_Bead(CMD_FIRE_LASER,FIRE_TYPE_THERE_NARROW,-1,0,0,SOUND_FIRE_LASER,50);
break;
case CONTROLLER_BUTTON3:
PlayTone(2801, 3);
nMode = cRetreat;
break;
}
SetRxMessageLock(MSG_NONE);
}
}
}
}
task MyBumpWatcher()
{
while (true)
{
monitor(EVENT_MASK(BumpEvent))
{
Wait(32767);
}
catch
{
SetPriority(1);
PlaySound_Bead(SOUND_OUCH, 0);
BasicMovement_Bead(MOVE_BASIC_BACKWARD, 50);
BasicMovement_Bead(MOVE_BASIC_SPIN_RIGHT, 50);
}
}
}
|
|
| |
In lugnet.robotics.spybotics, Steve Hassenplug wrote:
| |
On Thu, November 3, 2005 12:14 pm, Joe Strout wrote:
| |
It occurred to me that one might fit some sort of light sensors on top of
some of the six LEDs on the Spybot’s top side, and use this to select an
input channel to route information from any of a number of sensors to the VLL
sensor.
Has anybody tried this yet? Any thoughts on how well this would work, or
pointers to a suitable multiplexer circuit?
|
You can control the VLL output of the spybot, so you should be able to just
connect something much like the programming cable, and get two-way
communications.
|
Two-way communications with what? Are you picturing some sort of
microcontroller that monitors all the extra sensors, and reports values to the
Spybot upon request?
That sounds beyond my capabilities, as well as probably not as fast as the
multiplexer approach. With the latter, to read (say) one of sixteen inputs, you
just set the four LEDs to address the desired input, then take a reading from
the VLL.
To communicate with a microcontroller, you’d instead have to send the request,
then wait for a reply, both using a serial protocol. I imagine that for some
applications, polling the sensors as fast as possible would be helpful -- but I
haven’t actually done the math, so maybe this isn’t actually relevant.
| |
Here’s a good VLL page:
http://www.elecbrick.com/lego/
|
Thanks — I’d seen that before, but hadn’t realized its relevance to Spybotics.
Hmm... that suggests all sorts of fun things one might do, like printing VLL
codes onto a transparent wheel which you then spin in front of a light (using a
standard LEGO motor), making a “beacon” that not only advertises its presence
but transmits information (identity or commands) too.
Best,
- Joe
|
|
| |
On Thu, November 3, 2005 12:14 pm, Joe Strout wrote:
> It occurred to me that one might fit some sort of light sensors on top of some
> of the six LEDs on the Spybot's top side, and use this to select an input
> channel to route information from any of a number of sensors to the VLL sensor.
>
> Has anybody tried this yet? Any thoughts on how well this would work, or
> pointers to a suitable multiplexer circuit?
You can control the VLL output of the spybot, so you should be able to just connect
something much like the programming cable, and get two-way communications.
Here's a good VLL page:
http://www.elecbrick.com/lego/
Steve
|
|
| |
It occurred to me that one might fit some sort of light sensors on top of some
of the six LEDs on the Spybot’s top side, and use this to select an input
channel to route information from any of a number of sensors to the VLL sensor.
Has anybody tried this yet? Any thoughts on how well this would work, or
pointers to a suitable multiplexer circuit?
Thanks,
– Joe
|
|
| |
In lugnet.robotics.spybotics, Joe Strout wrote:
| |
I’ll keep y’all posted on my progress, so if somebody else comes along later
in the same boat, they can learn from my mistakes!
|
Well, here’s one: don’t buy a Dynex USB-to-serial adapter. The packaging and
web site both claim it’s Mac compatible, but I tried it on two different
machines (a G4 Powerbook running 10.2.8 and a dual G5 desktop running 10.3.9),
and two different serial apps (MacNQC and an app I wrote myself a while back to
test serial devices), and neither one sees this Dynex gadget as a serial port at
all.
I called Dynex tech support, and they were very nice, but utterly unhelpful.
Their answer amounted to, “It should just work.” Well, it doesn’t.
Everything I read indicates that the Keyspan ‘USA-19HS’ is the right gizmo to
use. It’s a bit hard to find in the stores — I’m going to have to order mine
online — but I bet it will work reliably. More later when I have positive
results.
Best,
– Joe
|
|
| |
In lugnet.robotics.spybotics, Timothy P. Smith wrote:
| |
Best way to get started would be to buy an RCX and a PC!
;)
|
Heh -- if robotics required a PC, I’d take up knitting instead!
| |
Seriously, if you can’t get NQC to run on your Mac, you might be able to find
a decent Windows Emulator that does and use that. Or buy or be given an older
PC- doesn’t take a lot of processing power to do this...
|
No need; MacNQC seems to run great and looks like a really nice environment. It
goes beyond just compiling & downloading NQC code, and includes various
interactive panels that let you query & control the robot directly. It also
looks like it should work fine with the Spybot controller.
My problem at the moment is that the USB/serial converter I have is the wrong
type; it’s got a MINIDIN-8 connector on the end instead of the DB9 needed by the
Spybotics cable. I found another Mac Spybotics user in my area, and he had a
similar problem until he got a USB/serial-DB9 converter, and now it’s working
fine for him. So that’s probably all I need.
I’ll keep y’all posted on my progress, so if somebody else comes along later in
the same boat, they can learn from my mistakes!
Best,
- Joe
|
|
| |
In lugnet.robotics.spybotics, Joe Strout wrote:
| |
I got a surprise birthday present of a Spybotics set #3808 (is my wife cool
or what?). I don’t have a Windows machine, but I dug around on the CD-ROM,
found the building instructions, and got it working. I’m able to drive it
around with remote control, and on occasion even manage to make it grab a
sock or small toy.
Then I tuned in here to see what else people are doing, and to my amazement,
I see people talking about programming these things in NQC! I had no idea
that was possible.
But I’m having trouble finding any introduction to the topic. I have several
Macs running OS X, and I have a USB/serial adapter, so I think the hardware
should be fine. I see references to MacNQC, though the
MacNQC home page only seems to
mention the RCX.
So I’m a bit like a babe in the woods here, or whatever the saying is... can
anyone point me to an orientation on what the Spybotics controller can do,
and how to make it do it? Maybe some sample programs, with instructions on
how to compile and download them?
Many thanks,
- Joe
|
Best way to get started would be to buy an RCX and a PC!
;)
Seriously, if you can’t get NQC to run on your Mac, you might be able to find a
decent Windows Emulator that does and use that. Or buy or be given an older PC-
doesn’t take a lot of processing power to do this... I’ve got an old laptop that
I use for this purpose, the prior owner gave it to me for free when I explained
what I wanted it for.
HTH,
Tim (Smith)
|
|
| |
In lugnet.robotics.spybotics, Joe Strout wrote:
| |
Then I tuned in here to see what else people are doing, and to my amazement,
I see people talking about programming these things in NQC! I had no idea
that was possible.
|
What limited Spybots programming I’ve done has been based on two things.
First, this site:
http://users.ncable.net.au/~blane/smartParts/index.htm
linked to off the .spybotics frontpage is a great resource as far as it goes
(with some examples in NQC even). Second, digging through and testing the stuff
from the Spybotics SDK.
| |
But I’m having trouble finding any introduction to the topic.
|
At least partially because there isn’t any really simple tutorial. The
Spybotics stuff wasn’t ment for programming as much (it seems to me), and
there’s a lot of pitfalls that are possible in using the built-in ROM routines.
--
Brian Davis
|
|
| |
I got a surprise birthday present of a Spybotics set #3808 (is my wife cool or
what?). I don’t have a Windows machine, but I dug around on the CD-ROM, found
the building instructions, and got it working. I’m able to drive it around with
remote control, and on occasion even manage to make it grab a sock or small toy.
Then I tuned in here to see what else people are doing, and to my amazement, I
see people talking about programming these things in NQC! I had no idea that
was possible.
But I’m having trouble finding any introduction to the topic. I have several
Macs running OS X, and I have a USB/serial adapter, so I think the hardware
should be fine. I see references to MacNQC, though the
MacNQC home page only seems to mention
the RCX.
So I’m a bit like a babe in the woods here, or whatever the saying is... can
anyone point me to an orientation on what the Spybotics controller can do, and
how to make it do it? Maybe some sample programs, with instructions on how to
compile and download them?
Many thanks,
- Joe
|
|
| |
In lugnet.robotics.spybotics, Steve Hassenplug wrote:
> On Tue, October 18, 2005 5:05 am, Allen Benter wrote:
> > perhaps you can help me with the directional capabilities. I have attached a
> > copy of my code below.
> >
> > I am reading the direction to another spybot/beacon and putting it through a
> > simple least squares adjustment. I find over short distance (HERE and maybe
> > THERE) I can get very good directions with as little as 5 consecutive sensor
> > readings. But when I extend this beyond the there zone (about 1m/3ft) I find
> > the spybot always reports direction as CENTER.
>
> I can't find it right now, but I thought I read somewhere that if the direction is
> "anywhere", it will not have a direction. I believe that's consistant with what
> you're seeing.
>
> Steve
Steve,
I think your right. A quick look into the ROM documentation shows "Sub Index 83
(p.139) TurnAway_Bead - Tries to turn the Spybot away from the target. If there
is no target, or if the target is in the Anywahere zone, the bead exits
immediately." This is similar for bead 84 - Advance_Bead.
The PointTo_Bead (#82) just spins left if the target is in the anywhere zone,
most likely just waiting for the target to get closer into the there/here zone.
And yet there are examples of people apparently getting directional readings at
2 metres? http://www.brickshelf.com/cgi-bin/gallery.cgi?i=574934
Anyway, until somethig more concrete comes up, I'll just have to limit the focus
down to the there/here zones.
Thanks again for your reply Steve. If you find the reference, I'd still be
pleased to read it.
Cheers,
Allen
|
|
| |
On Tue, October 18, 2005 5:05 am, Allen Benter wrote:
> perhaps you can help me with the directional capabilities. I have attached a
> copy of my code below.
>
> I am reading the direction to another spybot/beacon and putting it through a
> simple least squares adjustment. I find over short distance (HERE and maybe
> THERE) I can get very good directions with as little as 5 consecutive sensor
> readings. But when I extend this beyond the there zone (about 1m/3ft) I find
> the spybot always reports direction as CENTER.
I can't find it right now, but I thought I read somewhere that if the direction is
"anywhere", it will not have a direction. I believe that's consistant with what
you're seeing.
Steve
|
|
| |
Sorry,
I forgot to mention I am using nqc 3.1r4
Allen
In lugnet.robotics.spybotics, Allen Benter wrote:
> John,
>
> perhaps you can help me with the directional capabilities. I have attached a
> copy of my code below.
>
|
|
| |
John,
perhaps you can help me with the directional capabilities. I have attached a
copy of my code below.
I am reading the direction to another spybot/beacon and putting it through a
simple least squares adjustment. I find over short distance (HERE and maybe
THERE) I can get very good directions with as little as 5 consecutive sensor
readings. But when I extend this beyond the there zone (about 1m/3ft) I find
the spybot always reports direction as CENTER.
Do you get different results? I have 4 beacons and 5 spybots, and basically get
the same results each time. The batteries I am using are NiMH and fully
charged. The beacon light appears strong (if that is any indication of battery
strength).
I have wondered how much my floor type & room size affects the IR sensor.
Any tips you have on the IR sensor readings would be very much appreciated.
Cheers,
Allen
#pragma reserve 0 20
#define sum_x (@12)
#define sum_y (@13)
#define sum_x_2 (@14)
#define sum_xy (@15)
#define intercept (@16)
#define updated (@17)
task main()
{
int spy_direction;
int TARGET;
sum_x = 0;
sum_y = 0;
sum_xy = 0;
sum_x_2 = 0;
start display;
SetPingInterval(1);
ClearCounter(0);
spy_direction = 0;
TARGET = -1;
ClearWorld();
Wait(500);
FindWorld(TARGET, SPY_RANGE, REL_GT, RANGE_NOWHERE);
while(TARGET < 0)
FindWorld(TARGET, SPY_RANGE, REL_GT, RANGE_NOWHERE);
SetTargetID(TARGET);
while(true)
{
//PlaySound(SOUND_CLICK);
spy_direction = Target(SPY_DIRECTION);
if(spy_direction > -1 && spy_direction < 5)
{
IncCounter(0);
sum_x_2 = sum_x_2 + Counter(0)*Counter(0);
sum_x = sum_x + Counter(0);
sum_xy = sum_xy + Counter(0) * spy_direction;
sum_y = sum_y + spy_direction;
least_square();
}
//Wait(50);
if(sum_x_2 > 25000)
{
sum_x = 0;
sum_y = 0;
sum_xy = 0;
sum_x_2 = 0;
ClearCounter(0);
//PlaySound(SOUND_DOUBLE_BEEP);
}
}
}
task display()
{
int state;
while(true)
{
// put direction on green LEDs & distance on red LEDs
//state = (spy_distance & 0x7) | ((avg_dir & 0x7) << 3) ;
until(updated);
SetLED(LED_MODE_ON, intercept);
}
}
void least_square()
{
int ssx;
int ssxy;
int b1;
updated = false;
ssx = sum_x_2 - ((sum_x * sum_x)/Counter(0));
ssxy = sum_xy - ((sum_x * sum_y)/Counter(0));
b1 = ssxy / ssx;
intercept = (sum_y / Counter(0)) - (b1 * (sum_x / Counter(0)));
updated = true;
}
In lugnet.robotics.spybotics, John Hansen wrote:
> In lugnet.robotics.spybotics, Daniel Wittenaar wrote:
> > In lugnet.robotics.spybotics, Daniel Wittenaar wrote:
> > > In lugnet.robotics.spybotics, Brian B. Alano wrote:
> > > > /*
> > > > beacon.nqc <<
>
> There was a bug in the code generated by NQC for the find opcode prior to
> version 3.1r2. If you are using a version of NQC older than 3.1r2 then that
> *might* explain why Brian's beacon.nqc program fails to work sometimes.
>
>
> John Hansen
|
|
| |
In lugnet.robotics.spybotics, John Hansen wrote:
> There was a bug in the code generated by NQC for the find opcode prior to
> version 3.1r2. If you are using a version of NQC older than 3.1r2 then that
> *might* explain why Brian's beacon.nqc program fails to work sometimes.
>
> I will try to find a copy of the MindScript code for the default program and
> port it to NQC if possible for you.
I have found a copy of the MindScript code for the default program (sort of) and
I have ported it to NQC.
Here's the default program in MindScript:
program SpybotDefaultProgram
{
main
{
start 0
}
}
And here is its NQC equivalent:
#pragma noinit
task main()
{
StartTask(0);
}
Unfortunately, these programs don't help much since all either one does is start
Task 0 in the Spybot ROM. It is possible if you are really clever to write an
NQC program which cooperates with the built-in ROM tasks and subroutines. But
it is not an easy road to take and may not be possible given the specific
requirements of your robot.
John Hansen
|
|
| |
In lugnet.robotics.spybotics, Daniel Wittenaar wrote:
> In lugnet.robotics.spybotics, Daniel Wittenaar wrote:
> > In lugnet.robotics.spybotics, Brian B. Alano wrote:
> > > /*
> > > beacon.nqc <<
>
> Nobody who can help us out on this one?? I'm looking for the NQC comando's that
> can control (readout) the sensor on the rear of the spybot.. This can be used as
> told above to determen if the beacon is in front of the spybot.. Or behind the
> spybot.. That all to give the spybot a better left right sense..
>
> The sensor that is in the back is SENSOR_2 And can be used for IR comunication
> trough air.. But i'm not pretty sure how to put things together..
There was a bug in the code generated by NQC for the find opcode prior to
version 3.1r2. If you are using a version of NQC older than 3.1r2 then that
*might* explain why Brian's beacon.nqc program fails to work sometimes.
I will try to find a copy of the MindScript code for the default program and
port it to NQC if possible for you.
John Hansen
|
|
| |
Hi Daniel,
I can't really help you all that much, but some thoughts on my own experiments
regarding the use of direction/range with the Spybot.
I have found the direction readings to be very poor when the object is in zones
there or anywhere. Once the object enters the here zone, it is reasonably good.
Perhaps this is more a factor of the room I am in (very light coloured flat
walls - a brick room may give better results as you will not get the same IR
reflections).
I have in mind as my next project to develop the spybots into a soccer team
under the rules of RoboCup Junior. To do this however requires the use of the
rear sensor for position tracking on the grey scale floor mat. So I cannot use
the rear sensor for sensing the position of the ball.
Do you have a team of spybots? Maybe you could combine the sensor readings from
both robots and perform something like least squares analysis to determine where
the ball is?
I don't think that Lego would use the light sensor at the rear, because the
normal construction uses this connected to a light tube that, from memory,
points forward. But then I may be wrong.
Which program do you load up to use the directional capabilities? One way to
work out how Lego are doing it, is to watch the program as it is being uploaded
into the Spybot, and then look at the individual bytes codes to see which rom
routines they are using. You can do this using some demo software called Serial
Monitor by www.hhdsoftware.com. As you upload the program to the Spybot, it
will capture the data flowing over the serial port and allow you to see the
actual byte codes being sent to the spybot.
If you would like to email me, I can send you a document I wrote on how to
communicate with the Spybot. I wrote a small program in java that can upload
byte codes direct to the Spybot. It's not much use, but you are welcome to have
it if you want.
Good luck, and keep us all posted on your results.
Allen
In lugnet.robotics.spybotics, Daniel Wittenaar wrote:
> In lugnet.robotics.spybotics, Daniel Wittenaar wrote:
> > In lugnet.robotics.spybotics, Brian B. Alano wrote:
> > > /*
> > > beacon.nqc <<
>
> >
> > Well We are trying to get Spybotics following an IR emitting Ball.. This ball
>
> Nobody who can help us out on this one?? I'm looking for the NQC comando's that
> can control (readout) the sensor on the rear of the spybot.. This can be used as
> told above to determen if the beacon is in front of the spybot.. Or behind the
> spybot.. That all to give the spybot a better left right sense..
>
> The sensor that is in the back is SENSOR_2 And can be used for IR comunication
> trough air.. But i'm not pretty sure how to put things together..
>
> Daniel Wittenaar
|
|
| |
In lugnet.robotics.spybotics, Daniel Wittenaar wrote:
> In lugnet.robotics.spybotics, Brian B. Alano wrote:
> > /*
> > beacon.nqc <<
>
> Well We are trying to get Spybotics following an IR emitting Ball.. This ball
> will be emitting the same data as the Controller does on blinking mode..
>
> But somehow the program above (as said before) Will not work propperly and send
> the spybot as well away as to the ball because it has some problem to determine
> where the signal comes from..
>
> Somehow Lego did manage that good.. Because if i take the default programm in
> the Spybotic that can indicte and find the 'beacon' (controller) It can find it
> perfectly without very much problems...
>
> Maybe Lego is also using the IR sensor that is stcked in behind to determen if
> it comes from the front or from the rear...
>
> Is somebody intrested to help us out to get a more stable program that will find
> the beacon in 98% of the time???
>
> Many thanks in advanced,
> Daniel Wittenaar
Nobody who can help us out on this one?? I'm looking for the NQC comando's that
can control (readout) the sensor on the rear of the spybot.. This can be used as
told above to determen if the beacon is in front of the spybot.. Or behind the
spybot.. That all to give the spybot a better left right sense..
The sensor that is in the back is SENSOR_2 And can be used for IR comunication
trough air.. But i'm not pretty sure how to put things together..
Daniel Wittenaar
|
|
| |
Hi,
> I would like to know how to send and
> receive serial data from the RCX to a Sptbot and vice versa.
Sorry, I don't have an RCX so can't really help you there. The NQC Guide is
pretty good. The best way to find out is to try lots of combinations.
> Also, is serial the
> only way to communicate between two Spybots or is there a simpler way to
> communicate, if so, please let me know.
Here are a couple of programs where two Spybots send messages to each other.
Another way to send simple messages to all spybots is to use PingData().
Basically on the Spybot you SetPingData(55) which broadcasts a this data with
its ping. A good use of this is to let everyone else know what state you are in.
Make sure that PingInterval is not set to 0, though. All the other robots can
then find Spybots which are broadcasting a particular number using
FindWorld(spybot_index, SPY_INFO, REL_EQ, 55) will find the next spybot where
the ping info equals 55. The world relation table index will be stored in
spybot_index which you can then use to set as your target
SetTargetID(spybot_index).
Good luck!
Allen
/***********************************************************
* file: message_blue.nqc
* date: September, 2005
* auth: Allen Benter
* desc: This program broadcasts 4 messages to all spybots.
* It also listens for any messages received and will
* display the value on the LEDs
***********************************************************/
#define MESSAGE_EVENT 1
int MESSAGE;
task main()
{
SetEvent(MESSAGE_EVENT, VLL(), EVENT_TYPE_MSG_RECEIVED);
start listen;
start talk;
while(true)
SetLED(LED_MODE_ON, MESSAGE);
}
task listen()
{
while (true)
{
monitor (EVENT_MASK(MESSAGE_EVENT))
{
Wait(1000);
}
// message caught
catch
{
MESSAGE = RxMessage(MSG_IR, MSG_COMMAND);
}
}
}
task talk()
{
PlaySound(SOUND_DOUBLE_BEEP);
SendSpybotMessage(INDEX_BROADCAST, 10, 0, 0);
Wait(500);
PlaySound(SOUND_DOUBLE_BEEP);
SendSpybotMessage(INDEX_BROADCAST, 20, 0, 0);
Wait(500);
PlaySound(SOUND_DOUBLE_BEEP);
SendSpybotMessage(INDEX_BROADCAST, 30, 0, 0);
Wait(500);
PlaySound(SOUND_DOUBLE_BEEP);
SendSpybotMessage(INDEX_BROADCAST, 40, 0, 0);
Wait(500);
} //end of message_blue.nqc
/***********************************************************
* file: message_red.nqc
* date: September, 2005
* auth: Allen Benter
* desc: This program listens to all messages.
* If it receives a message with a value of 30 it
* switches to state 1 and sends out a message
***********************************************************/
#define MESSAGE_EVENT 1
int MESSAGE;
int STATE;
task main()
{
STATE = 0;
SetPingInterval(1);
SetEvent(MESSAGE_EVENT, VLL(), EVENT_TYPE_MSG_RECEIVED);
start listen;
start talk;
while(true)
SetLED(LED_MODE_ON, MESSAGE);
}
task listen()
{
while (true)
{
monitor (EVENT_MASK(MESSAGE_EVENT))
{
Wait(1000);
}
// message caught
catch
{
MESSAGE = RxMessage(MSG_IR, MSG_COMMAND);
if(MESSAGE == 30)
STATE = 1;
else
STATE = 0;
}
}
}
task talk()
{
while(true)
{
switch(STATE)
{
case 0:
break;
case 1:
SendSpybotMessage(INDEX_BROADCAST, 15, 0, 0);
PlaySound(SOUND_DOUBLE_BEEP);
Wait(100);
break;
}
}
}// end of message_red.nqc
|
|
| |
In lugnet.robotics.spybotics, Brian B. Alano wrote:
> /*
> beacon.nqc
>
> Uses World Relation Table to get a fix on and drive to another object.
> The object can be a Spybot, PC, or Spybot Controller.
>
> The program fixes on (i.e. drives to) the first object it finds. If that
> object disappears from the "radar", it will fix on the next one. The
> program exits when none are in range.
>
> Functions illustrated:
> ClearWorld()
> FindWorld([WorldIndex], SPY_RANGE, REL_GT, RANGE_NOWHERE)
> SetTargetID([WorldIndex])
> Target(SPY_RANGE)
> Target(SPY_DIRECTION)
>
> Thoughts and discoveries.
> 1. The Spybot suffers from the same ills that most two-eared creatures do,
> it can't tell whether an object is ahead left or behind right. This
> leads it to go in the opposite direction that it should sometimes. There's a
> word for this phenomenon, but I can't recall it.
>
> 2. I only registered LEFT_OF_CENTER and RIGHT_OF_CENTER when the
> object was also in RANGE_HERE.
>
> 3. This program usually failed to fix acurately on a second target
> after the initial target went to RANGE_NOWHERE.
>
> 4. There's probably a ROM routine that does the same thing as this
> program, but it may not be useful from NQC.
>
> Uses spy.nqh by John Hansen released 22 Oct 2003. See
> http://news.lugnet.com/robotics/spybotics/?n=235
>
> * The contents of this file are subject to the Mozilla Public License
> * Version 1.0 (the "License"); you may not use this file except in
> * compliance with the License. You may obtain a copy of the License at
> * http://www.mozilla.org/MPL/
>
> */
>
> #include "spy.nqh"
>
> // Convenience macros for my particular 'bot.
> #define FWD(x) OnRev(x)
> #define REV(x) OnFwd(x)
> #define OUT_LEFT OUT_B
> #define OUT_RIGHT OUT_A
>
> task main()
> {
> int t = -1; // our index into the World Relation Table
> int x; // temp var
> int range; // range to the current target
> int state = 0; // used for displaying SHORT_ID and RANGE on LEDs
> ClearWorld(); // empty the World Relation Table
> // wait for pings to be recieved.
> // I think this wait could be smaller, but I don't know by how much.
> // Probably something like 2x the default ping interval is enough.
> Wait(100);
> // FindWorld sets t to the next valid index in the World Relation Table
> // or to -1 if there are no more entries.
> FindWorld(t, SPY_RANGE, REL_GT, RANGE_NOWHERE);
> while (t != -1)
> {
> // By using SetTargetID, we can use the Target() convenience methods
> // for accessing the properities of the device.
> SetTargetID(t);
> x = Target(SPY_SHORTID);
> // put ID of the current target in red LEDs
> state = x & 0x7;
> SetLED(LED_MODE_ON, state);
> // Insure object is still in range before assuming other values are
> good.
> range = Target(SPY_RANGE);
> while (range != RANGE_NOWHERE) {
> x = Target(SPY_DIRECTION);
> // put direction on green LEDs
> state = (state & 0x7) | ((x & 0x7) << 3) ;
> SetLED(LED_MODE_ON, state);
>
> if (range == RANGE_HERE) { // we made it!
> Off(OUT_A+OUT_B);
> } else {
> // Turn and move toward the target
> switch (x) {
> case DIRECTION_LEFT:
> REV(OUT_LEFT);
> FWD(OUT_RIGHT);
> break;
> case DIRECTION_LEFT_OF_CENTER:
> Float(OUT_LEFT);
> FWD(OUT_RIGHT);
> break;
> case DIRECTION_CENTER:
> FWD(OUT_LEFT+OUT_RIGHT);
> break;
> case DIRECTION_RIGHT:
> REV(OUT_RIGHT);
> FWD(OUT_LEFT);
> break;
> case DIRECTION_RIGHT_OF_CENTER:
> Float(OUT_RIGHT);
> FWD(OUT_LEFT);
> break;
> default:
> // should never get here
> PlaySound(SOUND_LOW_BEEP);
> } // end switch
> } // end if range
> range = Target(SPY_RANGE); // update the range to the target
> } // end while in range
> // If we're here, it means our current target moved to RANGE_NOWHERE
> // so we need to acquire a new target.
> FindWorld(t, SPY_RANGE, REL_GT, RANGE_NOWHERE);
> } // end while
>
> }
Well We are trying to get Spybotics following an IR emitting Ball.. This ball
will be emitting the same data as the Controller does on blinking mode..
But somehow the program above (as said before) Will not work propperly and send
the spybot as well away as to the ball because it has some problem to determine
where the signal comes from..
Somehow Lego did manage that good.. Because if i take the default programm in
the Spybotic that can indicte and find the 'beacon' (controller) It can find it
perfectly without very much problems...
Maybe Lego is also using the IR sensor that is stcked in behind to determen if
it comes from the front or from the right...
Is somebody intrested to help us out to get a more stable program that will find
the beacon in 98% of the time???
Many thanks in advanced,
Daniel Wittenaar
|
|
|
