Category: Crazyflie

At the end of the week Marcus and I are going at the FOSDEM 16 conference in Brussels. There we will meet Fred, who is the main community developer and maintainer of the Crazyflie Android app. If you also visit FOSDEM and want to meet 2/5th of Bitcraze, let us know!


Fred, like last year, is going to have a lightning talk about Crazyflie. You find him in the schedule. We look forward to seeing it!

Edit: We’re really excited to see a second talk about the Crazyflie 2.0. AdaCore will be talking about their work on re-implementing the firmware to SPARK (more info here).

Finally, as you might know, at Bitcraze we try to have fun Fridays. This means that we reserve Fridays for more personal project that are fun and would not get prioritized otherwise. For example the DWM Local Positioning System started as a Friday project as well as the led ring deck (it was for Crazyflie 1 back then, with a neopixel-ring).

Last Friday Björn tried to make a flying pixel. The idea is to enclose Crazyflie in a white paper box and to use the led-ring to light it in the air. We think that would look great with the local positioning system :-). To be honest what we ended up with is not fully working yet (we have a lot of problems making it fly), but we have ideas for next Friday and at least it looks quite nice already:

As we have written before we are working on a DWM100-based ultra-wide-band local positioning system, we are making good progress and are getting ready to ship alpha systems. We hope to be able to ship in the following weeks. We aim at shipping these alpha system to anyone interested to test it early.

The alpha anchors and DWM deck will be very close to our expected final system. We are in the process of pushing the source code for it on GitHub, it will have open-source public code before we ship the first system.

We have now stocked enough DWM1000 modules and we are ordering the final PCB design for the anchor. This would allow early access to the technology and for us we would be able to get feedback. We are planning on selling the anchors around 100USD each and the DWM decks 70USD. The price is taking into account that we are manually soldering, testing and shipping ourselves. If you are interested to get access early please contact us (you can find the contact email on the contact page).

We have just made a quick and dirty video tour of our basement/autonomour flight lab. This was shot in one take so it is a bit messy, but our goal was to show our current state. We are using the Crazyflie python client training mode with the automatic controller as a student. This is why I keep the gamepad in my hand most of the time: the first flight is done with me controlling thrust and yaw, the controller controls roll and pitch. The second flight is fully autonomous but I still could take-over control by pressing a button. On a side note these tests are showing how good it is to have a lightweight and robust quadcopter like the crazyflie: the Crazyflie you see in the video has crashed countless time this last mount in the basement, I have not yet changed the motor mounts nor any other part on it.



First of all, happy new year on behalf of the Bitcraze team. In this post we would like to talk about the Deck API, but first a little bit of background.

Crazyflie and pretty much all we do is open-source. The main reason is that we want to share and allow everyone to build upon what we are doing. The first Crazyflie was expendable with an expansion port but modifying it was hard because it required good soldering skills. However if we really want others to build and use what we do, we had to increase the usability. So, when designing Crazyflie 2.0 we put a lot of efforts into making it easily expendable. We ended up with the deck port, which makes it easily to add an expansion board, called a deck, on top or bottom of the Crazyflie 2.0. An installed deck will automatically be detected and initialized when the Crazyflie starts thanks to the one-wire memory they contain. Finally we have also made the breakout and prototype deck to help making new decks.


With all this, we believe we managed to make it much easier to create a new deck. However making the firmware driver for these decks still required to understand a lot about how our firmware is architectured. It also did require to add code to multiple files to ensure the driver runs properly. The new deck API aims at making the firmware driver development more straightforward.

The base of the deck API is the driver declaration: it is possible to add a deck driver without having to modify any code in the firmware. The driver just has to be compiled and it will be automatically loaded at Crazyflie startup. This is inspired by the way the Linux kernel is loading modules and drivers. So the minimal driver can be written in 12 lines of code:

#define DEBUG_MODULE "HelloDeck"
#include "debug.h"
#include "deck.h"

/* init function */
static void helloInit()
 DEBUG_PRINT("Hello Crazyflie 2.0 deck world!\n");

/* Driver registration */
static const DeckDriver helloDriver = {
 .name = "myHello",
 .init = helloInit,

In this example, the driver will be initialized automatically if a deck is installed with the name “myHello”. It is also possible to force the driver initialization. For more information there is a documentation for this on the wiki and there is also a short howto that will guides you from zero to having your code running in Crazyflie.

There is also an implementation of the digital and analog input/output API similar to Arduino.

There is a lot of work left on the deck API. Among other things:

  • Easy shortcut to run tasks: currently the only way to run a task is to create one using the FreeRTOS API. The plan is to provide easy to use timers and an Arduino-like loop function.
  • More drivers for SPI, Serial, I2C, …
  • Access to other parts of the system like controlling the flight setpoint or setting the LEDs.

The two first are quite straightforward and ‘just’ need to be done. We are not so sure how to implement the last one yet (we need a good way to modularise the firmware). If you have any input on things you would like to see in the API please contact us, the forum is good for discussion and a ticket in the firmware github project for functionality. You are also welcome to help-out with the implementation, documentation or reporting bug :-).

We are currently working on a local positioning system based on ultra wide band decawave DWM1000 modules for the Crazyflie. We have already written a couple of times about it earlier, and in this post I will describe where we are now. We will also start making a wiki page and add more about the experimentation in the future.

During the end of year 2015, we have made some progress! We just moved to a new office and we now have a local positioning lab in the basement, where we are able to fly a Crazyflie 2.0 autonomously using the local positioning and keeping clear from the walls (I would like to say to keep a stable position, but we are not there yet :-).

As we have shown in previous posts we have electronic boards for the anchors, and the Crazyflie deck:
DWM1000 nodes and deck

We have setup 6 anchors at our office. The configuration is designed to maximize the trilateration precision in the middle of the room. The ranging is done by the crazyflie and then communicated to the ground using the log subsytem. The ROS crazyflie driver receives the ranging and send it to the trilateration algorithm, a particle filter. We can then display the estimated position and use the position to control the Crazyflie position:
graph_dwm rviz_dwm

In order to try to fly autonomously, we have been trying the controller included with the Crazyflie ros driver. We also connected ROS via ZMQ to our python client and the controller we made to fly autonomously with the Kinect. Both work but are far from perfect: they have been tuned for a pretty stable measurement (from a Vicon system or a Kinect) and the output of the particle filter is a bit noisy, mostly for the altitude. We are looking at improving the position control loop and adding sensor fusion for positioning in the Crazyflie 2.0.

Early 2016 will be time to finalize the DWM1000-based local positioning system to be able to distribute it. We are currently writing an open-source C driver for the DW1000 chip and we are finalizing the anchors electronic design. If you are interested in getting such system do not hesitate to contact us, as we are finalizing the design, any input is interesting so that we end up with a system that is easy to use and to setup.

If you are one of the lucky ones getting a Crazyflie for Christmas we are happy to tell you there is a new and fresh “getting started” guide to help you get going :-).

Before going on holiday me and Kristoffer published an updated version for the “getting started” part of the website which we are very happy about. Besides making a new edition of the “Assembling” part we have also added “Installing on a smartphone”, “Installing on a computer” and “Flying”.

We are hoping that these new additions for the “Getting started” section will be a big help for everybody who just got a Crazyflie for Christmas and feel unsure about how to start. Also this is an additional way to help people finding out if the Crazyflie is right for them, who otherwise might feel uncertain about buying one or not.

If you have any comments or suggestions about the new “Getting started” please feel free to contribute we are always open to ideas about improvements and tweaks.


It’s been a hectic time here att Bitcraze before Christmas with new decks coming out and the ongoing re-design of the website among others. So we are all taking some time off during the holidays but we will be answering email and support issues. However it might take a bit longer time since we will be occupied with drinking swedish glögg, french wine and stuffing ourselves with chocolate.


After a hectic week we’re finally ready to put some new decks into production! A couple of months ago we selected 4 deck prototypes to try to bring to production before Christmas: WiFi, GPS, BigQuad and the Buzzer. After working hard on them during the last months, we’re now ready to release the Buzzer and BigQuad decks. Last week we ordered the first batches and the product pages and descriptions are being written this week. We’ll push out more information about the boards as it gets available, so stay tuned!

Below is a few quick shots of the latest prototypes:

So what happened to the GPS and the WiFi decks? The latest prototypes are working, but there’s still some minor issues. So instead of moving to production with the current design, we’re doing one last prototype iteration and launching the boards early next year.

On a related note we’ve been working hard together with Seeedstudio to get some more Crazyflie 2.0s into stock before Christmas. Not so surprisingly we’re not the only ones rushing to produce. But thanks to lots of efforts from Seeedstudios side the Crazyflie 2.0 will be back in stock in a couple of days!

Lately we have been busy finalizing new Decks. We have a pretty long list of what we want to release and the first four to come are the bigquad deck, the Buzzer deck, Wifi (ESP8266) deck and a GPS (GlobalTop) deck. Before going further a disclaimer: we have ordered final prototype of these decks so the probability we release them is pretty high, though it is still possible we end up hitting a big bug and then some might be delayed.

The bigquad  was covered in previous post. It is a very simple deck: only connectors. It can be used to connect brushless motors ESCs to the Crazyflie in order to control a bigger quad. We have also added connectors to control the Crazyflie from a standard receiver (SPPM input), for GPS, active buzzer, battery telemetry and I2C sensors. The main use case we see for this deck is to be able to develop with the Crazyflie and then go outside and fly with bigger sensors without having to port the code to another platform.


Firmware-wise we are developing support for ESCs and SPPM input.

The Buzzer deck is the second simplest: we have ‘just’ mounted a buzzer on a deck and made the driver for it. As usual with production nothing is easy and selecting the buzzer was surprisingly hard. We wanted a low profile buzzer to be able to put other decks on top of it. We have ordered 20-ish different buzzer from DigiKey and tested all of them to select the best:



The Buzzer driver will be able to play some music as well other sounds. One use case we envision for the buzzer deck is to be able to find the Crazyflie if it has crashed out of sight.

The GPS deck is an old story: we started working on a GPS deck on the Summer 2014 and we even planed to release it at the same time as the Crazyflie 2.0. Unfortunately we had lots of problems with the antenna not working properly when attached to the Crazyflie. After a lot of experimentation, spread over 1 year, we finally endeded up with a design that works: an integrated GPS receiver and patch antenna:


We found the patch antenna to be much less sensitive to the Crazyflie 2.0 ground plane than the previously tested chip-antenna. As for the software part we will implement enough code to decode the NMEA strings from the GPS and makes them available via the log subsystem. We have a prototype of a new GPS tab in the client using a webview and openstreetmap, more on that on a later post.

Finally we have mounted an ESP8266 wifi module on a deck and Crazyflie 2.0 becomes Wifi enabled :-):


So far we are planning on loading the NodeMCU Lua firmware in the ESP8266 which will allow to easily develop wifi connectivity to the Crazyflie. Note that the final board will be based on a different ESP8266 module with chip-antenna.

We will post more in-depth information about those new decks in the following weeks. We will also communicate the release date as soon as we know it.

Last week I was at Lua Workshop 2015 in Stockholm, it was a very interesting conference with lots of interesting people. I also had the opportunity to see the office of King, the host for the workshop, and it gives a lot of idea for fun stuff and toys we could have in our office :-)

On a side note we are organizing a presentation in our office in Malmö the 22nd of October: Mandy from Seeedstudio is visiting us and will talk about manufacturing in China. If you want to come you can register.


Now, back to Lua. Lua is a dynamic programming language that is small, fast and meant to be embedded within other programs. Currently is is used a lot in video games and a bit on servers. It has also be used in deeply embedded system with the eLua project, for example Seeeds sells a Lua-preloaded ESP8266 wifi module. One of our plan for Crazyflie 2.0 is to be able to write deck drivers in Lua.

With Crazyflie 2.0 we are aiming to make a research-grade flying platform more accessible and versatile, hence the expansion capabilities (with decks) and the new API we are writing for it. Lua would fit well in this goal. It would allow to very quicky script and test a device driver. As a bonus Lua being safe (ie. the virtual machine cannot crash the system), there would be no risk of crashing the copter with those kind of driver. The architecture would look something like that:


Though Crazyflie Lua integration has not been prioritized so far, we think it is something that would be interesting to play with it in the future. If anyone is interested into testing and helping out please reach us on Github or on the forum.

Last Thursday we went to LTH (University of Lund), to the Robotics department, to make some measurements on the ultra wide band (UWB) positioning system we are working on. The idea was to use one of their robots to move a Crazyflie around along well known path, and at the same time record as much sensor data as possible. This would give us data that we can crunch offline.

We placed four anchors around the robot and our positioning expansion deck on the Crazyflie. The Crazyflie collected the data from the positioning deck as well as its internal sensors and streamed the data it over USB to an external computer for storage. We collected the following data:

  • Distance to the anchors (raw measurements)
  • Air pressure at the anchors
  • Air pressure at the Crazyflie
  • Accelerometers
  • Gyros

The logs from the robot will give us the real position of the Crazyflie as well as the anchors, and from that we will be able to evaluate the performance of algorithms that use the sensors to figure out the position.

The dataset will be shared with the researchers at Lunds university, they have some interesting ideas they want to try out.

Next step is to crunch the data…

For more information on our UWB positioning project, see Firmware and dwm 1000 nodes

Last week and this week is busy with preparations for the New York and Berlin maker faires. Since we will be in the Seeedstudio booth we don’t have the same space as at the Bay Area Maker Faire, so we had to rebuild our “fly-cage”. The new specs are 1.7 x 0.7 x 0.7 meters. This is the area the Crazyflie 2.0 should be able to fly in for a full charge without touching the sides on the net.

We don’t have any special plans during the faire, except for flying during the day. So if you feel like meeting up, having a beer and getting lost in various technology discussions then leave a comment or drop us a mail.

The autonomous flying rig we used in bay-area was using the Kinect 2 sensor. This new rig is only using a standard webcam which is cheaper and easier to manage (ie. we do not need a Windows computer anymore). We are attaching an augmented reality marker on the top of Crazyflie and the image processing is mostly done by the ArUco library. ArUco is detecting the position of the Marker in 3D and the position is sent via zeromq to the controller. We used the same controller code as for the Kinect, we just had to tune it a bit better to keep in the smaller space. Then the controller is sending pitch/roll/yaw to the Crazyflie client setup to have a ZMQ as input device.


If you want to build the same cage then here’s a list of the parts:

  • Some kind of net (we used normal fishing net)
  • Fishing line (to tighten the cage)
  • Aluminium beam (for tents)
  • These 3D printed parts
  • Webcam with standard camera attachment (we use Logitech C920)
  • Camera attachment screw

We are in the process of cleaning up the code for the webcam. It will be pushed on Github and we will document the build on the Wiki.