Looking back at 2025

2025-12-22 | Barbara | Leave a comment

Time flies! 2025 is already drawing to a close, and as has become a Bitcraze tradition, it’s time to pause for a moment and look back at what we’ve been up to during the year. As usual, it’s been a mix of new hardware, major software improvements, community adventures, and some changes within the team itself.

Hardware

2025 started with a bang, with the release of the Brushless! It was a big milestone for us, and it’s been incredibly exciting to see how quickly the community picked it up and started pushing it in all sorts of creative directions. From more demanding research setups to experimental control approaches, the Brushless has already proven to be a powerful new addition to the ecosystem. Alongside the Brushless, we also released a charging dock enabling the drone to charge autonomously between flights. This opened the door to longer-running experiments and led to the launch of our Infinite Flight bundle, making it easier than ever to explore continuous operation and autonomous behaviors.

Beyond new products, we spent much of the year working on two major hardware-related projects. Druing the first part of the year, our focus was on expanding the Lighthouse system to support up to 16 basestations. The second part of the year much of our efforst shifted toward preparing the release of the Color LED, which we’re very much looking forward to seeing in the wild.

Fun Fridays also got some extra time in the spotlight this year. Aris produced a series of truly delightful projects that reminded us all why we love experimenting with flying robots in the first place. Have you seen the disco drone, or the claw?

Software

On the software side, 2025 brought some important structural improvements. The biggest change was the introduction of a new control deck architecture; which lays the groundwork for better identification and enumeration of decks going forward. This is one of those changes that may not look flashy on the surface, but it will make life easier for both users and developers in the long run.

We also made steady progress with the Rust Lib, moving from Fun Friday to a fully-fleshed tool. It is now an integrated and supported part of our tooling, opening up new possibilities for users who want strong guarantees around safety and performance.

Another long-awaited update this year was an upgrade to the Crazyradio, improving its ability to handle large swarms of Crazyflie™ drones. This directly benefits anyone working with multi-drone setups and helps make swarm experiments more robust and scalable.

Community

It’s fair to say that 2025 was a busy year on the community and events front. We kicked things off, as usual,, at FOSDEM, where we hosted a dev room for the first time! A big step for us and a great opportunity to connect with fellow open-source developers.

Later in the year, we made our first trip back to the US since the pandemic. This included sponsoring the ICUAS competition, and hosting a booth at ICRA Atlanta, both of which were fantastic opportunities to meet researchers and practitioners working with aerial robotics. We also presented a brand-new demo at HRI.

In September, KTH hosted a “Drone gymnasium“, giving students hands-on access to Crazyflies and encouraging them to explore new robotic experiences. Seeing what happens when students are given open tools and creative freedom is always inspiring, and this event was no exception.

2025 was also marked by continued and valuable community contributions. From improvements and bug fixes to features like battery compensation, these contributions play a huge role in shaping the platform and pushing it forward.

Team

Behind the scenes, Bitcraze itself continued to grow. This year brought both change and expansion within the team. Tove moved on to new adventures in Stockholm, and while we’ll miss her, we were also happy to welcome a record four new team members!

Aris ansitioned from intern to full-time developer, Fredrik then joined as a growth and partnership guru, followed by Enya as an application engineer. Hampus was the last to join us as an administrator. With these new faces, the team is larger — and stronger — than ever.

All in all, 2025 has once again been an exciting, intense, and rewarding year for Bitcraze. Thank you to everyone in the community who flew with us, built on our tools, reported issues, shared ideas, and showed us what’s possible with tiny flying robots. We can’t wait to see what 2026 brings.

The Crazyflie Color LED Deck Meets SwarmGPT

2025-12-15 | Fredrik Ehrenstråle | Leave a comment

Recent work from the Learning Systems and Robotics Lab explores a question many of us have implicitly wrestled with:

How do we design expressive, coordinated swarm behavior without hand-crafting every trajectory?

Their answer, presented in the paper “SwarmGPT”, is to use large language models not as low-level controllers, but as a high-level interface for swarm intent, and then rely on classical robotics methods to make that intent executable and safe.

So what is SwarmGPT?

SwarmGPT is not about letting an LLM “fly drones”. Instead, it introduces a clear separation of responsibilities:

Language models operate at the level of structure, timing, and choreography
Motion planning and control handle feasibility, collision avoidance, and dynamics
Execution remains deterministic and verifiable

In practice, this means a user can specify swarm behavior using natural language (or music-derived cues), and the system generates structured multi-drone trajectories that are then validated and executed using established robotics pipelines.

This distinction matters. The paper does not replace control theory, but it compresses the path from idea to experiment. For researchers, this has several implications:

Faster iteration on swarm concepts
Lower barrier to expressive multi-agent behavior
A clean interface between creative intent and physical constraints

Making Swarm Structure Visible With the Crazyflie Color LED Deck

The authors used Crazyflie drones as research platform and we sent them a handful of Crazyflie Color LED Decks to experiment with.

The LED deck is not just decorative. It provides, per-agent visual feedback, clear indication of phase, grouping, or timing, and immediate insight into synchronization and coordination.

For research, this supports:

Real-time inspection of swarm state
Easier debugging of generated behavior
More legible demonstrations of complex coordination

For drone show–style applications, it enables:

Tight coupling between motion and light
Expressive patterns where choreography and illumination reinforce each other
Rapid iteration on visual concepts without custom hardware

The same capability serves both domains, which is part of its appeal.

Happy Robotic Holidays!

In our annual holiday video, nine Crazyflies take off from the Bitcraze HQ in Malmö. After briefly hovering to demonstrate the three mounting options of the Color LED Deck, they make their way to the Learning Systems and Robotics Lab in Munich.

There, they perform a SwarmGPT-generated choreography before slowly landing in a sparkling snowflake pattern.

When sandwich-mounted, the top- and bottom-mounted Color LED Decks can display independent colors and light patterns, enabling richer visual expressions and more nuanced feedback.

Happy Robotic Holidays from all of us!

Learn More

📄 SwarmGPT paper (Learning Systems and Robotics Lab)
https://ieeexplore.ieee.org/document/11197931

👉 SwarmGPT project website:
https://utiasdsl.github.io/swarm_GPT/

💡 Crazyflie Color LED Deck product page
https://www.bitcraze.io/products/color-led-deck/

🛒 Bitcraze store (Color LED Deck – available early 2026)
Crazyflie Color LED Deck – Top Mounted
Crazyflie Color LED Deck – Bottom Mounted

A Christmas Tree made of Crazyflies

2025-12-01 | Aris | Leave a comment

Christmas is getting close, and while most people are just starting to hang lights and decorate their tree, we decided to go a little bigger and a whole lot brighter. Instead of adding tinsels and ornaments, we set up a swarm of 8 Crazyflie 2.1 Brushless drones with the upcoming Color LED decks along with some long-exposure photography magic, and decorated our flying arena with a Christmas tree made of Crazyflies.

How it works

The project is split into two parts: the firmware side that controls the Color LED decks and the script that is responsible for the choreography of the swarm.

The Firmware

Instead of lighting the LEDs based on time or commands, each Crazyflie uses its 3D position to decide on the correct color. This makes the whole communication with the central computer easier. Inside the firmware, multiple virtual spheres are created in the flight arena, just like ornaments floating in a tree-shaped structure. Whenever a Crazyflie flies into one of these spheres, its Color LED deck switches instantly from green to red. When it flies back out, it glows green again. Since we’re taking a long-exposure photo, the whole color pattern begins when the drones are ready to perform the choreography and stops when they start landing.

The Script

The python script is pretty simple. It commands a swarm of Crazyflies to perform a coordinated spiral choreography resembling a Christmas tree outline in 3D space. Each drone takes off to a different height, flies in spiraling circular layers, and changes radius as it rises and descends, forming the visual structure of a cone when viewed from outside. To pull this off with the current state of the cflib, we used 3 Crazyradios 2.0 and the high level commander.

A Testbed for Crazyradio 2.0 Improvement

Lately, we have been looking again at improving the radio communication with the Crazyflie. A prototype featuring a new USB communication mode for the Crazyradio was ready just in time for testing with the Christmas tree demo.

This new mode makes Crazyradio 2.0 much more efficient when communicating with swarms. With it, we were able to fly the same demo using only one Crazyradio 2.0 instead of 3 with the connection time to the swarm greatly accelerated. This demonstrates the efficiency of the new mode.

The new mode is called “inline setting mode” since it works by inlining all radio settings with the packet data, negating the need to issue time-costly USB setup requests. It is currently a Pull Request to Crazyradio 2.0 and the Rust Crazyradio driver. Support for Crazyswarm/ROS and CFLib will be implemented and when we know that the protocol works out for all libs, we will merge and release support for the new mode. It will be enabled by default so you will get the benefits from upgrading the Crazyradio 2.0 firmware and lib. We will talk more about it when it is released, in the mean time do not hesitate to test and feedback on the PRs ;-).

Demo source code

You can find the project’s repository as well as the rust version on Github. The python version was used for the picture and video, and the Rust one behaves identically.

Fun Friday Project: Turn the Crazyflie into a Party Drone

2025-11-17 | Aris | 2 Comments

It’s always a good feeling to wrap up the week with a Fun Friday project – especially when it involves some questionable mechanical additions to a Crazyflie platform. This time, I decided to test the capabilities of the upcoming Color LED deck by turning it into a Disco deck.

Mechanics

The core of the Disco Deck is pretty simple: a 3D-printed disco ball mounted directly on top of the Color LED Deck with a couple of screws. To bring it to life, I added a Sub-Micro Plastic Planetary Gearmotor and used a rubber band as a drive belt to transfer the rotation. It’s a lightweight, low-tech solution that works surprisingly well with the Crazyflie 2.1 Brushless. All the structural parts were designed to be easily 3D printed in PLA, and they fit on a single print plate for a quick build. You can find all the part files here.

Electronics & Firmware

On my first attempt, I connected the motor directly to VCC and GND, which meant it started spinning as soon as the Crazyflie powered up. This turned out to be a problem as the vibrations prevented the Crazyflie from completing its initialization sequence, since it needs to remain completely still for about one second at startup. The proper fix was to connect the motor to one of the GPIO pins (IO_4) along with GND. For the firmware, I added a new deck driver for setting the IO_4 output to low during initialization and controlling it through a parameter.

Next Steps

The biggest limitation of the current Disco Deck design is the landing. The disco ball extends below the length of the Crazyflie 2.1 Brushless legs, which means the drone can’t take off or land horizontally – not even when using the standard Crazyflie 2.1 Brushless charging dock. To fix this, I’m planning to design a custom charging dock that also works as a stable landing platform for the Party drone.

If you’re interested on the process, you can check out the project repository for any updates.

Crazyflie CLI 0.3.0 released

2025-11-03 | Marcus | Leave a comment

About a year ago I started working on a Crazyflie CLI (command line interface), with the goal of having a utility for quickly doing simple interactions with the Crazyflie from the command line. Initially I was mostly interested in the console, but realized that it’s neat to also be able to check some logging variables and set some parameters as well. With the new release of the Crazyflie Rust lib I’ve also updated the cfcli to be able to access the memory subsystem, along with some other nifty updates to make it easier to use.

Below is a full list of the updates in the release:

Improved user interface
- Use interactive selection if command line parameters are missing (like what params to set or which memory to display)
- Animation while connecting
Added access to memory subsystem
- Raw access to memories
- Initialize, erase and display decoded information from EEPROM and 1-wire memories
- Configure the Crazyflie EEPROM (i.e set channel, address, speed etc)
Set and get multiple parameters at once
Generate and flash DeckCtrl configurations via debug probe
Bumped all dependencies

If you would like to give it a try just run cargo install cfcli. Have a look at the crates page or the GitHub repository for more information and feel free to leave any suggestions or comments below. Here’s a short video showing the new interactive selection being used:

The Color LED deck

2025-10-27 | Tobias | Leave a comment

It’s been a while since our last update on what started as the High powered LED deck prototype. We have finally had time to push this project forward and are aiming to have a release at the beginning of 2026.

A New Name and a Familiar Design

You might notice that the deck has a new name, something simpler and a bit catchier, the Color LED deck (bottom-mounted and top-mounted). The overall design and specs, however, remain very similar to the original concept:

Using a highly efficient high powered LED for maximum brightness
DC/DC driving circuitry for improved efficiency and consistent performance
A light diffuser for smooth, even illumination and wide visibility
Two versions, top or bottom mounted, depending on your build

The Color LED Deck brings fully programmable lighting to your Crazyflie, allowing you to create and control custom light patterns in real time. It’s useful for flying in darker environments, for visual tracking experiments, or for adding synchronized light effects in drone choreography. The deck is now also compatible with the Crazyflie 2.1 Brushless, bringing dynamic lighting to our most recent platform for the first time.

Software architecture

This deck will also be the first to use the new DeckCtrl architecture. If you’re curious about how that works, you can read more about it in this earlier blog post.

The Color LED deck has some intelligence built into it that runs on a STM32C0 MCU. The open-source firmware is still under development, and the repository can be found here.

Availability

The final pricing is still being determined, but make sure to sign up for the in-stock notification at the Color LED deck store pages (bottom-mounted and top-mounted) to get an update as soon as it’s available. And as always, keep an eye on the blog for more updates as we get closer to release.

Keeping Thrust Consistent as the Battery Drains

2025-10-20 | Marcel Rath | Leave a comment

When flying the Crazyflie Brushless, you may have noticed something familiar, as the battery drains, the drone becomes less responsive and can not generate the same amount of thrust it had at the start of the flight. This is because as the state of charge drops, the battery voltage decreases, and that directly affects the thrust output of the motors.

We wanted to fix this. In this post, we’ll explain why the old compensation method wasn’t ideal, how we used system identification to design a new battery compensation scheme, and how this improves thrust consistency across the entire battery range.

Motivation

The key problem is simple: a dropping battery voltage means a dropping thrust for the same command. This leads to flights that start crisp and responsive but is reduced as the battery drain.

Our goal was to make sure that, regardless of the state of charge, the actual thrust stays close to the commanded thrust. Though, for manual flight, sometimes this might not be preferred, so there will be an option to turn it off.

To illustrate the setup, here is a schematic of how the battery, PWM switching, and motor interact, effectively behaving like a simple buck converter:

This means the motor voltage can be computed by:

System Identification

To design a proper compensation, we first needed to understand how thrust relates to motor voltage. This meant running a series of experiments on the thrust stand introduced in this earlier blog post.

The first step was calibrating the loadcell used to measure thrust:

Once calibrated, we measured the thrust at different applied motor voltages.

As expected, the thrust can be modeled well by a third-order polynomial in motor voltage.

Mathematically, the relationship comes from two simple facts:

A DC motor torque is proportional to motor voltage and inversely related to motor speed.
A propeller’s thrust scales approximately with the square of the rotational speed.

Combining these effects leads to a nonlinear (third-order) relation between motor voltage and thrust.

Battery Compensation

The main idea is straightforward: instead of assuming the battery voltage is constant, we explicitly account for it. We can measure the battery voltage and low-pass filter it to reduce noise. Together with the necessary motor voltage from the curve above, we can solve the equation from above for the necessary pwm to apply:

This corrected motor voltage is then fed into our third-order model to compensate the thrust command. With this compensation, the commanded-to-actual thrust relation is now approximately linear, which is exactly what we want. We can verify this by applying thrust commands and comparing them to the actual thrust.

Dynamic Behavior

To obtain a complete parameter set of the motors and propellers, we also performed dynamic tests: commanding rapid increases and decreases in PWM and measuring the thrust response.

These dynamics are not required for the battery compensation itself, but they are very useful for accurate system identification and for simulation purposes.

Discussion and Conclusion

The new compensation method (#PR1526), ensures that thrust is consistent across the full range of battery charge. Compared to the old approach, it is both simpler to understand and more faithful to the actual physics of the motor–propeller system. The result is flights that feel the same at the end of the battery as at the beginning.

Beyond just improving flight performance, the system identification work also provides us with a full parameter set for the Crazyflie. We are already using these parameters in Crazyflow, our new simulation tool that models the Crazyflie dynamics with high fidelity. If you’re interested in simulation or in testing new control strategies virtually, check it out!

We’re excited to hear feedback from the community and to see what you do with this new capability.

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.

Release 2025.09

2025-09-29 | Rik | Leave a comment

We’re happy to announce that release 2025.09 is now available. This update includes Python 3.13 support and improved battery voltage compensation, along with enhanced trajectory control capabilities. The release also features substantial stability and architectural work that lays the groundwork for upcoming features and products. Thanks to our community contributors for their valuable additions to this release.

Major changes

Python 3.13 support
Added support for Python 3.13, with preparations already in place to ensure faster compatibility when Python 3.14 releases.

Improved battery voltage compensation
Enhanced voltage compensation for Crazyflie 2.1, 2.1+, and 2.1 with thrust upgrade kit provides more consistent flight performance across battery discharge cycles. Crazyflie Brushless battery voltage compensation coming soon. Thanks to @Rather1337 for this contribution.

Manual flight setpoint packet
New generic commander packet type for manual flight that allows dynamic switching between Angle and Rate modes for roll and pitch without re-flashing the firmware.

Fully relative trajectories
Trajectories can now be initiated relative to the drone’s current yaw, not just position. This enables fully relative trajectory execution where subsequent trajectories maintain the drone’s current orientation. Thanks to @johnnwallace for this contribution.

Modular deck discovery architecture
Replaced OneWire-only deck discovery with a modular backend system that supports multiple discovery protocols. This enables future deck communication methods while maintaining full backward compatibility with existing decks.

Release overview

crazyflie-firmware release 2025.09 GitHub

cfclient (crazyflie-clients-python) release 2025.9 GitHub, PyPi

cflib (crazyflie-lib-python) release 0.1.29 GitHub, PyPi

Making Social Robots Fly: Inside the Drone Gymnasium

2025-09-22 | Fredrik Ehrenstråle | Leave a comment

At Bitcraze, we’ve always believed in giving people the tools to explore the world of robotics, and especially flying robotics. We’re still surprised by just how many directions you’ve taken the Crazyflie platform, and the research and innovation areas seem endless. Swarming, autonomy, edge AI, vision, navigation, mapping, coordination, etc. are all examples of areas you are interested in and what you are using the Crazyflie to unlock.

But what about the more human aspects of robots, and the relationships we build with these machines? What does it feel like to share space with a flying system, and how can we see drones not only as tools, but companions? And how can we help push social robots from academic theory into everyday life?

These are the kinds of questions we’ve been exploring at Bitcraze and with the Drone Gymnasium, we finally have a space designed to push those ideas further.

A Living Lab for Shared Spaces

Partially inspired by science fiction, The Drone Gymnasium is an experimental playground brought to life by our industrial postdoc Dr. Joseph La Delfa, toghether with Rachael Garrett, Kristina Höök and Luca Mottola, in collaboration with KTH (Royal Institute of Technology), Digital Futures. and RISE.

It’s a living lab, where the boundaries between code, design, behavior, and imagination are blurred. A temporary, yet functional, “future lab” where people experiment with how flying robots might one day fit seamlessly into real-world environments. How they could share space with people, not just in theory, but in practice.

Students from the Physical Interaction Design course, together with our own drone experts, prototyped new robotic experiences using the Crazyflie platform, not just as flying hardware, but as social agents in motion.

From Lab to Real Life

One of the great unsolved challenges of social robotics is translation, moving from controlled lab setups into the beautiful, messy, complexity of the real world.

That’s where many good ideas stumble. That’s also where the Crazyflie shines.

Open, modular, and programmable down to the bone, the Crazyflie gives researchers and innovators permission to try things. To test, break, rebuild, and then observe how it feels to share a room with a machine that moves and reacts in the same space as you.

The Drone Gymnasium is one of many ways we’re trying to support academia, not just in supplying hardware, but in co-creating learning environments where ideas around autonomy, behavior, and social interaction can be explored hands-on, in full view of the community.

Asking Better Questions

And the results are exciting. From emergent swarm behaviors to subtle gestures and sound cues, the participants in the Drone Gymnasium weren’t just building tech, they were testing social contracts. What makes a drone feel present instead of intrusive? Helpful instead of unsettling?

That’s not only an academic question. It’s a design question. And a human robotics question.

We believe spaces like this are interesting, not only to prepare the next generation of roboticists, but to ask better questions about what we’re actually building, and for whom.