Reconciling Parrot AR.Drone developers and Android developers

The AR.Drone SDK 2.0.1 is sadly old

The Parrot AR.Drone SDK 2.0 was released in June 2011, and its latest update dates back to December 2012. Yet, the AR.Drone 2.0 is still being sold today and many people are still developing for it: independent tinkers, students on university projects, companies researching on AR/VR and more.

Meanwhile, in 3 years, the tools of these developers have evolved quite a lot. Android developers, particularly, have stopped using the Eclipse IDE and the Ant build system for a while. Instead, they use Android Studio and Gradle. Libraries are now globally distributed through Maven repositories and integrated straightforwardly with one line of code.

This is the constatation: the latest version of the AR.Drone SDK (2.0.1) is hard to find. When it is found, it’s no longer compatible with the newer build systems used by developers, or it can be made to work only at the cost of tedious adaptations.

I took some time to make these changes in a way that would be generic, open-source and reusable. The aim is to share with the developers out there to get you started faster on the development of your cool app for AR.Drone!

Note: this article focuses solely on Android development with the AR.Drone SDK. However the AR.Drone SDK released in December 2012 is a bundle for various other platforms (iOS, Win32, OS X, Linux). For these platforms too it may be worth updating the SDK to comply with newer build systems.

Parrot and Android Studio are best buds, and we're going to prove it!

Parrot and Android Studio are best buds, and we’re going to prove it!


An update to make it more user-friendly


The official SDK 2.0.1 is a ZIP archive that contains docs, C source code of the ARDroneLib and example apps for different platforms. The Android example is in fact the source code of the Freeflight app that is the official app, published on the Play Store, to control your AR.Drone.

This example is an Eclipse project, that contains:

  • The “pure Android” code in Java and XML for the UI.
  • The native libraries used by the app: ARDroneLib to pilot the drone and FFMPEG for the video feed.
  • Some native code, in C, to tie the Android code and the ARDroneLib together.

To compile & run, the official instructions require you to be running an Ubuntu system, install extra dependencies on it, run a bash script to compile the whole ARDroneLib and then an Ant script to build your APK.

I wanted to make the process much simpler.


The project is now a pure Android Studio + Gradle project, with the correct folder structure. What’s more, the ARDroneLib is directly precompiled for Android. It means that you don’t need extra dependencies anymore, so you can develop on any OS (Linux, OS X, Windows).

The code is available here:

All you need to do in your Android Studio is to download the NDK package (available in Android SDK Manager).
Then sync Gradle, click run. That’s it!


And that makes for a happy pilot!

And that makes for a happy pilot!


What happens next

Split app module and library module

Obviously, if you’re interested in the AR.Drone SDK, you don’t want only to compile and run the Freeflight app. But that’s the only code example that Parrot provided in the first place. The next step would be to push further the principle of Gradle modules. I want to separate the UI of the app from the functional bits that would be used by other apps (e.g. the method triggerTakeOff()).

Ideally, in the end, the AR.Drone SDK would be available on a Maven repository, so that one could start developing a new app controlling the drone with the help of one Gradle “compile” instruction.

I’m trying to dedicate some time to work on that, but contributions are very welcome! I started a branch separate-lib-and-app dedicated to this purpose in the Git repo.

Control the complete build chain

In this article, I focused specifically on Android, and that allowed us to make a big (albeit reasonable) simplification: we can use precompiled versions of ARDroneLib and FFMPEG in our projects. We don’t lose time compiling these bits, and they are ensured to work on any smartphone.

Even though this allows for super-fast development by focusing on what to do with the SDK rather than how is the SDK done, this is not respecting the original spirit of the 2011 ZIP archive. Having control on the complete build chain, from the first bits of code, would allow to, for example, fix bugs in the SDK or upgrade FFMPEG to a newer version.

I just started this idea by reintegrating the source code of ARDroneLib in the repo and tying it to the master Gradle script, but there’s still work to be done here. It is in the branch complete-build-chain and again, contributions are welcome!



Feel free to comment and share, and I’ll do my best to answer questions. Don’t forget also the fantastic Parrot dev forum.
Now, you should be all setup to start making cool apps for the AR.Drone! Happy coding,



Have something to add?

Loading Facebook Comments ...

Leave a Reply