Air hockey: il progetto completo.

1. Richieste e stato delle decisioni

2. Dimensioni, materiali e costruzione

↑ Mostra il CAD interattivo dei nove gruppi

Riscontro Brico io, 16 ottobre 2026: trovati a catalogo faesite3 nei formati1220 × 600 e1220 × 1010, MDF 930 × 520 × 12 e OSB 1250 × 620 × 9; listelli d’abete in lunghezze 1000, 2000, 2500 e 3000. BR-01 confermata: piano faesite3, base OSB9, pannelli MDF12 e sostegni abete15 × 15 applicati al CAD; camera utile25 e campo800 × 400 conservati. Decisione e nuove quote · Tagli nominali. Pannelli, prezzi, finiture e taglio · Listelli, sezioni e confronto con il progetto. Disponibilità e condizioni del negozio locale non verificate.

Quote in millimetri. Il cassone misura 900 × 500, 505 con i diffusori senza porte e 980 × 505 con le porte montate; altezza massima del tavolo senza supporto camera circa 126,5. Campo utile 800 × 400, a quota Z=98. Le dimensioni sono nominali di progetto: giunzioni, tolleranze e componenti commerciali possono richiedere revisioni.

Il vano accessori si trova sotto il fondo della camera, così non restringe localmente l’aria sotto il piano. Sigillare bordi del legno e giunzioni, tenere liberi i fori e prevedere guarnizioni compatibili con le quote finite. La preparazione rettangolare con lama ipotizzata3mm colloca i pezzi in3 MDF,1 faesite e1 OSB, più1 listello:71€ esposti. È una disposizione nominale non ottimizzata, da verificare con tolleranze, rifilatura e taglio minimo del servizio.

Distinta con tutte le quote e quantità · STEP assemblato · STEP esploso

3. Distribuzione dell’aria: ricerca, modello e confronto

Riferimento attuale: camera comune da 25 mm. Fondo a Z=58–70; volume d’aria a Z=70–95; piano a Z=95–98. Due deflettori all’ingresso e sostegni puntuali lasciano comunicare il volume. La ricerca ha documentato sia camere uniche sia canali per fila: i canali non sono stati dimenticati, ma modellati e confrontati come varianti.

Soffiante e percorso nel tavolo

Riferimento di calcolo: SUNON PF97331B1-B00U-A99, centrifuga 97 × 95 × 33, 12 V, 1,6 A, 19,2 W e 5400 rpm. Estremi di scheda: circa 75,1 m³/h a pressione nulla e 844 Pa a portata nulla; non sono ottenibili contemporaneamente. Rumore dichiarato 58 dB(A), non rumore misurato del tavolo. La variante A99 non ammette PWM sull’alimentazione: per regolare l’aria serve selezionare una variante/metodo compatibile e aggiornare il calcolo se cambia la curva.

Aspirazione laterale tramite griglia 116 × 34, area libera nominale circa 2184 mm²; soffiante nel vano inferiore e raccordo con gola ipotizzata 39 × 26 verso ingresso nel fondo 100 × 20. Sopra l’aspirazione della ventola rimangono circa 10 mm: perdite e raffreddamento nel vano devono essere verificati. Nessun filtro è attualmente previsto; aggiungerlo modifica le perdite.

Risultati nominali e varianti a 19 canali

Nelle varianti: camera inferiore 10 + separatore 3 + canali 12 = 25 mm totali; 18 setti da 784 × 12 × 3 formano 19 canali, larghi 17 internamente e 20,5 alle due estremità. Aperture 12 × 8: 19 a un’estremità oppure 38 alle due estremità. Il separatore misura 800 × 400 × 3 con otto foriØ7,4 per la minuteria; in queste varianti le battute sono alte11 e dadi/rondelle salgono1; sostegni e deflettori inferiori scendono a 10 mm. Incremento netto di materiale stimato circa 1,4 dm³, oltre a colla e finiture.

La camera comune fornisce circa 0,88 L/min per foro. Variando le perdite ipotizzate si ottengono circa 30,6–45,4 m³/h: è sensibilità del modello, non intervallo statistico. Lo studio dei canali include 18 combinazioni geometriche e scenari di perdite e fabbricazione. Con diametri ipotizzati fra 0,95 e 1,05 mm, il coefficiente di variazione sale a circa 6,1% per tutte le architetture: nel modello la foratura pesa più delle piccole differenze nominali.

Il calcolo è una rete stazionaria: 741 pressioni nella camera comune, 1482 nelle varianti a due livelli, curva della ventola e perdite viscose/inerziali. Non risolve vortici, getto 3D, disco che copre i fori, cuscino d’aria, difetti di tenuta o flessione del piano. I regimi 60/80% sono teorici, non valori PWM da impostare.

Esplora confronto e CAD dei canali · Tutti i casi e metodo · Calcolo di base · CSV dei fori

Display frontale e replay con traiettorie

Estensione approvata il 17 ottobre: schermo 10,1″ sul montante della camera, rivolto verso il fronte del tavolo, con alternativa 13,3″. Il Raspberry è l’host previsto per i replay a colori; modello Pi, camera USB e display commerciale restano da scegliere. Le camere in bianco e nero sono escluse.

Apri il confronto animato 3D e prova il layout del display →

La demo mostra disco e battitori animati, ripresa dall’alto sullo schermo, scia progressiva e rimbalzo, pausa e velocità1×/½/¼. Il tasto Partita→replay simula il passaggio dal gol al rallentatore. È una coreografia CAD: acquisizione, tracking e prestazioni sul Raspberry non sono stati collaudati.

CAD10,1″ · CAD13,3″ · Decisione e limiti · Ricerca USB aggiornata

4. Elettronica attuale, alimentazione e comandi

EL-01 è la proposta dettagliata per ESP32 WROOM classica. Comprende una sola scheda di controllo; CAM-01 aggiunge il video. Il CAD presenta nove gruppi: base, servizi/cassetto, fondo aria, pareti/sostegni, piano, cornice, ventola, elettronica e cablaggi. Le schede sono ingombri illustrativi, non PCB sbrogliati.

Alimentatore DC esterno → presa laterale → fusibile/distribuzione → rami ventola, RGB e convertitore 5 V per schede/display. Nel tavolo è prevista bassa tensione. Logica 3,3 V; adattamento I²C con BSS138 verso il driver 5 V. Il controllo non alimenta direttamente strisce o motore dai GPIO.

Scenario EL-01 massimo indicativo circa 4,1 A a 12 V; ramo camera con riserva 1 A a 5 V ed efficienza buck ipotizzata 85% porta a circa 4,6 A a 12 V. Un 12 V/5 A sarebbe vicino al limite: alimentatore, presa, protezioni e sezioni vanno ridimensionati sugli assorbimenti effettivi. Questi numeri non dimensionano un Raspberry Pi. Il ramo della scheda scelta, spunti, periferiche e raffreddamento richiedono un nuovo bilancio.

Schema EL-01 navigabile · PDF delle 15 tavole · Collegamenti pin per pin · Netlist · Disposizione e limiti. Non risultano ERC/SPICE, PCB o collaudo hardware eseguiti.

5. Camera integrata, ripresa e AI esterna

La proposta CAM-01 colloca l’obiettivo sopra il centro del campo: X=0, Y=0, Z=798, quindi 700 mm sopra il piano. Montante sul lato lungo posteriore a Y=270, senza occupare i lati dei giocatori. Tubo alluminio 20 × 20 × 1,5: montante 840 e braccio 270; staffe rimovibili, due contropiastre e quattro fissaggi M4 da dettagliare. Altezza totale circa 862 dal fondo, ingombro fisico circa 980 × 535. Con il supporto rimosso torna l’ingombro del tavolo.

Testata indicativa 64 × 50 × 28 con scheda riservata 50 × 35, camera e cavetto corto nella testata. Piastra 70 × 55 × 3, distanziali da 7; alimentazione nel tubo e buck separato nel vano. Non è stato selezionato un modulo commerciale né verificata la stabilità del braccio.

Inquadratura e visibilità

Con 70° orizzontali effettivi, formato 16:9, lente ideale e distanza 700, copertura = 2 × 700 × tan(35°) ≈ 980 × 551 mm. Rientrano campo e cassone. Con 60° si ottengono circa 808 × 455: il cassone non rientra. Campo visivo diagonale e orizzontale non sono intercambiabili; crop, distorsione e risoluzione effettiva vanno verificati prima di tagliare i tubi.

Chi fa cosa

1. Sensori delle porte: autorità del punteggio, con correzione manuale disponibile. La visione aggiunge informazioni e non annulla automaticamente un gol.
2. Acquisizione: immagini con identificativo e timestamp di cattura, eventi di gioco sincronizzati. La ricezione dei pacchetti non fornisce da sola il tempo del tiro.
3. Tracker: calibrazione dei quattro angoli, correzione ottica, posizione e traiettoria con indice di confidenza; gestione di occlusioni da mani e battitori.
4. AI esterna: telecronaca, statistiche e analisi dei tiri; riceve eventi e fotogrammi/sequenze nel formato del servizio scelto. Non ogni servizio AI accetta direttamente uno stream MJPEG o RTSP.

Nella soluzione a due ESP32 un PC/server gateway coordina video ed eventi, conserva le credenziali e adatta i dati all’AI. Con Raspberry può essere ospitata lì parte di questo lavoro. Fornitore, protocollo, abbonamento e tempi di risposta restano da scegliere; nessun servizio è già attivo.

Il riscontro Espressif di circa 20 fps a 720p MJPEG è relativo a un esempio, non una promessa per ogni ESP32-S3. A 5 m/s bastano 1 ms di esposizione per produrre 5 mm di mosso: più potenza AI non recupera immagini mai acquisite. Per tracking rapido valutare camera veloce, luce bianca stabile ed eventualmente global shutter; RGB e PWM possono alterare contrasto e introdurre bande. Prestazioni, costo e illuminazione aggiuntiva non sono ancora dimensionati.

Replay a 1080p e 120 fps — requisito in valutazione

Un Raspberry Pi 5 con camera USB 3 che produca già MJPEG a 1920 × 1080 / 120 fps è una candidata per registrare replay senza ricodifica in tempo reale. Non è stata provata la catena completa: ricezione, buffer, archiviazione, anteprima, controllo del tavolo e AI simultanei. La capacità del sensore, il formato in uscita e i frame realmente salvati sono requisiti distinti.

Non estendere queste specifiche a ogni modulo AR0234 o a qualsiasi camera pubblicizzata “120 fps”: altre revisioni raggiungono tale velocità soltanto a 720p. La pagina Arducam è risultata disponibile nel testo indicizzato, mentre l’apertura diretta ha restituito 403; confermare esatto codice, revisione, formato e modalità UVC prima dell’acquisto.

Architettura proposta: camera USB 3 → acquisizione nativa senza decodifica/ricodifica → buffer circolare di immagini compresse → evento gol → conservazione di alcuni secondi prima e dopo → riproduzione rallentata. A 30 fps di riproduzione, 120 fotogrammi acquisiti al secondo danno un rallentamento 4×; a 60 fps, 2×. Anteprima e tracking possono usare meno fotogrammi. Python coordina buffer ed eventi; la movimentazione video resta nei componenti nativi. Dimensione del buffer, SSD/altro storage, banda e carico devono essere misurati sulla camera reale; MJPEG ha bitrate variabile.

La codifica H.264 in tempo reale a 1080p120 sul Pi 5 non è garantita: usa encoder software. Il Pi 4 non è da considerare una soluzione H.264 hardware Full HD120 solo perché dispone di un encoder. La registrazione MJPEG già compressa dalla camera è un percorso diverso. Serve esposizione breve e illuminazione adeguata; global shutter riduce le deformazioni da lettura, non elimina il mosso da esposizione. Restano da quotare camera, storage, alimentazione e raffreddamento.

Fonti: tabella ufficiale dei sensori Raspberry · specifiche Arducam USB3 con ISP · codifica e acquisizione Raspberry.

Ricerca delle camere e scelta Pi 4 / Pi 5

Correzione ottica importante: il driver IMX708 nel modo 120 fps usa una regione 3072 × 1728 su una matrice 4608 × 2592. Per CM3 Wide la copertura stimata con ottica ideale a 700 mm è circa 1153 × 618 mm, con disco da 44 mm largo circa 49 pixel nel 720p. Non sono misure reali e non è la precedente ipotesi generica di 980 mm / 57 pixel. Verificare distorsione, correzione e crop effettivi.

Cavi: montante più braccio richiedono una tratta superiore ai soli 70 cm verticali. USB3 è pratico per tenere il Raspberry nel vano; anche il cavo da 1 m potrebbe non bastare al percorso interno completo. CSI è la scelta economica con camera ufficiale, ma un lungo flat va verificato o sostituito con una soluzione specifica: non è garantito dal solo connettore.

Pi 4, due percorsi: con USB MJPEG registrare i dati già compressi senza ricodifica; con CSI provare ISP a 720p e H.264 hardware. La documentazione rpicam descrive il target 720p120 con level 4.2, denoise software disattivato e senza preview, con ulteriori suggerimenti specifici Pi 4: non garantisce 120 fps stock con tutti i servizi. Su Pi 5 la codifica H.264 è software; maggiore potenza CPU permette altri compromessi qualità/carico ma richiede comunque misura. L’AI che analizza MJPEG deve decodificarlo: il risparmio di codifica non elimina il costo del tracking.

Raccomandazione aperta: riusare Pi 4 se disponibile, con CM3 Wide per contenere il costo dopo aver risolto CSI, oppure B0610 per global shutter e collegamento USB. Comprando nuovo e volendo tracking locale più impegnativo, preferire Pi 5 per margine. Registrare 120 fps, visualizzare replay a 30/60 e mandare all’AI esterna gli eventi/sequenze necessari; non richiedere automaticamente inferenza neurale a 120 fps. Prova di accettazione: 10–15 minuti, timestamp e frame distinti contati, buffer pre/post gol, rete, tracker, suoni e luci contemporanei; controllare temperatura e risposta dei sensori.

Rapporto completo: camere, crop, prezzi e fonti primarie · Rapporto Pi 4 / Pi 5 e pipeline di replay · Guida ufficiale alta frequenza · Riferimento prezzo CM3 Wide. Nessuna configurazione è stata collaudata sul banco.

Camera e campo visivo nel CAD · Calcoli, alimentazione e limiti CAM-01 · STEP con camera

6. Una o due schede? Tutte le alternative discusse

La richiesta successiva è stata valutare una sola scheda che faccia controllo e streaming. Sono alternative alla configurazione attualmente disegnata, non componenti da aggiungere tutti insieme. La capacità di eseguire ogni funzione separatamente non dimostra che le prestazioni simultanee siano sufficienti.

Impatto meccanico: per una Nucleo o P4 può convenire la scheda vicino al sensore, portando nel montante alimentazione e segnali di controllo. Un flat camera lungo circa 70 cm non è automaticamente compatibile. Per Raspberry è stata proposta la scheda nel vano e una camera USB sul montante, oppure una connessione CSI opportunamente verificata. La testata e il vano attuali non sono già dimensionati e raffreddati per queste alternative.

Impatto elettrico: tutte richiedono driver di potenza per RGB e ventola. Raspberry non ha un ADC equivalente all’ingresso analogico dell’ESP32 per il potenziometro: prevedere un ADC esterno o modificare il comando, oltre a riassegnare ingressi, PWM e alimentazione. L’altoparlante per la voce è aggiuntivo rispetto al buzzer. BOM e schema vanno revisionati soltanto dopo la scelta.

7. Rust su Nucleo e Python su Raspberry

Nucleo N657: possibile Rust, parte video da integrare

Embassy supporta STM32N657X0 e offre esempi per la Nucleo. La documentazione include GPIO, timer/PWM, I²C, SPI, CSI, DCMIPP ed Ethernet; questo non equivale a uno streaming H.264 completo già pronto in Rust. Nella verifica non è stata identificata una soluzione Rust completa e collaudata per la catena del nostro progetto.

Proposta discussa: STM32CubeN6, driver video ST in C e ThreadX/NetX Duo; logica del tavolo in Rust, collegata tramite un’interfaccia C/Rust limitata e documentata. Un unico sistema di scheduling iniziale; non sovrapporre automaticamente ThreadX ed Embassy. Usare trasferimenti hardware e buffer per camera, encoder e rete, gestendo cache e proprietà della memoria; il gol non deve dipendere dalla velocità dello streaming. La NPU potrebbe in seguito elaborare il disco localmente, ma serve un algoritmo/modello idoneo, non è una funzione pronta.

Per un firmware interamente Rust occorre una prova dedicata camera → encoder → rete prima dell’acquisto. L’avvio autonomo N6 richiede considerare il bootloader e la flash esterna; esempi caricati in RAM dal debugger non dimostrano ancora l’avvio all’accensione.

Raspberry Pi: Python come proposta più pratica per questo tavolo

Dopo il confronto è stato suggerito Python per arrivare prima al prototipo: consente di modificare regole, effetti, camera e collegamento all’AI con meno integrazione embedded. Questa è una raccomandazione discussa, non una scelta hardware già applicata. Rust su Linux rimane possibile, con libreria standard e librerie GPIO come RPPAL, soprattutto come obiettivo di apprendimento o per parti risultate critiche alle misure.

Python coordina; acquisizione, compressione ed elaborazioni pesanti restano in strumenti e librerie native come libcamera/rpicam e, se utile, OpenCV. Un’applicazione Python può usare librerie C/C++ senza riscriverle e senza passare necessariamente ogni pixel in un ciclo Python.

Priorità comune: il video può perdere un fotogramma; il conteggio non deve perdere un gol. Linux e Python non garantiscono tempi rigidi: verificare eventi delle porte sotto il carico massimo previsto, usare PWM hardware o driver dedicati per uscita regolare e introdurre un contatore hardware/MCU solo se le prove lo richiedono. La camera non sostituisce le barriere nelle porte.

Computer vision e traiettorie nei replay

Proposta iniziale: Python + OpenCV per il tracking, video e dati separati, replay web con Canvas. Un primo algoritmo può sfruttare campo fisso, colore e forma del disco. Una rete neurale addestrata sul nostro tavolo può essere introdotta se i test mostrano che questo metodo non basta. Nessun tracker, overlay su riprese reali o modello neurale è già implementato: il film CAD rimane una dimostrazione virtuale.

Calibrazione e riconoscimento del disco

1. Calibrazione: correggere la distorsione della lente e associare gli angoli del campo alle misure 800 × 400. Usare modalità, crop e orientamento della registrazione reale. Coordinate metriche coerenti con il CAD: centro (0,0), X da −400 a +400 e Y da −200 a +200 mm.
2. Rilevamento: OpenCV cerca candidati per colore HSV, area e forma nella regione del campo. Filtrare riflessi, grafica e oggetti simili; non basta trovare un oggetto giallo.
3. Tracking: collegare le rilevazioni nel tempo; un filtro, per esempio Kalman, può stimare posizione/velocità e aiutare nei brevi intervalli senza rilevazione. Misurare i tempi reali, senza assumere 120 frame perfetti ogni secondo.
4. Occlusioni: una previsione non è una misura. Disegnare continua la traccia osservata, tratteggiata quella brevemente prevista e interromperla quando l’incertezza cresce. Non ricostruire automaticamente colpi/rimbalzi dietro una mano; il filtro non deve smussare un urto rendendolo una curva inventata.

Illuminazione bianca stabile, fuoco bloccato dopo la calibrazione ed esposizione breve restano necessari. Una lente wide e il ritaglio a 120 fps richiedono verifiche specifiche. Per sovrapporre la grafica sull’originale, riportare i punti nello spazio corretto dei pixel: coordinate rettificate e immagine ancora distorta non sono intercambiabili.

Due modi per mostrare le traiettorie

Riproduttore web: il video originale viene riprodotto normalmente e un Canvas sovrapposto disegna scia, intero tiro, frecce, velocità, eventi e tratti incerti. I livelli si possono attivare separatamente. La grafica segue il tempo del video anche durante pausa, seek, cambio velocità e ridimensionamento, non un timer indipendente. Video e file dei dati rimangono separati: cambiare il colore della scia non richiede ricompressione.

MP4 annotato: un lavoro di esportazione applica la grafica ai frame con OpenCV/FFmpeg oppure GStreamer e produce un file unico condivisibile. Conservare sempre originale e dati. L’esportazione in differita non è una promessa di rendering a 120 fps in tempo reale.

Con 7 s reali a 120 fps si hanno circa 840 immagini se non ci sono perdite; un rallentamento 4× a 30 fps dura 28 s. La velocità fisica mostrata resta quella calcolata dai tempi di acquisizione: non si divide per quattro perché il replay è lento.

Rete neurale, Pi 4, Pi 5 e AI esterna

Se necessario, addestrare su PC un rilevatore leggero con esempi del nostro disco, battitori, mani, riflessi e luci diverse. Il rilevatore individua gli oggetti; il tracker collega le posizioni. Un modello generico non va considerato già capace di riconoscere il disco. Verificare su partite e condizioni diverse da quelle dell’addestramento.

Pi 5 non è obbligatorio per disegnare traiettorie. Registrare tutti i frame disponibili e analizzare il replay dopo il gol consente di elaborare più lentamente della cattura, senza perdere immagini già salvate. Il sistema deve però gestire lavori e buffer per non accumulare ritardi. Il commento dell’AI esterna può ricevere eventi, misure e sequenze selezionate: è un compito separato dal tracking e non richiede automaticamente tutte le 120 immagini ogni secondo.

Collaudo ancora da fare: posizioni annotate manualmente come riferimento, errore in pixel/mm, rilevazioni errate, recupero dopo occlusioni, qualità di velocità/rimbalzi; latenza del replay e carico sotto streaming e partita. Verificare anche esportazione, pausa/seek e corrispondenza fra grafica e immagine. Le soglie di accettazione non sono ancora concordate e nessuna prestazione è stata misurata.

Documento completo: computer vision e replay annotati

8. Esplorazione 3D e film del progetto

Le cinque viste in cima mantengono modelli ruotabili, selezione dei gruppi e mappe numeriche. Nell’assemblato, Position espone cursori per cornice, piano, camera, fondo, servizi, ventola, elettronica e cablaggi; Preview riproduce le clip. I cavi separati nell’esploso illustrano il percorso: non si allungano e non costituiscono una sequenza esecutiva di smontaggio.

Il film attuale dura 34 secondi, 1280 × 720, 24 fps, senza audio. Dopo la richiesta iniziale sono stati avvicinati gli strati, sincronizzati i colpi dei battitori e aggiunto il montaggio successivo della camera.

Il disco attende il servizio. I centri di disco e battitore distano 49,5 mm al contatto (22 + 27,5), con istanti dei colpi allineati ai fotogrammi. Il difensore si sposta prima del gol; verificata numericamente l’assenza di attraversamenti nella coreografia. Gol a circa 22,875 e 32 s, punteggio 2:3 → 3:3 → 4:3. Non è una simulazione dinamica degli urti, un test strutturale del montaggio o una ripresa reale.

Apri video con capitoli e download · MP4 · CAD animato

9. Distinta materiali e budget

BOM-03: 53 voci, di cui 46 per il tavolo e 7 per l’estensione video. Prima ESP32 e RGB considerati disponibili solo se sufficienti e compatibili; la seconda ESP32/camera non è dichiarata in casa. Stati alternativi dei LED nel render, motore/girante della soffiante e parti dei pulsanti non sono acquisti duplicati.

I71€ dei semilavorati derivano dai prezzi esposti Brico io; gli altri gruppi restano accantonamenti progettuali, non offerte commerciali verificate. Esclusi lavoro, utensili, CNC/stampa esterni e spedizioni. Camera, supporto, alimentazione aggiuntiva, gateway e servizio AI sono extra da quotare. Anche una migrazione a Nucleo o Raspberry richiede una distinta alternativa: non sommare schede che si sostituiscono né usare il vecchio totale come prezzo della nuova architettura.

Il budget iniziale di 100 € richiede recupero di materiali/alimentatore/minuteria oppure revisione delle funzioni. Restano da scegliere modelli reali di soffiante, piano finito, display, sensori e connettori e da misurare le strisce disponibili.

Distinta completa stampabile · Markdown · Dati della distinta

10. Cosa è verificato e come procedere

La prova fisica, inizialmente rimandata per concentrarsi sul CAD, rimane necessaria. Sequenza proposta, non ancora eseguita:

1. Chiudere i componenti: inventario delle schede e RGB disponibili, tensioni/correnti, soffiante regolabile con curva nota, piano e peso del disco. Confermare due ESP32 oppure una delle alternative.
2. Banco aria: provare piano e camera a tenuta prima della finitura; misurare pressione in più zone, scorrimento del disco su tutto il campo, rumore e temperatura. Confrontare i canali soltanto a parità di ventola e condizioni.
3. Banco elettrico: uscite di potenza, spunti e cadute di tensione, ingressi porte, correzioni manuali e accensione contemporanea dei carichi.
4. Banco camera: FOV reale all’altezza prevista, illuminazione, esposizione, latenza, frame persi e occlusioni; scegliere registrazione semplice o tracking e con quale accuratezza.
5. Integrazione: verificare gol e comandi con streaming, effetti e registrazione attivi; scollegare rete/AI e controllare che la partita continui.
6. Revisione dei file: solo dopo la scelta della piattaforma aggiornare CAD, schema, alimentazioni, BOM, software e costo complessivo.

11. Manuale di assemblaggio passo per passo

MAN-01: otto fasi, 38 passaggi illustrati e 76 controlli. Ogni passo ha un’immagine ingrandibile con didascalia: viste CAD, fotogrammi virtuali o schemi tecnici, etichettati e distinti da fotografie di un prototipo reale. Comprende pezzi identificati dalla BOM, attrezzatura, operazioni e verifiche. Checklist e note restano salvate sul browser. La funzione Stampa / salva PDF apre tutte le fasi e include tutte le immagini a colori.

Apri il manuale interattivo →

Appendici: quote nominali dalla distinta, GPIO e collegamenti EL-01, ordine di accensione, ricerca guasti e registro del prototipo. Il firmware, lo streaming e il replay restano da implementare; le animazioni esistenti non ne sostituiscono il collaudo.

12. Fonti tecniche e documenti collegati

Le fonti descrivono hardware ed esempi; non dimostrano il funzionamento del nostro assieme. Prezzi e prestazioni citati sono riferimenti della ricerca del 16 ottobre 2026 e vanno ricontrollati prima dell’acquisto.

• Ricerca costruttiva con brevetti e riscontri commerciali; fonti del modello aria; scheda SUNON.
• NUCLEO-N657X0-Q, store ST; famiglia STM32N6; esempi STM32CubeN6; esempio ST camera, AI, H.264 e USB UVC.
• Embassy: esempi Rust Nucleo/Discovery N6; periferiche Rust STM32N657X0; espansione Wi-Fi per Nucleo.
• ESP32-P4 Function EV Board; driver camera ESP32; interfacce e riscontri video Espressif.
• Raspberry Pi Zero 2 W; rpicam/libcamera e codifica software Pi 5; camere e global shutter; RPPAL per Rust e GPIO.
• Architettura di tracking e replay; OpenCV: rilevamento HSV; contorni; calibrazione; Kalman.
• GStreamer: overlay e timestamp; Raspberry: software AI; AI HATs e modelli supportati.

Cronologia sintetica: requisiti e CAD compatto → luci/display visibili e animati → ricerca e calcolo aria → impianto e schema elettrico → confronto canali → camera e AI → film con colpi corretti e montaggio camera → alternative Nucleo/Rust e Raspberry/Python. Questa raccolta conserva gli esiti e separa proposte, implementazione virtuale e collaudo reale.