Aggiornamento 2026-05-16 09:03

Decisione

Separare il ritmo della preview dal ritmo di inferenza YOLO.

Motivo: il video sorgente e' circa 30 fps, ma la pipeline completa non deve necessariamente elaborare ogni frame. Per la demo e per la futura pipeline reale e' piu' utile mantenere bassa la latenza, lasciando che la visualizzazione e YOLO abbiano frequenze configurabili.

Implementazione

Aggiunti due parametri in flywms_navigation.ini e nel parser di flywms_navigation.py:

preview_fps: FPS massimo per lettura/preview realtime. 0 usa il framerate della sorgente.
yolo_fps: FPS massimo per inferenza YOLO. 0 esegue YOLO su ogni frame di preview.

Valori iniziali:

preview_fps = 24.0
yolo_fps = 15.0

La stessa logica e' stata applicata anche alla shell DearPyGUI flywms_navigation_gui.py.

Nota su video e camera reale

Con un file video, questi parametri simulano il ritmo desiderato della preview e limitano l'inferenza YOLO. In questa versione single-thread, se YOLO e' piu' lento del target, non si puo' arrivare al target.

Con una camera reale, il codice prova anche a impostare CAP_PROP_FPS quando la sorgente e' webcam/camera. Questo e' best effort: molti driver ignorano il valore. Il metodo robusto resta scartare frame lato software e usare sempre il frame piu' recente disponibile.

Verifiche

Compilazione:

python -m py_compile flywms_navigation.py flywms_navigation_gui.py

Lettura config:

24.0 15.0

Run headless con yolo_fps=15 su CPU:

fps=5.5 yolo_fps=5.5

Interpretazione: su CPU il ciclo non raggiunge 15 fps, quindi YOLO gira comunque su ogni frame effettivamente processato.

Run headless con yolo_fps=2:

fps=13.7 yolo_fps=2.0

Interpretazione: il throttling YOLO funziona; la preview procede piu' veloce dell'inferenza.

Prossimo passo

Quando arrivera' la GPU, rimisurare con:

preview_fps = 24.0;
yolo_fps = 15.0;
device GPU Ultralytics;
GUI DearPyGUI attiva.

Se il costo GUI diventera' dominante, separare in seguito thread inferenza e thread GUI con stato latest-frame.

2.1 KiB Raw Blame History