v0.2.0 Deferred Work — Future Swarm Implementation

View Source

This document records every swarm-related feature or behaviour discussed during v0.2.0 planning that is intentionally left out of this release. It is the backlog seed for later milestones. Do not treat absence from the v0.2.0 implementation checklist as “forgotten.”

Related:

  • In scope: docs/research/swarm_coordination.md and docs/swarm.md
  • Research: docs/research/swarm_coordination.md
  • Formation guide: docs/formations.md

Suggested roadmap homes are indicative, not commitments. Revisit when that milestone is planned.


1. Behavioral flocking (decentralized local rules)

Discussed: Swarms can hold structure without a central leader by relying on local interactions (Reynolds-style / boids).

RuleMeaningv0.2.0Future
SeparateMaintain a safe minimum distance from neighborsPlan-time min_separation_cm onlyContinuous steer-away from live neighbors
AlignMatch velocity / heading of local neighborsNot implementedBehavior tick that biases yaw/speed
CohereSteer toward local flock centroidNot implementedBehavior tick toward neighbor centroid

Future module sketch: Drone.Swarm.Behavior (or Drone.Flocking)

  • Periodic tick (simulator-first)
  • Each vehicle reads neighbor telemetry within a radius
  • Emits soft relative move / rotate suggestions (still through Safety)
  • No central leader required for structure maintenance

Why deferred: Needs a neighbor sensing loop, timing model, and non- deterministic-friendly test strategy. v0.2.0 ships geometric planners, not emergent flocking.

Likely home: after swarm primitives stabilize; possibly with richer safety / observability work.


2. Live / dynamic collision avoidance

Discussed: Reject or reshape commands that would collide with other swarm members during flight.

Layerv0.2.0Future
Plan-time slot separationYesKeep
Mid-flight collision prediction in Drone.SafetyNoIngest neighbors' positions into Safety
Simulator collision volume checksNoOptional sim physics / bounding spheres
Reactive stop / hover on predicted conflictNoSwarm or vehicle policy

Future sketch:

  • Vehicle Safety gains optional neighbors: [%{name, x, y, z}, ...]
  • Swarm periodically publishes member poses to members (or Safety queries swarm)
  • On predicted breach of min_separation_cm, reject move or force hover

Why deferred: Changes the Safety contract and requires a pose distribution path. Easy to get wrong on real hardware without global localization.


3. Continuous / closed-loop formation control

Discussed: Hold Front/Vee/etc. over time while the group translates or turns (PID / leader-follower / virtual structure).

Approachv0.2.0Future
One-shot slot planner → missionsYesKeep as bootstrap
Continuous slot trackingNoRecompute error each tick; issue corrections
Velocity sync across membersNoShared speed / phase targets
Formation while translating (move as a Front)NoGroup translation primitive

Why deferred: v0.2.0 formations are command generators, not pilots. Closed-loop needs reliable pose and a control period.


4. Leader-based runtime dependency and recovery

Discussed: Formations relative to an explicit leader; what if the leader fails?

v0.2.0 decision:

  • Default reference = centroid or configured swarm origin, not a living leader
  • Optional leader: means plan-time pose snapshot only
  • Missing leader at plan time → hard error (:leader_unavailable)
  • Leader command failure during run → same as any member (:fail_fast)
  • No auto-undo of followers

Deferred behaviours:

BehaviourNotes
Live leader-follower re-anchorFollowers continuously track leader pose
Automatic leader election / promotionOn leader crash, elect next member
Replan formation on membership changeRecompute slots when members join/leave/fail
Follower hold / orbit until new leaderRecovery choreography
:all_or_nothing undo after leader failureLand/emergency succeeders automatically

Why deferred: Recovery policy is product-sensitive and unsafe to guess. Callers use explicit land/1 or emergency/1 in v0.2.0.


5. Alternate swarm failure policies

Discussed: :fail_fast vs :best_effort vs :all_or_nothing.

Policyv0.2.0Future
:fail_fastDefaultKeep as default
:best_effortNot shippedOptional opt on coordinated ops
:all_or_nothingNot shippedOn any failure, auto land/emergency succeeders
Configurable per-op policyNotakeoff(swarm, policy: :best_effort)

Why deferred: :all_or_nothing implies automatic dangerous commands. Must be explicit, tested, and documented before enabling.


6. Async / concurrent fan-out

Discussed: Task.async_stream for faster real-hardware coordination; Mission.concurrent/2 for parallel per-drone missions.

Featurev0.2.0Future
Sequential fan-outDefaultKeep for deterministic tests
:async coordinated takeoff/land/runNoOpt-in with timeouts and ordered result maps
Mission.concurrent/2 (planned)NoRun missions on many drones in parallel
Barrier sync (“all reached slot”)NoWait until all members report pose within epsilon

Why deferred: Concurrency complicates tests and partial-failure semantics. Sim-first milestone prioritizes determinism.


7. Automatic retry of swarm / movement steps

Discussed: Retry failed formation legs or movement commands.

v0.2.0: No automatic retry of dangerous movement commands (existing core principle). Swarm does not retry failed member steps.

Future (only with explicit enablement):

  • Query retries remain separately allowable (already a v0.1.0 principle)
  • Optional swarm retry: [max: n, only: [:query | ...]] — never default-on for moves

  • Human-in-the-loop replay of failed member missions

8. Multi-node / distributed swarms

Discussed: Swarm members on multiple BEAM nodes.

v0.2.0: Single-node only.

Future:

  • Distributed Registry or explicit node-qualified member refs
  • Partition handling (split-brain is hazardous for physical actuators)
  • Cross-node emergency propagation

Likely home: post-v1.0 research; treat as advanced/ops concern.


9. Nested swarm supervisors / per-swarm vehicle ownership

Discussed: DynamicSupervisor per swarm that owns vehicle children; richer restart strategies for the group.

v0.2.0: Vehicles stay under Drone.Supervisor; swarm is a sibling coordinator.

Future:

  • Optional “swarm owns vehicles” mode for classroom demos
  • Group restart policies (restart all members if one crashes — usually wrong for hardware, maybe useful for sim)

10. Real-hardware absolute formation flight (Tello)

Discussed: Running geometric formations on real Tello / Tello EDU.

v0.2.0: Simulator-first. Docs warn about Wi-Fi AP vs EDU station mode and lack of global pose. No claim of closed-loop choreography on bare Tello.

Future:

  • Tello EDU station-mode multi-drone connectivity guide
  • External localization (UWB, mocap, vision) feeding vehicle state
  • Hardware-in-the-loop tests behind explicit tags / opt-in CI
  • Honest accuracy bounds for open-loop slot flying on consumer drones

11. Adapter / platform swarm work beyond Sim

ItemRoadmap hint
Crazyflie single-drone (Crazyradio / mock)Shipped in v0.3.0 — see Crazyflie guide
Crazyflie multi-vehicle via same Drone.SwarmStill deferred — see v0.3.0 Deferred
MAVLink / PX4 multi-vehicle + SITL swarmv0.4.0+
Adapter position fidelity requirements for formationsWhen non-sim adapters join swarms
Swarm acceptance tests shared across adaptersWith adapter test suite work

Swarm and Formation modules must stay adapter-agnostic in v0.2.0 so these can plug in later.


12. Sensing, video, and surveillance semantics

Discussed: Circular/Diamond layouts for 360° surveillance and defense; Vee for aerodynamic drag savings.

v0.2.0: Geometry only. No sensor tasking, no video sync, no aero model.

Deferred:

BehaviourNotes
Video stream sync across swarm membersNeeds video milestone
Assign camera yaw / sector per circle slotSensor tasking API
Vee drag / energy modelNot applicable to Tello-class; do not fake
“Defense” behaviours for DiamondApplication-level, not library core

13. Formation catalog extensions and motion relative to heading

v0.2.0 ships geometric planners for classic shapes (see design plan): :front, :column, :vee, :diamond, :echelon, :circle, plus aliases :shoulder_pair / optional :grid.

Still deferred beyond those planners:

ItemNotes
Formation while translating as a rigid bodyGroup advance keeping Front/Vee
Smooth morph between formations (Front → Vee)Trajectory blend
3D formations (stacked vertical diamond, sphere)Needs altitude coordination policy
Hollow vs filled circle / wedge variantsExtra parameters
Custom user-defined slot maps DSLBeyond %{name => Mission}
World-frame path planner with obstacle mapFull nav stack

Heading-relative layout (heading_deg) is in scope for v0.2.0 planners so Front/Column/Vee/Echelon are meaningful; continuous heading tracking while moving is not.


14. Mission orchestration extras

Itemv0.2.0Future
Single-drone Drone.MissionYes (existing)Stable
Swarm.run formation / mission map / functionYesExtend
Mission.validate/1Optional small addOr defer if unused
Mission.run_async/2 with progress eventsNo (README idea)Later
Mission replay from logged swarm flightsNoPersistence / analytics milestone
Swarm-level DSL (Swarm.Mission)NoOnly if single-drone DSL proves insufficient

15. Observability and operator tooling

Itemv0.2.0Future
Swarm telemetry events (start/stop/command/emergency)YesKeep
LiveDashboard / charts for swarmNoObservability milestone
Mission visualizer / formation overlayNoEducational toolkit
Event log replay of swarm runsNoEducational / analytics
Observer teaching guides for swarm processesArticle notes onlyLivebook lessons

16. Membership dynamics

Itemv0.2.0Future
Fixed members at startYesKeep
Hot-add / hot-remove membersNoSwarm.join/2, Swarm.leave/2
Adopt pre-existing vehicles into a swarmDiscussed; not requiredExplicit adopt API
Stop swarm without disconnecting vehiclesDiscussed as optional flagDocument + implement keep flag if needed in v0.2.0 design; richer policies later

Tracking rule

When a deferred item above is scheduled:

  1. Move or copy its section into that milestone’s research/design docs
  2. Strike or annotate it here with Implemented in vX.Y.Z
  3. Do not implement it opportunistically inside v0.2.0 without updating the review checklist

Summary table

ThemeIn v0.2.0Deferred
Coordinator + RegistryYesMulti-node, nested ownership
Geometric formationsClassic set, one-shotMorphing, 3D, rigid translation
SeparatePlan-time min distanceLive Separate / Align / Cohere
LeaderOptional plan-time origin onlyElection, live follow, replan
Failure policy:fail_fast:best_effort, :all_or_nothing, auto-undo
Fan-outSequentialAsync, barriers, concurrent missions
SafetyPer-drone + plan separationNeighbor-aware live collision checks
PlatformsSim-firstTello absolute, Crazyflie, MAVLink swarms
Sensors / aeroNoneVideo sync, sector tasking, drag models
ToolingEvents + exampleDashboard, visualizer, replay

See also