esp32-eye: il monitor della ciotola d'acqua per gatti che chiama MiniCPM-V 4.7 due volte

Due schede ESP32-S3, un MacBook e due dimensioni diverse di MiniCPM-V 4.7 ora tengono un registro di quale gatto ha bevuto dalla ciotola dell'acqua e quando. Una scheda con fotocamera sorveglia la ciotola, un MacBook esegue localmente il modello piccolo per rispondere a una sola domanda specifica, e il modello grande viene chiamato solo dopo che un evento si è già verificato. Il progetto si chiama esp32-eye, si trova su {{1}}github.com/emwstudio/esp32-eye{{/1}} ed è diventato pubblico il {{2}}25 ottobre 2026{{/2}}. OpenBMB l'ha presentato nella prima settimana di novembre, ed è così che la maggior parte delle persone l'ha conosciuto.

Il modello sottostante è la parte su cui vale la pena essere precisi. OpenBMB ha caricato MiniCPM-V 4.7 su Hugging Face il 6 e 7 ottobre 2026, ha pubblicato la model card e la licenza Apache-2.0 il 12 ottobre e ha diffuso un comunicato stampa in inglese tramite PR Newswire il 15 ottobre. Quindi non si tratta di una storia di lancio, e il monitor per gatti non è un benchmark del fornitore. È la più dettagliata implementazione pubblica del modello che qualcuno fuori dal laboratorio abbia documentato finora, e per caso è un elettrodomestico.

Cosa fa effettivamente la build

L'hardware è deliberatamente economico e leggermente scomodo. Un Waveshare ESP32-S3-CAM-OV5640 è posizionato sul bordo della ciotola e trasmette in streaming frame JPEG da 1024×768 più l'audio del microfono via Wi-Fi. Una seconda scheda, una Waveshare ESP32-S3-Touch-AMOLED-2.16, è il display da scrivania: un pannello da 480×480 che mostra una striscia video in diretta, quattro schede dei gatti, un conteggio giornaliero rispetto a un obiettivo di otto bevande e una piccola animazione di evidenziazione quando un gatto viene confermato. Il MacBook è il cervello. Un server FastAPI riceve lo stream, esegue la logica di rilevamento, scrive su SQLite e ritaglia un clip MP4 per ogni evento con cinque secondi di pre-roll, tre secondi di coda e l'audio originale.

Il posizionamento della telecamera è la prima cosa da capire, perché spiega l'intera progettazione del rilevamento. L'obiettivo guarda dal bordo della ciotola verso l'alto, verso il muso del gatto, il che significa che la superficie dell'acqua non è nell'inquadratura. Il sistema non può vedere un gatto che beve. Può solo vedere un gatto che occupa l'area della ciotola e deduce il resto dalla persistenza e dall'identità. Chiunque abbia realizzato un progetto con telecamera sa che è qui che di solito l'onestà se ne va; qui è scritto nel README.

Prima che venga eseguito qualsiasi modello, la pipeline esegue una differenza di sfondo in scala di grigi rispetto a un fotogramma di riferimento con ciotola vuota. Se la quota di primo piano è inferiore al 15 percento, il fotogramma viene scartato senza coinvolgere una rete neurale. Oltre il 15 percento, al MiniCPM-V 4.7 1B locale viene posta una domanda: c'è un gatto in questa immagine? Una risposta positiva unita a una quota di primo piano superiore al 35 percento diventa un voto affermativo. Tre voti affermativi consecutivi aprono un evento; quattro voti negativi consecutivi lo chiudono.

La suddivisione in due modelli è l'aspetto ingegneristico interessante.

Eseguire un modello di visione ogni 1,5 secondi per sempre è una cattiva idea, e la build lo considera tale. Il modello 1B viene eseguito localmente tramite llama.cpp come quantizzazione Q4_K_M su un llama-server compatibile con OpenAI sulla porta 8080. È abbastanza economico che il progetto possa permettersi di chiamarlo ripetutamente, ma è comunque subordinato alla differenza di sfondo, così che una stanza vuota non costi nulla. Il compito del modello 1B è deliberatamente ristretto: presenza, non identità, non comportamento.

L'identità è la domanda costosa, e viene posta una volta per evento. Quando un evento si chiude, il server campiona i fotogrammi dal clip e li invia a MiniCPM-V 4.7 35B-A3B tramite l'API cloud di ModelBest, con una foto di riferimento per ciascuno dei quattro gatti. Il modello di grandi dimensioni restituisce un identificatore del gatto, un valore di confidenza e un sì/no sul fatto che la scena sia una scena di bevuta. I fotogrammi che non superano il controllo della bevuta vengono scartati e non conteggiati. Le identità ambigue vengono memorizzate come sconosciute anziché assegnate con la forza al gatto più vicino, e se la chiamata cloud fallisce l'evento entra in un percorso di retry invece di essere riempito retroattivamente con l'ipotesi del modello 1B.

Quella divisione del lavoro è lo stesso argomento che la letteratura on-device porta avanti da due anni, ora con tanto di ricevuta. Un modello piccolo è un sensore. Un modello grande è un giudice. Il modello di costo segue direttamente: il 1B si paga in millisecondi e batteria, il 35B si paga in token, e il conto dei token scala con il numero di eventi di bevuta anziché con il numero di frame. In una casa con quattro gatti si tratta di una manciata di chiamate al giorno.

Che cosa dimostrano e non dimostrano gli 89 eventi

Il post di OpenBMB riporta che in una casa con quattro gatti, nell'arco di tre giorni, sono stati verificati manualmente 89 eventi di abbeveraggio e l'identità di ogni gatto era corretta. È un risultato reale e anche limitato. Il compito di identificazione è una scelta chiusa a quattro vie tra gatti per cui il sistema ha già foto di riferimento. Non è una re-identificazione open-set, non è un'affermazione su cento gatti e non è un'affermazione che il sistema funzioni in una casa che non ha mai visto.

Ottantanove eventi in tre giorni equivalgono all'incirca a trenta al giorno per quattro gatti, ovvero circa sette e mezzo per gatto al giorno, il che è plausibile per uno studio sull'assunzione di acqua e fin troppo piccolo per stimare un tasso di errore con una qualche sicurezza. Un sistema che è corretto 89 volte su 89 potrebbe comunque sbagliare una volta su cinquanta. Il numero da tenere a mente non è il 100 percento; è che nessuno ha dovuto correggerlo in tre giorni di uso ordinario.

C’è anche un’avvertenza sulla provenienza. L’autore è un ambasciatore della comunità OpenBMB e la dimostrazione è stata eseguita sull’account di OpenBMB stesso. Ciò non rende falso il risultato, ma significa che la validazione non è stata progettata da uno scettico e nessuna terza parte l’ha ripetuta.

Perché il 1B non identifica il gatto

Il README contiene la frase più utile dell'intero progetto, ed è un risultato negativo: con tre gatti di colore chiaro che si somigliano, il MiniCPM-V 4.7 1B locale non era affidabile nello sceglierne uno su quattro. Il team l'ha provato, ha riscontrato che la discriminazione a quattro vie non era affidabile e ha spostato l'identità sul 35B invece di rilasciare una supposizione.

Vale la pena soffermarsi su questo, perché va contro il modo in cui i modelli di visione di piccole dimensioni vengono solitamente proposti. Un modello da 1,55 miliardi di parametri che ottiene buoni risultati sui benchmark OCR e sui grafici non è automaticamente bravo a distinguere due animali simili in una visuale fissa della telecamera. L'identità a grana fine è esattamente il tipo di compito in cui un budget compresso di token visivi penalizza: le differenze tra due gatti tigrati sono piccole, locali e facili da perdere facendo una media. La risposta della build — usare il modello piccolo per la domanda facile e pagare per quella difficile — è più utile di qualsiasi riga di classifica.

Quanto costa gestirlo e cosa succede quando la tratta cloud fallisce

Solo un segmento di questa pipeline ha un costo. Il modello 1B è un file GGUF locale su un laptop, quindi il costo marginale di un frame è l'elettricità. Il modello 35B è una chiamata ospitata verso l'API di ModelBest, che è l'endpoint proprietario del fornitore anziché un host di terze parti, e il progetto richiede una chiave per usarla. Il README specifica chiaramente che il modello 35B non è distribuito localmente: il MacBook non contiene 35 miliardi di parametri, contiene un client.

Quella separazione crea una modalità di errore che il progetto gestisce anziché nascondere. Se la chiamata cloud fallisce, l’evento viene ritentato; il risultato 1B non viene mai promosso a identità. Per un progetto amatoriale è insolitamente disciplinato. Per qualunque progetto di stampo produttivo, lo stesso design colloca un singolo endpoint esterno sul percorso critico di un sistema il cui intero scopo è registrare eventi senza supervisione.

Questo è il vuoto che un router colma, e vale la pena essere precisi su ciò che un router può e non può fare qui. OrcaRouter offre un'unica API per oltre 200 modelli con il prezzo di listino del fornitore trasferito a 0% di ricarico, più il failover automatico tra gli upstream, che è la forma giusta per una pipeline come questa. Attualmente non include MiniCPM-V 4.7, quindi il ramo da 35B in esp32-eye girerebbe comunque sull'API del fornitore stesso. La versione onesta del consiglio è: mantieni il percorso di retry e, se lo step di identità diventa critico, metti dietro la stessa chiamata un secondo modello che puoi effettivamente raggiungere.

Cosa non è ancora stato confermato

Tre cose cambierebbero il peso che questa build merita. La prima è una seconda abitazione. Tutto ciò che è stato riportato finora proviene da una sola casa con quattro gatti noti e una telecamera fissa. La seconda è una prova più lunga: tre giorni non bastano a distinguere un sistema che funziona da un sistema che funziona finché un gatto non cambia mantello, la luce non cambia o non arriva un visitatore. La terza è una verifica indipendente degli 89 eventi, che al momento si basa sulla revisione manuale dello sviluppatore stesso.

Ciò che è già consolidato è più modesto e più utile. MiniCPM-V 4.7 esiste in due dimensioni che si possono comporre: un modello denso da 1,55B che gira in un file Q4_K_M su un laptop, e un mixture-of-experts sparso da 35,2B che attiva circa 3 miliardi di parametri per token ed è abbastanza bravo in un compito di identità a quattro vie da poterglisi affidare. Una ciotola per gatti è un posto strano per dimostrarlo, ma è reale.

Se vuoi riprodurlo, il repository contiene il firmware della fotocamera, il firmware AMOLED, il server FastAPI e gli script di test del modello, e l'unico account di cui hai bisogno è una chiave ModelBest per la parte di identità. Se vuoi leggere il modello invece di eseguire il gatto, i numeri del fornitore sono il punto da cui partire e le avvertenze sono nel repository.