April 30, 2005, 11:40 am
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
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
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
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
...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
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
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
- » Extending the antenna on the Isaac16 Robot Controller
- — Next thread in » General Robotics Forum
-

- » hobbiest robot demographics
- — Previous thread in » General Robotics Forum
-

- » evoMUSART 2013: First CFP (with correct dates)
- — Newest thread in » General Robotics Forum
-

- » Bending 1/8 inch thick 7075-T6 aluminum
- — The site's Newest Thread. Posted in » General Metalworking
-


Subject







