Centralized Multi-UAV Exploration and 3D Reconstruction Using Single-UAV Planners
This is a preprint. The authors built a centralized multi-UAV exploration framework that lets existing single-UAV sampling-based planners work in a team by sharing a common TSDF map, filtering other robots from depth data, and checking inter-robot collisions. In simulation with three UAVs, separated start positions consistently beat joint starts; for example, KAEP reached 95% coverage of the school environment in 5.35 min vs 5.86 min from a joint start. The result matters because system-level integration, not new planner logic, can speed up exploration and improve robustness.
Can established single-UAV sampling-based exploration planners be extended to a centralized multi-UAV team through system-level adaptations alone, and how much does initial deployment configuration affect exploration speed and coverage?
Extending single-UAV exploration to multiple UAVs requires fusing depth measurements into one consistent map, avoiding robot-robot collisions, and preventing robots from being reconstructed as static obstacles. Existing planners and dense mapping tools such as voxblox are designed for a single sensor or robot, so direct multi-UAV use creates map contamination and unsafe or inefficient paths.
Earlier work used frontier-based exploration and sampling-based planners such as RH-NBVP, AEP, KRH-NBVP, and KAEP. Multi-robot coordination has typically used market-based task allocation, utility-based frontier assignment, or decentralized collaborative planning. Dense mapping has used voxblox for single robots, with c-blox and voxgraph for sub-map fusion. Shortcomings: single-robot planners lack multi-agent mechanisms; explicit coordination requires reformulating the exploration logic; c-blox and voxgraph impose high compute overhead; native voxblox cannot fuse multiple sensors.
The framework keeps the core sampling logic of RH-NBVP, AEP, KRH-NBVP, and KAEP unchanged. Each UAV runs a local voxblox sub-map and sends incremental updates to a central server, which merges them into a shared global TSDF using weighted averaging of voxel distances and weights. Robots share poses peer-to-peer to remove point clouds inside a spherical radius around other robots before mapping. A central active path cache is used to prune candidate paths that get closer than d_collision to other robots. The code is released as open source.
In three-UAV simulation with a DJI F450 model and RealSense D435i, five runs per condition. Map fusion RMSE was 0.24 ± 0.20 m in police station and 0.19 ± 0.15 m in school, about one voxel size. Central TSDF merges took 7.9 ± 2.6 ms and 8.6 ± 8.5 ms in those environments, while local TSDF integration took 113.0 ± 15.4 ms and 87.0 ± 13.1 ms on a shared workstation. KAEP was fastest: in the maze, 95% coverage in 59.04 ± 2.81 s; police station separated start 2.60 ± 0.18 min vs joint start 2.96 ± 0.32 min; school separated start 5.35 ± 0.37 min vs joint start 5.86 ± 1.06 min. Separated start also improved RH-NBVP final coverage, e.g., school 92.67 ± 2.53% vs 86.16 ± 7.27%, and RH failed to reach 95% within the time limit in both joint and separated starts. Multi-UAV operation enabled full 100% maze exploration for RH-NBVP, AEP, KRH-NBVP, and KAEP, which was previously prone to local minima in single-UAV runs.
Authors state that the centralized architecture is a single point of failure and does not scale well to large fleets; future work includes real-world validation and decentralized extension. Additional limitations: evaluation is simulation-only with three UAVs and five repetitions per condition; it assumes accurate state estimation via simulated RTK-GPS; there is no comparison with explicit multi-robot coordination baselines such as market-based allocation; and environments are limited to three structures.
Drone-inspection providers, search-and-rescue robotics teams, and 3D mapping or digital-twin startups could use this approach to coordinate small teams of UAVs for faster 3D reconstruction. System-level integration is available now as open source; real-world deployment likely takes 1–3 years for small teams after validation of localization, communication, and dynamic obstacle handling, with larger fleets requiring decentralized extensions.
The full text is not republished here because the paper's license does not allow it. Read the original on arXiv.