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.

Bitcrazers at FOSDEM 2025!

2025-01-27 | Arnaud | Leave a comment

Marcus and I are going to visit FOSDEM 2025 at the end of the week. This is a great open-source conference that I visit every year but this year there is a twist: I am part of the organisation of the Robotics and Automation devroom! I am going to give the welcome talk there:

FOSDEM is a conference with many tracks, the main track and devrooms. Devrooms are like mini-conferences: they are handled by a committee that produces a call for participation and handles the schedule for the room. FOSDEM allocates a time slot, a physical room, and video recording for the devroom so that all talks are broadcasted in real-time and recorded.

Since my first visit to FOSDEM in 2015, we have been thinking about the lack of a dedicated devroom for robotics: a lot of robotics, at least in research, is open source. This is in part thanks to ROS, which allows for easily sharing modules and algorithms between projects, but it also applies to things like flight stacks that are often open-source. So we took it upon ourselves to organize what we wanted, a robotics-dedicated devroom.

We started last year, at FOSDEM 2024, by organizing a robotics Bird of Feather with Kimberly. These are impromptu meetups that can be organized by booking a time on the spot for a couple of dedicated rooms. There, we had some really nice discussions with fellow robotics enthusiasts and figured out that there was indeed quite some interest in robotics at FOSDEM and that we were enough interested parties to organize a devroom.

If you’re interested in open source and/or robotics and you can be in Brussels, Belgium, on the weekend of the 1st and 2nd of February 2025, please join us! The Robotics and Simulation devroom is on Sunday afternoon. I will also be monitoring our Mastodon channel more carefully, so do not hesitate to poke me if you want to meet either me or Marcus, as we will be at the conference both days.

Looking forward to 2025

2024-12-30 | Arnaud | Leave a comment

2024 is almost over and 2025 is coming fast so it is a good time for us to think about what is coming for Bitcraze in 2025.

Projects

2025 will be the year of the Crazyflie 2.1 Brushless! We are finally releasing it early January. The end of the development phase was longer that expected (who would have thought manufacturing would be hard … :-), but it is now ready and we are very excited to see what awesome projects the community will come up with using the Crazyflie Brushless.

With the Crazyflie 2.1 Brushless released, we will have more time to dedicate to other projects. Following is a list of fields we think we might look at, no strong promises here though and if you think we should focus on anything specific do not hesitate to drop a comment under this post, a post on github discussions or just send us an email. We have way too many ideas, but we are always open to more :-).

We still have the Lighthouse deck V2 in the back-burner, this is likely something we will look more at soon. As a reminder, the new deck is going to support lighthouse systems with 16 base-stations which will increase the space that can be covered by a lighthouse system

We also have a Wifi camera deck in early prototype, we have been showing it at various conferences in the last years. We are still working on trying to find the perfect Wifi-chip/processor/Camera combo to make it a reality.

We (ie. I) also have a lot of ideas on how to improve the communication with the Crazyflie. Crazyradio 2.0 has a lot of untaped capabilities that we can use to implement better, easier to use and more reliable communication protocols so this is definitely something we want to have a look at.

Finally, I apparently managed to sell the Rust programming language a bit too well to the team. Some of us are even more enthusiastic than I am about it! This together with an increased frustration with Python and PyQT6 distribution to various platform will likely make us experimenting even more in Rust in the future. The first target in sight is to write a Rust lib for the Crazyflie together with binding for various languages including Python and C/C++. This means that would be able to have only one lib for most use case of the Crazyflie both in Python and in ROS.

Conferences

Arnaud is part of the organizing committee of the FOSDEM Robotics and Simulation devroom at Fosdem. Fosdem is one of the biggest open source conferences in Europe. It is an awesome community-driven conference, so if you are not too far and are interested in open-source please join us in Brussels the 1st and 2nd of February 2025!

As usual we will likely participate to a couple of robotic conferences during the year. We are not yet sure which one though so stay tuned for more information on this blog.

Team

The team has been evolving in 2024, we are now 6 in the Malmö office, Mandy is working from Shenzhen in China handling the production and Joe is doing a post-doc in Stockholm in close collaboration with us.

We are actively looking at hiring 2 more team members, one in technical support and one in Sales. Our goal is to build a team where all of us can focus on our strengths to develop even further and faster the Crazyflie ecosystem.

We wish you a great new year filled with hacking and exciting new discoveries!

Back from ICRA 2024

2024-05-27 | Arnaud | Leave a comment

Two weeks ago, Arnaud, Barbara and Rik were at ICRA 2024 in Yokohama. At our booth we showed our current products as well as the upcoming brushless Crazyflie and the camera deck prototype.

As usual, the conference has been very busy with a lot of visitors and a lot of very interesting discussion. Thanks to everyone that passed by the booth, we have come back to Sweden with a lot of energy and new ideas!

The autonomous lighthouse swarm demo demo has worked pretty well. If you are interested to know more about it you can visit our event page. It is an autonomous demo with 3 brushless Crazyflies and 6 Crazyflie 2.1s flying autonomously. With the extended battery life of the brushless, we could operate the demo pretty much continuously.

If you’ve been at the conference, you may have spotted someone proudly sporting our exclusive ‘Bitcraze took my poster’ button. We’re excited to have received posters covering a wide range of topics, the walls of our office are eagerly awaiting these visual representations of your hard work and dedication. Thank you to everyone who has contributed.

Crazyflie client: past, present and future

2024-03-18 | Arnaud | Leave a comment

The Crazyflie client has a quite long history, like a lot of things in the Crazyflie ecosystem it has been started when the Crazyflie was used alone using mainly manual control. It has evolved to follow new use-cases of the Crazyflie but it still has traces of its origins and some limitation are still there with us. Moreover, the Crazyflie client and lib are written in python, one the main goal was to make it easily cross-platform. Unfortunately making a cross platform graphical program that accesses hardware in Python has proven to be quite challenging and we feel Python is not the way to go anymore. In this blog post we would like to discuss a bit the current state of the Client and what we are looking at for the future.

Photo of a Crazyflie quadcopter in front of a laptop running the Crazyflie client — A Crazyflie connected to the CFclient

The Crazyflie client was originally design to be able to fly, inspect and work with one Crazyflie. It still serves this purpose quite well: with the client you can connect your Crazyflie, observe graphs of internal log values in real time, setup different decks and sets and store parameters. It is a very good tool to explore and work with the Crazyflie.

However, it is only working with one Crazyflie at a time will take over the radio, so another script cannot talk to the Crazyflie at the same time using the radio. Unless the script uses the ZMQ API that allows an external program to control client and so to control the Crazyflie while the client is connected and active. This functionality can be very useful but, since it is disabled by default, has not seen a lot of use.

The worst, for us, in the current client state is Python and PyQT distribution situation: we used to have an easy-to-use installer on windows, a Linux Snap package and plan for a Mac App. All these have been pretty much abandoned because they kept breaking down over time and the support weight for us was too big. So the only way to install the client is via Pip, the python package manager. This means that you already need a well setup Python environment to run the client. That is nice unless you have a Mac or a Raspberry pi: the latest MacOS broke part of the client that prevents it to run and there is no PyQT build for raspberry-pi available on PyPi. This is the kind of paper-cut that keeps happening at regular interval with distributing a Python application and that we keep having to look at.

So, we have been looking at ways to improve the situation. The Crazyflie client is more than 10 years old now, so a rewrite would not be such a crazy thing to consider. There are at least 2 angle of attack to make a new client better suited for the next 10 years of Crazyflie development:

Multi-platform and distribution

Making a multi-platform program is and will always be challenging. However, we have discovered that doing it in a dynamic interpreted language like python is even more so. The main challenge come from the fact that things tend to break on the user side depending of the user configuration: we all run a slightly different version of python, python evolve and package management evolves as well, so when things break it breaks at random depending of how up-to-date a particular system.

One solution would then be to switch to a compiled programming language. This increases the probability of finding problem at compile time and not at runtime, which means that we will hopefully be the first to know then Apple decided to change the location of one fundamental piece of library and so allow us to hopefully fix the problem before any user is impacted (assuming we can run CI on the latest version of MacOS early enough…).

So, as you might have guessed, our current idea is to write the client in Rust. We are currently looking at Tauri for the UI which is Web based. We still have ideas of also making a web-client so having a web-based IU on PC would simplify development of that.

We are not letting Python go away though, the idea is still to support Python, but to use it for what it is good at: a great language for developer and experimentation. Rust has great bindings to python so in this plan, the python lib is backed by the Rust lib.

Modularity

The other side of the current client limitation is the fact that it connects one Crazyflie taking over the radio. We actually love using the client to observe and poke the state of a Crazyflie so it would be really great to use it when writing a script or controlling a swarm with Crazyswarm. The current ZMQ implementation was designed to solve this issue, but it goes at it the wrong way around: the client becomes the gateway to the Crazyflie and must always be ON. It would be much nicer to be able to launch the client to connect and inspect a Crazyflie currently control by a script.

One design we are currently looking at would be to use use a protocol like Zenoh between the client and the lib. Basically, when connecting a Crazyflie, be it from a script or from the client, a server would be launched in the background that would handle the connection. All communication would pass through this server and so multiple programs would be able to communicate simultaneously with the Crazyflie.

This would allow us to build easily bridges to ROS to get the client to communicate with a Crazyflie currently connected in ROS. And since ROS2 is working on supporting Zenoh officially a bridge might not even be required.

As an added bonus, the Crazyflie server idea would greatly improve the situation when it comes to supporting Virtual Machines and WSL on Windows: it would move the USB connection handling to a Windows program and only require fast network connections which is something that works really well on WSL or VMs.

Conclusion

In this blog post I have tried to describe our current challenges and some way forward we see. The main message though is that we want to change things when it comes to the client, if you have wishes or ideas now is a good time to get in touch. Let’s make the next 10 years of Crazyflie client problem-free.

2024.2 Firmware release with new Bluetooth stack

2024-02-26 | Arnaud | Leave a comment

There is a new release of the firmware, version 2024.2. The main change, and almost only change, in this release, is the Bluetooth stack that was updated from the Nordic’s semiconductor S110 to S130, which affects the firmware on the NRF51 on the Crazyflie. This was mainly done to be able to pass the listing requirement on Bluetooth SIG, but it will also have beneficial technical effects on the Crazyflie radio communication state of affairs.

The new stack and bootloader are distributed in the normal release .zip, which means that it can be updated from the client as normal. Please note that the latest lib and clients are required as we have had to implement new procedures to flash the bootloader and stack.

First of all, let’s define what is a soft device. Nordic semiconductor radio chips are awesome in the way that the radio hardware is fully documented, this means that we can implement our own radio protocols but we would also be able to implement our own Bluetooth stack (I have attempted that a long time ago with some success, the nRF5 radio hardware is really powerful and can be set up to do much of the work!). However, backing your own Bluetooth stack would require passing a full suite of validation at the Bluetooth SIG to prove the stack conform to specification. In order to avoid that, the usual strategy is to buy a Bluetooth device and to talk to it over UART. What Nordic did is to implement a “Softdevice”, a binary blob that runs in the same CPU as the user application and that talks to the application using software interrupt. This keeps the application completely separated from the Bluetooth stack and so means that we get the benefits of a pre-qualified Bluetooth stack that has already been tested and approved.

Currently, we have ported the bootloader and the nrf firmware to the new S130 stack. This opens a lot of potential benefits for the future:

The new stack should be at least 6 times faster than the old one. This makes implementing BLE communication for the Crazyflie to a PC/Chromebook much more appealing and should allow to make the existing mobile client more full features.
We are now able to update the bootloader, so we can make a new improved version of it in the future (ie. with safe link, swarm optimization, much faster Bluetooth boot loading….)
The new stack supports device and host mode. So things like pairing a gamepad with the Crazyflie becomes a technical possibility! (actual implementation is left as an exercise for the contributor ;-).

One very important thing to note is that working on the bootloader requires a debugger: if you flash a bugged radio bootloader you need a SWD debug probe to be able to fix your Crazyflie. The bootloader+softdevice flashing procedure is very safe, as long as you flash a working firmware.

This change should open quite new exciting possibilities. It will be interesting to see what we can achieve with BLE and updated bootloaders in the future. Please note that we had to make a change to both the Crazyflie python library and the CFclient in order to flash this new firmware so make sure that you update those as well to try out this new release.

Developer meeting

The next developer meeting will be on the 6th of March 2024, we will talk about the Crazyflie Supervisor subsystem… We have made some changes to the supervisor recently, and we will continue working more on it in the next couple of weeks mostly preparing for the arrival of the Brushless Crazyflie. We will talk about the current state and what we are working on. Follow the thread on Bitcraze Discussions to be up to date on how to join!