Tuesday, August 01, 2006

Theoretical BT Data Traffic control and solutions to its limits

This started out with the intention of being a comment tacked onto the ARTag article http://www.bnxt.com/blog/2006/07/art-augmented-reality-tagging.html
But ended up being a much more robust monologue that I really wanted to become a dialogue with its own comments section. It can get complex in places so I thought I might try to summarize at the beginning and let you venture in if you need more. Now I dont yet have my 2nd NXT. But even if I did this type of research would require more than 3 I think. I leave a few unanswered questions such as how long does a BT transmission burst take - so if you have the resources please comment and fill in blanks.

BT Mail Box Limits and solutions:
NXT Bluetooth Mail Box system is limited to 10 pieces of information. By using math you can further "tag" pieces of information by making them of a unique Size. For example if you want to use only 1 mailbox to recieve both direction and range information. You could set a variable switch which puts values of 1-360 into direction and values over 1000 send to Distance. The sending bot would have added 360 (optional if <360>Traffic Control:
BT can only transmit to or recieve from 1 source at a time. Transmitting continual streams of data (like fluctuating US returns) is thus only possible when 1 bot is giving and the other recieving. If more bots are involved they need to know how to wait (I am not sure if this is done in the firmware programming - send until recieve).
You can have them synchronize watches and communicate in assigned windows of time.
They can use "Shhh... and let me talk" comands to clear the airwaves.
Reduce the number of transmissions by having the sender decide if the value change is signifigant enough to warant an update.
Daisey Chain - Since only a few connections can be made their is a finite limit to how many NXT's an NXT can talk to. So if you tell each NXT to talk to only two others (bot 2 talks to 1&3) then they can use that daisey chain to pass along information from themselves and others. Since #1 is talking to #9 and #2 and #9 is talking to #8 etc data can be sent like passing notes. Notes could be set up to go to all bots awareness or just be passed along untill they reach the target.

Primary Discussion (fodder)
Now I've been chewing this over more, and if we can give the NXT native programing this information (I speak of the mailbox system).
Assuming your dont use an active query system (hard to program - the bot asks for what it thinks it needs from a netword of NXT's or a PC/PDA) and instead use a broadcast system (all the data you want or need is being updated as it changes). This mind you nesecitates a BT traffic control system. If your bots are generating continually changing values like light or US readings then they woudl continually broadcast those. But only one connection can be maintained. So you might need to either A) reduce sends by creating a "value changes by X amount" trigger, which then sends until a "I have recieved" signal is recieved.
B) if you can find out how long each data burst would last you could have one NXT give a timer signal comand (could even be a MAX sound that they all recieve simotaneously by you yelling or ringing a bell) so that Bot1 would be free to transmit in the first 1 second, bot 2 in the 2nd and on the n+1th second where n = # of bots the timers would reset and start the que line-up all over.C) Daisey chain. Bot 1 tells bot2 what bot 1 and bot 3 are up to. Bot 2 tells 3 what 1&2 are doing then 3 tells 1 what 2 & 3 are doing. That would need to be like a VHF/CB radio Recieve a "let me talk" and a "I'm done" signal (or another timer) but only 2 bots are involved. This is much more expandable than B) since B is limited by the number of connections. C) has only 2 connections per bot. Its 2 assigned buddies. But since the buddies are all different you get a kind of robotic game of telephone. Make sure they move slow because unlike the game telephone the info will be accurate but it could be a few seconds old.There could be other systems - Comment to add more

Now with 10 mail boxes you could have 10 pieces of information. So if you ID'ed slots (mail boxes) 1&2 to refer to Bot A then you could have heading and range info stored their. That means 5 bots could be tracked by any 1 NXT.BUT! if you multiply range values to some value that all readings will be above 360 then use a compare switch to grab the values and sort them out so that heading values which are within a known range will be placed into a variable suitcase (thus freeing up the mailbox) so that the next piece of incoming info could go towards the same mailbox. If its a range reading it will be an inflated value (maiking below 360 unlikely) and sorted by the switch into a seperate variable suitcase for that bots range info.
Thus with a little math and switching your number of reception data entries are only limited by the NXT's max program size and the speed at which it can recieve info.
You could even distinguish robots by going: (Value+n)x nxA where n is the desigation of the robot and A is the designation of the value. At really small Values the +n gives the nxA something to enlarge (which is what your variables will sense). Alternatively for huges amounts of data (which is really the only reason you'd use this) it might be easier to send a BT message preffacing the next message so that the BT is expecting a certain value to arrive and it can use a switching tree to determine what variable recieves the second data based on what the first message says. But then THIS requires that all bots wait for the 2nd message before trying to but in. Otherwise bot 1 might send "Heres Direction" and bot 3 might but in and insert "Range" into Bot1's direction variable.

Now all of this muck and bother is only really required by builders with MANY nxt's and probably only if your Swarming. An exception would be with an external Augmented Reality sensor which could provide HUGE amounts of Data.



At August 04, 2006 6:12 PM , Blogger Brian Davis said...

I've got to really read over and think about your monolog, but a couple of quick things deserve mention. This is based on my kowledge, and may be completely wrong... but it's the best I have to offer.

First, a NXT can not serve as both a master and slave BT device. Since a Master NXT can form connections with at most three other slave NXTs, this sharply limits how many units can form a network - to wit, four. Worse still, those three slave units have no (direct) connection to each other: if slave B wants to send a message to slave C, then they have to use the master NXT as an active relay.

Second, each connection has ten mailboxes, and these are completely independant of any other connections. So for instance master A can have three connections, one to slave B, (say, connection #1. And it can send any message, text, number, or boolean, to any of the ten mailboxes... call them B1 through B10), one to slave C (with mailbox "addresses" C1 through C10), and one to slave D (D1 through D10). For messages from the slaves to the master, these all come in on channel 0 (reserved for only incoming messages... note that the NXT-G block for receiving a message has no buttons for selecting which connection, while the "Send BT" block does).

Third, you can, if you want, pack many different numbers into a single BT message. The way you mention (less than 361 is a direction, so place it in one variable, while greater than, say, 1000, implies a power setting and put it in another variable) would certainly work. Another way to send both a direction and power at the same time would be to add them together after multiplying the power by 1000, for instance. Now a message of "10045" could be seperated with simple math into a power of 10 and a direction of 45.

BT messaging between NXTs is very nice... but it's (IMO) one of the more confusing aspects of the new system.

Brian Davis

At August 07, 2006 10:13 PM , Blogger Drew Stevenson said...

I think that each NXT can at any non-busy time send a message to any of its 3 potential buddies. Thus as long as you have a traffic control system to make sure your messages get through there should be no problem daisy chaining and sending a message until it has gone through a bunch of NXT's and reached its "coded" destination (ie add Nx1000 to the # so that N is the designator of the bot you want to recieve. Then each bot checks the number to see if that number is destined for it. If it is then it will not retransmit down the line and will remove the Nx1000 tag and use the number).

I did not know that each connection had 10 boxes. Good to know but still limited (if less so). I know there are a few users out there that might want 100 different types of Mailboxes for Swarm Data instead of the 30 or 40 currently available.

Yes the Talker says who will listen (repeated send blocks can allow for general or repeated broadcast to all 3 over a longer time frame.)

I think your math for the dual info number is not so "simple" unless the reciever already knows the power setting (then why bother). What if the power was 96 and angle 45. The number 96045 (you missed a 0 I think) would not be easily desectable using basic math. I can think of some complex switching and math blocking that might do it.

I loved your input.
I think the current BT system could be better (maybe will be) but I also know that in it is the key to great complexity in design pottential with multiple NXT's.

It is good to know that only the few over the edge swarmers will need more mailboxes. But I like to bring out these ideas.


Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home