crazyflie

49 Crazyflies flying SWAN formations

  2026-10-26  |     |    Leave a comment

49 Crazyflie 2.1 Brushless lifting off their charging docks, flying formations, and landing back to recharge, all driven from a single Crazyradio 2.0. That’s what we have been flying lately, and it’s a great showcase of what the Crazyflie ecosystem can do with a big swarm.

If 49 Crazyflies sounds familiar, you might remember 49 Crazyflies, 1 Crazyradio, and cflib2. This time the formations are a lot more dynamic. They come from a collaboration with the Institute for Data Science in Mechanical Engineering (DSME) at RWTH Aachen University, and we recorded some videos we’re really happy with.

Where the formations come from

The choreographies were generated with SWAN, a pipeline developed at DSME that turns text promt into drone trajectories. In short:

  1. A generative video model turns the prompt into a reference video.
  2. A point tracker converts the motion in that video into trajectories for the swarm.
  3. A planner assigns them to individual drones, and a safety filter makes sure they are collision-free.

What makes these formations fun for us is that they are not static shapes: they move in ways that would be hard to animate by hand. That also makes them a demanding test for the swarm.

Taking it to the real world

The generated SWAN trajectories are turned into splines and deployed on a dense swarm of 49 Crazyflie 2.1 Brushless, flying under the Lighthouse positioning system and lit up by bottom-mounted Color LED decks. We won’t go through the whole setup again (covered by the earlier post), but two parts of the Crazyflie ecosystem made this kind of work practical:

  • Built on cflib2. All communication with the swarm goes through cflib2 over a single Crazyradio 2.0. Before takeoff, we use cflib2 to upload each drone’s trajectory to its memory, and during the show, the High-Level Commander executes it onboard. While they are flying, we log every drone’s position every 50ms, giving us a record of how closely the swarm followed the choreography.
  • No battery swapping. Each Crazyflie takes off and lands on its charging dock. When you want to fly the swarm many times back to back, not having to handle 49 batteries makes a huge difference.

The result is a setup where any idea can go from the computer to a real swarm without having to build the infrastructure yourself.

The videos

Enough talking, here is what it looks like. The video below shows the formations we flew: a ballerina (49 drones), a karate fighter (29 drones), and a hand making an “I love you” (ILY) sign (49 drones).

Wrapping up

Flying 49 Crazyflies through dynamic formations, with one radio, full position logging and drones that recharge themselves between flights shows how far the Crazyflie ecosystem has come for large swarms.

A big thank you to Pascal Reinhold, Alexander Gräfe and Sebastian Trimpe at DSME for their awesome work, and an extra special thanks to Alexander, who coordinated the whole project during his internship with us at Bitcraze. If you want to learn more about SWAN, check out their paper, Generative AI for Safe and Photorealistic Drone Light Shows. And if you want to fly your own swarm, cflib2 is ready to try.

Let us talk controls at the IEEE CSS days

  2026-10-19  |     |    Leave a comment

We are happy to have been invited to the IEEE CSS Days 2026 on Wednesday the 21st of October at 19:30 UTC to talk about the Crazyflie in a controls context. The talk is 15 minutes long, including questions. We hope to see you there! Read on for more information about what the talk will contain…

Every now and then we get to interact with the community; our users, customers, ex-colleagues and others. You keep on inspiring us every time, and the discussions help us understand what you are doing in your work and where you are heading next, so that we can prioritise our work and efforts. We also enjoy sharing what is in our pipeline, what we are thinking about and how we imagine our products can be used to do awesome things. This talk will be such a session, with a focus on what improvements have been made lately to the Crazyflie ecosystem that can be interesting from a controls perspective.

IEEE CSS Days – what is it?

IEEE Control Systems Society (CSS) is the IEEE society dedicated to control systems engineering. Their flagship online showcase event, IEEE CSS Days, held 19-23 October, is virtual and free, and will highlight the society’s people, research, industry activities, community activities and more. All information can be found in the link. One of the sessions is “Technical Committee on System Identification and Adaptive Control Session”, and it is during this sessions that we have been invited to talk about the Crazyflie.

An overview of the talk

The title is “Advancements in the Crazyflie as a Testbed for Drone Control Research” – let’s break that down a little bit. We envision the Crazyflie to be a platform for trying new things; a canvas with just enough things premade for you to test your concepts with as little effort as possible. This is also true for the controls field. All the ideas floating around in the research community, and everything that has already been done, combined, intend to solve control problems at different levels and in different ways. We want to support as many ways of working as possible, and we believe we have lately done some advancements that can help you in your work. We want to share them with you, and are excited to see what cool things you can come up with using them.

Some examples of improvements

We are aware of that all of you will not be able to catch the CSS session. For that reason, here are some of the things that will be mentioned. If you have been reading the blog, you will probably recognise them:

Onboard, decentralised positioning – not really new, but something we keep coming back to when talking to the community. Lighthouse, which is laser-based, is still our highest performing positioning system. However, as we move into larger swarms, UWB has the advantage of not requiring line-of-sight between satellites and robot – this keeps Loco Positioning System interesting.

Bidirectional DSHOT and RPM telemetry – The Crazyflie Brushless now carries the possibility to get measurements of the rotor speeds. motorsGetRPM()in motors.c gives you what you need to get started.

cflib2 – The new, rust-powered cflib. It is already released (still on version 0, so expect API changes), and gives you performance and reliability boosts compared to the old cflib, and with more to come. Together with radio improvements, the radio performance has increased immensely: we have flown 49 drones on one Crazyradio in our flight lab. If you use Python for scripting, we highly recommend you try the new lib out.

As we move into bigger swarms, swarm management becomes a topic: Communication, monitoring, flashing and configuration. This is something that we are working on.

Let us know what you think of these improvements, when you start using them!

Event details

Here are the details for the talk:

Event: IEEE CSS Days
Time: 21st of October, 19:30 UTC
Speaker: Stefan Thorstenson
Title: “Advancements in the Crazyflie as a Testbed for Drone Control Research”

We hope to see you there!

And, if not, we will hopefully catch you some other time. In the meantime, keep on letting us know what you are working on – we are always interested to hear about it and discuss.

Farewell to the Z-ranger deck v2 and Crazyradio PA

  2026-10-05  |     |    Leave a comment

And so, two of our products have reached the end of the road. This time it is the Z-ranger deck v2 and the Crazyradio PA. Both have now been discontinued, and our remaining stock has run out.

This is not a particularly dramatic change. Both products already have well-established successors, and much of what they enabled has simply become part of the next generation of the ecosystem. Still, they have been around for quite a while, so here’s a proper goodbye.

Z-ranger deck v2: knowing where the floor is

The idea behind the Z-ranger was simple: point a distance sensor downwards and give the Crazyflie a good measurement of its height above the ground. It enabled accurate height hold without an external positioning system and became a building block for early autonomous flight experiments.

The original Z-ranger used the VL53L0x Time-of-Flight sensor. In 2018 we introduced the Z-ranger deck v2, together with the Flow deck v2, using the newer VL53L1x sensor and extending the useful ranging distance. The Z-ranger v2 could measure the distance to the ground up to 4 metres.

There was always a close relationship between the Z-ranger and the Flow deck. The two decks share the same basic downward-facing ranging functionality, but the difference is that the Flow deck v2 also contains a PMW3901 optical flow sensor, allowing the Crazyflie to measure horizontal movement relative to the ground.

Over time, that has made the Flow deck the more useful general-purpose solution. You get the ground-distance measurement of the Z-ranger, but also the motion information needed for position hold and autonomous movement in X and Y.

Rather than maintaining two products with overlapping functionality, we are consolidating around the Flow deck v2. For existing Z-ranger users, nothing suddenly stops working. The firmware support remains, and there is no reason to replace a Z-ranger that is already doing its job in an experiment. For new setups, however, the the Flow deck v2 is now the natural choice.

Crazyradio PA: a small USB dongle that did a lot of work

The second product leaving the store is the Crazyradio PA. It has been our main USB radio dongle for communicating with Crazyflies for many years. Based on the nRF24LU1+, with a power amplifier providing up to 20 dBm output power, it provided the communication link behind everything from someone flying their first Crazyflie to fairly substantial research swarms.

By 2023, though, the nRF24LU1+ platform was becoming increasingly limiting for what we wanted to do next. That led to Crazyradio 2.0, based on the much more capable nRF52840. From the beginning, Crazyradio 2.0 was designed both as a replacement for Crazyradio PA and as a platform on which we could continue developing the communication side of the Crazyflie ecosystem. The nRF52840 gives us substantially more processing power, memory and radio flexibility, as well as a more convenient bootloader and room to experiment with new communication protocols and scheduling strategies.

Earlier this year, for example, we flew 49 Crazyflie 2.1 Brushless drones using a single Crazyradio 2.0 while testing cflib2 and improvements to the radio firmware. That is a useful illustration of why moving the radio platform forward matters: communication is part of the research infrastructure too, especially when experiments start scaling from one robot to many.

What changes for existing users?

Not very much is changing for existing users. If you already have a Z-ranger deck v2 or Crazyradio PA, you can continue using them. Discontinuation does not mean that they suddenly become incompatible with the Crazyflie ecosystem.

For new setups, however, use the Flow deck v2 for downward ranging capability and optical flow measurement. 

And as far as a radio goes, the Crazyradio 2.0 is the only alternative on which ongoing communication development is focused.

What does years of firmware in development look like?

  2026-09-21  |     |    Leave a comment

Most of us who work on Crazyflie firmware live in one corner of it at a time — a driver here, a control loop there — and rarely step back to see the whole tree at once. We built a treemap of the firmware to do exactly that: one picture, every source file, sized by how much code it actually is and grouped by the directory it lives in. It makes you realize how much is going on in the firmware to make your part work.

How the map was built

The map straight out of a real build: for the cf2 target, we let Kbuild run to completion and then read its own .cmd files, the bookkeeping Kbuild already writes for every compiled object, recording exactly which source file produced it. Group those files by their top-level directory under src/ — deck, drivers, hal, init, lib, modules, platform, utils — plus vendor and scripts alongside, size each tile by lines of code, and the tree draws itself.

The treemap

Below is the top-level view of the crazyflie-firmware. Quite beautiful, right? We think so, at least. It contains years of work from the Bitcraze team and all of you out there who have directly contributed or indirectly by finding bugs and asking for new features.

Click into modules/src and it’s 91 files, 27,680 lines — the flight logic. hal/src is leaner: 21 files, 7,036 lines, sitting right above the raw drivers.

Walking the tree

Ordered the way the map itself reads, biggest tile first:

  • vendor — a second, separate pile of third-party code (FreeRTOS itself, libdw1000, test frameworks), distinct from lib.
  • lib — vendored third-party libraries the firmware builds on (the STM32 standard peripheral library, CMSIS, FatFS, Segger RTT).
  • drivers — low-level code talking directly to individual chips: sensors, radio, motors.
  • modules — the flight logic: commander, controller, state estimator, Kalman filter, CRTP handling.
  • deck — drivers for the decks (flow deck, lighthouse, LED ring, and the rest), detected and brought up at runtime.
  • hal — the hardware abstraction layer sitting above the raw drivers (sensor fusion input, power management, storage) that the rest of the firmware calls into.
  • utils — small shared helpers used across the rest of the tree: CRC, PID, filters, assertions.
  • scripts — build tooling (Kconfig, Makefiles, dependency-checking scripts). Sized like everything else, but none of it is actually compiled into the firmware.

platform and init are in there too, but at this scale they barely register as pixels — more on why that’s fitting below.

Some observations

Diff two builds instead of looking at just one, and a couple of things pop out that are easy to state but satisfying to actually go and check.

CF2 vs. CF2.1 Brushless. These are two different physical boards, but walk the diff and the only directories where a single file differs are hal/src and platform/src. Everything else in the tree — all of modules, all of drivers, all of lib — is the same source code, regardless of whether it ends up on a brushed or a brushless frame. The resulting code differs mainly due to the configuration found in e.g. platform_defaults_cf2.h.

sensors_mpy9250_lps25h.c in the bottom left corner is not compiled into the Brushless – it does not have those sensors. The same is true for Crazyflie 2.1. However, the Crazyflie 2.0 has these sensors. The sensor setting is selected at runtime, which is why you can flash your CF2.0 and CF2.1 with the same firmware.

Every controller ships in every build. modules/src has a whole cluster of controllers sitting side by side — PID, Mellinger, INDI, Brescianini, Lee — and all of them get compiled in. Which controller actually flies the drone is a parameter you can flip at runtime.

Closing thoughts

Line them all up and the codebase is huge, but the part of it that’s actually specific to one physical board is tiny. platform and init — the directories that differ per board and handle bringing the system up — barely show up next to vendor and modules. That’s easy to feel intuitively after enough time in the codebase, and much easier to actually see laid out flat like this.

It would take a long time to work your way through every corner of this tree, if you ever fully do. The tool that generates this map can be found here, and it works on one or two (compare) Kbuild targets. It already has compiled examples.

Is this an interesting way to look at a codebase you already partly know? And now that it’s laid out flat in front of you — is there anything in here that looks like it could use some tidying up? We’d like to hear about it.

Running Tapestry OS on the Crazyflie: Collective Behavior Without Writing Firmware

  2026-09-07  |     |    Leave a comment

What does it take to bring a new coordination stack to the Crazyflie? In this guest post, Jim Steele, founder of Tapestry OS, shares his experience building a Zephyr-based firmware port for the Crazyflie 2.1 Brushless and using it to explore decentralized coordination with three drones. We’re happy to welcome Jim to the blog to share the work and what he learned along the way.

The Crazyflie platform has an excellent answer to the question of how to fly a drone autonomously. The firmware is well-documented and actively maintained with hardware abstraction, sensor drivers, and state estimators providing solid infrastructure that a research team can build on confidently.

The question I kept running into is one layer above that: once you have drones that can fly reliably, how do you coordinate what a collective of them does together? Not at the trajectory level (Crazyswarm2 handles that well) but at the level of distributed state: what does each drone know about where the others are, how fresh is that information, and how does the collective continue functioning correctly when a drone fails or communication is interrupted?

3 Brushless flying seen on a beige workplace background

Most research teams answer this question by writing custom coordination firmware specific to their experiment. The result works, but it does not transfer to the next experiment or the next platform. I wanted an answer that would.

Tapestry OS provides this layer as an open-source coordination stack built on Zephyr RTOS. It includes a distributed world model, gossip-based state propagation, fault-tolerant consensus, and a declarative application API that lets domain experts express collective behavior without touching the underlying firmware. This post is about porting Tapestry to the Crazyflie 2.1 Brushless and validating its core coordination claim on three drones flying in collective formation.

The port

Tapestry’s stack has seven layers, L1 through L7. For the Crazyflie port, the work lives in L1: the Physical Substrate Interface, Tapestry’s equivalent of a board support package. We began by developing a native Zephyr port for the Crazyflie 2.1 Brushless. This had to include the flight control itself: attitude (rate + angle), altitude-hold, position-hold loops, sensor drivers, and a Lighthouse V2 deck driver. Bitcraze stock firmware was an invaluable reference (the control cascade architecture and the Lighthouse calibration math especially) though Tapestry’s implementation is written from scratch and shares no code with it. 

Bring-up including L2 had some surprises, including two real bugs in Zephyr’s STM32 I2C driver that the Tapestry repository carries as patches until they are upstreamed. Streaming console output over the Crazyradio early in the port made debugging much less painful.

Lighthouse positioning took the longest. The interesting problems were pairing the base station’s sweep planes correctly from raw deck timestamps, and rejecting phantom rays from specular room reflections. The eventual implemented solution gates rays against the base station’s optical field of view (a hardware constant that survives recalibration) plus triangulation-consistency and rate-of-motion checks. Once resolved, position accuracy is solid.

Tapestry’s higher layers, including the L3 gossip transport and the L4 Collective State Manager, required no changes. That is the point: once the foundation is in place, the coordination logic does not care whether it is running on a ground robot or a drone.

The formation demo

Three Crazyflie 2.1 Brushless drones, each running Zephyr with the Tapestry substrate and collective world model, were flown in a simple formation. Each drone reads its own absolute position from the Lighthouse deck and gossips it to its peers every 500 ms over the nRF51’s peer-to-peer radio channel. The resulting world model holds fresh entries for its two peers, with staleness tracking, and continually compares its distance to each fresh peer against a target spacing: too close pushes away, too far pulls closer. 

The example formation in the following video shows two drones hover and align in equilibrium. When a third powers on and flies among them, the three maintain separation until the third drone ends its mission, lands itself, and the remaining two close back into their line before landing.

There is no leader, no ground station, and no phase script: each drone runs Tapestry’s decentralized world model and shares only its own position over gossip. The recovery behavior is the part to watch closely. When one drone ends its mission, it lands and goes silent. The remaining two re-form their line about ten seconds after the departure, without any instruction from an external system. This is deliberately the same code path that would handle a real mid-flight interruption. 

This is Tapestry’s first demonstration on real Crazyflie drones: a coherent shared understanding of collective state, maintained entirely through peer-to-peer gossip, driving behavior through local rules. The demo logic can be expressed as a declarative L7 Choreo with the Tapestry SDK without touching firmware.

What is available

The Crazyflie 2.1 Brushless support is in the Tapestry OS repository under Apache 2.0. It includes the steps to recreate this demo: per-drone configuration, Lighthouse calibration, and ESC provisioning.

This is an initial port. We chose Zephyr to unlock a standardized, scalable ecosystem that allows the Crazyflie to integrate with industrial-grade RTOS tooling. We chose standard PWM for this port to simplify the initial Zephyr hardware abstraction with a stable and reliable baseline for our formation coordination logic. A number of Crazyflie capabilities are not yet available on the Zephyr-based stack (Kalman estimation, flow deck, and DSHOT among them), and contributions are welcome.

If you are doing swarm research on the Crazyflie and want coordination infrastructure you do not have to build yourself, the Tapestry repository is a good starting point. Try the port, open an issue if you hit hardware-specific bugs, and share your formation experiments on GitHub or in the Bitcraze forum.

Release 2026.08

  2026-08-24  |     |    Leave a comment

We’re happy to announce that release 2026.08 is now available. This update ships a reworked lighthouse geometry estimator with a redesigned interactive Lighthouse tab, bidirectional DSHOT RPM telemetry, and a new deck supervisor for runtime deck health monitoring, along with a number of smaller bug fixes and quality-of-life improvements. Alongside the release, we’ve also shipped a fix for a long-standing lighthouse FPGA decode issue affecting simultaneous sensor hits. Thanks to our community contributors for their valuable additions to this release.

Major updates

Lighthouse geometry estimator rework
A large rework of the lighthouse base station geometry estimation (cflib + cfclient), replacing the old batch estimation script with a continuous, interactive workflow built into the client. Base stations and samples can now be added, removed, and verified live during a session, while the updated UI provides a live status feedback. Thanks to @krichardsson and @cafeciaojoe for their work in this project.

Bidirectional DSHOT and RPM telemetry
Motors driven over bidirectional DSHOT can now report their measured RPM back to the firmware. This feeds both telemetry and a new arming check: each motor is spun up and confirmed to actually be turning at the requested RPM before arming is allowed, catching a disconnected or seized motor before takeoff instead of after. Thanks to @EliaCareda for this contribution.

Deck supervisor
A new deck supervisor subsystem continuously monitors deck health at runtime, mirroring the role the platform supervisor plays for the flight controller itself. A deck that stops responding or reports a fault now surfaces an explicit error code instead of a simple alive/not-alive flag, so problems can be diagnosed rather than just detected.

Radio platform-packet handling moved into the nRF51 interrupt
All null CRTP platform packets — P2P, battery-voltage polling, bootloader, radio commands, safelink init — are now handled entirely inside the nRF51’s radio interrupt handler instead of being passed through safelink to the STM32. Battery-voltage queries in particular are answered directly from a packet rebuilt every ADC cycle, keeping this traffic off the application processor and giving these commands a fast, consistent response path.

Lighthouse FPGA: simultaneous sensor hit decode fix
Fixes a bug where a sweep crossing two sensors at (nearly) the same instant broke LFSR channel decoding and caused the firmware to discard the entire sweep block. This update belongs to the lighthouse-fpga repository. You can update your Lighthouse deck by flashing the 2026.08 release firmware via cfclient.

Persistent parameters settable from apps
Parameters marked PARAM_PERSISTENT can now be set from firmware apps, not just from a connected client, and their stored value is enforced/restored at boot.

Release overview

crazyflie-firmware release 2026.08 GitHub

crazyflie2-nrf-firmware release 2026.08 GitHub

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

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

Reproducibility and Continuity in Aerial Robotics

  2026-08-10  |     |    Leave a comment

Inheriting an experiment is often harder than building one. A PhD student graduates. A postdoc moves on. A sensor gets discontinued, and six months later, reproducing the earlier work means reconstructing a software environment, rebuilding a hardware setup, and re-deriving assumptions that were never written down anywhere. The paper is still there, but the experiment usually isn’t.

Reproducibility is normally discussed in terms of published results: can someone else get the same numbers from the same method, but in practice, most labs run into a different problem first, and it’s a more mundane one. Continuity. A new student needs to take over a project without starting from scratch, or a collaborating lab needs to replicate a setup without rebuilding the surrounding infrastructure. Then the experiment itself needs room to evolve without dragging everything underneath it into a rewrite.

Preserving context, not just code

Code and datasets are easier to share now than they’ve ever been, and that’s real progress. But a repository is not the same thing as an experiment. What a new student actually inherits is a pile of things that rarely make it into a GitHub repo: hardware configurations, positioning system calibration, flight scripts tuned by trial and error, a specific combination of dependency versions that happens to work, and a layer of tacit lab knowledge. That last part is usually the stuff someone would tell you in five minutes at the whiteboard. It never gets written down.

The problem compounds as the work moves forward. A sensor gets replaced. ROS moves to a new version. New questions branch off from the original project, and each one drags a little more infrastructure along with it.

A stable platform doesn’t solve reproducibility. Poorly documented assumptions are still poorly documented assumptions. But it can remove one source of uncertainty: the platform underneath the experiment hasn’t become something completely different. That matters when the next researcher needs to understand what was built before they can build on it.

Compatibility over time has research value

Infrastructure that survives across multiple projects tends to become more useful with time. A platform a lab can keep using across student cohorts and research directions accumulates knowledge around it: working configurations, scripts, extensions, troubleshooting experience and, eventually, people who know how the pieces fit together.

That’s one of the less obvious benefits of the Crazyflie® ecosystem. The platform has changed considerably over the years, as it should. Hardware has evolved, APIs have developed and tools have come and gone. But much of the underlying architecture and the way the pieces relate to each other remains recognizable.

That technical lineage matters. Someone returning to Crazyflie research from five or even ten years ago won’t find exactly the same system, but neither will they find an unrelated one. The communication model, firmware architecture, development tools and approach to hardware extensions have evolved incrementally rather than being repeatedly replaced.

It means older work can remain useful as a starting point rather than simply becoming a historical reference.

Reproducibility between people, not just between runs

Reproducing an experimental result and continuing someone else’s research aren’t quite the same problem. But they share much of the same infrastructure.

Robotics has irreducible uncertainty in it, and no platform removes that. What a well-designed, long-lived platform can do is lower the cost of understanding, reconstructing and extending previous work.

It’s a less visible kind of value than a benchmark result. But in labs where a project outlives the people who started it, that continuity is often what makes cumulative research possible at all

Did you know?

  • Today’s firmware still supports Crazyflie 2.0 (apart from certin recent features)
  • You can take over someone else’s sysid work. If you would build your own platform you would need to redo that. (When the Crazyflie 2.1 Brushless came out immediately people rushed to get out their sys id papers. There’s multiple out there now already.)
  • CRTP (the radio protocol) has been stable for over a decade.
  • Param/log TOC lets the Crazyflie tell a client at runtime what parameters/logs are available. This (among other things) allows years-old scripts to maintain compatibility with newer firmwares and even across different platforms in the ecosystem.
  • The firmware reports its own firmware revision so user logs can include this.
  • The deck port (the pins) are unchanged. The deck working on your Crazyflie 2.0 works on your Crazyflie 2.1 Brushless.
  • Out-of-tree extension points; allows writing apps controllers and estimators for the community to separate their work from our firmware version.

49 Crazyflies, 1 Crazyradio, and cflib2

  2026-07-06  |     |    Leave a comment

Flying formations with a swarm is always fun to develop and watch, but it is also a great way to stress-test the software behind it. As part of the development of cflib2, we put it through one of its toughest tests yet: flying 49 Crazyflies in coordinated formations.

The entire swarm was controlled using a single Crazyradio 2.0, highlighting the combined improvements in cflib2 and Crazyradio firmware over the past few months.

The setup

The hardware configuration was relatively straightforward. We used 49 Crazyflie 2.1 Brushless drones, each one equipped with a bottom-mounted Color LED deck for vivid lighting effects. For positioning, we used the Lighthouse positioning system, covering the entire flight area, which was roughly 5x5x2m. Its accuracy allowed the Crazyflies to fly grid formations with just 0.4m spacing between them.

One of the big practical challenges when managing a large swarm is swapping the depleted batteries for charged ones. Thanks to the Crazyflie 2.1 Brushless PCB design, each drone can now charge while sitting on its charging dock, making it much easier to prepare the swarm for the next flight.

Flying the formations

The swarm performed a sequence of synchronized formations under the control of a central PC. Rather than streaming the full trajectories to every drone, the formations are built using the Crazyflie’s High-Level Commander. Each Crazyflie receives simple motion commands such as go to or spiral, and executes the corresponding trajectory onboard. At the same time, it receives commands for changing the color of the Color LED deck.

Using cflib2, these commands can be sent to all 49 Crazyflies through a singe Crazyradio 2.0, which was not possible with cflib.

Looking ahead

This demonstration is an exciting milestone for cflib2 and showcases what the new library makes possible. While controlling 49 Crazyflies is an impressive demonstration, cflib2 is designed to benefit projects of every size. Whether you are flying a single Crazyflie or coordinating a large swarm, the goal is to provide a faster, more scalable, and more robust communication library.

Most of the functionalities from cflib have already been migrated to cflib2, and development is continuing. For many applications, cflib2 is already ready to use, so if you would like to try it out, you can find the repository here.

Bitcraze at ICRA 2026: Highlights from Vienna

  2026-06-15  |     |    Leave a comment

ICRA 2026 has wrapped up, and we’re back from a fantastic week in Vienna! Booth 91 was busy from start to finish, and we wanted to put together a short highlight video to share some of what happened — for everyone who stopped by, and for everyone who couldn’t make it this year.

The Swarm Demo

At the center of our booth was our live autonomous swarm demo — multiple Crazyflies flying autonomously in a controlled indoor environment, with everything tracked, repeatable, and stable across runs. We also could play around with our Lighthouse wand – which was also a great solution for troubleshooting the few misbehaving drones we had during those 3 days.

SwarmGPT, Live and Interactive

One of the highlights of the week was demonstrating SwarmGPT together with the Learning Systems and Robotics Lab (LSY) at the Technical University of Munich. SwarmGPT explores a simple but powerful idea: instead of hand-coding trajectories, you describe the intent — pick a piece of music, prompt a style or expression — and the system handles the planning and safety while the swarm performs it.

This time around, we brought a more interactive version of the demo than our end-of-year collaboration a few months back, and visitors got to try it out for themselves at the booth. Watching people prompt the swarm and then watch their idea come to life in the air was a great reminder of how far natural-language interfaces have come, and how much room there still is to explore in this space.

Research We Saw on the Crazyflie

Beyond our own demos, one of our favorite parts of ICRA is talking with our users and seeing what the community has built. This year was no exception — we spotted Crazyflies appearing in research spanning multi-agent coordination, modular micro-UAVs designed for autonomous mid-air docking, and decentralized swarm control approaches where each drone makes its own decisions based on local information rather than a central planner. Some examples include:

It’s always a bit surreal to see the same small quadcopter we ship from our office end up at the center of such different research questions — from choreography and language-driven control, to docking and modular hardware, to fully decentralized swarms. If you presented work involving the Crazyflie this year, thank you for stopping by and sharing it with us — and if you left a poster behind, it’s already found a home on our office wall.

Thanks for Stopping By

ICRA continues to be one of our favorite events of the year, not just for the demos, but for the conversations. Someone describes a challenge they’re running into in their lab, and a few months later, that conversation has often turned into a feature, a library improvement, or a new piece of hardware. If you stopped by booth 91, told us about your research, or just said hello, thank you. We’re already looking forward to the next one!

If you’d like to dig deeper into any of what’s shown in the video, or want to get started with the Crazyflie yourself, head over to bitcraze.io or reach out at contact@bitcraze.io.

The Community Behind the Crazyflie

  2026-06-08  |     |    Leave a comment

Whether You Realize It or Not, You’re Part of the Crazyflie Community

Most people probably don’t think of themselves as members of the Crazyflie community. They’re busy finishing experiments, writing papers, debugging flight controllers, supervising students, preparing grant applications, or trying to make a deadline. And yet, whether you think about it or not, you’re part of it.

Every time a paper is published, a GitHub issue is filed, a forum question is answered, or a new experiment is shared, the platform changes a little. Other researchers discover new approaches. Students inherit new examples. Future users benefit from lessons that someone else learned the hard way.

The Crazyflie ecosystem is not defined by Bitcraze. It is defined by thousands of individual decisions made across universities, research institutes, classrooms, and laboratories around the world, which makes us curious:

  • What are you working on?
  • What tools do you rely on?
  • What parts of the ecosystem help you move faster, and which parts slow you down?
  • What should we spend more time improving?

To help answer those questions, we’re running a community survey. Not because we need validation for decisions we’ve already made, but because many of the decisions we will make next should be informed by the people who use the platform every day.

If you use the Crazyflie, your experience matters. Make your voice heard!

Follow this link to participate in the survey!

We’ll close the survey June 15th.

Said Alvarado-Marin in front of his research poster at ICRA 2026.