I have quite a few zigbee modules of various powers. I've used them for serial communication of environmental data and found them perfect for that. I am looking to do some sort of UAVS but I am loath to spend hundreds of Euro on a decent radio system when I have the zigbee modules.

I wonder has anyone built a full RC system for an aircraft using zigbee for comms. Components of the system would be
airborne zigbee, arduino, servos
ground zigbee, computer , software, joystick, mouse or keyboard for controller

The advantage is that no RC radio or receiver would be required, saving cost and weight, while extending range but of course the disadvantage is potential unreliability.

Views: 14027

Reply to This

Replies to This Discussion

You loath to spend hundreds and want to do it by ourself?
The reason agains xbee is latency, and when you include range CRC checking etc, it will be also bandwith.
Actually they are Xbees from Maxstream not zigbee.

The thing is that I will be using the xbee for telemtry and remote updates of flight info. If I am doing that I would like to see if I can bypass the RC requirement.

How long would the latency be? Testing on the bench suggests pretty instantaneous transmission of push button events. I'll see if I can set up a desktop program to send out data with a timestamp and get the remote ardiono to reply. The maxstram dev kit comes with an echo test so maybe I'll try that.

The reason I asked is because I couldn't find any link to such a project. I was wondering what the protocol would be. These guys have a serial to servo unit. http://www.pololu.com/catalog/product/208 . A simple implementation would be just that board and an airborne zigbee with no arduino.
I'm also planning on building an xbee-only airborne platform next summer, with everything on a single line, incl. command uplink, telemetry and photo/video downlink. I've done a couple of trials (basically running about with an arduino that sends back 1 kB buffers it receives from a groundstation) and found out that a pair of 2 mW XBee Pro modules can maintain about 5 KB/s with decent latency (<200 ms) over 100 m (300 ft) LOS. I'm planning on using stronger ones, maybe 60 mW ones, and those are supposed to have a range over 1 km.
Sounds good, although I think photos and video might be too much for the xbees. I think there would have to be some sort of priority given to the RC. Maybe 200 ms might be too much for effective RC control. However, since this is meant to a semi automated aircraft, may that is enough. I'd be interested in Chris's and Jordi's experience on the RC link and how much it is used after takeoff and landing. How frequently are the controls changed on an RC transmitter, 4 or 5 times per second. That would be feasible on a xbee link and still have room left over for telemetry.
Jack Crossfire has done some testing with them for applications like this. Latency and reliability were indeed issues. See his comments here, for example.
Personally I would advise against using the pololu product for this application. I bought the exact same model when I set out to do a similar project and found out that the unit has been designed to lockup and need a hardware reset in the event of any incorrect serial data which is likely to happen at some point when using wireless products. This will certainly be a problem for an rc plane and I don't remember them mentioning this on the website. The only solution I found at the time was to build my own which simply ignored anything that wasn't valid servo data. I tend to get the plane in the air using a standard receiver then switch to Xbee and reverse for landing, latency doesn't seem to be a problem for gentle flight. GCS transmits 5 single byte servo positions every 100ms.
Hi James

Was that a single byte per servo? Have you any idea how much extra stuff the xbee adds to the packet for addressing, etc

Did you include a downlink for telemetry.

Hi Diarmuid,
yes it was single byte per servo, I'm not sure just how much extra is added to the packets but you can reduce it by switching off error checking and packet resends etc.. I do use telemetry which is sent every 400 or 500ms as long as nothing is being sent to the servo's (I started with an lprs radio so had to include this option). the Telemetry is 37 bytes long and includes stripped down gps, accelerometer and battery voltage.
Did you always send all the values for all servos all the time or did you only send when a value changed.

For instance, the throttle servo, was that always sent as it would not change so much.

Originally I thought only sending changed values would be a good idea then as I started testing it became a bad one because if a changed value wasn't received correctly then the servo would not be actioned until another change happened. For this reason I now send all 5 values.
I am in the middle of building that type of configuration at the moment.
Took a 3 axis joystick with throttle and ran the voltages from the internal potentiometers into a PIC16F690.
The PIC takes the joystick and trim and converts to hex.
PIC uart to XBEE900 in transparent mode.

On the RC plane I have another XBEE900 receiving in transparent mode.
The serial from the XBEE goes to the Pololu servo controller.(Mini SSC II mode)

At the moment motor and servos can be controlled .
Have got some electrical noise(motor ,servos) at the moment which sends the Pololu in the error state on occasions.It will not recovery by itself so have to reboot it.
This locks up the Pololu servo controller
Joe, I have some code for a PIC16F628A which does a similar job as the pololu but without locking up (watchdog timer enable just in case). only thing is though is uses a different command set and only has 16 positions per servo. it was originally written by someone for a 16F887. If you want to try it I can send you the source and hex.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service