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.
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.
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!
If you’ve ever gone looking for a more advanced, or use-case-specific Crazyflie example (something beyond the basic single-feature ones), you’ve probably ended up digging through the cflib and crazyflie-firmware example folders. That’s about to change.
We’ve created a new repository: crazyflie-demos. It’s a dedicated place where both us at Bitcraze and the broader community can host self-contained, well-described Crazyflie demos.
Why a new repository?
The examples in the core Bitcraze repositories were meant to be kept focused: demonstrating one feature, one API, or one subsystem at a time. But real demos tend to grow beyond that pretty quickly. Once you start combining positioning systems, swarming, custom firmware apps, external sensors, or other integrations, things stop fitting naturally into the firmware or library repos.
crazyflie-demos gives those larger, more practical examples a proper home, and finally provides a good answer to the question: “where should I put this cool thing I built?”
Why not just a folder of examples?
We want to avoid the fate of some older example collections that gradually turned into an unmaintained pile of half-working demos and missing context.
The goal with crazyflie-demos is that every demo should be properly documented and actually runnable. That means clear descriptions, listed dependencies, and enough context to understand what’s going on without digging through source code for an hour.
Another important part is reproducibility: each demo is self-contained and uses pinned dependencies, so an example you clone two years from now should still work.
What’s in there already?
The repository is organized by demo type:
scripts/cflib: Host-side Python scripts using crazyflie-lib-python, covering the full Crazyflie API.
scripts/rust: Rust demos using crazyflie-lib-rs, showcasing its high-performance and native async support.
scripts/cflib2: Early demos for our new Python library, crazyflie-lib-python-v2, built on top of the Rust library. cflib2 doesn’t have a release yet, but we’re already writing demos for it to test the API and the performance.
firmware: Out-of-tree firmware apps that are flashed directly to the Crazyflie. Each demo carries its own crazyflie-firmware submodule so you’re always building against the right version.
hybrid: Demos that combine onboard firmware with a host-side script working together.
A place to share your work
A big motivation behind crazyflie-demos is making it easier to share work with the community.
If you’ve built something useful, or just a fun experiment using our products, this is the place for it. Not everything needs to live in its own repository or branch. A well-described demo here makes it easier for others to find, understand, and build on your work, and most importantly, to get inspired by it.
We’ll also be using this repository as the go-to reference whenever people ask for more use-case-specific examples, so good demos here will naturally help more people discover what’s possible with the Crazyflie ecosystem.
It’s that time of year again! ICRA 2026 (IEEE International Conference on Robotics & Automation) is just around the corner, and this year we’re heading to Vienna. We couldn’t be more excited about this one: Vienna is an incredible city, and we’ve been working on some things we can’t wait to share.
June 1–5, 2026. Come find us!
A reproducible testbed for aerial robotics research
We will be running a live autonomous flight system based on the Crazyflie platform.
The focus is not the flight itself, but what it enables. The system provides a controlled indoor environment where experiments can be repeated, variables isolated, and results compared over time.
This is aligned with how aerial robotics research is actually conducted: iteration speed, reproducibility, and observability matter more than scale in early and mid-stage research. Our platform is designed around those constraints.
Autonomous indoor flight for controlled experimentation
The setup demonstrates autonomous flight under conditions that remain stable across runs.
This allows researchers to evaluate control strategies, perception pipelines, and multi-robot coordination without environmental noise dominating results. It also reduces costs and operational overhead compared to larger platforms, which changes how frequently experiments can be run.
In practice, this makes it feasible to move from idea to validated result faster and with clearer insight into failure modes.
Used in swarm robotics, control, and physical AI research
The Crazyflie platform is used across domains such as swarm robotics, learning-based control, SLAM, and human–robot interaction.
It has been referenced in hundreds of peer-reviewed publications and is often used as a bridge between simulation and larger systems. The value is not in representing the final deployment environment, but in enabling rigorous, comparable experimentation at low cost and risk.
If you are working in these areas, we are interested in how your setup is structured and where constraints appear.
Share your work with us
If you are presenting work that involves the Crazyflie, we would like to see it.
Even better, if you do not need your poster after your session, bring it by the booth! We collect and display these as part of the broader body of work built on the platform. We will make sure it is appreciated properly.
Meet us at ICRA 2026
One of our favourite things about ICRA is getting to meet the community in person, hearing about your research, seeing what you’ve built with the Crazyflie, and exchanging ideas with people who are just as excited about small flying robots as we are. Whether you want to chat about your research, see the demo up close, or just catch up, our booth is the place to be. We love hearing about all the cool projects you’re working on with the Crazyflie, so don’t be shy!
If you are working with the Crazyflie, evaluating platforms, or exploring new research directions, stop by booth 91. You can also reach out at contact@bitcraze.io to schedule time.
Bitcraze will exhibit at the European Robotics Forum 2026 March 23-27 in booth #90, where we will demonstrate a live, autonomous indoor flight setup based on the CrazyflieTM platform. The demonstration features multiple nano-drones flying autonomously in a controlled environment and reflects how the platform is used in research and applied robotics development.
Why Indoor Aaerial Testbeds Matter
The purpose of the demonstration is not the flight itself, but the role such setups play in validating aerial robotics concepts. Indoor, small-scale aerial systems allow researchers and R&D teams to study autonomy, perception, control, and multi-robot coordination under safe and repeatable conditions. This makes it possible to explore system behavior, test assumptions, and iterate rapidly before moving to larger platforms or less controlled environments.
Applicable in Both Academia and Industrial R&D
Bitcraze is used both in academic research and in industrial R&D contexts. In academia, the platform supports experimental work in areas such as swarm robotics, learning-based control, and human–robot interaction, and has been referenced in hundreds of peer-reviewed research papers worldwide. In industry, similar setups are increasingly used as testbeds to de-risk development by validating ideas indoors before scaling to outdoor testing, larger drones, or other robotic systems that require higher investment and operational complexity.
Hands-on Discussions at the Booth
At the booth, the live flight cage will be complemented by hands-on access to additional drones, expansion decks, and software tools. This allows for technical discussions around hardware architecture, sensing and positioning options, software stacks, and how different configurations support different research or development goals.
The Conversations We Are at ERF to Have
At ERF, Bitcraze is there to engage in conversations about platforms, testbeds, and how ambitious aerial robotics ideas can be validated in a financially responsible, safe, and controlled manner. This includes discussions with academic groups, industrial R&D teams, and project partners working across the research-to-application spectrum.
Looking forward to the discussions in Stavanger in booth #90!
Last week, Bitcraze attended the BETT Show in London to get a better sense of how the education landscape is evolving.
BETT (British Educational Technology Show) brings together educators, edtech companies, curriculum developers, policymakers, and technology providers across the full spectrum of learning: from primary school to higher education and professional training.
For us, it was a valuable opportunity to listen and get an understanding of where the general EDU landscape is and where it is heading.
Meeting Familiar Faces, and New Ones
One of the most rewarding parts of the visit was reconnecting with existing partners already using the CrazyflieTM in educational settings, and meeting new potential collaborators: teachers building robotics programs, universities modernising their lab infrastructure, and organisations developing national STEM (Science, Technology, Engineering, and Mathematics) and STEAM (Science, Technology, Engineering, Art, and Mathematics) initiatives.
A recurring theme in many conversations was the need for platforms that are robust and safe to use in classrooms, scale from simple programming exercises to advanced autonomy and AI, support both structured teaching and open-ended experimentation, and are well documented (both for the teacher and for the student).
These are exactly the problems we have spent more than a decade working on.
What the Education Robotics Market Looks Like Today
Speaking with a wide range of robotics vendors, software providers, and solution integrators gave us a clearer picture of the realities of the K-12 and STEM market:
Procurement is often tender-based and highly structured
Budgets are tight and price sensitivity is real
There are many vendors offering similar-looking robotics kits
Hardware is physically robust and classroom-proof and safety is critical
Programming is dominated by Python, Scratch, Blockly, or proprietary visual tools
“AI-enabled” frequently means GPT-style programming blocks layered on top
LEGO compatibility is everywhere
micro:bit has effectively become a compelling entry-level control board
Buyers apply hard scrutiny to educational value and learning outcomes
Real adoption requires curricula, lesson plans, and teacher training programs
And in practice, U.S.-developed curricula often transfer reasonably well globally
Why the Crazyflie is a Great Fit for Education
Although the Crazyflie originated as a research platform, its characteristics map naturally to education:
STEM / STEAM (Upper Secondary & High School)
Students can work hands-on with control systems, sensors, wireless communication, programming, and basic AI in a physical system they can see, debug, and iterate on. It makes abstract concepts tangible.
Undergraduate Education
Crazyflie is increasingly used in robotics, embedded systems, and mechatronics courses to teach estimation, control, perception, and multi-agent systems without the overhead of large and expensive hardware.
Post-graduate Research
This remains our strongest domain: swarm robotics, learning-based control, human–robot interaction, indoor navigation, and distributed systems.
The continuity matters. Students don’t outgrow the platform. They grow with it. And, more importantly, the same openness that researchers value is increasingly relevant in education as well (particularly relevant in the light of recent geopolitical movements). Institutions want transparency, long-term maintainability, and the freedom to adapt tools to their pedagogy and not just consume closed kits.
Education is a Strategic Part of the Robotics Ecosystem
BETT confirmed that education is a strategic and structured part of the robotics ecosystem. Not just as “learning about robots”, but as a way to train future engineers, researchers, and system designers using realistic platforms from an early age.
Succeeding in this segment requires more than good hardware. It requires thoughtful packaging, clear educational positioning, proper teaching material, partner ecosystems, and long-term commitment.
To those we met at BETT, thank you for the conversations. And if you are working with STEM, STEAM, or robotics education and are curious about the Crazyflie, we are always happy to talk.
Today, we welcome our first blog post by Maurice Zemp. Stay tuned for more of his adventures later!
When I started working on my Matura thesis (a mandatory project in Swiss High School), I wanted to create something that went beyond a purely theoretical project. I was fascinated by the idea of combining cutting-edge technology with a very tangible and exciting challenge: making a small drone fly through a racing course, composed by small gates, completely on its own and as fast as possible. Inspired by the work under Prof. Davide Scaramuzza, I set off for a challenge to find some new alternatives or improvements, while developping my approach from scratch.
What may sound simple at first quickly turns into a highly complex task. A drone needs to perceive its environment, process information in real time, and decide on precise actions within fractions of a second, all without human intervention. Professional drone racing pilots train for years to master this level of control. My goal was to see whether artificial intelligence could achieve something similar, using reinforcement learning as the core technique.
But there was another challenge: I wanted to design a system that wasn’t only powerful, but also affordable and reproducible. Many research institutions use equipment worth tens of thousands of francs for projects like these. I asked myself: Could I build something comparable with a fraction of the budget, and still push the boundaries of what’s possible?
That question became the driving force behind my project, which later brought me all the way to the finals of Schweizer Jugend forscht (short SJf) and saved me a place as the main prize to represent Switzerland at the world’s biggest Youth Science Competition, ISEF 2026. Over the following sections, I’ll share how I built my system step by step, what it was like to present it at the competition, and how it felt when all the effort finally paid off.
Fig. 1: Me with the Crazyflie 2.1 Brushless in the halls of ETH Zurich, where the main event of SJf took place.
Motivation and Objectives
The project I presented at Schweizer Jugend forscht was the result of my Matura thesis, in which I set out to combine my interests in drones, programming, and artificial intelligence. My goal was to develop a complete system for autonomous drone racing, based on Reinforcement Learning (RL), that would not only work in simulation but could also be transferred to real-world conditions.
To achieve this, I focused on three key aspects:
Building a highly efficient simulation environment for training a reinforcement learning agent.
Developing a cost-effective motion-capture system (MoCap) capable of tracking a drone’s position and orientation in real time with high precision.
Integrating both systems in a way that would allow seamless transfer from simulation to real-world experiments with minimal latency.
This combination made the project unique: instead of relying on expensive commercial hardware, I set out to create a solution that would be precise and affordable but still continue the state-of-the-art development in Drone Racing.
Simulation Environment
The simulation was implemented in Python, using Stable Baselines, OpenAI Gymnasium, and NumPy, accelerated with Numba for performance. At its core, the system employed the Proximal Policy Optimization (PPO) algorithm, a state-of-the-art reinforcement learning algorithm known for stability and efficiency.
Unlike general-purpose simulators such as Gazebo, my environment was designed specifically for drone racing. It could process tens of thousands of interactions per second, enabling a training run of a few dozen minutes to correspond to nearly a year of simulated flight time.
Key features included:
A physics-based flight dynamics model accounting for thrust, drag and gyroscopic effects.
A carefully engineered reward function balancing speed, precision and avoiding shortcuts.
A flexible design that allowed different gate sequences and drone parameters to be tested.
A multi-agent environment computing on multiple threads, leading to much shorter training time needed.
Fig. 2: Path of the drone after two hours of training on a given track
With this setup, an RL agent could learn to complete arbitrary racing tracks in near-optimal time1 after only a few hours of training. In simulation, top speeds of up to 100 km/h were achieved, though these exceeded the physical limits of the real drone and were generated with modified drone parameters.
Motion-Capture-System
A second cornerstone of the project was the development of a low-cost motion-capture system. Instead of relying on high-end solutions such as VICON or OptiTrack (which can cost tens of thousands of Swiss francs), I built a custom setup. The drone – a Crazyflie 2.1 Nanocopter (later a Crazyflie 2.1 Brushless) – was fitted with infrared diodes. With four cameras capturing at 120 frames per second, the drone’s position was calculated in real time through triangulation. By using three diodes arranged on the drone, I not only wanted to estimate the position but also the orientation. Unfortunately, due to the cameras being budget and thus not having a high-end resolution, the estimation of the orientation was not feasible and was therefore taken from the onboard IMU.
Fig. 3: Motion-Capture-System Concept
System Integration
For integration, I relied on the ROS2 middleware and the Crazyswarm2 framework, which allowed the simulation and MoCap data to be processed together with minimal latency. This setup ensured that a policy trained in simulation could be executed on the real drone almost seamlessly.
Fig. 4: Sim2Real Integration Concept
Results & Discussion
The results demonstrated the effectiveness of the combined system:
In simulation, the RL agent completed tracks in nearly optimal time1, demonstrating robust generalization across different gate sequences.
The motion-capture system delivered millimeter-level accuracy and reliable tracking in real time despite its simplicity. (see Fig. 5)
In real-world tests, the Crazyflie drone successfully completed tight gate sequences, even at speeds of up to 25 km/h, with a positional deviation of only 5–12 cm compared to the simulated trajectories. (see Fig. 6)
Given that the gates were roughly A3-sized openings (38 × 29 cm), the precision was sufficient to consistently hit every gate, confirming the feasibility of transferring simulated training into real-world racing. (Video)
Fig. 5: Boxplot of the deviation for collected points on a plane in millimeters
Fig. 6: Tracked Real Life Path on a given trackFig. 7: Realisation in my school’s physics laboratory
The system demonstrated that RL-based controllers can generalize effectively from simulation to reality, even with imperfect models. This robustness shows that RL is promising for real-world robotics applications where exact physical modeling is difficult or costly. To further investigate this robustness, I conducted ablation studies in simulation focusing on aerodynamic drag, as well as analyses of the MoCap system’s accuracy in measuring dynamic motion.
As for the aerodynamic drag, I introduced some randomness during evaluation, which deviated largely from what the Algorithm had trained upon. To achieve this, I introduced a parameter k which was multiplied with the correct aerodynamic drag to view how these differences would impact the flight. In Fig. 8 you can see the deviation from the real path over the course of a flight. As obviously more drag results in lower velocities, the two paths had to be fitted using the nearest two possible points. The results are impressive, even with an enormous change to training such as k = 10 the flight still performed somewhat okay, even though the gates probably wouldn’t have been hit anymore.
For the MoCap System, I used a mathematically representable motion, such as a pendulum. Then I performed a parameter optimization on this mathematical model and measured the deviation based on the current speed. There is a clear correlation between speed and deviation (see Fig. 9), which most likely was caused by the missing calibration of the cameras.
Fig. 8: Results of ablation studies on aerodynamic dragFig. 9: Experiment to confirm correlation between deviation and speed
Conclusion and Reflection
This work demonstrates that RL, combined with accessible hardware, enables precise and robust autonomous flight in dynamic indoor environments. The results underscore the potential of low- cost robotics solutions to democratize drone research. Even though it was a large project and there were some hard times, I enjoyed working on it a lot and believe that the result and the memories made with it are even more rewarding than any prize money!
Acknowledgments
To end this guest post, I want to sincerely thank Bitcraze for their amazing work and support during the development of this project. They have genuinely built such an incredible testbed for research in autonomous drones, it’s amazing! Without them, this project wouldn’t have worked out the way it did!
Near-optimal time here references to the theoretical boundary of a drone completing this track, given it’s parameters. To be clear, this is not fitting a polynomial with boundaries on their derivatives onto gate segments, as it was done during earlier approches in the 2010s. It was compared to multiple previous approches by UZH RPG such as Optimal Control (OC). Nevertheless, this comparison could be done more extensively in the future, as time ran short in the end. ↩︎
FOSDEM is one of the largest open source conferences in Europe, happening every year in Brussels. It’s a special place where developers, researchers, and enthusiasts come together to share ideas, showcase projects, and explore the latest in open-source technology. Over the years, we at Bitcraze have been regular attendees, enjoying the chance to meet fellow open-source fans and see what’s happening across the community.
Last year, we decided to take a bigger step and helped organize a developer room. Devrooms are like mini-conferences: they are handled by a committee that produces a call for participation and handles the schedule for the room. FOSDEM allocates a time slot, a physical room, and video recording for the devroom so that all talks are broadcasted in real-time and recorded. Before, the conference lacked a dedicated devroom for robotics, which is a shame as a lot of robotics, at least in research, are open source, thanks in large part to ROS. That’s why we’re devoted on helping out organizing a devroom focused on robotics and simulation. Being part of the developer room gives us the chance not only to attend talks but also to contribute to the schedule, help coordinate speakers, and support discussions among attendees.
The developer room is packed with exciting content for anyone interested in robotics, swarming, simulation, and more. There are presentations on new tools and libraries, discussions about open-source projects pushing the boundaries of what small robots can do. Last year, talks ranged from advanced motion planning and multi-robot coordination to hands-on experiments with drones and embedded systems. For 2026, the schedule promises even more fascinating sessions, highlighting the latest developments in robotics software and hardware, and providing a space to exchange ideas with people working on similar challenges.
Whether you’re interested in ROS, sensor fusion, or just curious about what researchers and makers are building, the developer room is a great place to meet like-minded people and get inspired. We’ve found it to be an incredible platform for sharing knowledge, discovering new tools, and seeing how open-source contributions can accelerate innovation.
This is happening on Saturday 31st of January, from 10.30 to 18.30, in room UB2.147. You can check out the full FOSDEM 2026 Robotics and Simulation schedule here: FOSDEM 2026 schedule
We’re really looking forward to being part of the developer room again this year, and we hope to see some of you there. If you’ll be at FOSDEM, come by, say hi, and share what you’ve been working on — we can’t wait to see the amazing projects the community will bring this year!
