i have had this question for a while. can i control my robot wirelessly through bluetooth, wifi, or rf? if so, how? and by this i mean a wireless usb kind of thing. has anybody had any luck with this kind of thing?
The quick answer to your question is yes this can be done. I have not used any wireless control but I do plan to use my PC for vision navagation via a wireless network. You can also control your robot using a wireless controller. There are others on this forum that have used wireless control for their bots such as Nick Rieser and Andy Lippitt. They can give you the details of what is required or involved much better than I can.
thank you, this helps, im going to ask them how they did it.
Hi there,
I’ve done this a whole bunch of different ways. I’ve used lots to different kinds of radios and kicked myself for being a little cheap in the beginning as it was a long and painful process until I broke down and went all the way.
The cheaper, more painful versions were via some of the inexpensive nordic radios from Sparkfun. While these are cheap and you get a lot of bang for you buck, getting them to run at high speeds w/reliable communications proved a complex problem to which you’re largely left own devices (although I think they’ve since written some decent firmwares with retransmits and the like).
I then moved onto class 1 bluetooth. Very disappointing speeds. I haven’t been following too closely, but I think bluetooth has undergone a major revision with some substantial throughput improvements, but I’m far from up to date on it.
Finally I broke down and decided to go the 802.11 route. I settled on a Lantronix WiPort with a breakout board from www.wibotics.com. I can’t say enough good things about this device, although it has it’s little quirks, it precisly fits the bill for this sort of project. I had been demanding nothing less than 20ms round trips carrying all new servo positions on the one side and sensor feedback on the other. While I was constantly struggling to improve my line protocol efficiency with the others and just sqeaking by, the WiPort delivered it in less than 2ms (once you work through the packing silliness see my blog on it).
I’m rebuilding the bot from scratch, and dropping the WiPort but sticking with 802.11. I’m dropping the WiPort not because of any failing of it, but because I’m putting a Gumstix computer onboard and can access a compact flash card directly. The WiPorts primary purpose is to act as a 802.11 to serial bridge. I’ll be using the linux tcp/ip stack directly and so have no need for this anymore.
A major design consideration around these radios is what will be on either end of the radios, therefore what will the over the air protocol be. If you are hoping to connect a WiPort directly to an SSC32 or something of the sort, it will work just fine, but what you’ll be sending back and forth over the network will be dictated by the SSC32, which is optimized for readability, not low byte counts.
Many servo controllers have considerably worse interfaces (from a network perspective) which send back acknowledge bytes for every command sent. Translating between a serial and a packet based stream requires quite a bit of overhead in both data size and time to form a packet. You might find that a 1 byte acknowledgement gets a 30 byte header when it’s wrapped with all the requisite protocol headers for the network in question.
To get high data rates out of the WiPort, you need to have control over the protocol. This means having a micro or something on the bot side which can interpret your specially crafted over the air language.
In all the incarnations of my bot up until the current, I used 18 series PICs at 40mhz that could easily rip through the data. This interface deserves some thought too if you’re trying to squeeze the things for speed. Serial interfaces are often times hard to get running any faster than 115.2k because most UARTS cap out there. With the WiPort, and a signed NDA, you can get access to write custom firmwares for the WiPort device itself and if need be, create a parallel interface over it’s 11 GPIO pins to speed up the WiPort to onboard uC if need be.
Sorry for the long rambling post here. This is about the track I followed and haven’t looked back until now. 
a couple more thoughts:
I think wireless USB isn’t quite there yet, but certainly sounds promising. I’ve heard about some pretty impressive demos with mind numbing speeds. It’ll be interesting to see what kind of range the product versions yield.
Although this brings up another bonus for 802.11. It’s so widely supported now that there are a wealth of resources that can be brought to bear if you choose this route. You can buy an access point from any consumer electronics store, use standard network packet sniffers for debugging, and if range becomes an issue, there a million different solutions available to the problem.
wow, that is exactly what i meant. but, i have two questions: will it interrupt a wifi signal? and also, is it a wiport-to-wiport or wiport-to-computer with 802.11?
The WiPort will not interrupt a wifi signal per se, it is a wifi signal. The only thing that should be mentioned that you might consider interruption is that if you put a ton of traffic across it it can slow down your other communications over wifi on the same channel. The WiPort is a full and proper implemention of 802.11b and can communicate with another WiPort, or any 802.11b capable device. So you can connect it to your Access Point (including WEP support) or setup an ad-hoc network. Essentially it behaves just like any other device on the network (taking an IP address from DHCP servers and the like) and provides a bridge to a serial port.
alright, that seems perfect, now i only have to test it. but first, to save up the money for one.
this WiPort stuff seems prospective, i may want to look into this 
everything is run through key board or joy stick, right? and can this technology go through walls? and how much programming skills does this require? if it does, then… 
-Jared
(hope you dont mind if i add a little to ur post beserkerman)
doesnt matter. its all for the same purpose.
the WiPort doesn’t come with any software at all except for some configuration bits. I’ve heard of, though not used, something called a ComPortRedirector which will create a device in windows that will appear as a com port but is backed by a socket connection. I believe Nick was trying to use this and will surely chime in with some thoughts on it. Something like this might let you use software that is designed to talk directly with what you put on the other end of the WiPort through a serial cable. For example, you might be able to use LynxTerm to talk to the WiPort over a ComPortRedirector port through the WiPort.
All that said, write your own code. You really won’t be able to get the performance I’m talking about out of it unless you design the application around the network interface. The ComPortRedirector might help you get something up and running a bit more quickly though.
Since I am also interested in using the wiport breakout board for my project, I may as well jump on board and ask some questions as well.
Andy, you mentioned creating your own code around the wiport protocal but I don’t have the skills needed to do this. Will I be able to use the wiport with another application that outputs data to a serial port without any custom code? I quess what I am asking is can the wiport be plug and play?All I need is to take the serial output from a desktop application to send data to the SSC32. I do not intent to have 2 way communications, just the PC to the SSC32.
Nick might be able to speak the the effectiveness of the redirector which is the only shot at making it plug and play.
Sorry about the tardiness, guys.
I’ve been taking four classes this summer, and it’s brutal.
Let’s see…
I wouldn’t call myself experienced with the WiPort, in any real sense.
I still haven’t been able to get it to talk to my robot’s electronics (although I’ve got the laptop --> WiPort communication working).
So, I don’t know the actual speed or reliability of the comport redirector.
I doubt that it would be up to par with what Andy has done, since it seems to utilize a TCP connection that buffers and packets it’s information before actually sending it.
If you’re not too worried about speed, though, I do know that the WiPort can be more-or-less plug-and-play with the redirector.
More-or-less because the V3 Breakout Board needs to be assembled first, and the WiPort’s WiFi has to be manually setup.
To use the redirector, you select the PC’s port that you want to pretend to send serial information to, type in the IP address of the WiPort that you assign in the initial setup, and type which of the two ports on the WiPort that you want to talk to.
After the initial setup of the redirector, everything runs without further hassle.
When you open a COM program (like Lynxterm, RIOS, Visual Sequencer, etc…) a window will pop up that shows the redirector trying to grab the com data and send it across the WiFi.
Then, if it’s successful, you’ll simply have to click the drop-down list on the program and select the COM port that you’re pretending to send info to.
After that, everything should work as if you had a cable running directly from a PC port to the electronics.
Nick, My heeero, my brother! 4 classes eh? Better you than me… 
Glad to see you drop by.
Oooo… looks fancy. I cannot tell, exactly, what the PC has to do with anything in that picture. Does it transmit the signal via PC now instead of through the antenna or does it just make the transmitter look neat? If it is now transmitted through the computer, can it be transmitted throught the internet? This would surely help in not having to worry if my transmitter (or me for that case) is too far away from my rover, but IS that how it works?
The transmitter and PC work together. The PCTx utilizes a normal r/c transmitter to achieve a wirless link to your robot, r/c car, or any r/c receiver for that matter. Instead of you manually moving the sticks on the transmitter, you can write software to send commands through the transmitter instead. It connects to a PC via the USB port.
Take a look at the site now. Ive added more movies and images that hopefully will explain things better. www.endurance-rc.com
The advantage would be ease of integeration. Control software is already written in VB and C++ and can be easily modified for other languages. You can also use any standard r/c gear you already have.
If you connected the system to a PC running server software, you could do this.
Hi all,
Has anyone used the endurance-rc.com PCTx besides BotHakr who developed the PCTx?
I have been to the website, but there does not seem to be much in the way of recent downloadable software available.
I would expect more sophisticated free APIs for downloading by now, or is the website owner not allowing them to appear to help enhance the sale of his own software?
Just a thought.
Regards,
TCIII
If the cable simply connects the Tx to the Computer, one can use a R/C flight simulator cord for hooking your Tx to the computer.
You can find them for $10 to $20. $10 here: gravesrc.com/category_s/371.htm
I use on of these for my flight sims and you can set it up as a joystick in windows. One could interface the controls from there.
Unless yours comes with software for interfacing the controls on the pc.