eSlider
57e48e0b55
Problem statement, on-board architecture, Parquet/DuckDB storage design, swarm sync strategy, zero-trust networking, environments, observability, CI/CD delivery with fleet release manifests, roadmap and open questions.
4.4 KiB
4.4 KiB
10 — Domain context
Swarm autonomy has moved past biomimicry-driven research toward practical, operational systems. This proposal builds on a set of publicly discussed principles from that field; each maps directly onto a platform component.
Principles and where this design answers them
| Principle | What it means | Where it lands in this design |
|---|---|---|
| Decentralization | No single controller; every unit perceives locally and decides autonomously; no single point of failure | No swarm-wide orchestrator; each drone runs its own full data plane (02) |
| Local interactions | Behavior emerges from neighbor-to-neighbor exchange, not top-down commands | State broadcast between peers; event hooks trigger local reactions (04) |
| Self-organization | The group coordinates without pre-planned orchestration and survives the loss of members | Opportunistic replication; store-and-forward through intermediate peers; automatic reconciliation after partitions (04) |
| Sustainable pulsing | The swarm repeatedly engages a target area from multiple directions and re-forms as conditions change | Requires every unit to know peer state with bounded staleness — exactly the state-sync contract (04) |
| Ubiquitous sensing | The swarm acts as one distributed sensor, fusing observations into shared "top sight" | Detections are first-class derived data: locally stored, selectively shared, fully preserved for post-flight fusion (03) |
| Edge intelligence | Detection and classification happen on the unit; a local event can autonomously cue nearby units without central validation | On-board YOLO-like inference + event hook that publishes detections to the mesh immediately (02) |
| Mesh networking | Units relay data for each other; loss of any single link degrades nothing | Encrypted ad-hoc mesh, no infrastructure dependency (05) |
| GPS-denied operation | Position comes from visual odometry and relative localization, not satellites | The state schema carries a frame-of-reference field and covariance, not just raw coordinates (03, 09) |
| Man-in-the-loop | A supervisor defines intent and boundaries; the system distributes tasks itself | Narrow C2 plane for declarative goals; no per-vehicle steering (02) |
| Adaptive re-tasking | A detected event re-prioritizes nearby units without manual replanning | Event-driven data plane: detections propagate as events, mission logic subscribes (02) |
| Ethical autonomy / traceability | Autonomous actions must be explainable: event-driven sensing over indiscriminate collection, decisions logged and auditable | Every broadcast, sync, and re-tasking trigger is recorded in the flight data; the warehouse preserves the full decision trail for replay (03, 06) |
| Adaptive learning | Experience gathered by one unit improves the whole team over iterations | Complete flights land in the ground warehouse; training reads from it and ships improved model weights through the fleet release cycle (06, 11) |
| Multi-domain scaling | The same swarm concepts apply to aerial, ground, surface, and underwater units — including sub-250 g platforms | The data plane is a set of small independent services; the minimal profile (writer + publisher, no GPU stack) fits constrained units (02) |
Why this matters for a data platform
Every one of these principles quietly assumes a working data layer underneath:
- Pulsing and re-tasking assume each unit knows peer state — that is a sync latency and staleness budget.
- Ubiquitous sensing assumes observations are fused later — that is a warehouse with aligned timestamps and schemas.
- Edge intelligence assumes detection events reach neighbors fast — that is an event-driven publish path, not a polling loop.
- Traceability assumes actions are replayable — that is complete, immutable, partitioned flight data.
- Learning assumes flights are comparable across the fleet and across time — that is schema versioning and a single storage format.
The swarm behaviors are the visible product; the platform in this repository is the substrate they stand on.