On October 13–14, we’re heading to the WASP Academia and Industry Days 2026, where we’ll be exhibiting, meeting researchers and industry representatives, and taking part in the event’s speed dating sessions.
For those unfamiliar with WASP, the Wallenberg AI, Autonomous Systems and Software Program is Sweden’s largest individual research program, funded by the Knut and Alice Wallenberg Foundation. It brings together universities and industry to advance research in artificial intelligence, autonomous systems, and software, with a strong emphasis on scientific excellence and industrial relevance.
The annual Academia and Industry Days are an opportunity for these communities to meet, exchange ideas, and explore how research can lead to new applications and collaborations. This year’s theme, For the Betterment of Sweden, puts the focus on how advances in these fields can contribute to society and industry.
A flexible testbed for autonomous systems research
At Bitcraze, we’re particularly interested in how new ideas in autonomous systems can be explored, tested, and developed in practice. The Crazyflie platform has become a widely used research tool in this field, supporting everything from flight control and navigation to multi-agent coordination and swarm robotics.
Crazyflie is more than a small flying robot. It’s a purpose-built, open-source research platform designed to make experimentation accessible and flexible. Its modular hardware, open software stack, and supporting ecosystem allow researchers to develop and test their own algorithms, integrate new sensors, and move from simulation to physical experiments without having to build an entire robotic system from scratch.
With Crazyflie used in hundreds of scientific publications and research projects worldwide, we’re pleased to see how the platform continues to support new ideas and discoveries. Many of the challenges being explored also have clear connections to industrial applications, making WASP Academia and Industry Days a particularly interesting place for us to exchange experiences and explore new opportunities.
Let’s meet in Stockholm
We’ll be exhibiting throughout the event and participating in the speed dating sessions, where we hope to connect with researchers working on interesting robotics challenges.
We’re looking forward to hearing what others are working on, exchanging experiences, and exploring where our platform and expertise might contribute. Perhaps some of those conversations will lead to new collaborations, research projects, or applications we haven’t considered yet.
If you’re attending WASP Academia and Industry Days, come by our stand and say hello to Enya and Fredrik!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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
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.
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.
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 built a small drone for people who want to understand how things fly. The community took it considerably further than that. The citations keep arriving from directions we didn’t anticipate. Spacecraft dynamics. Tactile human-swarm interaction. Onboard deep learning. Mapping algorithms that fit inside a nano-drone’s compute budget. The platform’s combination of openness, known dynamics, repeatable behavior, and low replacement cost turns out to be useful for a wider set of problems than any single team could have imagined building for.
What follows is by no means a comprehensive survey, but rather a selection of research areas where the Crazyflie has found a home, each illustrated with recent work. We find it genuinely interesting that the same hardware can be useful across this range, and we hope it gives other researchers a sense of what is possible.
1. Decentralized Multi-Agent Coordination and Swarm Control
Multi-agent coordination is probably the research area most closely associated with the Crazyflie, and for good reason. The platform’s light weight, predictable dynamics, and relatively low cost per unit make it practical to run experiments with enough agents to observe emergent swarm behavior, rather than just simulating it. A lab can field a meaningful swarm without the capital outlay that larger platforms would require.
Recent work has pushed this in some interesting directions. Decentralized approaches, where each agent makes decisions based on local information rather than a central planner, are particularly well-served by a platform where individual failures don’t cascade into catastrophic system loss. Research on collision avoidance, formation control, and consensus algorithms benefits from hardware that can absorb the crashes that inevitably happen when you are testing novel coordination strategies.
The ROS 2 ecosystem around the Crazyflie has matured considerably, with frameworks like Crazyswarm2 enabling standardized multi-drone experiments that other labs can replicate. The reproducibility this enables is meaningful: a coordination result demonstrated on Crazyflies in one lab is demonstrable in another (see “CrazyChoir: Flying Swarms of Crazyflie Quadrotors in ROS 2” (arXiv)).
2. Onboard AI and Edge Inference at Nano Scale
What can you fit inside a couple of dozen grams grams and still have compute left over for intelligence? Quite a lot, it turns out, especially when researchers are motivated to find out. The AI Deck, which adds a GAP8 system-on-chip with a camera and Wi-Fi, opened a wave of work on fully onboard perception and inference pipelines on nano-UAVs.
More recently, work using custom expansion decks with the GAP9 processor has enabled onboard SLAM and scan-matching at take-off weights around 46 grams, showing that the platform’s expansion architecture makes it a meaningful target even as compute capabilities grow. See “Ultra-Lightweight Collaborative Mapping for Robot Swarms” (arXiv).
The Crazyflie’s transparent hardware design is important here: researchers can build custom decks, verify the power budget, and integrate new silicon without waiting for a vendor to offer an approved configuration.
3. Spacecraft and Orbital Dynamics Simulation
Researchers at the University of Houston, in collaboration with the US Air Force Research Laboratory, used Crazyflie drones to simulate the relative motion dynamics of spacecraft in formation, specifically the Clohessy-Wiltshire equations that describe how objects move relative to each other in near-circular orbit.
The reasoning is practical: testing spacecraft autonomy on-orbit is expensive and high-risk. Ground-based testbeds using air bearings exist, but are complex and space-intensive. A small fleet of Crazyflies, running scaled versions of orbital trajectories in an indoor lab, offers a much cheaper and more accessible way to validate formation-flying control laws and neural network guidance systems before committing to hardware that will be launched into space.
4. Reinforcement Learning: From Simulation to Real Hardware
Reinforcement learning (RL) for drone control has been a thriving research area for years, but the gap between simulation and physical hardware remains a hard problem to close. The Crazyflie’s well-documented dynamics, consistent manufacturing, and open firmware have made it a preferred target for sim-to-real transfer research, because the sim and the real thing can be brought into close agreement.
Work in this space spans a wide range of problem settings. Multi-agent RL for collision-free navigation, safe RL with control barrier functions, landing on moving targets, and agile trajectory following in cluttered environments have all been demonstrated on Crazyflie hardware. A common thread is that the platform’s low inertia and predictable response make it a fair test: there is nowhere to hide on a platform this light and responsive, and if the policy is sloppy, it falls (see “AttentionSwarm: Reinforcement Learning with Attention Control Barier Function for Crazyflie Drones in Dynamic Environments” (arXiv).
The “LEARN framework”, which claims to run a compact attention-based RL policy on six Crazyflies for multi-robot navigation through 0.2-meter gaps at 2 m/s, is a recent example of how far this line of work has come. The system runs fully onboard, using only time-of-flight sensors, and transfers directly from simulation to real hardware without fine-tuning. See “LEARN: Learning End-to-End Aerial Resource-Constrained Multi-Robot Navigation” (arXiv).
5. Human-Swarm Interaction and Expressive Robotics
An unexpected corner of the research community is the one that adopted the Crazyflie to the human-robot interaction field. It turns out that a swarm of small, quiet, slow-moving drones is a better vehicle for studying how humans interpret and respond to group robot behavior than many ground robot alternatives.
Work in this space ranges from the technical to the almost philosophical. Researchers have studied whether humans perceive swarm motion as intentional and communicative; whether vibrotactile feedback can give operators an intuitive sense of swarm state during physical interaction; how flight formation shapes emotional perception; and how to design impedance-controlled swarms that respond naturally to human touch (see “SwarmTouch: Tactile Interaction of Human with Impedance Controlled Swarm of Nano-Quadrotors” (arXiv).
The Crazyflie’s low injury risk in the event of a collision, its predictable behavior, and its ability to carry sensing and communication payloads make it well-suited to user studies where physical proximity and spontaneous human response are important variables. The fact that the platform is widely available also matters: HRI research benefits from results that can be reproduced in different lab environments with different participant populations.
Looking across these five areas, a pattern emerges. In each case, the research is not about the Crazyflie itself. The platform is a means, not an end.
What the Crazyflie provides is a credible physical substrate that researchers can trust to behave consistently, modify freely, and replace cheaply when something goes wrong. The open source firmware means the dynamics are fully inspectable. The transparent hardware means the platform can be extended with custom decks. The stable software ecosystem means results from one year’s experiments can be compared against another year’s, and against results from other labs using the same platform.
If your research uses the Crazyflie in a direction not represented here, we’d like to hear about it. The research portal at bitcraze.io/portals/research lists some of what we know about, but the community is larger and more inventive than any curated list can capture.
