Author: Arnaud

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.

A we wrote before, we are working on a Ultra-Wide-Band-based local positioning system for the Crazyflie. We are doing slow progress but progress anyway and we wanted to do a small update on it.

We are at our second revision on the anchors, they are now based on an STM32F072 CPU which has the advantage to have an USB bootloader which will useful to update them on the field. We are trying to think about either or not we should implement more communication like Ethernet to the anchor. Our main use-case is to get the localisation in the Crazyflie but we are aware of use-case where the localisation is required on the ground instead. If you have any input on the design of Ultra-Wide-Band anchors please let us know.

We have also made a 3D printed support for attaching the anchors to the ceiling or ground:

stand

As for the localisation, we are able to range from the copter to the anchors and we are logging the range using the Crazyflie 2.0 log subsystem. We have tested logging data in a csv file and running a Particle filter to find the copter position, more about the filter in a future post.  So far it looks good but we need a nicer way to visualize the data. The way we are taking is to learn and use ROS.

ROS is a system used by researcher in robotics and it implements a lot of things like visualization and state of the art algorithm. Wolfgang from USC has written a ROS driver for Crazyflie and it is about time we are getting into ROS. It is a learning process for us but the plan is to implement and test the UWB local positioning system on top of ROS, which will allow us to use its components and reduce development time.

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.

bigquaddeck

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:

BuzzerSelect_w

buzzerdeck

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:

gpsdeck

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 :-):

wifideck

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.

The last week has been really busy here at Bitcraze. We are working on regular bugfixes, support and new Decks to be release as soon as possible. But at the same time, we have moved our office in a new building (still in Malmö, Sweden) which is a lot of work, even more for us who have a lot of random hardware lying around. We left Minc, the incubator that hosted us since our beginning as full-time company. We where really happy at Minc, it has been a great place to work and evolve. We thought it was time to move to get closer to other hardware companies and to have a bit more space.

We are now at The Ground. It is a co-working space for startups that hosts some very cool companies. We are really happy to have moved there and are just started to settle-in. We now have a lab separated from the office (which is a first for Bitcraze, we are a bit anxious to be so far from the soldering iron but lets see how it works :-). The great news is that we are going to use the basement as an autonomous-flight-lab to develop the DWM-1000-based local positioning system. I am sure we will have more news on that in later posts.

Another important change: we now have a new member in our team! Björn, who arrived last week, will look, among other things, on refreshing the website and all our communication. The current website state is fully made by hardware engineer and we thought it should be shaped-up a bit.

Björn

Björn

Seeedstudio is our manufacturer and our main distributor. Last week Mandy from Seeedstudio came and visited us after being at Maker faire Rome. She did a very interesting talk at Minc, our incubator, about manufacturing in China and how Seeedstudio helps with agile manufacturing. The interest was high here in Malmo, it is not often someone from China comes to Sweden and talks about manufacturing. Usually you would have to travel to China to find out more about that.

If you would like to know more about what she talked about the slides are available on Slideshare: