Category: Electronic

It’s been a while since we summed up things happening in the community so here’s some of the things that are happening. There’s lots of more things, so if you think we are missing something, then post it in the comments below.

Ralph has been doing some work on an semi-automatic flip feature in the client. There’s more info on the forum and video below.

Last week we tested some modifications made by otto for a headfree mode (i.e yaw only rotates the platform, not the referance direction). It’s a really nice feeling just rotating without taking care of the direction you are going in :-) There’s more information and links to code on the forum.

The SHERPA project have been working on swarm algorithms using a vision system and the Crazyflie.

Geof from Centeye have been working on optical flow stabilization using the Crazyflie. He has a prototype board working and there’s lots of information in the forum about this build. To see the results have a look at the video below.

Thanks to Victor the Deviation firmware for Devo-7e (custom firmware for Devo RC-controllers) now has support for the Crazyflie (needs hardware hack). If you would like to give it a try have a look at the code or grab one of the nightlies.

Researchers at the University of Tokyo have been testing a new concept for a HoverBall using the Crazyflie. Imagine throwing a ball into the air that doesn’t come down (well not right away at least..). Here’s some more info and a picture.

We have also seen some nice stand alone controllers for the Crazyflie, one by  MidLifeCrisis (more info here) and one by ivandevel (video below) . There’s also more info in the forum.

There also some updates on the work done by Oliver on the Kinect tracking of the Crazyflie. A demo video is shown below (it looks great!) and there’s more information on the forum.

And finally here’s a nice video we found on Youtube showing position control of the Crazyflie using a VICON system.

A couple of weeks ago we found the NeoPixel ring from Adafruit at a local shop, we had to attach this neat board to our copter and see what cool effect we could make with it. The ring has 16 RGB LEDs that can be driven independently with only one data wire. The LEDs the Neopixel contains are called WS2812.

This post is describing the development of a WS2812 driver for the Crazyflie. A later post will show the usage we did of it (fairly limited in comparison of the seemingly endless possibility, as usual we have more ideas than time to execute them :-).

The WS2812 LED

First of all we needed to see how to control the LEDs. The protocol used by the WS2812 is quite simple but special. All LED on the ring have a data input and a data output pin in a chained manner. Colors of the LED is send over the Data line to the first LED that will save it internally. When sending a second color the first LED will send the saved color to the second LED. And so on, by sending 16 color data we can set the color of all LEDs of the ring independently. Colors are sent as 24 bits (8 bits per component).

Up to there nothing is really peculiar, the system is pretty neat and allows to control a lot of LEDs with just one IO. The problems comes with the Bit encoding:


Bits are encoded with pulse width: a short pulse means 0 and a long pulse means 1. The bitrate is of about 800KHz and the tolerances on bit timing is pretty tight. As there is no hardware peripheral dedicated for this (on common microcontrollers), this bitstream needs to be implemented either by bit-banging or by being a bit creative with the peripheral we actually have at our disposal.

Driver implementation

Adafruit did implement a driver for the WS2812 for Arduino, this is a software implementation that uses the CPU to implement the signal. However at that bitrate a software/bit-bang implementation have to be timed carefully and the easiest for that is actually to implement it in assembler. Arduino runs on an AVR processor and these processor are very predictable: each instruction runs in a specified number of clock cycle which makes it possible to implement a timed loop like the one of Adafruit. However this becomes impractical on bigger CPU that implements caches and other optimization that makes it really hard to predict how much cycle each instruction will take.

The Crazyflie runs a STM32F103 based on an ARM Cortex-M3. This is just complex enough to make the ASM-timed loop impractical: The CPU core runs at 72MHz but the flash is slower so a simple cache memory is inserted in the middle and depending of the state of this cache it may take from 1 to 3 cycles to execute an instruction. There is an even bigger problem: a CPU timed loop requires to stop all interrupt and to have the CPU running exclusively on updating the WS2812. We cannot allow that on the Crazyflie that require a 250Hz control loop to stay (controllably) airborne.

We asked Google to see if someone already came with a solution and actually someone did. The Elia’s Electronics Blog posted a neat, well documented, solution using the STM32 Pulse Width Modulation (PWM) capabilities of the STM32 to generate signals that the WS2812 understands. All we needed was a timer/pwm output then. It happens that we have one timer1 output on the Crazyflie extension port:


This is only 3 wires: VCOM for the battery voltage, GND and the timer output.

I started porting the Elia’s code to the Crazyfle. The only free timer we could easily use was different and much more complex than the one Elia uses. So part of the frustrating implementation was to figure out WHY the signal was looking weird on the scope! Finally after an hour or so the code was working:



Now that was not quite enough. The driver is using the PWM to generate the 1’s and 0’s pulse width and the DMA is used to feed the bit width independently of the CPU (so that it can do something else, like controlling the copter attitude…). It requires all the 16 LEDs data to be written in the memory buffer before starting the DMA. Each LED has 24 bits color data and each bit will be encoded as 16bit pulse length for the timer. It means that the full ring will take 768Bytes in RAM. It sounds small but its a bit too much for us and, most importantly, it does not scale: if we want a second ring the ram requirement will double.

To fix this I implemented two things: An easy one is that the DMA can do some type conversion and one of these is that it can read 8 bit in memory and write 16 bit in the peripheral. This allows to store only 8 bits pulse width in memory and so divides by 2 the memory requirement, but it still doesn’t scale.

The fix to scaling is double buffering. The STM32F103 does not implement DMA double buffering as such but what it has is close enough: circular DMA with half-transfer interrupt. The idea is to load the 2 first LED in a buffer and to start the DMA for 42 bytes in circular mode. When the DMA has transferred the first LED it triggers the half-transfers interrupt which allows the CPU to replace the first LED data by the 3rd. When the 2nd LED is transferred the transfer-complete interrupt is triggered by the DMA and the CPU fills in the 4th LED in place of the 2nd one. The DMA roll-over at the beginning of the buffer and sends what is now the 3rd LED data. This continues until all the LEDs has been  sent. This solution scales: it requires a 42 bytes buffer for as many LED as we want!


All that process was not really simple. However the result is simple, now the only thing required to control a Neopixel ring in the Crazyflie is:


#define BLACK {0x00, 0x00, 0x00}</span>
static uint8_t color[][3] = {{40, 40, 40}, {32, 32, 32}, {16,16,16}, {8,8,8},
                             {4,4,4}, {2,2,2}, {1,1,1}, BLACK,
                             BLACK, BLACK, BLACK, BLACK,
                             BLACK, BLACK, BLACK, BLACK,

/* ... */
ws2812Send(color, 16);

And it will run nicely without interrupting other tasks like control and communication. Replace 16 by 32 to control 2 Neopixel rings. The current implementation has been pushed in the crazyflie-firmware neopixel_dev branch (still require some clean-ups!). Actual implementation is in ws2812.c and neopixelring.c.


The only problem left is not software: At the end of the battery life, the voltage is not enough to fully lit the blue LED. That make all white look orange-ish. The only way to fix this problem would be to step-up the battery voltage higher then the forward voltage of the blue LED. Though it works well enough without that.

Stay tuned for a following post about actual usage of the ring.

A while ago I started working on a brushless motor control driver for the Crazyflie. I implemented most of it but did not really have time to test it. Recently we have gotten some request and questions about it so we took some time to do some further testing.

Implementing a brushless motor control driver can be done in many ways. If you have brushlesss motor controllers that can be controlled over I2C that could have been one way but usually the brushless motor controller (BLMC) take a PWM input. This is most commonly a square wave with a period of 20ms and a pulse width of 1-2 ms high, were 1 ms is 0%, and 2 ms is 100%. A period of 20 ms means a frequency of 50Hz. This is most often a high enough update rate for R/C electronics like servos etc. but when it comes to BLMC that is not the case. Therefore many new BLMC can read a much higher update rate of up to 400 Hz were the pulse still is 1-2 ms high. That way you can match the BLMC input to the update rate of the stabilization control loop and increase stability. In the code we added a define BLMC_PERIOD where this can be set.

To test this we wanted a frame which was quick to setup and found this. It is based of a PCB just like the Crazyflie and has the four motor controllers with it, perfect! The built in BLMC are based on an the Atmel MCU Atmega8 which is very commonly used in the R/C BLMC which means it is possible to re-flash them with the SimonK firmware. This is know to be a great firmware and enables fast PWM update rate etc. So we built and flashed the firmware configured for the tgy6a which is compatible and it worked right away, yay!

Now we only had to connect the Crazyflie to the BLMC:s on the frame. The BLMC electrical interface for the PWM signal is often a 5V interface but the Crazyflie runs on 2.8V. 2.8V would in most cases be treated as an high input and can probably be used directly but there is no simple way to connect this signal on the Crazyflie. Instead one way is to use the existing motor connectors and the pull-down capability that is already there. Then it is also possible to pull this signal to 5V with a resistor to get a 5V interface so this is what we did. To power the Crazyflie we took the connector of an old battery and soldered it the 5V output of the frame.CF to BL Frame connections

Now it was just a matter of testing it! However as size increases so does the potential damage it can make. We therefore took some precaution and tied it down. First we tested the stability on each axis using the stock values and it worked really well so we decided to not tune it further. The only issue was that suddenly one of the BLMC mosfets burnt. We replaced it and it worked again but don’t know why it burnt. Later when we flew it something was still strange so we have to investigate this.

We will upload the code as soon as it has been cleaned up. Please enjoy a short video of the journey :)

A couple of weeks ago we attached a uBlox MAX-7 GPS module to the Crazyflie (blog post). Back then it was mostly a proof of concept, all we did was to re-route the raw GPS data (in text NMEA format) directly to the PC using the Crazyflie text console port. This allowed us to quickly prove that a GPS can work on the Crazyflie but was not that useful and efficient: the copter did not decode the gps position and a lot of radio bandwidth was used. Last Friday we decided to fix it and to make it clean(er).

The ultimate goal was to measure the Crazyflie speed, if it wasn’t for the rain we could have done the measurement! Anyway, this work allowed us to exercise the debug functionality of the Crazyflie platform and so to see the strength of it but also what needs to be enhanced. In this post we will try to document (at high level) the steps taken to implement the GPS in the Crazyflie. The source code is pushed in the crazyflie firmware and python-client git repos. The Python client code is in the master branch and the firmware code in the gpu_ublox_dev branch (dev branch means that the code is far from final/clean, but it works!).

Electronically the GPS is connected using only 4 pins: VCC, GND, serial RX and serial TX. The serial port is connected to pins 3 and 5 of the expansion header. The power is connected to VCC.


The electronic was already tested and working so we had 2 tasks left:

  • Decoding the GPS information in the firmware and creating log variables to make the data available for the PC software
  • Updating the GPS tab of the PC software to fetch GPS data from the log subsystem instead of parsing it from the text console

It happens that these two tasks could be done mostly independently and Marcus and I started to work in parallel. The only thing we had to agree upon was which log variable and what scaling to use for the variables. We used the format that the GPS chip is already using which made things easier.


For the firmware part, the first step was to acquire the GPS data. GPS chips usually can talk two languages: the standard text-based NMEA and some kind of proprietary binary format, UBX for uBlox. I chose the binary format as it is a lot easier use in C: no text parsing has to be done, all data dirrectly fits in a C structure. But first the GPS has to be setup to output data in binary modes and to output the data we were interested in. To quickly setup the GPS I used a tool that uBlox provides and that permits to generate proper UBX messages:


Two UBX messages where required: One to disable NMEA output and one to enable the NAV-PVP message which contains basically all data you would want from a GPS (position, speed, date and the accuracy). Once this is sent to the GPS chip it starts to send a NAV-PVP UBX packet once a second. Then, the GPS acquisition loop in the Crazyflie (currently implemented in the UART task, so it has to be moved into a proper driver) just has to wait for an UBX packet, read it and if it is a NAV-PVT packet then extract values from it. The GPX code has been tested on PC using another uBlox receiver connected to a USB serial cable. Then after copying the newly added uartReceiveUbx() function  into the Crazyflie firmware, the GPS acquisition loop looks like this:

    uartReceiveUbx(&msg, 100);

    if (msg.class_id == NAV_PVT) {
      gps_fixType = msg.nav_pvt->fixType;
      gps_lat = msg.nav_pvt->lat;
      gps_lon = msg.nav_pvt->lon;
      gps_hMSL = msg.nav_pvt->hMSL;
      gps_hAcc = msg.nav_pvt->hAcc;
      gps_gSpeed = msg.nav_pvt->gSpeed;
      gps_heading = msg.nav_pvt->heading;

    ledseqRun(LED_GREEN, seq_linkup);

The last thing, to make the data available from the PC, is to add a GPS log block and to add variables to it:

LOG_ADD(LOG_UINT8, fixType, &gps_fixType)
LOG_ADD(LOG_INT32, lat, &gps_lat)
LOG_ADD(LOG_INT32, lon, &gps_lon)
LOG_ADD(LOG_UINT32, hAcc, &gps_hAcc)
LOG_ADD(LOG_INT32, gSpeed, &gps_gSpeed)
LOG_ADD(LOG_INT32, heading, &gps_heading)

Debugging the firmware code can be done using the client log plotter tab, not so nice to look at positioning but good enough to see if it is working (when the accuracy, gps.hAcc,  goes down the GPS has a fix!):



Once the log block was decided, Marcus could start the client development by updating the debug driver. The debug link is a module of the Python client that behaves like a CRTP (the Crazyflie protocol) link but is in fact just some software running offline. It allows to easily develop and debug the client without requiring the usage of a Crazyflie. The debug link was modified to include all variable that the Crazyflie would eventually contain and to give them some value that can be logged.

When this was done, the GPS tab has to be updated to display actual values, a max speed and reset button is also added (the idea was to measure the Crazyflie speed). After fighting more than expected with the QT layouts the result is good enough:


Note that the client uses the Python binding of KDE Marble which has to be compiled manually. Only Marcus has had the courage to do that on his computer, but luckily he also compiled it on the latest Bitcraze VM so that we can all easily enjoy the new GPS tab :).


Now that the client and the firmware are made separately we ‘just’ have to connect the new client to the new firmware. And guess what? it worked the first time :-) (Yes I know you have no reason to believe me but this time it really worked the first time).

Unfortunately for us last Friday was one of these Swedish rainy day, all we could do was to take turns to stand in the middle of the road outside of our office, in the rain, holding the Crazyflie in a plastic bag and waiting for the GPS to get a fix (people passing by were looking quite strangely at us …). It happens that the rain where not helping at all! And the fact that we don’t have assisted-GPS (yet) means that the GPS would get a fix in 40sec best case, it took about 5-10minutes for us. But eventually we got the fix:



One thing we have to work on is the modularity of the firmware. Things like having a clear and easy to use HAL for peripherals on the extension port. It is on our ToDo list and it would have been useful here to do a cleaner job with the firmware implementation. A good thing is that while this implementation is uBlox specific for the firmware part, it is completely hardware-independent on the client side. It means that it is possible to implement any kind of positioning, with other GPS chip or other technology, and as long as this positioning declares the right log variable the client will work with it unmodified.

As for the GPS, uploading assistance data to the Crazyflie would permit to drastically reduce the fix time to about 10-15sec. Also this GPS is capable of 10Hz update rate which would be nice to test. The GPS on a Crazyflie is still mostly a proof-of-concept and is of course not useful for indoor flight. Though with light winds the Crazyflie is pretty capable outdoor, so with GPS capability it could be interesting to experiment a bit with trajectory planing. Of course this is even more true for country with a warm and dry weather :-).

Before the holidays we said that we would be doing some testing with attaching a GPS receiver to the Crazyflie. For now it’s just a bit of a quick hack, but we are planning on doing more development. Here’s a quick summary of where we’re currently at (yes, that’s a bad joke..).

We attached a GPS module based on the u-blox MAX-7 chip which is interfaced using the UART. The initial plan was to interface it using I2C, but this will probably not work out. We thought that we could use the I2C interface for reading out the data via a normal memory map (like an EEPROM), but the module will continuously stream the data on the bus. This means that the module probably won’t play nice with other devices on the bus (which kind of defeats the purpose of the bus in the first place). So UART it is. By default the module sends NMEA data every second over the interface. There’s lots of information to get here, but what we focused on was the fix status of the module and latitude/longitude/altitude. Currently the firmware doesn’t contain any string library so parsing data from strings sent on the UART isn’t that easy. Instead we decided to just forward all the incoming data on the UART to the CRTP console. On the client side the NMEA data is picked up from the console and parsed. This data is then visualized using KDE Marble, where the position is shown on a map fetched from OpenStreetMap.

So what now? Well, there’s a few things more that we would like to do. First of all the data shouldn’t be sent over the CRTP console, the logging framework should be used for this. So we need to parse the lat/long/alt/fix data coming from the module and place into variables that can be logged. But there’s functionality that we would like that doesn’t fit within the logging/parameter framework, so a new gps port will be added. Using this port we are planning on making more data available (like information about satellites). But the main reason for this new port is to be able to send data to the GPS implementation in order to implement A-GPS to minimize the time to get a position fix. So by downloading the GPS almanac online and uploading via the radio to the Crazyflie the first time to fix should be shortened considerably.

If you would like to give it a try then have a look at the GPS hacks page om the Wiki for instructions. Note that on Ubuntu 13.10 (and probably other distros as well) the Marble build doesn’t include the Python bindings, so you will have to build Marble from source and enable them. If you would like to play around a bit with Marble here are some docs: Python examples and C++ API. If you don’t have a GPS module but still want to try it, then enable the DebugDriver. It will send fake lat/long/alt data to the UI. Oh, and if you figure out how to plot a path over the map, let us know ;-)

A quick note about dependencies for specific tabs in the Crazyflie python client. New tabs are added to the cfclient by creating a python file in the lib/cfclient/ui/tabs directory. So if you would like to add a tab for GPS you would just create a file and this will automatically be picked up when the application starts up. Since we are now adding some dependencies that are just for specific tabs (like Marble for the GPS and PyQtGraph for the Plot) we have also added some decency checking. This means that if you don’t have Marble or PyQtGraph installed when starting the cfclient these tabs will still be listed in the menus, but will be disabled.

Finally, don’t forget about our holiday competition where you can win Crazyflies! There’s still one more week to go before it ends.

[pe2-gallery album=”” ]

For a while Invensense’s gyros has been the MEMS sensors to use in multirotor  applications due to their good performance and vibration rejection. ST Microelectronics are also big when it comes to MEMS sensors but their gyros has not been that good when it comes to handle vibrations. In the beginning if 2013 they released the 3-axis gyro L3GD20 which are advertised to improve this and we thought we finally would do an investigation. So we bought a Pololu  AltIMU-10 board which has ST sensors and also the iNEMO module, LSM9DS0, which is a very sweet 9-axis 4x4x1mm chip. After a bit of a soldering exercise we got them both attach to an accompanying Crazyflie. The AltIMU-10 board we glued to the bottom and connected to the expansion I2C buss. The LSM9DS0 was a bit trickier and we removed the MPU6050 and used some of its components for the LSM9DS0 so we could glue it up-side down to the board. I think the picture speaks for itself. After some quick and dirty coding we managed to get them both working and flying. The flying capability is very similar to the MPU6050 and we can’t really tell the performance apart. We will have to investigate it in more detail and for that we are adding a SD Card breakout to write raw data from all sensors at full speed. That will be the exercise for next week so stay tuned!


[pe2-gallery album=”” ]

This Monday post we are devoting to the community development and we will try to give a short summary of what is going on there. We recently haven’t our selves had that much time to help out with this development, something we intend to change, so all credit goes to the community!

  • A port of the OpenPilot CC3D firmware to the Crazyflie done by webbn. Still under development but video already shows promising results.
  • Altitude hold functionality which is being developed in parallel by many, omwdunkley, phiamo, et. al. We hope we soon can contribute to this as well.
  • Improved thrust control which is being discussed a lot and hopefully we will soon see some ideas realized.
  • A Ruby cfclient written by hsanjuan.
  • The Android client with a lot of work from derf and sebastian.
  • The FPV implementation driven mainly by omwdunkley and SuperRoach. Omwdunkley has made an awesome HUD (Heads Up Display) which we hopefully sometime will see integrated into the cfclient. Check out the video!
We have probably forgotten some of the great development that has been going on recently and if that is the case please write a comment about it and we will update the post with it.

We finally got the time to clean-up the Crazyflie kicad project enough to make it publicly available.  It is not in a perfect shape but should be good enough to use and learn from. It’s a 4 layer board with signal layers on bottom and top and power planes in the middle. We have also uploaded the custom kicad-libs parts which should be placed in the same directory level as the kicad projects in order to make use of them, it also includes Crazyradio kicad parts.

It is released under CC BY-NC-SA license so you are able to use if for personal use, and please respect that. Please also give us feedback if you have some comments or find something that could be improved!

Crazyflie kicad snapshot


There’s an updated version of the Bitcraze virtual machine out. The VM has all the pre-requisites for using the Crazyflie/Crazyradio and also the full development environment for our projects. Here’s a list of the improvements from version 0.2:

  • Upgraded version to of Xubuntu to 13.04
  • Improved README and instructions inside VM
  • Updated to the latest version of repositories
  • Added script for updating all the project repositories
  • Added pre-configured JTAG debugging for Eclipse using BusBlaster
  • Added KiCad and the Crazyradio design files

More information on the Bitcraze VM can be found here and it can be downloaded from this link. If you don’t want to download our virtual machine but instead make your own then have a look at this guide on the wiki.  It details how to get Xubuntu running in VirtualBox with all the pre-requisites for the development environment.

We have finished cleaning up the Crazyradio design files and they are now added to a Bitbucket repo. The project includes a cache file with all the components from our library that we have used. Once we are finished with cleaning up the component library it will also be uploaded.

It’s been an incredible week seeing people from all over the world getting their Crazyflies into the air!! We have seen videos of people doing crazy stuff we never thought of, 3D models of cases and frames on Thingiverse and of course a lot of images of people unpacking and assembling their Crazyflies. The wiki is receiving some well needed updates and everyone is helping out answering questions in the forum. It’s really great for us to see this project come to life after such a long time and as far as we can tell we have a lot of happy users, even though there’s still a few people struggling with issues.

Like we said last week, this is the first time we distribute the software/firmware/hardware widely and there’s a few bugs that has been found. We are currently correcting the most important ones and will post updates for the firmware and software once we fix enough of them. If you want to follow the progress drop by the bug tracker on Bitbucket for the PC-client, Crazyflie and Crazyradio.

We are doing our best to answer questions and give support in the forum, but there’s a couple of issues that we would like to highlight to make the assembly and usage easier for everyone. Please be careful with your new Crazyflies, they are not unbreakable.

  • Check for shorts after solderingAfter the motor wires has been soldered make sure to inspect for shorts and especially to the resistors, red highlighted area, in the picture as it can damage the digital voltage regulator. This will show up as that the blue LEDs wont light up and the other LEDs will be dim. To fix this the regulator U9 will have to be exchanged. It is the SOT23-6 package in the picture.



  •  The Crazyradio doesn’t work on USB3 ports but a fix is on the way. Until then the work-around is to use USB2 ports.
  • If the Crazyflie crashes upside down there is a chance the motor bearing gets depressed. There is a protection for this and that is to carefully glue a spacer between the motor and the propeller, similar to what we have done in the picture. That will prevent the propeller from pushing on the bearing but will instead be pushing on the spacer which will absorb the force much better. The spacer needs to be higher then the motor bearing else it will not work that well.


  • Loading an already existing input-device configuration in the PC-client does not work, the best is to start from scratch (see this issue). Also when configuring the input-device you will have to map all the axis and buttons before you can save the configuration (see this issue). For more information on device-input configuration see this page on the wiki.

Unfortunately the production of the new motor-mounts has been delayed and they will not be available for order until next week. But the kits that are currently in stock still contains a spare motor-mount.

Happy flying!!