Dexter NXTBee (NXC)

[afanofosc]

Andy,

So, based on a brief perusal of this leJOS thread (http://lejos.sourceforge.net/forum/view ... f=7&t=3257) if I implemented a bitbus protocol in the enhanced NBC/NXC firmware (somehow) then all the problems with trying to use the half-duplex RS485 NXT hardware with no hardware flow control will be resolved?

Would you ever recommend trying to use RS485 on the NXT without some sort of layer like your bitbus leJOS code enforcing the half-duplex master/slave polling mechanism?

John Hansen

[gloomyandy]

Hi John/Doc,
Good questions! I think it depends on what you are trying to do with RS485. If you are simply using it to talk to a single device (i.e not in a bus based network), then certainly you could use something simpler, though you will still have to take care to avoid collisions. An obvious way to do this is to use a simple master/slave arrangement with the master polling the slave.

For the more general situation then I think something like BitBus or perhaps has Doc has suggested some other network like token ring or perhaps Aloha (http://en.wikipedia.org/wiki/ALOHAnet), is needed. BitBus is a relatively simple and well documented master slave protocol suitable for use in a bus based environment (it was designed to control groups of computer controlled systems in a manufacturing environment). One of the main advantages is that it was designed to operate over RS485 hardware. It does have some disadvantages to the more general case networks in that it is master/slave, but I suspect that for Lego based projects a master slave implementation may well be good enough. Remember that more general networks can relatively easily be built on top of a basic BitBus network by using the master to route packets between slaves. The key advantage of a BitBus master/slave protocol is that there will not be any collisions to worry about as the slaves will only respond when polled by the master which greatly simplifies things. Also I think that the Master/Slave model may well fit better with the current Lego message passing system which I think is essentially Master/Slave.

As to things like token ring I'm not really sure how you would implement this given the NXT hardware. In a classic token ring network each station would be connected to previous and next devices in the ring via separate interfaces, which is not really possible with an NXT. So in effect you would be implementing a token passing network over the RS485 bus, I'm sure this is possible though there may be some tricky issues with startup of the network as Doc has already mentioned. You may want to take a look at the various forms of the Aloha network which was designed to operate in an environment that has collisions that are not detected by any hardware. Note that in this sort of environment good software error detection is vital, hence the pointers to error detection mechanisms. My general point is that most of the issues that Doc mentions have already been addressed in existing network protocols many of which are well documented, and that rather than creating your own (which would no doubt be a lot of fun), you may want to consider using an existing system. Designing and debugging network protocols is a tricky process and you may not want to spend your time doing it.

All the best (and good luck!)

Andy

[HaWe]

routing packages between slaves is vital for a larger network, it's by far not always a master who has to send data to single slaves (or poll some), also slaves must be able to poll other slaves, direct-control remote I/Os, or actively send data to other slaves.
Not a big issue if you got 2 NXTs in your net, but what about 20 or 32 ?
And mailbox-msg queues are quite limited and short - too short for many different quickly incoming message strings.

So better than master-slave is peer-to-peer, no master who alone is able to poll and send.

Aloha is a very good idea, it has been discussed for NXT use already some years ago, IIRC it was one of the precursors of the TCP-IP protocol.

[mattallen37]

John, if you are considering implementing a higher level software protocol layer, it must be optional. I do a lot with RS485, and all my drivers are based on using raw bytes. All error detection is done in my SW, as is all other means of communication.

Doc, what's wrong with a master/slave setup? Couldn't the master act as the center hub, to poll the slaves and send necessary information to other slaves? Either that, or the slave that's responding could throw in a flag so that another slave knows to listen in, because some of the data is meant for it.

A token ring could work fine, but I would recommend master/slave instead, because it's much easier to control and deal with errors (such as an NXT going off line).

Typically in an NXT network, all NXTs are working together to complete a specific task (such as controlling a brick sorter with conveyor belts, arms, etc.). If one NXT fails, then the whole system must go into an error state until things get cleared up. It would be unnecessary to use a token ring, because all NXTs must be online all the time. In addition, it could take quite a while for them to all realize that they are in error mode, and it could also be hard to keep them is sync (so that things move along as fast and smoothly as possible).

The only situation I can think of for using a token ring, would be for something like swarm robots. Even then, I think I would still do master/slave.

I guess what I'm trying to say, is that every application is going to be different. There is no "one fits all" solution. If you need a specific network structure, I think it should be up to you to design and program it to work best with your application.

[HaWe]

it's a matter of data traffic.
let's call the NXTs: a,b,c,d,e,f,g,h,i,j.

NXT (a) might be either a master (for master-client) or just any client (for peer-to-peer).

for peer-to per:
b -> g request value of sensor1 of g
g -> b sends sensor 1 + checksum, request ack
b -> g sends ack (ok)


for master slave (a=master):
b -> a request value of sensor1 of g
a -> g request value of sensor1 of g
g -> a sends sensor 1 + checksum, request ack
a -> g sends ack (ok)
a -> b sends sensor 1 + checksum, request ack
b -> a sends ack (ok)

imagine, you have 20 NXTs and each request or data message has to run via master a instead directly to the addressee.
Now imagine, b wants sensor1 of g and sensor3 of c and sensor2 of h.
Now imagine, any ack or checksum failed.


Poor master.
Poor network performance.
Poor real time behavior.

If you need a specific network structure, I think it should be up to you to design and program it to work best with your application.

keep you advices of this kind for yourself. This is not about just this advice but all of that kind that fit.
I was just talking to John to plan the network structure, not to you.
If you want it different, why don't you make it different by yourself?

Again, Aloha is a very good idea.

[mattallen37]

But what if NXT(a) is the master, and it tells everyone what to do. Now NXT(b) doesn't need to know the value of sensor 1 on NXT(g). Instead, NXT(a) will read all necessary sensors, figure out what needs to happen, and send motor commands to the necessary motors.

It is especially when you have more like 20 NXTs that it would be much more efficient. Instead of each of them asking for sensor values from whatever other NXT, one NXT would act as a hub, with the fairly current sensor readings from all 20 NXTs, and also be able to send motor commands to all 20 NXTs.

The most efficient communication would be a communication protocol built around the structure of the application. By saying "If you need a specific network structure, I think it should be up to you to design and program it to work best with your application." I wasn't criticizing you, I was trying to imply that the best solution for your application is one that only you can design.

keep you advices of this kind for yourself. This is not about just this advice but all of that kind that fit.
I was just talking to John to plan the network structure, not to you.

If you only want advice from John, then why ask on a public forum?

If you want it different, why don't you make it different by yourself?

I am quite content with RS485 the way it is. Any software layers I need, I build. I'm not the one who is asking for a change.

[HaWe]

NXTs in a net may have own requests, they don't ask a master which requests or commands they might have or give and no master tells them what they are supposed to want.
my post was just a reply after gloomyandy's post concerning bitbus vs. TR vs. Aloha.

Better simply ignore my posts in future and move on.
If you don't need any enhancements, simply keep quiet.

[gloomyandy]

Hi Doc,
You probably also need to take into account collisions when comparing the two implementations, particularly in the case of a busy network. Any network that allows direct peer to peer communication in this way (and that runs on the current NXT hardware) will have to handle data collisions. As you increase the amount of peer to peer traffic and the number of nodes the chance of a collision increases. Exactly how likely a collision is will depend upon the mechanism that you use to handle retransmissions and the packet sizes in use, my understanding is that for pure Aloha the peak data rate is approx 19% of the available bus speed. However as the data rate approaches the capacity of the bus, the actual usable data rate will drop to virtually zero. The big advantage of a master/slave network is that there are no collisions and this network overload problem does not occur (however the master node itself may become a limiting factor). A peer to peer network may also suffer from unpredictable transmission delays due to the packet collisions, which may not be desirable in a real time system. The master/slave system although suffering from larger minimum delays (particularly in a lightly loaded network), will typically have a more predictable overall response time.

A token passing network can avoid some of the data collision issues, but in that case you will also need to factor in the cost of the token passing, and the associated delays of waiting for the token to be available to the various NXTs.

I'm not suggesting that a peer to peer network is not a good thing to aim for. It will certainly offer some flexibility over a master/slave setup. But this gain needs to be weighed against the extra complexity and the above issues.

One other thing you may wish to consider is that the real world speed of the network may be a lot less than the simple bus speeds may suggest. Here are some figures I measured some time ago using leJOS. In this case the RS485 bus is running at the Lego default 921600bps. Obviously your own implementation will probably be different but they should provide some ball park figures. The RS485 numbers are all obtained using the leJOS BitBus master/slave implementation:

First I measured the round trip time (or latency), using a simple program
to send a single byte and echo it back. The results are:
USB PC->NXT : 1.8ms
BT PC->NXT : 53.8ms
BT NXT->NXT : 46.6ms
RS485 NXT->NXT: 5.7ms

The second test increased the transmitted data size from 1 byte to 512
bytes with a single byte response. The table below shows the (average)
time taken for a single 512 byte packet with the resultant bandwidth in
brackets:
USB PC->NXT : 5.1ms (100KB/s)
BT PC->NXT : 67.3ms (7.6KB/s)
BT NXT->NXT : 132.4ms (3.9KB/s)
RS485 NXT->NXT: 22.0ms (23.4KB/s)

Finally I tested the transmission of a 512 byte data packet, but without
any form of acknowledgement (so the data was in effect streamed):
USB PC->NXT : 3.9ms (131KB/s)
BT PC->NXT : 26.7ms (19KB/s) this could be my case
BT NXT->NXT : 45.2ms (11.3KB/s)
RS485 NXT->NXT: 19.1ms (26.8KB/s)

As I said good luck with whatever you end up doing...
Andy

[HaWe]

yes, I know that I have to avoid data collisions, that's the main problem when having lots of members and only a half-duplex connection both for wired rs485 and probably also for nxtBees running through rs485.
And that's why I suggested a token ring where always only 1 "member" is allowed to send.
Passing a token is admittedly 1 additional message that has to be sent by the member which already has got the token and who has already finished sending all the rest.

My header is supposed to identify the kind of message and the kind of addressee and sender.
Also acknowledgements only may be sent if the relevant NXT is allowed to send (i.e, if he owns the token).
So when only 1 sends at 1 time and the rest listens - how can data collide?

Of course this special anti-collide mechanism is only valid for TR nets, I don't know how this will work in different architectures (Aloha, TCP/IP, or what ever). I don't insist saying that TR is the best choice of all, Aloha sounds really fine, too, and I admit that I don't know anything about the capabilities and limitations of the bitbus net.

But being able to send or poll sensor data, encoder data, send motor commands, direct commands, send or poll calculated values, and send messages of any kind from any network member to any other member is essential for larger nets (e.g., 20 NXTs connected by rs485 or nxtBees). I actually can't imagine that requiring a master in between all msg traffic between all other members could speed up the net performance - but if it should be that way, why not?

I personally don't ever use PC's for my net of autonomous NXTs, but for general requirements this would be nice to have (e.g. additionally connected to the net by by BT or USB ? Or how else?). But PC integration is not the highest priority.

[gloomyandy]

Hi Doc,
Yes I agree that using a TR setup will also avoid collisions. Aloha does not attempt to avoid them, rather it has a mechanism for dealing with them. One of the problems with a TR setup is that you will have the delays of waiting for the source NXT to receive the token, as the net gets larger this delay will increase (on average you will have to wait t*n/2 seconds where t is the time taken to send the token and n is the number of nodes in the net). In many ways a TR network is similar to having a master/slave setup, think of the token as being the poll action from the master. That would in fact be an alternative master/slave implementation in which the master did not take part in the transfer between peers, but rather gave the current NXT permission to send data to any other NXT in that "slot".

If you are interested in using a token passing bus system (which in effect is what you get with a token on the NXT style RS485 bus), you may want to take a look at ARCNET. Another possible alternative that uses an implicit token is Contention-Free Time Slots (CFTS), which is used in power line networks.

As to the data I presented I wasn't really suggesting any sort of involvement with a PC. I just wanted to present the performance data so you could all see how RS485 compares with the other connection options available on the NXT. As you can see for the leJOS implementation RS485 is faster than using Bluetooth but not that much faster for data transfers. The main advantage comes from having a much lower round trip time, and from allowing the use of more NXTs talking to each other.

Andy