49 Crazyflie 2.1 Brushless lifting off their charging docks, flying formations, and landing back to recharge, all driven from a single Crazyradio 2.0. That’s what we have been flying lately, and it’s a great showcase of what the Crazyflie ecosystem can do with a big swarm.
If 49 Crazyflies sounds familiar, you might remember 49 Crazyflies, 1 Crazyradio, and cflib2. This time the formations are a lot more dynamic. They come from a collaboration with the Institute for Data Science in Mechanical Engineering (DSME) at RWTH Aachen University, and we recorded some videos we’re really happy with.
Where the formations come from
The choreographies were generated with SWAN, a pipeline developed at DSME that turns text promt into drone trajectories. In short:
A generative video model turns the prompt into a reference video.
A point tracker converts the motion in that video into trajectories for the swarm.
A planner assigns them to individual drones, and a safety filter makes sure they are collision-free.
What makes these formations fun for us is that they are not static shapes: they move in ways that would be hard to animate by hand. That also makes them a demanding test for the swarm.
Taking it to the real world
The generated SWAN trajectories are turned into splines and deployed on a dense swarm of 49 Crazyflie 2.1 Brushless, flying under the Lighthouse positioning system and lit up by bottom-mounted Color LED decks. We won’t go through the whole setup again (covered by the earlier post), but two parts of the Crazyflie ecosystem made this kind of work practical:
Built on cflib2. All communication with the swarm goes through cflib2 over a single Crazyradio 2.0. Before takeoff, we use cflib2 to upload each drone’s trajectory to its memory, and during the show, the High-Level Commander executes it onboard. While they are flying, we log every drone’s position every 50ms, giving us a record of how closely the swarm followed the choreography.
No battery swapping. Each Crazyflie takes off and lands on its charging dock. When you want to fly the swarm many times back to back, not having to handle 49 batteries makes a huge difference.
The result is a setup where any idea can go from the computer to a real swarm without having to build the infrastructure yourself.
The videos
Enough talking, here is what it looks like. The video below shows the formations we flew: a ballerina (49 drones), a karate fighter (29 drones), and a hand making an “I love you” (ILY) sign (49 drones).
Wrapping up
Flying 49 Crazyflies through dynamic formations, with one radio, full position logging and drones that recharge themselves between flights shows how far the Crazyflie ecosystem has come for large swarms.
A big thank you to Pascal Reinhold, Alexander Gräfe and Sebastian Trimpe at DSME for their awesome work, and an extra special thanks to Alexander, who coordinated the whole project during his internship with us at Bitcraze. If you want to learn more about SWAN, check out their paper, Generative AI for Safe and Photorealistic Drone Light Shows. And if you want to fly your own swarm, cflib2 is ready to try.
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.
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!
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.
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.
