Best Bluetooth hardware for robots?

Hi…

what kind of Bluetooth hardware you would recommend?
I read the Posts in the Sticky above and I think there are a lot of different possibilities to connect the SSC-32 via Bluetooth with a PC.

At first, I´m quit new in this business, this is also my first post here, and my english knowledge is not the best, so please excuse my english.

But what I got is, that you can have different operating distances by using different hardware.

So it would be great if you can giv me a hint which Configuration (Receiver, Transmitter / USB Dongle, Antenna, etc.) will have the best results concerning range and suitability.

thanks a lot…

PS:
I don´t know if this information is importend, but the robot I want to control is a hexapod 3DOF (18 Servos)

I have only tried one Bluetooth configuration with my hardware, but it worked on the first try, and continues to work very well, with no problems at all:

Computer side:]MSI Star Key USB Bluetooth dongle (V. 2.22)/:m]
Robot side:]Sparkfun Blue SMiRF (RP-SMA version)/:m]]RP-SMA antenna/:m]]Lynxmotion SSC-32/:m]
The Bluetooth dongle/Blue-SMiRF combination works almost seamlessly, to provide a transparent serial link between the programs and the SSC-32. Only one extra step is required - double-clicking on the virtual COM port icon to establish the link.

Hi Seamus,

which OS are you using on PC side?
I want to use Linux for that …

another question, did you ever test the maximum range for that connection?

PS:
The hexapod is not build yet, but in my mind for a qiut long time :wink:

My PC is running XP, but I imagine that any driver that provides for a virtual COM port through Bluetooth would work just as well.

did you ever test the maximum range for that connection?

No, but both the dongle and the BlueSMiRF are supposed to be Class 1 devices. The limiting factor would obviously be the chip antenna in the dongle, but I have plans to address that one of these days. :wink:

Edit to add: Keep in mind that this is Bluetooth. It isn’t supposed to be a long-distance link, anyway - Bluetooth was designed around the idea of a “personal area network” for data transfer between devices on or around your person, or maybe between you and a friend a few feet away. Keeping this in mind, I consider anything beyond 20 feet or so to be “out of spec” anyway, even for communications between two class 1 devices. If I want to control something over greater distances than that, I would look first to other, more powerful means of communication.

yes, I even thought about using a Wifi connection but until now I don´t have a clue how to send rs232 commands via wifi or how to connect a wifi card with the robot without packing a hole PC on its shoulders… :frowning:

but actually, I don´t think that the distance will exceed maybe 10 or 20 meter. I hope that will work also with a bluetooth connection and if not, it´s even better than using a cable…

Mit freundlichen Grüßen
Alex

We got better than 16 meters from our testing.

Robot-Explorer_Germany,

I am presently using the A7 Engineering eb500 with my PC and the eb501 with my robot.

Can get about 300 feet or more line of sight when using a good 1/4 wave antenna with the eb500.

Take a look at this link: a7eng.com/index.htm

Regards,
TCIII

Ok thanks a lot for your help, I think I will try out the SMiRF thing with the built in ceramic antenna…

thanks…

I have an a7eng eb501 board for my SSC-32, the distance looked good to me. I also have a XBEE Pro kit that I really want to use because it can do over a 1\4 mile.

The blue smirf dongle is only outputting the power of a class 2 device.

I tried out a lot of different wireless communication methods with my bot, including bluetooth. I found bluetooth’s speed to be inadequete for quick/constant position updates. If you have a processor of some sort on board that you are just trying to link to a PC, then it might work out great.

But if you’re trying to stream data to something like an SSC32 over a serial connection, you’ll pretty quickly run up against the speed limits.

Another issue with bluetooth is the nonconfigurable auto-error correction. While this is usually a feature, it becomes a bug when retransmits are stubborn about delivering stale data, futher delaying the current.

If the bot end of it is a serial port, then there are some further things that deserve consideration in terms of speed. Bluetooth is a packet based network. Serial ports are streams. So Bluetooth is going to want to create buffers of the data coming and going through the serial port so that it can segment it into packets for transmission. Doing this means buffering and sending on two conditions. First, a full buffer, second a timeout. This timeout I believe is not defined in the bluetooth spec and will be hardware specific (hopefully software configurable). I used one bluetooth device that created a third option, packet termination characters. You’d send the data you wanted, then tack on a couple characters it would be watching for to close the packet prior to the timeout. Another option is to discover and carefully keep track of the packet size. Always make sure that you fill the buffer when you want it sent. This is dangerous though in case you and the packet scheduler get out of sync.

Be careful when evaluating wireless serial port replacement devices. These will tell you what port frequencies they can handle, but just because it can communicate locally at 115.2K doesn’t mean it can saturate it with data over the network. There are buffers involved which it can fill/dump at that speed through the port. That says nothing of the over the air transmission speed.

What I settled on eventually was a WiPort. It comes very close to saturating a 115.2K serial port. On the PC side, I was able to deal with it as a real packet based network instead of deailing with a serial port simulation layer, on the bot side the packet stuffing problem remains, though as I recall they had a configurable timeout which helps. While the WiPort and it’s friends are more expensive, it’s a whole lot cheaper than starting with crappy/inadequete radio and working through 5 others before eventually buying a WiPort. :wink:

Of course, if you have a controller of some sort running on the bot that you are simply sending small/infrequent commands to, you don’t have to worry about speed and can focus on other important details like power consumption and range.

Hi all,

For an example of bluetooth communication with a BOEBOT using an A7 Engineering eb500 and a MSRS controlled bluetooth dongle on a PC, take a look at the attached BS2 code.

Regards,
TCIII

’ ----- Title ]--------------------------------------------------------------
’ File: BoeBotControlForMsrs.bs2

[code]’ {$STAMP BS2}
’ {$PBASIC 2.5}

’ ----- DATA ]---------------------------------------------------------------

ResetOnOff DATA 0 ’ On/off toggle w/ Reset button
RequestConnect DATA $FF, 0, 1, 0, 0
ConnectionGranted DATA $FF, 0, 2, 0, 0
RequestCommand DATA $FF, 0, 3, 0, 0
ServoSpeeds DATA $FF, 0, 4, 0, 0

’ ----- Variables ]----------------------------------------------------------

tLeft VAR Word ’ Servo control pulse durations
tRight VAR Word

temp VAR Word ’ Temp variable

’ Buffer array not declared as buffer VAR Word(5) for SERIN functionality.
’ It can still be accessed as buffer(0), buffer(1), etc. However,
’ buffer0, buffer1, etc. should be used in SERIN commands with variations
’ of WAIT.
buffer0 VAR Byte ’ Buffer - Start char = $ff
buffer1 VAR Byte ’ Message Index value
buffer2 VAR Byte ’ Command
buffer3 VAR Byte ’ Argument 1 (return data 1)
buffer4 VAR Byte ’ Argument 2 (return data 2)
buffer VAR buffer0 ’ For standard array indexing

duration VAR Byte ’ 50ths of ms duration
frequency VAR Byte ’ 50ths of frequency
pointer VAR Byte ’ EEPROM pointer
msgIndex VAR Byte ’ EEPROM message index

routine VAR Nib ’ Routine selector
counter VAR Nib
index VAR Nib

flagWhiskers VAR Bit ’ Act on Whisker values
flagDigSens VAR Bit ’ Send back digital sensors 1/0s
’ with every reply
flagIr VAR Bit ’
tempBit VAR Bit

’ ----- Initialization ]-----------------------------------------------------

’ This code makes it possible to toggle the Boe-Bot on/off by pressing and
’ releasing the Board of Education’s Reset button.

Program_Start:

’ For on/off toggle with Reset
’ READ ResetOnOff, temp
’ temp = temp + 1
’ WRITE ResetOnOff, temp
’ IF temp.BIT0 = 0 THEN
’ FREQOUT 4, 1000, 2000 - Indicate inactive
’ END
’ ENDIF

HIGH 15
FREQOUT 4, 75, 4500
LOW 15

Reset:

DEBUG CLS

'Wait for the eb500 radio to be ready.
PAUSE 1000

'Wait for the EB500 Bluetooth connection to be established.
DO UNTIL IN5 = 1: LOOP

GOSUB Ram_Clear

Request_Connect:
pointer = RequestConnect
GOSUB Get_Packet
SEROUT 1, 84, [STR buffer \5]

Confirm_Connect:
pointer = ConnectionGranted
GOSUB Get_Packet
Wait_For_Confirm:
SEROUT 1, 84, [255, 0, 1, 0, 0]
SERIN 0, 84, 20, Wait_For_Confirm, [WAITSTR buffer \ 2,
buffer2, buffer3,
buffer4]
Request_Packet:
msgIndex = msgIndex + 1
pointer = RequestCommand
GOSUB Get_Packet
SEROUT 1, 84, [STR buffer \5]

’ ----- Main Routine ]-------------------------------------------------------

DO
Resume: ’ If Message not rcvd, try again
IF IN5 = 0 THEN Reset ’ EB500 disconnected?

PULSOUT 13, tLeft ’ Servo control pulses
PULSOUT 12, tRight

SERIN 0, 84, 5, Resume, ’ Get next command
[WAITSTR buffer \ 2, buffer2,
buffer3, buffer4]

PULSOUT 13, tLeft ’ Servo control pulses again
PULSOUT 12, tRight

IF buffer2 = 192 THEN ’ Handle restart req from PC
msgIndex = 0
GOTO Request_Connect
ENDIF

LOOKDOWN buffer2,[32, 33,
64, 65,
96, 97, 98,
128, 129, 130,
160, 161, 162], routine

ON routine GOSUB Set_Servo_Speed, Maneuver,
Get_Ir, Get_Whiskers,
Speaker_Tone, Set_Pins, Delay,
Enable_Digital_Sensors, Enable_Ir, Enable_Whiskers,
Disable_Digital_Sensors, Disable_Ir, Disable_Whiskers

’ Load digital sensor values into buffer byte 3 for return message.
IF flagDigSens = 1 THEN GOSUB Digital_Sensors

’ Increment message index for reply. Next message from PC has to use
’ reply’s buf[1].
msgIndex = msgIndex + 1
buffer1 = msgIndex
SEROUT 1, 84, [STR buffer \5]

LOOP

’ ----- Subroutine Digital_Sensors ]-----------------------------------------

’ This subroutine is used by the main routine to return digital sensor values
’ with each reply.

Digital_Sensors:

buffer3 = 0
GOSUB Get_Ir
GOSUB Get_Whiskers

IF ((buffer3.BIT2 = 0 OR buffer3.BIT3 = 0) AND (flagWhiskers = 1)) THEN
tLeft = tLeft MAX 750
tRight = tRight MIN 750
ENDIF

RETURN

’ ----- Subroutine Set_Servo_Speed ]-----------------------------------------

’ Range of 0 to 200 with 100 = stopped maps to 650 to 850 with 750 stopped.

Set_Servo_Speed:

tLeft = buffer3 + 650 ’ Decode servo speed.
tRight = buffer4 + 650

RETURN

’ ----- Subroutine Speaker_Tone ]--------------------------------------------

Speaker_Tone:

duration = buffer3 ’ Decode speaker tone
frequency = buffer4
FREQOUT 4, duration * 50, frequency * 50 ’ Transmit tone

RETURN ’ Go to resume routine

’ ----- Subroutine Get_Ir ]--------------------------------------------------

’ IR object detection for buf[3] bits 1 (left) and 0 (right).

Get_Ir:

’ IF flagIr THEN

FREQOUT 9, 1, 38500                        ' IR headlight
tempBit = IN10                             ' IR receiver
buffer3.BIT1 = tempBit                     ' Left IR reply bit
FREQOUT 3, 1, 38500
tempBit = IN2
buffer3.BIT0 = tempBit

’ ENDIF

RETURN

’ ----- Subroutine Get_Packet ]----------------------------------------------

’ Loads packet into buffer for transmitting. Used by initialization.

Get_Packet:

FOR index = 0 TO 4
READ pointer + index, buffer(index)
NEXT

buffer(1) = msgIndex

RETURN

’ ----- Subroutine Display_Command ]-----------------------------------------

’ For debugging.

Display_Command:

’ FOR index = 0 TO 4
’ DEBUG DEC buffer(index), CR
’ NEXT

RETURN

’ ----- Subroutine - Check_Whiskers ]----------------------------------------

’ Stores left and right wiskers (contact switches) for buf[3] bit 3 (left) and
’ 2 (right).

Get_Whiskers:

'IF FlagWhiskers THEN

buffer3.BIT3 = IN7                         ' Left whisker
buffer3.BIT2 = IN8                         ' Right whisker

'ENDIF

RETURN

’ ----- Subroutine - Set_Pins ]----------------------------------------------

’ Sets up to two pins. buf[3] high nibble specifies the operation, and the
’ low nibble specifies the pin. The same applies to buf[4].

’ High nibble:
’ 0 - no action
’ 1 - set to output
’ 2 - set to input
’ 3 - set to (output-high)
’ 4 - set to (output-low)
’ Low Nibble:
’ 0 to 15 - Specifies I/O pin.
’ DO NOT try to set 0, 1, 5, or 6.

Set_Pins:

temp.NIB1 = buffer3.HIGHNIB
temp.NIB0 = buffer3.LOWNIB
GOSUB Op_Pins

temp.NIB1 = buffer4.HIGHNIB
temp.NIB0 = buffer4.LOWNIB
GOSUB Op_Pins

RETURN

Op_pins:

SELECT temp.NIB1
CASE 1
OUTPUT temp.NIB0
CASE 2
INPUT temp.NIB0
CASE 3
HIGH temp.NIB0
CASE 4
LOW temp.NIB0
ENDSELECT

RETURN

’ ----- Subroutine - Delay ]-------------------------------------------------

’ Specify delay in ms.

Delay:

temp.LOWBYTE = buffer3
temp.HIGHBYTE = buffer4
PAUSE temp

RETURN

’ ----- Subroutine - Enable_Digital_Sensors ]--------------------------------

’ Causes program to put digital sensor values in buf[3] of the reply packet.

Enable_Digital_Sensors:

FlagDigSens = 1

RETURN

’ ----- Subroutine - Disable_Digital_Sensors ]------------------------------

’ Causes program to put digital sensor values in buf[3] of the reply packet.

Disable_Digital_Sensors:

FlagDigSens = 0

RETURN

’ ----- Subroutine Enable_Whiskers ]-----------------------------------------

’ Causes program to stop the Boe-Bot if Whisker contact is sensed. This gives
’ the PC bluetooth system time to reply.

Enable_Whiskers:

flagWhiskers = 1

RETURN

’ ----- Subroutine Disable_Whiskers ]----------------------------------------

’ Causes program to ignore the whisker contact. Also ignores when they are
’ not connected.

Disable_Whiskers:

flagWhiskers = 0

RETURN

’ ----- Subroutine Enable_Ir ]-----------------------------------------------

’ Not implemented.

Enable_Ir:

flagIr = 1

RETURN

’ ----- Subroutine Enable_Whiskers ]-----------------------------------------

’ Not implemented.

Disable_Ir:

flagIr = 0

RETURN

’ ----- Subroutine - Maneuver ]----------------------------------------------

’ Preprogrammed maneuver example. Current setup allows:
’ “U” - Back up then U-turn
’ “R” - Back up then right turn
’ “L” - Back up then left turn

Maneuver:

FOR temp = 0 TO 35
PULSOUT 13, 650
PULSOUT 12, 850
PAUSE 20
NEXT

SELECT buffer3
CASE “U”
FOR temp = 0 TO 40
PULSOUT 13, 650
PULSOUT 12, 650
PAUSE 20
NEXT
CASE “R”
FOR temp = 0 TO 20
PULSOUT 13, 850
PULSOUT 12, 850
PAUSE 20
NEXT
CASE “L”
FOR temp = 0 TO 20
PULSOUT 13, 650
PULSOUT 12, 650
PAUSE 20
NEXT
ENDSELECT

RETURN

’ ----- Subroutine Ram_Clear ]-----------------------------------------------

’ Clears ram for reset from PC. This prevents retaining the msgIndex and
’ pulseLeft/right variable values, which would otherwise cause problems.

Ram_Clear:

W0 = 0
W1 = 0
W2 = 0
W3 = 0
W4 = 0
W5 = 0
W6 = 0
W7 = 0
W8 = 0
W9 = 0
W10 = 0
W11 = 0
W12 = 0

RETURN[/code]

@ andylippitt

so you think that I can run into a lot of trouble when I use a bluetooth connection?

What I want to do is to control the hexapod with a PC completely.
On the hexapod should be only the SSC-32 and the powersupply (and the wireless bluetooth connection)

to be honest, I am a bit frustrated now :imp:

I thought I can write a control program in C on my Linux PC and send the commands easily via bluetooth to the hexapod and that´s it. At the beginning that sounds very simple to me but now …

Is there anybody who is doing it like this already?
Or do you all use a Micro controller with the SSC32 and just sending the direction commands via bluetooth to the micro controller ???

My setup is very similar to what your headed towards. There are no decisions made onboard. If the net connection goes down, the bot freezes at whatever it’s last commanded posture is.

In my setup, I have two way data. I’m reading the pots of the servos and sending actual position and current sense data back to the PC. The PC sends 18 2 byte position values. Both sets of data are exchanged every 20ms.

My bot side is not a SSC32, rather a series of PICs which handle the communication and also functions as the servo pulse drivers.

With the SSC32, its interface isn’t designed for over the wire efficiency. For instance, my protocol is much more specialized for the application, assuming lots of knowledge. The 18 2-byte positions are sent in a block of 36 bytes rather than a series of 18 comparably verbose SSC32 commands. It’s been a while since I’ve looked at the SSC32 docs, but you’ll want to be particularly wary of calling anything which has output. For instance if you were trying to read the previously commanded positions back from the SSC32, and you can’t do it in a batch, then you’d be looping through your servos, generating 2 way traffic across the packet network. You want to reduce the number of round trips you make as much as possible. For this to work, your goal should be 1 wireless packet from the PC to the bot every 20ms frame.

If you have the setup for PIC or Atmel programming, I’d strongly suggest putting a uC between your radio and the SSC32 so that you can layer your own protocol on top of the SSC32. Another option is that the SSC32’s firmware is open source. You can modify its command interface and reflash it directly. Yet another option would be that some of the radios will have a micro in them whose firmware you can modify. For instance the Lantronix WiPort is customizable via a free SDK they release called the CPK. I think there are versions of this for both the WiPort as well as that new one they are talking about in another thread. You could embed your protocol translation in there as well.

On the suitability of Bluetooth for this rather speed intensive application… in theory, the bluetooth serial profile is capable of much faster than is required. I was not able to get the required performance out of the hardware I used. YMMV.

I do know that the WiPort with a custom over the air protocol solves your problem with speed to spare.