e90d775dfd
pick_worker trie les candidats par: 1. nombre de jobs deja assignes sur le worker (moins d abord) 2. VRAM free (plus d abord) 3. hostname (tiebreaker sans comparer les dicts) Avant: le worker avec le plus de VRAM gagnait toujours (ex: .84 24GB vs .87 12GB) donc tous les jobs empilaient sur .84 pendant que .87 idle. fps=3 -> fps=2 via COSMA_QC_FPS dans dispatcher.env (cf user: 1 kt + reconstruction SfM -> 2 fps pas stride 6). Logs pick_worker ajoutes pour debug quand no candidate.
cosma-qc
COSMA post-acquisition QC pipeline — reconstruction photogrammétrique par GoPro (lingbot-map), queue de jobs distribués, dashboard web pour suivi terrain le jour même.
Objectif
Après une acquisition AUV (2 GoPros × 2-3 AUVs × heures d'enregistrement), savoir rapidement si la couverture est complète avant de replier la mission — sans attendre les 30 jours du traitement photogrammétrique complet.
Pipeline
SSD plugged ─┐
├─▶ Ingestion ─▶ Frame extraction (per GoPro × segment)
│ │
│ ▼
│ Job queue (SQLite)
│ │
│ ┌──────────────┼──────────────┐
▼ ▼ ▼ ▼
Dashboard Worker .87 Worker .84 (scalable)
(FastAPI) (3060) (3090)
│ │ │
│ └─▶ PLY ◀──────┘
│ │
│ ▼
└──────── ICP stitch (Open3D) ─▶ viser viewer
Stack
- Backend : FastAPI + SQLite
- Frontend : HTMX (UI réactive sans build JS)
- Queue : table SQLite + workers SSH-triggered
- Monitoring : polling
nvidia-smisur .87 / .84,dfpour disque - Reconstruction : lingbot-map (GCT-Stream windowed)
- Stitch : Open3D ICP
Déploiement
- Service sur .82 (stable, Caddy pour URL propre)
- Workers : SSH vers .87 (3060 12 GB) et .84 (3090 24 GB)
État
Scaffold en cours.