|
|
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
|
|
|
Hello everybody,
This is my first post, I hope someone can help. I've recently started
programming my Spybot with NQC and BricxCC. I would like to know how to send and
receive serial data from the RCX to a Sptbot and vice versa. 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.
|
|
|
In lugnet.robotics.spybotics, John Hansen wrote:
> In lugnet.robotics.spybotics, John Hansen wrote:
> > In lugnet.robotics.spybotics, Wolfgang Heinrich wrote:
> > > I'm not sure if this is a bug in NQC (or in the firmware ?!?) or if I do
> > > something wrong. Can anybody help?
> >
> > The code generated by NQC appears to be correct.
>
> Nope. NQC is definitely generating bad code. My apologies. I will fix it
> right away.
The Spybot LASM Opcode documentation for this opcode is just plain wrong. It
says that the command structure is 6 bytes. The first byte is the opcode 0xd5.
The second byte is the variable number. The third byte is the "find source"
(relation table sources 43-49). The fourth byte is the "find criteria" and it
says 0 is '>', 1 is '<', 2 is '=', and 3 is '<>'. The fifth byte is "find
threshold" source and the sixth byte is "find threshold" value.
If that is how this opcode really worked then the NQC code generation would be
correct. In reality, this opcode combines the fourth and fifth bytes together
and uses two bytes for the "find threshold" value. The fourth byte has 0x00 for
'>', 0x40 for '<', 0x80 for '=', and 0xc0 for '<>'. These values are logically
ANDed with the "find threshold" source value (which is less than 0x3f).
I can get it to work for constant or variable threshold values quite easily so
that will be my initial change. While you wait for a fixed API function you can
use this one instead:
__nolist void FindWorldFixed(int &v, const int relsrc, const int crit, const
int& thresh)
{
asm { 0xd5, $v : 0x3000001, 0x2a + relsrc, (crit * 0x40) + __type(thresh),
$thresh : __ASM_NO_TYPE };
}
John Hansen
P.S. a fixed NQC (3.1r2) is at http://bricxcc.sourceforge.net/swan_test.zip
|
|
|
In lugnet.robotics.spybotics, John Hansen wrote:
> In lugnet.robotics.spybotics, Wolfgang Heinrich wrote:
> > I'm not sure if this is a bug in NQC (or in the firmware ?!?) or if I do
> > something wrong. Can anybody help?
>
> The code generated by NQC appears to be correct.
Nope. NQC is definitely generating bad code. My apologies. I will fix it
right away.
John Hansen
|
|
|
In lugnet.robotics.spybotics, Wolfgang Heinrich wrote:
> I'm checking out the function FindWorld() [with BrixC and nqc version 3.1 a1
> (built Mar 8 2005, 07:33:11)] and run into problems. The call
> int t = -1;
> ClearWorld();
> FindWorld(t, SPY_RANGE, REL_GT, RANGE_NOWHERE);
> seems to work quite well. However if I try to restrict the conditions for
> finding items I get bad results.
>
> FindWorld(t, SPY_RANGE, REL_EQ, ... )
> finds no items. I tried it out with last parameter = RANGE_HERE, RANGE_THERE and
> RANGE_ANYWHERE. None of them worked.
>
> If I try
> FindWorld(t, SPY_RANGE, REL_GT, ... )
> then FindWorld always finds an item regardless of the last parameter. E.g.
> FindWorld(t, SPY_RANGE, REL_GT, RANGE_THERE)
> finds items in the THERE range, too.
>
> I'm not sure if this is a bug in NQC (or in the firmware ?!?) or if I do
> something wrong. Can anybody help?
The code generated by NQC appears to be correct. I've had reports over the
years from lots of people who have had great success with using the world
relation table information in the Spybot so I doubt that the firmware is buggy
in this respect (i.e., find world). Possibly you are calling FindWorld too
quickly after calling ClearWorld. ClearWorld will remove all entries from the
world relation table. FindWorld just returns the first entry in the table that
matches the specified criteria so if the table is empty then it would not find
anything. There are at least two very good examples of using the FindWorld API
function in NQC in the Lugnet Newsgroups.
http://news.lugnet.com/robotics/spybotics/?n=269
http://news.lugnet.com/robotics/spybotics/?n=367
Unfortunately, neither of these exercise the FindWorld function with values
other than REL_GT and RANGE_NOWHERE. I will try to run some tests myself to
verify whether other parameters work correctly.
John Hansen
|
|
|
I'm checking out the function FindWorld() [with BrixC and nqc version 3.1 a1
(built Mar 8 2005, 07:33:11)] and run into problems. The call
int t = -1;
ClearWorld();
FindWorld(t, SPY_RANGE, REL_GT, RANGE_NOWHERE);
seems to work quite well. However if I try to restrict the conditions for
finding items I get bad results.
FindWorld(t, SPY_RANGE, REL_EQ, ... )
finds no items. I tried it out with last parameter = RANGE_HERE, RANGE_THERE and
RANGE_ANYWHERE. None of them worked.
If I try
FindWorld(t, SPY_RANGE, REL_GT, ... )
then FindWorld always finds an item regardless of the last parameter. E.g.
FindWorld(t, SPY_RANGE, REL_GT, RANGE_THERE)
finds items in the THERE range, too.
I'm not sure if this is a bug in NQC (or in the firmware ?!?) or if I do
something wrong. Can anybody help?
|
|
|
In lugnet.robotics, John Hansen wrote:
> In lugnet.robotics, John Hansen wrote:
> > Recently I happened across the MindScript headers for the RCX in the SDK and saw
> > some interesting macros for RCX communication. I decided to port them to NQC
> > and possibly add them to the official built-in NQC API. I would be extremely
> > grateful if someone out there would be willing to try out some of the functions
>
>
> I forgot to include a few #defines:
>
> #define SERIAL_PACKET_RC 0 // default
> #define SERIAL_PACKET_SPYBOT 0
>
> #define SERIAL_COMM_RC 7 // 4800/76KHZ/25%
> #define SERIAL_COMM_SPYBOT 7 // was SERIAL_COMM_4800 + SERIAL_COMM_76KHZ
>
> The RC function, by the way, is essentially identical to the code posted a long
> time ago regarding how to communicate with the MANAS motor unit using NQC.
>
> I'm not sure whether the Spybot functions are working. For one thing, the
> previous Ping function (SendSpybotPing) is known to have worked in its original
> version but I was using a different value for SERIAL_COMM_SPYBOT (3 rather than
> 7). The MindScript macros definitely use 7 but it is not outside the realm of
> possibility that they are incorrect.
>
> I'm trying to sort it all out but if anyone else out there would like to help
> that would be great.
>
> John Hansen
John, I have a few beginner questions for you. I am trying to emulate the
infrared protocol on a different microcontroller. I want it to be able to be
controlled by a Lego remote and to send/receive messages to Lego devices. What
format does the Lego Remote protocol has? My microcontroller can do a standard
protocol like 8 bit command followed by 8 bit device. Is this close enough? The
device is the RCX, Spybot, Remote, etc. and the command is 01 to 99 or whatever
else? Is there a list of commands and device codes that I can use?
Thanks for your patience, the result of this study will be posted soon.
Gabriel
|
|
|
In lugnet.robotics.spybotics, Tim David wrote:
> In lugnet.robotics.spybotics, Don Heyse wrote:
> > I searched, but I can't seem to find the answer to this one.
> > But someone must have encountered it by now.
> >
> > I installed the lego spybotic software on an XP Home Edition PC.
> > Now it only works when logged in as the administrator. Try to run
> > it as anyone else and I get,
> >
> > "The Registry has been corrupted. You need to reinstall the program
> > so that settings may be restored."
> >
> > What's up with that? There must be a way to run this thing as a
> > normal user, right? Please help.
>
> I would guess that you need to change the permissions (when logged on
> as an admin) on the part of the registry that the spybotic software
> uses to allow all users change permissions. How you find out which
> bits are needed is a question of (A) searching, (B) trial and error!
Hey thanks. Permission bits, eh? Now why didn't I think of that?
Oh well, I gave it a shot last night with Full access for everyone
(I think), and no luck. I also checked the Spybotics directory
in Program Files and discovered a user.ini file that's updated every
time you run it. So I ran CACLS and gave everyone Full access
to that file. Still no luck.
I'm gonna forward this to the dear-lego group. Maybe there's an
official solution somewhere that I couldn't find.
Don
|
|
|
In lugnet.robotics.spybotics, Don Heyse wrote:
> I searched, but I can't seem to find the answer to this one.
> But someone must have encountered it by now.
>
> I installed the lego spybotic software on an XP Home Edition PC.
> Now it only works when logged in as the administrator. Try to run
> it as anyone else and I get,
>
> "The Registry has been corrupted. You need to reinstall the program
> so that settings may be restored."
>
> What's up with that? There must be a way to run this thing as a
> normal user, right? Please help.
>
> Thanks,
>
> Don
I would guess that you need to change the permissions (when logged on as an
admin) on the part of the registry that the spybotic software uses to allow all
users change permissions. How you find out which bits are needed is a question
of (A) searching, (B) trial and error!
tim
|
|
|
Hi all,
Thank you if you completed the survey about your chosen development environment.
Early results are as follows:
48% of respondents use NQC as their main language.
NQC scores 1.6 for usefulness, 1.5 for ease of use and 2.1 for enjoyment. (1 is
the best, 6 is the worst).
18% use Robolab
Robolab scores 2.2 for usefulness, 1.6 for ease of use and 1.5 for enjoyment.
18% use brickOS/C
6% use RCX-code
9% use Java
90% of respondents have been male. The average age of all respondents is 38.
No further analyses have been performed yet.
There is still time to complete the survey at:
http://www.nottingham.ac.uk/~liztc/RobotSurvey.html
Thank you,
Thomas
|
|
|
Hi,
I am very interested (for a variety of reasons) in which programming language
people are using to build robots. I wonder if you would fill in a questionnaire
about it at:
http://www.nottingham.ac.uk/~liztc/RobotSurvey.html
It's all about how useful, easy and enjoyable your chosen language is.
If anyone does, I will summarise the results on a web page and post up the URL.
Thank you
Thomas
|
|
|
I searched, but I can't seem to find the answer to this one.
But someone must have encountered it by now.
I installed the lego spybotic software on an XP Home Edition PC.
Now it only works when logged in as the administrator. Try to run
it as anyone else and I get,
"The Registry has been corrupted. You need to reinstall the program
so that settings may be restored."
What's up with that? There must be a way to run this thing as a
normal user, right? Please help.
Thanks,
Don
|
|
|