As some of you might know, we are working full ahead on developing a local positioning system for the Crazyflie 2.0 ecosystem. There are many things to be done and we just took two major step by improving the stabilizer code architecture and moving the position control code into the firmware. Getting the position from an external system is fine and dandy, but we also have to control the pitch, roll and yaw of the Crazyflie to keep its desired position. Up til now we have been running this control algorithm outside the Crazyflie in an external computer, but now we have moved it into the Crazyflie itself. The controller is a simple PID controller and can definitely be improved, but the main purpose of the work has been to improve the architecture in this area. We know there are people in the community working on position related features and we hope the new architecture will make it easier for us all to implement the bits and pieces needed to get an autonomous Crazyflie. The estimation of the position has not been implemented in the firmware yet but the architecture now has support for it.

The general layout of the new architecture is as follow:

• The sensors are gyroscope, accelerometer and pressure sensor. More could and will be added in the future like position and altitude measurement.
• The state estimator calculate an as good as possible estimate of the Crazyflie state using the sensor values. The state contains the Crazyflie orientation (roll, pitch, yaw), its position and speed. Currently the state estimator has complementary filters for the orientation and the altitude. In the near future the full position will be estimated as well.
• The commander generate a setpoint to be followed by the Crazyflie. Currently this is only done by receiving commander packet from the ground using Crazyradio or bluetooth low energy.
• The state controller generates control output to achieve the requested setpoint from the current state.
• Finally the power distribution is translating controls from the controller into driving the actual motors.

This is implemented in stabilizer.c and each block is implemented in there own file. Stabilizer.c used to be very verbose and complex to read and modify, it has now been greatly simplified and the above architecture is implemented in one short loop (see the full code in GitHub):

while(1) {
  vTaskDelayUntil(&lastWakeTime, F2T(RATE_MAIN_LOOP)); // 1KHz

  sensorsAcquire(&sensorData, tick);
  stateEstimator(&state, &sensorData, tick);
  commanderGetSetpoint(&setpoint, &state);
  stateController(&control, &sensorData, &state, &setpoint, tick);
  powerDistribution(&control);
  tick++;
}

Our philosophy with this new architecture is to keep the code as simple as possible and to allow customisation at compile time. The high-level functions have as simple as possible interface and so can be exchanged easily. So if tomorrow, we have a shiny new controller we just have to compile it instead of the current PID controller. We think that this fits the way the Crazyflie is used, as a development tool.

This is just the beginning: there is still some more to clean-up in the functions and we will most certainly enhance the code from feedback. Please tell us if this is useful and how it can be enhanced even more.

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.

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.

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.

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:

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!).

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.

We have stared to look at what is needed to make the Crazyflie position aware and to integrate the upcoming positioning system. The rough idea is to add a position estimation module to the firmware of the Crazyflie that will be responsible of estimating the current position based on data from internal or external sensors. The sensors could be mounted on the Crazyflie but it should also be possible to inject the position over radio from an external system. A control module will use the estimated position to try to navigate the copter to a desired position that could be set for instance by a user or by some navigation algorithm. If you want to participate in the design discussions or implementation head over to github where we will use issues for this conversation.

We decided that a suitable first step was to improve the altitude hold, so that is what we did last week. The code has been refactored and improved and we think the altitude hold is now working much better than before. It’s not perfect, still room for improvements :-)

Tilt compensation

While we were at it we also added a thrust compensation to avoid loosing altitude when tilting the copter. It turns out it makes flying easier as the pilot does not have to add extra thrust when moving around. Good for both human and automatic pilots.

Hackster.io

Have you checked out our projects on hackster.io? Help out and make Bitcraze a featured platform by adding your own project or just follow us, we need 10 projects and 25 followers to be featured. You can make a difference!

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.

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