as far as price goes you have a lot more room to save on wireless than on a microcontroller, so I think any micro with a hardware serial port in conjuction with a cheap bluetooth module with serial port profile is a winner! I haven’t used the linked $10 bluetooth module but I intend to.
That’s what was frustrating me… SparkFun has had Smirfs for ages but they are always @ $40 to $50 a unit… seemed frustrating when the uC is less than half that price.
So now we are looking at :
115K Serial with no Servo contention, Computer->Robot with a BBB $16 + Cheap BT $10 = $36 a unit
Thanks for all the information CTC and advice. I have successfully avoided Xbees because of their price and voltage requirements. I am interested in swarming, but all the information will either be directed by the computer or routed from one robot through the computer to another robot…
Its encouraging you have had solid results with both, now to see if Rogues super cheap BT example is just as solid !
It says these modules have password 1234 … which is fine, but what about BT identifiers? Do they all come with unique IDs like ether MACs? or can the id’s be programmed?
Everyone gets their own mac address. I will do some tests but I am pretty sure they will just show up as different com ports and thus, eclipse or processing would simply run multiple serial lines. --one for each unit.
you typically can’t reprogram a bluetooth MAC address, but they should be different. on the other hand you can likely change the module name which shows up during a search, but that feature is module dependent.
I’ve found the bare Bluetooth modules are difficult to solder even with a microscope and surface mount soldering station, I really don’t like the half via pins they use. The four dollar premium for the presoldered breakout board is worth every penny to me.
in windows each bluetooth device with serial port profile will have a unique COM port associated with it. You can discover it by right clicking the bluetooth icon in the windows tray and clicking Show Bluetooth Devices, then right click the bluetooth device and click properties. Then by viewing the different tabs of the properties window it will show a COM port for the Bluetooth services offered for that device. Helpful when you have a swarm and you need to determine which device is communicating on which COM port.
By the fact that Windows (or other OS) understands them as seperate devices was the part I was concerned about. When I get the pieces together, I suspect that MRL will ask each uC who it is. That way regardless of how the OS identifies the BT/Com devices, MRL will identify with the uC’s response and bind them with the appropriate SerialService during runtime.
In the past I have seen com ports register differently depending on bootup, and many other variables.
But having the uC respond (as long as there IS a connection) would allow identification of the each uC consistently…
Good for when the bots have slightly different capabilities, e.g. IR sensor on bot #1 vs WiiDAR on bot #2 vs Servo gripper on bot #3…