<p>I started out in this hobby almost exactly the same way, as a programmer who wanted to get into flight code for multicopters and autonomous planes. And while I've yet to launch a fully autonomous aircraft with my own code at the proverbial stick, within my year or so researching the topic hands-on, I have accumulated some useful knowledge which I'm going to share here.</p>

<h2>First, you'll probably need to become intimately familiar with all the hardware that comprises a drone.</h2>

<p>If you want to do anything seriously interesting with it, anyway.</p>

<p>There <em>do</em> exist some integrated programmable drones that abstract the hardware part away and let you code basic flight routes, but they're limited by that same abstraction to the most basic maneuvering. This, as many consumer drone owners can attest, is rather boring unless you have a specific application in mind. And specific applications (apart from filming/photography, which are usually automated enough in commercial camera drones out of the box anyway) usually require something more than just a drone with a camera.</p>

<p>Of course, you might be content with that. You might want to simply play with it in your living room or backyard, which is perfectly fine, and in this case a prefab proprietary drone like the Tello might suit you well, especially if you're only going to use it as a stepping stone/demo version before diving into the "real thing" (or not). As a disclaimer, I haven't researched this one in particular, but I'd bet it has all the characteristics of a proprietary product: highly refined, but also sealed, with its own API/ecosystem, and capable of some particular subset of possible flight modes that the developers thought safe/proper. Which is okay if you're using this as a tool for learning programming and/or general robotics, but this will slow one down once one starts to get into anything advanced. Besides, if you decide to move on from one of these to something else, you won't be able to take any of your code along: it will certainly be incompatible with anything not of that manufacturer.</p>

<p>The alternative is to roll your own: buy all the components either separately or as a kit and build a drone for yourself (or buy a prebuilt kit, which is very distinct from buying a commercially manufactured drone). This has all the characteristic advantages and drawbacks of open source: On the plus side, it's highly customizable and extendable, often has the most cutting edge tech, open standards, portability of code, etc. Most importantly for this application, it allows interoperability with about any kind of peripheral you can think of (provided that this peripheral can talk via one of the standard protocols, e.g. SPI/I²C/RS232/OneWire/etc, though you probably could hack in support for proprietary protocols as well if you really wanted). All of that is balanced by around zero customer support: No one's there to hold your hand, and any issues you might experience you'll have to troubleshoot on your own, maybe with the help of knowledgeable friends... or internet strangers like ourselves. Given that you're already a software engineer, you're probably doing it all the time anyway, however.</p>

<h2>Second: There's only a few scriptable autopilots.</h2>

<p>I'm going to cover the open source ones for the most part, as for the reasons outlined above I was never particularly interested in the proprietary variety. Also, I'm talking about high-level flight code, e.g. code that defines complex behavior <em>on top of some other flight control software, which in turn provides at least basic stabilization and primitive maneuvering</em>. If you want to dabble in low-level stabilization code that works directly with bare metal, you can just fork any flight control project or even write your own.</p>

<p>So, a rundown of all the options in order of increasing complexity:</p>

<ul>
<li>Most flight control software has varying degrees of inbuilt flight behavior automation such as takeoff, landing, position hold/loiter, return to home, and waypoint missions.</li>
<li>The latter represents the most basic form of programming: you set up a flight route consisting of waypoints, possibly with other modes thrown in (e.g. takeoff, go to waypoint A, then B, loiter there for 10 minutes, go home, land). This <em>mission</em> is then uploaded to the drone and off it goes. This, as far as I know, does not support conditionals or other control structures, so is not turing-complete.</li>
<li><p>For more complex high-level flight control, there's a widely-supported protocol called <a href="https://mavlink.io" rel="nofollow noreferrer">MAVLink</a>. It allows for a device external to the flight controller to query flight parameters and issue commands via a UART connection. This is the protocol that's usually used by ground station software (through which you define the waypoint missions mentioned above and otherwise remotely control your craft's behavior). </p>

<p>MAVLink is supported by most flight control software suites, and is very bulletproof by the standards of this currently highly experimental field. The data and commands available via the protocol range from the highest inbuilt abstraction level (e.g. add waypoints or change flight modes and set their parameters) to almost the lowest (e.g. query exact attitude, read data from gyros or other peripherals, set rotation rates), and the set can be extended arbitrarily. The only caveat is that it's only a communication protocol/API, so you'll need some kind of external computing device, either onboard or remote, to provide the actual logic. </p>

<p>This "physically external logic" approach is probably the most approachable option for a regular programmer, since you can run your flight code on your laptop in any language you like, controlling the craft remotely via a telemetry link (which is basically a pair of transponders, one of which plugs into USB and the other into the flight controller's UART, providing a bidirectional serial connection over radio). If you do so, mind the latency and link health: it might restrict you to higher-level control. If you find yourself needing more fine-grained control, you can move the code to an onboard computer (e.g. raspberry pi) connected to the flight controller directly, getting rid of the radio link and retaining the familiar Unix-y operating environment.</p>

<p>The MSP protocol mentioned in the other reply falls, as far as I can tell, into the same category, but is somewhat more specific. That's perfectly fine, though; use whatever works for you.</p></li>
<li>Finally, there's the option of <em>onboard scripting</em>, defined as user code that runs on the flight controller hardware together with (or, rather, <em>on top of</em>) the basic flight control software itself, and makes use of the latter's capabilities. This allows one to code custom flight logic without modifying the code of the autopilot itself, yet have both high-level control of the autopilot's automation features, and fine-grained low-level access to the craft's hardware with about the lowest possible latency. The approach comes with some operating restrictions, however, since you'll have to work within a real-time operating environment and with very limited resources. Also, there's only a small selection of autopilots which support such scripting, at least ones that I know of, and all of those are thanks to <a href="https://drones.stackexchange.com/questions/688">a question</a> I asked earlier on this very site. Here's a summary of the contents:

<ul>
<li>Ardupilot <a href="https://ardupilot.org/copter/docs/common-lua-scripts.html" rel="nofollow noreferrer">supports onboard Lua scripting</a> in its Copter/Rover variants since v4.0 and in Plane since v3.11. As of right now, this seems the most "lightweight-yet-powerful" option and thus most promising for my use case.</li>
<li><a href="https://rosflight.org/" rel="nofollow noreferrer">ROSflight</a> has been suggested, which is an autopilot package running on top of the Robot Operating System, all of which is apparently highly modular and allows you to add (or replace) any part of the flight code independently. See the <a href="https://drones.stackexchange.com/a/895/272">relevant answer</a> for more details.</li>
<li>Finally, this comment by <a href="https://drones.stackexchange.com/users/46/kenn-sebesta">Kenn Sebesta</a>: <em>Tau Labs supports picoC and full flight scripting. It is very stable and the feature set is robust, but it's a bit abandonware at this point so you'd be on your own for support.</em></li>
<li>There might be more I don't know of, so may want to look around some more if you want onboard scripting.</li>
</ul></li>
</ul>

<h2>Third: Your hardware choice will depend heavily on which of the above you choose.</h2>

<p>The first (implicit) choice is the type of platform: plane, multicopter, boat, car, etc. Of which you seem to have already chosen the second, but I'm going to point out the existence of that choice anyway.</p>

<p>Then comes the flight control system's architecture as outlined above: Is it going to be just a single (scriptable) flight controller? An FC with a control link to a ground station? An FC/onboard general-purpose single board computer pairing? Something else? If you've got a specific application in mind, do you need any particular onboard peripherals/payload that need to be integrated into the control stack? </p>

<p>With all of that in mind, you'll choose a combination of flight controller (hardware) and flight control package (firmware), plus possibly the aforementioned peripherals, secondary computer, radio links for the ground station, etc., and then an airframe that will carry your hardware and payload comfortably.</p>

<p>It's possible you'll find an integrated package with all of that included that will fit your needs, either proprietary or open source hardware. Of the former, the Tello might be one. Of the latter, I know of <a href="https://discuss.ardupilot.org/t/ardubee-a-ready-to-fly-micro-drone-for-education-and-swarming/54362" rel="nofollow noreferrer">ArduBee</a>, a single-board copter (in which the PCB <em>is</em> the drone's frame) built for ArduPilot, and <a href="https://outcastdroneworks.com/products/microhawk-complete-maker-kit" rel="nofollow noreferrer">MicroHawk</a>, which is purpose-built to fit a Raspberry Pi Zero.</p>

<h2>Finally: You'll need to learn to fly the thing manually. No excuses.</h2>

<p>No matter what, accidents with UAVs happen. Software bugs or other malfunctions that are <em>capable</em> of leading to an accident are even more common. Especially when it's your own prototype code. It's not a question of <em>if</em>, but <em>when</em>. And just losing the aircraft is one of the better outcomes. A multicopter is inherently dangerous. It's a flying blender with sharp blades connected to a half-kilo brick, which is often traveling at 50+ km/h. You <em>do not</em> want it to fly into anything that you care about. So unless you're only going to fly in a very unpopulated area and run a hundred meters away from the thing before each launch, you must at least learn the basics of flying a drone, in both stabilized (attitude) and acro (rate) modes, to the point of being confident enough in your abilities to assume manual control at any moment if the aircraft starts to act in a way it's not supposed to, and guide it safely to the ground.</p>

<p>Besides, manual piloting of both quadcopters and fixed-wing planes is fun! </p>

<p>Feel free to ask for any clarification or additional details I might have missed, and I'll add it to the answer (or as a comment).</p>

CC BY-SA 4.0
2020-06-07T00:48:18.733Z
2020-06-07T01:05:38.663Z
2020-06-07T01:05:38.663Z
FlashCactus
<p>All multicopter drones use a flight controller. This flight controller is usually a small board with a micro controller like an ARM F4/F7 on it:</p>

<p><a href="https://i.sstatic.net/RFZvKm.jpg" rel="noreferrer"><img src="https://i.sstatic.net/RFZvKm.jpg" alt="picture of a flight controller board"></a></p>

<p>One job of the flight controller is to receive and decode the control inputs of the receiver. This is another board with antennas:</p>

<p><a href="https://i.sstatic.net/4nASj.png" rel="noreferrer"><img src="https://i.sstatic.net/4nASj.png" alt="rc receiver"></a></p>

<p>Nearly all receivers use a serial protocol to communicate with the flight control. So you can send commands via the serial protocol.</p>

<p><strong>Serial interface</strong></p>

<p>This would be a very simple way to send commands to the flight control but the downside is that you need to build your own radio receiver or find a way to send commands to the receiver directly.</p>

<p><strong>MSP</strong></p>

<p>Another simple option would be the MSP protocol that is used by a number of different open source projects. It is another serial interface but with this protocol you can read and write information from/to the flight control. See <a href="https://github.com/iNavFlight/inav/blob/bcd4caef92bff67e91350456903a5cdd1d779840/src/main/msp/msp_protocol.h" rel="noreferrer">https://github.com/iNavFlight/inav/blob/bcd4caef92bff67e91350456903a5cdd1d779840/src/main/msp/msp_protocol.h</a> for a list of available messages in the protocol.</p>

<p>Warning: it's not recommended to control the drone via this interface alone but it is possible.</p>

<p><strong>Ground control software</strong></p>

<p>Other open source projects offer a ground control program that allows to send commands to the drone during flight. One example is QGC <a href="http://qgroundcontrol.com/" rel="noreferrer">http://qgroundcontrol.com/</a> with the MAVLink protocol: <a href="https://mavlink.io/en/" rel="noreferrer">https://mavlink.io/en/</a> that communicates with PX4 Pro or ArduPilot flight controllers. </p>

<p>So you would need a drone with the flight controller, a telemetry radio ( <a href="https://ardupilot.org/copter/docs/common-sik-telemetry-radio.html" rel="noreferrer">https://ardupilot.org/copter/docs/common-sik-telemetry-radio.html</a> ) and a PC to run the ground control software. </p>

<p>I don't know what the DJI drone can do but you have many open source options to start with. Maybe it's a good idea that you start with a simple drone setup to learn the basics and then move on to the more advanced stuff like controlling the drone via software commands.</p>

CC BY-SA 4.0
2020-05-26T07:22:03.543Z
2020-05-26T07:22:03.543Z
bingo-fuel
<p>I am a software engineer brand new to drones.</p>

<p>I want a drone where I have full access to all of the flight controls programmatically. For example, I can run a python script and once executed, it sends a command to the drone and it moves up or something like that.</p>

<p>I also want to be able to do this outside and not require something like a wifi signal.</p>

<p>I think the cheap 100 dollar <a href="https://www.ryzerobotics.com/de/tello-edu" rel="nofollow noreferrer">DJI Ryze Tello</a> sounds good, but I can't tell from the demos how much I actually have access to the drone programmatically or if DJI is a good option to start with. Any suggestions would be great.</p>

CC BY-SA 4.0
2020-05-26T01:09:01.653Z
Hi Adam, welcome to Drones.SE! I just changed the title of your question to better reflect what I believe you're asking about. Let me know if I'm misunderstanding your intent.
ifconfig
CC BY-SA 4.0
2020-06-06T20:55:33.227Z
I'd suggest you take a look at [this question](https://drones.stackexchange.com/questions/688). While you seem to be asking about a prebuilt drone, I believe the discussion there will benefit you greatly.
FlashCactus
<software><autonomous><control-input>
Do drones with inflight API access for control inputs exist?
Adam Johnston
# Do drones with inflight API access for control inputs exist?

(Asked by: username_0 on 2020-05-26)

I am a software engineer brand new to drones.

I want a drone where I have full access to all of the flight controls programmatically. For example, I can run a python script and once executed, it sends a command to the drone and it moves up or something like that.

I also want to be able to do this outside and not require something like a wifi signal.

I think the cheap 100 dollar [DJI Ryze Tello](https://www.ryzerobotics.com/de/tello-edu) sounds good, but I can't tell from the demos how much I actually have access to the drone programmatically or if DJI is a good option to start with. Any suggestions would be great.

**Tags:** software, autonomous, control-input
> **Comments:**
> **username_1**: Hi Adam, welcome to Drones.SE! I just changed the title of your question to better reflect what I believe you're asking about. Let me know if I'm misunderstanding your intent.  
> **username_2**: I'd suggest you take a look at [this question](https://drones.stackexchange.com/questions/688). While you seem to be asking about a prebuilt drone, I believe the discussion there will benefit you greatly.  

---

## 2 answers

### Answer by username_2 on 2020-06-07. Score: 5

I started out in this hobby almost exactly the same way, as a programmer who wanted to get into flight code for multicopters and autonomous planes. And while I've yet to launch a fully autonomous aircraft with my own code at the proverbial stick, within my year or so researching the topic hands-on, I have accumulated some useful knowledge which I'm going to share here.

## First, you'll probably need to become intimately familiar with all the hardware that comprises a drone.

If you want to do anything seriously interesting with it, anyway.

There *do* exist some integrated programmable drones that abstract the hardware part away and let you code basic flight routes, but they're limited by that same abstraction to the most basic maneuvering. This, as many consumer drone owners can attest, is rather boring unless you have a specific application in mind. And specific applications (apart from filming/photography, which are usually automated enough in commercial camera drones out of the box anyway) usually require something more than just a drone with a camera.

Of course, you might be content with that. You might want to simply play with it in your living room or backyard, which is perfectly fine, and in this case a prefab proprietary drone like the Tello might suit you well, especially if you're only going to use it as a stepping stone/demo version before diving into the "real thing" (or not). As a disclaimer, I haven't researched this one in particular, but I'd bet it has all the characteristics of a proprietary product: highly refined, but also sealed, with its own API/ecosystem, and capable of some particular subset of possible flight modes that the developers thought safe/proper. Which is okay if you're using this as a tool for learning programming and/or general robotics, but this will slow one down once one starts to get into anything advanced. Besides, if you decide to move on from one of these to something else, you won't be able to take any of your code along: it will certainly be incompatible with anything not of that manufacturer.

The alternative is to roll your own: buy all the components either separately or as a kit and build a drone for yourself (or buy a prebuilt kit, which is very distinct from buying a commercially manufactured drone). This has all the characteristic advantages and drawbacks of open source: On the plus side, it's highly customizable and extendable, often has the most cutting edge tech, open standards, portability of code, etc. Most importantly for this application, it allows interoperability with about any kind of peripheral you can think of (provided that this peripheral can talk via one of the standard protocols, e.g. SPI/I²C/RS232/OneWire/etc, though you probably could hack in support for proprietary protocols as well if you really wanted). All of that is balanced by around zero customer support: No one's there to hold your hand, and any issues you might experience you'll have to troubleshoot on your own, maybe with the help of knowledgeable friends... or internet strangers like ourselves. Given that you're already a software engineer, you're probably doing it all the time anyway, however.

## Second: There's only a few scriptable autopilots.

I'm going to cover the open source ones for the most part, as for the reasons outlined above I was never particularly interested in the proprietary variety. Also, I'm talking about high-level flight code, e.g. code that defines complex behavior *on top of some other flight control software, which in turn provides at least basic stabilization and primitive maneuvering*. If you want to dabble in low-level stabilization code that works directly with bare metal, you can just fork any flight control project or even write your own.

So, a rundown of all the options in order of increasing complexity:

* Most flight control software has varying degrees of inbuilt flight behavior automation such as takeoff, landing, position hold/loiter, return to home, and waypoint missions.
* The latter represents the most basic form of programming: you set up a flight route consisting of waypoints, possibly with other modes thrown in (e.g. takeoff, go to waypoint A, then B, loiter there for 10 minutes, go home, land). This *mission* is then uploaded to the drone and off it goes. This, as far as I know, does not support conditionals or other control structures, so is not turing-complete.
* For more complex high-level flight control, there's a widely-supported protocol called [MAVLink](https://mavlink.io). It allows for a device external to the flight controller to query flight parameters and issue commands via a UART connection. This is the protocol that's usually used by ground station software (through which you define the waypoint missions mentioned above and otherwise remotely control your craft's behavior).

  MAVLink is supported by most flight control software suites, and is very bulletproof by the standards of this currently highly experimental field. The data and commands available via the protocol range from the highest inbuilt abstraction level (e.g. add waypoints or change flight modes and set their parameters) to almost the lowest (e.g. query exact attitude, read data from gyros or other peripherals, set rotation rates), and the set can be extended arbitrarily. The only caveat is that it's only a communication protocol/API, so you'll need some kind of external computing device, either onboard or remote, to provide the actual logic.

  This "physically external logic" approach is probably the most approachable option for a regular programmer, since you can run your flight code on your laptop in any language you like, controlling the craft remotely via a telemetry link (which is basically a pair of transponders, one of which plugs into USB and the other into the flight controller's UART, providing a bidirectional serial connection over radio). If you do so, mind the latency and link health: it might restrict you to higher-level control. If you find yourself needing more fine-grained control, you can move the code to an onboard computer (e.g. raspberry pi) connected to the flight controller directly, getting rid of the radio link and retaining the familiar Unix-y operating environment.

  The MSP protocol mentioned in the other reply falls, as far as I can tell, into the same category, but is somewhat more specific. That's perfectly fine, though; use whatever works for you.
* Finally, there's the option of *onboard scripting*, defined as user code that runs on the flight controller hardware together with (or, rather, *on top of*) the basic flight control software itself, and makes use of the latter's capabilities. This allows one to code custom flight logic without modifying the code of the autopilot itself, yet have both high-level control of the autopilot's automation features, and fine-grained low-level access to the craft's hardware with about the lowest possible latency. The approach comes with some operating restrictions, however, since you'll have to work within a real-time operating environment and with very limited resources. Also, there's only a small selection of autopilots which support such scripting, at least ones that I know of, and all of those are thanks to [a question](https://drones.stackexchange.com/questions/688) I asked earlier on this very site. Here's a summary of the contents:
  + Ardupilot [supports onboard Lua scripting](https://ardupilot.org/copter/docs/common-lua-scripts.html) in its Copter/Rover variants since v4.0 and in Plane since v3.11. As of right now, this seems the most "lightweight-yet-powerful" option and thus most promising for my use case.
  + [ROSflight](https://rosflight.org/) has been suggested, which is an autopilot package running on top of the Robot Operating System, all of which is apparently highly modular and allows you to add (or replace) any part of the flight code independently. See the [relevant answer](https://drones.stackexchange.com/a/895/272) for more details.
  + Finally, this comment by [Kenn Sebesta](https://drones.stackexchange.com/users/46/kenn-sebesta): *Tau Labs supports picoC and full flight scripting. It is very stable and the feature set is robust, but it's a bit abandonware at this point so you'd be on your own for support.*
  + There might be more I don't know of, so may want to look around some more if you want onboard scripting.

## Third: Your hardware choice will depend heavily on which of the above you choose.

The first (implicit) choice is the type of platform: plane, multicopter, boat, car, etc. Of which you seem to have already chosen the second, but I'm going to point out the existence of that choice anyway.

Then comes the flight control system's architecture as outlined above: Is it going to be just a single (scriptable) flight controller? An FC with a control link to a ground station? An FC/onboard general-purpose single board computer pairing? Something else? If you've got a specific application in mind, do you need any particular onboard peripherals/payload that need to be integrated into the control stack?

With all of that in mind, you'll choose a combination of flight controller (hardware) and flight control package (firmware), plus possibly the aforementioned peripherals, secondary computer, radio links for the ground station, etc., and then an airframe that will carry your hardware and payload comfortably.

It's possible you'll find an integrated package with all of that included that will fit your needs, either proprietary or open source hardware. Of the former, the Tello might be one. Of the latter, I know of [ArduBee](https://discuss.ardupilot.org/t/ardubee-a-ready-to-fly-micro-drone-for-education-and-swarming/54362), a single-board copter (in which the PCB *is* the drone's frame) built for ArduPilot, and [MicroHawk](https://outcastdroneworks.com/products/microhawk-complete-maker-kit), which is purpose-built to fit a Raspberry Pi Zero.

## Finally: You'll need to learn to fly the thing manually. No excuses.

No matter what, accidents with UAVs happen. Software bugs or other malfunctions that are *capable* of leading to an accident are even more common. Especially when it's your own prototype code. It's not a question of *if*, but *when*. And just losing the aircraft is one of the better outcomes. A multicopter is inherently dangerous. It's a flying blender with sharp blades connected to a half-kilo brick, which is often traveling at 50+ km/h. You *do not* want it to fly into anything that you care about. So unless you're only going to fly in a very unpopulated area and run a hundred meters away from the thing before each launch, you must at least learn the basics of flying a drone, in both stabilized (attitude) and acro (rate) modes, to the point of being confident enough in your abilities to assume manual control at any moment if the aircraft starts to act in a way it's not supposed to, and guide it safely to the ground.

Besides, manual piloting of both quadcopters and fixed-wing planes is fun!

Feel free to ask for any clarification or additional details I might have missed, and I'll add it to the answer (or as a comment).


---

### Answer by username_3 on 2020-05-26. Score: 4

All multicopter drones use a flight controller. This flight controller is usually a small board with a micro controller like an ARM F4/F7 on it:

[![picture of a flight controller board](https://i.sstatic.net/RFZvKm.jpg)](https://i.sstatic.net/RFZvKm.jpg)

One job of the flight controller is to receive and decode the control inputs of the receiver. This is another board with antennas:

[![rc receiver](https://i.sstatic.net/4nASj.png)](https://i.sstatic.net/4nASj.png)

Nearly all receivers use a serial protocol to communicate with the flight control. So you can send commands via the serial protocol.

**Serial interface**

This would be a very simple way to send commands to the flight control but the downside is that you need to build your own radio receiver or find a way to send commands to the receiver directly.

**MSP**

Another simple option would be the MSP protocol that is used by a number of different open source projects. It is another serial interface but with this protocol you can read and write information from/to the flight control. See <https://github.com/iNavFlight/inav/blob/bcd4caef92bff67e91350456903a5cdd1d779840/src/main/msp/msp_protocol.h> for a list of available messages in the protocol.

Warning: it's not recommended to control the drone via this interface alone but it is possible.

**Ground control software**

Other open source projects offer a ground control program that allows to send commands to the drone during flight. One example is QGC <http://qgroundcontrol.com/> with the MAVLink protocol: <https://mavlink.io/en/> that communicates with PX4 Pro or ArduPilot flight controllers.

So you would need a drone with the flight controller, a telemetry radio ( <https://ardupilot.org/copter/docs/common-sik-telemetry-radio.html> ) and a PC to run the ground control software.

I don't know what the DJI drone can do but you have many open source options to start with. Maybe it's a good idea that you start with a simple drone setup to learn the basics and then move on to the more advanced stuff like controlling the drone via software commands.


---

