Air hockey: il progetto completo.
Camera da 25 mm · piano da 3 mm · 741 fori da 1 mm
Manuale di assemblaggio · 38 passaggi e checklist →
Nuovo · Display frontale 10,1″ / 13,3″ e replay animato 3D →
Apri questo CAD a tutta pagina ↗ ·
Il primo caricamento può richiedere alcune decine di secondi. Attendi la comparsa del modello e dell’elenco dei nove gruppi.
Il CAD mostra la geometria nominale da 25 mm. La vista aria usa il caso 100%; le selezioni qui a destra aggiornano la mappa e i numeri, non il CAD.
Quanto passa in ciascun foro?
Stima con curva della soffiante SUNON PF97331B1. Camera sigillata, senza disco sul piano. Griglia e aspirazione nel vano non risolte: perdite ancora ipotizzate.
L’uniformità è quella di una camera ideale. Getto all’ingresso, vortici, piccole perdite e irregolarità dei fori possono peggiorarla. Le frecce 3D e i traccianti illustrano i risultati: non sono una simulazione CFD tridimensionale.
Ipotesi, sensibilità e attendibilità
Rete stazionaria a 741 nodi: pressione e portata risolte insieme alla curva pressione–portata della soffiante. Due deflettori da 70 mm delimitano l’ingresso; il cassetto è sotto il fondo della camera.
- Aria a 20 °C; nessuna perdita dalle giunzioni; nessun disco o battitore che copra i fori.
- Fori: termine viscoso cilindrico più accelerazione del getto e perdita d’ingresso (K totale 1,5). I fori sono corti: lo sviluppo del flusso è approssimato.
- Canali fra nodi: resistenza viscosa rettangolare più termine inerziale con fattore Darcy assunto 0,03. Sostegni puntuali e getto 3D non risolti.
- Raccordo: sezione minima ipotizzata 39 × 26 mm, K totale 2. Geometria del raccordo ancora da dettagliare sul componente reale.
- Regimi 60/80% ottenuti dalle leggi di similitudine; non sono percentuali PWM. Questa variante della ventola richiede verificare il metodo di regolazione.
- Curva letta dal grafico SUNON: errore di lettura stimato ±12,5 Pa e ±0,5 CFM, oltre alle tolleranze del costruttore.
Il calcolo non certifica il galleggiamento del disco né la rigidità del piano. Servono prove reali; il prezzo della soffiante non è ancora validato nel budget.
Metodo e risultati completi · Fonti e curva letta · Dati del calcolo
Tutte le scelte, i confronti e i punti aperti
Air hockey compatto per due adulti, senza gambe, da appoggiare su un normale tavolo da pranzo. Questa pagina raccoglie il progetto costruttivo, i risultati numerici, le funzioni richieste e le alternative discusse fino a Raspberry Pi con Python.
1. Richieste e stato delle decisioni
| Argomento | Contenuto | Stato |
|---|---|---|
| Uso e formato | Compatto, per adulti; appoggio sul tavolo da pranzo, maniglie incassate, vano accessori e piedini morbidi. | Richiesto; rappresentato nel CAD |
| Gioco | Due sensori nelle porte, segnapunti, correzione manuale +/− per ciascun giocatore, avvio partita e mute. | Richiesto; schema proposto, firmware da realizzare |
| Effetti | RGB 5050 tradizionali, suoni e regolazione dell’aria. | Richiesto; caratteristiche elettriche reali ancora da verificare |
| Materiale disponibile | ESP32, Arduino e strisce RGB 5050 dichiarati già in casa. Arduino aggiuntivo non necessario nella soluzione attuale. | Disponibilità dichiarata; modelli e quantità da inventariare |
| Camera e AI | Ripresa della partita, commento/statistiche e analisi del disco e dei tiri; seconda ESP32 dedicata al video. | Funzioni e seconda scheda confermate; modulo e prestazioni aperti |
| Alternative successive | Unificazione su STM32 N657, ESP32-P4 oppure Raspberry Pi; confronto Rust/Python. | Proposte aperte; nessun aggiornamento automatico del CAD o dei pin |
| Budget | Obiettivo iniziale 100 €; stima preliminare del solo tavolo 166–241 €, video e AI esclusi. | Obiettivo attualmente non soddisfatto |
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.
| Parte | Dimensioni / quantità | Materiale e indicazioni |
|---|---|---|
| Piano forato | 800 × 400 × 3; 741 fori Ø1 su griglia 39 × 19, passo 20 | Faesite nominale3 da Brico io: finitura e scorrimento da verificare su campione. BR-02: battute interne, guarnizione compressa nominale1 e otto M3 a filo; tenuta e rigidità da provare. |
| Base removibile | 900 × 500 × 9 | OSB9; apertura per manutenzione e fissaggi smontabili. |
| Fondo camera aria | 824 × 424 × 12 | MDF12 sigillato; ingresso 100 × 20 a X=0, Y=180. |
| Fianchi | 2 da 900 × 89 × 12; 2 testate da 476 × 89 × 12 | MDF12; incassi per maniglie, cassetto, porte, aspirazione e presa DC. |
| Cornice superiore | 2 bordi da 800 × 50 × 12; 2 da 500 × 50 × 12 | MDF12 sigillato e finito; scassi per comandi, display e diffusori. |
| Camera e sostegni | Altezza utile 25; 8 sostegni 15 × 15 × 25; 2 deflettori 70 × 25 × 3 | Pareti lunghe824 × 25 × 12, testate400 × 25 × 12; giunti su facce12 × 25. Battute784/400 × 8 × 12 con guarnizione1; due mensole424 × 38 × 12 sotto il fondo. Deflettori scaricati presso le battute. |
| Cassetto | 180 × 94 × 36 esterni; 174 × 88 interni | Pareti e fondo in faesite3. Alloggiamento con fianchi MDF12 e pelli3. Alloggiamento esterno 208 × 100 × 44, separato dalla camera pressurizzata. |
| Gioco e appoggi | 2 battitori Ø55, alti 32; disco Ø44 × 5; 4 appoggi 50 × 35 × 4 | Disco liscio e leggero, peso/materiale da determinare con la prova aria; gomma morbida sotto il tavolo. |
| Porte | Tunnel90, largo110, alto7,5 dopo raccordo iniziale10→7,5 | Moduli esterni smontabili, sporgenza40 per estremità. PavimentoZ98, fascioX±450/Z101,75 a50 dalla linea, recupero inferiore90 × 25 con sogliaZ57. Sensori nominali20 × 10 × 8 e supporti separati. |
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.
Come sono realizzati i tavoli trovati nella ricerca
- US5104607: camera unica con sostegni puntuali; esempio con fori circa 1,016 mm a passo 25,4 mm. L’altezza utile del plenum non è identificabile con la curva periferica del fondo.
- US3927885: anima da 25,4 mm con canali sotto le file, aperture verso una camera inferiore da 25,4 mm; larghezza e profondità dei singoli canali non dichiarate.
- US7441775B2: soffiante centrifuga laterale, collettore trasversale, aperture e canali longitudinali; quote dei canali e curva della soffiante assenti.
- US6109607A: architettura da appoggio con alimentazione laterale, pertinente all’assenza di gambe.
- Hathaway Blue Line 32, scheda storica: campo circa 790,6 × 384,2, piano 3,175, 741 fori a passo 19,05, camera 12,7; ventola assiale AC 120 V, 24 W. È un confronto costruttivo, non la ventola prevista nel nostro tavolo DC.
Le quote dei nostri canali sono scelte progettuali, non dimensioni copiate dai disegni dei brevetti. Ricerca completa con fonti e limiti di consultazione.
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
| Architettura, al 100% teorico | Portata m³/h | Pressione ai fori Pa | Variazione max−min / media |
|---|---|---|---|
| Camera comune 25 mm | 39,08 | 346,4–347,3 | 0,130% |
| 19 canali, un ingresso per fila | 37,75 (−3,38%) | 322,9–327,7 | 0,783% |
| 19 canali, due ingressi per fila | 38,59 (−1,25%) | 337,9–338,9 | 0,150% |
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.
| Sottosistema | Proposta e comportamento |
|---|---|
| Strisce RGB | Due sedi da 790 mm, 1,58 m utili totali; diffusore superiore 12 mm e risvolto esterno 8 mm. RGB 5050 analogici a quattro fili, tre MOSFET AO3400A proposti: le due strisce cambiano insieme. Nessuna animazione indipendente del singolo LED con queste strisce. |
| Effetti luminosi | Ciano fisso, lampeggi rosa al gol, pulsazione e sequenze finali. Colori e animazioni sono dimostrativi; l’opacità nel CAD non è una misura fotometrica. “5050” indica il formato del LED, non garantisce tensione 12 V, assorbimento o passo di taglio. |
| Segnapunti | Due cifre a sette segmenti; HT16K33 e due Kingbright SC56-11EWA rosse come riferimento elettrico. Il ciano nel CAD è illustrativo. Quattro pulsanti consentono +/− per ciascun giocatore in caso di errore. |
| Porte | Due barriere IR: trasmettitore e ricevitore per porta; uscite compatibili 3,3 V o collettore aperto. Rilevamento, riarmo e prevenzione del doppio conteggio da implementare. |
| Ventola | Potenziometro 10 kΩ proposto; ingresso ADC e interfaccia a transistor per ventola con comando ammesso dal produttore. Tachimetria opzionale; il solo disegno del filo PWM non rende regolabile la SUNON A99. |
| Suoni | Buzzer magnetico passivo 5 V con MOSFET e diodo, pulsante mute. Produce toni, non riproduce la telecronaca vocale: per quella servono uscita audio, amplificazione/altoparlante o un dispositivo esterno. |
| Cablaggio | Piastra removibile 300 × 135, connettori e distanziali. Fili sotto il fondo o nei bordi esterni al volume pressurizzato. Colori nel CAD illustrano funzioni, non certificano uno standard o un cablaggio completo. |
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.
Assegnazione GPIO EL-01 — soltanto ESP32 WROOM
| GPIO | Rete | Direzione | Funzione |
|---|---|---|---|
| 16 | PWM_R | OUT | RGB rosso |
| 17 | PWM_G | OUT | RGB verde |
| 18 | PWM_B | OUT | RGB blu |
| 19 | FAN_CTL | OUT | Ventola: PWM invertito sul transistor |
| 23 | BUZZ_CTL | OUT | Toni del trasduttore magnetico |
| 21 | SDA_3V3 | IO | I2C SDA |
| 22 | SCL_3V3 | IO | I2C SCL |
| 35 | GOAL_A | IN | Barriera porta A |
| 39 | GOAL_B | IN | Barriera porta B |
| 34 | FAN_TACH_IN | IN | Tachimetria opzionale |
| 36 | AIR_ADC | IN | Potenziometro ADC1_CH0 |
| 13 | KEY_A_PLUS | IN | Punteggio A + |
| 14 | KEY_A_MINUS | IN | Punteggio A - |
| 25 | KEY_B_PLUS | IN | Punteggio B + |
| 26 | KEY_B_MINUS | IN | Punteggio B - |
| 27 | KEY_START | IN | Avvio partita |
| 32 | KEY_MUTE | IN | Suoni on/off |
Numeri GPIO, non posizione fisica del connettore. Schema non trasferibile automaticamente a ESP32-S3, Nucleo o Raspberry; ingressi, ADC, livelli e PWM vanno riprogettati. I dettagli dei fusibili, passivi, connettori e collegamenti pin per pin sono nelle tavole.
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
- Sensori delle porte: autorità del punteggio, con correzione manuale disponibile. La visione aggiunge informazioni e non annulla automaticamente un gol.
- Acquisizione: immagini con identificativo e timestamp di cattura, eventi di gioco sincronizzati. La ricezione dei pacchetti non fornisce da sola il tempo del tiro.
- Tracker: calibrazione dei quattro angoli, correzione ottica, posizione e traiettoria con indice di confidenza; gestione di occlusioni da mani e battitori.
- 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.
| Frame effettivi al secondo | Spostamento fra due immagini |
|---|---|
| 20 | 250 mm |
| 30 | 167 mm |
| 60 | 83 mm |
| 120 | 42 mm |
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.
| Camera | Modalità documentata | 1080p120? |
|---|---|---|
| Raspberry Camera Module 3 | 1536 × 864 a 120 fps; 2304 × 1296 a 56 fps | No nelle modalità riportate |
| Raspberry HQ Camera | 1332 × 990 a 120 fps; 2028 × 1080 a 50 fps | No nelle modalità riportate |
| Raspberry Global Shutter Camera | 1456 × 1088 a 60 fps | No; non è un sensore Full HD |
| Arducam 2.3MP Color Global Shutter USB3 UVC con ISP, modello della pagina citata sotto | Il costruttore dichiara MJPEG 1920 × 1080 a 120 fps; YUYV Full HD a 60 fps | Candidata USB, non collaudata sul nostro Raspberry |
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
| Camera | Modo utile | Valutazione sul nostro tavolo |
|---|---|---|
| Camera Module 3 Wide, colori / rolling shutter | 1536 × 864 a circa 120 fps → 720p | Prima candidata economica, con calibrazione e buona luce. Riscontro Melopero: 37,58 €, non disponibile al controllo; spedizione da verificare. |
| Camera Module 3 Standard, colori / rolling shutter | Stesso modo veloce, con ritaglio | A 70 cm la stima ottica copre circa 606 × 349 mm: il campo 800 × 400 non rientra. Non selezionarla senza cambiare altezza/ottica. |
| Raspberry HQ IMX477, colori / rolling shutter | 1332 × 990 a 120 fps | Ottica separata da scegliere considerando il ritaglio. Più ingombro e costo, non prima scelta. |
| Raspberry Global Shutter IMX296, colori | 1456 × 1088 a 60 fps | Fedeltà geometrica del movimento, ma non soddisfa 120 fps nelle specifiche ufficiali. |
| Arducam B0610 USB3 UVC, colori / global shutter | MJPEG 720p120 e 1080p120 dichiarati; YUYV 720p120 | Prima candidata tecnica USB con luce adeguata; cavo incluso 1 m da verificare sul percorso completo. Sample price produttore 139,99 USD, non prezzo consegnato UE. Riconfermare modalità, revisione e campo visivo veloce. |
| Arducam B0495 AR0234 USB3 | YUY2 1920 × 1200 a 50 fps; 960 × 600 a 80 fps | Non è equivalente alla B0610 e non soddisfa 720p120 nelle specifiche pubblicate. |
| OV9281 global shutter monocromatica, CSI | 120 fps e oltre secondo SKU / RAW8 o RAW10 | Interessante per tracking, meno adatta ai replay a colori richiesti. Confermare sensore/modulo/driver esatti. |
| OV9281 USB B0332 | Pagina corrente: MJPEG 1280 × 800 a 100 fps | Non assumere 120 fps dal nome dell’URL. Divergenza fra titolo e tabella, da chiarire prima dell’acquisto. |
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.
| Soluzione | Punti utili | Limiti / lavoro necessario | Ruolo nella discussione |
|---|---|---|---|
| ESP32 controllo + ESP32-S3 camera | Separa gioco e video; riusa la prima ESP32 disponibile. Camera con PSRAM e Wi-Fi nella testata. | Due firmware, sincronizzazione e gateway; prestazioni di streaming/tracking da misurare. | Riferimento attuale CAD / EL-01 / BOM-03 |
| Una ESP32-S3 con PSRAM | Possibile prototipo economico con camera MJPEG e controllo sullo stesso MCU. | Verificare GPIO residui, memoria, driver e carico simultaneo; non garantisce tracking rapido. | Alternativa aperta |
| NUCLEO-N657X0-Q | STM32N657 Cortex-M55, camera MIPI CSI-2, H.264 hardware, Ethernet e acceleratore AI. | Camera separata, Wi-Fi mediante modulo aggiuntivo. Esempi video ST da adattare alla Nucleo, memoria, camera e rete effettive. | Candidata a un solo MCU; sola scheda intorno a 75 USD nello store ST consultato, non preventivo italiano |
| STM32N6570-DK Discovery | Piattaforma ST più completa con camera, memoria, Ethernet, audio e display; base degli esempi video. | Più costosa e ingombrante del necessario; non confonderla con la Nucleo. | Riferimento software / sviluppo, non selezionata |
| ESP32-P4 Function EV Board | Ingresso MIPI e encoder H.264, possibilità di accorpare controllo e video. | Una sola scheda ma Wi-Fi affidato a un secondo chip ESP32-C6. Verificare versione, periferiche e integrazione. | Alternativa nell’ambiente Espressif |
| Raspberry Pi Zero 2 W | Linux, camera CSI, Wi-Fi, GPIO e H.264 hardware. | Risorse inferiori a Pi 4/5; streaming più carichi aggiuntivi da provare. | Prima alternativa Linux compatta |
| Raspberry Pi 4, 2–4 GB | Linux, codifica H.264 hardware, rete e controllo sullo stesso computer. | Gestire avvio, alimentazione, archiviazione, raffreddamento e acquisizione degli eventi sotto carico. | Proposto per controllo e streaming con AI esterna, soprattutto se già disponibile |
| Raspberry Pi 5, 4 GB | Più risorse CPU per elaborazione immagini e tracking locale, oltre al controllo e alla rete. | H.264 codificato in software: maggiore potenza non significa automaticamente latenza video inferiore. Misurare carico e temperatura. | Proposto se si sviluppa anche visione locale; nessun acquisto deciso |
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.
| Servizio proposto | Responsabilità | Comportamento richiesto |
|---|---|---|
| Controllo partita | Eventi delle due porte, conteggio, correzioni +/−, avvio/mute, regolazione aria e sequenze LED. | Indipendente dalla rete; eventi con timestamp e riarmo definito. Lettura GPIO tramite eventi del kernel e verifica degli impulsi reali. |
| Camera / video | Acquisizione, codifica, streaming ed eventuale registrazione. | Separato dal controllo, code limitate, gestione dei frame persi e delle disconnessioni; misurare latenza invece di accumulare immagini vecchie. |
| Gateway / AI | Tracker, statistiche, adattatore al servizio esterno e commento. | Un blocco dell’AI non interrompe il gioco; mostrare confidenza e non inventare traiettorie mancanti. |
| Interfaccia e supervisione | Pagina web di impostazioni, stato, registrazioni, diagnostica e avvio dei servizi. | Servizi Linux avviati automaticamente, riavvio controllato, log, arresto pulito e limiti dei file registrati. |
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
- 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.
- 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.
- 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.
- 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.
| Dati associati alla clip | Uso |
|---|---|
| Frame, timestamp di acquisizione e tempo nel video | Sincronizzare replay e misure, riconoscere immagini mancanti; non usare soltanto l’arrivo dei pacchetti. |
| Posizione in pixel e in millimetri | Disegno corretto e misure sul campo; salvare la versione della calibrazione. |
| Stato osservato / previsto / perso e confidenza | Rendere visibili i limiti dell’analisi, senza inventare traiettorie complete. |
| Velocità stimata ed eventi con origine | Distinguere gol da sensore, correzione manuale e possibili colpi/rimbalzi stimati dalla visione. |
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.
| Obiettivo | Configurazione da provare | Cosa non è garantito |
|---|---|---|
| Replay e traiettoria dopo il gol | Pi 4 da 4 GB, OpenCV e acquisizione nativa separata; analisi della clip registrata in differita | Tempo dal gol al replay annotato disponibile; carico mentre il gioco continua |
| Overlay su telefono o PC | Video + dati + Canvas sul dispositivo di visione | Sincronizzazione e fluidità, da verificare sul client |
| Traiettorie live e più elaborazione locale | Pi 5 con pipeline misurata; risoluzione di analisi ottimizzata | 120 inferenze/s e assenza di interferenze con il controllo del tavolo |
| Reti neurali più impegnative | PC esterno oppure Pi 5 con AI HAT+ / Hailo e modello compatibile | Compatibilità, accuratezza e prestazioni complete; i TOPS non misurano l’intera applicazione |
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.
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.
| Tempo | Cosa si vede |
|---|---|
| 0–2 s | Strati separati in primo piano. |
| 2–10 s | Riassemblaggio del tavolo; supporto e cavi verticali della camera omessi in questa sola inquadratura. |
| 10–13 s | Montante e braccio si accostano al tavolo già chiuso. |
| 13–16 s | La testata sale di 100 mm fino all’attacco sotto il braccio; cavi visibili a montaggio terminato. |
| 16–24 s | Servizio e ribattute, LED e segnapunti. |
| 24–34 s | Vista virtuale dall’obiettivo; secondo gol e reazione RGB. |
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.
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.
| Gruppo, tavolo senza video | Stima € |
|---|---|
| Pannelli Brico io e listello abete | 71 |
| Soffiante | 25–45 |
| Alimentatore | 10–20 |
| Elettronica e comandi, esclusa ESP32 disponibile | 30–50 |
| Cavi e connettori | 10–20 |
| Diffusori, raccordi, minuteria, tenuta e finitura | 15–25 |
| Battitori e disco | 5–10 |
| Totale preliminare | 166–241 |
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
| Ambito | Verifiche registrate nel progetto | Ancora da fare |
|---|---|---|
| CAD | BR-02: dieci STEP validi,61componenti della lista tagli e8ingombri BOM confrontati; assenza di interferenze fra i pezzi strutturali controllati nell’assemblato e nelle due varianti. Render e fotogrammi aggiornati. | Giunzioni, pezzi reali, tolleranze, rigidità del piano e stabilità del montante. |
| Aria | Rete numerica, bilancio, punto di lavoro, confronto camera/canali e sensibilità; controlli automatici dell’implementazione. | Pressioni reali, flusso con il disco, perdite, rumore, curva della ventola e aspirazione nel vano. |
| Elettronica | Schema proposto, netlist, distinta e percorsi illustrativi. | ERC/SPICE se applicabili, PCB/cablaggio effettivo, assorbimenti, dissipazione e prove hardware. |
| Video animato | Contatti della coreografia, fasi camera, decodifica MP4 e riproduzione/capitoli nel browser. | Non sostituisce test fisici o acquisizione video reale. |
| Camera / AI / software | Calcolo FOV ideale e confronto delle architetture su fonti ufficiali. | Firmware/applicazioni, streaming, frame rate effettivo, sincronizzazione, tracking, AI e prova sotto carico. |
La prova fisica, inizialmente rimandata per concentrarsi sul CAD, rimane necessaria. Sequenza proposta, non ancora eseguita:
- 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.
- 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.
- Banco elettrico: uscite di potenza, spunti e cadute di tensione, ingressi porte, correzioni manuali e accensione contemporanea dei carichi.
- Banco camera: FOV reale all’altezza prevista, illuminazione, esposizione, latenza, frame persi e occlusioni; scegliere registrazione semplice o tracking e con quale accuratezza.
- Integrazione: verificare gol e comandi con streaming, effetti e registrazione attivi; scollegare rete/AI e controllare che la partita continui.
- 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.
| Fase | Passi | Contenuto |
|---|---|---|
| 1 | 01–04 | Configurazione, componenti reali, attrezzatura e riferimenti delle quote. |
| 2 | 05–09 | Campione, taglio, 741 fori, aperture e sedi dei componenti. |
| 3 | 10–14 | Cassone, giunti, cassetto, recupero e porta campione. |
| 4 | 15–19 | Camera aria, appoggi, variante a canali, soffiante, tenuta e piano. |
| 5 | 20–23 | Cornice, RGB, comandi, cablaggi e manutenzione dal fondo. |
| 6 | 24–29 | Distribuzione, ESP32, display, sensori, carichi e firmware da realizzare. |
| 7 | 30–33 | Inquadratura, supporto camera, alimentazione e prova video/replay. |
| 8 | 34–38 | Chiusura, collaudi, verbale e manutenzione. |
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.