Category: Electronic

We are excited to announce that we have just started the production of the first boards for the Loco Positioning system!
Since this is the first batch of a complex new product, we thought we should be there in person. This time, Tobias and Kristoffer went to visit Seeedstudio, our product manufacturer. It is always very nice to meet them in person and to visit the factory.
Also visiting the factory is always an opportunity to discover a new fashion style!


The first boards to be produced are the Loco Nodes:


After a minor problem: we specified the LEDs to be mounted reversed, quickly found and fixed for this first batch by the Seeedstudios engineers, the production of the nodes is looking good and the first 8 pieces are flawless!


To go with the nodes, we need to have the Loco decks. Like for the other decks we have implemented the test rig based on a Crazyflie 2.0 programmed with special flags for the test. We found some issues with the rig software but it has been quickly sorted out. So the launch of the deck production, tomorrow Tuesday, should be without any hick-ups. This is what a deck test rig looks like (note the Crazyflie 2.0 being attached on the bottom):

In other news we’re welcoming Aman in the Bitcraze team for the summer. Aman is flying straight from Kiruna at the very north of Sweden (before that from Germany and even before from his university in the US). He will be looking at improving control and stability of the Crazyflie. The fist step today was to learn how to fly it manually :-).

As we already talked before in a couple of post, we are currently developping a local positioning system for the Crazyflie based on ultra-wide-band radio DWM1000. This is one of our main focus currently so we wanted to post a short update on our progress.

We have assembled and shipped a couple of LPS system already and so far the performance and progress are great. We now think that we have the copter flying as good as we can have it without running sensor fusion and the control loop in the Crazyflie microcontroller. Next step is to integrate algorithms in the Crazyflie.

We are currently working hard at finishing the design to make it ready for production. We will write more updates about that so stay tuned :).

We have shot a short video demonstrating the current state, see after the video for more information about the setup:

To make this video we have installed 6 anchors. 3 are above the room and 3 at about 50cm from the ground. The Crazyflie has a LPS deck and ranges in a round-robing fashion with all 6 anchors. The ROS driver pulls the ranging, estimate the Crazyflie position, and calculate a corrected roll/pitch/thrust in order to keep it at the pre-defined setpoint. The Yaw is not controlled externally, it is kept by the Crazyflie internal gyroscope only.

The ROS computer was setup according to the instruction on our wiki, and by launching the pf_hover launch file:

roslaunch bitcraze_lps_estimator dwm_loc_pf_hover.launch uri:=radio://0/110/2M x:=1.5 y:=5 z:=1.2

Early Access

For a long time now we have discussed the BigQuad deck which basically can transform your Crazyflie 2.0 into a bigger quad by attaching it to a bigger frame. The first simple prototype we did using the prototype deck was made already in the fall of 2015. As it turns out the BigQuad deck requires plenty of software and ads a whole new level of caution. That along with limited time and resources has slowed down the development progress. To overcome parts of this hurdle we came up with the early access program. It is basically hardware which is ready, but the software is in a early and rudimentary state. This way eager development users can get hold of the prototypes we are working on and to try out the latest and greatest designs. The benefits are mutual, we make it possible for our users to get started with new hardware and development at an earlier stage in the development cycle, in return we hope the community will help out with important feedback and contributions towards finalizing the product. First out in this program is the BigQuad deck.

BiqQuad deck

We run each “early access” project as an open project on github, in this case the repository is named early-access-big-quad-deck and is the focal point. Since many changes in the Bitcraze software stack spans over multiple repositories (firmware, clients, radio and so on), this “early-access” repo is where to post issues or feature requests, discuss solutions and what to implement. We love to collaborate with the community, join the fun!

The current sparse user documentation of the BigQuad deck is put on the corresponding wiki page. Let’s add more!

Crazyflie family

Crazyflie family

Crazyflie 2.0 used in Ericsson Mobile World demo

Erricsson have presented a demo for Mobile World congress using the Crazyflie 2.0 and the wireless charging deck.

The crazyflie was also present for the keynote in the hand of the Ericsson CEO. I is always nice for us to see Crazyflie being used for cool demo and events :-).

Last week and today we have been busy at making the first DWM1000-based LPS system we are currently developing.

As usual with hardware and production nothing goes according to plan. We sometime envy people working only with software, but then we think about how awesome it is do make physical things. Anyway the plan was to start producing the boards middle of last week but some components where missing. Then we discovered that the regulator we chose did not have the right pin-out (we are quite ashamed about this one, we assumed all regulator had the same pin-out ….). Finally we discovered that the reflow oven was melting the plastic component (connector and buttons), adding small pieces of tin-foil over the plastic parts fixed the problem.

At the end, we managed to start production with a good rhythm this afternoon. We have assembled half of what we where aiming for and the last half will be done tomorrow. As announced before we intend to sell this first pre-pre-production to anyone interested in having early access to the local positioning system (we think university, but getting it to the hands of research lab or hackerspace would be awesome too). If you are interested please drop us a mail.

We have also started to document the LPS system, and we have pushed the DWM1000 open-source C driver, nodes and deck driver to our github.

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.



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.

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.

DWM1000 nodes
Last hacking-Friday we have had some time to put together the DWM1000 boards we ordered during the summer. The DWM1000 from Decawave is an ultra-wide-band ieee802.15.4 radio transceiver that can very precisely timestamp packets arrival and departure. More simply it means that it is a standard and it can be used to implement a real time local positioning system: this could be really handy for the Crazyflie. We soldered all the boards and we got some basic ranging working on the nodes. The next step is to implement an opensource driver to be able to implement the ranging in the Crazyflie. We will keep you updated on the progress but in the mean time here is a photo of the prototypes:

DWM1000 nodes and deck


Things happening on the firmware side
Recently the commit rate for the Crazyflie 1.0/2.0 firmware has increased a lot. Some of it because of pull requests, great work, and some because we are starting to move in hacks and such on feature branches into the master branch. Our new college Kristoffer has taught us that having stuff on feature branches can be a bad idea, they tend to stay there. It is then better to have them compile switched and in the master branch as it is more visible and get a better chance of getting in for real.

Github crazyflie firmware contributions


Here are some of the recent thing going on:

  • A situation awareness framework originating from this pull request by fredgrat. It allows the Crazyflie 1.0/2.0 to react to triggers. Currently there is a free-fall, tumbled and at-rest detection. He recently also submitted an auto-takeoff functionality. Enable the functionality with the define here.
  • The beginning of a Arduino like API for the deck port. Currently GPIO and ADC are the only functions there but more will come.
  • Possibility to fly in rate (acrobatic) mode committed here. Support in the cfclient for this is being developed so currently one have to change the parameters to activate it manually.
  • Carefree, plus and X-mode implemented in firmware. There is also support for this being added to the cfclient.
  • Automatically switch to brushless driver. Motor driver being rewritten so it can be dynamically configured. This means that if the Crazylfie 2.0 is attached to the big-quad-deck it can automatically switch over to the brushless driver during power on.

Summertime are good times, less administration and more time to develop! As soon as things has been integrated and fully tested we will do a new release of the firmware and the cfclient :).

Starting this week we’re all back at our desks and after getting some time off, recharging our batteries, we’re slowly getting up to speed again. The summer has been spent on everything from improving our server environment to cleaning up both the firmware and the client. We’ve also been working on some new things, like the iOS bootloader and prototyping new decks for the Crazyflie 2.0.

Now it’s full speed ahead into an exiting fall with lots of things happening!

As a side note we are going to Maker Faire Berlin the 3&4th of October and we are planing to do a Bitcraze meet-up in Berlin while we are there. We started a thread in the forum to talk about it.

Big Quad Deck
Today we received the revised big-quad-deck PCBs. We made the connectors fit a bit better, and fixed the deck port connectors being mirrored,  and it is starting to look quite good. Next up is to implement the firmware functionality, which is the biggest work. If you have any ideas or suggestions on the design please let us know!

Big-quad-deck v2

Big-quad-deck v2 mounted


Continuing from last Monday post where the hardware wiring part was discussed we now move on to the software side. The brushed motors are controlled with a normal PWM  where the duty cycle will adjust how much power goes into the motors. A brushless motor on the other hand needs more complicated controlling and uses it’s own micro-controller to handle this. These brushless motor controllers (BLMC or Brushless ESC) comes in many flavors and sizes but what is pretty common is how they are interfaced/controlled. This is inherited from how R/C receivers are controlling servos and how the receiver gets updates from the transmitter. This is a PWM where the width of the high pulse define the duty cycle. 1ms equals min and 2ms equals max and this is repeated every 20ms, thus giving an update rate of 50Hz.ServoPwm

This way of interfacing the BLMC is currently the most common way but interfacing with I2C, CAN, etc is getting more common.

To generate the servo PWM on the Crazyflie we have just reconfigured the timer a bit using a conversion macro so that setting the motor ratio of zero will result in a 1ms high pulse and setting it to max (uint16) will result in a 2ms pulse. The period time can be set with the BLMC_PERIOD define in motors.h. The standard period time of 20ms is actually a big drawback as it adds a latency from when a new output is calculated to when it is actually set. Therefore many motor controllers allow to shrink this period down to 2.5ms (400Hz) which result in lower latency and better flight stability.

Brushless prototype board

First you need to put together the brushless prototype board from the last post. The output will be generated on the pins marked BLMC 1,2,3,4 which should be connected in the same position an rotational direction as the brushed M1, M2, M3, M4 respectively. The output signal will be 0v – 3.0v which should work fine with 5V BLMC but it might be worth keeping that in mind.

BL proto descr

Building the brushless firmware

The code which contains the brushless functionality is currently on the bigmerge branch so start by pulling the latest changes and switching to that branch.

git pull
git checkout bigmerge

Then to activate the brushless functionality enable the brushless defines


This can be done by by either creating defines in config.h or by creating file in the same directory as the Makefile with the content:


The period time BLMC_PERIOD is by default set to 2.5ms (400Hz) so change that if needed.

Then build the firmware (make sure to clean first)

make clean

It will build for the Crazyflie 2.0 and for wireless bootloading by default. Put the Crazyflie 2.0 in bootloader mode by holding the power button until the blue led start to blink, then flash it with the wireless bootloader (Crazyradio required).

make cload


You are now probably dealing with powerful and dangerous stuff so make sure to take precautions. E.g. don’t have propellers mounted when you test! When you have taken all the safety precautions do your first test. Remember the Crazyflie firmware has not yet been developed for big quads, it is all at your own risk! And another thing, even though the Crazyflie 2.0 can be controlled using a mobile device we don’t recommend this, use a Crazyradio.


With that cautions being said it is great seeing a big quad fly and we will soon put out a video showing some of our builds. Our bigger quads have flown quite well with the stock tuning (PID parameters) but tuning should be done as well. Plenty of guides can be found on ways how to do it so I will not go into details here. The values can be found in pid.h and can be updated (but not saved) live using the cfclient. To save them the pid.h file must be changed and the firmware flashed again.