eSlider
87551fc1c1
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.
5.7 KiB
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) 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) 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) 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), 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); 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 as the working assumption. Summary table: 00 — Executive.