Bluetooth vs. WLAN to control biped

Translate This Thread From English to

Threaded View
In an effort to get rid of that silly wire between my bot and the PC, I
added a Bluetooth-to-RS232 module to my servo controller. WIth mixed results
though.

While the serial connection itself is great and pretty much guaranteed
(either on or off, but not losing a'a few bytes' on the way), the Windows
side of things drives me nuts! One data set to the controller is 34 bytes,
but the Windows driver tries to be efficient and waits until I fill a 100
some byte buffer before sending any data out.

So now in real life, the robot communication lags about half a second (until
the buffer is full), but then the controller get 5 different servo positions
at once. It's useless and makes the originally very smoothly moving robot
behave like a - um - B-movie robot.

So the alternative would be to use a WLAN-to-RS232, but will I get the same
problem with lag. Does anyone have any experience with those? Which one
should I get? I'd prefer raw solder-yourself modules over some clunky
plastic box.

Any other true alternatives? UHF?

Thanks for opinions,

 Matt



Re: Bluetooth vs. WLAN to control biped

This isn't unusual, and the buffer issue affects some other interfaces
as well, including a number of implementations of USB. One way around it
is to pad out the buffer with null (or otherwise "do nothing") bytes.
Have you tried this?

-- Gordon


News wrote:


Re: Bluetooth vs. WLAN to control biped



I'm also surprised that there is no way to turn this behavior off.

OP, did you try editing the driver settings? I know that, for instance,
you can tell a modem to turn off this type of wait/compress cycle. I did
this a long time ago to play Bolo on the internet with a 56k modem with
less lag.

--
|\/|  /|  |2  |<
mehaase(at)sas(dot)upenn(dot)edu

Re: Bluetooth vs. WLAN to control biped


At least for USB the 64-byte packet seems to be fairly standard. I'm not
sure if it's part of the USB protocol or just the FTDI chips that are so
popular.

In the case for the FTDI chips you can send data in 64-byte packets,
which probably means some empty bytes, which should be harmless; toggle
the DTR line (works with only some of their chips); or just wait for the
buffer to self-flush. They offer some nice data sheets on optimizing
latency and flow-control.

A sometimes visitor to the SD robotics user group, who also works for a
company that sells Bluetooth radios, demonstrated some "hive motion"
robots that appeared to have little or no trouble with latency or
buffers, so some of this may be product-specific.

http://robotics.fullthrottle.com/Articles/Buildingtheradio.html

One of their products, EmbeddedBlue, is designed to connect directly to
the Basic Stamp. Example code shows dealing with the buffer. (I have not
used these boards, but have seen them demonstrated.)

-- Gordon

Re: Bluetooth vs. WLAN to control biped

Ah, well, the controller on the receiver side does not like 'empty' bytes at
all. Toggeling the control lines btw was something I tried and it *does*
flush the bytes in the buffer out, but for some reason, flushing plus
setting a control pin plus clearing a control pin takes a fourth of a
second. I need to send data at 30 or better 50 commands per second though
:-/

Thanks much for the link.

Matthias



Re: Bluetooth vs. WLAN to control biped

I tried the usual COMM line stuff to flush buffers, set the output buffer
size, etc., but to no avail. I have not found any way to directly modify
Bluetooth driver settings in Windows XP. Any ideas?



Re: Bluetooth vs. WLAN to control biped

   Just an Idea...
   ...that using two or more transceiver pairs to throw data should be twice
(or more) as fast!
   Just use two (or more) seperate carrier frequencies.
-----------------------------------------------------------------------
Ashley Clarke
-------------------------------------------------------


Re: Bluetooth vs. WLAN to control biped


Ah, nice idea.

I still need to find out how to do changes to the BT side. The serial
connection looks just like a com port, and thre are no extra settings like
carrie frequency.



Re: Bluetooth vs. WLAN to control biped


Yes, I tried to pad. And while I am getting a nice regular tranmission of
blocks, I am wasting a lot of bandwidth on the receiver (RS232) side. But
worse, the controller expects data blocks with correct checksum and hickups
at 'do nothing' zeros by running out of sync. This at least will be solved
as soon as I get my own controllers soldered.



Re: Bluetooth vs. WLAN to control biped



     Latency on 802.11b/g systems sucks, too.

     In particular, avoid the Sveasoft Linux software for
Linksys wireless modems.  We have three of these units, and
have established with a packet sniffer that the units mangle
TCP packets.  Apparently, even when the "firewall" code is
supposedly turned off, it's still doing something, and when
there are more than two or three packets in flight, it
consistently mangles one of them, causing checksum errors.

                John Nagle
                Team Overbot

Re: Bluetooth vs. WLAN to control biped



Have your tried "FlushFileBuffers(...)" on the serial port file handle after
each write?


Re: Bluetooth vs. WLAN to control biped

Yes, I did. No change in behavior. The BT com emulation still waits until it
has eiter 64 bytes in the buffer, or a 30th of a second.

By building my own controller, I am now able to send 64 byte blocks, getting
30 data sets per second, working my way to the required 60 data sets.

Still, a little bit more controll over the BT side of the Com port would be
nice... .

Thanks,

 Matthias



Re: Bluetooth vs. WLAN to control biped



It sounds like you are bumping into an SO_RCVLOWAT or SO_SNDLOWAT issue with
the socket. I'm not familiar with your system, but if it is using sockets
to communicate, see if there is a way to set socket options on the system.

Alternatively, you may be seeing the "Nagle algorithm," in which case you
should look for a way to specify "TCP_NODELAY" on the socket.




Re: Bluetooth vs. WLAN to control biped


Ah, good hints. I have to check out the socket interfaface for BT soon as I
am running into all those restrictions. I use sockets for ethernet
connections, so it should not be too difficult to adapt as long as the
serial receive module understands me.

I am using the WIndows XP COMM port emulation:

CreateFile("//./COM15", ... etc.




Site Timeline