This is a guest blog post written by Fred, the maintainer of the Android Crazyflie client and Java Crazyflie lib.

As a follow-up to last week’s blog post about the different Crazyflie clients, I would like to describe the current status of the Android client in a bit more detail.

After more than a year, Version 0.7.0 of the Android client has been released last Friday (March 16). Most importantly this release fixes a very annoying UI bug that appeared on newer Android versions, where the on-screen joystick did not show up when the app was started for the first time. It also adds support for height hold mode when using the zRanger or Flow deck, it adds a console view (can be enabled in Settings -> App settings -> Show console) and also shows the link quality for BLE connections now. You can read the full changelog on Github. You can find the release in the Google Play Store and as an APK on GitHub.

Connection quality and console messages now work on a BLE connection

Apart from the obvious/visible new features and bug fixes, quite a lot has happened “under the hood”. Some parts of the code were cleaned up, refactored, decoupled, etc. This is still a work in progress though.

There is still plenty of stuff to do for future releases, especially in the realm of Bluetooth support. On the short list are:

  • Param/Log support for BLE connections
  • bootloading over BLE
  • support for Flow deck sequences

Admittedly there was almost no documentation for the Android client and some features are hidden (too well). In an effort to change that, I’ve started to document some features on the project’s Github wiki.

If you find bugs in the app, want to request a feature or see errors in the documentation, please open a GitHub issue.

If you are interested in the development of the Crazyflie Android client and want to get involved, let me know. The fastest way to get new features added or bugs fixed is to contribute a pull request.

Last but not least, I’d like to thank the Bitcraze team for creating and developing the Crazyflie and amazing new decks. Maintaining the Crazyflie Android client is still one of my favorite past times. :)

We though we could use this Monday blog post to do a small state of the Crazyflie clients. What we call a Crazyflie client is a piece of software that connects a Crazyflie and allows to control it and get telemetry back from it. In this post we will concentrate on single-crazyflie client we have on our GitHub page, there exists a lot of libraries and software to control one or many Crazyflies, we will write another blog post about them.

Crazyflie PC client

The Crazyflie PC client, is what we consider the reference client. It supports connecting one Crazyflie using the Crazyradio (PA) dongle or direct USB connection to Crazyflie 2.0. It supports the full Crazyflie telemetry (ie. log), parameters (ie. params) and firmware update. It has support for all the Crazyflie 2.0 deck that can use client support. It is updated each time it is needed when new functionalities are added in the Crazyflie which makes it actively developed and maintained by the community and Bitcraze. A bluetooth link has not been prioritize so far since its multi-platform implementation is non-obvious and bluetooth will introduce some latency and lower the radio bandwidth compared to Crazyradio. However, if anyone would want bluetooth support for the Crazyflie PC client, we welcome contributions :-). The Crazyflie PC client is using the crazyflie-lib-python to communicate with the Crazyflie.

We have three mobile clients on our Github. They have various level of functionality depending on community involvement. Our philosophy is to have the mobile clients at least able to control a Crazyflie, this allows to use them to test Crazyflies without requiring to setup a computer. We will help and support anyone that is interested in adding functionalities to the mobile clients but we generally do not have time to add much functionalities by ourselves.

The Andoid crazyflie client is currently maintained by Fred from the community. It is mobile Crazyflie client with the most feature. It supports both Crazyradio and Bluetooth link. Using Crazyradio it currently supports the part of telemetry and parameter required to support a couple of deck like the led-ring and buzzer deck and supports updating the firmware. Using bluetooth there is currently no telemetry, parameter or firmware update functionality so no deck support. Development is in progress to support more decks and to bring the bluetooth link to the same functionality as the Crazyradio link. The Android client is written in Java and Fred has developed a Crazyflie Java library that is used in the Android client but that can also be used in any other Java program.


Crazyflie Android client

The iOS Crazyflie client, works on iPhone and iPad. It supports bluetooth link. It does not have any telemetry or parameter support, so no deck control support. It has firmware update support over bluetooth. It has mainly been developed by me with great contributions from the community for, among others, the port to swift.  The iOS client is written in swift. The Crazyflie and Bluetooth part of the code could be a good starting point if anyone wanted to make a native mac Crazyflie client.

Crazyflie iOS client

Finally we have a prototype of a Windows UWP client developed by theseankelly. It supports Bluetooth low energy. It currently does not supports any telemetry or parameters. It is working both on Windows phone and on Windows 10 on computer, it is currently the only way to connect a Crazyflie using Bluetooth from a laptop. The windows client supports manual control of the Crazyflie using a gamepad or with gesture using HoloLens. This original set of functionality makes it both the most simple and the most advanced Crazyflie client :-).

If you are interested in developing for any of these client, of by making your own, feel free to make a ticket on the relevant github repo or open a thread in the forum. We migh not have much time to develop for the mobile clients, but we will always be glad to help and guide anyone that wants to implement software in relation with the Crazyflie. The Crazyflie clients (running in a computer or phone) and the Crazyflie firmwares (running in the Crazyflie itself) are open source and in active development, it means that is possible to modify both side, this makes it a great target to experiments and to play around with new ideas :-).


We are excited to announce that the Crazyflie 2.0 and the STEM bundle has been chosen by Udacity for their Flying Car Nanodegree Program. For the students that want to try out their skills on a real world flying drone, the core curriculum has been augmented with supplemental lessons and Udacity announce that they will provide thorough instructions for the Crazyflie.


Udacity is providing on-line learning and their mission is 

“to democratize education through the offering of world-class higher education opportunities that are accessible, flexible, and economical”

We are super happy that Udacity likes the Crazyflie and that more people will have the opportunity to explore the world of robotics!

Qualisys is a Motion Capture (Mocap) system manufacturer based in Gothenburg in Sweden. Since we are also based in Sweden, Qualisys have been able to visit us a couple of times and we now have one of their Motion capture system installed at the office. This collaboration allows us to have access to a Mocap system, something we did not have previously. It means that we can better support people using motion capture systems with Crazyflie.

We are currently implementing support for Qualisys in the Crazyswarm project. Crazyswarm currently supports a couple of motion capture system including Vicon and Optitrack, with the addition of Qualisys we and everyone with a Qualisys system will be able to fly swarms of Crazyflie in their mocap.

We are also planning on having a combined booth, Bitcraze and Qualisys, at IROS 2018. We are planning to demo flying both with the Mocap and with the Loco Positioning System. We will keep updating on this when we have more details.

We look forward to this collaboration since it will allow us to use and better support motion capture positioning for the Crazyflie.

We have seen a big interest in flying swarms of Crazyflies and there are many challenges in doing so. The USC ACT Lab has developed Crazyswarm, a collection of software and firmware that allows to fly big swarms of Crazyflie using a motion capture system. This project has been used by USC and other universities to fly the most impressive swarms of Crazyflie 2.0 to date. 

Picture from “Downwash-Aware Trajectory Planning for Large Quadrotor Teams” publication using Crazyswarm

We are very happy that we together with Wolfgang and James, the main developer of Crazyswarm, have started to merge the firmware part into the official Crazyflie firmware. Merging the code will have two great consequences: people will be able to use Crazyswarm with a Crazyflie 2.0 running the stock firmware and everybody else will be able to use functionalities that has been developed for Crazyswarm.

There is currently a couple of parts that are in the works. The state controller has been merged already. There is currently some discussion on Github on how to merge the high-level commander, a commander that would allow the Crazyflie to autonomously follow trajectories as well as other high level commands. Finally there will be some work required to adapt the Kalman filter to make it more suited to accepts measurements from a motion capture system. The Crazyflie was not developed as an autonomous platform from the beginning but it is becoming one in big part thanks to the great contributions from the community.

A great thanks to James and Wolfgang for their effort in merging CrazySwarm in the Crazyflie code-base!

Out of stock
Unfortunately we miscalculated how much China slows down during Chinese new year which has caused some products to become out of stock. One of them is the Crazyradio PA which is also causing some bundles to become out of stock as well. The good news is that the products are in transit to the warehouse and will hopefully be back in stock any day now. Until then you can use the “Item out of stock – notify me!” functionality to get notified as soon as the product is back in stock.


During the fall we did two blog-posts (12) about a new prototype named Obstacle Avoidance/SLAM deck, but since then it’s been a bit quiet about it. So we thought it was due for an update! First of all, after a lot of discussions, we decided to rename the deck to Multi-ranger. It better describes what the board does and matches the naming of the Z-ranger. We’ve sent out some samples to customers and so far the response has been great. So we’re pushing forward and preparing for production that’s estimated to begin in March. Below is a picture of the latest prototype.

The biggest change for the final prototype is adding a LDO regulator to power the sensors. We’ve seen that depending on the settings for the sensors they might consume a lot more than when we initially tested. Using the same settings as for the Z-ranger brings the consumption to 90 mA, which together with the Crazyflie 2.0 electronics, comes close to filling the power budget for the Crazyflie 2.0 VCC LDO regulator. Aside from that we’re making some minor changes to simplify production and testing.

We’ll keep you updated on the progress!

We just released a new version of the Bitcraze VM, version 2018.01. Nothing very new in this version, the VM has been rebuilt so that all the projects included in it are now up-to-date. This solves an issue where the Crazyflie client was blocked in the previous revision.

The current VM is running a quite old version of Ubuntu, the 14.04 LTS version. We are planning at refreshing the VM by making a new one when Ubuntu 18.04 LTS is released.

Since the Crazyflie 1 time we have been documenting the VM as a standard development environment. This has a couple of advantages:

  • We can distribute a fully setup development environment that has minimal dependencies with the host system
  • If someone has a problem with the VM, there is a bit chance we can reproduce and fix it, everyone is running the same system
  • Everything is pre-setup so it should be fairly quick to get started with the actual firmware or software development

However the VM solution also has drawbacks:

  • It requires to install and somewhat configure VirtualBox or other virtual machine software
  • It has some cost in performance, mostly for USB as it slows down the communication with the Crazyflie
  • The USB implementation seems to have bugs on Windows, which makes the communication with the Crazyflie buggy. This is currently the biggest problem!

So, the situation is not ideal, and we would love to get some feedback from the community.

There are two very different parts in the system: the lib and client in Python, and the firmwares in C.

  • Starting development of the python parts, on Windows/Mac/Linux, is fairly straightforward. Basically one has to install python and git, clone the projects, install dependencies and it runs. Different python IDEs can be used and work pretty much out of the box.
  • Starting development for the embedded C part can be a bit more challenging. On Linux and Mac it is pretty easy since it only requires to download the arm-embedded-gcc compiler and adding it to the path. On windows things are a bit more complex because you also need Make and I haven’t yet figured-out the best way to install that. Having an IDE requires to configure Eclipse CDT.

What do you think about the VM as a development environment and would you prefer other solutions like documentation for each operating system on how to install a development environment?


We have been writing a couple of times already about the new TDoA2 algorithm for the Loco Positioning System. A TDoA mode has been experimental from the day we released the LPS but we are now proud to announce that TDoA is an official positioning mode for the Loco Positioning System and the Crazyflie.

Practically it means that the Loco Positioning System now has an officially supported mode to locate and fly a swarm of Crazyflie 2.0.

We have worked these last weeks at updating documentation, the “Getting started” tutorial and releasing all the affected firmware and software. One of our goals was to make the new TDoA mode as seamless and as easy as possible to work with, this meant having everything working without having to recompile the Crazyflie or any other part of the system. The Crazyflie is now detecting the LPS mode automatically and it is possible to configure the anchors position and ranging mode remotely from the within Crazyflie client LPS tab.

What we have just released is:

If you have 8 anchors and want to convert your local positioning system to TDoA, this can be done very easily by following the new version of the getting started with loco positioning system guide.

If you want more information about the different positioning modes, we have also updated the system description.


We have been lucky get the opportunity to use a motion capture system from Qualisys in our flight lab. The Qualisys system is a camera based system that is using IR-cameras to track objects with sub-millimeter precision! The cameras are designed to measure the position and track small reflective marker balls that are fixed to the object to be tracked with high accuracy. By using multiple cameras shooting from different angles it is possible for the system to calculate the 3D position of a marker in space. By mounting multiple markers on an object the system can also identify the object as well as its orientation in space. Very cool!

We have started to look at how to add support in our ecosystem for the Qualisys system as well as other “external” positioning systems, external in this context is systems that calculate the position outside the Crazyflie. There is already great support for external positioning in the CrazySwarm project by the USC-ACTLab, but we are now looking at light weight support in the python client. We are not sure what we will add but ideas are on the lines of viewing an external position in the client, feed an external position into the Crazyflie for autonomous flight and maybe a simple trajectory sequencer.

MoCap Deck

We have also started to design a MoCap Deck to make it easy to mount reflective markers on the Crazyflie. Our design goals include:
* light weight
* easy to use
* support for multiple configurations to enable identification of individuals
* the possibility to add a button for human interaction

The current design of the MoCap Deck

The suggested design of the MoCap Deck

Any feedback on the MoCap Deck and ideas for functionality to add to the client is welcome! Please add a comment to this blog post or send us an email.

We will write more about the Qualisys system later on, stay tuned!

This week we have a guest blog post by Ben, enjoy!

I’m Ben Kuperberg and i’m a digital artist, artist-friendly software developer and orchestra conductor. Being a juggler, I’ve decided to focus some of my work on the intersection between juggling and technology, and i’ve since been working more and more with jugglers, my last project being “Sphères Curieuses” from Le Cirque Inachevé, created by Antoine Clée. While the whole project is not focused on drones, a part of it involves synchronized flight of multiple drones and precise human interaction with those drones. Swarm flight is something already out there and some solutions already exist but the context of this project added some challenges to it.

Most work on drone swarms have been done by research group or school. They use high-grade expensive motion-capture system able to track precisely the drones and able to assign their absolute positions. While the quality of the result is undeniable, it’s not fit for stage shows : the setup is taking a lot of time which we can’t always have when the show is on the road. Moreover, the mocap system is too invasive for the stage if you want to be able to “hide” a bit the technology and let the spectator focus on what the artist wants you to see. Not to mention it costs an arm and a leg and Antoine needs both to juggle.

So we had to find other ways to be able to track multiple drones. That’s when we found out the [amazing] team at Bitcraze was working on the TDoA technology, which allows precise-enough tracking of a virtually unlimited amount drones, at reduced cost and with a fast and clean setup.

After some work we managed to have a first rough version of our swarm server made by Maxime Agor that allowed to connect and move multiple drones using the TDoA system, controlled from a Unity application.

While we were able to present a decent demo with this system, we were facing a major problem of reactivity. When working with artists and technology, reactivity is a key component to creativity. Because it can be frustrating and tense to stop each 2 minutes to make changes or fix problems. My first priority was therefore to prepare and design softwares that will allow me to spend most of the “creation time” on the actual creation aspect and not on technical parts. It is also essential that the artist performing in front of the audience can entirely focus on the performance and by fully confident in this technology. The last challenge is that as I focus my work on the creation and not touring, all my work needs to be easily understood and modified by both the artists and the technicians who will take over my work for the tour.

With all of that in mind, I decided to create a software with a high-end user interface called “La Mouche Folle” (« The Crazy Flie » in french) that allows to control multiple drones and have an overview of all the drones, their battery/charging/alert states, auto-connect / auto-reboot features, external control via OSC, and a Unity client to view and actually decide how to move the drones. All my work is open-source, so you can find the software on github.

There only is a Windows release for now but it should compile just fine on OSX and Linux, the software is made with JUCE, depends on OrganicUI and lib-usb. Feel free to contact me if you want more information on the software. Many thanks Wolfgang Hoenig for the support and the great work on the crazyflie cpp library i’m relying on.

So this is the basic setup of our project, but we needed more than that to control the drone. We wanted to be able to control them in the most natural way possible. We quickly decided to go with glove-base solutions, and have been working with Specktr to get our hands – pun intended – on developer versions of the glove. The glove is good but can’t give us absolute position of the hand, so we added HTC Vive trackers with the lighthouse technology and then were able to get both natural hand control and sub-millimeter precision of the tracked hand.

Then it was a matter of connecting everything together : for other projects for Theoriz Studio, I already developed MrTracker (used in the MixedReality project) that acts as a middleware between the Vive trackers and Unity.

I used Chataigne to easily connect and route the Specktr Glove data to Unity as well so we would have maximum flexibility to switch hardware or technology without breaking whole setup if we needed to.

A video of the final result


In the past years, i’ve come to work on a lot of different projects, with different teams, which i like very much, because each project leads to discover new people, new ways of working and new challenges to overcome. I’m having a great time working on this project and especially sharing everything with the guys at Bitcraze and the community, everyone has been so cool and nice. I’ve planned to go at the Bitcraze studios to work for few weeks with them and i’m sure it’ll be a great experience !