There are many parts of the Crazyflie® that can be developed, and before digging in, it helps to understand how the system fits together. Here are some links to key development resources.
The Eco-System – read about the projects, APIs, architecture, protocols and other techie details.
Repository overview - from each element and aspect of our ecosystem, there exists github repositories and accommodating detailed documentation.
Support channels – Know where to look for support when you are getting into trouble.
Github – A list of all the source code, for software and hardware. Here you can contribute and share your work with the community.
The Getting started with development Tutorial – a step by step guide to set up your development environment, build your first custom firmware and download it to the copter.
Contribute your work - Opensource is all about sharing and caring! If you want your code to be preserved and used by more generations, contribute your work back to our code base.
The different systems use different languages. So if you are looking at using a specific programming language, these are the most common ones in our Repository overview :
Make sure to use our coding standard for languages, which will be important if you want to Contribute your code back to our firmware/software.
There are a number of APIs in the Crazyflie eco system on multiple levels, some might be obvious while others are a bit more subtle. Some of the APIs are documented and versioned while there is room for improvement in other cases.
Since all code can be used by a programmer, one point of view would be that all functions and protocols are APIs, and should not change without some form of version change. To make it possible for us to manage and improve the code base, we have chosen a few areas (APIs) that we will update in a structured way (see below). Code that does not belong to these APIs can be changed at any time, which we believe is necessary to keep the system dynamic and evolve over time.
The purpose of managing APIs in a structured way is to help a developer to understand if a protocol or a set of functions is likely to change over time and if it will break the application. It should also be possible to detect if (and how) the API has changed and what changes that are required to the code to make the application work.
Areas that can be versioned using a version number, for instance protocols, should update the version number when something is changed. Check the documentation for the specific area/protocol to see if there is a specific update policy for this area. An example would be CRTP.
For functions in the code base, there is not always a version number tied to the function (except the release version) that
clearly tells the programmer if there has been an API break or not. The approach we use is to mark functions that we
want to remove as deprecated. The deprecated function will continue to exist and work for a minimum of 6 months before
being removed. Deprecated functions are documented in the release notes to give a heads up that they will be removed in
a future release. The deprecation marking is usually done by adding the word deprecated to the function documentation.
Also add a date when the function will be removed (at the earliest) and, if applicable, a replacement function to use
instead or how to change the code.
Example:
/**
* @brief Deprecated (removed after August 2023). Use the "deck.bcLoco" parameter instead.
*
* Nonzero if [Loco positioning deck](https://store.bitcraze.io/products/loco-positioning-deck) is attached
*/
PARAM_ADD_CORE(PARAM_UINT8 | PARAM_RONLY, bcDWM1000, &isInit)
The Crazyflie platform is much more than just a Quadcopter. It consists of lots of different parts working together to complete the system. That means that developers can dive into any given area and experiment, learn and improve.
Here’s examples of a few areas that you can explore:
Check out the Repository overview documentation for more inspiration, especially the crazyflie-firmware.
Even though we detail how to set up the different development environments for the Crazyflie platform, this can be a hassle. Here we will provide a list of tools that can be used to make development easier:
Also check which open source tools we are using / have used at Bitcraze internally to get inspiration on what you would like to use for your case.
Since the Crazyflie platform was intended to be used for experiments and development, we wanted to put in some features that made this easier.
The radio bootloader enables downloading and flashing firmware to the Crazyflie via the radio, so that no JTAG programmer is required. However, for on-chip debugging, the Crazyflie still has a JTAG adapter for those that really want to dig in.
Moreover, the parameter and logging framework enables developers to easily define a special usage for variables, and the parameters are used to change variables in the Crazyflie in real-time.
Check out all the features and specifications of the Crazyflie on the Product page.
All our projects are open and are hosted over at GitHub. This is also the place where you can suggest new features, report issues and find current issues that needs fixing. Apart from this we also host an active discussion page which is mostly used for support but can also start discussions.
You can use the community to discuss your contributions and share your code with the community. That is what it is all about in the open-source world!