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:

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

Ford Prefect

Guru

Joined: Sat Mar 01, 2008 12:52 pmPosts: 1030

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.

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:

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.

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.

Who is online

Users browsing this forum: No registered users and 1 guest

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