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.
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.
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.
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.
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.
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!
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.
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.
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!
Setting up a mobile indoor positioning system with the Crazyflie platform—specifically using the Loco Positioning System (LPS)—typically involves walking through a large room with a laser measure, sticky notes, and a bit of patience.
That was exactly my situation at work when setting up UWB anchors for mobile robot demonstrations, which often had to be relocated to different rooms. And it got me thinking—what if there were a more intuitive, flexible way to define and deploy these setups, especially in labs or educational settings where reconfigurability is key?
This question led to the development of XR-PALS, a mixed reality tool that simplifies the entire LPS configuration process. Instead of manually measuring anchor positions and inputting coordinates into cfclient, XR-PALS allows users to create and sync virtual and physical setups almost seamlessly—just by moving virtual anchors in space using a VR headset.
Three-step setup process for the Bitcraze Loco Positioning System, illustrating anchor connection, system configuration, and 3D Crazyflie drone tracking.
What is XR-PALS?
XR-PALS (XR-Powered Assistance for Loco Positioning Systems) is a tool we (Victor Victor and Dominik Grzelak) developed for defining cyber-physical spaces using UWB anchors on tripods. It runs on a passthrough VR headset (we used Meta Quest 3), allowing users to visualize the LPS layout and manipulate anchor placements in a virtual 3D environment until they are virtually and physically aligned.
Once everything is aligned, a single tap on the “Export” button sends the virtual anchor positions to a Rust-based middleware service running on a host machine within the same network as the VR headset.
It’s fast, visual, and eliminates the need for hand-measuring coordinates for our mobile robot demonstrators.
You can watch the system in action in our demo video:
Why We Built It
Usually, the LPS setup involves manual measurements and manual data entry in cfclient. This is time-consuming when environments change frequently—as is often the case in education and research.
With XR-PALS, the goals are to:
Speed up setup – Users in our study completed setups significantly faster.
Reduce error – Anchor placement is visual and interactive. No calculations needed.
How It Works
XR-PALS consists of two main components:
VR application Runs on a VR headset and displays the full anchor layout. Users can drag anchors, view distances, toggle info layers, and adjust alignment using natural hand gestures.
Middleware service A Rust-based REST API that basically bridges the VR app with the LPS anchors. This service receives the coordinates and remotely updates the LPS anchors—enabled by the open-source nature of the LPS firmware: bitcraze/lps-node-firmware. Coordinates are exported as YAML that can be imported by cfclient.
System architecture.
User interactions.
Real-World Evaluation
We compared XR-PALS against a traditional laser measurement tool in a user study involving 18 participants from our Faculty of Computer Science. Each participant had to configure a LPS layout (trapezoidal or rectangular) using one of the two tools.
Results:
XR-PALS users completed the task faster
Fewer measurement errors
Higher usability scores and confidence
Lower cognitive load, especially for the trapezoidal layout
Bar chart comparing task completion times between XR-PALS and laser.Lower values are better.
Measurement error comparison between XR-PALS and Laser. Lower values are better.
The minimal loss in accuracy compared to the time saved is not dramatic for our use cases, compared to the time saved—especially when more participants were able to correctly determine the coordinates overall. In general, users were more confident using VR glasses than a laser measurement device.
Summary and What’s Next
So if you’re working with dynamic robot setups or swarm experiments, XR-PALS might save you a lot of setup time.
The app works natively with the Bitcraze Loco Positioning System and, so to speak, extends the capabilities of the cfclient.
Here’s what we’re currently thinking about:
Supporting larger anchor sets within the app (currently limited to 8 anchors)
Improving user interactions based on feedback from our user study
Displaying anchor diagnostics (e.g., latency, power levels)
Simpler layout reusability (layouts can be saved and shared only via the computer)
At the beginning of the year, we released the Crazyflie 2.1 Brushless charging dock. This project was very much an experiment for us since this is the first product we are mainly manufacturing and assembling by ourselves in Sweden. We though we would write a little bit about the reason we made it that way and how it is going.
The Chaging dock is already described in a brunch of peviousblock post. It is basically a landing pad for the Crazyflie Brushless that charges the Crazyflie when landed. This is an idea and a design we have been using for years for our fair demos and that has been very useful, we would not be able to continuously fly at fair without it! Some of us even started using is on their desk to keep their Crazyflie Brushless fully charged at all time while developing with it:
However, even though it has been so useful for us, and we designed the Crazyflie Brushless to be compatible with contact-charging, we where not sure of how many people out there would want or need such a charging dock. So we decided to make it available in an experimental manner by manufacturing it by ourselves!
Why ‘made in Malmö’?
While the manufacturing we have in place for all our other products works really well, it requires a non-trivial amount of effort to start the first manufacturing batch. This is mainly due to the fact that the full mass production chain needs to be setup for the first batch and that production happens outside Bitcraze, this requires a lot of work in documentation, planning and administration.
However by doing the production in house, we are able to fix issues as they arises and to work in a much more agile way. In house production will of course no scale, but for a proof of concept it might work, this is at least what we wanted to experiment with.
There are two main improvements that has allowed us to even consider in-house experimental production: the advent of cheap and efficient PCBA services and the improvement in 3D printers reliability. This allows us to source all the parts and assemble them to make the final product.
How is a Charging Dock made?
The charging dock is comprised of two main parts: the plastic landing pad and the electronic.
The Landing pad is 3D printed by us. We now have a mini-print-farm at the office (if a Swarm starts at 2 drones, a print farm shall start at 2 concurrently running printer :):
What made it possible for us to consider running this kind of production was when we got our Bambulab X1 carbon. It is much more reliable and most importantly easier to maintain that any printer we got before, which gave confidence that we could start making products of what we printed. We now have an H2D as well. This currently allows us to print 12 landing docks per working day.
On the electronic side, we are now able to order fully assembled PCB, and even custom cable within weeks.
All we then need is assembly and testing and we got ourselves a small production line with very little risk and a lot of flexibility.
What now?
We are very pleased with what we have achieved so far with the charging dock. The first batch is sold out and we have started manufacturing a new batch with no big pain-point in sight. At some point we will have some decision to take though: do we continue in house or transition to more traditional manufacturing? Will all the work we put so far be useful for setting up mass manufacturing or will we have to restart from zero? At what batch size or frequency will we need to transition?
However this is also one of the great advantage of this: we have full control and we can decide when to manufacture where. As we have talked a bit previously, Bitcraze is a self-organized company, and this experiment actually fits very well with our way of working and keeps us agile. We hope this can free us from the doubts we usually have when thinking about more ‘niche’ products and will allow us to try new things in the future.
