Blog

During the autumn we introduced the docker based builder images that are used for builds on the CI server. They make sure the build environment is well known and reproducible which is key on the build server, but they can also be very useful when building code locally on your machine. The obvious upside is that if a build passes in the builder on your local machine, it should also pass on the CI server but the really nice thing here is that you don’t have to install compilers, frameworks or tools on your machine, the builder handles all that for you! The drawback has been that it requires some typing to use docker, for instance building the crazyflie-firmware project would require you to type

docker run --rm -it -v ${PWD}:/module bitcraze/builder tools/build/build

That is quite a lot of typing and to solve that we now introduce the Toolbelt, it makes it dead simple to compile or test any bitcraze project.

The Toolbelt is a set of scripts that fires up the correct builder image and then executes your build script in that container. When done, the container is shut down and disappears. For instance to build the crazyflie-firmware project with the toolbelt, locate your self in the root of the project and type

tb build

Thats it!

So how do you install it? How does it work? The toolbelt it self is also running in a docker container(!) so all you need is to install is Docker and add an alias to your .profile or .bashrc file. Run a toolbelt container to get instructions on how to install

docker run --rm -it bitcraze/toolbelt

or read the (limited) documentation on the wiki, the github repo and the help.

The toolbelt works with almost all our projects such as firmware for the Crazyflie, the radio and even our website project! The toolbelt is tested on linux and OSX. It will probably work on windows as well but we have not tested it, so if you fell inclined, please contribute any insights or fixes to the repository.

Does the Toolbelt replace the VM? No, the toolbelt is simply another option, the VM will still be around. The VM offers a more complete solution than the Toolbelt, while the toolbelt is more light weight and lets you work with your normal editor and other tools you are used to.

Let us know what you think and happy hacking!

logo

If you haven’t watched it already, make sure to watch the TED talk “Raffaello D’Andrea: Meet the dazzling flying machines of the future”!

We are super excited to see that they use the Crazyflie 2.0 drones for the firefly swarm demo in the end of the talk. After all, our goal is to enable people to test their ideas, so this awesome demo makes us thrilled!

Greetings all community members!

This week we have a couple of requests that we hope you can help out with. First of all we would love to hear about all the cool projects you are using the Crazyflie for out there. We have wanted to collect this for a long time and now we have found hackster.io. Go to https://www.hackster.io/bitcraze/projects and add your favourite project. Also make sure to follow us at https://www.hackster.io/bitcraze, if you don’t have an account already it’s quick to create one, our hope is to use hackster.io to create a new way for our community to grow.

glove_closeup

Secondly we are curious of how the Crazyflie is used in education. If you are using it as a teacher or as a student, we would be very happy if you send us an email to education@bitcraze.io and describe how you use it and any other feedback you have.

Last week we finished the manufacturing of the first alpha builds of our new positioning system. A few systems have been shipped to selected users for initial trials but we still have a few left, so if you are interested in trying one out, drop us an email at contact@bitcraze.io and describe what you would use it for.

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.

So as usual at Bitcraze it’s been a busy week. We have made a complete makeover of the front page of our website. The main goal has been to communicate what Bitcraze and the Crazyflie is about, in an engaging way to our visitors. We have added sections where we try to explain common use cases for the Crazyfile and all the exciting areas it is used in. We have also added a “used by” section where we want to collect all the cool organisations that use the Crazyflie. Since we made the site open, send us a pull request if your organisation is missing or if you find anything else that you think should be improved. By the way, we got the first pull request for the site the other day :-) Awesome! Finally we have updated the team member page, so now you can see what we look like and what we do.

We hope you like it! We love feedback, please share your thoughts.

Aside from being busy at the office we’ve also had a busy (and awesome) weekend at FOSDEM! When we go to conferences we normally try to either talk or exhibit something. But for FOSDEM we just wanted to take it easy and meet people, have interesting conversions and listen great talks. We had a great time and we’re definitely coming back next year. We were especially excited to catch Fred’s lightningtalk on the Crazyflie 2.0 and AdaCore’s talk on re-implementing the Crazyflie 2.0 firmware using SPARK and Ravenscar. The videos from the talks still aren’t available, but when they are we’ll make sure to let you know. Below are some images from our weekend at FOSDEM.

 

At last Fred published the slides for his talk:

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!

fosdem16

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.

 

 

There has been much discussion at bitcraze on where to put informations, forum or website. The website is more pretty and more accessible but it can only be updated by us. The wiki can be updated by anyone but it is less accessible and tend to contains much more details. We now solved this debate!

I’m happy to announce that in the spirit of open source and collaborative work, we have published the source code and content for our website on github. It is now possible for anyone to contribute to the website through pull requests on github, so if you want to add, updated or remove something, please go ahead! The code contains all static content, while the blog is still handled by a WordPress instance that lives elsewhere.

github_bitcraze_website

We have tried to make it as easy as possible to work with the code, start a server and see your changes in a browser – check out the “quick start” in the readme.md for details. Most of the content is still in html, but we are aiming at converting as much as possible to markdown over time. We hope that it will make it more accessible and super easy for everyone to work with the site.

Happy updating! And please tell us what you think about this new website.

 

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.

Connector_multiplexing

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,
};
DECK_DRIVER(helloDriver);

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.