crazyflie

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.

Controlling Crazyflies with a Magic Wand

  2026-05-25  |     |    Leave a comment

Some Fun-Friday projects begin with a clear goal and a straight path to the finish line. The best ones, however, take you somewhere completely unexpected.

This project originally set out to build a device for determining spatial coordinates within a Lighthouse-covered flight area. Instead, it evolved into the Lighthouse Wand, a hand-held “magic wand” letting you grab and move drones in 3D space just by pointing at them.

How it works

The Wand is a Crazyflie platform with a Lighthouse positioning deck. That’s enough for it to know its own position and orientation in the room. When the button is pressed, it starts broadcasting those 6 numbers over Peer to Peer radio.

Any Crazyflie/receiver in the room on the same radio channel, listens to those packets and runs a simple “grasping” algorithm: while the wand line (positive x-axis) passes close enough to the drone, it builds up a confidence score. Once the score crosses a threshold, the drone is considered grasped. From that point on, it just keeps a specific distance from the wand, while being on the wand line.

When the button is released, the grasped drone either hovers in place, or lands, depending on the release height.

The Color LED deck on the receiver drone, gives you visual feedback: yellow while the Crazyflie is building up its confidence score, green when it’s grasped, and red when it’s landing.

A big advantage of this system is that all interactions run entirely onboard the Crazyflies, allowing them to operate without relying on the cfclient or cflib during flight.

The hardware design

The wand is a Crazyflie Bolt 1.1 with a Lighthouse positioning deck and a Buzzer deck for audio feedback. To allow for user input, I created a simple “Button deck” based on the Prototyping deck utilizing the GPIO pins of the Crazyflie. It also includes an LED for visual feedback when the button is pressed.

The casing is fully 3D printed in PLA and was designed to give the device a more wand-like feel in the hand. Its shape also makes it easier to hold, aim, and use intuitively during interaction.

The firmware design

Both the Wand and the receiver are firmware apps created on top of the crazyflie-firmware. In the design that I followed, there is a clean separation between the two parties. The wand is a pure broadcaster: it only reads its own pose and transmits it. All grasping logic and flight control run independently on each receiver. Since each receiver is fully autonomous, the system scales to any number of drones with no extra load on the wand.

Where to find the Lighthouse Wand?

A version of the Lighthouse wand is now integrated in our decentralized swarm demo, where it can be used to interact with multiple drones, while the collision avoidance algorithms are still on. This system was first showcased at the European Robotics Forum 2026 in Stavanger, and we’ll also be bringing it to ICRA 2026. If you’re there, stop by booth 91and try flying a bunch of Crazyflies yourself using the wand.

You can find the complete Lighthouse Wand project in this repository. It contains the firmware, the hardware files, and detailed documentation to build and experiment with the wand yourself.

crazyflie-demos: a new home for Crazyflie examples

  2026-05-18  |     |    Leave a comment

If you’ve ever gone looking for a more advanced, or use-case-specific Crazyflie example (something beyond the basic single-feature ones), you’ve probably ended up digging through the cflib and crazyflie-firmware example folders. That’s about to change.

We’ve created a new repository: crazyflie-demos. It’s a dedicated place where both us at Bitcraze and the broader community can host self-contained, well-described Crazyflie demos.

Why a new repository?

The examples in the core Bitcraze repositories were meant to be kept focused: demonstrating one feature, one API, or one subsystem at a time. But real demos tend to grow beyond that pretty quickly. Once you start combining positioning systems, swarming, custom firmware apps, external sensors, or other integrations, things stop fitting naturally into the firmware or library repos.

crazyflie-demos gives those larger, more practical examples a proper home, and finally provides a good answer to the question: “where should I put this cool thing I built?”

Why not just a folder of examples?

We want to avoid the fate of some older example collections that gradually turned into an unmaintained pile of half-working demos and missing context.

The goal with crazyflie-demos is that every demo should be properly documented and actually runnable. That means clear descriptions, listed dependencies, and enough context to understand what’s going on without digging through source code for an hour.

Another important part is reproducibility: each demo is self-contained and uses pinned dependencies, so an example you clone two years from now should still work.

What’s in there already?

The repository is organized by demo type:

  • scripts/cflib: Host-side Python scripts using crazyflie-lib-python, covering the full Crazyflie API.
  • scripts/rust: Rust demos using crazyflie-lib-rs, showcasing its high-performance and native async support.
  • scripts/cflib2: Early demos for our new Python library, crazyflie-lib-python-v2, built on top of the Rust library. cflib2 doesn’t have a release yet, but we’re already writing demos for it to test the API and the performance.
  • firmware: Out-of-tree firmware apps that are flashed directly to the Crazyflie. Each demo carries its own crazyflie-firmware submodule so you’re always building against the right version.
  • hybrid: Demos that combine onboard firmware with a host-side script working together.

A place to share your work

A big motivation behind crazyflie-demos is making it easier to share work with the community.

If you’ve built something useful, or just a fun experiment using our products, this is the place for it. Not everything needs to live in its own repository or branch. A well-described demo here makes it easier for others to find, understand, and build on your work, and most importantly, to get inspired by it.

We’ll also be using this repository as the go-to reference whenever people ask for more use-case-specific examples, so good demos here will naturally help more people discover what’s possible with the Crazyflie ecosystem.