What does it take to bring a new coordination stack to the Crazyflie? In this guest post, Jim Steele, founder of Tapestry OS, shares his experience building a Zephyr-based firmware port for the Crazyflie 2.1 Brushless and using it to explore decentralized coordination with three drones. We’re happy to welcome Jim to the blog to share the work and what he learned along the way.
The Crazyflie platform has an excellent answer to the question of how to fly a drone autonomously. The firmware is well-documented and actively maintained with hardware abstraction, sensor drivers, and state estimators providing solid infrastructure that a research team can build on confidently.
The question I kept running into is one layer above that: once you have drones that can fly reliably, how do you coordinate what a collective of them does together? Not at the trajectory level (Crazyswarm2 handles that well) but at the level of distributed state: what does each drone know about where the others are, how fresh is that information, and how does the collective continue functioning correctly when a drone fails or communication is interrupted?
Most research teams answer this question by writing custom coordination firmware specific to their experiment. The result works, but it does not transfer to the next experiment or the next platform. I wanted an answer that would.
Tapestry OS provides this layer as an open-source coordination stack built on Zephyr RTOS. It includes a distributed world model, gossip-based state propagation, fault-tolerant consensus, and a declarative application API that lets domain experts express collective behavior without touching the underlying firmware. This post is about porting Tapestry to the Crazyflie 2.1 Brushless and validating its core coordination claim on three drones flying in collective formation.
The port
Tapestry’s stack has seven layers, L1 through L7. For the Crazyflie port, the work lives in L1: the Physical Substrate Interface, Tapestry’s equivalent of a board support package. We began by developing a native Zephyr port for the Crazyflie 2.1 Brushless. This had to include the flight control itself: attitude (rate + angle), altitude-hold, position-hold loops, sensor drivers, and a Lighthouse V2 deck driver. Bitcraze stock firmware was an invaluable reference (the control cascade architecture and the Lighthouse calibration math especially) though Tapestry’s implementation is written from scratch and shares no code with it.
Bring-up including L2 had some surprises, including two real bugs in Zephyr’s STM32 I2C driver that the Tapestry repository carries as patches until they are upstreamed. Streaming console output over the Crazyradio early in the port made debugging much less painful.
Lighthouse positioning took the longest. The interesting problems were pairing the base station’s sweep planes correctly from raw deck timestamps, and rejecting phantom rays from specular room reflections. The eventual implemented solution gates rays against the base station’s optical field of view (a hardware constant that survives recalibration) plus triangulation-consistency and rate-of-motion checks. Once resolved, position accuracy is solid.
Tapestry’s higher layers, including the L3 gossip transport and the L4 Collective State Manager, required no changes. That is the point: once the foundation is in place, the coordination logic does not care whether it is running on a ground robot or a drone.
The formation demo
Three Crazyflie 2.1 Brushless drones, each running Zephyr with the Tapestry substrate and collective world model, were flown in a simple formation. Each drone reads its own absolute position from the Lighthouse deck and gossips it to its peers every 500 ms over the nRF51’s peer-to-peer radio channel. The resulting world model holds fresh entries for its two peers, with staleness tracking, and continually compares its distance to each fresh peer against a target spacing: too close pushes away, too far pulls closer.
The example formation in the following video shows two drones hover and align in equilibrium. When a third powers on and flies among them, the three maintain separation until the third drone ends its mission, lands itself, and the remaining two close back into their line before landing.
There is no leader, no ground station, and no phase script: each drone runs Tapestry’s decentralized world model and shares only its own position over gossip. The recovery behavior is the part to watch closely. When one drone ends its mission, it lands and goes silent. The remaining two re-form their line about ten seconds after the departure, without any instruction from an external system. This is deliberately the same code path that would handle a real mid-flight interruption.
This is Tapestry’s first demonstration on real Crazyflie drones: a coherent shared understanding of collective state, maintained entirely through peer-to-peer gossip, driving behavior through local rules. The demo logic can be expressed as a declarative L7 Choreo with the Tapestry SDK without touching firmware.
What is available
The Crazyflie 2.1 Brushless support is in the Tapestry OS repository under Apache 2.0. It includes the steps to recreate this demo: per-drone configuration, Lighthouse calibration, and ESC provisioning.
This is an initial port. We chose Zephyr to unlock a standardized, scalable ecosystem that allows the Crazyflie to integrate with industrial-grade RTOS tooling. We chose standard PWM for this port to simplify the initial Zephyr hardware abstraction with a stable and reliable baseline for our formation coordination logic. A number of Crazyflie capabilities are not yet available on the Zephyr-based stack (Kalman estimation, flow deck, and DSHOT among them), and contributions are welcome.
If you are doing swarm research on the Crazyflie and want coordination infrastructure you do not have to build yourself, the Tapestry repository is a good starting point. Try the port, open an issue if you hit hardware-specific bugs, and share your formation experiments on GitHub or in the Bitcraze forum.