eSlider
5f6fd8462c
Extend glossary with storage floors, source of truth, and linkable anchors. Fix broken links, pose frame drift, rsync/offload wording, and README tone. Add docs/improvement audit records and live demo links in design journey.
6.5 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 the source of 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 — Bulk transfer tool choice
In-flight peer bulk sync, dock offload, and sim shortcuts have used different wording (rsync, rclone, mc mirror, cp -ru).
Proposal: rsync over SSH is the default for peer bulk sync and wired dock offload of the Hive partition tree; MinIO mc mirror when the far end is the object-store facade; rclone only when the backend is S3-compatible and rsync is awkward; sim CronJob keeps cp -ru + mc mirror as a documented shortcut. Pick one primary tool per path in provisioning, not all at once.
13 — DuckLake vs plain DuckDB + Parquet on T3
The design journey mentions DuckLake; no ADR or implementation commits to it yet.
Proposal: baseline remains DuckDB read_parquet globs over the T3 Hive tree with MinIO underneath; evaluate DuckLake only if catalog/versioning pain appears at warehouse scale — decision gets its own ADR before any dependency lands.
14 — schemas/ registry layout
03 — Data platform references an in-repo schemas/ directory that does not exist yet (roadmap stage 2).
Proposal: add schemas/ as part of stage 2 with one SemVer file per dataset version, referenced from the fleet release manifest; until then treat schema versions as manifest-only fields and document the gap here rather than implying the directory already exists.