View unanswered posts | View active topics It is currently Wed Jun 19, 2019 12:55 am

 Page 1 of 2 [ 25 posts ] Go to page 1, 2  Next
 Print view Previous topic | Next topic
High level API for using one NXT to control another
Author Message
Rookie

Joined: Wed Jun 25, 2008 6:07 pm
Posts: 46
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
Guru

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Re: High level API for using one NXT to control another
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 )

_________________
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
Site Admin

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3654
Location: Rotterdam, The Netherlands
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
Site Admin

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

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
Guru

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
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
Site Admin

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3654
Location: Rotterdam, The Netherlands
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
Rookie

Joined: Wed Jun 25, 2008 6:07 pm
Posts: 46
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
Site Admin

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3654
Location: Rotterdam, The Netherlands
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
Rookie

Joined: Wed Jun 25, 2008 6:07 pm
Posts: 46
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
Guru

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Re: High level API for using one NXT to control another
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).

_________________
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
Site Admin

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3654
Location: Rotterdam, The Netherlands
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
Guru

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
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 ubyte02 2 single ubytes03 3 single ubytes...11 1 single byte12 2 single bytes13 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) requested31 sensor port 1 (S2) requested32 sensor port 2 (S3) requested33 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) requestedA1 motor encoder 1 (motorB) requestedA2 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
Site Admin

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3654
Location: Rotterdam, The Netherlands
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

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
Guru

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Re: High level API for using one NXT to control another
ok, it was just an idea, YOU are the specialist!

_________________
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
Site Admin

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

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
Display posts from previous:  Sort by
 Page 1 of 2 [ 25 posts ] Go to page 1, 2  Next

#### 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

Search for:
 Jump to:  Select a forum ------------------ ROBOTC Applications    ROBOTC for LEGO MINDSTORMS       Third-party sensors    ROBOTC for CORTEX & PIC    ROBOTC for VEX IQ    ROBOTC for Arduino    Robot Virtual Worlds    Multi-Robot Communications    Issues and Bugs Competitions & Partners    Mini Urban Challenge    CS2N Robot Virtual Worlds Competitions       VEX Skyrise Competition 2014-2015       VEX Toss Up 2013-2014       FTC Block Party! 2013-2014    Competitions using VEX - BEST, TSA, VEX, and RoboFest!    FTC Programming    RoboCup Junior and Other ROBOT Competitions Virtual Brick Robotics Discussions    General Discussions    Project Discussions Off-Topic ROBOTC Forum & ROBOTC.net Suggestions/Feedback    ROBOTC Forums Suggestions/Comments    ROBOTC.net Suggestions/Comments       NXT Programming: Tips for Beginning with ROBOTC       VEX Programming: Tips for Beginning with ROBOTC    2013 Robotics Summer Of Learning       VEX Toss Up Programming Challenge       FTC Ring It Up! Programming Challenge    International Forums       Spanish Forums          ROBOTC for MINDSTORMS          ROBOTC for VEX       French Forums          ROBOTC pour Mindstorms          ROBOTC pour IFI VEX       Japanese Forums （日本語のフォーラム）       German Forums    2015 Spring Carnival Event    PLTW (Project Lead The Way)    Robotics Merit Badge    2014 Robotics Academy Summer of Learning

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