View unanswered posts | View active topics It is currently Wed Aug 20, 2014 10:24 pm






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

Joined: Wed Jun 25, 2008 6:07 pm
Posts: 46
Post High level API for using one NXT to control another
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.


Thu Nov 06, 2008 5:49 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
I'm speechless.
And promise to keep speechless. :wink:

But I'll do what I can :D

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

_________________
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 Sun Nov 09, 2008 6:44 am, edited 1 time in total.



Thu Nov 06, 2008 6:17 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3188
Location: Rotterdam, The Netherlands
Post Re: High level API for using one NXT to control another
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

_________________
| 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]


Fri Nov 07, 2008 2:33 am
Profile WWW
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3188
Location: Rotterdam, The Netherlands
Post Re: High level API for using one NXT to control another
Ford Prefect wrote:
And promise to keep speechless. :wink:

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

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]


Fri Nov 07, 2008 3:50 am
Profile WWW
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
@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)

_________________
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 Fri Nov 07, 2008 8:37 am, edited 5 times in total.



Fri Nov 07, 2008 7:09 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3188
Location: Rotterdam, The Netherlands
Post Re: High level API for using one NXT to control another
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

_________________
| 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]


Fri Nov 07, 2008 7:11 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
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.


Last edited by AvidProgrammer on Fri Nov 07, 2008 10:00 am, edited 1 time in total.



Fri Nov 07, 2008 9:24 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3188
Location: Rotterdam, The Netherlands
Post Re: High level API for using one NXT to control another
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

_________________
| 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]


Fri Nov 07, 2008 9:43 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
FordPrefect wrote:
And promise to keep speechless.

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 :-)


Fri Nov 07, 2008 9:47 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'm glad to see that finally things are going on :P
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).

_________________
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)}


Fri Nov 07, 2008 10:42 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3188
Location: Rotterdam, The Netherlands
Post Re: High level API for using one NXT to control another
Ford Prefect wrote:
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.

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?)

Quote:
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?

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.

Quote:
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.

Such is the nature of a simplex communication channel :)

Quote:
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 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

_________________
| 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]


Fri Nov 07, 2008 11:50 am
Profile WWW
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
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. 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?)

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 ;)

Quote:
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.


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)
Code:
 
// transmission block: 24 bytes
// header block: 8 bytes
  TBlock[0] =0x00; // addressee: 00
  TBlock[1] =0x01; // own (sender) address 01
  TBlock[2] = ...  // free; maybe low byte of mesage ID or sth. else
  TBlock[3] = ...  // free; maybe hi byte  of mesage ID or how often repeated
  TBlock[4] =0x00; // value type: e.g. sensor port 0  (see below)
  TBlock[5] = ...  // in case of variable value:  low byte variable ID 
  TBlock[6] = ...  // in case of variable value:  hi byte variable ID   
  TBlock[7] =0x51;  // value encoded as 1* 16 byte integer  (see below)

// data block: 16 bytes
  TBlock[8] = 0x00;
  ... 
   TBlock[23]= 0x00;   


TBlock[7]= encoder types:
Quote:
01 1 single ubyte
02 2 single ubytes
03 3 single ubytes
...
11 1 single byte
12 2 single bytes
13 3 single bytes
...
42 2* 2 byte integer (short)
...
51 1* 4 byte Integer (long)
...
B1 1* 4 byte float
...



TBlock[4]= value types:
Quote:
00 sensor port 0 (S1)
01 sensor port 1 (S2)
02 sensor port 2 (S3)
03 sensor port 3 (S4)
... (space for more virtual ports of sensor multiplexers)
30 sensor port 0 (S1) requested
31 sensor port 1 (S2) requested
32 sensor port 2 (S3) requested
33 sensor port 3 (S4) requested
... (space for more virtual ports of sensor multiplexers)
70 motor encoder 0 (motorA)
71 motor encoder 1 (motorB)
72 motor encoder 2 (motorC)
... (space for more virtual ports of motor multiplexers)
A0 motor encoder 0 (motorA) requested
A1 motor encoder 1 (motorB) requested
A2 motor encoder 2 (motorC) requested
... (space for more virtual ports of motor multiplexers)
E0 variable value sent (number of variable specified in TBlock[5] + [6] )
E1 variable value requested (number of var specified in TBlock[5] + [6] )
...
FE error (general)
FF ok


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.

_________________
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 11:07 am, edited 2 times in total.



Fri Nov 07, 2008 12:13 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3188
Location: Rotterdam, The Netherlands
Post Re: High level API for using one NXT to control another
Ford Prefect wrote:
you're right! what we need is bricks, but what we already actually got are just plastic granulate, studs, shapes, and glue. ;)

Now now, it's not quite that dire :P

Quote:
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 (modified), e.g., also if it's a data request (query) or a data transmission:
Code:
 
// transmission block: 24 bytes
// header block: 8 bytes
..   
TBlock[23]= 0x00;   

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

_________________
| 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]


Fri Nov 07, 2008 12:34 pm
Profile WWW
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
ok, it was just an idea, YOU are the specialist! 8)

_________________
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)}


Fri Nov 07, 2008 12:40 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3188
Location: Rotterdam, The Netherlands
Post Re: High level API for using one NXT to control another
Ford Prefect wrote:
ok, it was just an idea, YOU are the specialist! 8)

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

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]


Fri Nov 07, 2008 12:41 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 25 posts ]  Go to page 1, 2  Next

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.