eSlider
87551fc1c1
CI & Release / Verify simulator (push) Skipped
CI & Release / Trivy scan (push) Skipped
CI & Release / Semantic Release (push) Skipped
Treat MinIO as existing stack infrastructure (default T3 warehouse, not on the drone), add a one-page executive map, and record placement as an open team question rather than a rip-and-replace.
83 lines
5.7 KiB
Markdown
83 lines
5.7 KiB
Markdown
# 09 — Open questions
|
|
|
|
Known unknowns, each with a proposed default so the project never blocks on an answer. These are the questions to settle with the domain teams early.
|
|
|
|
## 1 — Time synchronization across the swarm
|
|
|
|
**The single most critical open item.** Merging state and detections from multiple drones is only meaningful if their clocks agree. GPS time may be unavailable (GPS-denied operation is a design case).
|
|
|
|
*Proposal:* PTP over the mesh with one elected (or designated) grandmaster per mission, disciplined by GPS when available; record per-drone clock-offset estimates into `telemetry` so post-flight fusion can correct residual skew. Budget: peer clocks within ≤1 ms keeps 5 Hz pose fusion honest; IMU-grade fusion needs tighter, but that happens on-board within one clock domain.
|
|
|
|
## 2 — Frame of reference in GPS-denied flight
|
|
|
|
Visual-odometry positions are relative; different drones may hold different local frames.
|
|
|
|
*Proposal:* the `frame_ref` field in the state schema is mandatory from day one; frame alignment (co-registration) is a mission-logic concern, but the platform must carry the metadata — retrofitting it is painful.
|
|
|
|
## 3 — Conflict resolution after partitions
|
|
|
|
By construction there are no write conflicts in bulk sync (each drone writes only its own `drone=` subtree). But *derived swarm-level* products (shared maps, fused detections) may need merging.
|
|
|
|
*Proposal:* keep swarm-level fusion out of the storage layer entirely: every drone stores its own observations; fusion is computed, not stored, in flight — and recomputed from ground truth in the warehouse. If a persistent shared structure becomes unavoidable, use a CRDT type for it rather than inventing reconciliation.
|
|
|
|
## 4 — Degradation policy under sustained link loss
|
|
|
|
What does a drone do when it has seen no peer state for N seconds?
|
|
|
|
*Proposal:* the platform's job is to expose staleness honestly (per-peer last-seen in the state cache) and keep store-and-forward running. The behavioral response (loiter, climb, return) is mission logic — but the staleness contract must be a documented, tested number per message class.
|
|
|
|
## 5 — Data disposal on loss of a drone
|
|
|
|
A drone that does not return carries a full flight on NVMe.
|
|
|
|
*Proposal:* LUKS at rest ([05](05-network-security.md)) bounds exposure; key revocation removes the lost unit from the mesh. Open question for the domain owner: is remote crypto-erase over C2 required, and what evidence standard applies to disposal?
|
|
|
|
## 6 — Sensor priority order under resource pressure
|
|
|
|
The degradation ladder ([03](03-data-platform.md)) needs a domain-approved ordering: which high-rate sensors are sacrificed first when NVMe or CPU budgets are hit?
|
|
|
|
*Proposal:* default order — reduce optional high-rate environmental sensors first; never degrade `state`, `detections`, or IMU. To be reviewed per mission profile.
|
|
|
|
## 7 — Hardware-in-the-loop coverage
|
|
|
|
The virtual swarm covers logic and protocol; it does not cover radio behavior, GPU thermals, or NVMe write endurance under vibration.
|
|
|
|
*Proposal:* a small HIL rig at the bench — real compute module + radio, simulated sensor feeds — as stage 5.5 of the roadmap, exercised by the same seeded scenarios as CI.
|
|
|
|
## 8 — Video retention policy
|
|
|
|
Detections are events, but how much raw video context should be kept? Full stream on NVMe is possible but dominates the storage budget; keeping only detection-triggered clips aligns with event-driven sensing principles and privacy-proportionality, but reduces training data.
|
|
|
|
*Proposal:* configurable per mission: detection-triggered clips with pre/post-roll as the default profile; full-stream retention as an explicit opt-in for data-collection flights.
|
|
|
|
## 9 — Fleet identity and registry governance
|
|
|
|
Who owns the device registry (drone ids, key issuance, revocation) organizationally, and what is the audit process for provisioning?
|
|
|
|
*Proposal:* treat the peer registry as a versioned artifact in the release manifest ([11](11-cicd-delivery.md)) so every change is reviewed, signed, and rollback-able like code.
|
|
|
|
## 10 — Nano-platform profile
|
|
|
|
Sub-250 g class units cannot run the full stack (no GPU, minimal CPU/storage).
|
|
|
|
*Proposal:* define a minimal profile early — state publisher + UDP-multicast pose broadcast, no local Parquet store, no video — so the swarm protocol never assumes full-stack peers.
|
|
|
|
## 11 — Lake retention and partition pruning
|
|
|
|
The observability path now scans only the most recent flights ([ADR-0009](adr/ADR-0009-bounded-lake-scans.md)), but old `flight=` partitions still accumulate on T1 disk after offload to T3.
|
|
|
|
*Proposal:* a scheduled prune of T1 partitions whose flights are confirmed present in the T3 warehouse (offload as the retention gate), configurable by age and free-space watermark. On the drone the same policy is bounded by the NVMe quota ladder ([03](03-data-platform.md)); in the sim environment it is a ground CronJob alongside the offload job.
|
|
|
|
## 12 — MinIO placement (already in the stack)
|
|
|
|
Exact how MinIO is used today was not fully specified. It should not be ripped out.
|
|
|
|
*Proposal (default):*
|
|
|
|
- **Ground warehouse (T3):** primary MinIO home — offload target and long-term object API.
|
|
- **On the drone:** default **off** — local Parquet + DuckDB cover the hot path; an object store competes with flight-critical CPU/RAM.
|
|
- **Exception:** on-board MinIO allowed if Compose already depends on an S3 API — derived datasets only, never 5 Hz pose.
|
|
- **Peer bulk catch-up:** prefer sealed-partition pull (SSH/rsync); use MinIO replication only if that is already the ops standard.
|
|
|
|
*Settle with the team:* one short diagram of today's MinIO topology (buckets, clients, what syncs). Until then, treat A7 in [01](01-problem-statement.md) as the working assumption. Summary table: [00 — Executive](00-executive.md).
|