Re: BT in robotics

At 08:14 PM 6/4/2005, Bruce Hopkins wrote:
> Bruce,
>
> 1.  TMobile does have a flat rate for data at $19 /mo

That's happened since we got our office contract. I'll check into it, 
thanks. If it's $19 for as much as you can stand to use, that's not so bad. 
We were paying $10-$20 for a couple of megabytes per month. But the phones 
are so slow I don't think we ever went over. I experimented with a couple 
of midlets and even deployed one from systronix.com just to prove it was 
possible, but the cell phone user interface is soooo klunky it was not an 
experience which inspired me to try more.

Many of the Tungsten PDAs have decent keyboards, and foldable external ones 
(I've used them for years), and also BT. The Tungsten screens are so 
excellent too; the Tungsten C screen is considered better than any current 
Windows CE PDA.

There's also a JVM or several (IBM J9 is supposed to work; I haven't tried 
it) for Tungsten. So if the JVM includes wireless support, it would seem 
that JSR-82 could be added to PDAs? Then you've got a much nicer, color, 
touchscreen UI for mobile robots. We were thinking of a PDA with a 
clippable Zigbee node (on the Tungstens with the 'universal connector'). We 
haven't had the resources (time, mostly) to do more along these lines.

> 2. Is there really interest anymore in RS-232 Bluetooth modules? I
> used to have a conact at BlueUnplugged.com and he was almost willing
> to give them away, because they weren't selling.

I know of some universities that have been using them in (groan) "BT 
connection" support even though there is no real BT use or programming 
involved, you just plug them in and send RS232 from one point to one other 
point.

> 4. Please note that the 7-connection limit is for ACTIVE connections.
> A Bluetooth device can easily cache 200 connections to 200 Bluetooth
> devices in the vicinity, but it can only use 7 of them at a time. So
> you can easily create a multhithreaded application to with a method
> named broadcast() that iterates though all the cached connections and
> send the message to all the nodes in the vicinity. When the message
> has been sent, then disconnect, since you don't need to connect to
> that node anymore.

It's interesting to know that this could be done, then. It still sounds 
klunky to me vs. a real broadcast where all nodes are listening and the 
one(s) affected can respond.

Suppose you have 20-30 BT nodes in a room. How do they power up and 
enumerate each other, if there is no existing cache?

My personal bias is to use only P2P networks with mobile robots since they 
will be moving in and out of range, and you can not rely on pre-assigned 
master.

> Now, to answer your question, each piconet has a master where all the
> nodes communicate. For nodes to communicate in a scatternet, then data
> needs to be routed from slave1 to master1 to master2 to slave2.
>
> 5. Hopefully, i'll be at JavaOne next year.

Well, hopefully by then we'll have a swingin' demo of a swarm with RF and JXTA.

Several of us from robotics communities will be at the JavaOne JXTA town 
hall meeting on June 26 and other JXTA events the following week.

We're also starting a new Java Robotics community at java.net. It's all 
approved and started and we hope to take it public with some active 
projects with working code, before JavaOne. (don't look for it there now 
since it isn't public yet - we're still building it)

> 6. I haven't played much with JXTA. In a nutshell what are the
> benefits? I've heard of JXME, but I never played with that either.

http://www.jxta.org/

JXME is the proxied version of JXTA ported to J2ME, for use with "less 
capable" nodes such as cell phones. If you are using IP or virtual IP as 
the transport layer then cell phones aren't P2P anyway - they have to go 
back to the cell tower, then get relayed to another phone, even if it is in 
your other hand.

Personally, the implementation of JXTA which appeals for use on robots is a 
non-proxied but slimmed down JXTA (if you do everything possible it gets 
big). JXTA is media layer agnostic and platform agnostic. At the lowest 
level, JXTA messages want to be basically packets of XML, so you have to 
have an XML parser running, and the data is also not compressed. JXTA 
messages can also be binary, which is better for low bandwidth channels, 
but worse for ease of debugging and "sniffing". A couple of years ago at 
JavaOne we demonstrated 900 MHz RF nodes running JXTA-like packets of XML 
controlling a robot arm, with another node as a sniffer with a touchscreen 
LCD. That was with Linx modems http://www.linxtechnologies.com/ where we 
had to write our own Manchester codec. We've since switched to Maxstream 
modems http://www.maxstream.net/ where all that is already done and the 
modems themselves are designed for P2P use. We have XML support for all our 
robots, since we use XML to "tag" each motor and sensor point so that one 
code base can run on all (non-identical) robots and self-configure at 
startup (that's the subject of TS-1464 later this month at JavaOne). But I 
digress.

The jxta.org website is where it's all at. Here are the highlights of "why 
JXTA"

Interoperability - across different peer-to-peer systems and communities
Platform independence - multiple/diverse languages, systems, and networks
Ubiquity - every device with a digital heartbeat
Find peers and resources on the network even across firewalls
Share files with anyone across the network
Create your own group of peers of devices across different networks
Communicate securely with peers across public networks

There is a new and very active proxy-less JXME, you can see the highlights 
here:
http://jxme.jxta.org/

> If the interest is out there, I can have probably have a RS-232 Java
> Bluetooth development kit available for under $200. I just need to
> check with my hardware partners.

A small (25x50 mm or so) pluggable module with onboard antenna, TTL serial 
I/O, and JSR-82 support would be ideal. You could plug it anywhere 
including one of our JSimm plugin boards. If such a module were available, 
we would do a BT JSimm board which would work with Java targets TStik 
(Dallas TINI) www.tstik.com, JStamp www.jstamp.com, JStik www.jstik.com, 
and the SNAP module from Imsys http://www.imsys.se/ as well as other 
SimmStick boards http://www.simmstick.com/

Regards

Bruce Boyes