Intelligent Multirotor communication system

I'm building an arduino multirotor that will have GPS compatibility, and be able to navigate to coordinates 100% autonomously, but also have a manual control capabilities.

Here is a theoretical operation scenario of the drone:

  1. Power it up
  2. Fly it around manually, or plot an autonomous flight plan
  3. Send it off, and at this point the autopilot takes over
  4. As it reaches it's destination, it could either land, or hover, or proceed to return to its point of origin, depending on the pre-programmed flight plan.
  5. However as it flies, it should be intermittently listening for any incoming transmissions from the controller. That way the manual controller will be able to take over control from the autopilot the moment the drone is within range.

My main issue is:
What type of communication should I use for this? Hack a radio control unit? WiFi Xbees? Are there other Xbees that could be used for this kind of range?
I'm looking at significant range. like at bare minimum 300m, but upwards of 750m would be great. This is all outdoors.

Price is a factor. I'm trying to keep costs down.
Battery life is also a factor. I believe Xbees eat up alot of power, so I you suggest Xbees, any knowledge on how to have them sleeping on a lower power state most of the time to save battery would be great.


use a n rc airplane control system use an extra servo channel to engage/disengage the autopilot

There is a lot to be said for this - proven wireless technology.

You could use the Arduino to capture the RC data and do what you want with it on the plane.

You may be able to use an Arduino on the ground to input "data" to the RC transmitter. I have in mind that the extra channel could be used to send "data" for the onboard Arduino.

These Deltang devices work with standard Spectrum RC transmitters and can be programmed as Arduino devices. I don't know anything about range but an email to DavidT who makes them should get a quick answer. I use them for model trains but they are also used in aircraft.


I agree with Greensprings.

There are lots of projects around that do exactly what you want for example

Or the multi-wii based on Arduino and a wii controller (which is just an accellerometer)

There is not much point in being concerned with the current draw of the controller as your motors will be using 10 Amps or more

Thanks all for the advice

You’re absolutely right, in that projects almost identical to mine already exist, but I’m making this project not as a means to an end, but the goal in itself is to build my own for learning experience and the programming freedom it gives me. If I write my own code for it, the possibilities are endless! I could have it delivering parcels, dropping leaflets. Heck, I could make it a VTOL aircraft.

About the motors, they draw about 25Amps each, but I still think that if the multirotor spends 10% of its time actually receiving data and the rest of it on autopilot, a receiver sleep state would be very beneficial for flight time.

Getting data from a servo input now THERE’S a great idea (thank you). I’ll look into that, but i presume rc recievers only output the data in servo output, which would be sending pulses of varying widths, as opposed to binary data (not PWM btw). I guess I could try to build communication code based purely on the pulseIn() arduino function but I fear that it isn’t accurate enough. And RC Transmitter/receivers arent cheap at all. (I dont live anywhere near the US or the UK so that limits my choice quite a bit.)

I happen to have some low power xbees i could another project so I think I will try that before buying an entire RC transmitter system for the solution you three posited.

Also to Robin2 specifically, those Deltang things would be perfect, except it would take a long time to ship it over (assuming they ship).

So I’m mostly sorted out for now, thank you.

The only bit of information I could use would be: what are the advantages of xbees. They are completely programmable themselves are they not? I’ve only ever used them as mediums for primitive point to point serial communication.


You're on about step 100 but haven't yet completed all the previous steps. Whatever you use to is going to use a miniscule amount of power compared to the motors, any sort of sleep isn't going to be required. On top of that you can't sleep. You're going to need a PID control loop just to keep a multirotor in the air, before you even start looking at user input or autonomous flight. A PID loop is a fairly complex piece of math code and it will need tuning to fly with your particular setup. You're also going to need a gyro and an accelerometer before anything else

If you want a manual control option you're going to need to use an existing RC technology. Other hobby type radios will have too much packet loss or too high latency (or both), however that actually makes life easier. You'll need a secondary link to program the autonomous side of things but some simple HopeRF modules at whatever frequency is legal in your country can solve that.

For actual manual control I would suggest trying to find some RC gear that can output CPPM or SBUS. There is code out there in other projects to read these signals and it means one wire from the receiver rather than 4-8 wires.

Once you have manual control sorted with self leveling and reliable altitude control then you can look at autonomous modes. you do need to be aware that this isn't a simple project and will take a significant amount of time to do. You also need to be aware that a multirotor will do a frightening amount of damage to a human that gets in the way.

I'd recommend you look at existing controllers and buy one of those, even if only so you can get a piece of hardware with all the sensors already attached and known to be working. You can easily wipe it and upload your own code for almost all of them, multiwii boards are arduino based anyway

Okay, thanks. I'll go look into that.

You are absolutely correct in that I'm thinking ahead, but dont assume I've skipped ALL the steps haha

The PID software is done already. I wrote code based off a PID Library which you can find on the arduino website. It saved me alot of effort, but I have not tuned the Kp, Ki,Kd, so that will take a while. I've already done programming for the gyro and accelerometer. Furthermore I'm using a couple moving average filters to stream out the sensor noise a little bit. I'm using an ultrasound sensor pointing down for low altitude flight (if I ever need to fly within 4m from the ground over a surface ultrasound waves will rebound off).

and i was referring to the xBee sleep mode (if in a fit of madness i went ahead and disregarded all the good advice i got earlier about not using an xbee), not the flight controller of course. That would be stupid.

I truly appreciate your concern and I will rethink my safety measures because of your warning
Nevertheless, I think I can handle this. My question was pertaining to the method of communication anyway.

HopeRF modules, SBUS, CPPM. I will go look those up immediately. Thanks for the pointer!


Wow, you're certainly on your way then :slight_smile:

I'm not aware of anyone in the Multirotor community that has got acceptable performance from downward facing sonar. The typical problems are very poor results as the ground changes, for example flying over a solid surface gives good results, but when you're over uneven dirt or grass your results are worthless.

Even sleeping xbee's won't make any read difference to power usage but if you do keep using them you'll want to use their highest power setting and the lowest data rate to get the range up. You don't need the link to have a high speed, you need it to have a low latency which is where it'll typically fail

You may want to ignore that for now, but if you do want to play with something along those lines having a down looking low resolution camera is a very good way to do position hold.

You've probably found the radio stuff now but if not something like this for a telemetry link, they come in 915 and 433Mhz, you'll need to get the right one for your country as typically only one of those bands is available unlicensed.

Typically CPPM capable receivers will be cheaper, but SBUS is a much nicer protocol in that's it's a digital serial data stream, not just pulses. The cheapest SBUS setup I've found is this however you still need a radio with a JR socket for the TX module

I'm not sure how your testing will happen but you may want to look at geting a large reel of something like fishing line. Even existing flight controllers have been known (some with alarming regularity) to fly off into the sunset and never be found again. A GPS is not a 100% full-proof and it's probably worth doing some comparisons from one reading to the next and if they are more than say... 50m apart then fall into some failsafe mode