View unanswered posts | View active topics It is currently Fri Oct 31, 2014 2:20 am






Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
High level API for using one NXT to control another 
Author Message
Rookie

Joined: Wed Jun 25, 2008 6:07 pm
Posts: 46
Post Re: High level API for using one NXT to control another
mightor wrote:
I don't think this is a job for the developers, to be honest. They have provided us with all the tools necessary to make this possible. The basic RS485 and BT functionality is there, we just need to put it together.

I agree completely with Mightor. It's not the developers' job to implement everything that crosses our mind. Nor are they obligated to implement everything that is available in other languages.

mightor wrote:
The acks may give us overhead but that is the price of reliability.

I've given this quite a bit of thought, and, as much as I dislike ACKing every single bit of data, I think it's probably still the right thing to do. I'd hate to have to answer to someone after they couldn't get their motors to stop, for example, even though we sent the message four times.

That said, I still think we should try to provide ways to minimize the number of ACKs by batching requests. The way I see it, there could be a "StartBatch" function that you call before a series of commands. Once that has been called, all commands get queued until you call a "SendBatchedCommands" function. At that point, all the commands get sent together, with a single ack and potentially multiple responses coming together. That allows us to minimize the amount of switching between transmit/receives, which is time consuming on Bluetooth.

Of course, if you don't call the "StartBatch" routines, any command would be sent by itself with its own ACK. It's just an option to provide for the users (long term).

mightor wrote:
The message ID would not need to be bigger than a single byte. I doubt very much we'll have more than 255 outstanding messages. If we can make the payload variable by specifying the payload length in the package header, we can eliminate a lot of overhead, too. Packets would not be bigger than they strictly have to be.

I was thinking of using TLV (type-length-value) trios, which could include nesting. A command would consist of something like:

Type: 0x## -- Set Motor Speed
Length: 2
Value: 0x## 0x## (motor index and actual speed value)

A batch command would have one master outer TLV with the value containing a list of embedded TLVs that each get processed independently.


Sat Nov 08, 2008 2:34 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: High level API for using one NXT to control another
hi,
I don't think it's the right way to "bundle" commands.
You don't do that if you're controlling the motors and sensors at the local brick, and you shouldn't have to do it if you're doing the same at the remote brick.
Each port (local or remote) should be treated in the same way.

Imagine, you got a subsumption program cotrolling 10 sensors and 6 motors by 8 different tasks, each task has got his specific pattern of sensor events for his specific behavior.
So each task has to poll it's specific sensor(s) to check if to stay idle or become active and stop other tasks / behaviors.
1 task watches the emergency button (local S1)
1 task watches the 2 high range IR sensors and the US sensor at the front (SMuxer local S2 and S2 local daisy-chained)
1 task watches the 4 IR sensors at both sides (SMuxer local S2) and the rear US sensor (remote S1)
1 task watches the touch sensor in front (local S3) and 2 low range IR and 2 high range IR sensors in front/side (SMuxer local S2)
1 task watches the cam (or maybe an IR seeker) for object recognition and tracking (local S4)
1 task watches the 3 IR sensors for grabber control (SMuxer local S2) and 3 touch sensors for arm end/reset positions (remote S2, remote S3, remote S4)
1 task watches 2 moving motorencoders for odometrics (local motorA, motorB)
1 task controls 2 moving motors and 4 arm motors as the arbitrator task
1 function controls 2 moving motors for steering (local motorA, motorB)
1 function controls 4 arm motors for grabbing (local motorC, remote motorA, remote motorB, remote motorC)

Each task is running on his own, each needs the inputs of several different single sensors or sensor patterns, and every task polls it maybe every 15 msecs. in every time slice.

So that's why I think that every sensor polling and motor controlling action should be enabled as a unique event.

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Last edited by Ford Prefect on Sat Nov 08, 2008 7:34 am, edited 11 times in total.



Sat Nov 08, 2008 5:06 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Jan 31, 2007 3:39 am
Posts: 299
Location: San Diego, California. USA
Post Re: High level API for using one NXT to control another
Just FYI, the NXT can only handle 8 tasks.

Scott

_________________
Mmmm Legos B-)

My Robot Projects:
http://www.freewebs.com/robotprojects/


Sat Nov 08, 2008 5:08 am
Profile WWW
Rookie

Joined: Wed Jun 25, 2008 6:07 pm
Posts: 46
Post Re: High level API for using one NXT to control another
Ford Prefect wrote:
I don't think it's the right way to "bundle" commands.

Just to re-iterate what I said before:

AvidProgrammer wrote:
Of course, if you don't call the "StartBatch" routines, any command would be sent by itself with its own ACK. It's just an option to provide for the users (long term).

IE - If you don't want the feature, don't use it. It probably wouldn't be there for a while anyway.


Sat Nov 08, 2008 9:44 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: High level API for using one NXT to control another
aha, I didn't understand what that "ACK" should mean.

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Sat Nov 08, 2008 9:48 am
Profile
Rookie

Joined: Wed Jun 25, 2008 6:07 pm
Posts: 46
Post Re: High level API for using one NXT to control another
Ford,

It looks like Ogait87 now has some of what you're looking for. I'm going to put this on the back burner again unless you have strongly compelling reasons for why you're not planning to use what he already created:

viewtopic.php?f=1&t=697&start=105

Oh, and Ogait, well done. It looks like you're making some people very happy :-)


Sat Nov 08, 2008 1:32 pm
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: High level API for using one NXT to control another
hello,
unfortunately ogait's/docilio's program is not working and he seems not to be proceeding.
What about your project, will you try it again?

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Thu Jan 08, 2009 5:26 pm
Profile
Rookie
User avatar

Joined: Sun Jan 02, 2011 1:57 am
Posts: 31
Post Re: High level API for using one NXT to control another
Hey guys just ran across this forum and thought I might be able to throw an idea in

Maybe you could try using the Samantha module that FTC teams are using this year and use a wireless network that all the NXT's are connected to to delegate tasks to NXT's and then communicate back to the main computer and then delegate tasks again based on information recieved from the NXT's

Baisically this could possibly be done in a few ways. Easiest would be using something like the Field Control System that FTC uses to start matches, baisically using the waitForStart(); command to run a program chosen as the task on the NXT.

Having the robots communicate with each other may be slightly more difficult but the current FCS receives battery levels and program statuses from the NXT already so it is possible, what would need to be done would be to get these messages to be sent to another NXT.

Just my 2 cents!

_________________
Karan Hiremath
FTC Team 110- MFS Foxes
Co-Captain
Head Programmer
Builder
Electrical
Service Coordinator


Tue Jan 04, 2011 10:25 pm
Profile
Rookie

Joined: Thu Nov 10, 2011 4:27 am
Posts: 1
Post Re: High level API for using one NXT to control another
karan.hiremath wrote:
Hey guys just ran across this forum and thought I might be able to throw an idea in

Maybe you could try using the Samantha module that FTC teams are using this year and use a wireless network that all the NXT's are connected to to delegate tasks to NXT's and then communicate back to the main computer and then delegate tasks again based on information recieved from the NXT's

Baisically this could possibly be done in a few ways. Easiest would be using something like the Field Control System that FTC uses to start matches, baisically using the waitForStart(); command to run a program chosen as the task on the NXT.

Having the robots communicate with each other may be slightly more difficult but the current FCS receives battery levels and program statuses from the NXT already so it is possible, what would need to be done would be to get these messages to be sent to another NXT.

Just my 2 cents!

Don't know if that has already been discussed. Sorry for that. But i got troubles while using Samantha. "xxxxx requires phantom.dll"?


Last edited by JDarwein on Thu Jun 21, 2012 9:17 am, edited 2 times in total.



Thu Nov 10, 2011 4:35 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3227
Location: Rotterdam, The Netherlands
Post Re: High level API for using one NXT to control another
You need to install the NXT drivers which you can download here: [LINK].

- Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Thu Nov 10, 2011 4:49 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 25 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.