The Color LED deck

2025-10-27 | Tobias | Leave a comment

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.

Keeping Thrust Consistent as the Battery Drains

2025-10-20 | Marcel Rath | Leave a comment

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.

New co-worker at Bitcraze: Hampus!

2025-10-13 | Enya Nilsson | Leave a comment

Bitcraze is on an exciting journey on many levels and one of them is expanding the team. In the middle of September, I started at Bitcraze. My name is Hampus, I am 33 years old and I will have a role as administrator. I live in central Malmö together with my wife Hannah and my 4 year old kid, Sigge.

After a few weeks at Bitcraze I am 100% confident I made the right choice. The company might be small, but it’s full of fun and interesting people. Everyone is helpful and share an awesome enthusiasm for the company.

My role as administrator will include many tasks. But to summarize, I will “steal” responsibilities from my colleagues, for example bookkeeping and other financial tasks, so that they can focus more on the development of the Bitcraze products.

I really enjoy administration and diving into Excel-sheets. This is not always the case for colleagues, so hopefully this means that it will be a good match between me and the rest of the company.

Besides Bitcraze, I am playing professional handball in HK Malmö at the top the Swedish division. My ambition is that my my experiences from many years of playing a team sport will help in the development of Bitcraze. I will split my time between Bitcraze and HK Malmö 50/50.

New DeckCtrl architecture: The Future of Deck Enumeration

2025-10-06 | Arnaud | Leave a comment

One of the unique characteristic of the Crazyflie platform is the fact that decks (the Crazyflie expansion boards) are detected dynamically at startup. This makes the platform pretty much plug and play: plug a flow deck and you can fly autonomously with relative positioning, no configuration or recompilation required.

In this blog post we will present a new system we have implemented to identify and enumerate decks. This is intended to be the new default from now-on and can be used by anyone who wants to make a Crazyflie-compatible deck.

Current system: 1-Wire Memories

This is currently achieved using 1-Wire Memories. These memories can be discovered and addressed using a guaranteed unique serial number. This means that there can be as many memories as we want on the bus and they can all be discovered and read.

In the Crazyflie ecosystem, every deck has a 1-Wire memory that contains the identity of the deck. At startup, the Crazyflie discover and read all the memories which allows to discover all the decks and initialize the corresponding deck driver.

The future: DeckCtrl

The current system works very well but is has two major shortcommings:

The 1-Wire memory we are using does not provides GPIO or any other control. It makes it impossible to control the deck “out-of-band” in order to switch it on/off or launch a bootloader for example.
The 1-Wire memory has only one manufacturer and, because of a lot of reasons, we can only use a single model of it. At times it has caused us stress when the chip availability is low.

The new DeckCtrl-based system addresses these two problems by using a regular micro controller over I2C and provides support for GPIO as well as, in the future, UART, SPI and any other protocol that might be needed to handle the deck startup and configuration.

DeckCtrl is mainly a protocol definition. The current implementation is for STM32C011 micro controllers. While this could be implemented on any micro controllers, we will likely stick to the STM32C011 for the foreseeable future.

Deck discovery over I2C

One of the main innovations is the development of a new discovery and enumeration algorithm over I2C. Indeed, one of the main difference between I2C and 1-Wire is that 1-Wire memories are addressed using a 64Bit unique serial number while I2C uses 7 (or 10) bit addresses. This means that it is impractical to assign a unique I2C address to each device, and even if we tried to assign one address per deck type it would make it impossible to detect the same deck multiple times on a Crazyflie.

To solve that problem we designed a protocol that allows starting all DeckCtrl on the same address and enumerate them so that we can select all of them one by one, and then assign them a unique address on the bus. At a high-level this behaves very similarly to DHCP, where all devices will be assigned an address dynamically.

Once the decks have all been configured, it is possible read a memory to recover the deck identity and initialize deck drivers as we are currently doing.

Just that is a great step forward for Bitcraze: we are not dependent anymore to a single model of 1-Wire memory.

Deck life-cycle control

The second major improvement is what I called earlier “out-of-band” control of the deck. By that I mean that we can have control over the deck that is independent from the deck’s main micro controller chip. This is something we have long missed to, for example, be able to put decks in bootloader mode. The solution that has been used for the lighthouse deck is to always start in bootloader mode and then boot. This works, but has proven to be impractical for some use-cases and is not possible with all micro controllers.

The new DeckCtrl protocol defines space for GPIO control and the possibility for more in the future. This allows for example to switch ON and OFF a deck in software if one of the GPIO is used to control the deck power supply. We can also control the Reset and Boot pin of a micro controller in order to put it in bootloader mode.

Our goal there is to greatly simplify the design of more clever decks based on micro controllers. This will allow us, and anyone interested in making decks, to make more competent decks while making is easy to develop the firmware for them. For example, we will be looking at allowing to reprogram decks without having to restart the Crazyflie, which will make it much easier to develop and iterate.

Status

We have now finished the first iteration of the DeckCtrl protocol design and implementation. There is also a driver that exercises the GPIO part of it, this has been tested to work on many identical decks at the same time on a dev-deck we use for development:

This has been done in the context of the High-Power LED deck project. This future deck will feature a powerful RGBW LED which will be controlled by a micro controller onboard the deck. So it will be seen as an I2C device from the Crazyflie side. This design also shows the intent of DeckCtrl as this deck has 2 STM32C011: one implementing DeckCtrl and one application micro controller implementing the LED driver and other useful functionalities like color correction and temperature monitoring.

Release 2025.09

2025-09-29 | Rik | Leave a comment

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.

Release overview

crazyflie-firmware release 2025.09 GitHub

cfclient (crazyflie-clients-python) release 2025.9 GitHub, PyPi

cflib (crazyflie-lib-python) release 0.1.29 GitHub, PyPi

Making Social Robots Fly: Inside the Drone Gymnasium

2025-09-22 | Fredrik Ehrenstråle | Leave a comment

At Bitcraze, we’ve always believed in giving people the tools to explore the world of robotics, and especially flying robotics. We’re still surprised by just how many directions you’ve taken the Crazyflie platform, and the research and innovation areas seem endless. Swarming, autonomy, edge AI, vision, navigation, mapping, coordination, etc. are all examples of areas you are interested in and what you are using the Crazyflie to unlock.

But what about the more human aspects of robots, and the relationships we build with these machines? What does it feel like to share space with a flying system, and how can we see drones not only as tools, but companions? And how can we help push social robots from academic theory into everyday life?

These are the kinds of questions we’ve been exploring at Bitcraze and with the Drone Gymnasium, we finally have a space designed to push those ideas further.

A Living Lab for Shared Spaces

Partially inspired by science fiction, The Drone Gymnasium is an experimental playground brought to life by our industrial postdoc Dr. Joseph La Delfa, toghether with Rachael Garrett, Kristina Höök and Luca Mottola, in collaboration with KTH (Royal Institute of Technology), Digital Futures. and RISE.

It’s a living lab, where the boundaries between code, design, behavior, and imagination are blurred. A temporary, yet functional, “future lab” where people experiment with how flying robots might one day fit seamlessly into real-world environments. How they could share space with people, not just in theory, but in practice.

Students from the Physical Interaction Design course, together with our own drone experts, prototyped new robotic experiences using the Crazyflie platform, not just as flying hardware, but as social agents in motion.

From Lab to Real Life

One of the great unsolved challenges of social robotics is translation, moving from controlled lab setups into the beautiful, messy, complexity of the real world.

That’s where many good ideas stumble. That’s also where the Crazyflie shines.

Open, modular, and programmable down to the bone, the Crazyflie gives researchers and innovators permission to try things. To test, break, rebuild, and then observe how it feels to share a room with a machine that moves and reacts in the same space as you.

The Drone Gymnasium is one of many ways we’re trying to support academia, not just in supplying hardware, but in co-creating learning environments where ideas around autonomy, behavior, and social interaction can be explored hands-on, in full view of the community.

Asking Better Questions

And the results are exciting. From emergent swarm behaviors to subtle gestures and sound cues, the participants in the Drone Gymnasium weren’t just building tech, they were testing social contracts. What makes a drone feel present instead of intrusive? Helpful instead of unsettling?

That’s not only an academic question. It’s a design question. And a human robotics question.

We believe spaces like this are interesting, not only to prepare the next generation of roboticists, but to ask better questions about what we’re actually building, and for whom.

Bitcraze’s Side Event at The Drop 2025

2025-09-15 | Fredrik Ehrenstråle | Leave a comment

We are hosting a side event at “The Drop” in our home town of Malmö, Sweden.

The Drop, brought to life by Pale Blue Dot and Domino Studio, is not just another climate tech festival. It’s a dynamic forum for scientists, investors, startups, and innovators who thrive on meaningful dialogue and next-generation problem solving.

Set inside a century-old, repurposed train workshop, The Drop combines historic ambiance with forward-looking discussions. Attendees often highlight how the event sparks collaborations, unlocks new funding opportunities, and reignites optimism for the future of climate innovation.

Side events at The Drop shift the focus from grand stages to gritty, solution-oriented collaboration. There’s a long list of pop-up gatherings in Malmö’s coffee shops, studios, and parks, where teams form around specific challenges to discuss, prototype, or model new ways of solving traditional problems.

At the side event we invite participants to a discussion about the emerging role of autonomous drones in society, not just as tools, but as extensions of our thinking, imagination, and responsibility. There will be good coffee, delicious croissants from our favourite French breakfast place Dame Ginette, real tech, hands-on experimentation, and an open conversation about how robotics can be both functional and poetic.

Although our attendee capacity has maxed out, you can still sign up and hope to secure a spot. See the side event page for more details and hope to connect with fellow innovators eager to push the boundaries of robotics and climate tech later this week!

The Crazyflie 2.1 Brushless: Indoor Research Drones Just Got Better

2025-09-08 | Fredrik Ehrenstråle | Leave a comment

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.

Towards the Rust Crazyflie Lib

2025-09-01 | Arnaud | Leave a comment

We have already had a few discussions about putting more Rust into the Crazyflie ecosystem. One of the places where we find it could be the most beneficial is to replace the current Python-based Crazyflie Lib.

Why a Rust Crazyflie Lib

Rust is a modern system programming language that prioritizes reliability and productivity. This means that it is a language that will have enough performance for any current use-case of the Crazyflie lib, and nice enough to use that we can write code that is correct and easier to maintain. So in a way, switching from Python to Rust, is a move to benefit the main lib developers, us here at Bitcraze.

Furthermore, Rust has binding capabilities to almost everything. So, with a Rust implemented lib, we can target languages for all current users of the Crazyflie: mainly Python and C++ (for ROS). This means that we can make and maintain one lib for everyone.

This would be mainly interesting for the Crazyflie ecosystem because it would lift the Crazyflie API one notch. Currently, if you want to talk to the Crazyflie in C++, Swift, Kotlin, or any other language that is not Python, you have to re-implement the radio link as well as all binary radio packet handling that communicates with the Crazyflie. Our goal is to raise that to the Crazyflie lib: the Crazyflie lib would then become the Crazyflie API.

This does not mean that we want to prevent anyone from playing around with the radio packets, but we do not want that to be a requirement for interacting with the Crazyflie.

Status

Since we last talked about it, there has been quite some progress with the Crazyflie rust lib. First of all it has been moved from my personal GitHub to the Bitcraze Github. It is now an official day-time Bitcraze project :).

The lib has also been used by Marcus to make a Crazyflie-cli. This is a very useful tool when developing or working with the Crazyflie. It makes it possible to observe values, set and get params, and more, directly from the command line.

Finally, the Crazyflie Rust lib is now used in the production test rig for the Crazyflie 2.1 Brushless. We have a new rust-built test system for production that was developed for Crazyradio 2.0, and the Rust Crazyflie lib is now part of it for producing Crazyflie 2.1 Brushless. This means that the Rust lib is now officially in use and needs to be maintained! A side-project it is no more :-D.

Future, where are we going?

We have been thinking for (way too) long about what strategy we would take to introduce the Rust Crazyflie lib. The plan we currently have is to replace the current python lib, but to keep as much as possible of the current python API. The goal being to run the Crazyflie client on top of the Rust lib.

This would not only improve the client and lib reliability and performance, but it will also prove that the Rust lib is full featured enough to be used by more clients. Then we can target C++ and even Swift and Kotlin to finally improve our mobile clients.

Finally, one ‘dream’ that might be enabled by this move is to be able to make a Web-client. There are still a couple of technical hurdles (for example the fact that we for now only support the Tokio async executor), but this lib would be the foundation for a WASM mobile client. Imagine configuring and controlling your fleet of Crazyflie directly from a web-browser. Of course we need to focus on what can work today first, but this might become possible in the future thanks to Rust.

New addition to the Bitcraze team: Enya!

2025-08-25 | Enya Nilsson | Leave a comment

Hi everybody!

My name is Enya, and I am really excited to join the amazing team here at Bitcraze as an Application Engineer! In this role, I will get to work on a mix of fun things such as documentation, demos, usability, support and more, which is exactly the kind of variety that made me so drawn to this role.

I recently graduated with an M.Sc. in Engineering, focusing on information and communication technologies. During my education, I have specialized in interaction design and usability, which is also what I did my masters’ thesis in. While drones and robotics are still quite new to me, my background in software makes me eager to dive in and learn. The first time I came across Bitcraze I was fascinated by the technology, community, and the way this company works, and I knew right away that I wanted to be part of it. After all, getting the chance to explore the world of robotics feels like a dream opportunity for any engineer!

I’m looking forward to contributing, learning, and collaborating with all of you. Do you have ideas on how our documentation could be even more helpful? Or maybe a demo you’d love to see in action? I’d be happy to hear your thoughts!