Let's Make Robots!

Arduino <--> PC wireless communication: Hardware options?!

Hi Guys!

I think i fancy adding some wireless control to my little rover bot thing.

I fancy using an Xbox controller perhaps, or an old PC controller. I also might want to have the bot transmit some data back to the computer perhaps? therefore, I think running through a PC make the most sense.

What are my options for hardware. What are the advantages and dis advantages?

Bluetooth seems the most obvious, but i image the range is pretty poor?

WLAN looks like it has better range, but surely this would be much more complicated?

Or can i buy a Shield, and paired USB dongle for the computer?

Any offers of advice/reccomendations/experiences?

Cheers :)  Olly

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Damn, now you've intruiged me.

Been thinking too much into how I would do this and now I have a few sheets of paper with my scribbled handwriting and diagrams and visual studio open.

I also have a "spare" rooted arduino phone knocking around, so that could be useful. (currently use a windows Lumia)

I have a lumia 710 so sadly can't use that as a remote. i have a nexus 7 tablet, root isn't needed, worked fine sending data to a serial terminal on my PC, with the slick 2 USB app it also worked with my PL2303 usb to TTL adaptor quite nicely. Sadly my sister saw fit to smash the nexus screen so that's now borderline useless (part still works and I can still get blueterm fired up). Annoyingly the PL2303 I have is an older revision and unsupported on windows 8, i don't have a level shifter or native RS232 device to use my real serial port. Oh well. I do have an old android 2.2 phone somewhere, perhaps that might still work.

Thats really helpful, thanks. Your description puts a whole lot of information i have seen all over the place, into one coherent description, which is much easier to understand. I have used serial comms on my DrawingBot quite a lot, so shouldnt have a problem there. my draw bot just sends and recieves in ASCII, and uses the standard instructions that ascii already uses. I could make up my own protocol for whatever i was doing, using a pre set "format" to transmit the data i wanted.


Start, X( For axis, forward and backward), a 0-9 value, Y, (for axis, left right), a value 0-9, End.

or similar

I am dual booting Ubuntu/Windows, but only tend to use windows for Steam.

I have an Xbox Controller output reading program already, so dont anticipate that being too difficult.

For "desktop" use, i might just get a bluetooth shield, and then worry about expanding it once ive learnt the basics!

Got a few choices in this area. RF modules (433MHz or similar), bluetooth, WiFi and XBEE are the ones I can think of.

RF, bluetooth and XBEE are all serial based. WiFi however is significantly more complicated.

 I dont believe there is a standard shield + USB dongle setup with the exception of a bluetooth shield + bluetooth USB adaptor or the same with WiFi.

Some of the RF modules are one way communication only. You have a module that transmits serial data, and a module which recieves. This would mean you would need both a transmitting and recieving node at each end. However some modules are both in one thankfully, such as this one: http://www.parallax.com/Store/Accessories/CommunicationRF/tabid/161/CategoryID/36/List/0/SortField/0/Level/a/ProductID/582/Default.aspx

Bluetooth modules will usually just break out a Tx and Rx port which can be connected to your microcontroller. Any USB bluetooth adaptor or internal adaptor on a windows/mac/linux PC will support serial port mode (ie on windows, registering themselves as a usable COM port for serial data) and this is also a mode which android phones support (but not iOS, windows phone or blackberry). Some Bluetooth modules may also offer advanced functions but serial should do the job, anything else is just over complicating things.

XBEE again, breaks out a Tx and Rx port for usage. You will need a corresponding XBEE at the PC end too. You can probably just use a USB > TTL serial adaptor for that at the PC end (same adaptor would work for RF modules too). XBEE's can be expensive but some more expensive models with a proper antenna can have phenomenal range (line of sight dependant, XBEE will work through a wall, but will severly impact range, think they may be more effected by it than bluetooth). Outdoors XBEE is probably the best choice short of using a 3G modem.

WiFi shields I think are more complicated. You cant just treat them as serial, I think you have to break out into proper Tcp programming.

Serial should be absolutely fine for your needs. Best part would be that if you did it via serial then you can switch and choose between RF, bluetooth and XBEE at any time. As far as the computer is concerned it is communicating on a serial port, it doesnt know that its really transmitting through an RF module or bluetooth modem. Same at the microcontroller end.



You would need to write an application on the PC which reads the current controller state. Converts this into a set of bytes indicating button states etc. Write this data to the serial port.

What operating system are you using? I have taken input from a 360 gamepad on windows before and played with the serial port. It is rather trivial to do within a windows forms application in C# or VB.net. If you were able to give a rigid specification for how things need to work then I could even assist here.


The microcontroller will need to be programmed the read these bytes and establish which buttons are being pressed. A well documented example of this might work is the microsoft serial mouse protocol if you are willing to do some googling.


If you were to go with serial, one other consideration would be whether to poll for input or have a constant input stream. I would be half tempted to poll on an embedded system. If you poll for input, you would write a serial request for input data, the PC then replies with the controller state. If you use a constant stream, the PC constantly sends the current state. For the sake of not overflowing any buffers, I think polling might be more suitable in this scenario.