Technical Summary: Swarmcage

Problem Statement

The utilization of drone swarms offers significant potential for complex tasks such as situational awareness, infrastructure inspection, and disaster response. However, existing approaches often rely on offline trajectory planning or simulation, lacking robust frameworks for real-world hardware deployment that support dynamic runtime changes. Key challenges include the limited flight time of rechargeable batteries, the inability to seamlessly add or remove drones during operation without disrupting the swarm, and the difficulty of managing collisions in dense, indoor environments. Furthermore, traditional systems often fail to handle individual drone malfunctions or battery depletion without requiring a complete system restart. There is a need for a development sandbox that enables continuous observation, autonomous hardware replacement, and intuitive human-swarm interaction using real hardware.

Methodology

The authors present Swarmcage, a framework for the runtime management of drone swarms using Crazyflie drones, the Robot Operating System (ROS), and a Vicon motion capture system. The system is designed to abstract hardware complexities from the user, allowing for dynamic adaptation of swarm sizes and formations.

System Architecture

The software architecture is modularized around a central Swarm Control instance that interfaces with hardware via a Hardware Abstraction Layer (HAL).

• Manager: A central instance responsible for integrating new drones, allocating them to subswarms, and monitoring status (e.g., battery levels, crash detection). It facilitates the "Pad Manager" logic for automated charging and replacement.
• Subswarms: The swarm is divided into self-managed groups (subswarms) tailored to specific tasks. Two specialized concepts were implemented:
  • Single Drone: Maintains a fixed size of one drone, used for interactive control.
  • Formation Swarm: Dynamically maps drones to formation points (e.g., circles, lemniscates) to maintain constant spacing.
• Commander: A central node that filters and smooths target commands from subswarms. It implements a global Collision Avoidance algorithm combining a Potential Field Method (PFM) with a custom algorithm. This algorithm uses elliptical bounding regions for moving drones and spherical regions for stationary ones, adjusting targets in the x/y plane while avoiding z-axis maneuvers that could cause downwash-induced instability.
• Hardware Abstraction Layer (HAL): Based on the Crazyswarm project but significantly modified. Key modifications include:
  • Dynamic adjustment of polling rates for battery logging to reduce radio traffic (enabling >10 drones per antenna).
  • Fair distribution of antenna access to prevent non-responsive drones from blocking others.
  • Replacement of ROS services with topics to allow the addition and removal of drones at runtime.
  • Implementation of a secondary HAL for Webots simulation.

Hardware Implementation

• Arena: A 16m × 8m × 6.5m flight area equipped with a Vicon motion capture system (20 Vicon V16 cameras).
• Drones: A fleet of 50 Crazyflie 2.1 drones.
• Tracking: Custom lightweight active infrared LED decks (<1g) were developed to replace heavy passive reflective markers, preserving flight time and payload capacity.
• Charging Infrastructure: A landing pad grid (6 × 9 arrangement) containing 50 Qi wireless charging pads. Each pad is pre-configured to identify specific drones upon landing, enabling automated reintegration.
• Interaction: A "Magic Wand" interface using a stick equipped with unique 3D marker patterns (for Vicon) or a custom DWM1000/ESP32-S3 board (for Loco Positioning System) allows users to control drone position and orientation via natural gestures.

Operational Logic

The system employs specific Replacement Strategies to manage drone turnover:

1. Default: Waits for the low-battery drone to reach the transfer point before acquiring a replacement (prevents swarm size spikes).
2. Early Replacement: Acquires a replacement immediately upon triggering the transfer (maintains swarm size).
3. Wait For Replacement: Acquires a replacement immediately but delays the release of the old drone until the new one joins (ensures constant swarm size).

Transfers between subswarms follow a four-phase timing sequence: Pre-Transfer, Transition to Transfer Point, Handover, and Integration.

Key Contributions

1. Runtime Management Framework: A novel system enabling the dynamic addition and removal of drones without disrupting ongoing operations, addressing a limitation of existing frameworks like Crazyswarm.
2. Autonomous Replacement Mechanism: A fully automated workflow for detecting low battery or crashes, landing the affected drone, and seamlessly swapping it with a charged unit from a 50-drone charging infrastructure.
3. Custom Hardware Extensions: Development of lightweight active IR LED markers for efficient tracking and a 50-pad Qi wireless charging grid with pre-configured drone identification.
4. Interactive Control Paradigm: Implementation of a "Magic Wand" interface that allows intuitive, gesture-based control of single drones or swarm reference frames.
5. Robust Collision Avoidance: A hybrid collision avoidance strategy tailored for dense indoor swarms that prioritizes safety over z-axis maneuvers.

Results

The authors conducted proof-of-concept experiments and empirical evaluations to validate the framework:

• Continuous Observation: A formation swarm maintained a circular surveillance pattern around a miniature city. The system successfully managed battery depletion and drone failures over a 3-hour period.
• Battery Depletion Test: Using 13 drones, the system maintained a single active drone in a circular formation for 3 hours. The experiment confirmed that all 13 drones were utilized cyclically, with recharged drones re-entering the swarm. The average charge-to-flight time ratio was 7.6, indicating that at least 9 drones are required to sustain one active drone continuously.
• Failure Handling Test: The system successfully detected and replaced manually removed drones (simulating crashes) within 7–10 seconds, ensuring continuous operation until the pool of available drones was exhausted.
• Magic Wand Interaction: Users successfully controlled drone positions and formations using the wand, demonstrating the system's utility for educational and interactive applications.

Significance and Claims

The paper claims that Swarmcage provides a comprehensive development sandbox for swarm applications using real hardware, moving beyond simulation and offline planning. The primary significance lies in demonstrating the feasibility of continuous drone operation through autonomous hardware replacement. The authors assert that their approach allows a swarm to sustain a specific number of active drones indefinitely, provided the total system maintains a sufficient number of operational units to cover the charging cycle.

The work highlights the importance of modular software architecture and custom hardware (active markers, wireless charging grids) in overcoming the physical limitations of small-scale drones. While the authors acknowledge that online collision avoidance in dense formations remains a challenging research topic requiring speed limitations, they posit that their subswarm division and transfer protocols effectively mitigate these risks for the demonstrated use cases. The framework is presented as a foundation for future research in long-duration surveillance and intuitive human-swarm interaction.