Need Help regarding BlueSmirf and RCB3.
by shsan
Sun Mar 11, 2007 3:35 am
After more than 2 weeks, I have finally taken the time to try it again.
Solder all the part as you described PaulP and it was still not working
Until I realized that it might be my code.
And ahaha, I had forgotten to switch the UART of the BlueSmirf to 115Kbps..
Add that try again and oh miracle it's working...
Well almost, I have way too many errors for it to be usefull.
I don't really know where it's coming from. It could be the quality of my assembly.
Anyway, I am going to use the BlueSmirf for the Bioloid instead.
Here in Japan, it seems people have been using a module From BestTechnology which does not required inverting but I have not been able to find the reference of the module itself.
Solder all the part as you described PaulP and it was still not working
Until I realized that it might be my code.
And ahaha, I had forgotten to switch the UART of the BlueSmirf to 115Kbps..
Add that try again and oh miracle it's working...
Well almost, I have way too many errors for it to be usefull.
I don't really know where it's coming from. It could be the quality of my assembly.
Anyway, I am going to use the BlueSmirf for the Bioloid instead.
Here in Japan, it seems people have been using a module From BestTechnology which does not required inverting but I have not been able to find the reference of the module itself.
BlueSmirf
by ryann2k1
Sun Mar 11, 2007 8:16 am
PaulP wrote:To test and build I ran originally from a variable power supply, initially at 5V then wound it up to 10.8V to prove the regulator. Now its running off the KHR-1HV internal battery.
The jumper was open circuit on my board when it arrived so I put the Link in. If you are sure its made on your board then the external link isnt necessary..
Hi,
Thank you for the pdf file and your explanation. Now I manage to turn on and off my robot via Bluetooth, but once I tried to run several motions consecutively, my robot could not move at all. I have set my laptop port speed up to 115200 bps. In your case, does it work well?
Thank you.
Cheers,
ryann2k1
Re: BlueSmirf
by heke
Mon Mar 12, 2007 8:21 am
If I understood correctly, bluetooth does not work with H2H and KHR because bluetooth uses packet transmission which has too big latency and the robot has very tight time slots ? And we can not adjust the timings of the receiver.
by shsan
Mon Mar 12, 2007 8:48 am
BlueTooth does not work with H2H because most of the bluetooth module will need some data to be sent to configure it in the proper mode before using it.
As for being a packet transmission, I don't know. If that was the issue then it would never work I think.
However I see that some of my commands are executed properly (getting the version number, listing motions/scenarios). And sometimes the same command executed twice will not work (listing motion/scenarios).
So it's not clear to me that the BlueTooth protocol is directly in question here.
It might be that I have not exactly the same component as PaulP and that it is causing an issue.
As for being a packet transmission, I don't know. If that was the issue then it would never work I think.
However I see that some of my commands are executed properly (getting the version number, listing motions/scenarios). And sometimes the same command executed twice will not work (listing motion/scenarios).
So it's not clear to me that the BlueTooth protocol is directly in question here.
It might be that I have not exactly the same component as PaulP and that it is causing an issue.
by Ray
Mon Mar 12, 2007 1:18 pm
Apart from the inversion necessary as in my case of using the XBee module, I found another reason, (may be), all the wireless tools we used are half-dulpex (something like a walkie Talkie)l.
** Edit: Tx & Rx use the SAME Antenna
In my case, the XBee need to received all the data (or max. buffer size) before it send data. There is a gap in between. Data will be lost if the buffer size is not enough or the other side speaking too lengthly!
I try to adjust the max. buffer that will trigger the transmission. It make better result, but I still get errors.
Some foolish idea are making use of 2 pairs of wireless transmitter & receiver with 2 band of frequencies. I think it may solve the time gap.
But it make too many things together! and costy.
(Thanks to shsan trying the inversion)
Raymond
** Edit: Tx & Rx use the SAME Antenna
In my case, the XBee need to received all the data (or max. buffer size) before it send data. There is a gap in between. Data will be lost if the buffer size is not enough or the other side speaking too lengthly!
I try to adjust the max. buffer that will trigger the transmission. It make better result, but I still get errors.
Some foolish idea are making use of 2 pairs of wireless transmitter & receiver with 2 band of frequencies. I think it may solve the time gap.
But it make too many things together! and costy.
(Thanks to shsan trying the inversion)
Raymond
by PaulP
Mon Mar 12, 2007 10:40 pm
The main reason why it fails, even when you manage to get the wiring and the baud rate sorted is the RCB Firmware.
The timings are so precise that even a slight variation can cause it to fail.
If you examine the packets being sent by H2H to the RCB, one of the first commands they send is Sleep. This is why it slumps momentarily while uploading and downloading. This is why you would have been left in a state where nothing worked. A glitch in comms before the unsleep command is sent will leave the bot lying inert.
When using H2H it sometimes works but more often than not it will fail. Shsan you are seeing exactly what I saw.
This will happen no matter which Bluetooth unit you use as it is the nature of Bluetooth to have latency issues. I have emailed several suppliers and they have all replied that they cannot guarantee it wil work. From what I have read and from my experience with my new board, the BlueSmirf is one of the better ones on the market.
Most packet based carrier systems have this problem to one degree or another.
A 54G WIfi based product may perform better as its overall data rate is higher but I wouldnt guarantee it. Nor would anyone I asked.
I have since removed the RCB from my bot and installed an SSC-32 with the same bluetooth unit. (I had to remove all the invertor and pulldown resistor as the SSC has the TTL serial implemented properly.) It has gone from strength to strength and is now wandering wirelessly around the house quite happily.
Before removing the RCB I did one final test with the Bluetooth and that was to ignore the way H2H works and write some code of my own. By faking the timings (not waiting properly for a reply) I was able to upload, download and send Play instructions but I was not up to the task of rewriting H2H in its entirety as I simply don't have enough information about how it all works.
The timings are so precise that even a slight variation can cause it to fail.
If you examine the packets being sent by H2H to the RCB, one of the first commands they send is Sleep. This is why it slumps momentarily while uploading and downloading. This is why you would have been left in a state where nothing worked. A glitch in comms before the unsleep command is sent will leave the bot lying inert.
When using H2H it sometimes works but more often than not it will fail. Shsan you are seeing exactly what I saw.
This will happen no matter which Bluetooth unit you use as it is the nature of Bluetooth to have latency issues. I have emailed several suppliers and they have all replied that they cannot guarantee it wil work. From what I have read and from my experience with my new board, the BlueSmirf is one of the better ones on the market.
Most packet based carrier systems have this problem to one degree or another.
A 54G WIfi based product may perform better as its overall data rate is higher but I wouldnt guarantee it. Nor would anyone I asked.
I have since removed the RCB from my bot and installed an SSC-32 with the same bluetooth unit. (I had to remove all the invertor and pulldown resistor as the SSC has the TTL serial implemented properly.) It has gone from strength to strength and is now wandering wirelessly around the house quite happily.
Before removing the RCB I did one final test with the Bluetooth and that was to ignore the way H2H works and write some code of my own. By faking the timings (not waiting properly for a reply) I was able to upload, download and send Play instructions but I was not up to the task of rewriting H2H in its entirety as I simply don't have enough information about how it all works.
Bluetooth
by ryann2k1
Tue Mar 13, 2007 12:22 pm
PaulP wrote:The main reason why it fails, even when you manage to get the wiring and the baud rate sorted is the RCB Firmware.
The timings are so precise that even a slight variation can cause it to fail.
If you examine the packets being sent by H2H to the RCB, one of the first commands they send is Sleep. This is why it slumps momentarily while uploading and downloading. This is why you would have been left in a state where nothing worked. A glitch in comms before the unsleep command is sent will leave the bot lying inert.
When using H2H it sometimes works but more often than not it will fail. Shsan you are seeing exactly what I saw.
This will happen no matter which Bluetooth unit you use as it is the nature of Bluetooth to have latency issues. I have emailed several suppliers and they have all replied that they cannot guarantee it wil work. From what I have read and from my experience with my new board, the BlueSmirf is one of the better ones on the market.
Most packet based carrier systems have this problem to one degree or another.
A 54G WIfi based product may perform better as its overall data rate is higher but I wouldnt guarantee it. Nor would anyone I asked.
I have since removed the RCB from my bot and installed an SSC-32 with the same bluetooth unit. (I had to remove all the invertor and pulldown resistor as the SSC has the TTL serial implemented properly.) It has gone from strength to strength and is now wandering wirelessly around the house quite happily.
Before removing the RCB I did one final test with the Bluetooth and that was to ignore the way H2H works and write some code of my own. By faking the timings (not waiting properly for a reply) I was able to upload, download and send Play instructions but I was not up to the task of rewriting H2H in its entirety as I simply don't have enough information about how it all works.
Hi All,
It seems controlling RCB through Bluetooth is quite complicated.
In the previous, PaulP mentioned that you used virtual com port to communicate with the board. How did it go?
With your new board, SSC-32, how do you think it will perform better than the original board?
Hopefully you dont mind to share with your findings.
Cheers,
ryann2k1
by PaulP
Tue Mar 13, 2007 6:01 pm
I've tried all sorts of methods now for monitoring and driving the RCB and all basically failed due to timing issues...
As for the SSC-32. It works very well. As a controller it does what they all do.
The SSC is different in that it doesn't store routines for you to play back so it has to have a connection to either a P.C. running control software or an onboard computer such as a Stamp to run the routines.
I managed to write some routines that converted the sample moves across to the SSC as well which helped.
It works well, its a bit larger but it fits and I have fitted the BlueTooth so its completely untethered from the P.C. It also works well with my PDA.
There is a package called SEQ to drive it that takes the role of H2H and is very similar in its functionality.
I'm now looking for a processor to attach.
On the downside you loose some of the features such as ICS but I've never found I need it so I dont miss it. You also loose all the KHR features.
On the Upside, I now have a method of control that is completely open for me to program without any restrictions. I can choose a processor that runs under whatever language I prefer and write routines that are only limited by my ability(and of course those forum members whi share their wealth of experience)
So for me yes its a good move. I've posted images of the mods I've done on Lynxmotion as I was working quite closely with them, I'm also in the process of getting roborealm working with my bot so it should be 'seeing' soon.
As for the SSC-32. It works very well. As a controller it does what they all do.
The SSC is different in that it doesn't store routines for you to play back so it has to have a connection to either a P.C. running control software or an onboard computer such as a Stamp to run the routines.
I managed to write some routines that converted the sample moves across to the SSC as well which helped.
It works well, its a bit larger but it fits and I have fitted the BlueTooth so its completely untethered from the P.C. It also works well with my PDA.
There is a package called SEQ to drive it that takes the role of H2H and is very similar in its functionality.
I'm now looking for a processor to attach.
On the downside you loose some of the features such as ICS but I've never found I need it so I dont miss it. You also loose all the KHR features.
On the Upside, I now have a method of control that is completely open for me to program without any restrictions. I can choose a processor that runs under whatever language I prefer and write routines that are only limited by my ability(and of course those forum members whi share their wealth of experience)
So for me yes its a good move. I've posted images of the mods I've done on Lynxmotion as I was working quite closely with them, I'm also in the process of getting roborealm working with my bot so it should be 'seeing' soon.
by PaulP
Wed Mar 14, 2007 1:11 am
The SSC allows you to use several voltages at once,
VL is Vlogic, this can be anything between 5 and 20+ Volts (cant remember exact figure.)
VS1 and VS2. The servos are organised in 2 banks of 16 and each can have have a seperate voltage.
OR, you can set VS1=VS2=VL with links and just use the 10.8V supply.
It supports Analogue in so I will say yes but I've not played myself as I have no sensors yet. Ithink you might have to do any mixing yourself though.
On LynxMotion, there is a thread regarding RoboRealm which is a free Vision system for robots.
They are currently in discussion with them about integration.
Also Laurenteus who wrote the SEQ application is on the verge of releasing an update which will enable the SSC to store and playback routines and also provide a WinSock server from his application to allow network control from roborealm and any other WinSock enabled app, i.e. whatever you wanna write.
I am currently searching for a microcontroller to add as well but there are so many and they all claim to be the best on the market....
VL is Vlogic, this can be anything between 5 and 20+ Volts (cant remember exact figure.)
VS1 and VS2. The servos are organised in 2 banks of 16 and each can have have a seperate voltage.
OR, you can set VS1=VS2=VL with links and just use the 10.8V supply.
It supports Analogue in so I will say yes but I've not played myself as I have no sensors yet. Ithink you might have to do any mixing yourself though.
On LynxMotion, there is a thread regarding RoboRealm which is a free Vision system for robots.
They are currently in discussion with them about integration.
Also Laurenteus who wrote the SEQ application is on the verge of releasing an update which will enable the SSC to store and playback routines and also provide a WinSock server from his application to allow network control from roborealm and any other WinSock enabled app, i.e. whatever you wanna write.
I am currently searching for a microcontroller to add as well but there are so many and they all claim to be the best on the market....
Bluetooth
by ryann2k1
Wed Mar 14, 2007 3:52 am
Hi,
That's awesome Paul. Good luck with the project.
What do you think this board which I found through google?
http://www.bdmicro.com/mavric-iib/
I have to still struggle with the fundings for my plan from my department. Once I got it, I will start to work on my robot.
Cheers,
ryann2k1
That's awesome Paul. Good luck with the project.
What do you think this board which I found through google?
http://www.bdmicro.com/mavric-iib/
I have to still struggle with the fundings for my plan from my department. Once I got it, I will start to work on my robot.
Cheers,
ryann2k1
by Orac
Fri Mar 16, 2007 12:31 am
I would imagine something like this would suffer even more latency problems then
http://www.rfsolutions.co.uk/acatalog/DS-S103-1.pdf
http://www.rfsolutions.co.uk/acatalog/DS-S103-1.pdf
by PaulP
Fri Mar 16, 2007 2:42 pm
On that one I'm not sure, That is a 802.11b device not bluetooth. Its similar to the type of device you would use for connecting you Laptop t o a LAN (WiFi) and is designed to run best speed of 11Mbps. 802.11a is 54MBps (54g) Wifi routers etc.
It all depends on how the serial to radio aspect is handled. Its hard to explain with just words but I'll give it a go.
Some systems send each data bit as it arrives, (FSK (Frequency Shift Keying) and telephone modems do this) some systems wait for a complete byte to arrive before sending.
A byte is normally 8 bits but with serial data you have to include 1 start bit 1 stop bit and 1 parity bit so 11 we wait for.
Without getting into the maths and exact numbers.
If it takes 1 ms to send 1 bit then for that bit to get from one end to the other, it would be held up for 1 ms while it is detected, transmitted and received before being put on the wire.
If its waiting for a complete byte then it will take 11 times as long before the first bit is put on the wire at the far end. This is probably the crudest description of latency ever written but its close enough.
This is why, BlueTooth at 9600 serial has a higher latency than Bluetooth at 115,200.
I did a quick search on 802.11b and it does mention that FSK (single bits at a time) is used in some types.
To be blunt though, even with a guarantee from the manufacturer that there is low-latency, if the manufacturer of the RCB never took Wireless comms into account, you could be on to a loser.
The only way to really tell is for someone to take the chance and buy one.
It all depends on how the serial to radio aspect is handled. Its hard to explain with just words but I'll give it a go.
Some systems send each data bit as it arrives, (FSK (Frequency Shift Keying) and telephone modems do this) some systems wait for a complete byte to arrive before sending.
A byte is normally 8 bits but with serial data you have to include 1 start bit 1 stop bit and 1 parity bit so 11 we wait for.
Without getting into the maths and exact numbers.
If it takes 1 ms to send 1 bit then for that bit to get from one end to the other, it would be held up for 1 ms while it is detected, transmitted and received before being put on the wire.
If its waiting for a complete byte then it will take 11 times as long before the first bit is put on the wire at the far end. This is probably the crudest description of latency ever written but its close enough.
This is why, BlueTooth at 9600 serial has a higher latency than Bluetooth at 115,200.
I did a quick search on 802.11b and it does mention that FSK (single bits at a time) is used in some types.
To be blunt though, even with a guarantee from the manufacturer that there is low-latency, if the manufacturer of the RCB never took Wireless comms into account, you could be on to a loser.
The only way to really tell is for someone to take the chance and buy one.
