flywms/handoff.md

FlyWMS handoff

Data: 2026-05-18

Stato repository

• Branch: master
• Remote: origin su Gitea
• Commit da creare per questa milestone: pipeline in linea single thread
• Tag git previsto per questa milestone: pipeline-in-linea-single-thread

Stato funzionale attuale

La base di lavoro e' ancora una pipeline sostanzialmente single-thread, con logica completa di navigazione/demo in Python.

Componenti principali presenti:

• flywms_navigation.py
  • detector Ultralytics YOLO
  • tracking geometrico
  • logica snapshot gaylord + etichetta
  • macchina a stati demo per movimento verso etichetta, stabilizzazione, scatto, ritorno, attesa WMS
  • client WMS asincrono
  • log prestazioni dettagliato per frame
  • profilo benchmark
• flywms_wms_server.py
  • server demo FastAPI
  • ricezione payload e immagini
  • OCR lato server
  • salvataggio payload/immagini ricevute
• flywms_paddleocr_worker.py
  • worker persistente per PaddleOCR
• flywms_navigation_gui.py
  • shell DearPyGUI separata dalla logica principale

Stato GPU / librerie

Verificato su questo PC:

• OpenCV con CUDA e GUI Win32 attivi
• cuDNN attivo
• YOLO/Ultralytics su GPU RTX 3050
• yolo_half = true supportato

PaddleOCR al momento resta nel worker dedicato e non e' il focus della prossima rifattorizzazione.

Configurazione importante

File: flywms_navigation.ini

Valori chiave attuali:

• ultralytics_device = 0
• yolo_half = true
• preview_fps = 24.0
• yolo_fps = 15.0
• benchmark_mode = false
• benchmark_preview_fps = 30.0
• perf_log_path = tempistiche.txt

Il video di lavoro locale usato durante i test recenti e' testhd2_edit.mp4. Nota: i file video locali non sono necessariamente da committare.

Log e benchmark

Log demo con UI

File:

• tempistiche.txt

Risultati principali gia' analizzati:

• video sorgente: circa 10.97 min a 30 fps
• run demo completo molto piu' lento a causa di:
  • UI OpenCV pesante
  • pause snapshot
  • attese WMS

Numeri rilevanti del run demo:

• demo_active_s = 1092.85 s
• demo_draw_ui_s = 597.18 s

Conclusione:

• la UI OpenCV e il rendering accessorio pesano moltissimo
• la pipeline di calcolo non deve piu' essere accoppiata alla UI in questo modo

Benchmark headless

File:

• tempistiche-benchmark.txt

Profilo usato:

python flywms_navigation.py --benchmark-mode

Caratteristiche del profilo benchmark:

• nessuna finestra OpenCV
• preview_target = 30 fps
• log tempi separato

Risultati benchmark gia' analizzati:

• benchmark_active_s = 762.13 s
• durata video reale: 658.3 s
• scarto residuo netto: circa 103.8 s = 1.73 min
• active_fps = 25.97
• active_yolo_fps = 12.69

Tempi medi in regime stabile:

• mean_loop_ms = 36.90
• mean_read_ms = 6.10
• mean_yolo_ms = 31.20
• mean_track_ms = 0.18

Conclusione benchmark:

• togliere la UI fa recuperare circa 5.5 min
• la pipeline core e' vicina all'obiettivo ma non ancora allineata alla durata reale del video
• il residuo e' dovuto soprattutto a:
  • inferenza YOLO sotto il target dei 15 fps
  • cap.read()
  • struttura single-thread del loop

Decisione architetturale emersa oggi

La prossima fase non deve essere "ottimizzare la GUI attuale", ma formalizzare una separazione netta dei ruoli.

Ruoli da formalizzare

Capture

• acquisisce frame
• acquisisce posa drone nello stesso istante
• produce un pacchetto coerente frame + pose + timestamp + frame_id

Vision / YOLO

• riceve il frame gia' corredato di posa
• produce bbox, associazioni, offset, misure visive
• non decide il workflow
• non parla direttamente con WMS

Navigation / Control

• interpreta i risultati visivi
• decide comandi di scansione, centraggio, scatto, ritorno, ripresa
• e' il vero orchestratore della missione

Drone I/O

• invia i comandi al drone o al simulatore
• riceve stato / ack / posa aggiornata
• esegue lo scatto reale

WMS Client

• riceve payload finale pronto
• invia al WMS
• non decide il volo

Punto concettuale gia' chiarito

Ogni frame che YOLO riceve deve avere gia' associata la posa del drone.

Quindi il thread di cattura non passa solo l'immagine, ma un record strutturato del tipo:

CapturedFrame {
  frame_id
  timestamp
  image
  pose_x
  pose_y
  pose_z
  yaw
  pitch
  roll
}

YOLO non deve rileggere la posizione "corrente" a posteriori. La posa da usare per interpretare quel frame e' quella congelata al momento della cattura.

Domande aperte per domani

1. Formalizzare le strutture dati tra thread:

   • CapturedFrame
   • VisionResult
   • DroneCommand
   • CommandResult
   • WmsPayload

2. Disegnare la pipeline multi-thread minima:

   • capture_thread
   • vision_thread
   • navigation/control_thread
   • wms_thread

3. Decidere se il primo passo implementativo deve essere:

   • solo capture + vision separati
   • oppure capture + vision + command pipeline

4. Formalizzare bene il flusso "scatto etichetta":

   • il controller decide
   • il layer drone/scatto produce immagine e posa
   • il payload finale va al WMS senza far diventare YOLO l'orchestratore del sistema

Raccomandazione per il prossimo avvio

Domani, in una nuova chat, partire da qui:

1. leggere questo handoff.md
2. leggere gli ultimi aggiornamenti:
   • aggiornamento-2026-05-18-18-30.md
   • aggiornamento-2026-05-18-19-14.md
   • aggiornamento-2026-05-18-19-58.md
3. cominciare scrivendo le specifiche formali di:
   • responsabilita'
   • messaggi tra thread
   • ownership dei dati
   • chi comanda chi

Comandi utili

Server WMS:

python flywms_wms_server.py

Demo navigazione con UI OpenCV:

python flywms_navigation.py --wms-enabled

Benchmark headless:

python flywms_navigation.py --benchmark-mode

GUI DearPyGUI:

python flywms_navigation_gui.py