New Crazyradio 2.0 Swarm-optimized firmware 5.1

2025-12-08 | Arnaud | Leave a comment

We are thrilled to announce that we just released a new firmware version for Crazyradio 2.0. This version implements a new USB protocol, called inline mode, that makes it much better at handling swarms of Crazyflie_^TM. The following measurement, made by Wolfgang Hönig, shows the improvement in latency scaling when using Crazyradio 2.0 v5.1 with the latest Crazyswarm:

Visit to the Multi-Robot Systems LAB in TU Berlin

This work started with a visit to Wolfgang’s lab in TU Berlin. Wolfgang is the original developer and maintainer of Crazyswarm 2, and has seen first-hand the problems Crazyradio 2.0 had with flying swarms. After a week of work together we made enough progress that we almost had Crazyradio 2.0 working with Crazyswarm.

The “almost” part was because Crazyradio 2.0 exhibits a bug when sending high frequency of broadcast packets mixed with uni-cast packets. This is primarily visible in Crazyswarm when flying at least 8 Crazyflies in a MoCAP system. The inline-mode implemented in 5.1 actually side-steps this bug.

What is inline mode

Crazyradio has quite a long legacy, the USB protocol dates from the original Crazyradio which was implemented to control Crazyflie 1. At this time, the main use-case was to fly a single Crazyflie. So, the protocol was optimized for connecting a single link. Setting link properties like radio channel and radio address uses USB-setup transaction, which are useful side-channel commands provided by the USB protocol. These setup transaction are not optimized to be fast though, they are designed to send occasional device commands, which was well suited for the original use of Crazyradio.

Flying with a swarm came later, and while the USB protocol was not optimized for this, it worked well enough. When controlling multiple Crazyflie, Crazyradio will communicate with each Crazyflie one after another. This requires setting up radio between each packet, which means at least as much Setup transaction as regular USB-Bulk transaction used for the packets. Things are worst with a MoCAP system, since the position of all the drones needs to be sent at a fast rate to all the drones, which is much more efficiently done using broadcast packet. This requires one mode setup transaction to activate/disable broadcast mode.

This is the main improvement of the inline mode. All radio parameters that matter when communicating to multiple Crazyflies are now sent as a header to the radio data packet itself, using the performant Bulk transactions used for data. This makes the communication to a swarm more performant and, more importantly, it scales much better.

Before one could expect ~1200 packet per seconds to a single Crazyflie and ~600 with 2 and more. Setting parameters used a lot of time limiting the performance. The new inline mode offers the same performance for one and many Crazyflie: the 1200 packets per seconds are shared equally between all connected Crazyflie. This should double the number of Crazyflie one can fly per Crazyradio.

How to use it

As of writing this blog post, the inline mode is only implemented in the latest commit of Crazyswarm 2. Implementation in the Crazyflie Python lib and the Rust lib are planned and should land before 2026. The mode will be enabled by default if Crazyradio 2.0 is updated to Firmware 5.1 or later. So if you want to benefit from the performance boost, update your Crazyradio by fetching the new firmware.

Future of Crazyradio 2.0

There is still a lot more to be done. Of course we will not have another 2x gain, but we have not reached the limit of what the Crazyradio 2.0 can achieve yet. Early tests with the “fast ramp-up” mode of the radio shows that we should be able to improve latency by another 10% quite easily.

We are, however, still limited by the current USB protocol philosophy that synchronize USB and radio communication. Decoupling both is already prepared in the inline protocol but might require more drastic re-engineering of the USB protocol.

Robotics and Simulation developer room at Fosdem 2026

2025-11-10 | Arnaud | Leave a comment

For the second year, we are helping organize the Robotics and Simulation developer room (ie. devroom) at Fosdem. This is a community effort and I, Arnaud, am part of the organization committee for this devroom. Tldr: last year’s edition was a great success, propose a talk for this year!

Collage of the 2025 Robotics and Simulation Developer room

Fosdem is the biggest open source software conference in Europe. It is free to attend and happens the weekend between January and February in Brussels, Belgium.

The conference is organized with a main track as well as … devrooms. A devroom is very much like a small conference in and of itself: Fosdem allocates a room and the video recording. The dev room managers are responsible for publishing a Call for Participation to get people to propose talks, reviewing the talk proposals, and organizing the room so that all goes smoothly on the day.

Last year, we were allocated Sunday afternoon to host a Robotics and Simulation dev room. It went really well, we had so many talk proposals that we had to refuse some, and the room was so full that we had to refuse the entrance to some people during talks (Fosdem rightfully takes fire safety very seriously, so we cannot pack rooms over capacity).

We are thrilled to announce that we got a full-day room this year! This will allow us to have many more talks and hopefully to reach even wider in the robotics landscape.

If you, or anyone you know, has anything interesting to talk about and present, please have a look at the Call for Participation. The deadline for the proposal is on the first of December, and the main requirement is that it covers an open source project. A talk should highlight both foundational capabilities and new AI-driven approaches, showcasing practical progress and key takeaways. The topics could include, but are not limited to, core robotics libraries and applications, frameworks for building robotics systems, simulation tools, or open-source-friendly hardware platforms. See the CfP for more details. You can also look at last year’s talks for some inspiration.

We look forward to meeting you in Brussels this year!

New DeckCtrl architecture: The Future of Deck Enumeration

2025-10-06 | Arnaud | Leave a comment

One of the unique characteristic of the Crazyflie platform is the fact that decks (the Crazyflie expansion boards) are detected dynamically at startup. This makes the platform pretty much plug and play: plug a flow deck and you can fly autonomously with relative positioning, no configuration or recompilation required.

In this blog post we will present a new system we have implemented to identify and enumerate decks. This is intended to be the new default from now-on and can be used by anyone who wants to make a Crazyflie-compatible deck.

Current system: 1-Wire Memories

This is currently achieved using 1-Wire Memories. These memories can be discovered and addressed using a guaranteed unique serial number. This means that there can be as many memories as we want on the bus and they can all be discovered and read.

In the Crazyflie ecosystem, every deck has a 1-Wire memory that contains the identity of the deck. At startup, the Crazyflie discover and read all the memories which allows to discover all the decks and initialize the corresponding deck driver.

The future: DeckCtrl

The current system works very well but is has two major shortcommings:

The 1-Wire memory we are using does not provides GPIO or any other control. It makes it impossible to control the deck “out-of-band” in order to switch it on/off or launch a bootloader for example.
The 1-Wire memory has only one manufacturer and, because of a lot of reasons, we can only use a single model of it. At times it has caused us stress when the chip availability is low.

The new DeckCtrl-based system addresses these two problems by using a regular micro controller over I2C and provides support for GPIO as well as, in the future, UART, SPI and any other protocol that might be needed to handle the deck startup and configuration.

DeckCtrl is mainly a protocol definition. The current implementation is for STM32C011 micro controllers. While this could be implemented on any micro controllers, we will likely stick to the STM32C011 for the foreseeable future.

Deck discovery over I2C

One of the main innovations is the development of a new discovery and enumeration algorithm over I2C. Indeed, one of the main difference between I2C and 1-Wire is that 1-Wire memories are addressed using a 64Bit unique serial number while I2C uses 7 (or 10) bit addresses. This means that it is impractical to assign a unique I2C address to each device, and even if we tried to assign one address per deck type it would make it impossible to detect the same deck multiple times on a Crazyflie.

To solve that problem we designed a protocol that allows starting all DeckCtrl on the same address and enumerate them so that we can select all of them one by one, and then assign them a unique address on the bus. At a high-level this behaves very similarly to DHCP, where all devices will be assigned an address dynamically.

Once the decks have all been configured, it is possible read a memory to recover the deck identity and initialize deck drivers as we are currently doing.

Just that is a great step forward for Bitcraze: we are not dependent anymore to a single model of 1-Wire memory.

Deck life-cycle control

The second major improvement is what I called earlier “out-of-band” control of the deck. By that I mean that we can have control over the deck that is independent from the deck’s main micro controller chip. This is something we have long missed to, for example, be able to put decks in bootloader mode. The solution that has been used for the lighthouse deck is to always start in bootloader mode and then boot. This works, but has proven to be impractical for some use-cases and is not possible with all micro controllers.

The new DeckCtrl protocol defines space for GPIO control and the possibility for more in the future. This allows for example to switch ON and OFF a deck in software if one of the GPIO is used to control the deck power supply. We can also control the Reset and Boot pin of a micro controller in order to put it in bootloader mode.

Our goal there is to greatly simplify the design of more clever decks based on micro controllers. This will allow us, and anyone interested in making decks, to make more competent decks while making is easy to develop the firmware for them. For example, we will be looking at allowing to reprogram decks without having to restart the Crazyflie, which will make it much easier to develop and iterate.

Status

We have now finished the first iteration of the DeckCtrl protocol design and implementation. There is also a driver that exercises the GPIO part of it, this has been tested to work on many identical decks at the same time on a dev-deck we use for development:

This has been done in the context of the High-Power LED deck project. This future deck will feature a powerful RGBW LED which will be controlled by a micro controller onboard the deck. So it will be seen as an I2C device from the Crazyflie side. This design also shows the intent of DeckCtrl as this deck has 2 STM32C011: one implementing DeckCtrl and one application micro controller implementing the LED driver and other useful functionalities like color correction and temperature monitoring.

Towards the Rust Crazyflie Lib

2025-09-01 | Arnaud | Leave a comment

We have already had a few discussions about putting more Rust into the Crazyflie ecosystem. One of the places where we find it could be the most beneficial is to replace the current Python-based Crazyflie Lib.

Why a Rust Crazyflie Lib

Rust is a modern system programming language that prioritizes reliability and productivity. This means that it is a language that will have enough performance for any current use-case of the Crazyflie lib, and nice enough to use that we can write code that is correct and easier to maintain. So in a way, switching from Python to Rust, is a move to benefit the main lib developers, us here at Bitcraze.

Furthermore, Rust has binding capabilities to almost everything. So, with a Rust implemented lib, we can target languages for all current users of the Crazyflie: mainly Python and C++ (for ROS). This means that we can make and maintain one lib for everyone.

This would be mainly interesting for the Crazyflie ecosystem because it would lift the Crazyflie API one notch. Currently, if you want to talk to the Crazyflie in C++, Swift, Kotlin, or any other language that is not Python, you have to re-implement the radio link as well as all binary radio packet handling that communicates with the Crazyflie. Our goal is to raise that to the Crazyflie lib: the Crazyflie lib would then become the Crazyflie API.

This does not mean that we want to prevent anyone from playing around with the radio packets, but we do not want that to be a requirement for interacting with the Crazyflie.

Status

Since we last talked about it, there has been quite some progress with the Crazyflie rust lib. First of all it has been moved from my personal GitHub to the Bitcraze Github. It is now an official day-time Bitcraze project :).

The lib has also been used by Marcus to make a Crazyflie-cli. This is a very useful tool when developing or working with the Crazyflie. It makes it possible to observe values, set and get params, and more, directly from the command line.

Finally, the Crazyflie Rust lib is now used in the production test rig for the Crazyflie 2.1 Brushless. We have a new rust-built test system for production that was developed for Crazyradio 2.0, and the Rust Crazyflie lib is now part of it for producing Crazyflie 2.1 Brushless. This means that the Rust lib is now officially in use and needs to be maintained! A side-project it is no more :-D.

Future, where are we going?

We have been thinking for (way too) long about what strategy we would take to introduce the Rust Crazyflie lib. The plan we currently have is to replace the current python lib, but to keep as much as possible of the current python API. The goal being to run the Crazyflie client on top of the Rust lib.

This would not only improve the client and lib reliability and performance, but it will also prove that the Rust lib is full featured enough to be used by more clients. Then we can target C++ and even Swift and Kotlin to finally improve our mobile clients.

Finally, one ‘dream’ that might be enabled by this move is to be able to make a Web-client. There are still a couple of technical hurdles (for example the fact that we for now only support the Tokio async executor), but this lib would be the foundation for a WASM mobile client. Imagine configuring and controlling your fleet of Crazyflie directly from a web-browser. Of course we need to focus on what can work today first, but this might become possible in the future thanks to Rust.

Making the Crazyflie 2.1 Brushless charging dock

2025-08-11 | Arnaud | Leave a comment

At the beginning of the year, we released the Crazyflie 2.1 Brushless charging dock. This project was very much an experiment for us since this is the first product we are mainly manufacturing and assembling by ourselves in Sweden. We though we would write a little bit about the reason we made it that way and how it is going.

The Chaging dock is already described in a brunch of pevious block post. It is basically a landing pad for the Crazyflie Brushless that charges the Crazyflie when landed. This is an idea and a design we have been using for years for our fair demos and that has been very useful, we would not be able to continuously fly at fair without it! Some of us even started using is on their desk to keep their Crazyflie Brushless fully charged at all time while developing with it:

However, even though it has been so useful for us, and we designed the Crazyflie Brushless to be compatible with contact-charging, we where not sure of how many people out there would want or need such a charging dock. So we decided to make it available in an experimental manner by manufacturing it by ourselves!

Why ‘made in Malmö’?

While the manufacturing we have in place for all our other products works really well, it requires a non-trivial amount of effort to start the first manufacturing batch. This is mainly due to the fact that the full mass production chain needs to be setup for the first batch and that production happens outside Bitcraze, this requires a lot of work in documentation, planning and administration.

However by doing the production in house, we are able to fix issues as they arises and to work in a much more agile way. In house production will of course no scale, but for a proof of concept it might work, this is at least what we wanted to experiment with.

There are two main improvements that has allowed us to even consider in-house experimental production: the advent of cheap and efficient PCBA services and the improvement in 3D printers reliability. This allows us to source all the parts and assemble them to make the final product.

How is a Charging Dock made?

The charging dock is comprised of two main parts: the plastic landing pad and the electronic.

The Landing pad is 3D printed by us. We now have a mini-print-farm at the office (if a Swarm starts at 2 drones, a print farm shall start at 2 concurrently running printer :):

What made it possible for us to consider running this kind of production was when we got our Bambulab X1 carbon. It is much more reliable and most importantly easier to maintain that any printer we got before, which gave confidence that we could start making products of what we printed. We now have an H2D as well. This currently allows us to print 12 landing docks per working day.

On the electronic side, we are now able to order fully assembled PCB, and even custom cable within weeks.

All we then need is assembly and testing and we got ourselves a small production line with very little risk and a lot of flexibility.

What now?

We are very pleased with what we have achieved so far with the charging dock. The first batch is sold out and we have started manufacturing a new batch with no big pain-point in sight. At some point we will have some decision to take though: do we continue in house or transition to more traditional manufacturing? Will all the work we put so far be useful for setting up mass manufacturing or will we have to restart from zero? At what batch size or frequency will we need to transition?

However this is also one of the great advantage of this: we have full control and we can decide when to manufacture where. As we have talked a bit previously, Bitcraze is a self-organized company, and this experiment actually fits very well with our way of working and keeps us agile. We hope this can free us from the doubts we usually have when thinking about more ‘niche’ products and will allow us to try new things in the future.

A 3D-Printable case for Crazyradio 2.0

2025-06-30 | Arnaud | Leave a comment

Lately, at home and at work during my Fun Fridays, I have been trying to learn more about 3D CAD and more precisely about FreeCAD, mostly in the context of (ab)using our 3D printers :). Inspired by a couple of Crazyradio cases that have already been published, I started working on a Crazyradio 2.0 case since this has not yet been done, I am quite happy about the result:

The design is mostly press-fit: the top and bottom parts are pressed together and hold thanks to the 3D printed layers interlocking in each-other. The LED lens is pressed in the top and the button actually slides and is guided by the top. The button is flush with the case since it is mainly a bootloader button and is not required to be pressed during normal use.

ECAD/CAD design

One of my goal when starting with this project was to experiment working both with Electronic CAD (KiCAD in my case) and Mechanical CAD (FreeCAD). There is an extension for FreeCAD that allows to go back-and-forth between the two tools, but in this case it was much simpler since my board was already finished, so I only needed to get a model of it in FreeCAD.

To do so, I made sure all the important components had 3D models in the Crazyradio electronic design. I had to import a couple of models from Mouser, and had to re-create the RGB LED in FreeCAD. I then exported it as a STEP file. This file can be imported in FreeCAD and retain all the interesting shape and surfaces useful to work with the model:

Shape binder: Keeping it DRY

Coming from the software/electronic world, we have this notion of DRY: Do not Repeat Yourself. Ideally I would like to apply the same to mechanical design and avoid as much as possible to write any measurement by hand. one way to do that with FreeCAD is with Shape binder. A good example of its use is with the LED lens.

I wanted to put a translucent lens just on top of the Crazyradio LED. One way to achieve that is to create a Shape binder of the LED top surface onto the TOP and Lens. The LED top is the yellow square in the next picture and its presence allows to align perfectly the hole in the top cover to the middle of the LED on the PCB. This prevent all hazardous manual measurement when placing the hole.

For the lens design I can go one step further, I can create a shape binder both for the LED and for the hole in the top layer, this way the shape of the lens is derived from existing geometry and, to a large extent, does not have to be specified manually:

This allows to quite easily align the lens perfectly on top of the LED. The same principle is used for the button to get it to slide and press on the PCB switch with minimal play.

Final product

I pushed the current state of the case on GitHub. It is also available on Maker World. I plan on improving the design before deciding to name it 1.0 and to eventually upload it on Printables and Thingiverse.

If you want to learn more about FreeCAD, I can recommend this great video series on YouTube, it goes through a lot of very useful functionalities like the shape binders.

Improving our Python project management

2025-06-23 | Arnaud | Leave a comment

With the Swedish summer upon us, things are more calm at Bitcraze. The summer is usually a time for us to look a bit more at fixing infrastructure and other things that we do not have time to work on the rest of the year. One of the things I have been looking at improving lately is the state of our Python projects.

We currently use Python as the default language for everything we do on PC. This includes the Crazyflie lib, Client and other tools for our ecosystem. Over the years the state of the Python projects have greatly evolved. It started in ~2011 with almost no project management at all; just Python files. Then we switched to setup.py/pip support. Recently the Crazyflie client got the pyproject.toml treatment. Now that most Linux distributions prevent pip install-ing packages we need to juggle with venvs in order to use or develop in Python.

In essence, Python started with an easy to use language but has now become quite complex and hard to handle. Things become even more complicated when we take into account CI in Github actions that have to test that our projects actually work with all supported version of Python on Linux/Mac/Windows.

A bit of Rust (tooling) in our Python

As you might have gathered from our previous blog posts over the years, we like Rust quite a bit at Bitcraze and hope to use it more in our products moving forward. One of the great parts of Rust is the quality of the tooling and of the compiler feedback. Cargo as a project management tool helps a lot working with projects in a comfortable and repeatable way.

This is why we are now quite interested in using uv going forward as an official tool to work with the Bitcraze Python projects. uv can replace both venv and pip and makes working with a Python project as easy as working on a Rust one with cargo. It is also very fast and efficient since it is written in … Rust of course :-).

We are also looking at switching from Flake8 to Ruff and Ty for linting and type checking respectively. These two tools, from the same developer as uv are very fast and give very high quality error messages and warnings – this should make it much easier to maintain good code quality.

These changes would mostly be on our documentation and development side. The resulting projects are still compatible with pip and can still be used as they where used before. However we would make sure the projects can be efficiently used with uv.

Example

The Crazyflie client is currently already fully able to run with uv since it already uses the ‘new’ pyproject.toml project config file. So working with the project, from within the project folder, would look like that:

crazyflie-clients-python $ uv run cfclient    # Run the Crazyflie client GUI
(...)

crazyflie-clients-python $ uv run ruff check  # Check the code, runs in ~100ms!
All checks passed!

crazyflie-clients-python $ uv run pre-commit
      Built cfclient @ file:///(...)/crazyflie-clients-python
Uninstalled 1 package in 0.97ms
░░░░░░░░░░░░░░░░░░░░ [0/1] Installing wheels...
Installed 1 package in 4ms
[WARNING] Unstaged files detected.
[INFO] Stashing unstaged files to /home/arnaud/.cache/pre-commit/patch1750684440-121836.
flake8...............................................(no files to check)Skipped
[INFO] Restored changes from /home/arnaud/.cache/pre-commit/patch1750684440-121836.Code language: Bash (bash)

This last command is a great example of the usefulness of uv: currently one need to install pre-commit on a virtual environment, enter it, and run pre-commit in the project. With uv is just works out of the box. In the back of course, pre-commit is installed in a virtual environment in the project folder. But this is all done automatically.

Finally we will also easily be able to test multiple versions of Python:

crazyflie-clients-python $ uv run --python 3.10 pre-commit
Using CPython 3.10.18 interpreter at: /home/linuxbrew/.linuxbrew/opt/python@3.10/bin/python3.10
Removed virtual environment at: .venv
Creating virtual environment at: .venv
      Built cfclient @ file:///(...)/crazyflie-clients-python
    Updated https://github.com/bitcraze/crazyflie-lib-python.git (3a35d22026c2ed8251b821e4f5b10e67091f811f)
      Built cflib @ git+https://github.com/bitcraze/crazyflie-lib-python.git@3a35d22026c2ed8251b821e4f5b10e67091f811f
░░░░░░░░░░░░░░░░░░░░ [0/32] Installing wheels...                                                                                             warning: Failed to hardlink files; falling back to full copy. This may lead to degraded performance.
Installed 32 packages in 699ms
[WARNING] Unstaged files detected.
[INFO] Stashing unstaged files to /home/arnaud/.cache/pre-commit/patch1750684632-123219.
[INFO] Installing environment for https://github.com/PyCQA/flake8.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
flake8...............................................(no files to check)Skipped
[INFO] Restored changes from /home/arnaud/.cache/pre-commit/patch1750684632-123219.Code language: JavaScript (javascript)

And, for the end user, uvx also simplify running the client:

$ uvx cfclient   # Pulls and run cfclient from Pypi
(...)

$ uvx --from cfclient cfloader
      Built cfclient
Installed 22 packages in 164ms

==============================
 CrazyLoader Flash Utility
==============================

 Usage: /(...)/.cache/uv/archive-v0/_OZwn5_zGeTE-qFoK_kEG/bin/cfloader [CRTP options] <action> [parameters]

The CRTP options are described above

Crazyload option:
   info                    : Print the info of the bootloader and quit.
                             Will let the target in bootloader mode
   reset                   : Reset the device in firmware mode
   flash <file> [targets]  : flash the <img> binary file from the first
                             possible  page in flash and reset to firmware
                             mode.Code language: HTML, XML (xml)

This last command would likely be added to all our firmware Makefiles to be used when calling make cload to flash the Crazyflie.

Feedback?

This currently does seem like a good idea to us. If you have any feedback or ideas on how to handle Python projects in a better way we are very interested to hear them. Like I mentioned, the summer is kind of a ‘clean up’ time for us so this is when we have time to look at this kind of things.

State of the Crazyflie mobile apps

2025-04-21 | Arnaud | Leave a comment

For quite some time now we have had mobile apps that can be used to control the Crazyflie 2.x quadcopter. There is one iOS and one Android app available. There used to be a prototype of a Windows phone app but it has not survived the demise of Windows on phone (fun fact, the windows phone app can be compiled to run on XBox, however there is no USB access in there so it is quite useless). In this blog post I want to talk about the state of the apps and a possible future for them. As usual with me, the future should include a bit ot Rust :-).

Android app

The Android app is the oldest of the mobile apps, it has been created originally to be used with a Crazyradio conncted to an Android phone over USB. Then, when we released Crazyflie 2.0 with Bluetooth Low Energy, BLE was added to the app to be able to Connect to a Crazyflie without radio attached.

Over the years, the Android app has mainly been maintained by FredG, one of the very first Crazyflie contributors. The app supports controlling Crazyflie using touch-control as well as using an Android-supported Gamepad. It also has support for showing the Crazyflie console, controlling some decks and assisted flight using the flow deck.

It also supports updating the Crazyflie firmware using a Crazyradio connected on USB. This functionality is unfortunately broken since we altered the update process when changing the Crazyflie bluetooth stack last year.

The Android app is also working on Chromebook. This means that it can be used to fly the Crazyflie form a chromebook using Crazyradio of BLE. This is one of the only way to control the Crazyflie from Bluetooth on a laptop.

iOS app

The iOS app is newer and much simpler. It has had a couple of really good contribution over the years but overall it has seen much less development than the Android app. I have tried to keep it up and working but nothing more so far.

The iOS app was released when we made the Crazyflie 2.0. Since iOS does not let us communicate with USB devices, it can only work using Bluetooth Low Energy. It can control the Crazyflie using touch control as well as motion control using the IPhone gyroscope.

The iOS app also had support for updating the Crazyflie over Bluetooth, however, like for the Android app this is now broken and it has been removed in a recent release. I hope to be able to add it back soon.

With the advent of the Apple Silicon Mac, the iOS app is now also a Mac app. Like for the Android app on Chromebook, this gives the unique ability to communicate with the Crazyflie over Bluetooth from a computer. However it still has no USB support for Crazyradio and until we implement Gamepad support there is no way to control the Crazyflie from a Mac using the app.

The future

Some of the biggest issues for the development of the mobile app so far has been a lack of specification and the difficulty of re-implementing Crazyflie protocol for each app.

For the former, the apps have been created at a time where flying the Crazyflie manually was one of the major use-case. Nowadays, it is much more common to fly autonomously. This means that the apps should be able to do more to be really useful. Manual flight might still be needed to test the Crazyflie or just to play around. But the app could also have a much greater use for things like assisting in setting up positioning system or swarms. We are still not sure what would be needed or useful yet so if you have any ideas please tell us here as a comment or on Github discussions.

For the later, the difficulty of re-implementing the Crazyflie lib, this is something we have had problem with on multiple front. For example this is also a problem for ROS support and for Crazyswarm. The main problem is that the official Crazyflie lib is implemented in Python, and Python happens to not be a good choice for most cases due to limited portability and performance. One solution we have been imagining and working towards is to implement the Cazyflie lib in Rust and then implement binding for Python, C/C++, Java and Swift. This will cover our current python client, ROS, Crazyswarm as well as all the mobile app. It should allow to get much more done much more easily on mobile, since we will not have to start by re-implementing the wheel each time and will be able to focus on actual functionalities.

One idea, would be to start now with implementing the Crazyflie update algorithm in Rust and to use is from python and the mobile apps. This is a good first target, since this is a non-trivial really annoying piece of code in all languages, and it is also one that must be as bug-free as possible. So having a single implementation that is well tested and can be used everywhere would be very beneficial to the Crazyflie ecosystem.

I hope I managed to convey where we are and where we want to go with the mobile app. If you have any feedback please tell us about it.

Robotic track at Embedded Linux Conference Europe 2025

2025-03-24 | Arnaud | Leave a comment

This year at the Embedded Linux Conference Europe 2025 the 25-27th of August in Amsterdam, there will be a Robotic and simulation sub-track!

This is a follow-up of the Fosdem robotic and simulation I and Kimberly helped organize at Fosdem 2025. The Embedded Linux Conference is taking place this year in the Open Source Summit Europe and we helped by providing some insights on what a robotic track could look like!

This is a very interesting open-source conference, on the opposite side of the spectrum to Fosdem. We are very excited that there is interest in organizing robotics talks there as well, since there are a lot of very important and great open-source projects in the robotic space. I will definitely be joining this year!

This track will explore how open-source technologies are shaping the robotics industry, from software frameworks to simulation projects. There will be talks about tools and their impact, offering insights into both their development process and real-world implementation. If you are interested in giving a talk about your project, you can find the Call for Proposal on the OSS website. The deadline for proposals is the 14th of April and speakers get to attend OSS for free which is a nice perk :-).

A last technical note, the robotic and simulation subtrack, is intended to contain only full 40min talks. So to summit your talk, you need to choose the “Embedded Linux Conference” track, “Robotics” topic and “Session Presentation (40min)”.

FOSDEM 25

2025-02-17 | Arnaud | Leave a comment

As written in my previous blog post, Marcus and I have been visiting FOSDEM 25 at the beginning of February 2025 in Brussels, Belgium. This year we helped organize the first Fosdem Robotic and Simulation devroom!

Attending FOSDEM

I have been attending FOSDEM every year since 2015 (except 2020 and 2021 unfortunately …) and while it continues to grow year after year, it is still an awesome experience. It is a great place to talk to the people that make the software we use every day and to get new ideas.

This year we have had very good talk at different booth, most notably at KiCAD and Zephyr, since they are key to the work we do at Bitcraze. We could also attend a couple of really nice talks even though all the dev-room were full most of the time. And as usual we have also seen a lot of random booth and talk that sparks enough ideas to last a couple of years :).

Robotic and Simulation dev-room

Speaking of full dev-room. We helped organize the Robotic and Simulation dev-room this year. This is the first time there is a robotic dev-room at Fosdem.

The room was a success, it was full all-along and we have very nice talks. It was great to have a meeting point for robotics at Fosdem and we will definitely do it again next year!

If you missed it, most of the talks video are now available on the Fosdem website in the robotic and simulation dev-room page.