Author: Jonas Danielsson

We are happy to announce the availability of the 2021.06 release of the Crazyflie firmware and client! This release includes bugfixes related to flashing the Crazyflie and the Lighthouse deck and also the new concept of core parameters and logging variables, that we talked about in the blog post: Crazyflie logging and parameters interface.

There are new binaries for the Crazyflie (2021.06), the Crazyflie client (2021.6) as well as a new release of the Crazyflie python library (0.1.16). The firmware package can be downloaded from the Crazyflie release repository (2021.06) or can be flashed directly using the Crazyflie client.


Noteworthy features and fixes

Crazyflie STM firmware

* Added an app layer application of the wall following demo
* Fixed a bug where the initial position of the Kalman estimator was set to (1.5, 0, 0)
* Enable an estimator to be added by out of tree build
* Add and document core parameters and log variables
* Fix deck info mem implementation can return uninitialized buffer
  - Caused: Flashing errors with Flowdeck
* Rechecked INDI controller for mistakes/consistency

Crazyflie NRF firmware

* pm: Increase delay before powering system
  - Caused: Issues flashing Lighthouse deck

Crazyflie Python library (0.1.16)

* Add support for crazyflie-link-cpp
* Add get_value to parameter class
* Make tutorial more user friendly
* Improve reset_to[firmware|bootloader]

Crazyflie Client

* Do not allow upgrading firmware when connected to USB
* Console tab: new messages should always appear at the bottom
* Update install doc

Documentation

* Core logging groups and variables
* Core parameter groups and variables
* Improved motion commander tutorial

Help us out!

We always strive to release quality software and firmware, but we are not perfect! Please help us out by installing the new library, client and firmware and make sure that your applications, tools and algorithms still work as you expect! And if not please file an issue with us or contact us via the forum.

Happy hacking!

Background

In the past couple of weeks we have been busy trying to improve the development interface of the Crazyflie. We want to make developing with and for the platform a more pleasant experience.

We have started looking at the logging- and parameter framework and how to improve it for our users. The aim of this framework is to easily be able to log data from the Crazyflie and to set variables during runtime. Your application can use them to control the behavior of the platform or to receive data about what it is currently up to. As of today, in the firmware there are 227 parameters and 467 logging variables defined.

View from the cfclient of the different logging variables one could subscribe to

These logging variables and parameters have been added to the Crazyflie firmware over the course of years. Some are critical infrastructure, needed to be able to write proper applications that interface with the platform. Some are duplicates or were added as debug years ago. Others have in some way outlived their usefulness as the firmware and functionality has moved on. The problem is that we have no way of conveying this information to our users and this is what we are trying to rectify.

An attempt of stability

We are currently reviewing all of our logging variables and parameters in an attempt to make the situation clearer for our users … and ourselves. We are adding documentation to make the purpose of each individual parameters and logging variables more clear. And we are also dividing them up into two categories: core and non-core.

If a parameter or logging variable is marked as core in the firmware that constitutes a promise that we will try very hard to not remove, rename or in any other way change the behavior of it. The idea is that this variable or parameter can be used in applications without any fear or doubt about it going away.

If a variable or parameter is non-core it does not mean that it is marked for removal. But, it could mean that we need more time to make sure that it is the proper interface for the platform. It means that it could change in some way or in some cases be removed in later firmware releases.

The reason for doing this is twofold: we want to make the Crazyflie interface clearer for our users and we want something that we feel we can maintain and keep an up-to-date documentation of.

What is the result?

We have introduced a pair of new macros to the firmware, LOG_ADD_CORE and PARAM_ADD_CORE which can be used to mark a parameter or variable as core. When using these we also mandate that there should be a Doxygen comment attached to the macro.

Below is an example from the barometer log group, showing the style of documentation expected and how to mark a logging variable as core. Parameters gets treated in the same way.

/**
 * Log group for the barometer
 */
LOG_GROUP_START(baro)

/**
 * @brief Altitude above Sea Level [m]
 */
LOG_ADD_CORE(LOG_FLOAT, asl, &sensorData.baro.asl)

/**
 * @brief Temperature [degrees Celsius]
 */
LOG_ADD(LOG_FLOAT, temp, &sensorData.baro.temperature)

/**
 * @brief Air pressure [mbar]
 */
LOG_ADD_CORE(LOG_FLOAT, pressure, &sensorData.baro.pressure)

LOG_GROUP_STOP(baro)

We have also added a script In the firmware repository: elf_sanity.py. The script will return data about parameters and logging variables that it is included in a firmware elf. This can be used to count the number of core parameters. If we point it to a newly built Crazyflie elf, after we’ve done our initial review pass of the parameters and variables, we get the result below.

$ python3 tools/build/elf_sanity.py --core cf2.elf 
101 parameters and 78 log vars in elf

To produce a list of the parameters and variables you can add the --list-params and --list-logs options to the script.

What is the next step?

Once we have finished our review of the parameters and logging variables we will explore different ways of making the documentation of them available in a clear and accessible way. And we will come up with a scheme for making changes to the set of parameters and variables. Once this is all finished you can expect an update from us.

The end goal of our efforts is making developing for the Crazyflie a smoother process, and we would love to hear from you. What is confusing? What are your pain points? Let us know! So we can do better.

Hi all! I am Jonas Danielsson and I started at Bitcraze on the first of March. I am a software developer with experience of Linux-, open source- and embedded development. Sometimes all at once.

Jonas and Bosse out hiking

I have worked with embedded systems of different sizes since 2007 and look forward to getting to know the Crazyflie and all of its ecosystem.

I am interested in and care a lot about software- and product maintenance. At Bitcraze I hope to be involved both in developing new features, fixing bugs and finding ways of keeping the product and code in nice shape. To find ways of working that allow us to add a bunch of cool stuff as fast as we want to, without endangering the cool stuff we already have.

Also, I am interested in getting to know the Crazyflie community and to work together with you to create the best development experience we can achieve. Do not be afraid to reach out with ideas or suggestions on how we can improve!