How should an automated drone battery-swap cabinet system be designed?
Design a battery swap as a safe, recoverable, traceable transaction that the cabinet can complete locally: verify task and device identity, bay, door, battery, and mechanism; perform removal, insertion, and locking; confirm the replacement battery and charging state; and only then report completion to the cloud. The cloud coordinates tasks, inventory, permissions, and operations, but a public-network failure must not break cabinet safety.
A swap cabinet can contain battery bays, chargers, BMS communications, mechanisms, doors, fire and thermal controls, and coordination with the aircraft or dock. Manual, assisted, fully automatic, and charge-only designs have radically different risks and system scope. Freeze mechanical and electrical boundaries before platform architecture.
| Mode | Operator | Software focus | Main risk |
|---|---|---|---|
| Human scan and exchange | Pilot or technician | Identity, bay, battery stock, transaction, error guidance | Wrong placement, open door, damaged battery recirculation |
| Assisted cabinet | Person loads; mechanism inspects or transfers | Human confirmation, mechanical states, timeout, recovery | Gripping/jam, sensor conflict, power-loss midpoint |
| Fully automated aircraft swap | Aircraft docks, cabinet exchanges, aircraft resumes | Precise coordination, interlocks, scheduling, local autonomy | Flight, mechanism, battery, and environment combine |
| Charge only | Battery or aircraft docks to charge | Charge policy, reservation, status, safety | Slow turnover, thermal and compatibility risk |
Start with the simplest mode that can prove operating value. Wavesteam can integrate devices and build states, platform, user, and operations clients. Cabinet, electrical, mechanical, fire, flight, and battery safety require the corresponding specialists.
When separating device, connectivity, and platform responsibilities, also compare How should a battery management platform be developed? and How should a smart pet collar app be developed?; the linked guidance adds context that should be considered in the same decision.
Use a state machine, not remote buttons
A transaction can move through standby, authorization, arrival, reservation, safety check, unlock, transfer, identity recheck, lock, charging verification, complete, or fault recovery. Each step has prerequisites, timeout, sensor evidence, retries, and manual takeover. One transaction ID enforces idempotency. During disconnection the cabinet continues safely or stops; reconnection backfills events without repeating completed motion.
Inventory identifies each battery, bay, and state rather than only a count. Battery records include serial, model, firmware, SOC, temperature, cycle/health evidence, latest task, and service state. Pending inspection, charging, available, reserved, in use, faulted, isolated, and retired have explicit transitions. Missing data never defaults to available.
Industrial lithium batteries may draw on IEC 62619:2022, but aviation or other applications can have overriding standards. Industrial control and network design can refer to IEC 62443-4-2. Drone operation in China also follows the current flight administration regulations. Software acceptance is not flight authorization.
Remote opening, reset, and update use strict roles, current-state verification, secondary or dual approval where appropriate, short-lived signatures, anti-replay, local interlocks, and final acknowledgement. Offline service is permitted only when local identity, inventory consistency, and hazard analysis support it. Payment state and physical result are separate; a refund must never trigger a mechanical reversal.
Wavesteam validates one cabinet, aircraft model, and uniquely identified battery fleet through repeated swaps, including misalignment, wrong type, unclosed door, jam, sensor conflict, no BMS response, overtemperature, network/power loss, duplicate command, and manual recovery. We measure successful-swap and duration distributions, mid-state recovery, inventory consistency, alarm handling, charge faults, audit, and OTA rollback. Multi-cabinet scheduling, regional stock, predictive maintenance, and charging follow only after endurance evidence.