Due to frequent requests made here on the forum, I've decided to take some time to create an API for using one NXT to control another.

I'll be using this area to outline my current and future plans for the project, as well as post updates, current code drops, etc.

Comments and questions are always welcome, but I will be using my own personal discretion to determine what things to work on and when. My time is not unlimited, and there are usually reasons for doing things in a particular order.

In particular, I'm going to focus on motor control first, followed by reading values from standard NXT sensors.

We'll see how things go from there.

I'm speechless.
And promise to keep speechless.

But I'll do what I can

EDIT:
Mightor! ,
would you like to join us? (he's really great in low (and high) level programming )

Yeah, this sounds like a great opportunity to make this work! I am looking to make a robot that uses two NXTs. Thanks for the compliment, btw

Xander

Helmut, now, now, don't go making promises you can't keep

Xander

@Xander:
yes, that will be very hard....
as I know that you're working on a RS485_API, and avidprogrammer is doing a similar job for a BT_API:

Do you think you'll get both by a similar syntax?
Like:
1 included RS485 HS header file like #include "RS485_API.h"
1 command for remote sensor polling: GetHSRemoteSensorValue(string nxtIDname, int sPort, int &sValue1)
1 command for remote motor control: SetHSRemoteMotor(string nxtIDname, int mPort, int speed [, int motTarget])
1 command for remote motor encoder polling: GetHSRemoteEncoderValue(string nxtIDname, int mPort, int &encValue)

and
1 included BT header file like #include "BT_API.h"
1 command for remote sensor polling: GetBTRemoteSensorValue(string nxtIDname, int sPort, int &sValue1)
1 command for remote motor control: SetBTRemoteMotor(string nxtIDname, int mPort, int speed [, int motTarget])
1 command for remote motor encoder polling: GetBTRemoteEncoderValue(string nxtIDname, int mPort, int &encValue)

I think it would be very good to have a consistent API for both means of NXT-to-NXT comms. I really like that idea.

Regards,
Xander

Yeah, I was thinking the same thing. Actually, I was thinking the best option would be to just pass in some sort of connection handle that would indicate whether you wanted the command to 1) go over RS485 or Bluetooth, and 2) which connected device should respond to the command.

One of the things that is a little awkward with that is the fact that bluetooth takes a long time to switch between receive mode and transmit mode. So, at least for bluetooth, we will probably also need a way to transmit multiple requests at a time so that they can be serviced together.

Also -- I was thinking I'd pretty much ignore any kind of peer-to-peer situation and just keep the entire scheme on a master/slave basis. It simplifies things quite a bit and I don't really see any reason for allowing peers to control each other's motors and sensors. Wost case, we could always provide a way for the peers to chat by proxying the data through the master.

One nice thing about keeping things set that way is that it helps get rid of contention problems. The master acts as a centralized controller, of sorts, and schedules who has access to the media.

I was planning to start fleshing a few things out later this weekend and possibly give Ford some teaser code that would at least let him see that I'm serious about this. But, Mightor, have you already started? I wasn't aware that you were already working on something like this for RS485. Have you actually started an implementation? Or were you just thinking about how to get things done?

(Edit) Also, Ford, just so you're aware of what to expect, I'm expecting that this will start with the slave being a dedicated slave. There will be a program to run on the slave and it will not allow you to do other computations. This will allow us to dedicate the slave entirely to monitoring incoming messages. We can re-evaluate that later on, but to get going, that's where I will start. Likewise, to begin there isn't going to be any way for the slave to 'interrupt' or send unrequested messages to the master.

Longer term, these may be possible. With sending unrequested data, though, I'd expect it will still need to work a bit like the USB protocol does -- the slave will raise a flag that the master checks periodically. The flag will indicate that data is available, but the master will then send an explicit request for the data. That way, the master is always in control.

I was only thinking about it Ford made it sound like I was practically done! The single API with a connection handle would be nice, but I think we have to start small. If we can agree on a list of functionality that we need implemented and a nice naming and argument order standard for the functions we can always merge the calls later. We could use the existing functions as a hidden lower layer that these new higher level functions will use. That will also give us greater independence when programming

Perhaps we could start a Google code repository and sync our code with svn or something? I already have a repo there but have no used it yet. If you have a Google account, I could very easily add you, I just have to figure out how! The nice thing about using something like svn is that in the unlikely event that your laptop/computer gets nuked, you'll still be able to retrieve your code

There is a wiki there as well where we can document our progress and APIs. There is no rush with this, though, remember we're doing this as a hobby (well, I am anyway).

It's here: http://code.google.com/p/robotc-drivers/ but right now there isn't a whole lot there yet.

The peer-to-peer part would only be possible to implement if we took the token-ring approach or something. For now I think we should stick with a simple solution and that's master-slave. The master relay part could be implemented at a later stage.

Regards,
Xander

I didn't mean that you have to be speechless. Mostly, I just wanted to point out that beggars can't be choosers. Also, a good thing to keep in mind for the future is that although it's the squeaky wheel that gets the grease, sometimes, the squeaky one just gets replaced.

Mightor:

That sounds like a great idea. I use code management repositories all the time.

I'm not in any hurry with this either. Like you, I just do this for fun. That's what I was trying to warn Ford about in my original posts

hi,
I'm glad to see that finally things are going on
BTW: I don't expect any user to do the devopers' job, and I don't want anybody to do this for me personally - it's a functionality just to everybody's benefit which still is missing.

Meanwhile there have been several threads where we've been thinking about the communication problems and data transfer protocols (Honolulu net, token ring, TCP/IP, data packages, mailbox queues). But did anybody try to check out how the BT mailbox system of NXT-G actually works?

For RS485 connection 1 extra pair of wires is missing for full duplex, so one has to switch continuously from "send" to "receive" mode and back.

The advantage of BT is that always 3 slaves may stay connected to the BT master at the same time, and BT can already work in a full duplex mode, that may reduce the disadvantages of lower speed at the first place (correct me if I'm wrong). Above this, you win one extra sensor port at each brick (plus the port splitter) which is really a great value. That was why I started to figure out aternatives of other programming languages using Bluetooth (e.g. also at nxtOSEK only BT is available, but no RS485 yet).

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. It's like Lego bricks. Lego makes the bricks, we make the models If we wanted pre-made stuff, we would've been playing with Playmobil, no? (can I say that word on an NXT board?)


The mail box system is quite limited. I believe there are at most 6 outstanding messages you can have. I would like to develop a messaging system but I'd like to optimise it for controlling and polling remote devices. There should be different message types, control and query. Control would be used to configure and setup sensors, control the speed of a motor, etc. Query messages would be used to read a motor's tacho or a remote sensor. We need to come up with a common packet format that could be used on either BT or RS485. We need to figure out whether we'll forgo ACKS and instead transmit a packet 4 times, like you do with IR. Lots of design decisions that need to be made.

If a master sends a query packet, it is easy to tell on the master if the slave got the message, it'll have sent a reply. However, if the slave sent a message and the master never got that response and the master resends the query, it is important for the slave to know that it is a retransmission of an older query packet. Hence the need for some kind of sequence numbering. In this case it would see that this is a retransmission and merely send the old reading back, rather than requery the sensor. This would only go on for 3-4 times before a message is deemed irrevocably lost.

Perhaps all command packets should be acknowledged much the same way.

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


Such is the nature of a simplex communication channel


I think the multi-slave setup is nice, but I have no way of testing that. I have just two NXTs and I am not sure I'll be getting a 3rd any time soon. I've just spent about 300 euro on various robot-related things and I doubt my wife would be too impressed if I went out and bought another set

Regards,
Xander

you're right! what we need is bricks, but what we already actually got are just plastic granulate, studs, shapes, and glue.
and yes, it's a free world, you can say "playmobil" without being shot: were not in China or Tibet! But I doubt that anybody at overseas knows what Playmobil really is, and that it's single parts also have to be connected to a whole



this was why I suggested a data package consisting of a header block and a data block. With this you can encode a message ID and anything else, e.g., also if it's a data request (query) or a data transmission:
(modified)


TBlock[7]= encoder types:


TBlock[4]= value types:


Using full duplex BT, you may have always 2 threads running on the master and on any slave, 1 for sending and 1 for receiving, simultaneously all the time.

And you may test your code even with just 2 bricks:

Write the code for 2 slaves, polling 2 different sensors at 2 different ports.
Test it first with the Brickname of the slave1, poll brickname1-port1.
then rename slave1 to the Brickname of slave2,
and then test it again: poll brickname2-port2.
Because you use different Bricknames, you should get different results.

And don't forget: Meanwhile I've got 3-4 nxt bricks, I can test your code if you can't.

Now now, it's not quite that dire


My goodness, I'd make it a lot smaller than that. That would take a while to transmit over BT, remember it's not that fast I am not sure we should bother encoding the data type in the package. Just raw payload. Let a higher level function figure out what to do with it. That would make the protocol a lot simpler, too. 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.

Keep the protocol simple, put the intelligence in the higher level functions. When you make a query for a specific item on the other side, you already know what you're expecting, ie a float, an int or whatever.

Regards,
Xander

ok, it was just an idea, YOU are the specialist!

Haha, hardly But I admire your faith in my abilities!

Xander