eSlider
5f6fd8462c
CI & Release / Verify simulator (push) Skipped
CI & Release / Trivy scan (push) Skipped
CI & Release / Semantic Release (push) Skipped
CI & Release / Verify simulator (pull_request) Failing after 4s
CI & Release / Trivy scan (pull_request) Skipped
CI & Release / Semantic Release (pull_request) Skipped
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.
88 lines
6.5 KiB
Markdown
88 lines
6.5 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 the [source of truth](00-glossary.md#source-of-truth) in the warehouse. If a persistent shared structure becomes unavoidable, use a [CRDT](00-glossary.md#infrastructure--delivery) 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](00-glossary.md#infrastructure--delivery) 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](00-glossary.md#t1--warm) disk after offload to [T3](00-glossary.md#t3--warehouse).
|
|
|
|
*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 — 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](00-glossary.md#bulk-sync) and wired dock [offload](00-glossary.md#offload) of the Hive partition tree; **MinIO `mc mirror`** when the far end is the object-store facade; **[rclone](00-glossary.md#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](00-glossary.md#t3--warehouse) 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](03-data-platform.md) 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.
|