This week we merged a pretty big change in the Crazyflie firmware code repository. The change altered the way we configure and build what goes in to the drone. We now make use of the Kbuild build system.
The Kbuild build system is the build system used, foremost, by the Linux kernel, but is also used in other projects like Busybox, U-Boot and sort of Zephyr. It is mostly known from its terminal based configuration tool, menuconfig.
Kbuild leverages Kconfig files to build up an hierarchy of configuration options to use when building the software. It allows you to setup dependencies between your configuration, allowing us to do things like only enable the Kalman filter when there is a deck driver that needs it enabled.
This new way of building the firmware replaces the old way of using config.mk to set the build defines you need. Our hope is that Kbuild will make it easier to customize the Crazyflie firmware to fit the need of your department or project.
What does this mean for you?
If you are not changing the firmware as part of your Crazyflie development this will not change anything for you. The Python library will continue to work just like before and Bitcraze will release official firmwares, just like before.
If you are in the habit of fetching and building the latest and greatest version of the Bitcraze firmware there will be some minor changes. This can be seen in our updated build documentation on the web. The biggest deal is that the firmware code needs a configuration file before building is possible. To get the default one you can go:
$ make defconfig
make[1]: Entering directory '/home/jonasdn/sandbox/kbuild-firmware/build'
GEN ./Makefile
scripts/kconfig/conf --defconfig Kconfig
#
# configuration written to .config
#
make[1]: Leaving directory '/home/jonasdn/sandbox/kbuild-firmware/build'Code language: PHP (php)The way to compile app-layer applications has changed a bit and you will need to adapt (sorry!) the new way of building your app-layer application can be seen in the updated documentation.
If you make heavy use of config.mk and frequently change code in the firmware there are many new possibilities for you. Check the documentation and keep reading this blog.
Making the firmware more modular
With the new build systems help we hope to make it easier to enable and disable features and sub systems in the quad copter. In the default firmware all drivers for all expansion decks are included, as well as all estimators. If you are pushing a feature or experiment that need more RAM or flash, that might be inconvenient for you.
As an experiment we can try building the current maximum-, minimum- and default configuration of the Crazyflie. We say current because the work to make the firmware more modular is ongoing.
The default configuration, the official firmware, we can obtain by invoking the special make command defconfig.
$ make defconfigAnd building the maximum is done using allyesconfig this gives us configuration file with all options enabled.
$ make allyesconfigAnd conversely the minimum configuration can be set using allnoconfig, which will disable all features that can be disabled.
$ make allnoconfigThe resulting firmware sizes can seen in the table below:
| Build | Flash | RAM | CCM |
|---|---|---|---|
| defconfig | 232 Kb (23%) | 76 Kb (59%) | 57 Kb (89%) |
| allyesconfig | 428 Kb (42%) | 80 Kb (62%) | 57 Kb (90%) |
| allnoconfig | 139 Kb (14%) | 62 Kb (48%) | 45 Kb (71%) |
This shows some of the potential of the modularization of the firmware. We hope it will make it easier for you to get your stuff to fit, without having to hack around in the code too much.
Making it easier for us to merge your contributions
The new system makes it easier include code in the firmware repository without necessary needing to include it in the official firmware. This will make it easier for us to merge controllers, estimators, algorithms, deck drivers and other stuff from you.
We can include them in our Kconfig files, allowing people to select them and build firmware using them and we can make sure they get (at least compile) tested as part of our continuous integration. So you can sleep soundly knowing your code will not suddenly break with new versions of the firmware.
Creating and distributing your own config
If you want to create your own configuration, and spread it around you can do so.
You can use:
$ make menuconfigTo create a base .config file with your special configuration. If you copy the file, or have us merge it, to the configs/ directory.
$ cp build/.config configs/waggle-drone_defconfigThen it will be possible for other people to build your configuration by going:
$ make waggle-drone_defconfig
make[1]: Entering directory '/home/jonasdn/sandbox/kbuild-firmware/build'
GEN ./Makefile
#
# configuration written to .config
#
make[1]: Leaving directory '/home/jonasdn/sandbox/kbuild-firmware/build'Code language: PHP (php)But it would also be possible to just add the configuration that differ with the default configuration to your config file:
$ echo CONFIG_PLATFORM_BOLT=y > configs/waggle-drone_defconfig
$ make waggle-drone_defconfig
$ grep PLATFORM build/.config
# CONFIG_PLATFORM_CF2 is not set
CONFIG_PLATFORM_BOLT=y
# CONFIG_PLATFORM_TAG is not set
Code language: PHP (php)Help out and test it please!
This is quite a big change and we are still shaking out bugs. Please give it a test run and report any issues you find!
If you want to help out, there is a GitHub project that contain the issues we know about, feel free to grab one and contribute your solution!
Happy hacking!
Aye, Linux but also very in line with Zephyr Project. Ever consider moving to Zephyr from FreeRTOS?
Anyway, I used the KConfig straight away and it’s looking pretty good!!
We are using Zephyr in Crazyradio 2.0, so we are aware of it :-). We have not really considered it for the Crazyflie yet, we may in the future. One of the Zephyr potential shortcoming for Crazyflie is that the Device Tree configuration was very hard to get right (with horrible error messages from the C compiler when something is wrong), and is very static. I am not sure how this would work out for Crazyflie expansion ports and various decks that are detected and initialized at runtime.