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 beairborne zigbee, arduino, servosground zigbee, computer , software, joystick, mouse or keyboard for controllerThe 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.
You need to be a member of diydrones to add comments!
Hey any way your drone design could.maybe possably go into a hover or short range glide mode while awaiting for the latency to catch up.or your not designed to hover like copter??
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.
Jack Crossfire has done some testing with them for applications like this. Latency and reliability were indeed issues. See his comments here, for example.
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.
Replies
The reason agains xbee is latency, and when you include range CRC checking etc, it will be also bandwith.