peer to peer

Some Fun-Friday projects begin with a clear goal and a straight path to the finish line. The best ones, however, take you somewhere completely unexpected.

This project originally set out to build a device for determining spatial coordinates within a Lighthouse-covered flight area. Instead, it evolved into the Lighthouse Wand, a hand-held “magic wand” letting you grab and move drones in 3D space just by pointing at them.

How it works

The Wand is a Crazyflie platform with a Lighthouse positioning deck. That’s enough for it to know its own position and orientation in the room. When the button is pressed, it starts broadcasting those 6 numbers over Peer to Peer radio.

Any Crazyflie/receiver in the room on the same radio channel, listens to those packets and runs a simple “grasping” algorithm: while the wand line (positive x-axis) passes close enough to the drone, it builds up a confidence score. Once the score crosses a threshold, the drone is considered grasped. From that point on, it just keeps a specific distance from the wand, while being on the wand line.

When the button is released, the grasped drone either hovers in place, or lands, depending on the release height.

The Color LED deck on the receiver drone, gives you visual feedback: yellow while the Crazyflie is building up its confidence score, green when it’s grasped, and red when it’s landing.

A big advantage of this system is that all interactions run entirely onboard the Crazyflies, allowing them to operate without relying on the cfclient or cflib during flight.

The hardware design

The wand is a Crazyflie Bolt 1.1 with a Lighthouse positioning deck and a Buzzer deck for audio feedback. To allow for user input, I created a simple “Button deck” based on the Prototyping deck utilizing the GPIO pins of the Crazyflie. It also includes an LED for visual feedback when the button is pressed.

The casing is fully 3D printed in PLA and was designed to give the device a more wand-like feel in the hand. Its shape also makes it easier to hold, aim, and use intuitively during interaction.

The firmware design

Both the Wand and the receiver are firmware apps created on top of the crazyflie-firmware. In the design that I followed, there is a clean separation between the two parties. The wand is a pure broadcaster: it only reads its own pose and transmits it. All grasping logic and flight control run independently on each receiver. Since each receiver is fully autonomous, the system scales to any number of drones with no extra load on the wand.

Where to find the Lighthouse Wand?

A version of the Lighthouse wand is now integrated in our decentralized swarm demo, where it can be used to interact with multiple drones, while the collision avoidance algorithms are still on. This system was first showcased at the European Robotics Forum 2026 in Stavanger, and we’ll also be bringing it to ICRA 2026. If you’re there, stop by booth 91and try flying a bunch of Crazyflies yourself using the wand.

You can find the complete Lighthouse Wand project in this repository. It contains the firmware, the hardware files, and detailed documentation to build and experiment with the wand yourself.

Hello world, 

you had probably seen me from the last blog post when I first arrived. I spent this summer working here in Malmö and I can definitely say that it was one great, educative and fun experience. During the last three months I have been in Bitcraze, I was given the chance to work and develop applications and demos on the robotics subject I am most interested in, drone collaboration. 

Centralized Swarm with Multiple Flying Copter

I initially started looking into the implemented swarm demo which had 7 drones charging wirelessly in 7 charging decks and one of them flying by executing a spiral trajectory until it has a low battery and another one takes its place. The original swarm demo was shown at several conferences before the pandemic hit, but my plan was to improve it by adding more quadcopters flying simultaneously. The biggest problem was the collisions and ground effect happening between them. In order to solve that I was based on this paper and the optimization engine OpEn. I solved the problem of all drones starting from a point and going to a final one without colliding and covering the minimum distance by transferring these constraints into a cost function of an optimization problem assuming a simplified model for the quadcopter. Its output is waypoints for each quadcopter to pass from. These waypoints are transformed into a trajectory(piecewise polynomial) by a custom trajectory generator based on linear algebra.

In this way, I made it possible to execute non-colliding trajectories for 4 quadcopters, upload and execute them. While executing the first trajectory, the next one was being calculated and uploaded assuming the goal of the previous one as starting point. In this way, I managed to have 4 Crazyflies flying simultaneously and landing when their battery was running out and the fully charged ones were taking their place. This mechanism with some modifications can be used as a path planner or a standalone trajectory generator from a future user by feeding it waypoints and time durations for each waypoint segment. You can find the source code here.

Decentralized Swarm with Multiple Flying Copters

The aforementioned setup seemed to work pretty well but there was always the need of having a central PC monitoring and taking decisions for the whole swarm. So we wanted to move the architecture to a decentralized one, of which Kristoffer did some preliminary work shown at BAMdays last year. This was made possible by utilizing the onboard peer-to-peer protocol (P2P) in collaboration with the onboard collision avoidance algorithm introduced in this PR contributed by James Preiss from the University of Southern California. All the Crazyflies share their position and state through the protocol by broadcasting them at a rate of 15 Hz.

Although there were some missed packets, they could avoid each other while flying by updating the collision avoidance algorithm which is taking action between the high level and the action commander by altering its waypoints. The decisions of which drone should take off or land are also taken in a decentralized way. Whenever one copter is about to take off it enters the corresponding state and assigns itself a randomized timeout. During this timeout, if the desired number of airborne copters is achieved it goes back to idle. If not and the timeout occurs it finally take-offs. So, despite there is not an actual common decision, the swarm can be led to simple desired states like keeping the number of the drones flying constant and executing changes between the landed, charged copters and flying ones. You can find the source code here.

Token Ring Implementation

After I finished this project and since I had some extra time left I decided to work more in the P2P protocol. The need for having a robust way to communicate between the Crazyflies and a way to verify that a packet was indeed sent was obvious. A solution to this problem was offered by Christos Zosimidis and Klaus Kefferpütz from the Cooperative Control Lab in Hochschule Augsburg, namely a token ring implementation. I would really like to thank them for this collaboration and hope for future ones as well.

Specifically, the proposed token ring protocol was implemented in a modified version of the nrf-radio firmware and the Crazyradio. This protocol assumes that each Crazyflie is a node of a network and a token is passed around giving permission to each drone that has it in its possession to broadcast data. So, each time only one Crazyflie broadcasts data which leads to fewer packet collisions and losses. It can also acknowledge that a node has received the data targeting to it and then continues to others. The interface with the protocol is being done by 2 queues (TX and RX) where the user can place data that wants to send and read the RX queue to receive. The moment that this blog post is being written only the static version of it is public in the firmware, which means that the number and the id of the  Crazyflies must be defined before execution and in case a copter fails the whole network fails. Although, I am currently working on a dynamic approach that is going to solve these problems

All in all, I had a great time here in Malmo despite the fact that the Swedish summer is much colder than the warm weather I was used to in Greece. I was amazed by the way things in Bitcraze work and how the whole company operates. It was a pleasure being around so creative people and I am happy that I could help even in a small way. Thank you very much for giving me the opportunity to work with you and I hope I will keep on contributing to this amazing project in the future.

Happy hacking and fly safe!