Let us talk controls at the IEEE CSS days

2026-10-19 | Stefan | 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.

What does years of firmware in development look like?

2026-09-21 | Stefan | 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.

Crazyflie in Research: A Growing Research Ecosystem

2026-09-14 | Fredrik Ehrenstråle | Leave a comment

We try to keep up with recent research using the Crazyflie^®. We read a lot of papers and check out new GitHub projects, controllers, and simulators. Sometimes the topics are straightforward and sometimes we learn new things from completely unexpected angles. It is such a treat to see where the community is heading, and it helps us prioritize our own work, from new features and functionality to the hardware we develop next.

Most of the time we look at the Crazyflie applicability close up, but two recent studies in particular put it into a bigger context:

In their 2026 A Scoping Review of the Crazyflie Ecosystem: An Evaluation of an Open-Source Platform for Nano-Aerial Robotics Research paper, Rareș Crăciun and Adrian Burlacu reviewed the Crazyflie research ecosystem from 2015 to 2025. They identified 321 studies across 183 publication venues, with research spanning control, navigation, swarms, localization, sensing, AI, safety and simulation. The number of publications has grown quickly too, reaching 105 papers in 2024. The authors calculate an annual publication growth rate of 38.9%.

The institutions represented include ETH Zurich, University of Bologna, TU Delft, Università della Svizzera italiana, Tsinghua University and University of Toronto, among many others. For us, the breadth is at least as interesting as the number of papers. The same underlying platform is being used to investigate quite different research questions.

In their 2026 NanoCockpit: Performance-optimized Application Framework for AI-based Autonomous Nanorobotics paper, Elia Cereda, Alessandro Giusti and Daniele Palossi took a different approach. They surveyed nano-quadrotor research from 2020 to 2024, using Scopus as the primary source and manually reviewed the publications to identify the platforms being used. Their final dataset contains 586 relevant publications and the Crazyflie was used in 381 of them, or 65%. DJI Tello was second with 128 publications, or 21%, followed by Parrot Mambo with 50.

Cereda, Giusti and Palossi describe Crazyflie as the de facto standard platform for nano-robotics research. We’re as vain as the next guy, but we’re mostly interested in what researchers actually benefit from, namely a shared research platform that becomes more useful as the body of reproducible work, software and experimental knowledge around it grows.

Figures from Crăciun & Burlacu (2026), *A Scoping Review of the Crazyflie Ecosystem*. CC BY 4.0.

Software momentum in the community

The Crazyflie firmware has now accumulated more than 4,000 commits. The repository has around 1,500 stars and more than 1,200 forks, and Bitcraze currently maintains 77 public repositories around the ecosystem.

Some of that work is ours, but a lot of the interesting stuff isn’t. Researchers and developers have contributed controllers, estimators, positioning methods, simulation environments, swarm tools, drivers, fixes and documentation, and many projects live outside our repositories but build directly on the platform.

NanoCockpit is a good example. The researchers took the Crazyflie and AI-deck, found ways to use the available computing resources more effectively, and demonstrated the resulting framework on applications including human pose estimation, relative localization and autonomous drone racing.

Someone else can now build on that, which is what makes the ecosystem useful.

A foundation to build on

The Crazyflie a researcher starts with today is not just the hardware we designed. It comes with years of firmware development, libraries, positioning systems, simulation tools, documentation and published experimental work. Each contribution adds a little more to that foundation, and over time, that compounds.

To everyone who has published with Crazyflie, contributed code, shared a tool, reported a bug, documented an experiment or pushed the platform into a research area we hadn’t anticipated: thank you.

You’re not just using the Crazyflie ecosystem. You’re helping build it.

Help us make the next research video compilation

2026-08-03 | Barbara | Leave a comment

It’s about time for a new research video compilation, and this time we want your help putting it together!

If you’ve followed the blog for a while, you know we love making these compilations: from the very first one, to 2023’s roundup, to the latest edition.

Every time, we’re blown away by what the community manages to do with the Crazyflie. Everything from swarms and aerial manipulation to novel mechanical designs, perception and mapping, you name it. It’s a reminder of just how far people push this little platform in directions we never would have imagined ourselves.

And every time, the hardest part is finding all the great footage that’s out there. We do our best to scout for it by combing through papers, conference proceedings, and YouTube, but we know we don’t catch everything. Some of the best material never makes it online in an easily searchable way, or ends up buried a few pages deep in a lab’s channel, or is still sitting on a hard drive waiting for the right moment to be shared.

So this time, instead of only hunting for videos ourselves, we’re asking you directly: if you’ve used a Crazyflie in your research and have video to show for it, we’d love to see it!

What we’re looking for

We’re after footage that shows off what your project can do — the more visually interesting, the better! Think flight demos, swarm behavior, novel mechanical tricks. Past compilations have featured everything from hopping quadcopters to gas-seeking swarms to drones that land upside down, so honestly, if you think it’s cool, there’s a good chance we will too.

It doesn’t need to be professionally edited; raw lab footage works great too, we’ll take care of putting the compilation together.

Since our last compilation already covered 2023 and 2024, we’re looking for footage from 2024 onwards this time — so anything newer that hasn’t been featured yet is exactly what we want.

A short description of the project, a link to the paper (if there is one), and the names and affiliations of everyone involved would help us a lot in giving proper credit — we always try to list every contributor alongside their work, the way we’ve done in previous posts.

How to send it in

Send us a link to your video (or the file itself, if it’s not online yet) together with a short project description to contact@bitcraze.io. Let us know if it’s already been used in a previous compilation, so we can be sure to feature fresh footage this time around. There’s no strict deadline yet, but the sooner we hear from you, the more likely your project makes it into the mix.

As always, we’ll do our best to fit in as much as we can and showcase the breadth of what’s happening in the Crazyflie community. You can also check out our applications overview if you want to see the kind of projects we’re already tracking; or browse this Youtube playlist for more research videos, from us or our partners.

We’re constantly amazed by what this community builds, and we can’t wait to see what you’ve been working on. Thank you in advance to everyone who takes the time to send something our way — it genuinely makes these compilations possible!

Why Bitcraze Chose Openness

2026-07-27 | Fredrik Ehrenstråle | Leave a comment

If you’ve spent any time exploring the Crazyflie^® ecosystem, you’ve probably noticed that almost everything is out in the open. The firmware is public. The communication protocols are documented. Development tools, client libraries and documentation all live in public repositories.

That’s not an accident, and it wasn’t the result of a carefully crafted business strategy. It started with three engineers trying to solve an interesting technical problem.

A project built for curiosity

The Crazyflie started as an engineering challenge: build a very small quadcopter that could fly indoors. That sounds simple now, but the constraints were severe. Weight mattered. Power mattered. Every component had to justify its place. The printed circuit board was not just electronics; it became part of the structure of the aircraft.

From the beginning, the project was shaped by curiosity rather than product planning. The point was not only to make something fly. It was to understand how it could fly.

When the early work was shared publicly, people were not only interested in the result. They wanted to understand the system. They wanted to inspect the code, study the design, modify the firmware and try their own ideas, and that response mattered. It showed that the real value of the Crazyflie was not simply that it was small. The value was that it could become a platform for people who wanted to learn, experiment and build.

Openness as an engineering principle

For engineers, openness has always been practical before it was philosophical. If you’re trying to understand why a controller behaves a certain way, you need to read the code. If you’re developing a new positioning algorithm, you need to understand how measurements flow through the estimator. If you’re integrating new hardware, you need documentation instead of guesswork.

This is why openness made sense for Crazyflie from the start. The intended users were not passive operators. They were researchers, students, developers and hardware-oriented innovators. For them, the ability to inspect and modify the system was not a bonus feature. It was part of the reason to use the platform at all.

That remains one of the clearest differences between a development platform and a finished consumer product. A consumer product tries to hide complexity. A development platform must expose enough of the system for serious users to understand and change it.

What “open” means in a Crazyflie context

The word “open” can become vague if it is not defined. For Bitcraze, openness does not mean that every part of the company, every internal process or every commercial asset is unrestricted. It means that the Crazyflie ecosystem is designed to be inspectable, modifiable and extendable in the areas that matter most to users.

Firmware is open source. Software libraries are open source. Communication protocols are openly documented. Development tools are public. Documentation is public.

Hardware follows a slightly different model. Schematics, board designs and technical documentation are published to help users understand, integrate and extend the platform, while Bitcraze also maintains the commercial foundations required to continue designing, manufacturing and supporting new hardware. That distinction is deliberate.

Why are there boundaries?

Openness is not without trade-offs, though, and every engineering decision involves balancing competing goals.

Bitcraze invests heavily in maintaining firmware, documentation, development tools and community support. Those efforts are funded by selling hardware that researchers and developers trust.

The company also has responsibilities that go beyond publishing code. Safety matters when products can fly. Quality matters when researchers need consistent, reproducible hardware. Trademarks matter because users should know they’re buying genuine Bitcraze products and receiving the level of support they expect.

Drawing boundaries doesn’t contradict openness. It’s part of making openness sustainable.

A philosophy that has aged well

Open source was already a major force when the first Crazyflie was built. The practical truth is that openness was the right fit for the kind of platform we wanted to build. The Crazyflie was never meant to be a sealed product. It was meant to be explored, modified and built upon. That made openness a natural engineering choice.

Over time, that choice has aged well. Researchers increasingly care about platforms they can inspect and reproduce. Students need systems they can learn from, not only operate. Developers want tools they can extend instead of work around.

Those are exactly the kinds of people Crazyflie was built for.

More than a licensing model

Openness is partly defined by license terms, but its practical value is measured by what it allows people to do. A useful development platform should help people explore ideas, understand how things work and build something new on top of what already exists.

That was the motivation behind the first Crazyflie, and it is still the principle that guides Bitcraze today.

If you’re interested in the details of how Bitcraze approaches licensing, hardware and software openness, we’ve collected those principles on our Open Source Philosophy page.

Looking Across Recent Research Using the Crazyflie

2026-07-13 | Fredrik Ehrenstråle | Leave a comment

At Bitcraze we really have a front-row seat in robotics research. Every week, various papers appear: Conference papers, PhD theses, journal articles, and preprints that resonate across the community. Sometimes they arrive from universities we’ve worked with for years, and sometimes from labs we’ve never heard of before.

We are constantly humbled by the possibilities and the lengths that the community takes the platform. Although applications seem endless, we’ve grouped recent papers from the community into broad categories to give a useful snapshot of how different labs and research groups are answering questions from different angles.

Swarms are all about robustness (and size)

A decade ago, entire keynote talks revolved around ever-larger choreographed formations. Don’t get me wrong, it’s always impressive to see large swarms, but recent papers seem to increasingly raise questions around reliability.

How do individual robots coordinate without overwhelming the communication network? What happens when information arrives late? What if one vehicle fails? How do you distribute decisions without relying on a central controller?

DMPC-Swarm: Distributed Model Predictive Control for Nano-UAV Swarms is a good example. Rather than treating coordination as a centralized optimisation problem, the authors investigate distributed model predictive control, with the optimization shared across the swarm rather than handled by a single central unit (see https://link.springer.com/article/10.1007/s10514-025-10211-w).

It’s also interesting to see how much current work still builds on the foundations laid by the original Crazyswarm framework (https://ieeexplore.ieee.org/document/7989376). Nearly a decade later, it continues to serve as a reference point for new ideas, while more recent work pushes towards larger, more resilient, and more scalable swarm systems (https://ieeexplore.ieee.org/document/10611499).

Flying robots are literally touching the world

The most common drone use case is still the observer. To inspect bridges, map forests, measure crops, and capture data, but aerial manipulation turns that idea upside down.

Instead of asking what a flying robot can see, researchers ask what it can do. Some groups investigate cooperative payload transport (https://ieeexplore.ieee.org/document/8461014). Others focus on cable manipulation and contact-rich interaction (https://ieeexplore.ieee.org/document/10382688). More recent work explores increasingly sophisticated manipulation strategies while maintaining stable flight (https://ieeexplore.ieee.org/document/10802794).

Aerial manipulation forces multiple disciplines together. Control theory, estimation, mechanical design, and physical interaction all become tightly coupled. As these systems mature, flying robots may increasingly move beyond sensing and inspection roles into applications that require direct interaction with the physical world.

The challenge of making AI practical

Look anywhere and everything’s “AI”, but thankfully the research papers tell a nuanced story. Researchers are asking practical questions, if learning can improve flight performance without sacrificing stability, if sophisticated controllers can run on tiny embedded processors, and if simulation can reduce the amount of expensive real-world data needed before deployment?

DATT: Deep Adaptive Trajectory Tracking explores how learned components can complement classical control methods under uncertain conditions (https://arxiv.org/abs/2310.09053).

Learning to Fly in Seconds takes another route, demonstrating how efficient training in simulation can dramatically shorten the path to successful real-world flight (https://ieeexplore.ieee.org/document/10517383).

Palossi et Al. investigates yet another line of research on how machine learning can be integrated directly into flight control, allowing nano-quadcopters to improve their performance while remaining reliable and computationally efficient (https://ieeexplore.ieee.org/document/8715489)..

The frontier isn’t simply making robots smarter. It’s making sophisticated autonomy accessible on hardware small enough to fit in the palm of your hand.

Can robots learn to work with people, not just around them?

Technical performance alone doesn’t determine whether a robotic system is successful. People need to understand what the robot is doing, communicate with it naturally, and develop enough confidence to work alongside it.

That has led researchers to investigate everything from gesture-based interfaces, or “SwarmTouch” (https://ieeexplore.ieee.org/document/8758191) to shared autonomy in Hand-worn Haptic Interface for Drone Teleoperation (https://ieeexplore.ieee.org/document/9196664) and broader questions around interaction and collaboration between humans and aerial robots bu La Delfa et Al. (https://ieeexplore.ieee.org/document/10973956).

In some cases, the hardest challenge is not controlling the robot itself, but designing the relationship between humans and machines. After all, even the most capable autonomous system ultimately exists to help someone accomplish something.

Sometimes the cleverest solution is the simplest one

Before a robot can make intelligent decisions, it must know where it is. For small aerial robots, this question is particularly challenging, since limited payload capacity restricts sensor choices, while limited onboard compute constrains what algorithms can realistically run. This has made nano-quadcopters an attractive platform for investigating efficient perception and navigation techniques.

In Visual Route-following for Tiny Autonomous Robots, published in Science Robotics, researchers demonstrated an insect-inspired navigation strategy using an omnidirectional camera mounted on a Crazyflie Brushless (https://www.science.org/doi/10.1126/scirobotics.adk0310).

Rather than constructing detailed maps of the environment, the robot simply learns visual routes and follows them. It’s an elegant reminder that engineering progress doesn’t always come from adding complexity, but from asking what can be removed.

That same philosophy appears elsewhere in recent perception and navigation research, where teams continue to develop increasingly efficient onboard perception and localization methods suited to the severe constraints of nano-quadcopters. NanoSLAM: Enabling Fully Onboard SLAM for Tiny Robots (https://ieeexplore.ieee.org/document/10343110, and Robust and Efficient Depth-Based Obstacle Avoidance for Autonomous Miniaturized UAVs are perfect examples of this (https://ieeexplore.ieee.org/document/10272390).

A community exploring difficult problems

What makes the broad body of Crazyflie research interesting is the sheer variety of approaches researchers bring to the same fundamental challenges. Across universities, laboratories, and disciplines, researchers continue to investigate cooperation, physical interaction, learning, perception, and human collaboration from different angles.

Taken together, these projects provide a glimpse of where robotics research is heading. There’s clearly more to find out, and we’re glad to keep being part of how people go looking.

Visit our Applications pages for more examples of how researchers, educators, and innovators are using the Crazyflie.

A simpler way to explore the Crazyflie ecosystem

2026-06-29 | Fredrik Ehrenstråle | Leave a comment

Over the years, the Crazyflie^® ecosystem has grown far beyond a single nano drone. It now also includes positioning systems, expansion decks, software libraries, simulation tools, research examples, educational resources, and a global community of researchers, educators, innovators, and developers.

The growth has been exciting, but it has also introduced a challenge. If you were new to Bitcraze, it was not always obvious where to start, what was possible with the platform, or how the different pieces fit together. To address that, we have made updates to bitcraze.io in an effort to make the ecosystem easier to understand, navigate, and engage with.

Starting from the questions people actually ask

When talking to the community, the same questions tend to come up:

What can I do with the Crazyflie?
Which hardware do I need?
Where do I find documentation?
How do I get started?
What are other people doing with the platform?
How can I contribute?

The updated website is an attempt at answering those questions more directly.

A new Applications section

One of the largest additions is a new Applications section. We now provide entry points also based on what people are trying to achieve. Whether your work involves swarm robotics, autonomous systems, perception and navigation, aerial manipulation, human-robot interaction, or STEM and education, the goal is to make it easier to discover relevant resources, examples, and recommended configurations.

For many visitors, this should provide a more natural starting point than navigating through individual products and documentation pages.

A clearer structure

We have also revisited the overall information architecture of the site. Content has been reorganized to make it easier to understand how products, software, documentation, tutorials, research examples, and community resources relate to one another.

The front page has been simplified, navigation has been streamlined, and page layouts have been updated to improve readability across the site.

Lowering the barrier to getting started

Another goal has been to reduce friction for new users. The Crazyflie platform serves a broad audience, from first-time students to experienced robotics researchers. We want newcomers to understand where to begin without having to learn the entire ecosystem first.

At the same time, we want experienced users to more quickly find advanced resources, technical documentation, and examples relevant to their work.

This is the first step

This is the first step in an ongoing effort to improve how information is presented and discovered across the Bitcraze ecosystem. We expect to continue refining content, adding resources, improving navigation, and learning from how the community uses the site.

If you explore the new site and find something confusing, missing, or particularly useful, we would love to hear from you. After all, the platform has always evolved together with its community. Take a look around and let us know what you think.

The Community Behind the Crazyflie

2026-06-08 | Fredrik Ehrenstråle | 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.

Bitcraze at ICRA 2026: Exploring the Future of Aerial Robot Swarms

2026-06-01 | Fredrik Ehrenstråle | Leave a comment

We are at ICRA 2026 in booth 91, and we are looking forward to a few days in Vienna for research discussions, technical conversations, and reconnecting with the community.

ICRA has always been a favorite of ours. It brings together researchers from very different domains, but despite different research goals, many face similar questions around how to build reliable experiments, iterate quickly, and evaluate results in a repeatable way.

Many of the improvements in the Crazyflie ecosystem over the years have started exactly there. Someone stops by the booth, describes a challenge in their lab, and shortly thereafter a feature, library, or hardware addition begins to take shape.

This year we are bringing a few things we are excited to discuss.

Towards larger and easier-to-manage swarms

Over the last months we have spent time improving how larger groups of Crazyflies behave and scale in practice.

Swarm experiments sometimes start small. Then a few drones become ten, ten become fifty, and suddenly radio communication and system overhead become part of the research problem itself.

Recent work around overall system performance has significantly improved how many Crazyflies can be handled from a single radio, reducing communication bottlenecks and making larger coordinated experiments easier to run. We are also working toward improved tooling and workflows for managing swarms, with the goal of reducing setup complexity and making experiments easier to reproduce. A transition to Rust has helped reduce connection overhead and improve responsiveness in larger systems.

We are looking forward to discussing where this work is heading and hearing what challenges researchers encounter in their own systems.

Tech talk: “A Swarm Welcome to New Aerial Robotics Functionality”

Wednesday, June 3rd, 12:45 CEST, at the Tech Talk Stage in Hall C7

We will give a tech talk focused on recent work around swarm functionality and capabilities.

The session will cover improvements that significantly expand what can be done with larger Crazyflie groups and how recent developments are reducing practical limitations in swarm experimentation.

If your work involves multi-agent systems, collective behaviors, or coordinated aerial robotics, stop by and continue the discussion afterward.

Demonstration: SwarmGPT and human interaction with robot swarms

On Wednesday afternoon, together with the Learning Systems and Robotics Lab (LSY) at the Technical University of Munich, we will demonstrate SwarmGPT running on the Crazyflie.

Some of you may remember the end-of-year collaboration a few months ago. This time we are bringing a more interactive version of the concept. SwarmGPT explores how natural-language intent can be translated into coordinated swarm behaviors. Rather than manually programming trajectories, users can pick a piece of music and prompt desired expression, and leave planning and safety mechanisms to the system to execute on.

Come by our booth and try it for yourselves.

Color, Rust, camera deck, and more

We will also bring several smaller developments and ongoing efforts that we have discussed on the blog over recent months.

Some of these include:

Continued work on Rust
Improved radio performance for larger groups of drones
The now available Color LED Deck
Early version of the upcoming camera deck
Discussions around improved swarm workflows and management support

The Color LED deck has turned out to be useful far beyond aesthetics. In swarm experiments, visible state information can help indicate timing, grouping, synchronization, and system behavior across multiple agents.

User survey

We will be running a community survey during ICRA. One of the strengths of the Crazyflie ecosystem is the breadth of research and experimentation happening around it. People use the platform in ways we never originally anticipated, often combining different hardware, software, and workflows depending on the research problem they are trying to solve.

The survey is an opportunity for us to better understand how the platform is being used today, and the feedback helps us make better decisions around priorities, tooling, documentation, hardware, and long-term roadmap direction.

We would greatly appreciate a few minutes of your time. Please complete the survey following this link.

Trade your poster with us

This has become a tradition. If you are presenting research involving Crazyflie and do not need your poster after your session, bring it by the booth.

We love collecting them and filling our office walls with the incredible range of work built on the platform. It is also one of our favorite ways of seeing where the community takes the Crazyflie next.

Bring your poster, and we will make sure you leave with a little Bitcraze treat in return.

Find us in booth 91

If you are working with Crazyflie already, considering it for your research, or simply want to discuss ideas around swarm robotics, autonomous flight, perception, AI, or experimental workflows, stop by booth 91.

We are looking forward to the conversations.

Crazyflies: An Unlikely Tool for Subscale Urban Air Mobility Research

2026-06-01 | Spencer Folk | Leave a comment

When people think of Urban Air Mobility (UAM), they might think of large, futuristic eVTOL aircraft carrying people between skyscrapers, not a 30-g nano-quadrotor fitting in the palm of their hand. However, testing full-scale aircraft in chaotic urban wind fields is dangerous, expensive, and practically impossible. During my PhD thesis, I found that the brushless Crazyflie makes an ideal subscale proxy to rigorously explore flight in these complex microclimates.

Urban microclimates are notoriously unpredictable and dangerous for aircraft. High-intensity wind gusts and spatial gradients are formed by multi-scale interactions between the atmospheric boundary layer and the buildings, bridges, and other urban infrastructure that define our skylines. There are entire fields dedicated to studying urban wind patterns using supercomputers and precise wind tunnel testing, but how can drones leverage all this data and modeling in real time?

Put another way, if we want package delivery drones and electric air taxis safely operating in urban airspaces, we need innovative ways for aircraft to predict hazardous wind conditions and adapt to them on the fly. Our initial research showed that drones could predict surrounding time-averaged urban winds with reasonable accuracy using LiDAR, and our follow up work suggests that incorporating these local wind predictions into navigation could reduce potential crashes and even improve energy efficiency.

This article breaks down the hardware details for experiments during the final six months of my thesis, where the brushless Crazyflie played a pivotal role in validating concepts from my thesis in the real world.

A Subscale UAM Testbed

A lot of research related to drone wind estimation is limited by the lack of ground truth data available to compare against. With my research, I really wanted to use a highly instrumented laboratory environment, where we could tightly control the experimental conditions and get accurate, repeatable trials without being at the mercy of the weather.

To accomplish that, we used the WindShaper facility at NASA Ames Research Center in Mountain View, CA, a state-of-the-art open-air wind tunnel (the “WindShaper”) positioned inside a basketball court-sized motion capture space. We mimicked “urban winds” using wooden boxes meant to represent buildings.

The problem was that the WindShaper was only so big. We needed a similarly scaled drone that could represent our eVTOL. That’s where the Crazyflie came in!

The (Modded) Crazyflie

For multiple reasons, all relating to dynamic similitude, the Crazyflie ended up being the perfect size for our experiments. The timing was perfect too because the brushless Crazyflie had just been released, offering a similar footprint as the original Crazyflie, but with the additional thrust and battery life necessary to carry our payloads and handle gusty wind conditions.

We modified the Crazyflie with two additional sensors. The first was an INA260 power sensor that we used for… well, measuring the power draw from the battery! The second sensor was a bit more interesting. In partnership with the Microrobotics Lab at Carnegie Mellon University, we put a whisker-based air flow sensor on the Crazyflie to measure the wind. You can read more about that neat sensor here.

The all up weight, including the battery, power sensor, whisker, and motion capture markers was 57g, almost double the standard weight. With a 350mAh battery we could get about 3 to 5 minutes of flight, depending on the wind speed, which was just enough time for us to run our experiments.

Actuator, Aerodynamic, and Power System Identification

I did two experiments to characterize the brushless Crazyflie. The first experiment involved strapping the Crazyflie onto a thrust stand with an optical RPM sensor to model the relationships between thrust, speed, commanded PWM signal, and battery supply voltage. The last three signals were relevant because at the time the firmware didn’t support direct motor speed measurements!

The second experiment involved subjecting the Crazyflie to wind speeds varying from 0 m/s up to 8 m/s. For these experiments, I used the onboard accelerometer to measure the net drag force, which required being able to subtract the static thrust from the propeller, hence the previous experiment; the INA260 sensor to measure power draw from the battery; and a combination of motion capture and a pitot-static probe on a tripod to measure the drone’s ground speed and wind speed, respectively.

The plot above shows a surprisingly linear relationship between the acceleration and the sum of airspeed and motor speeds for the x body axis. This is known as rotor drag, and it’s generally considered the dominant form of drag for quadrotors at lower airspeeds. The slope of this line is the rotor drag coefficient. What this model lets us do is infer the airspeed along the x axis from the accelerometer and motor speeds alone, no dedicated wind sensor necessary!

Lastly, I used the same experiment to model the power curve for the Crazyflie. What we were able to show was that there is a measurable dip in the average power consumed by the brushless Crazyflie at steady level forward flight. This effect is well-documented in full-scale helicopters, where the translational lift effect makes the rotors more efficient in forward flight, but it is rarely captured or documented on a scale as micro as the Crazyflie. To the best of my knowledge, this is one of the first empirical confirmations of any sort of power dip on a nano-UAV, which may (or may not!) have relevance as we think more about taking these tiny drones out into the wild.

My measurements indicate an average power consumption of 10.56 Watts in hover, placing the hover efficiency at around 0.188 W/g. Keep in mind this is for the modded Crazyflie weighing in at 57g.

Putting It All Together

The ultimate goal with all these experiments was to test out my methods for wind prediction & estimation and wind/obstacle-aware motion planning in real time. We tested these algorithms through multiple trials across five “building” configurations, totaling over an hour of actual flight time. Below is a video showcasing the wind field prediction happening in real time.

In this trial, the Crazyflie is trying to track the XY location of the end of the wand while also avoiding the obstacles using (simulated) LiDAR scans. Meanwhile the WindShaper is throwing wind at about 4 m/s at the drone. This particular trial was focused more on the wind prediction side of things rather than motion planning, so the motions aren’t particularly exciting. Nevertheless, the network was capturing salient flow features like the high speed wind tunnel effect between the building clusters.

Closing Thoughts

Building this testbed proved that nano-quadrotors like the Crazyflie are far more than just educational toys or swarm demonstrators. When properly characterized, their tight physical scaling parameters make them uniquely qualified as safe, high-fidelity proxies for validating the next generation of Urban Air Mobility algorithms.

None of this would have been viable without the open-source architecture of the Bitcraze ecosystem. Being able to easily modify the firmware to interface with our custom INA260 power monitor, log high-frequency accelerometer measurements, and dynamically communicate with external motion capture and WindShaper using ROS allowed us to treat the Crazyflie as a true subscale UAM development kit.

If you want to dive deeper into anything you found interesting in this article, or better yet get access to the data I collected, you can find more details in my full dissertation (available on arXiv) or reach out to me on LinkedIn!

Category: Random stuff