DIY 2.4ghz RC Control Via PC

[rich smith]

A few people have expressed interest in RC control via a PC so here's a circuit and code for an XBee/servo adapter. It only costs a dollar or two and takes a few minutes to build. Originally it was for a model boat project but I tried it in my 48" foamie last week and seems to work great for flying a plane too.

The regular RC transmitter and receiver are not required. A pair of low cost 2.4ghz XBee RF modules replace the 72mhz RC link and can be controlled via numeric keypad of a PC running WINDOWS HYPERTERM or other basic comm program. It's also possible to develop custom software for things like fully automated flight etc. and with 2-way GPS link PC control of UAV, FPV, or aerial photography. Single character commands are as follows (numlock on):

'8'=elevator up
'2'=elevator down
'4'=rudder left
'5'=rudder center
'6'=rudder right
'*'=throttle full
'9'=throttle up
'3'=throttle down
DEL=throttle off
'0'=reset (throttle off, R/E center)

Notice that they are similar to those of Microsoft Flight Simulator.

Diagram below shows wiring for the plane module. As you can see it's based on an Atmel Tiny25 chip but also works with Tiny45 and Tiny85 w/o modification. It uses the same interface cable for the PC end from the XB/GPS project:

http://www.rcgroups.com/forums/showthread.php?t=993165

SRVPC50x.TXT is the Intel Hex file for downloading to a Tiny25 (fuseh=d7 fusel=e2 fusex=fe). It's a pretty simple program, only about a hundred instructions. Baud is 4800bps instead of the XBee default 9600 so DI pin can be optionally connected to a GPS for plane tracking.

Configuration of the XBee via AT commands is required. Must be plugged into the PC end for this:

+++
atrp1
atbd2
atac
(change PC to 4800)
atwr

Technically this only need be done on the plane module but I do it to both so they will be interchangeable."atrp1" is optional but enables short blink on the RSSI pin so you can see individual characters come in.

As usual let me know if you find any bugs or documentation errors. If there's interest I'll see if I can come up with photos and maybe a video.




Update:

Here's photos of the assembled unit and also new simpler version of the XB/Tiny schematic with a diagram added for the XB/PC end. The regulator can be replaced by a couple diodes which are cheaper and easier to obtain (Radio Shack). Also the original bin was for idle lo serial for an older RF modem and is replaced with idle hi for the XB. Channel 4 is shown in the schematic but is not implemented by the code at this time. Old files moved to post #12 for anyone who needs that type serial.

Notice the Associate and RSSI LEDs are attached to the top of the XBee now instead of the adapters. Tiny SMD types are very light and very bright. Maybe you can make them out in the photo. All my XBee modules have these now. Very helpful in telling if power is applied and if link is established regardless of what they are plugged into.

Assembly hints (no PCB):

1. Gorilla glue the XBee socket to one side of an 8 pin DIP socket. Glue 2x4 and 1x4 pins (3x4) to the servo side. Be careful not to get any glue on the contacts as it will wick in and ruin them. Mixing a little bit of water into PU will cause it to foam and set faster which helps prevent this. Let set overnight.

2. Solder regulator or diode circuit to the XBee socket and then solder connections between DIP and servo pins.

3. Test the module and if OK add more glue to the bottom for physical strength (photos taken before this step). Allow it to foam up and set overnight.

4. Similar technique for the XB/PC adapter. Again, don't let any glue wick into the contacts of the XBee socket. If using a PC drive power connector then block position 3 of the cable and cut that pin on the connector (polarizing key) so it can't be plugged in wrong.

5. To test simply plug everything in and see if the Associate LEDs light indicating power. Even with no servos or LEDs connected you can check the link because if the plane end is wired for loopback (DI to DO) every time a key is hit it's echoed on the PC. RSSI LEDs blink too if attached. Next see if numpad keys move the servos at which point it's ready to fly.




Update:

New hex for 4800bps instead of 9600bps. This allows optional connection of DI to a GPS for plane tracking. Plane XBee must be configured for the new baud via AT commands. EE location 0 still holds OSCCAL value for fine tuning but now factory default is used if 0xFF (never programmed). Most will not have to put anything there.

In addition a change has been suggested to the schematic for easier plug in of an EM406 or other GPS. Connecting DI to the channel 4 pins through a 1k resistor allows those to be used for that purpose. This means there is no echo now so if you want that feature use the old schematic. You can still add code for another servo on channel 4 w/o hardware change if there is no GPS plugged in.

Old files moved to post #64.

[boldive]

Is it possible to use analog resistors from buddy box (Futaba Skysport4 for example) to control a plane? What kind of adapter needs to be installed between XBee and servo (if more than 3 channels)?
Thanks

[gobigkahuna]

There's interest! ;) I'm very interested in this. I'm building a remotely operated (underwater) robot that is currently being controlled by a DX5e radio, but my future plans are to control it by computer. The 2.4 GHz signal is sent down a single wire to the receiver which resides in the robot several hundred feet away. The reason for using an RF signal is that data can be sent very long distances on a single wire. I'd be very interested in replacing my current radio / receiver with a pair of Xbee modules but up 'til now I had no idea where to start. Your post has shed some light on the subject and a glimmer of hope! :) I'll start googling for info on coding the Xbee, but in the mean time what would be involved to expand what you've done to 6 or 8 servo channels instead of 3? Using a joystick, gamepad or other analog Windows HID device instead of the numpad?

[MCarlton]

If its possible to use a PC for flight control, then would it be possible to use that PC for almost infinite programming possibilities, and tie those into telemetry from the model?

Thus, if flying a sailplane, one could have a 2-way comm link between a laptop and the model. Telemetry from the model "tells" the laptop what it is doing, and the laptop "tells" the model the best combination of flaps, trim etc.

You could select a setting "minimum sink" "maximum LD" etc, and the model would automatically and continually adjust itself, leaving the pilot free to concentrate on searching out lift and such.

Also, for landing approaches with large models, one could programme in an ILS approach. Define a glideslope and sink rate in the laptop and the telemetry link looks after that aspect of the approach.

There's even a possibility for a failsafe. If the model has a radio failure, a VHF (or whatever) telemetry link could take over and, using a GPS unit mounted in the model, could actually bring the model back and land it on the strip.

[rich smith]

I don't know about resistors but it is quite common to use a micro to convert PC serial into PPM for the buddy box input and the TX then sends the signal to a plane. The plane uses a regular unmodified RX/ESC in this case. XBee is used for the current setup because 2-way communication was required which is not possible with RC TX. Since RC TX/RX are not required the XBee approach is actually cheaper too.

It's also possible to connect the buddy box output to an XBee and use the same circuit shown below for the plane. In this case another micro is needed to convert PPM from the TX to serial for the XBee. Requires a different program.

In the current project the Tiny25 micro goes between XBee and servos on the plane. For the PC end the transmit XBee connects directly to the serial port. Only a regulator to convert 5v to 3v and inverter are used. No micro for the PC end.



Is it possible to use analog resistors from buddy box (Futaba Skysport4 for example) to control a plane? What kind of adapter needs to be installed between XBee and servo (if more than 3 channels)?
Thanks

[rich smith]

I'll dust off the camera and take picks of the assembled unit sometime in the next day or so. Next time I go out to the field I'll try to get video of the unit in action.

That's interesting about using RF to control underwater. I'm not sure 2.4ghz is best choice though because very thick insulation would be needed to prevent siganl from bleeding off. Lower frequency like 72mhz or, better still, 27mhz will go farther. In fact really low frequency RF (khz range) cuts through water and may not need a wire at all. That's what is used to talk to subs on the other side of the world.

As far as more channels the idiots at Atmel made an unbelievable blunder by putting Timer1 and Timer0 on the same pins limiting Tiny to only 3 PWM channels. One fix is to write bit bang code to do more than 3 which will increase code size by 10. Another is switch to Mega (i.e. Mega48) which has 6 PWMs or use 90sPWM AVR or DsPIC which have jillions of PWM pins.

As far as HID is should be easy to throw together custom WINDOWS code (Visual Studio) to replace HYPERTERMINAL. Non-HID is a bit more complicated. I'm not sure what the benefit would be over regular RC TX/RX though.


There's interest! ;) I'm very interested in this. I'm building a remotely operated (underwater) robot that is currently being controlled by a DX5e radio, but my future plans are to control it by computer. The 2.4 GHz signal is sent down a single wire to the receiver which resides in the robot several hundred feet away. The reason for using an RF signal is that data can be sent very long distances on a single wire. I'd be very interested in replacing my current radio / receiver with a pair of Xbee modules but up 'til now I had no idea where to start. Your post has shed some light on the subject and a glimmer of hope! :) I'll start googling for info on coding the Xbee, but in the mean time what would be involved to expand what you've done to 6 or 8 servo channels instead of 3? Using a joystick, gamepad or other analog Windows HID device instead of the numpad?

[gobigkahuna]

That's interesting about using RF to control underwater. I'm not sure 2.4ghz is best choice though because very thick insulation would be needed to prevent siganl from bleeding off. Lower frequency like 72mhz or, better still, 27mhz will go farther. In fact really low frequency RF (khz range) cuts through water and may not need a wire at all. That's what is used to talk to subs on the other side of the world.

The way I understand it, the benefit to using 2.4 ghz is the reduction in noise. We're building this based on the advice of a consultant who's done this before so hopefully he's right.

As far as more channels the idiots at Atmel made an unbelievable blunder by putting Timer1 and Timer0 on the same pins limiting Tiny to only 3 PWM channels. One fix is to write bit bang code to do more than 3 which will increase code size by 10. Another is switch to Mega (i.e. Mega48) which has 6 PWMs or use 90sPWM AVR or DsPIC which have jillions of PWM pins.

Way over my head. :o I'll take that as to mean, no adding more than 3 channels would not be easy to do. ;)

As far as HID is should be easy to throw together custom WINDOWS code (Visual Studio) to replace HYPERTERMINAL. Non-HID is a bit more complicated.

So when you plug this into your USB port I'm assuming Windows recognizes it (ie. you didn't need to create any drivers)? So you're able to plug it in and then just send commands to a COM port?

I'm not sure what the benefit would be over regular RC TX/RX though.

I'm not sure there would be a benefit to using an XBEE since it's limited to only 3 channels. But I was hoping to use it as a computer interface instead of a standard RC TX/RX because of a) cost, b) wouldn't required "destructive" hacking c) takes up less space d) more easily customized.

[rich smith]

Yes, the potential is huge. Right now we're not using the XBee "downlink" capability but it would allow the possibility of having a ground PC do UAV type duties instead of a wimpy on-board micro. The existing circuit is pretty much ready to go for that.

I was always fascinated by the prospect for "intelligent soaring" software Even without downlink but never did anything. For example when sensing a wing being lifted then bank in that direction hoping to catch the thermal. And, like you say, automatically adjusting for flight conditions.

On the subject of failsafe I have code buried in other projects for just that purpose and maybe incorporate it into this project or do another thread. Similar to this but with RC RX in addition to the XBee. There is still one unused port bit available.

If its possible to use a PC for flight control, then would it be possible to use that PC for almost infinite programming possibilities, and tie those into telemetry from the model?

Thus, if flying a sailplane, one could have a 2-way comm link between a laptop and the model. Telemetry from the model "tells" the laptop what it is doing, and the laptop "tells" the model the best combination of flaps, trim etc.

You could select a setting "minimum sink" "maximum LD" etc, and the model would automatically and continually adjust itself, leaving the pilot free to concentrate on searching out lift and such.

Also, for landing approaches with large models, one could programme in an ILS approach. Define a glideslope and sink rate in the laptop and the telemetry link looks after that aspect of the approach.

There's even a possibility for a failsafe. If the model has a radio failure, a VHF (or whatever) telemetry link could take over and, using a GPS unit mounted in the model, could actually bring the model back and land it on the strip.

[rich smith]

So when you plug this into your USB port I'm assuming Windows recognizes it (ie. you didn't need to create any drivers)? So you're able to plug it in and then just send commands to a COM port?


Actually you plug it into a serial port (COM1-4) or, if there's no RS232 available like with notebooks, use an USB-to-serial converter (COM5+). For the adapters XP drivers are required (FTD/Prolific) but I think Vista don't need any.

Please keep us updated on that robot-sub project. I tried doing something like that many years ago but failed miserably due to lack of know-how. :eek:

[fungus amungus]

I dont mean to sound like a killjoy but you guys do realise that this kind of thing is against broadcasting laws as the system hasnt been approed by roff.

[rich smith]

I dont mean to sound like a killjoy but you guys do realise that this kind of thing is against broadcasting laws as the system hasnt been approed by roff.


Not sure if "approed by roff" but as holder of 2nd class RadioTelephone license I can assure you these are legit in the U.S.. Note FCC ID in photo.

[rich smith]

I've uploaded photos, updated hex, assembly hints, and a new simpler schematic to post #1. A couple emails indicated trouble with original hex files. Problem was idle lo serial used for a dffierent RF modem so the new one is proper idle hi for XBee. The old one was moved here to allow use of other RF modems which need that type of serial.

Biggest hardware change is replacing regulator with common diodes. Also a diagram for the XB/PC adapter was added using diodes instead of regulator too. A regulator is a safer more accurate supply but costs more and harder to procure. The original schematic is reproduced in this post so you can go either way. LEDs have been removed from the adapter and can be soldered to the top of the XBee modules which is more convenient.

Always go to post #1 for latest files with bug fixes and improvements.

[Gary Mortimer]

Blimey Rich, the boys in heavy jackets and sunglasses from JR Futaba et al will be knocking on your door to explain the errors of your ways.

Well done top use of xbees.

I was just wondering when somebody was going to bring all of the UAV function to the computer on the ground!!

Automatic soaring certainly is interesting, yesterday I flew my 40 inch electric V tail, not made for soaring airfame into a boomer and was soon joined by 3 real gliders! The power saving for that portion of flight is obviously tremendous.

I have often thought that a slope that you know well from hand flying that works when conditions are a certain way would be a great place to put a radio relay of some sort.

Could you wire a couple of maxstream extends for this??

This thread will certainly be followed with great interest!

Cheers

G

[rich smith]

Thanks Gary. These XBee modules are great. Wireless RS232. It was love at first sight. I just got through testing a couple of the 6 mile 900mhz units with modified RCCam patch. Got a little over 3 miles in my case. These are actually cheaper than the 2.4ghz and weigh about the same so I may switch over.

The 40 mile Xtend units are a little heavy (and pricey :) ) for my application but RS232 is RS232 so they should work. May put something together in the future.

Also tried flying one of the 1B1M Delta with this setup. Not as easy as the more stable 48" foamie because they're a little "frisky" but no problem. You definitely have to set the typematic rate on the keypad to minimum.

So far there are 3 units built (5 counting my 2) and they all work so that's a good indication bugs have been worked out. I got a couple requests to change baud to 4800 so it would be compatible with the GPS tracker. Apparently reconfiguring the XBee with AT commands is not that big a deal so maybe another bin coming down the pike. And pics of the diode version.

Blimey Rich, the boys in heavy jackets and sunglasses from JR Futaba et al will be knocking on your door to explain the errors of your ways.

Well done top use of xbees.

I was just wondering when somebody was going to bring all of the UAV function to the computer on the ground!!

Automatic soaring certainly is interesting, yesterday I flew my 40 inch electric V tail, not made for soaring airfame into a boomer and was soon joined by 3 real gliders! The power saving for that portion of flight is obviously tremendous.

I have often thought that a slope that you know well from hand flying that works when conditions are a certain way would be a great place to put a radio relay of some sort.

Could you wire a couple of maxstream extends for this??

This thread will certainly be followed with great interest!

Cheers

G

[rich smith]

I put pics of the diode XBee circuit in post #1 and moved the regulator ones to post #12 so photos will be with corresponding schematics.

A buddy of mine just gave me a Tiny25 chip that don't work. It programs ok and code and fuses read correct but it fails in my socket so somethings amiss. The only thing different is it's from a batch that's couple years newer than my Tiny45s. Probably the internal oscillator is off or something. I'll take a closer look today at lunch.

[gobigkahuna]

These XBee modules are great. Wireless RS232.
Hey Rich,
How difficult would it be to use a pair of XBee modules with a serial servo controller (like this: http://www.pololu.com/catalog/product/207 ) to do something similar to what you're doing? The advantage would be that the SSC would support up to 8 servos and software already exists that works with it (RoboWare).

[rich smith]

That looks like a great find. I just ordered one. Don't know how I missed such a neat gadget. It costs a couple bucks more than the quick and dirty one here but definitely solves the limited channel issue. I may upgrade my Tiny to a Mega for similar features some day but for now the 3 channels are enough for me to play with and I need the MS Flight Sim layout.

I did run into a bug which, as suspected, is due to variation in the internal oscillator. It took me a while to dig out the source from couple years back but I now understand how my own design works :). Out of few dozen of my Tiny25/45/85 chips a couple were far enough off to fail.

Like all AVRs, frequency is determined by the OSCCAL register. There are two ways to set this for SRVPC.HEX: put the correct value at EE location 0 where it gets loaded on power up or edit the hex (text) file at offsets 60 and 62. The former method would use a regular AVR programmer and the second uses a text editor like NOTEPAD. It may be necessary to change the checkbyte at the end of the line but I don't need to since my loader program ignores it. In any case the unit always powers up with chan 1 set for 1.5ms making adjustments easy. Anyone needs more onfo on this just ask.

I see a better long term fix but involves re-compiling which is not convenient right now. I got the two "wayward" chips going with the bandaid solution. The 4800bps mod is also on the list. New code will be put up here when it's available.




Hey Rich,
How difficult would it be to use a pair of XBee modules with a serial servo controller (like this: http://www.pololu.com/catalog/product/207 ) to do something similar to what you're doing? The advantage would be that the SSC would support up to 8 servos and software already exists that works with it (RoboWare).

[gobigkahuna]

Sorry if this is taking us too far off topic, but here's what I'm thinking:

On the computer end use an XBee with a USB interface board, then on the remote end use an XBee with a Polulu Micro Serial Servo Controller (http://www.pololu.com/catalog/product/207) and then use RoboRealm software to control it (http://www.roborealm.com/help/Pololu_SSC.php). Using RoboRealm should make setting up joysticks / gamepads a snap, plus I can also use it to display / control the video coming from my camera. I'm pretty sure that RoboRealm + the Micro SSC will work. What I haven't found is any super simple info on how to set up a pair of XBee's as a simple RS232 "wireless" cable. I'm hoping this will be a "plug and play" solution. Any thoughts?

[kaldak]

Great stuff! I was making plans for something almost exactly along these lines, and then was pointed here.

Now, the one thing I still haven't tracked down is some sort of program running on the computer that could emulate the more advanced functions of a Tx such as mixing channels, trimming, exponential controls, loading different profiles, etc.

Probably doesnt exist, but I figured it couldnt hurt to ask. I know I could include an actual Tx inputting to the computer, but I'd rather simplify things by leaving it out entirely.

Any thoughts?

Thanks!

[tune by tito]

What I haven't found is any super simple info on how to set up a pair of XBee's as a simple RS232 "wireless" cable. I'm hoping this will be a "plug and play" solution. Any thoughts?
that is the basic function of the Xbee module a replacement for RS232 cables

[robertspil]

It is nearly ready.
I devised a "Radio Comand Control Language or RCCL" , powerful enough for the most difficult transmitter programs (has to be better than my MC24)
My idea was to program the transmitter on the PC, with a full size and comfortable keyboard and display.
There is a simulator written in Python.
The "real" use is with a program is written in C for a Atmega128 . It is tested, not yet flyed. Now I am soldering/testing PCBs for the real transmitter.
The HF transmission shall use normal modules (a JR/Graupner because all my planes/gliders have a 35Mhz receiver).
There is a first documentation (in french, not yet translated ), the project is not yet released as open source...
Robert

[gobigkahuna]

that is the basic function of the Xbee module a replacement for RS232 cables
Any links to a basic tutorial on using an Xbee this way? I'm looking at using one of the USB modules to use on the PC end (which seems simple enough), but need some help with the remote end where I'd want to connect my serial device.

[rich smith]

Not OT if you believe in thread titles :). I have a SSC on the way.

As far as getting XBee modules to talk it is simply a matter of powering on two modules (3.3v) and sending idle hi 9600bps into DI of one. It comes out DO of the other. If you build the PC level converter in my diagram for one and just short DI to DO on the other you have instant 2-way link. Any characters typed in HYPERTERM will echo back.

Or if you build two PC adapters and run them on two computers then anything sent from one will show up on the other as long as it's within a half mile or so. Couldn't be simpler.

I just tested this out with a couple of the 900mhz versions which cost less than the 2.4ghz, weigh less, and have up to 6 mile range with good antennas. I got almost four miles with el cheapo $2 antennas. (maybe 900mhz is off topic? Naaaaah....)

Sorry if this is taking us too far off topic, but here's what I'm thinking:

On the computer end use an XBee with a USB interface board, then on the remote end use an XBee with a Polulu Micro Serial Servo Controller (http://www.pololu.com/catalog/product/207) and then use RoboRealm software to control it (http://www.roborealm.com/help/Pololu_SSC.php). Using RoboRealm should make setting up joysticks / gamepads a snap, plus I can also use it to display / control the video coming from my camera. I'm pretty sure that RoboRealm + the Micro SSC will work. What I haven't found is any super simple info on how to set up a pair of XBee's as a simple RS232 "wireless" cable. I'm hoping this will be a "plug and play" solution. Any thoughts?

[gobigkahuna]

So lemme see if I'm following you (sorry for being such an electronics noob). I've attached a quick schematic of the remote end using an SSC. The computer end I would use a USB adapter for the XBee (or your schematic too, right?). The two 1N4001's are reducing the voltage from 5v to 3v, right? So I'd need a 5vdc supply. Then Do/Di from the XBee are merged and connected to the RS232 in on the SSC. And lastly a common ground connection. Is that it? Can't be that simple! ;)

[Jimthree]

Hey Folks,

Can i ask how you have your Xbee's configured? I'm suffering from high latency on mine.

I have two series 2 xbee's (flashed to the ZB firmware). One is connected to the PC and the other to an Arduino. The Arduino pushes out one byte every 1/10 second, and I watch what is happening on a terminal program on the PC. The Xbees are in transparent mode.

I see a burst of the bytes come through then a long pause, then another burst more, then a pause....

I've taken the packetization value down to 0, and i'm running at 9600,8N1 with no flow control. Can anyone suggest any settings that could help get a more consistent and smooth transfer rate?

cheers
Jim

[rich smith]

I haven't wired mine up yet but from docs looks like two errors in your diagram. First, you cannot connect power input of XBee to power input of SSC03A because neither will receive power then. The Xbee circuit should get it's power from one of the servo outputs.

Note that if you have 6v or battery source the regulator circuit is required. The diodes only work from a +5v source.

Second, the XBee does not have standard RS232 serial so it does not go to those pins on the controller. It needs to connect to what they (incorrectly) call "logic level" serial. More proper term would be "inverted" or "idle high" serial since it is polarity that's important and level is pretty much irrelevant.

Other than that looks like you're on the right track.

So lemme see if I'm following you (sorry for being such an electronics noob). I've attached a quick schematic of the remote end using an SSC. The computer end I would use a USB adapter for the XBee (or your schematic too, right?). The two 1N4001's are reducing the voltage from 5v to 3v, right? So I'd need a 5vdc supply. Then Do/Di from the XBee are merged and connected to the RS232 in on the SSC. And lastly a common ground connection. Is that it? Can't be that simple! ;)

[rich smith]

I usually don't bother to configure at all but use them "out of the box". No API mode or any changes except maybe baud rate for the GPS. Default setting generally result in delays of only few microsecond whether one byte or packet is sent. This is virtually instantaneous in human time.

In my Ardupilot XBee connects only to the GPS for tracking purpose. Not sure why Jordi runs the XBee to the Mega at all at this point. Apparently just because it's there? :)



Hey Folks,

Can i ask how you have your Xbee's configured? I'm suffering from high latency on mine.

I have two series 2 xbee's (flashed to the ZB firmware). One is connected to the PC and the other to an Arduino. The Arduino pushes out one byte every 1/10 second, and I watch what is happening on a terminal program on the PC. The Xbees are in transparent mode.

I see a burst of the bytes come through then a long pause, then another burst more, then a pause....

I've taken the packetization value down to 0, and i'm running at 9600,8N1 with no flow control. Can anyone suggest any settings that could help get a more consistent and smooth transfer rate?

cheers
Jim

[gobigkahuna]

Other than that looks like you're on the right track.
So out of 3 leads I got the ground wire correct? Guess that's close enough to being correct if I were a politician or a weather forecaster, huh? :D

Sounds like I better wait until you've had a chance to play with your SSC before I start messing with mine. ;)

[rich smith]

So out of 3 leads I got the ground wire correct? Guess that's close enough to being correct if I were a politician or a weather forecaster, huh? :D

Sounds like I better wait until you've had a chance to play with your SSC before I start messing with mine. ;)


If you do that better bring a lunch... it may be months before I get around to it. The el cheapo Tiny SSC will be occupying my attention for now because I just wanted to fly a plane using Windows XP and the SSC03 can't do that. I suggest jumping in because your circuit looks good with those two minor corrections. YOU be the guinea pig! :)

PS Cool, the way you cut and paste those two docs!

[gobigkahuna]

Ok, if I finish my current project (driving the underwater ROV with a 2.4 Ghz RC radio) before you start with the Micro SSC, then I guess I'll have to be the guinea pig! ;) I may post another circuit or two before wiring things up, so I don't fry the electronics. BTW, the main service voltage at the remote end of my system is 12V but I'm powering the receiver with the built-in 5V from the brushless motor ESC's BEC. On the computer end, I'd like to use the 5V taken from the USB port.

[rich smith]

I'm powering the receiver with the built-in 5V from the brushless motor ESC's BEC. On the computer end, I'd like to use the 5V taken from the USB port.

That's exactly the way I do it with the el cheapo SSC on my UAV. Channel 3. Simple and neat.

[gobigkahuna]

Ok, I think I've corrected the remote side wiring schematic (new attachment). What adapter do people recommend using (esp. for the computer end). So far I've found these:

http://store.gravitech.us/xbtousbad.html
http://www.sparkfun.com/commerce/product_info.php?products_id=8687
http://xbeeadapters.com/index.html
http://www.robotshop.us/droids-sas-xbee-usb-board.html
http://www.adafruit.com/index.php?main_page=product_info&cPath=29&products_id=126

[davidlowjw]

http://www.sparkfun.com/commerce/product_info.php?products_id=8687
note that this xbee usb explorer from sparkfun have no voltage regulatior.
not recommended for use with 5v microcontroller

btw, they have produce one with regulator recently
http://www.sparkfun.com/commerce/product_info.php?products_id=9132
hence, no problem connecting xbee 3.3v to arduino/pic 5v

personally, i recommend adafruit's (USD10) , it is cheap, if not the cheapest :)

[13brv3]

http://www.sparkfun.com/commerce/product_info.php?products_id=8687
note that this xbee usb explorer from sparkfun have no voltage regulatior.
not recommended for use with 5v microcontroller

personally, i recommend adafruit's (USD10) , it is cheap, if not the cheapest :)

FWIW, the Sparkfun USB Explorer does have a 3.3V regulator. They don't mention it, but take a look at the schematic. I don't recall the chip number, but the current rating was only "guaranteed" to be 150 ma, though I'm running the 900 Pro XBee modules with no problem.

Thanks for the tip on the adafruit unit. If you already have an FTDI adapter (and who doesn't), that would have been a better way to go.

Cheers,
Rusty

[Gary Mortimer]

Just thinking about the mention of MSflightsim if you've hooked up to fly via flight sim.

Then the autopilot should sort of work!!

My joke somewhere else about using the flight sim Predator becomes less funny!!

http://www.pcaviator.com/shop/viewAProduct.php?pid=977

[gobigkahuna]

@Gary - My application isn't for RC aircraft, but I would guess that any delay in response time due to downlink / uplink of data to / from the ground station would be a bad thing in trying to fly an airplane. So a ground based autopilot probably wouldn't work. For other applications where immediate response isn't as critical (like mine) this project may very well work for that. Take a look at "RoboRealm" ( http://www.roborealm.com/ ) and some of the autonomous projects created using it. Once I get things running manually, I plan on using RoboRealm to experiment with more autonomous methods of navigation.

[Gary Mortimer]

I think Rich mentioned it earlier gobig

[rich smith]

The Sparkfun unit has 500ma regulator intentionally unlabeled in the schematic. The 150ma spec is what's left over after XBee Pro is plugged in. Somewhat more with the low power XBee as mentioned in the docs.

IMO the Adafruit is not worth $10 for nothing more than a regulator.

FWIW, the Sparkfun USB Explorer does have a 3.3V regulator. They don't mention it, but take a look at the schematic. I don't recall the chip number, but the current rating was only "guaranteed" to be 150 ma, though I'm running the 900 Pro XBee modules with no problem.

Thanks for the tip on the adafruit unit. If you already have an FTDI adapter (and who doesn't), that would have been a better way to go.

Cheers,
Rusty

[rich smith]

@Gary - My application isn't for RC aircraft, but I would guess that any delay in response time due to downlink / uplink of data to / from the ground station would be a bad thing in trying to fly an airplane. So a ground based autopilot probably wouldn't work. For other applications where immediate response isn't as critical (like mine) this project may very well work for that.

Actually the XBee delay is virtually zero. Certainly negligible compared to the 20ms frame time of a 72mhz RC TX/RX. The multi character protocol of the SSC03 might cause trouble so watch out for that.

LOL! Didn't quite get Garys joke til I clicked on the list of countries.

[Gary Mortimer]

Little off topic but I reckon this is the place to ask!!

Right I was in PCworld today and looked at all the USB hubs, all the cheap webcams and decided what I wanted was a wireless USB hub that would allow me to connect several cameras and let me see them at a distance.

I know these things act an RS232 link, what chance a USB hub, I'm guessing not enough bandwidth.

Plug and play long distance USB2.0 would be a charm.

[13brv3]

The Sparkfun unit has 500ma regulator intentionally unlabeled in the schematic. The 150ma spec is what's left over after XBee Pro is plugged in. Somewhat more with the low power XBee as mentioned in the docs.

The regulators on the Sparkfun boards I have are marked "KB33", and are shown on this data sheet- http://www.micrel.com/_PDF/mic5205.pdf The spec sure looks like 150 ma to me, which is pretty marginal if the XBee Pro is pulling 180 ma typical as they claim. So far, it's working flawlessly though.

Cheers,
Rusty

[Tomapowa]

Actually the XBee delay is virtually zero. Certainly negligible compared to the 20ms frame time of a 72mhz RC TX/RX.

The Digi Xtend modems have an advertised latency (not incl hoping freq which is not advertised) of 9.4ms (best case!). I can not see how the Xbee pro modules are better than this (maybe you have that spec for the Pro module). And 9.4ms assumes you are transmitting at the highest baud, not including retransmits, etc... due to interference & multi-path issues. I have flown many UAVs directly via Digi Xtend modems (never mind the lower-power Xbee Pro modules) and you can in fact feel the latency. Couple this latency with other built-in latencies (i.e. PC computing, serial servo controllers, etc...)... and it gets real noticeable. :eek:

[kaldak]

Hm, I hadn't really though of latency as a problem. If there's no way it's going to match the feel of R/C radios then... I'm not sure there's really much point in it

[rich smith]

This thread is primarily for XBee technology so Xtend modules are a bit OT. Kind of silly to hang hundereds of dollars in RF gear off a $1 servo controller. In any case your 9ms is still less than the delay of standard RC TX/RX so apparently you are hard to please. (but then I knew that from before :) )

Just checked a couple 2.4ghz and 900mhz XBee modules again and latency out of the box is in the order of 3ms. I think this can be improved upon with API tricks but I prefer to keep life simple. Fast enough for normal human reflexes and as mentioned before virtually instantaneous compared to RC gear. See pic below.

The Digi Xtend modems have an advertised latency (not incl hoping freq which is not advertised) of 9.4ms (best case!). I can not see how the Xbee pro modules are better than this (maybe you have that spec for the Pro module). And 9.4ms assumes you are transmitting at the highest baud, not including retransmits, etc... due to interference & multi-path issues. I have flown many UAVs directly via Digi Xtend modems (never mind the lower-power Xbee Pro modules) and you can in fact feel the latency. Couple this latency with other built-in latencies (i.e. PC computing, serial servo controllers, etc...)... and it gets real noticeable. :eek:

[jppizhere]

Great thread, I have been working on something along these lines for a while. Currently I am using pretty simple visual basic program to read a usb joystick and give an on screen display of joystick position. The joystick I have is elevator/ailron with twist rudder, throttle, and 15 buttons. I have it set up so certain buttons will act as a trim for certain channels. The joystick data is in a range on 0-255 so it is converted to a 75 thru 225 range so the microcontroller used later doesnt need to do any of the processing to get the proper numbers to output to the servos (rc servo pulses are typically listed as 100ms - 200ms but you can push to 75 or 225 with trim). I am basically reading only three channels from the joystick and after conversion I send a stream containing three numbers out via serial conncetion.

Currently the serial connection is to a Picaxe (4800 baud), however the picaxe is pretty limited in how many servos one can drive as well as speed (right now it can reasonably control three), you can actually cheat some and just use pulsout as long as you are not horribly worried about frame rate and it more of a proof of concept thing instead of a working product anyways. The picaxe receives three numbers and uses those numbers in turn as the pulse length in to drive a pulse in three pins..

serin 0,N4800,#b0,#b1,#b2
pulsout 1,b0
pulsout 2,b2
pulsout 0, b1

Basically my system started out as intending to control an rc device via pc joystick, the radios I have currently are sadly lacking in documentation so sadly I have been unable to make them work, but it looks like with a couple of xbees and this thread I may be able to get this up and working.

If anyone is intrested I will happily give out all visual basic code I have written for this project.

[kaldak]

Just checked a couple 2.4ghz and 900mhz XBee modules again and latency out of the box is in the order of 3ms. I think this can be improved upon with API tricks but I prefer to keep life simple. Fast enough for normal human reflexes and as mentioned before virtually instantaneous compared to RC gear. See pic below.

Ah, excellent! That makes me feel better. :)

Any thoughts on whether 900mhz or 2.4ghz is better for this application? 900mhz seems to get better range...and perhaps less interference from wifi, normal R/C hardware, etc. But there may be downsides I havent thought of.

[Tomapowa]

...Just checked a couple 2.4ghz and 900mhz XBee modules again and latency out of the box is in the order of 3ms....

3ms?? Hmmm...I bet you tested this with the transceivers side by side. Try this same test at a distance equal to your flying distance and you'll see latency increase exponentially, especially if you use cheap 3db antennas. Also, be sure to average the latency over time... it changes... maybe not so much when on your workbench in a controlled environment.

Rich, have to ever really flown an aircraft directly using Xbee modules?? I have and can speak from experience. What type of RSSI are you getting at flying distances? I guess as long as you are flying a cheap-o foam airplane with that $1 servo controller, you have nothing to lose when it crashes. I just don't want some here to think they can (or should) use such a system on expensive models.

[Tomapowa]

The joystick data is in a range on 0-255 so it is converted to a 75 thru 225 range so the microcontroller used later doesnt need to do any of the processing to get the proper numbers to output to the servos (rc servo pulses are typically listed as 100ms - 200ms but you can push to 75 or 225 with trim).
RC servo pulse are typically spec'd at 1-2ms, not 100ms-200ms as you mentioned... simple mistake.

Those #'s you mentioned, 100 & 200, are what the Picaxe uses for servo or pulsout controls, and are of 10us resolution, hence they really are 100x10us or 1ms, and 200x10us or 2ms respectively.

[kaldak]

Rich, have to ever really flown an aircraft directly using Xbee modules?? I have and can speak from experience.
Have you? You mentioned flying with the Digi Xtend previously, but not actually an Xbee. Latency will no doubt increase with distance, but it's starting out 3x better than the Xtend spec (probably a best case scenario). If the Xtend is at least servicable as a remote, that could put the Xbee in pretty good shape.

That said, Xbee does seem to have some overhead to it. I've been digging a bit into Cypress radios and they seem to provide a simpler, more direct connection. Could prove speedier. Unfortunately they seem much less common in the DIY community. Not looking forward to getting one talking to an arduino from scratch...

Xbee still seems like the most direct solution if I can tweak the settings to make latency acceptable at range. Seems like some people have had luck with this, but I have yet to find many details.

[Tomapowa]

Have you? You mentioned flying with the Digi Xtend previously, but not actually an Xbee. Latency will no doubt increase with distance, but it's starting out 3x better than the Xtend spec (probably a best case scenario).
Yes, we've used/tested almost all Maxstream/Digi products including all the Xbees (and most Aerocomm products.. stay away from them,... serious latency) and decided on the Xtends (for range/performance mainly). I still have doubts about that 3ms latency... sounds low... probably not an ideal test setup either. Understand though that the processing of the data via microcontroller and other circuitry adds additional latency. Picaxes (and PIC themselves) will certainly increase that latency. For instance, The following code snippet takes 0.9ms to execute on a PICAXE-18 running at 4MHz ...

Loop:
pins = pins ^ $FF
GOTO Loop

Latency adds up quick...

I've been digging a bit into Cypress radios and they seem to provide a simpler, more direct connection. Could prove speedier.
Ah... isn't that what Spektrum uses? :rolleyes:
Here's an interesting DIY Cypress project:
http://www.rcgroups.com/forums/showthread.php?t=971053

Seems like some people have had luck with this, but I have yet to find many details.
All I can tell you is from past experience, I did not have such good luck...

[rich smith]

Hey, what ISN'T off topic. I don't really don't mind though (just giving my old buddy Tomapowa a hard time). :)

Actually bandwidth is not an issue at all. I stream DVD with those all the time. The reall issue is distance. At least the ones I played with were extremely limited. Few yards at best.

Bridges and extenders are a different story. I know a fellow who regularly picks up WiFi 45 miles away in Boston using el cheapo FTA sat dish. I'm playing with the same setup for the XBees but haven't got THAT far yet.


Little off topic but I reckon this is the place to ask!!

Right I was in PCworld today and looked at all the USB hubs, all the cheap webcams and decided what I wanted was a wireless USB hub that would allow me to connect several cameras and let me see them at a distance.

I know these things act an RS232 link, what chance a USB hub, I'm guessing not enough bandwidth.

Plug and play long distance USB2.0 would be a charm.

[rich smith]

Rusty, go through those datasheets one more time. The 150ma spec is to guarantee a certain drop out and is not the actual max for that part. Further on they describe the actual shutdown current as 500ma. More than enough for XBees (which draw closer to 300ma than 180ma). We assume reasonable copper like in the Sparkfun unit to avoid thermal shutdown which explains why they actually work.

The regulators on the Sparkfun boards I have are marked "KB33", and are shown on this data sheet- http://www.micrel.com/_PDF/mic5205.pdf The spec sure looks like 150 ma to me, which is pretty marginal if the XBee Pro is pulling 180 ma typical as they claim. So far, it's working flawlessly though.

Cheers,
Rusty

[rich smith]

I think it would be very helplful for you to put up a VB program. PC software is a huge time consumer and MS dev is a resource hog for me. ATM I use Windows XP built-in terminal for flying the XBee plane to avoid that sticky wicket. Also use it to capture NMEA strings for my autopilot and Xbee/GPS tracker projects.

Looks like your project is ready to go, just replace the wire with XBee. Maybe switch to cheapie AVR at some point. Not so much due to speed issues because Picaxe can be programmed in asm (I got 6 chan no problem) but more because Tiny is so much lower cost than Picaxe. You've already done the hard part and should be easy to port.

Great thread, I have been working on something along these lines for a while. Currently I am using pretty simple visual basic program to read a usb joystick and give an on screen display of joystick position. The joystick I have is elevator/ailron with twist rudder, throttle, and 15 buttons. I have it set up so certain buttons will act as a trim for certain channels. The joystick data is in a range on 0-255 so it is converted to a 75 thru 225 range so the microcontroller used later doesnt need to do any of the processing to get the proper numbers to output to the servos (rc servo pulses are typically listed as 100ms - 200ms but you can push to 75 or 225 with trim). I am basically reading only three channels from the joystick and after conversion I send a stream containing three numbers out via serial conncetion.

Currently the serial connection is to a Picaxe (4800 baud), however the picaxe is pretty limited in how many servos one can drive as well as speed (right now it can reasonably control three), you can actually cheat some and just use pulsout as long as you are not horribly worried about frame rate and it more of a proof of concept thing instead of a working product anyways. The picaxe receives three numbers and uses those numbers in turn as the pulse length in to drive a pulse in three pins..

serin 0,N4800,#b0,#b1,#b2
pulsout 1,b0
pulsout 2,b2
pulsout 0, b1

Basically my system started out as intending to control an rc device via pc joystick, the radios I have currently are sadly lacking in documentation so sadly I have been unable to make them work, but it looks like with a couple of xbees and this thread I may be able to get this up and working.

If anyone is intrested I will happily give out all visual basic code I have written for this project.

[rich smith]

Any thoughts on whether 900mhz or 2.4ghz is better for this application? 900mhz seems to get better range...and perhaps less interference from wifi, normal R/C hardware, etc. But there may be downsides I havent thought of.

Having played with both recently I can say 900mhz is significantly better for this application. Particularly when the plane goes out of sight behind trees. 2.4ghz has the advantage of smaller antenna which helps when carrying the system on a bike like I do. My 2.4ghz patch is about 1/3 the size.

Generally the lower the frequency the better which explains why 72mhz TX/RX beats the crap out of 2.4ghz in terms of range. Too bad they don't make 72mhz XBee. But then we wouldn't have these nice little 2" antennas.

[rich smith]

You'd win the bet! They were only few inches apart. And you are right about signal attenuation. However the latency does not increase anywhere near as bad as you make out. At least in my experience. I suspect it's more related to channel saturation and you might be using far more bandwidth than my simple one character commands. The plane has the default 3" wire but on the ground a 24db patch may account for my excellent range and minimum delay. (lets' not get into that power distribution argument again :) )

As far as losing planes I strongly recommend the XBee/GPS tracker and IMO it's foolish to play with autopilots or PC control w/o getting this running first. Haven't lost a plane in several hundred hours of flight since. Basically just tack on an EM406 to DI pin instead of tying it to DO.

And you are right about the foamies too. They don't fly away anymore but do in fact crash a lot. Unlike $5k-10k UAVs my $5 mid-slot design tends to bounce and don't even damage motor, prop, battery, or electronics. Ironic that the super expensive airframes are the most fragile. KISS (and cheap) is my moto.

3ms?? Hmmm...I bet you tested this with the transceivers side by side. Try this same test at a distance equal to your flying distance and you'll see latency increase exponentially, especially if you use cheap 3db antennas. Also, be sure to average the latency over time... it changes... maybe not so much when on your workbench in a controlled environment.

Rich, have to ever really flown an aircraft directly using Xbee modules?? I have and can speak from experience. What type of RSSI are you getting at flying distances? I guess as long as you are flying a cheap-o foam airplane with that $1 servo controller, you have nothing to lose when it crashes. I just don't want some here to think they can (or should) use such a system on expensive models.

[gobigkahuna]

Comments regarding latency and bandwidth lead me to ask this question: What would be the maximum latency (milliseconds) and minimum throughput (baud rate) that would still result in "natural" feeling controls (assuming a serial servo controller like this: http://www.pololu.com/catalog/product/207 were used)?

[kaldak]

Comments regarding latency and bandwidth lead me to ask this question: What would be the maximum latency (milliseconds) and minimum throughput (baud rate) that would still result in "natural" feeling controls (assuming a serial servo controller like this: http://www.pololu.com/catalog/product/207 were used)?
Well at least with old-school 72Mhz stuff, servos only get updated every 20ms. So...I suspect if you can keep your total latency below that it should be quite comfortable.

And assuming you want 8 bits per channel, 6 channels, updated 50 times per sec that would be 2400bps. Of course that's the actual throughput rate you need for your data. There will be overhead.

[rich smith]

What would be the maximum latency (milliseconds) and minimum throughput (baud rate) that would still result in "natural" feeling controls?

Like with GPS rates and servo resolution most hobbyists seriously overestimate what is required. It's somewhat dependent on the plane. I found with the 48" foamie that 400ms delay was more than adequate but the "frisky" delta 100ms felt better. Standard 20ms RC rate is way faster than most humans need.

FYI minimum time is determined by servo frame limit which can't drop much below 5ms.

[jppizhere]

RC servo pulse are typically spec'd at 1-2ms, not 100ms-200ms as you mentioned... simple mistake.

Those #'s you mentioned, 100 & 200, are what the Picaxe uses for servo or pulsout controls, and are of 10us resolution, hence they really are 100x10us or 1ms, and 200x10us or 2ms respectively.


Thanks for the correction Tomapowa, yeah I was looking at the code from what was going to the picaxe, not what it was actually generating.

[jppizhere]

I think it would be very helplful for you to put up a VB program. PC software is a huge time consumer and MS dev is a resource hog for me. ATM I use Windows XP built-in terminal for flying the XBee plane to avoid that sticky wicket. Also use it to capture NMEA strings for my Xbee/GPS project.

Looks like your project is ready to go, just replace the wire with XBee. Maybe switch to cheapie AVR at some point. Not so much due to speed issues because Picaxe can be programmed in asm (I got 6 chan no problem) but more because Tiny is so much lower cost than Picaxe. You've already done the hard part and should be easy to port.


The code is pretty rough, is functional but not totally pretty...I use a usb to serial adapter for a serial port and the program expects it to be in the same port every time (com 4 as it is currently written), as well as being written to work with the joystick I have no idea whether it will owrk with others. I have not yet figured out how to make it autodetect the proper port so you may have to mess with the port numbers or something to get it working.

[Tomapowa]

The code is pretty rough, is functional but not totally pretty...I use a usb to serial adapter for a serial port and the program expects it to be in the same port every time (com 4 as it is currently written), as well as being written to work with the joystick I have no idea whether it will owrk with others. I have not yet figured out how to make it autodetect the proper port so you may have to mess with the port numbers or something to get it working.

Lots missing in order to recompile/attempt to run... like assumed DLLs and especially (more importantly) the "joystick.frm" file/form...

[jppizhere]

Lots missing in order to recompile/attempt to run... like assumed DLLs and especially (more importantly) the "joystick.frm" file/form...
Oh, yeah the Form file might be helpful. Lets try that one again.

All of the embedded DLLs should be standard VB stuff.

[rich smith]

Oh, yeah the Form file might be helpful. Lets try that one again. All of the embedded DLLs should be standard VB stuff.

Thanks for supplying that code. I'm sure it will help jumpstart many who want to develop the PC end of RC control projects.

Putting up software ain't as easy as it seems sometimes. :) Good thing we got guys like Tomapowa here to keep us on the straight and narrow. I got a little hint that helps too. Use a different file name when supplying another version. Prevents file confusion on later downloads. Couple friends of mine nearly abandoned a recent internet autopilot project because of document control problems.

I wouldn't worry about com port numbers. It's so easy to reassign those in Windows IMO not even worth making it an option. One thing that might help is providing some executables and runtime modules for those of us who are unable to recompile due to resource or other issues. In any case it's greatly appreciated that you took time to share. Thanks again.

[rich smith]

New hex has been uploaded to post #1 for 4800bps instead of 9600bps. This allows optional connection of DI to a GPS for plane tracking. Plane XBee must be configured for the new baud via at commands below. EE location 0 still holds OSCCAL value but now factory default is used if 0xFF (never programmed).

Old files moved here in case anybody needs it.

[rich smith]

In addition a change has been suggested to the schematic for easier plug in of an EM406 or other GPS. Connecting DI to the channel 4 pins allows those to be used for a GPS if one is plugged. This means there is no echo now so if you want that feature or add code for channel 4 then use the old schematic.

Old files moved to post #64.

[gobigkahuna]

So am I reading your schematic correctly, "di" from the XBee now goes through a 1Kohm resistor to the signal out of the GPS? Very interesting. I might be able to use this to share the serial "line" with a digital compass that sends ASCII through the serial port with the servo controls... cool! :)

[rich smith]

So am I reading your schematic correctly, "di" from the XBee now goes through a 1Kohm resistor to the signal out of the GPS? Very interesting. I might be able to use this to share the serial "line" with a digital compass that sends ASCII through the serial port with the servo controls... cool! :)

Exactly. I also used a compass at one time and should be no problem hooking one up to the XBee. Your robo program will read that? Also check signal polarity as some are idle low which requires original hex. Personally I switched to lighter cheaper more accurate GPS for direction.

Note that newest schematic allows either channel 4 or GPS on the same circuit w/o hardware change.

[gobigkahuna]

Your robo program will read that?
It should. I was using RoboRealm (which works great BTW) but may write my own app in RealBasic instead. I'd like to use this compass (https://www.silabs.com/products/mcu/Pages/DigitalCompassRD.aspx) which has a USB interface so I'd have to find some way to getting it to talk to serial instead. My robot will be underwater, so a GPS won't work. I'm actually surprised that RC FPV pilots would use a GPS for compass heading anyways, the delay in displaying compass headings is several seconds at best.