Author: Arnaud

As early as when the first Crazyflie prototype did it’s first flight back in 2009, we where dreaming about a local positioning system that would allow our future micro quadcopter to fly autonomously indoor. This dream is now becoming a reality with the development of the Ultra Wide Band radio that we have been using the last months to develop our own local positioning system for the Crazyflie 2.0. We are now reaching a very important milestone: the first early access production batch has been ordered!

We sat down to find a name for the system and since ‘Crazy’ is kind of a theme for our products here at Bitcraze we settled for “Loco Positioning”. So the two products we are about to launch are the Loco Positioning Node and the Loco Positioning Deck.

If you want to receive information as the system evolves, sign up to our mailing list. If you want to talk to us directly do not hesitate to comment or send us a mail at locopositioning@bitcraze.io.

The positioning system is based on the Decawave DW1000 Ultra Wide Band radio chip. These radios work by transmitting very short pulses instead of full sinus waves the way a standard radio would, and the advantage for positioning is that it is possible to measure the time at which these short pulses are received very precisely. By using clever algorithms it is possible to measure the time it took for the radio signal to “fly” from one radio to another and from that we can calculate the distance between the radios.

A basic system is composed from a number of Anchors (Loco Positioning Nodes) at fixed positions and a Tag on the Crazyflie 2.0 (the Loco Positioning Deck). The system continuously measures the distances from the Tag to the Anchors and calculates the position of the Tag from that information. The concept is similar to GPS where the Anchors represent the satellites and the Tag the GPS-receiver. 4 Anchors is the theoretical minimum required to calculate a 3D position, but 6 has turned out to be more realistic number.

We have designed the Loco Positioning Nodes as standalone boards containing a micro controller and the DWM1000 UWB radio module. The nodes are intended to act as Anchors: they are setup at fix positions in the room and will serve as references for the system.

locopos_node

The Loco Positioning Deck, also based on theDWM1000 module, acts as a Tag and plugs into the Crazyflie 2.0 expansion port. It allows the Crazyflie 2.0 to calculate its absolute position in space and this is all we need to start flying it autonomously in the room. In this case the Crazyflie 2.0 acts as a Tag, but since we are always striving for flexibility, the nodes can also act as Tags for example for other robotic application.

logopos_deck

We consider the first batch to be an early access release. This means that the hardware is finished and tested but the software is still very much work in progress. Currently the Crazyflie ranges with the Anchors, while a PC running ROS interprets the ranges and calculates the estimated position. More in depth information will come if future blog-posts and e-mails on the list. For a video and some more information see our previous post “Update on Local Positioning System“.

Crazyflie 2.0 already has two mobile clients, one for Android maintained by Fred and the iPhone client. Now we officially have a new one on development: the Windows client.

IMG_20160425_202412

Theseankelly, from the community, has started a Windows client for Crazyflie 2.0. It connects Crazyflie using bluetooth low energy and works both on phone and on PC running windows. Last week, he transferred the source code repos in the Bitcraze github so that it can have more visibility. We plan to eventually released it in the Windows store, but first it needs to have a little bit more features :-). To this end we have created a milestone on GitHub and have filled a couple of tasks. The plan is to get to a minimum set of functionalities. That for, we will focus on phone support first but if you are interested in PC support do not hesitate to say so and push tickets for it (gamepad support and configuration is the first thing I can think about for desktop support).

Last week Fred released a new version of the Android client. The outstanding new feature is a support of the LED and Buzzer decks when using Crazyradio! It means that you can now change the light effects and play sounds on the Crazyflie from the phone. This is even better because it means that the Android client code is now able to access the param subsystem and soon the log subsystem: this will allow for much more interactions in the future (like access to advanced Crazyflie settings and supporting more decks). The support of decks using BLE and more are on going so stay tuned and if you have any functionality request please head to the GitHub ticket tracker.

aclient-deck

We have just released a new version 2016.04.1 of the Crazyflie client.

client_2016.4.1

The biggest change is actually not so visible but very important: we have now separated the GUI client from the Crazyflie lib. The great advantage is that the lib became a small project and could be pushed to pypi. This means that if you want to control Crazyflie from your own Python program all you have to do is to “pip install cflib” and you are ready to “import cflib” in your program to control the Crazyflie.

For the new release of the client we also pushed the client in pypi as well. This will be mainly useful in Linux and Mac where you are now able to install the client with “pip3 install cfclient”. One little drawback however: since the GUI lib we are using, pyqt, is not in pypi it has to be installed on the side. This can be done in Ubuntu with something like “sudo apt-get python3-pyqt4 install python3-pyqtgraph” or on Mac with homebrew or MacPorts.

Last but not least we have enabled Windows continuous integration with appveyor and fixed the Windows build. This means that a Windows build and installer are going to be generated for every commit in the Crazyflie client repos. Maintaining the Windows client has always been a challenge to us since we are mainly Linux users, so the this will help a lot to keep good Windows support. We still consider this Windows build to be somewhat experimental so please test it and report any bug you are hitting.

The last system to support for executable distribution is Mac. We did put some time trying to generate a mac app out of the client without any success. If anyone wants to give it a try or have some tips please head to the ticket on github.

Historically the main way to control a Crazyflie has been by using a computer running a Crazyflie client and communicating with a Crazyradio (PA). However since very early we have made an Android client that also communicated using the Crazyradio. This was at the very beginning of USB On-The-Go for Android and it allowed to fly without a PC. When we released Crazyflie 2.0 with Bluetooth LE support we made an iPhone client as well as adding bluetooth to the Android client.

The Android App is the oldest and thanks to the community the most fully featured. It has a community maintainer, Fred, that is doing a great job a keeping the app stable and adding features.

android_client

With the Android app you can fly with both touchscreen control and game-pad control. It works with Bluetooth and Crazyradio. It can update Crazyflie 1.0 and Crazyflie 2.0 firmware using Crazyradio and soon Bluetooth for Crazyflie 2.0. Soon the possibility to use deck functionality like LED ring and Buzzer will be added.

The iPhone app is, for the moment, a bit more simple:

ios_main

 

It allows to fly and update Crazyflie 2.0 using Bluetooth low energy. There has already been a couple of contribution to keep the app up to date with Apple dev tools and more featured are currently being pushed.

Finally there is a new one coming soon. A windows 10 app prototype has been done by theseankelly and is just waiting to be enhanced. The exciting parts is that it works on Windows phone but it is also the first Bluetooth GUI client for Crazyflie 2.0 on desktop platform (there is nodejs libs that supports BLE on computer but no GUI that I know off, if I am wrong please comment!).

windows_client

A great thanks to all the contributors, the mobile clients for Crazyflie would not be that far without you! If you are interested in mobile development you are welcome to contribute, these clients started as a “just to fly” remote control but they could do so much more.

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

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.

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.

 

 

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.