It’s been a while since our last update on what started as the High powered LED deck prototype. We have finally had time to push this project forward and are aiming to have a release at the beginning of 2026.
A New Name and a Familiar Design
You might notice that the deck has a new name, something simpler and a bit catchier, the Color LED deck. The overall design and specs, however, remain very similar to the original concept:
Using a highly efficient high powered LED for maximum brightness
DC/DC driving circuitry for improved efficiency and consistent performance
A light diffuser for smooth, even illumination and wide visibility
Two versions, top or bottom, depending on your build
The Color LED Deck brings fully programmable lighting to your Crazyflie, allowing you to create and control custom light patterns in real time. It’s useful for flying in darker environments, for visual tracking experiments, or for adding synchronized light effects in drone choreography. The deck is now also compatible with the Crazyflie 2.1 Brushless, bringing dynamic lighting to our most recent platform for the first time.
Software architecture
This deck will also be the first to use the new DeckCtrl architecture. If you’re curious about how that works, you can read more about it in this earlier blog post.
The Color LED deck has some intelligence built into it that runs on a STM32C0 MCU. The open-source firmware is still under development, and the repository can be found here.
Availability
The final pricing is still being determined, but make sure to sign up for the in-stock notification at the Color LED deck store page to get an update as soon as it’s available. And as always, keep an eye on the blog for more updates as we get closer to release.
When flying the Crazyflie Brushless, you may have noticed something familiar, as the battery drains, the drone becomes less responsive and can not generate the same amount of thrust it had at the start of the flight. This is because as the state of charge drops, the battery voltage decreases, and that directly affects the thrust output of the motors.
We wanted to fix this. In this post, we’ll explain why the old compensation method wasn’t ideal, how we used system identification to design a new battery compensation scheme, and how this improves thrust consistency across the entire battery range.
Motivation
The key problem is simple: a dropping battery voltage means a dropping thrust for the same command. This leads to flights that start crisp and responsive but is reduced as the battery drain.
Our goal was to make sure that, regardless of the state of charge, the actual thrust stays close to the commanded thrust. Though, for manual flight, sometimes this might not be preferred, so there will be an option to turn it off.
To illustrate the setup, here is a schematic of how the battery, PWM switching, and motor interact, effectively behaving like a simple buck converter:
This means the motor voltage can be computed by:
System Identification
To design a proper compensation, we first needed to understand how thrust relates to motor voltage. This meant running a series of experiments on the thrust stand introduced in this earlier blog post.
The first step was calibrating the loadcell used to measure thrust:
Once calibrated, we measured the thrust at different applied motor voltages.
As expected, the thrust can be modeled well by a third-order polynomial in motor voltage.
Mathematically, the relationship comes from two simple facts:
A DC motor torque is proportional to motor voltage and inversely related to motor speed.
A propeller’s thrust scales approximately with the square of the rotational speed.
Combining these effects leads to a nonlinear (third-order) relation between motor voltage and thrust.
Battery Compensation
The main idea is straightforward: instead of assuming the battery voltage is constant, we explicitly account for it. We can measure the battery voltage and low-pass filter it to reduce noise. Together with the necessary motor voltage from the curve above, we can solve the equation from above for the necessary pwm to apply:
This corrected motor voltage is then fed into our third-order model to compensate the thrust command. With this compensation, the commanded-to-actual thrust relation is now approximately linear, which is exactly what we want. We can verify this by applying thrust commands and comparing them to the actual thrust.
Dynamic Behavior
To obtain a complete parameter set of the motors and propellers, we also performed dynamic tests: commanding rapid increases and decreases in PWM and measuring the thrust response.
These dynamics are not required for the battery compensation itself, but they are very useful for accurate system identification and for simulation purposes.
Discussion and Conclusion
The new compensation method (#PR1526), ensures that thrust is consistent across the full range of battery charge. Compared to the old approach, it is both simpler to understand and more faithful to the actual physics of the motor–propeller system. The result is flights that feel the same at the end of the battery as at the beginning.
Beyond just improving flight performance, the system identification work also provides us with a full parameter set for the Crazyflie. We are already using these parameters in Crazyflow, our new simulation tool that models the Crazyflie dynamics with high fidelity. If you’re interested in simulation or in testing new control strategies virtually, check it out!
We’re excited to hear feedback from the community and to see what you do with this new capability.
We’re happy to announce that release 2025.09 is now available. This update includes Python 3.13 support and improved battery voltage compensation, along with enhanced trajectory control capabilities. The release also features substantial stability and architectural work that lays the groundwork for upcoming features and products. Thanks to our community contributors for their valuable additions to this release.
Major changes
Python 3.13 support Added support for Python 3.13, with preparations already in place to ensure faster compatibility when Python 3.14 releases.
Improved battery voltage compensation Enhanced voltage compensation for Crazyflie 2.1, 2.1+, and 2.1 with thrust upgrade kit provides more consistent flight performance across battery discharge cycles. Crazyflie Brushless battery voltage compensation coming soon. Thanks to @Rather1337 for this contribution.
Manual flight setpoint packet New generic commander packet type for manual flight that allows dynamic switching between Angle and Rate modes for roll and pitch without re-flashing the firmware.
Fully relative trajectories Trajectories can now be initiated relative to the drone’s current yaw, not just position. This enables fully relative trajectory execution where subsequent trajectories maintain the drone’s current orientation. Thanks to @johnnwallace for this contribution.
Modular deck discovery architecture Replaced OneWire-only deck discovery with a modular backend system that supports multiple discovery protocols. This enables future deck communication methods while maintaining full backward compatibility with existing decks.
We built a strong contender in the world of indoor micro drones, and it’s pushing the boundaries of what’s possible in the lab, lecture hall, and research workshop. We are talking about the Crazyflie 2.1 Brushless and it has proven to be a leap in capability, endurance, and potential, compared to the Crazyflie 2.1+. And, it’s all designed for indoor environments where precision, safety, adaptability, and repeatability matter most.
Engineering Advances that Matter
The Crazyflie 2.1 Brushless expands the indoor experimentation capabilities, letting researchers fly longer, push for more complex missions, and iterate faster.
The most striking evolution is the switch from brushed to brushless motors, which becomes a real enabler for serious indoor flight:
Robust onboard electronics and compatibility with the full Crazyflie 2.X expansion ecosystem (except the LED ring), which means every sensor, radio, and positioning deck you’ve built will just work out of the box.
10-minute flight time on the stock 350mAh battery, compared to the old ~7 minutes of the Crazyflie 2.1+.
Max payload of 40g, more than doubling the prior recommended limit and opening the door to advanced sensors and heavier expansion decks.
Quieter and more reliable flight, thanks to lower RPM propellers optimized for a stealthier, stable operation in confined spaces.
Real Research: Indoor Applications
The Crazyflie platform is already a staple in academic circles, and “The Brushless” amps things even further:
Swarm Robotics Indoors: Multiple universities coordinate Crazyflie swarms inside test arenas, labs, and lecture halls for research into distributed control, real-time collision avoidance, and modular asset tracking.
Precise Indoor Positioning: With decks for Lighthouse or Loco positioning, research groups achieve centimeter-level indoor path planning and formation control. This is vital for AI benchmarking where GPS access isn’t possible.
Autonomous Sensing: The payload bump means researchers could run in-situ experiments with real environmental sensors like gas monitors, radiation detectors, or tiny RFID readers, all indoors, for smart buildings and logistics.
Gesture and Object Tracking: Computer vision decks enable interactive robotics projects, allowing drones to follow hand gestures, track moving people, or scan QR codes throughout an office or lab.
Key Specs (For the Tinkerers)
Spec
Crazyflie 2.1 Brushless
Crazyflie 2.1+
Motor Type
Brushless 08028-10000KV (30g thrust)
Brushed
Flight Time
10 min
~7 min
Max Payload
40g
15g
Weight
32-37g (w/ guards/legs)
29g
Open Source Ecosystem
Yes
Yes
The Crazyflie 2.1 Brushless as an Enabler
The Crazyflie 2.1 Brushless has proven itself as an enabler for rapid experimentation, reproducible robotics, and ambitious research, where safety, precision, and repeatability matter. Its robust platform, expanded payload, and enhanced flight time make it a micro drone of choice for anyone building the next wave of intelligent swarms, real-time path planners, or AI-integrated automation systems in contained spaces.
What will the next breakthrough look like? This drone lets the imagination take flight.
Unmanned aerial vehicles (UAV) are invaluable to challenging remote applications, including coastal monitoring, surveillance for safe passage in icy waterways, and search-and-rescue missions. However, after deployment in a remote setting, the functional life of the multirotor is ultimately limited by its battery life. The research we continue to investigate is the ability to cooperatively and autonomously land a multirotor on an uncrewed surface vessel (USV) for recharging. We address this problem in real time with safe control algorithms that we apply on a Crazyflie.
Approach
Our approach enables the Crazyflie to cooperatively coordinate, with a simulated USV, a safe landing in severe wave conditions. It is critical to the autonomy of the system that the agents do not know when or where they’re going to land at the outset, they are cooperating in real time to make these determinations. The novelty of this work is three primary contributions:
Learning a Spatial-Temporal Wave Model as a Gaussian Process
We first learn the local tilt model, representative of the spatial and temporal impact of waves on the tilt angle of a USV, using Gaussian Process (GP) regression. Prior to the execution of the landing, the USV collects Nd noisy observations D = {q, t, φ²}, where q is the position of the USV, t is time, and φ is the tilt angle of the USV. We use GP regression to learn the spatial-temporal tilt model: fw(q, t) = (φ(q, t))² . The predicted tilt and uncertainty, conditioned on the observed data D, at a query point a = [q, t] can be inferred using the posterior distribution.
Distributed Model Predictive Control
Our proposed model predictive control (MPC) architecture combines standard tracking MPCs for the Crazyflie and USV and augments them with additional artificial goal locations. These artificial goals enable the vehicles to coordinate without prior guidance. Each vehicle solves an individual optimization problem for both the artificial goal and an input that tracks it but only communicates the former to the other vehicle. The MPC integrates, into the cost functions for both vehicles, the learned mean and uncertainty quantification of the spatial-temporal wave model from the GP regression. This encourages the agents to converge to calmer waters enabling safer landings in variable wave conditions.
Low-Cost USV Simulation Testbed Platform
To validate the proposed MPC scheme for landing on a USV, we simulate the spatial-temporal motion of a USV in waves of variable intensity using a custom tilting platform. The custom tilting platform has two degrees of freedom (roll, pitch) and is affixed to the deck of a differential-drive unmanned ground vehicle (UGV), the ClearPath Robotics Husky. We selected a differential-drive UGV to replicate the motion of a broad range of USVs, including those with differential drive and conventional rudder steering. Our platform is low-cost, modular, and open source, enabling rapid testing and benchmarking of UAV-USV landing strategies indoors before going onto the water which is high-risk and expensive.
Block diagram of our proposed distributed model predictive control scheme.
Overview of the USV simulation testbed tilting platform for ground vehicles. Left: the platform is shown mounted on the deck of the ClearPath Robotics Husky with the Crazyflie 2.1 hovering above. Center: a closer view of the landing pad configuration and platform components. Right: Section view showing the ball-and-socket joint and the linkage mechanism.
Experimental Setup
Full system architecture.
We evaluate the proposed MPC scheme for UAV-USV cooperative landing in indoor experiments using the Crazyflie 2.1 and our tilting platform. These experiments represent a scaled-down version of real-world harsh wave conditions. Amplitude and frequency are informed by a survey of waves along the coastlines of the Great Lakes of North America. We select a spatially decaying sine wave whose amplitude decreases gradually with increasing x-position. We expect the Crazyflie and the simulated USV to cooperatively select the safest landing spatially and temporally by learning the GP and incorporating it the MPC scheme.
The UAV MPC is run off-board on a Thinkpad X1 Carbon with Intel Core i7-1270P Processor. The MPC runs at a frequency of 50Hz and transmits control inputs to the Crazyflie via long range Crazyradio USB. The Raspberry Pi onboard the Husky runs its MPC at 10Hz. The two vehicles communicate their goals using ROS topics on a local WiFi network and receive their own pose feedback at 240 Hz from a VICON motion capture system.
Experimental Results
Experiment 1. We define the tilt model. Our proposed distributed MPC scheme can locate a low-tilt landing location from all six initial platform positions.
Experiment 2. We learn the wave model using a GP. The MPC scheme can locate a low-tilt landing location from all three initial platform positions.
In the first set of experiments, we assume no uncertainty in the tilt model. We compare four MPC weighting strategies ranging from a purely cooperative strategy in red (where neither vehicle weights wave tilt in the MPC, neglecting spatial-temporal tilt motion), to our proposed strategy in blue (where both vehicles weight wave tilt highly in the MPC). In this set of experiments, our proposed approach (blue) reduces the tilt angle of the platform at landing by between 68-89% and results in a 53% increase in landing success rate over the purely cooperative strategy (red).
In the second set of experiments, we learn the wave tilt model as a GP. We compare the purely cooperative strategy in red from before to our proposed strategy in blue where we weight the posterior mean cost from the GP regression. In this set of experiments, our proposed approach (blue) reduces tilt angle of the platform at landing by 23-32% and results in a 47% increase in the landing success rate over pure cooperation (red).
Future Work
In the work presented above we assume that there is a local region with calm waves that can be reached by both vehicles to then perform a safe landing. However, in practical scenarios, spatial-temporal assumptions are not realistic if an emergency landing is necessary or if time and resources are constrained. Recently, we explored quadratic MPC strategies for landing a Crazyflie on the tilting platform in high frequency high amplitude conditions. In these strategies we include optimization costs that weigh position, attitude, and altitude errors between the multirotor and the platform.
Though all strategies successfully land in low-frequency, low-amplitude conditions, they have low success in the higher-amplitude conditions. Therefore, designing a safe controller that is robust to a wide range of wave amplitudes and frequencies is an ongoing research area.
Poster presented at the workshop ’25 Years of Aerial Robotics: Challenges and Opportunities’ at ICRA 2025.
Debugging the Crazyflie using the debug-adapter kit gives you direct access to the STM32 with a hardware debugger. It makes it possible to pause execution, step through code, and inspect what’s happening in real time.
Even if you’re working mostly at a higher level, having this kind of visibility can be a huge time-saver when something unexpected happens. It’s a tool I use frequently when tracking down firmware issues or verifying low-level behavior.
We already have documentation for debugging the STM32 on the Crazyflie using ST-LINK and VS Code, but there are still a few missing pieces; like how to use J-Link, how to debug other platforms (like the Crazyflie 2.1 Brushless), and how enabling debug builds can help.
Debug Build
If you’re debugging and your breakpoints aren’t landing where you expect, or stepping seems unpredictable, or variables aren’t visible, it’s probably because the firmware was built with compiler optimizations enabled. When you select a debug build, the build system disables optimization by setting the compiler flag -O0, which preserves line-by-line correspondence between source code and machine instructions. This makes stepping and inspecting variables much more reliable.
To enable a debug build, you need to set the CONFIG_DEBUG option in your Kconfig configuration. You can do this, for example, by running make menuconfig in a terminal. Then navigate to Build and debug options and select Enable debug build. After changing Kconfig options, re-run make to rebuild the firmware with the new configuration.
Enabling debug build Kconfig option through menuconfig
VS Code Debug Configuration
With debug builds enabled, you’ll get more predictable stepping and reliable breakpoints. The next step is setting up your debugger. Below is a launch.json configuration for VS Code that supports both ST-Link and J-Link, and works with Crazyflie 2.x and the 2.1 Brushless.
To use this setup with a different platform, like the Flapper, just change the executable field to point to the correct .elf file. By default, starting a debug session in VS Code will erase and reflash the firmware, so make sure the firmware is built beforehand. If you need to attach to a running target without flashing, you’ll need to modify the launch.json to skip loading the binary.
A couple of weeks ago, we were at ICRA 2025 in Atlanta. This year’s ICRA drew over 7,000 attendees, making it the biggest edition yet. We had a booth at the exhibition where we showed our decentralized swarm demo. The setup included a mix of Crazyflie 2.1+ units with Qi charging decks and Crazyflie 2.1 Brushless platforms with our new charging dock. The entire swarm operated onboard, with two Lighthouse base stations for positioning. More details about the setup can be found in the recent swarm demo blog post.
8 Crazyflies flying simultaneously in our decentralized swarm at ICRA 2025
Some of the brushless drones carried our high-powered LED deck prototype to make the swarm more visible and engaging. One of the drones also had a prototype camera streaming deck, which held up well despite the busy wireless environment.
A Different Perspective
This year we were also invited to participate in a workshop: 25 Years of Aerial Robotics: Challenges and Opportunities, where I (Rik) gave a short presentation about the evolution of positioning in the Crazyflie, from webcam-based AruCo marker tracking to the systems we use today.
Usually, we spend most of our time on the exhibition floor, so being part of a workshop like this was a different experience. It was interesting to hear researchers mention the Crazyflie in their work without needing to explain what it is. That kind of familiarity isn’t something we take for granted, and it was nice to see.
Many thanks to all the participants of the workshop '25 Years Of Aerial Robotics: Challenges And Opportunities' that we had the pleasure to co-organise for #ICRA2025. The speakers, young researchers, chairpersons and, of course, the attendees all made it a unique experience🦾 pic.twitter.com/WNfUUYLtop
The workshop also gave us a chance to talk with both established researchers and newer faces in the field. What stood out most was hearing how people are using the Crazyflie in their work today. It’s very rewarding to see how what we do at the office connects with and supports real research.
Catching Up and Looking Around
One of the most rewarding parts of the conference was the chance to connect directly with people using the platform. We talked to many users, both current and past, and saw new research based on the platform. It was also great to reconnect with Flapper Drones, who build flapping-wing vehicles powered by the Crazyflie Bolt. And it was nice to see HopTo on the exhibition floor for the first time. The company is a spin-off from the Robotics and Intelligent Systems Lab at CityU Hong Kong, which published a Science Robotics paper on the hopcopter concept that used a Crazyflie. We also had the chance to catch up with a maintainer of CrazySim, an open-source simulator in the Crazyflie ecosystem. It’s always valuable to connect with people building on top of the platform, whether through research, hardware, or open-source tools.
Wrapping Up
ICRA 2025 was packed with activity. From demoing the swarm, to the workshop, to hallway conversations, it gave us a lot of valuable feedback and insight. Thanks to everyone who stopped by, joined a talk, or came to say hello.
As we mentioned in a previous blog post, the last couple of weeks have been full of exciting events in the US. We first began our adventure in Charlotte, North Carolina, where we attended the International Conference on Unmanned Aircraft Systems (ICUAS), as platinum sponsors.
We were especially thrilled to be involved because the final stage of the conference’s competition featured Crazyflies, which played a central role in the challenge.
The ICUAS UAV Competition
This year’s competition simulated a search mission in an urban environment. The goal was for teams to identify ArUco markers placed on multiple obstacles, while maintaining line-of-sight and communication among a swarm of three Crazyflies.
Each team’s UAVs launched from a designated base, navigated a known environment, and attempted to locate several targets. The drones relied on an OptiTrack system for positioning and used the AI deck as a camera for image recognition. Constant communication between the base and all UAVs was required throughout the mission.
The event, organized by the LARICS team, combined both simulation and real-world implementation. Their hard work ensured that competitors could smoothly transition their systems from digital models to actual flying drones. What followed was an intense and fun two-day hackathon.
Although the ICUAS UAV Competition drew interest from 26 teams globally, only five finalist teams made it to Charlotte to run their scenarios with real drones. In the end, it was Team Aerial Robotics from the Indian Institute of Technology Kanpur (IITK) who took home first place—congratulations to them!
While the event went smoothly overall, some communication challenges cropped up—solved creatively by placing a radio in the center of the arena. Battery management was also key, with fully charged packs being a hot commodity to maximize flight time.
Research and Presentations
Alongside the competition, the conference featured a wide range of research presentations. We were proud to see Rik present on the AI deck during a workshop focused on embodied AI.
One of the highlights was the Best Paper Award, which—although we missed the talk, was awarded to a team from Queen’s university using the Crazyflie to simulate drone landings on ocean waves. You can read their fascinating paper here: https://arxiv.org/abs/2410.21674
Final Thoughts
Overall, ICUAS 2025 was a great experience—full of innovation, collaboration, and of course, plenty of flight time. We’re grateful to the organizers, competitors, and everyone who stopped by our booth. Until next time!
We’re happy to announce that release 2025.02 is now available. This update includes fixes and improvements for the Crazyflie 2.1 Brushless, along with stability enhancements for the AI-deck.
It’s hard to believe it’s already been almost a month since the Crazyflie 2.1 Brushless was released. We know some of you have already had the chance to take it for a spin, and we’re really excited to hear what you think.
Here at the office, we have started using them a lot – to discover gaps in the documentation, to test our new features, or simply to make nice trajectories during a Fun Friday as shown here:
We’re constantly amazed by it and the new capacity it brings… But, interestingly, we haven’t received many support questions so far… which has us wondering—did we accidentally make it too good? Jokes aside, we’d love to get your thoughts! Whether you have feedback, questions, or just want to share your experience, we’re all ears.
We have a quick form for you here to fill out – it takes a couple of minutes and would help us a lot: